Claude untuk Sysadmin: 6 Tugas Server Linux

Claude untuk sysadmin: utamakan saran, lalu eksekusi

Claude untuk sysadmin paling efektif sebagai peninjau. Tempelkan cuplikan log, file konfigurasi, perintah yang tidak Anda kenali, atau string error, lalu Anda akan mendapatkan penjelasan yang dapat diperiksa sebelum mengubah apa pun pada server. Jawaban yang salah tidak menimbulkan dampak sampai Anda menjalankannya. Karena itu, menjaga model tetap pada sisi pemberian saran merupakan dasar keselamatan pendekatan ini.

Setiap minggu, ada enam tugas yang umum dilakukan pada Linux VPS (virtual private server) sewaan. Setiap tugas di bawah ini memiliki pola prompt yang efektif, perintah untuk membuktikan jawabannya, serta mode kegagalan yang perlu Anda antisipasi. Tidak satu pun tugas tersebut memerlukan model untuk mengakses server Anda.

Urutannya penting pada server produksi: baca penjelasannya, jalankan pemeriksaan sendiri, lalu ambil keputusan. Otonomi dapat digunakan pada VM uji. Namun, pada server yang melayani pelanggan, peninjauan lebih aman karena model tidak dapat melihat kondisi yang sedang ditebaknya.

Hal yang tidak boleh Anda tempelkan

Semua isi prompt keluar dari server Anda. Empat kategori berikut harus tetap berada di server:

• Kunci privat: ~/.ssh/id_ed25519, /etc/ssh/ssh_host_*_key, dan semua kunci TLS (transport layer security) di bawah /etc/letsencrypt/live/.
• File kredensial: .env, ~/.aws/credentials, /root/.docker/config.json, serta kata sandi database dalam file atau baris log apa pun.
• Data akun: /etc/shadow dan /etc/gshadow. Tidak ada pertanyaan sysadmin yang memerlukan hash kata sandi untuk dijawab.
• Apa pun yang menjadi milik pengguna Anda: alamat email, baris pesanan, log permintaan yang memuat cookie sesi atau PII (personally identifiable information).

Kunci publik aman untuk ditempelkan. Kunci privat tidak aman, dan kedua file tersebut sekilas tampak serupa. Karena itu, baca baris pertama sebelum menyalin: file yang baris pertamanya memuat BEGIN OPENSSH PRIVATE KEY tidak boleh dimasukkan ke prompt. Menjaga file kunci SSH tetap teridentifikasi layak Anda perhatikan selama sepuluh menit.

Lakukan redaksi sebelum menempelkan, bukan mengandalkan kemampuan Anda untuk menemukan satu token di antara 200 baris:

sudo journalctl -u myapp -n 200 --no-pager | sed -E 's/(token|secret|password|api[_-]?key)[=:][^[:space:]]+/\1=REDACTED/gI'

Ada satu jebakan khusus Docker. docker compose config menginterpolasikan nilai .env Anda ke dalam output yang dicetaknya, sehingga output tersebut menjadi rahasia meskipun file di disk tidak bersifat rahasia. Gunakan docker compose config -q, yang melakukan validasi dan tidak mencetak apa pun. Untuk kebijakan yang lebih luas tentang hal yang boleh dilihat agen, menjauhkan rahasia dari agen AI membahas sisi lingkungan.

Job 1: mengapa service ini gagal?

Mulailah dengan dua perintah yang memuat jawabannya:

systemctl status myapp.service --no-pager
sudo journalctl -u myapp.service -b -n 100 --no-pager -o short-iso

Tempelkan keduanya, beserta konteks yang tidak dapat ditebak oleh model: distribusi dan versinya, perubahan terakhir yang Anda lakukan, apakah service tersebut pernah berfungsi, dan sejak kapan masalah terjadi. Minta mekanismenya terlebih dahulu.

Ubuntu 24.04. myapp.service berfungsi normal sampai saya mengedit unit tersebut satu jam lalu. Berikut systemctl status dan 100 baris terakhir dari journal. Baris mana yang merupakan error nyata pertama, dan apa artinya? Jangan berikan perbaikan dulu.

