Dipijit lagi

Baru aja 7 bulan lewat dikit, kambing mengalami musibah lagi 🙁

Singkatnya, data ilang semua =D detilnya saya kurang tahu mengapa.

/dev/md0              5.5T  640G  4.9T  12% /mirror/data

Terakhir total data yang ada itu sekitar 3TB, jadi.. masih jauh perjalanannya..

Sekali lagi terima kasih kepada mirror-mirror tetangga shol, unej, ugm, ipb, kebo, komo, itb, foss-id dll. Mohon maaf kalau bakal disedot kambing besar-besaran..

Untuk info lebih lengkap mengenai kejadian yang terjadi beberapa hari yang lalu, silakan baca http://staff.blog.ui.ac.id/jp/2010/03/01/insider-info/

Restrukturisasi repositori openSUSE di Kambing

tl;dr Repositori openSUSE di Kambing tidak mengikuti struktur standar yang diberikan oleh openSUSE sehingga akan direstrukturisasi ulang agar mengikuti struktur asli.

Kalau melihat rsync.opensuse.org, openSUSE mengelompokkan repositorinya ke dalam beberapa modul rsync yang mungkin bisa dikelompokkan lagi menjadi hotstuff, updates, full, dan buildservice. Menurut dokumentasi tentang mirror repositori openSUSE, kelompok hotstuff berisi berkas-berkas yang paling sering diminta dan kelompok full berisi apa saja yang ada di download.opensuse.org. Kelompok updates dan buildservice masing-masing berisi paket-paket perbaikan dan berkas-berkas dari openSUSE Build Service.

Kali ini saya hanya akan membahas mengenai isi kelompok hotstuff dan full karena keduanya mungkin yang paling sering banyak dipakai. Isi kelpompok updates sudah termasuk di dalam kedua kelompok tersebut sehingga tidak perlu dibahas secara khusus. Untuk kelompok buildservice, sepertinya isinya tidak terlalu relevan untuk pengguna akhir (cmiiw) jadi tidak akan dibahas juga.

Kembali ke isi repositori. Kalau melihat isi kelompok hotstuff 160GB, kelompok ini hanya berisi repositori untuk openSUSE 11.1 (bukan yang terbaru kan nih?), update untuk 10.3 sampai 11.2, dan sebuah direktori repositories yang sepertinya berisi paket-paket terbaru yang dikelompokkan berdasar kategori tertentu. Berbeda dengan kelompok hotstuff, kelompok full tidak memiliki direktori repositories namun kelompok ini berisi memiliki repositori untuk openSUSE versi 11.0, 11.1, dan 11.3-Milestone1 yang masih dalam masa pengembangan.

Bagi yang ingin melihatnya sendiri, coba jalankan perintah berikut.

$ rsync -av rsync.opensuse.org::opensuse-hotstuff-160gb/ > opensuse-hotstuff-160gb.txt
$ rsync -av rsync.opensuse.org::opensuse-full/ > opensuse-full.txt

Tenang saja, perintah di atas tidak akan menyalin seluruh berkas yang ada melainkan hanya akan mengambil daftar berkas yang ada di dalamnya lalu dimasukkan ke dalam berkas opensuse-hotstuff-160gb.txt dan opensuse-full.txt. Buka kedua berkas tersebut untuk melihat apa yang ada di dalam repositori.

Sekarang coba lihat repositori openSUSE di Kambing.

$ rsync -av kambing.ui.ac.id::kambing/ > kambing.txt

Repositori di Kambing memiliki direktori repositories dan juga repositori untuk openSUSE versi 11.0 sampai 11.3-Milestone1! Kok bisa? padahal kan keduanya seharusnya berada dalam kelompok berbeda (menurut rsync.opensuse.org). Jawabannya adalah karena Kambing menggabungkan kedua kelompok tersebut. Isi opensuse-full yang ditambahkan dengan direktori repositories dari opensuse-hotstuff-160gb. Dengan melakukan hal ini sebenarnya Kambing telah membuat sesuatu yang tidak standar (mencampurkan dua repositori) dan sepertinya tidak baik untuk diteruskan.

Dalam beberapa hari ke depan, Kambing akan tobat melakukan penyimpangan ini dan akan melakukan restrukturisasi ulang repositori openSUSE. Penggabungan dua repositori ini akan dihapuskan dan akan kembali dipecah menjadi dua buah repositori terpisah, sesuai aslinya. Berikut ini struktur baru yang akan dibuat.

Berkas ISO tentu saja juga tidak akan dimasukkan karena memang sengaja dipisahkan di ftp://kambing.ui.ac.id/iso/opensuse/. Isi direktori khusus ISO ini diambil dari opensuse-full dengan mengatur agar hanya berkas ISO yang diambill. Tenang saja, struktur direktori tetap sama seperti aslinya.

kambing.ui.ac.id

