Claude untuk Sysadmin: 6 Tugas Server Linux

Claude untuk sysadmin: dahulukan saran, kemudian eksekusi

Claude untuk sysadmin paling efektif sebagai reviewer. Anda dapat menempelkan cuplikan log, file konfigurasi, perintah yang tidak Anda kenali, atau string error, lalu menerima penjelasan yang dapat diperiksa sebelum mengubah apa pun di server. Jawaban yang salah tidak menimbulkan dampak sampai Anda menjalankannya. Karena itu, menjaga model tetap berada pada sisi pemberian saran merupakan inti model keamanan 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 memverifikasi jawabannya, dan mode kegagalan yang perlu Anda antisipasi. Tidak satu pun tugas tersebut memerlukan akses model ke server Anda. Anda dapat menempelkan data dari tab browser atau jendela pada desktop Anda sendiri, karena Claude berjalan secara native di Linux sebagai aplikasi desktop dan CLI.

Urutan ini penting pada server produksi: baca penjelasannya, jalankan pemeriksaannya sendiri, lalu tentukan tindakan. Otonomi dapat diterapkan pada VM pengujian. Pada server yang melayani pelanggan, review lebih aman karena model tidak dapat melihat kondisi aktual yang sedang ditebaknya.

Hal yang tidak boleh Anda tempelkan

Semua yang ada dalam prompt akan keluar dari server Anda. Empat kategori berikut harus tetap berada di server:

• Kunci privat: ~/.ssh/id_ed25519, /etc/ssh/ssh_host_*_key, dan kunci TLS (transport layer security) apa pun di bawah /etc/letsencrypt/live/.
• File kredensial: .env, ~/.aws/credentials, /root/.docker/config.json, dan 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 menjawabnya.
• Apa pun yang dimiliki pengguna Anda: alamat email, baris pesanan, log request yang memuat cookie sesi atau PII (personally identifiable information).

Kunci publik aman untuk ditempelkan. Kunci privat tidak aman, dan kedua file tersebut sekilas terlihat serupa. Karena itu, baca baris pertama sebelum menyalin: file yang baris pertamanya memuat BEGIN OPENSSH PRIVATE KEY tidak boleh dimasukkan ke dalam prompt. Menjaga materi kunci SSH tetap jelas layak Anda pelajari 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 memvalidasi tanpa mencetak apa pun. Untuk kebijakan yang lebih luas mengenai hal-hal yang boleh dilihat oleh agen, menjaga rahasia agar tidak terlihat oleh agen AI membahas sisi lingkungan.

Tugas 1: mengapa service ini gagal?

Mulai 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 adalah 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" memiliki fungsi penting dalam prompt tersebut. Log biasanya menyembunyikan kegagalan pertama di bawah percobaan ulang yang ditimbulkannya. Jika model diminta memberikan perbaikan, model akan menjelaskan baris terakhir yang dilihatnya. Baris yang penting biasanya berada sekitar dua puluh baris sebelum deretan pesan tersebut.

Hasilnya dapat berupa baris seperti Main PID: 1841 (code=exited, status=203/EXEC). Exit status 203/EXEC berarti kernel tidak dapat menjalankan file yang disebut dalam ExecStart: path tersebut tidak ada, atau file ada tetapi tidak dapat dieksekusi. Baris #! yang menyebut 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 sesuatu yang umum, seperti "port sudah digunakan". Tanyakan kembali: "baris mana dalam informasi yang saya berikan yang mendukung pernyataan itu?" Penyebab yang tidak dapat ditunjukkan dalam 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 jika proses berakhir dengan status non-zero. 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 mengurai file dengan cara yang sama seperti systemd, sehingga kesalahan yang terlewatkan oleh mata manusia dapat terdeteksi. Direktif yang salah eja menghasilkan /etc/systemd/system/myapp.service:7: Unknown key name 'Enviroment' in section 'Service', ignoring.. Binary yang tidak ada menghasilkan Command /usr/local/bin/myapp is not executable: No such file or directory. Keduanya tidak menampilkan apa pun selama daemon-reload. Karena itu, unit dapat dimuat tanpa error tetapi tetap gagal saat dijalankan.

