Basic Linux untuk System Administrator Yang Perlu Kamu Tau

Sebagai basic Linux system administrator, hal terpenting bukan hafal perintah, tapi paham konteks, risiko, dan dampak setiap tindakan di server produksi.

Prolog: kesalahan yang mengubah cara pandang

Saya ingat betul hari itu. Jumat sore, tahun 2013. Langit Jakarta sedang mendung gelap, tapi ruang server di kantor lama saya jauh lebih dingin secara harfiah dan metafora.

Saya adalah junior IT support yang penuh semangat dan, jujur saja, sedikit ceroboh. Ada masalah permission error pada aplikasi web kantor. Deadline mepet, bos sudah menelpon tiga kali dalam sepuluh menit. Dalam kepanikan, saya melakukan “dosa besar” yang mungkin paling sering dilakukan pemula, saya mengetik chmod -R 777 /var/www dan menekan Enter.

“Selesai,” pikir saya. “Aplikasi jalan, error hilang. Saya jenius.”

Tiga hari kemudian, pada Senin pagi, server itu berubah menjadi peternakan botnet spam Rusia. Website kami di-deface, database korup, dan reputasi IP kantor masuk blacklist di mana-mana. Saya menghabiskan 48 jam berikutnya tanpa tidur, membangun ulang server dari nol sambil menahan malu luar biasa.

1.1 pelajaran utama

Saat itu saya belajar satu hal keras: Di Linux, “jalan” (it works) itu tidak cukup. Kamu harus tahu mengapa itu jalan.

Artikel ini bukan sekadar daftar perintah yang bisa kamu temukan di manual man. Ini adalah fondasi teknis yang akan menyelamatkan kamu dari panggilan telepon panik di jam 3 pagi.

Mindset: hindari copy-paste engineering

Masalah terbesar sysadmin pemula saat ini, dan saya katakan ini dengan kasih jujur, adalah ketergantungan pada tutorial instan.

Kamu dapat error, kamu copy error-nya ke Google, kamu buka hasil pencarian pertama dari StackOverflow, lalu kamu paste solusinya ke terminal produksi.

Tunggu dulu. Berhenti.

Saya sering sharing dengan teman-teman yang baru mengenal linux. Beberapa kali saya melihat kawan-kawan pemula saya melakukan ini. Tangan saya gatal ingin menepis keyboard mereka, tapi saya tahan. “Coba baca dulu,” kata saya pelan. “Kamu barusan nyuruh sistem menghapus user root, lho.”

2.1 kebiasaan berbahaya

Linux tidak kenal ampun. Dia adalah sistem operasi yang sangat patuh. Kalau kamu menyuruhnya menghancurkan dirinya sendiri, dia akan melakukannya tanpa ragu.

Menjadi system administrator bukan soal menghafal 1000 perintah. Ini soal memahami anatomi sistem. Mari kita bedah organ-organ vitalnya secara teknis dan terstruktur.

Fondasi identitas, privilege, dan konteks

Sebelum menyentuh produksi, pahami siapa yang menjalankan perintah dan di konteks mana.

3.1 perintah inti

whoami, id, groups: verifikasi identitas user dan grup aktif.
sudo -l: cek hak akses yang diberikan.
umask: default permission file baru. Banyak insiden lahir dari umask yang terlalu permisif.

3.2 aturan praktik

Jalankan perintah sebagai user biasa terlebih dulu.
Naik sudo hanya untuk aksi yang benar-benar perlu.
Pisahkan akun admin, akun service, dan akun aplikasi.

File permission dan ownership

Kembali ke kesalahan fatal saya: chmod 777.

Bagi yang belum tahu, Linux memiliki konsep kepemilikan (ownership) dan perizinan (permission) yang kaku. Setiap file punya pemilik (user) dan grup (group).

Read (4): bisa dibaca atau dilihat.
Write (2): bisa diedit atau dihapus.
Execute (1): bisa dijalankan sebagai program atau masuk folder.

4.1 kenapa 777 berbahaya

Angka 777 berarti: semua orang (user, group, others) punya hak read + write + execute. Ini sama saja dengan kamu meninggalkan rumah dengan pintu terbuka lebar, kunci tergantung di pintu, dan ada papan tulisan “Silakan Masuk dan Ambil TV Saya”.

