Achmad Mardiansyah's Journal

Hari ini berarti sudah 12 jam lebih website GLC ngak bisa diakses baik melalui http maupun ssh. Jadi, ketika anda membuka website GLC, website tersebut tidak akan menghasilkan apa2 selain blank. Bisa diakses sih, cuman hasilnya timeout karena mungkin yang akses banyak sekali sehingga load server menjadi tinggi sekali. prakiraan saya, semua pengunjung yang datang pada ngakses halaman ini. di facebook beberapa rekan memberikan saran untuk troubleshooting, dan saya sangat mengapresiasi sekali pendapat mereka. berikut ini hal2 yang dapat kita ambil sebagai pelajaran:

• Ketika troubleshooting, adalah wajib hukumnya untuk berpikir kritis, logis, analitis, dan sistematis.
  • kritis dalam praktis berarti tidak langsung menerima data/informasi/masukan yang ada. semua input yang masuk perlu di verifikasi dengan proses2 sesudahnya.
  • Logis artinya harus masuk akal dan mempunyai sebab akibat yang jelas. dalam kasus ini, troubleshooter harus tahu cara kerja aplikasi (ssh), tahapannya bagaimana, kemudian stuck dimana.
  • Analitis artinya mampu memahami data/informasi yang diberikan dan membuat keputusan berdasarkan data/informasi yang dimiliki. dalam analitis juga perlu dipersiapkan logika IF-THEN-ELSE yang banyak untuk mendiagnosis masalah. tentunya agar punya kemampuan analisis masalah yang baik diperlukan skill teknis yang mumpuni. Dalam kasus ini, troubleshooter wajib punya sesuatu yang bisa dipakai sebagai acuan untuk mengambil keputusan. nah salah seorang rekan, memberikan saran yang bagus sekali untuk mencoba koneksi ssh dengan opsi verbose sehingga terlihat jelas tahapan koneksinya.
  • Sistematis artinya kita perlu berpikir sistemik (bukan spesifik), maksudnya kita memandang system yang kita analisys adalah sebuah system dimana terdiri dari subsystem (misal: komponen2) merupakan bagian dari system yang lebih besar, sehingga dapat dipengaruhi/mempengaruhi system/komponen lain. konsekuensinya, dalam kasus “susah login SSH”, bisa jadi karena ada sebab internal atau external.
• dari hasil verbose, tahap koneksi sudah sampai pada “entering interactive shell” yang berarti sudah dapet shell
• ada yang berkomentar “ssh daemonnya gak jalan kali mas?”. komentar ini mentah karena ada reply dari server.
• ada yang berkomentar “ssh_exchange_identification: Connection closed by remote host?”. komentar ini mentah karena tahap koneksi sudah sampai pada shell. umumnya symptom ini terjadi ketika koneksi kita ditolak, biasanya karena hosts.deny
• ada yang berkomentar “mas… Install ulang saja servernya“. wuah… ini apalagi… langsung dibuang ke laut (sorry…) hehehe ya jelas aja kalo ini diikuti berarti menghina admin, karena adminnya ngak tau apa2. di company besar, mengusulkan ini bisa jadi mengundang surat peringatan atau ancaman dipecat… :-p
• ada yang berkomentar “apalagi kayaknya ada yg ganti privilledge file auth_keynya… jadi accountnya jadi ga bisa baca private keynya…“. ini bisa jadi sebab terutama untuk koneksi yan udah trusted sehingga ngak perlu masukin password lagi. nah kalo key yang sudah disetup berubah, maka jadi ngak bisa login. tapi masalahnya bukan ini.
• ada yang berkomentar “hapus aja directory .ssh“. ehem.. sayapun balik nanya apa dasarnya & kenapa saya harus mengikuti sarannya? dan dijawab, “saya sering mengalaminya.. biasanya terjadi kalau ada pergantian server ip sama.. tetapi mesin berbeda.. dan diremote menggunakan client yang sama“. oh begitu ternyata. sayang sekali, sering mengalami bukan berarti otomatis bisa diterapkan dalam kasus ini. Jika problemnya adalah known-hosts, kenapa hasil debug sampai pada tahap ‘entering interactive shell’? Berarti masalahnya bukan ada pada known-hosts. Memberi solusi tanpa ada dasar yang kuat (mis: dari hasil debug), bisa jadi salah obat. Karena itu (mohon maaf) usulannya tidak saya laksanakan.
• ada yang berkomentar “saya rasa bukan known hosts. kalo itu problemnya, error output yang terjadi adalah tentang “key mismatch”. menurut saya kasus pak Achmad lebih mirip dengan problem di IP network/IP Backbone. misalnya seperti network split, ato dilewatin ke load balancer yang ga men-keep by session. Karena kalo servernya ga diutak-atik, ga mungkin kan behavior ssh servernya aneh begitu? lain cerita kalo sudah bisa masuk, tapi eksekusi command lemot. patut dicurigai adalah hardware faulty. Dan suspect pertamanya adalah hardisk ato HDD/RAID controllernya yang bermasalah. mumpung masih bisa di remote, saya usul supaya semua log system (messages, syslog, dmesg, kernel, secure) ditarik ke local. lebih fleksibel untuk mendebug problemnya.“.
  reply saya, “Betul kasusnya mirip dengan ssh yang dilewatkan di load balancer yang g aware terhadap session. tapi ini g pake load balancer. Saya rasa ini karena load di server tinggi sekali. Bisa jadi karena ada yang ngelakuin DOS. dan (berdasarkan pengalaman sbelumnya) yang bikin berat adalah php-fpmnya. Karena load tinggi, maka di sshpun susah (maklum cuman single core). Kliatannya php-fpm memang belum mature enough… Dalam kasus ini saya udah pernah dapat shell kok. Cuman ya itu, responnya lama sekali. Ini kejadian udah beberapa kali. Udah dicek juga log file yang macem2 itu terutama pada baris yang dekat2 dengan waktu hang, tapi hasil nihil. Ga ada faulty hardware disana.
• Komentar, “bottleneck IO sepertinya. Udh coba dishutdown service yg suspected kena DOS/too high? Siapa tau IO nya bisa free sendiri.“. reply saya, “ya itu dia, ngetik command untuk matikan itu service aja lama sekali. Malah sampe timeout. Jadinya ngak pernah bisa dieksekusi itu command. Hehehe alhasil masih ngehang”
• Komentar, “pake one-liner command: ssh root@server “/etc/init.d/http restart” sapa tau bisa…:D” reply saya, “yeah.. Saya tau command itu & pengennya sih gitu. Sayangnya, saya harus melewati pertahanan sudo. Hehehe”

Summary:

• Untuk troubleshooting, diperlukan pemahaman terhadap cara kerja aplikasi kita.
• Fasilitas verbose sangat beguna untuk debug (nyari error program)
• kita juga harus terbuka terhadap kemungkinan lain, yaitu ternyata service SSH tidak bermasalah, permasalahan datang dari system lain (high IO / high CPU usage) dimana dengan arsitektur single core, hal ini benar2 sangat berpengaruh ke SSH.