"Jangan berikan perbaikan dulu" berperan penting dalam prompt tersebut. Log biasanya menutupi kegagalan pertama dengan percobaan ulang yang dipicunya, sehingga model yang diminta memberikan perbaikan akan menjelaskan baris terakhir yang dilihatnya. Baris yang penting biasanya berada sekitar 20 baris sebelum pesan-pesan yang tidak relevan.

Hasilnya dapat berupa baris seperti Main PID: 1841 (code=exited, status=203/EXEC). Status keluar 203/EXEC berarti kernel tidak dapat menjalankan file yang disebutkan dalam ExecStart: path tersebut tidak ada, atau file tersebut ada tetapi tidak dapat dieksekusi. Baris #! yang menyebutkan interpreter yang belum terinstal menghasilkan status yang sama. Semua kemungkinan tersebut dapat diuji dengan ls -l dan head -1.

Mode kegagalan: penyebab yang dibuat-buat. Jika Anda menempelkan terlalu sedikit informasi, model akan mengisi kekosongan dengan penyebab umum, seperti "port sudah digunakan". Solusinya adalah mengajukan satu pertanyaan lanjutan: "Baris mana dalam informasi yang saya berikan yang mendukung pernyataan itu?" Penyebab yang tidak dapat ditunjukkan pada teks hanyalah dugaan.

Tugas 2: menyusun unit systemd atau entri cron

Berikan fakta yang diperlukan file unit: perintah yang tepat, pengguna yang menjalankannya, direktori kerja, apakah unit harus menunggu jaringan, dan tindakan yang harus dilakukan saat proses berakhir dengan kode selain 0. Kemudian verifikasi hasilnya sebelum mengaktifkan apa pun.

sudo systemd-analyze verify /etc/systemd/system/myapp.service
sudo systemctl daemon-reload
sudo systemctl start myapp.service
systemctl status myapp.service --no-pager

systemd-analyze verify mem-parsing file dengan cara yang sama seperti systemd, sehingga kesalahan yang terlewat oleh pemeriksaan manual dapat ditemukan. Direktif yang salah eja menampilkan /etc/systemd/system/myapp.service:7: Unknown key name 'Enviroment' in section 'Service', ignoring.. Biner yang tidak ada menampilkan Command /usr/local/bin/myapp is not executable: No such file or directory. Keduanya tidak menghasilkan pesan selama daemon-reload. Karena itu, unit dapat dimuat tanpa error tetapi tetap gagal saat dijalankan.

Dua kesalahan saat menyusun unit sering terjadi. Kesalahan pertama adalah After=network.target. Status ini hanya berarti stack jaringan sudah dikonfigurasi, bukan alamat IP sudah tersedia. Service yang melakukan bind ke IP tertentu kemudian gagal saat boot dengan bind: Cannot assign requested address. Perbaikannya adalah Wants=network-online.target bersama After=network-online.target. Kesalahan kedua adalah Type=simple untuk program yang menjalankan daemonisasi. systemd menganggap proses pertama sebagai service. Proses induk segera berakhir, lalu unit ditandai sebagai berhenti sementara proses sebenarnya tetap berjalan tanpa dikelola.

Untuk jadwal, periksa jadwal tersebut, bukan hanya membacanya:

systemd-analyze calendar 'Mon *-*-* 04:00:00'

Perintah itu mencetak bentuk yang dinormalisasi dan waktu berikutnya saat ekspresi akan dijalankan. Dengan demikian, maknanya dapat dipastikan. Jika Anda memilih antara timer dan crontab, service dan timer systemd pada VPS membahas perbedaannya.

Cron memiliki jebakan yang tidak akan diperingatkan oleh model kecuali Anda menanyakannya. Cron menjalankan job dengan environment minimal. Karena itu, PATH kira-kira bernilai /usr/bin:/bin, dan profil shell Anda tidak pernah dibaca. Job yang berhasil saat ditempelkan ke terminal dapat gagal saat dijalankan oleh cron dengan /bin/sh: 1: docker: not found, karena biner tersebut berada di /usr/local/bin. Gunakan path absolut dalam crontab.

Tugas 3: tinjau file nginx atau Compose sebelum digunakan