4.2 praktik least privilege

Jangan pernah gunakan 777, kecuali kamu sedang tes di mesin lokal yang terisolasi.

Gunakan prinsip least privilege. Berikan akses seminim mungkin agar aplikasi tetap jalan.

File konfigurasi biasanya cukup 640 atau 644 (hindari world-read untuk file sensitif).
Script eksekusi 755 (rwxr-xr-x).
Direktori upload publik? Pastikan web server (misal: user www-data) hanya bisa tulis di folder spesifik.

4.3 checklist permission

ls -lah: cek owner dan mode.
chown -R user:group: perbaiki kepemilikan.
chmod u=rw,g=r,o=: gunakan notasi simbolik agar niat jelas.

Tambahan penting: pahami setuid, setgid, dan sticky bit (/tmp memakai sticky bit). Ini sering jadi sumber privilege escalation jika tidak diawasi.

Kadang saya bergumam dalam hati saat sedang audit server klien: “Siapa yang kasih root ownership ke folder publik ini? Apakah mereka ingin diserang ransomware?”

Proses dan load average

Pernahkah server kamu terasa lambat seperti siput mabuk?

Pemula biasanya langsung restart server. Senior sysadmin akan melakukan investigasi. Restart itu solusi orang yang menyerah; kita adalah dokter bedah, kita cari penyakitnya.

5.1 membaca load average

Ketik top atau favorit saya, htop. Lihat angka load average. Biasanya ada tiga angka: 1 menit, 5 menit, dan 15 menit terakhir.

Analogi supermarket:

Bayangkan CPU kamu adalah kasir supermarket.

Load 0.0: kasir nganggur.
Load 1.0: ada satu orang antre pas di depan kasir.
Load 5.0 (pada single core CPU): ada 5 orang antre. 1 dilayani, 4 menunggu sambil ngomel.

Jika server kamu punya 4 core CPU, load 4.0 itu masih aman. Tapi kalau load sudah 20.0? Itu bencana.

Konteks teknis:

Load average adalah jumlah runnable tasks + uninterruptible sleep (biasanya I/O wait).
Load tinggi bisa berarti CPU penuh atau storage lambat.

5.2 alat diagnosis

Gunakan kombinasi:

top atau htop: lihat proses pemakan CPU atau RAM.
vmstat 1: cek wa (I/O wait), r (run queue).
iostat -xz 1: lihat latency disk, util%, dan throughput.

5.3 kill dengan etika

Gunakan ps aux | grep [nama_proses] untuk mencari biang keroknya. Lalu, hati-hati dengan perintah kill.

kill -15 [PID] (SIGTERM): minta proses berhenti dengan baik.
kill -9 [PID] (SIGKILL): hentikan paksa. Gunakan hanya sebagai jalan terakhir.

Saya pernah tidak sengaja melakukan kill -9 pada proses database yang sedang transaksi besar. Hasilnya? Data korup.

Memori, cache, dan oom

Sering terjadi panik saat melihat RAM “penuh”. Di Linux, RAM yang dipakai untuk cache itu normal.

6.1 tanda oom

Perintah penting:

free -h: lihat available, bukan hanya used.
cat /proc/meminfo: sumber data mentah.
dmesg -T | grep -i oom: cek apakah OOM killer pernah aktif.

Tanda sistem kehabisan memory:

proses mati tiba-tiba tanpa error jelas.
log berisi Out of memory: Kill process.
swap thrashing dan si/so tinggi di vmstat.

6.2 strategi mitigasi

Solusi bukan selalu tambah RAM. Bisa jadi memory leak di aplikasi. Profiling dan limit resource dengan cgroups lebih aman daripada restart berulang.

Log files dan investigasi

Pilot punya black box, kita punya /var/log.

7.1 lokasi log penting

/var/log/syslog atau /var/log/messages: log umum sistem.
/var/log/nginx/error.log: kalau web server batuk-batuk.
journalctl -xe: untuk sistem berbasis systemd modern.

7.2 membaca real-time

Gunakan perintah tail -f untuk melihat log secara real-time.