Kabarnya, kambing.ui.ac.id akan menjadi nama tunggal si Kambing. Jadi jangan sampe salah sebut nama!

Segera ganti nama lama kambing, misalnya kambing.ui.edu dan kambing.vlsm.org dan bahkan anak.kambing.vlsm.org atau malah ada yg masih pake nama tetangga tuma.ui.edu menjadi kambing.ui.ac.id.

Yang perlu dicek antara lain: bookmark, konfigurasi repositori, konfigurasi upstream kalo Anda punya mirror yg nyedot ke kambing, dan sebagainya.

Oya, “nama tunggal” dapat diartikan sebagai “nama lain tidak dilayani”. Why? don’t ask me.

Kambing lagi dipijit

Baru aja ngomongin backup beberapa waktu yang lalu. Sekarang saya dan kawan2 pengurus Kambing sedang merasakan kebenaran pernyataan tersebut =))

Real men don’t use backups, they post their stuff on a public ftp server and let the rest of the world make copies.

– Linus Torvalds

Ada apa? harddisk Kambing crash lagi. Apa yang terjadi kalau ada 2 harddisk crash pada konfigurasi RAID5? ~ö

Terima kasih bagi mirror2 tetangga yg menyediakan layanan rsync =D shol, unej, ugm, kebo, komo.. Mohon maklum kalo jadi sibuk dalam bbrp hari ke depan..

Membuat sendiri sumber data untuk MRTG

Biasanya data yang digunakan oleh MRTG berasal dari SNMP server. Namun ternyata kita juga bisa menyiapkan sendiri data yang kemudian akan digunakan oleh MRTG.

Grafik MRTG di atas adalah jumlah rata-rata koneksi HTTP yang terbangun ke Kambing. MRTG mengambil data ini setiap lima menit dari skrip yang saya siapkan sendiri. Bagaimana cara menghubungkannya?

Pertama2, siapkan skrip yang akan menghasilkan dua buah data. Dua data ini akan menjadi data input dan output bagi MRTG. Keluaran harus ditulis dalam format berikut.

input
output

komentar

Baris pertama dan kedua masing-masing berisi sebuah angka yang menggambarkan besar masukan dan keluaran data yang ingin dipantau. Baris ketiga adalah sebuah baris kosong dan baris terakhir berisi komentar.

Tuk mendapatkan jumlah koneksi HTTP dimana Kambing menggunakan nginx sebagai HTTP servernya, saya hanya menggunakan informasi yang diberikan oleh aplikasi netstat. Saya ambil seluruh baris yang menyatakan koneksi terhubung ke port 80 dan hitung jumlah baris tersebut. Kira2 skripnya adalah sebagai berikut.

#!/bin/sh

NUM=`netstat -ant | grep :80 | grep ESTABLISHED | wc -l`

echo $NUM
echo $NUM
echo
echo Established HTTP Connections

Sebenarnya saya hanya butuh sebuah angka yang menggambarkan jumlah koneksi. Berhubung MRTG meminta dua angka, ya sudah saya tuliskan angka yang sama saja.

Lalu untuk konfigurasi MRTGnya sendiri, tuliskan path skrip tadi dalam isian Target. Path ditulis di dalam sepasang backtick. Contoh:

Target[kambing.http]: `/path/ke/mrtg-num-http.sh`

Simpan konfigurasi MRTG dan tunggu beberapa waktu sampai MRTG mendapatkan data yang cukup untuk mulai membuat grafik. Oh iya, jangan lupa mengatur agar skrip tadi bisa dieksekusi.

Catatan tambahan: Saya tidak membedakan jumlah koneksi masuk dan keluar dalam skrip di atas. Agar data yang ditampilkan lebih menggambarkan kondisi asli, tentu saja perlu dibuat skrip yang lebih canggih, yang bisa mengeluarkan dua angka berbeda, yaitu jumlah koneksi masuk dan keluar. Ada yang mau membuat? =D

Referensi: http://lena.franken.de/mrtg/

Kambing Kesetrum

Peristiwa yg terjadi hari minggu kemarin dan seminggu terakhir:

  • mdadm melakukan consistency check
  • skrip mematikan services lain selama mdadm kerja tidak berjalan =D
  • ubuntu jaunty rilis

kerjaan si mdadm itu akan membuat I/O load tinggi. andai mdadm ngerjain ini dan data terus disedot, maka biasanya services lain akan mogok karena semua operasi nyangkut di I/O. namun pada 1 hari belakangan ini, transmisi data tetap terlihat banyak walau terjadi penurunan sekitar 50%. tapi ini kan hari minggu dmana biasanya memang turun.

Terakhir dicek, kerjaan mdadm akan selesai sekitar 1 jam lagi. artinya mdadm akan kerja selama sekitar 25 jam. kalau services lain mati, maka mdadm cukup butuh waktu sekitar 14 jam.