Tugas ini memberikan hasil terbaik. Tempelkan file tersebut, jelaskan fungsinya, lalu minta penjelasan baris demi baris tentang perilaku sebenarnya.

Vhost ini harus menyajikan example.com melalui HTTPS dan meneruskan /api ke service lokal pada port 8080. Bacakan kembali konfigurasinya, lalu sebutkan apa pun yang tidak sesuai dengan deskripsi tersebut.

Selanjutnya, jalankan alat yang memahami sintaksnya:

sudo nginx -t
docker compose config -q

nginx -t mencetak nginx: configuration file /etc/nginx/nginx.conf test is successful, atau menyebutkan nama file dan barisnya, seperti pada nginx: [emerg] unknown directive "proxy_pas" in /etc/nginx/conf.d/app.conf:12. docker compose config -q tidak mencetak apa pun jika file berhasil diproses, dan mencetak pesan singkat seperti yaml: line 7: did not find expected key jika indentasi Anda keliru.

Kedua alat tersebut tidak memeriksa maksud konfigurasi. Konfigurasi yang lolos nginx -t tetap dapat meneruskan trafik ke port yang salah, atau mendengarkan pada 0.0.0.0 saat yang Anda maksud adalah 127.0.0.1. Celah inilah yang membuat model berguna, tetapi juga menjadi sumber kegagalannya: ketika diminta memperbaiki satu direktif, model sering mengembalikan seluruh file yang telah ditulis ulang dan diam-diam menghilangkan dua direktif Anda. Minta hanya baris yang diubah beserta alasan untuk setiap perubahan, lalu lakukan pengeditan secara manual.

Pastikan hal yang benar-benar Anda ekspos:

sudo ss -tulpn

Tanpa sudo, Anda hanya dapat melihat socket yang sedang listening, bukan proses yang memilikinya. Jika output tersebut mengejutkan Anda, bacaan singkat tentang port dan cara Linux melakukan binding dapat membantu.

Tugas 4: jelaskan perintah yang belum dikenal sebelum menjalankannya

Tempel perintah tersebut dan ajukan empat pertanyaan: apa fungsi setiap flag, apa yang ditulis, apa yang dihapus, dan apa yang terjadi jika perintah dijalankan dua kali. Pertanyaan terakhir mendeteksi lebih banyak potensi kerusakan daripada pertanyaan lainnya.

Ambil find /var/log -name '*.gz' -mtime +7 -delete sebagai contoh. Jawaban yang baik menjelaskan bahwa -mtime +7 menghitung periode 24 jam penuh dan membuang pecahannya. Dengan demikian, perintah tersebut mencocokkan file yang berusia setidaknya delapan hari, bukan tujuh hari. Jawaban itu juga menjelaskan bahwa find mengevaluasi ekspresinya dari kiri ke kanan. Jadi, jika -delete dipindahkan ke depan -name, perintah tersebut akan menghapus semua yang berada di bawah path awal. Poin kedua ini tercantum sebagai peringatan dalam halaman man find, dan telah menyebabkan orang kehilangan /var/log.

Atau, ambil rsync -a --delete /srv/app/ /backup/app/ sebagai contoh. Tanda garis miring di akhir source berarti “isi direktori ini”. Jika tanda tersebut dihilangkan, hasilnya adalah /backup/app/app/. Jika --delete ditambahkan, apa pun di destination yang tidak ada di source akan dihapus. Perilaku ini benar untuk mirror dan menjadi bencana jika path source salah.

Verifikasi dengan tool, bukan dengan model:

rsync -a --delete --dry-run /srv/app/ /backup/app/ | head -20
find /var/log -name '*.gz' -mtime +7

Jalankan find tanpa -delete untuk mendapatkan daftar, bukan kehilangan data.

Mode kegagalan: halusinasi flag. Model cukup andal untuk tool yang dokumentasinya telah tersedia selama tiga puluh tahun, tetapi jauh lebih lemah untuk CLI vendor (antarmuka command line) dan subcommand terbaru. Pada kasus tersebut, model dapat menghasilkan flag yang terlihat benar, tetapi sebenarnya tidak ada. --help memastikannya dalam satu detik. Quoting adalah titik lemah lainnya. Jadi, ketika sebuah perintah membungkus ekspresi $(...), baca cara command substitution diperluas sebelum perintah dijalankan, alih-alih mempercayai penjelasannya.