Dua kesalahan dalam penyusunan unit sering muncul. Kesalahan pertama adalah After=network.target. Ini hanya berarti stack jaringan sudah dikonfigurasi, bukan bahwa alamat 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 melakukan daemonisasi. systemd menganggap proses pertama sebagai service, proses induk langsung berakhir, dan unit ditandai mati sementara proses sebenarnya tetap berjalan tanpa dikelola. Inilah kesalahan yang paling mungkin diberikan model kepada Anda karena model tidak dapat mengetahui dari perintah Anda apakah binary melakukan fork. Karena itu, pahami jaminan setiap nilai Type= untuk systemd sebelum menerima draf tersebut.

Untuk jadwal, periksa jadwal tersebut alih-alih hanya membacanya:

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

Perintah itu mencetak bentuk yang dinormalisasi dan waktu berikutnya saat ekspresi dijalankan. Dengan demikian, tidak ada lagi perbedaan pendapat tentang maknanya. Jika Anda memilih antara timer dan crontab, service dan timer systemd pada VPS membahas pertimbangannya.

Cron memiliki jebakan yang tidak akan diperingatkan oleh model kecuali Anda menanyakannya. Cron menjalankan job dengan environment minimal. Jadi, PATH kurang lebih sama dengan /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 binary tersebut berada di /usr/local/bin. Gunakan path absolut dalam crontab. Jika keharusan file unit untuk mencantumkan pengguna, environment, dan dependensi secara eksplisit terasa berlebihan dibandingkan satu baris crontab, masalah yang menjadi alasan systemd dibuat menjelaskan asal mula verbosity tersebut.

Tugas 3: tinjau file nginx atau Compose sebelum digunakan

Tugas ini memberikan manfaat terbesar. Tempelkan file tersebut, jelaskan fungsi yang seharusnya dijalankannya, lalu minta penjelasan baris demi baris tentang fungsi sebenarnya.

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

Kemudian 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 diparse, dan mencetak pesan singkat seperti yaml: line 7: did not find expected key jika indentasi Anda salah.

Kedua alat tersebut tidak memeriksa maksud konfigurasi. Konfigurasi yang lolos nginx -t tetap dapat meneruskan trafik ke port yang salah atau listen pada 0.0.0.0 saat yang Anda maksud adalah 127.0.0.1. Di sinilah model memberikan manfaat, tetapi juga dapat gagal: ketika diminta memperbaiki satu directive, model sering mengembalikan seluruh file yang telah ditulis ulang dan secara diam-diam menghilangkan dua directive Anda. Minta hanya baris yang diubah beserta alasan setiap perubahan, lalu lakukan penyuntingan secara manual.

Pastikan apa yang benar-benar Anda ekspos:

sudo ss -tulpn

Tanpa sudo, Anda hanya dapat melihat socket yang listen, bukan proses yang memilikinya. Jika output tersebut mengejutkan Anda, baca penjelasan singkat tentang port dan cara Linux melakukan bind pada port.

Tugas 4: jelaskan perintah yang belum dikenal sebelum menjalankannya

Tempelkan perintah tersebut dan ajukan empat pertanyaan tentangnya: apa fungsi setiap flag, apa yang ditulisnya, apa yang dihapusnya, dan apa yang terjadi jika saya menjalankannya dua kali. Pertanyaan terakhir dapat mencegah lebih banyak kerusakan daripada pertanyaan lainnya.

Perhatikan find /var/log -name '*.gz' -mtime +7 -delete. Jawaban yang baik menjelaskan bahwa -mtime +7 menghitung periode 24 jam penuh dan membuang pecahannya. Jadi, 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, memindahkan -delete ke depan -name akan menghapus semua yang berada di bawah path awal. Poin kedua tersebut tercantum sebagai peringatan di halaman man find dan telah membuat banyak orang kehilangan /var/log.

Atau, perhatikan rsync -a --delete /srv/app/ /backup/app/. Garis miring di akhir source berarti "isi direktori ini". Jika dihapus, hasilnya adalah /backup/app/app/. Jika --delete ditambahkan, semua yang ada di destination tetapi tidak ada di source akan dihapus. Ini benar untuk mirror, tetapi 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 dapat diandalkan untuk tool yang memiliki dokumentasi selama tiga puluh tahun, tetapi jauh lebih lemah untuk CLI (command line interfaces) vendor dan subcommand terbaru. Dalam kasus tersebut, model dapat menghasilkan flag yang terlihat benar tetapi sebenarnya tidak ada. --help dapat memastikannya dalam satu detik. Quoting adalah titik lemah lainnya. Jadi, ketika sebuah perintah membungkus ekspresi $(...), baca cara command substitution diperluas sebelum perintah dijalankan dan jangan hanya mempercayai penjelasannya.