kesimpulan sementara: services gak perlu dimatiin selama pemeliharaan rutin bulanan =D ö/

namun kok itu cpu load tingginya teratur tiap jam ya? wah ada sesuatu yg lain kayanya..

Download managernya apa ya?

Saat ini log nginx kambing dipenuhi oleh baris2 seperti berikut.

a.b.c.d - - [25/Mar/2009:19:11:12 +0700]
"GET /iso/fedora/9/Fedora/i386/iso/Fedora-9-i386-DVD.iso HTTP/1.0" 206 11584
"http://kambing.ui.edu/iso/fedora/9/Fedora/i386/iso/"
"Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.7) Gecko/2009021910 Firefox/3.0.7"

Yang jadi perhatian saya adalah kode respon HTTP dan besar data yang dikirim. Kode respon yang terlihat di atas adalah 206 yang berarti partial content. Kode ini akan digunakan ketika si klien meminta sebuah berkas secara parsial dan/atau tidak dari awal.

Ukuran berkas yang dikirim oleh server pada sesi HTTP tersebut hanyalah sebesar 11584 Byte. Sangat kecil sekali jika dibandingkan dengan berkas yang ingin diunduhnya, sebuah ISO DVD yang berukuran sekitar 4 GB.

Saya rasa sang pengunduh menggunakan sebuah aplikasi download manager (entah deh user agent yang tertera di situ benar atau tidak berasal dari Firefox) dan mengaturnya supaya dapat mengunduh berkas tersebut secara paralel beberapa bagian sekaligus. Menurut saya, aplikasi yang digunakan tersebut bisa dibilang bodoh karena tidak dapat menggunakan koneksi yang dibuat secara efektif dan efisien. Terlalu banyak koneksi yang dibuat dan diputus namun setiap koneksi yang terbangun tidak dimanfaatkan dengan baik.

Dann.. demi kemaslahatan bersama.. saya tutup dulu koneksi HTTP dari IP “bermasalah” tersebut =D

Log nginx: “-” 400 0 “-” “-“

Di kambing ada sejumlah (err.. sekitar 1.8% di log minggu kemarin) entry seperti berikut di log nginx-nya.

a.b.c.d - - [04/Mar/2009:00:14:01 +0700] "-" 400 0 "-" "-"

Kira2 entry tsb bisa dibaca sebagai request tidak benar (400) dan si server tidak mengirim respon apa2 (0 byte). Tidak ada informasi lain tertulis di sana.

Setelah diselidiki, salah satu penyebabnya adalah adanya koneksi HTTP yang masuk yang langsung diputuskan sehingga si server tidak dapat memberikan respon apa2.

Salah satu “pelakunya” adalah (sepertinya) sebuah bot search engine. Kira2 mengapa ya si bot2 itu berperilaku seperti itu? atau ada masalah dg nginx? humm..

Siapa itu?

Bikin gosip iseng ah..

Barusan aja iseng ngeliat iftop di kambing. Ternyata inilah penyedot tercepat saat itu.

Mari kita cek sedang ngapain dia =D

$ sudo netstat -antp|grep 131.107.65.116
tcp        0 397120 152.118.24.30:6389      131.107.65.116:47386    ESTABLISHED 22161/vsftpd
tcp        0 414640 152.118.24.30:14936     131.107.65.116:41763    ESTABLISHED 18936/vsftpd
tcp        0      0 152.118.24.30:21        131.107.65.116:47331    ESTABLISHED 22159/vsftpd
...

Oh lagi nyedot pake ftp.. berkas apakah itu?

$ grep 131.107.65.116 vsftpd.log | head
Wed Feb 18 02:09:52 2009 1 131.107.65.116 3532 /pub/ubuntu-repository/intrepid/README b _ o a IEUser@ ftp 0 * c
Wed Feb 18 02:10:03 2009 1 131.107.65.116 2105 /pub/ubuntu-repository/intrepid/REVISI.txt b _ o a IEUser@ ftp 0 * c
Wed Feb 18 02:10:12 2009 1 131.107.65.116 3532 /pub/ubuntu-repository/intrepid/README b _ o a IEUser@ ftp 0 * c
Wed Feb 18 02:15:42 2009 5 131.107.65.116 301184 /pub/ubuntu-repository/dapper/ubuntu-6.06-repository-i386-1_contrib-r1.iso b _ o a IEUser@ ftp 0 * i
Wed Feb 18 02:58:58 2009 2581 131.107.65.116 981221512 /iso/ubuntu-repository/dapper/ubuntu-6.06-repository-i386-1_contrib-r1.iso b _ o a IEUser@ ftp 0 * i

Oh lagi nyedot dvd repo Ubuntu toh.. hihihi

Arsip milis terkait: http://www.linuxsa.org.au/mailing-list/2003-06/1113.html