Job 5: ubah shell history Anda menjadi runbook

Anda baru saja menghabiskan dua jam untuk membuat sesuatu berfungsi. Pengetahuan itu hanya tersimpan di scrollback dan akan hilang bulan depan.

history 200 > /tmp/session.txt

Baca file tersebut dan hapus setiap baris yang memuat password, token, atau pengenal pelanggan sebelum file itu digunakan di tempat lain. Shell history adalah salah satu tempat paling andal untuk menemukan secret di sistem Linux, karena setiap orang setidaknya pernah mengetikkannya langsung di command line. Atur HISTCONTROL=ignorespace di dalam ~/.bashrc Anda. Dengan begitu, command yang diketik dengan spasi di awal tidak pernah ditulis ke history.

Prompt yang menghasilkan runbook yang dapat digunakan harus meminta pemeriksaan, bukan hanya langkah:

Ini adalah sesi shell yang mengubah mesin Debian 13 yang baru dipasang menjadi instalasi Postgres yang berfungsi. Tuliskan sebagai runbook bernomor. Gunakan satu command per langkah. Setelah setiap langkah, berikan command yang membuktikan bahwa langkah tersebut berhasil dan jelaskan seperti apa output yang sehat. Tandai setiap langkah yang bergantung pada host tertentu milik saya.

Mode kegagalan: cerita yang rapi. Dalam sesi Anda ada langkah yang dua kali Anda lakukan dengan salah sebelum memperbaikinya. Itulah langkah yang dihaluskan oleh model, karena transkrip terlihat lebih rapi jika langkah tersebut dihilangkan. Bandingkan runbook dengan history Anda dan masukkan kembali koreksinya. Model juga dapat mengarang command verifikasi yang tampak masuk akal. Karena itu, jalankan setiap pemeriksaan yang ditulisnya sebelum menyimpan file. Jika runbook tersebut mencakup boot pertama, baca kembali dengan membandingkannya dengan sepuluh menit pertama pada VPS baru agar Anda tidak menuliskan versi yang lebih buruk dari masalah yang sudah diselesaikan.

Tugas 6: ubah pesan error menjadi solusi

Tempelkan string persisnya, perintah yang menghasilkannya, dan satu hal yang Anda ubah sebelum pesan tersebut muncul. Minta penyebab yang diurutkan berdasarkan kemungkinan, disertai satu perintah pembeda untuk masing-masing penyebab. Dengan demikian, jawaban dapat diuji.

nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use). Urutkan penyebab yang paling mungkin dan berikan satu perintah untuk setiap penyebab yang mengonfirmasi atau menyingkirkannya.

Untuk error tersebut, mekanismenya jelas: proses lain sudah menggunakan port 80, dan sudo ss -tulpn | grep ':80 ' mengidentifikasi proses tersebut. Sering kali penyebabnya adalah master nginx kedua yang tertinggal setelah reload gagal, atau Apache yang ditarik sebagai dependency lalu dijalankan oleh package-nya sendiri.

Mode kegagalan: solusi yang berhasil dengan menyembunyikan penyebabnya. chmod 777, --privileged, menonaktifkan SELinux, dan menjalankan service sebagai root semuanya dapat menghilangkan error tersebut. Tolak solusi apa pun yang memperluas permission sebelum model menjelaskan alasan permission yang lebih terbatas gagal. Penjelasan itu adalah jawaban sebenarnya. Workaround hanya membuat error tidak lagi terlihat.

Kesalahan yang konsisten

• Model tidak dapat melihat server Anda. Setiap jawaban bergantung pada hal yang Anda tempelkan, dan model tidak akan memberi tahu jika cuplikan tersebut terlalu pendek.
• Model sering keliru terkait versi. Nama paket dan flag default dapat berubah antar-distribusi dan rilis, sedangkan model merata-ratakan semuanya.
• Model tetap lancar saat jawabannya salah. Mekanisme yang diada-adakan terbaca persis seperti mekanisme yang benar. Karena itu, setiap penyebab di atas disertai perintah untuk mengujinya.
• Model kehilangan konteks dalam sesi yang panjang. Fakta dari awal percakapan selama dua jam tidak lagi memengaruhi jawaban di bagian akhir.