Job 5: ubah shell history Anda menjadi runbook

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

history 200 > /tmp/session.txt

Baca file tersebut dan hapus setiap baris yang berisi password, token, atau identifier pelanggan sebelum file digunakan di tempat lain. Shell history adalah salah satu tempat paling andal untuk menemukan secret pada sistem Linux, karena setiap orang setidaknya pernah mengetikkannya secara inline. Atur HISTCONTROL=ignorespace di dalam ~/.bashrc, dan command yang diketik dengan spasi di awal tidak akan ditulis ke history sama sekali.

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

Ini adalah shell session yang mengubah instalasi Debian 13 baru menjadi instalasi Postgres yang berfungsi. Tuliskan sebagai runbook bernomor. Gunakan satu command pada setiap 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 spesifik saya.

Mode kegagalan: cerita yang terlalu rapi. Session Anda memiliki langkah yang dua kali salah sebelum diperbaiki, dan itulah langkah yang dihilangkan model karena transkrip terlihat lebih rapi tanpanya. Bandingkan runbook dengan history Anda dan masukkan kembali koreksi tersebut. Model juga dapat membuat command verifikasi yang terdengar masuk akal, jadi jalankan setiap pemeriksaan yang ditulisnya sebelum menyimpan file. Jika runbook tersebut mencakup boot pertama, bandingkan isinya 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 yang persis sama, perintah yang menghasilkannya, dan satu hal yang Anda ubah sebelum pesan tersebut muncul. Minta daftar penyebab berdasarkan peringkat, disertai satu perintah pembeda untuk setiap penyebab. Dengan begitu, 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 guna mengonfirmasi atau menyingkirkannya.

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

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

Yang sering salah

• Claude tidak dapat melihat server Anda. Setiap jawaban bergantung pada hal yang Anda tempelkan, dan Claude tidak akan memberi tahu bahwa cuplikan tersebut terlalu pendek.
• Claude tidak konsisten pada versi. Nama paket dan flag default dapat berubah antardistribusi dan rilis, sedangkan model merata-ratakan semuanya.
• Claude tetap fasih saat jawabannya salah. Mekanisme yang diada-adakan terdengar persis seperti mekanisme yang benar. Karena itu, setiap penyebab di atas disertai perintah untuk mengujinya.
• Claude 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 adalah solusi praktisnya: gunakan sesi yang lebih singkat, satu tugas per sesi.

Menempatkan agent langsung di server

Semua langkah di atas cukup disalin dan ditempel, sehingga model tidak pernah berinteraksi dengan mesin Anda. Setelah berjalan di server, membaca file, dan mengeksekusi perintah, bentuk risikonya berubah: perintah yang salah dapat menyebabkan sebuah service berhenti. Berikan agent akun pengguna sendiri yang tidak memiliki hak istimewa, bukan root. Jangan jalankan agent di server produksi selama Anda masih mempelajari perilakunya, dan buat snapshot terlebih dahulu. Menjalankan Claude Code dengan aman di VPS membahas sandboxing dan model izin. Menjalankan Claude Code di dalam tmux mengatasi masalah lainnya, karena sesi SSH (secure shell) yang terputus akan menghentikan agent yang berjalan di foreground saat pekerjaannya belum selesai. Buat akun tersebut seperti Anda membuat akun service, sebagaimana dijelaskan dalam pengguna dengan hak minimum di VPS.

FAQ

Bisakah Claude membaca log server saya secara langsung?

Tidak secara langsung. 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 sudah disamarkan lebih cepat dan lebih 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 cuplikan tersebut dimasukkan ke prompt. Salah satu kasus yang sering terlewat: output docker compose config berisi nilai .env Anda yang sudah 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 memiliki konteks: aman untuk membaca, tetapi tindakan penulisan perlu ditinjau. Pada sistem produksi, minta penjelasannya lalu jalankan sendiri perintah tersebut. Jika Anda memang ingin agen menjalankan perintah, berikan akun khusus tanpa hak istimewa dan tanpa akses sudo secara menyeluruh. Mulailah pada server staging, sehingga kesalahan mengharuskan Anda melakukan rebuild, bukan menyebabkan outage.

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, ketika dokumentasi yang tersedia bagi model masih terbatas atau sudah berubah. --help dan man menjadi acuan utama. Setiap perintah yang menghapus atau menimpa data harus diuji dengan 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, dan menandai binary ExecStart yang tidak ada 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.