Misal: tail -f /var/log/nginx/error.log

Ada kepuasan tersendiri saat melihat baris log bergulir cepat, lalu mata kamu menangkap satu baris merah: “Out of Memory: Kill process mysqld”.

Terkait masalah serupa, baca studi kasus troubleshooting Docker crash yang melibatkan analisis log untuk menemukan OOMKilled.

Disk usage dan inode

“Disk penuh padahal filenya sedikit!“

8.1 size vs inode

Ini klasik. Di Linux, disk penuh bisa karena dua hal:

Size penuh: filenya memang besar.
Inode penuh: jutaan file kecil menghabiskan inode.

Cek dengan df -i.

8.2 teknik pembersihan

Gunakan du -h --max-depth=1 / | sort -hr untuk size, dan find . -type f -delete untuk pembersihan inode.

Saya pernah menangani server email yang macet total. Ternyata ada 4 juta file antrian email spam di satu folder.

Filesystem dan mount

Banyak masalah produksi muncul dari mount yang salah atau storage yang tidak stabil.

9.1 tools dasar

lsblk, blkid: identifikasi disk, UUID, filesystem type.
mount, findmnt: lihat apa yang benar-benar ter-mount.
fstab: konfigurasi mount permanen. Salah satu karakter di sini bisa bikin server gagal boot.

9.2 praktik aman

Selalu mount pakai UUID, bukan /dev/sdX.
Gunakan nofail dan x-systemd.automount untuk disk non-kritis.
Monitor dmesg untuk error I/O: dmesg -T | grep -i error.

Networking untuk sysadmin

Seringkali masalahnya bukan di server, tapi di koneksi. Jangan jadi admin jago kandang yang tidak mengerti jaringan.

10.1 tools wajib

ping: “Halo, kamu hidup?”
curl -v: cek detail header HTTP atau sertifikat SSL.
ss -tulpn: lihat siapa yang mendengarkan di port tertentu.

10.2 DNS dan port

Tambahan teknis yang sering terlewat:

DNS debug: dig +short domain, resolvectl status, cek /etc/resolv.conf.
Koneksi TCP: ss -tan state established, lihat backlog dan retransmit.
Firewall: ufw status atau iptables -L -n -v / nft list ruleset.

Service management dengan Systemd

Di banyak distro modern, systemd adalah pusat kontrol. Jangan hanya systemctl restart, pahami statusnya.

11.1 status dan log

systemctl status service: ringkasan kondisi.
journalctl -u service -b: log service sejak boot.
systemctl show service: detail properti (restart policy, limits, dependencies).

11.2 pola troubleshooting

systemctl status
journalctl -u service -b
cek config dan permission
restart setelah perbaikan, bukan sebelum diagnosa

Paket dan update

Update sembarangan di production bisa berbahaya.

12.1 kontrol versi

apt-cache policy package atau dnf info package: lihat versi dan origin.
apt-mark hold package: tahan update critical.

12.2 strategi update

Snapshot VM sebelum update besar.
Catat perubahan (changelog) untuk service kritikal.
Uji di staging, baru dorong ke produksi.

Penutup: mentalitas di atas hafalan

Menjadi system administrator senior bukan berarti kamu hafal semua switch perintah tar. Yang membedakan pemula dan profesional adalah ketenangan dan metodologi.

Saat server produksi down, dan manajer berdiri di belakang kursi kamu dengan napas memburu, tangan kamu tidak boleh gemetar. Kamu harus punya prosedur di kepala:

Cek koneksi.
Cek beban server (CPU/RAM).
Baca log.
Isolasi masalah.
Eksekusi solusi.

Jangan menebak. Jangan menembak dalam gelap.

Belajar Linux itu seperti belajar naik sepeda di jalan berkerikil. Kamu pasti akan jatuh. Tapi itulah satu-satunya cara belajar.

Jadi, buka terminal kamu. Ketik whoami. Dan mulailah bertanggung jawab atas baris perintah yang kamu ketik.

Selamat berjuang di shell.

Saran internal link:

Best Practice Server Hardening Linux
Studi kasus troubleshooting Docker crash
LVM error: studi kasus PVS/LVS