Masalah terakhir lebih berkaitan dengan cara kerja daripada modelnya, dan mengelola konteks dalam sesi Claude Code yang panjang merupakan solusi praktisnya: gunakan sesi yang lebih singkat dan satu tugas dalam setiap sesi.

Menempatkan agent di server itu sendiri

Semua langkah di atas hanya perlu disalin dan ditempel, sehingga model tidak pernah menyentuh mesin Anda. Setelah berjalan di server, membaca file, dan mengeksekusi perintah, bentuk risikonya berubah: perintah yang salah dapat menghentikan sebuah service. Berikan agent akun pengguna sendiri tanpa hak istimewa, bukan root. Jangan jalankan agent di server produksi selama Anda masih mempelajari perilakunya. Buat snapshot terlebih dahulu. Menjalankan Claude Code dengan aman pada VPS membahas sandbox dan model izin. Menjalankan Claude Code di dalam tmux mengatasi bagian lainnya, karena sesi SSH (secure shell) yang terputus akan menghentikan agent foreground di tengah pekerjaannya. Buat akun tersebut seperti saat membuat akun service. Panduan pengguna dengan hak istimewa minimum pada VPS menjelaskan caranya.

FAQ

Apakah Claude dapat membaca log server saya secara langsung?

Tidak dengan sendirinya. Antarmuka chat hanya dapat melihat teks yang Anda tempelkan. Claude Code, yang dijalankan di server sebagai alat baris perintah, dapat membaca file dan menjalankan perintah dengan izin pengguna yang menjalankannya. Ini merupakan keputusan kepercayaan yang lebih besar. Untuk pertanyaan dukungan biasa, menempelkan cuplikan 100 baris yang telah disamarkan lebih cepat dan aman daripada memberikan akses shell kepada agen.

Apa yang tidak boleh saya tempelkan dari server?

Kunci privat, file .env dan penyimpanan kredensial lainnya, /etc/shadow, serta data apa pun milik pengguna Anda. Samarkan token dari cuplikan log sebelum memasukkannya ke prompt. Satu kasus yang tidak selalu disadari: output docker compose config berisi nilai .env Anda yang telah diinterpolasi. Karena itu, gunakan docker compose config -q, yang memvalidasi file dan tidak mencetak apa pun.

Apakah aman membiarkan Claude menjalankan perintah pada VPS produksi?

Perlakukan Claude seperti administrator baru yang belum memahami konteks: aman untuk membaca, tetapi perubahan perlu ditinjau. Pada sistem produksi, minta penjelasannya lalu jalankan perintah tersebut sendiri. Jika Anda memang ingin agen menjalankan perintah, berikan akun khusus tanpa hak istimewa dan tanpa akses sudo menyeluruh. Mulailah pada server staging, sehingga kesalahan mengharuskan Anda melakukan rebuild, bukan menyebabkan gangguan layanan.

Mengapa Claude menyarankan flag yang tidak ada?

Karena Claude memprediksi teks yang masuk akal, sedangkan flag yang masuk akal terlihat sama seperti flag yang benar-benar ada. Hal ini paling sering terjadi pada CLI vendor dan subperintah yang lebih baru, saat dokumentasi yang tersedia bagi model terbatas atau telah berubah. --help dan man menjadi acuan utama. Setiap perintah yang menghapus atau menimpa data harus dicoba dalam mode dry run terlebih dahulu.

Bagaimana cara memeriksa unit systemd sebelum mengaktifkannya?

Jalankan sudo systemd-analyze verify /etc/systemd/system/myapp.service. Perintah ini mengurai file menggunakan parser milik systemd, melaporkan direktif yang tidak dikenal beserta nomor barisnya, serta menandai biner ExecStart yang hilang atau tidak dapat dieksekusi. Kemudian jalankan daemon-reload, start, dan baca systemctl status sebelum Anda enable unit tersebut, karena unit yang berhasil dimuat tetap dapat gagal saat pertama kali dijalankan.