Cara Guna Claude AI Untuk Tugasan Pentadbir Sistem Linux

Claude untuk pentadbir sistem: nasihat dahulu, pelaksanaan kemudian

Claude untuk pentadbir sistem berfungsi paling baik sebagai penyemak. Anda menampal petikan log, fail konfigurasi, arahan yang tidak anda kenali, atau rentetan ralat, dan anda mendapat penjelasan yang boleh anda semak sebelum mengubah apa-apa pada pelayan. Jawapan yang salah tidak merugikan anda selagi anda tidak menjalankannya, jadi mengekalkan model pada bahagian nasihat adalah model keselamatan yang menyeluruh.

Enam tugasan muncul setiap minggu pada Linux VPS (pelayan peribadi maya) yang disewa. Setiap satu di bawah mempunyai corak gesaan yang berkesan, arahan yang membuktikan jawapan tersebut, dan mod kegagalan yang perlu anda jangkakan. Tiada satu pun daripadanya memerlukan model mempunyai akses kepada pelayan anda. Anda boleh menampal daripada tab pelayar atau daripada tetingkap pada desktop anda sendiri, memandangkan Claude berjalan secara natif pada Linux sebagai aplikasi desktop dan CLI.

Urutan adalah penting pada pelayan pengeluaran: baca penjelasan, jalankan semakan sendiri, kemudian buat keputusan. Autonomi boleh diterima pada VM ujian. Pada pelayan yang melayani pelanggan anda, semakan adalah keutamaan, kerana model tidak dapat melihat keadaan sebenar yang sedang ditekanya.

Perkara yang tidak boleh anda tampal

Segala maklumat dalam prompt akan meninggalkan pelayan anda. Empat kategori ini mesti kekal di dalam pelayan:

• Kunci peribadi: ~/.ssh/id_ed25519, /etc/ssh/ssh_host_*_key, dan sebarang kunci TLS (transport layer security) di bawah /etc/letsencrypt/live/.
• Fail kelayakan: .env, ~/.aws/credentials, /root/.docker/config.json, dan kata laluan pangkalan data dalam mana-mana fail atau baris log.
• Data akaun: /etc/shadow dan /etc/gshadow. Tiada soalan pentadbir sistem yang memerlukan hash kata laluan untuk dijawab.
• Apa-apa sahaja milik pengguna anda: alamat e-mel, baris pesanan, log permintaan yang membawa kuki sesi atau PII (maklumat pengenalan peribadi).

Kunci awam selamat untuk ditampal. Kunci peribadi tidak selamat, dan kedua-dua fail tersebut kelihatan serupa, jadi baca baris pertama sebelum anda menyalin: fail yang baris pertamanya mengandungi BEGIN OPENSSH PRIVATE KEY tidak boleh dimasukkan ke dalam prompt. Mengurus bahan kunci SSH anda adalah topik yang berbaloi untuk dipelajari selama sepuluh minit.

Lakukan penyuntingan (redact) sebelum anda menampal, daripada mempercayai diri sendiri untuk mengesan satu token dalam 200 baris:

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

Satu perangkap adalah khusus untuk Docker. docker compose config melakukan interpolasi nilai .env anda ke dalam output yang dicetaknya, jadi output tersebut adalah rahsia walaupun fail pada cakera tidak. Gunakan docker compose config -q, yang melakukan pengesahan dan tidak mencetak apa-apa. Bagi polisi yang lebih luas tentang perkara yang dibenarkan untuk dilihat oleh ejen, menjauhkan rahsia daripada ejen AI merangkumi aspek persekitaran.

Tugasan 1: mengapa servis ini gagal?

Mulakan dengan dua arahan yang mengandungi jawapannya:

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

Tampal kedua-duanya, berserta konteks yang tidak dapat diagak oleh model: pengedaran dan versi, perkara terakhir yang anda ubah, sama ada ia pernah berfungsi, dan berapa lama dahulu ia rosak. Tanya tentang mekanismenya dahulu.

Ubuntu 24.04. myapp.service berfungsi dengan baik sehingga saya menyunting unit tersebut sejam yang lalu. Berikut adalah systemctl status dan 100 baris log journal terakhir. Baris manakah ralat sebenar yang pertama, dan apakah maksudnya? Belum ada pembaikan lagi.

"Belum ada pembaikan lagi" memainkan peranan penting dalam prompt tersebut. Log sering menimbus kegagalan pertama di bawah percubaan semula yang disebabkannya, jadi model yang diminta untuk memberikan pembaikan akan menjelaskan baris terakhir yang dilihatnya. Baris yang penting biasanya berada dua puluh baris di atas gangguan tersebut.

Hasilnya ialah baris seperti Main PID: 1841 (code=exited, status=203/EXEC). Status keluar 203/EXEC bermaksud kernel tidak dapat melaksanakan fail yang dinamakan dalam ExecStart: sama ada laluan tersebut tidak wujud, atau fail tersebut wujud tetapi tidak boleh dilaksanakan. Baris #! yang menamakan penterjemah yang tidak dipasang akan menghasilkan status yang sama. Semua itu boleh diuji dengan ls -l dan head -1.

Mod kegagalan: punca yang direka-reka. Tampal terlalu sedikit dan model akan mengisi ruang tersebut dengan sesuatu yang generik, seperti "port sudah digunakan". Penawarnya adalah dengan satu soalan kembali: "baris mana dalam apa yang saya berikan menyokong perkara itu?" Punca yang tidak dapat ditunjukkan oleh sesiapa dalam teks tersebut hanyalah satu tekaan.

Tugas 2: merangka unit systemd atau entri cron

Berikan fakta yang diperlukan oleh fail unit: arahan tepat, pengguna yang menjalankan proses, direktori kerja, sama ada ia perlu menunggu rangkaian, dan tindakan yang perlu diambil apabila ia keluar dengan status bukan sifar. Kemudian, sahkan kandungan tersebut sebelum anda mendayakan apa-apa.

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 menghuraikan fail tersebut mengikut cara systemd, jadi ia mengesan perkara yang terlepas daripada pandangan manusia. Arahan yang salah eja akan mencetak /etc/systemd/system/myapp.service:7: Unknown key name 'Enviroment' in section 'Service', ignoring.. Binari yang hilang akan mencetak Command /usr/local/bin/myapp is not executable: No such file or directory. Kedua-duanya kekal senyap semasa daemon-reload, itulah sebabnya unit boleh dimuatkan dengan sempurna tetapi masih gagal sebaik sahaja ia dijalankan.

Dua kesilapan merangka sering berlaku berulang kali. Yang pertama ialah After=network.target, yang hanya bermaksud tindanan rangkaian telah dikonfigurasikan, bukan bermakna alamat sudah wujud. Servis yang mengikat (bind) pada IP tertentu kemudian gagal semasa but dengan bind: Cannot assign requested address, dan penyelesaiannya ialah Wants=network-online.target bersama-sama dengan After=network-online.target. Yang kedua ialah Type=simple untuk program yang melakukan daemonisasi: systemd menganggap proses pertama sebagai servis, induk (parent) terus keluar, dan unit ditandakan sebagai mati manakala proses sebenar terus berjalan tanpa pengurusan. Itu adalah kesilapan yang paling mungkin diberikan oleh model kepada anda, kerana ia tidak dapat mengetahui daripada arahan anda sama ada binari tersebut melakukan fork, jadi adalah berbaloi untuk mengetahui apa yang dijanjikan oleh setiap nilai Type= kepada systemd sebelum anda menerima draf tersebut.

Untuk jadual, semak ia dan bukannya membacanya:

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

Itu mencetak bentuk ternormal dan masa seterusnya ungkapan tersebut akan dicetuskan, yang menyelesaikan sebarang perdebatan tentang maksudnya. Jika anda memilih antara pemasa (timer) dan crontab, servis dan pemasa systemd pada VPS merangkumi perbandingan tersebut.

Cron mempunyai perangkap yang tidak akan diberi amaran oleh mana-mana model melainkan anda bertanya. Cron menjalankan kerja dengan persekitaran minimum, jadi PATH secara kasarnya ialah /usr/bin:/bin dan profil shell anda tidak pernah dibaca. Kerja yang berfungsi apabila anda menampalnya ke dalam terminal anda gagal di bawah cron dengan /bin/sh: 1: docker: not found, kerana binari tersebut berada dalam /usr/local/bin. Gunakan laluan mutlak (absolute paths) dalam crontab. Jika desakan fail unit untuk menyatakan pengguna, persekitaran dan dependency terasa seperti upacara yang rumit berbanding satu baris crontab, masalah yang systemd dibina untuk selesaikan menjelaskan dari mana datangnya kelakuan verbose tersebut.

Tugasan 3: semak fail nginx atau Compose sebelum ia dilancarkan

Tugasan ini memberikan pulangan terbaik. Tampal fail tersebut, nyatakan fungsinya, dan minta penjelasan baris demi baris tentang apa yang sebenarnya dilakukan oleh fail itu.

vhost ini sepatutnya menghidangkan example.com melalui HTTPS dan memproksi /api ke servis tempatan pada port 8080. Baca semula kepada saya dan namakan apa-apa yang tidak sepadan dengan penerangan tersebut.

Kemudian jalankan alat yang memahami tatabahasa:

sudo nginx -t
docker compose config -q

nginx -t akan mencetak nginx: configuration file /etc/nginx/nginx.conf test is successful, atau ia menamakan fail dan baris tersebut, seperti dalam nginx: [emerg] unknown directive "proxy_pas" in /etc/nginx/conf.d/app.conf:12. docker compose config -q tidak mencetak apa-apa apabila fail berjaya dihuraikan, dan mencetak mesej ringkas seperti yaml: line 7: did not find expected key apabila indentasi anda tersasar.

Tiada satu pun alat yang menyemak niat. Konfigurasi yang melepasi nginx -t masih boleh memproksi ke port yang salah, atau mendengar pada 0.0.0.0 sedangkan anda berniat menggunakan 127.0.0.1. Jurang itulah tempat model ini memainkan peranan, dan ia juga merupakan tempat ia gagal: apabila diminta untuk membetulkan satu arahan, ia sering memulangkan keseluruhan fail yang ditulis semula dengan dua arahan anda hilang secara senyap. Minta baris yang diubah dan sebab bagi setiap satu, kemudian edit secara manual.

Sahkan apa yang sebenarnya anda dedahkan:

sudo ss -tulpn

Tanpa sudo anda melihat soket yang mendengar tetapi bukan proses yang memilikinya. Jika output tersebut mengejutkan anda, apakah port dan bagaimana Linux mengikatnya adalah bacaan yang lebih ringkas.

Tugas 4: terangkan arahan yang tidak dikenali sebelum anda menjalankannya

Tampal arahan tersebut dan ajukan empat soalan mengenainya: apakah fungsi setiap flag, apakah yang ditulisnya, apakah yang dipadamkannya, dan apakah yang berlaku jika saya menjalankannya dua kali. Soalan terakhir ini dapat mengesan lebih banyak kerosakan berbanding soalan lain.

Ambil contoh find /var/log -name '*.gz' -mtime +7 -delete. Jawapan yang baik memberitahu anda bahawa -mtime +7 mengira tempoh 24 jam penuh dan membuang pecahan, jadi ia memadankan fail yang berusia sekurang-kurangnya lapan hari dan bukannya tujuh. Ia juga memberitahu anda bahawa find menilai ekspresinya dari kiri ke kanan, jadi mengalihkan -delete ke hadapan -name akan memadamkan segala-galanya di bawah laluan permulaan. Perkara kedua itu dinyatakan dalam halaman manual find sebagai amaran, dan ia telah menyebabkan ramai orang kehilangan /var/log mereka.

Atau ambil contoh rsync -a --delete /srv/app/ /backup/app/. Garis miring (trailing slash) pada sumber bermaksud "kandungan direktori ini". Gugurkannya dan anda akan mendapat /backup/app/app/. Tambahkan --delete dan apa-apa sahaja dalam destinasi yang tiada dalam sumber akan dibuang, yang mana betul untuk cermin (mirror) tetapi menjadi bencana apabila laluan sumber salah.

Sahkan dengan alat tersebut, 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 dan anda akan mendapat senarai dan bukannya kehilangan data.

Mod kegagalan: halusinasi flag. Model ini boleh dipercayai pada alat yang mempunyai dokumentasi selama tiga puluh tahun dan jauh lebih lemah pada CLI (antara muka baris arahan) vendor serta sub-arahan terkini, di mana ia menghasilkan flag yang kedengaran sempurna tetapi tidak wujud. --help menyelesaikannya dalam satu saat. Penggunaan tanda petik (quoting) adalah satu lagi kelemahan, jadi apabila sesuatu arahan membungkus ekspresi $(...), baca bagaimana penggantian arahan dikembangkan sebelum arahan dijalankan dan bukannya mempercayai penjelasan tersebut.

Tugasan 5: tukarkan sejarah shell anda menjadi runbook

Anda baru sahaja menghabiskan dua jam untuk menyiapkan sesuatu. Pengetahuan itu tersimpan dalam scrollback anda dan akan hilang pada bulan hadapan.

history 200 > /tmp/session.txt

Baca fail tersebut dan padamkan setiap baris yang mengandungi kata laluan, token, atau pengecam pelanggan sebelum ia dipindahkan ke mana-mana. Sejarah shell adalah salah satu tempat paling boleh dipercayai untuk mencari rahsia pada kotak Linux, kerana semua orang pasti pernah menaipnya secara inline sekurang-kurangnya sekali. Tetapkan HISTCONTROL=ignorespace dalam ~/.bashrc anda dan arahan yang ditaip dengan ruang kosong di hadapan tidak akan ditulis ke dalam sejarah sama sekali.

Prompt yang menghasilkan runbook yang boleh digunakan memerlukan semakan, bukan sekadar langkah:

Ini adalah sesi shell yang menukar kotak Debian 13 baharu kepada pemasangan Postgres yang berfungsi. Tuliskan ia sebagai runbook bernombor. Satu arahan bagi setiap langkah. Selepas setiap langkah, berikan arahan yang membuktikan ia berfungsi dan terangkan rupa output yang sihat. Tandakan mana-mana langkah yang bergantung pada hos khusus saya.

Mod kegagalan: cerita yang terlalu kemas. Sesi anda mempunyai langkah yang anda lakukan salah dua kali sebelum membetulkannya, dan itu adalah langkah yang akan dilicinkan oleh model, kerana transkrip kelihatan lebih bersih tanpanya. Bandingkan runbook dengan sejarah anda dan masukkan semula pembetulan tersebut. Ia juga mencipta arahan pengesahan yang munasabah, jadi jalankan setiap semakan yang ditulisnya sebelum anda menyimpan fail tersebut. Jika runbook tersebut meliputi but pertama, bacalah ia berbanding sepuluh minit pertama pada VPS baharu supaya anda tidak menulis versi yang lebih buruk bagi masalah yang telah diselesaikan.

Tugasan 6: menukar mesej ralat kepada pembaikan

Tampal rentetan tepat, arahan yang menghasilkannya, dan satu perkara yang anda ubah sebelum ia muncul. Minta senarai punca yang disusun mengikut keutamaan berserta arahan pengesahan bagi setiap satu, yang memaksa jawapan menjadi sesuatu yang boleh diuji.

nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use). Susun punca yang berkemungkinan mengikut keutamaan dan berikan saya satu arahan bagi setiap punca untuk mengesahkan atau menolak punca tersebut.

Bagi ralat tersebut, mekanismenya tidak samar: proses lain sudah memegang port 80, dan sudo ss -tulpn | grep ':80 ' menamakannya. Selalunya, ini adalah master Nginx kedua yang tertinggal akibat reload yang gagal, atau Apache yang ditarik masuk sebagai dependency dan dimulakan oleh pakejnya sendiri.

Mod kegagalan: pembaikan yang berfungsi dengan menyembunyikan punca. chmod 777, --privileged, menyahdayakan SELinux, dan menjalankan servis sebagai root, kesemuanya membuatkan ralat hilang. Tolak sebarang pembaikan yang meluaskan kebenaran (permissions) sehingga model menjelaskan mengapa kebenaran yang terhad gagal. Penjelasan itu adalah jawapan sebenar. Penyelesaian sementara (workaround) hanya mendiamkan ralat tersebut.

Perkara yang sering disalah anggap

• Ia tidak dapat melihat pelayan anda. Setiap jawapan adalah fungsi daripada apa yang anda tampal, dan ia tidak akan memberitahu anda jika petikan tersebut terlalu pendek.
• Ia terkeliru mengenai versi. Nama pakej dan flag lalai berubah antara pengedaran dan keluaran, dan model ini memberikan purata merentas kesemuanya.
• Ia sangat lancar walaupun salah. Mekanisme yang direka-reka kelihatan tepat seperti yang betul, itulah sebabnya setiap punca di atas disertakan dengan arahan untuk mengujinya.
• Ia hilang fokus dalam sesi yang panjang. Fakta daripada bahagian atas perbualan selama dua jam berhenti membentuk jawapan di bahagian bawah.

Perkara terakhir itu lebih kepada masalah kerja berbanding masalah model, dan mengurus konteks dalam sesi Claude Code yang panjang adalah penyelesaian praktikalnya: sesi yang lebih pendek, satu tugasan bagi setiap sesi.

Meletakkan ejen pada pelayan itu sendiri

Segala perkara di atas adalah salin dan tampal, jadi model tidak pernah menyentuh mesin anda. Sebaik sahaja ia berjalan pada pelayan, membaca fail dan melaksanakan arahan, bentuk risiko akan berubah: satu arahan yang salah kini boleh menjejaskan servis anda. Berikan pengguna tanpa keistimewaan (unprivileged user) sendiri dan bukannya root, jauhkan ia daripada pelayan pengeluaran (production box) semasa anda mempelajari tabiatnya, dan ambil snapshot terlebih dahulu. Menjalankan Claude Code dengan selamat pada VPS merangkumi pemisahan persekitaran (sandboxing) dan model kebenaran. Mengendalikan Claude Code di dalam tmux menyelesaikan separuh lagi masalah, memandangkan sesi SSH (secure shell) yang terputus akan mematikan ejen latar depan di tengah-tengah kerjanya. Bina akaun tersebut seperti cara anda membina mana-mana akaun servis, yang diperincikan dalam pengguna dengan keistimewaan minimum pada VPS.

FAQ

Bolehkah Claude membaca log pelayan saya secara terus?

Tidak secara sendirinya. Antara muka sembang hanya melihat teks yang anda tampal ke dalamnya. Claude Code, yang dijalankan pada pelayan sebagai alat baris perintah, boleh membaca fail dan menjalankan perintah dengan kebenaran pengguna yang memulakannya, yang merupakan keputusan kepercayaan yang lebih besar. Untuk soalan sokongan biasa, menampal petikan 100 baris yang telah disunting adalah lebih pantas dan lebih selamat daripada memberikan akses shell kepada ejen.

Apakah yang tidak boleh saya tampal daripada pelayan?

Kunci peribadi, fail .env dan stor kelayakan lain, /etc/shadow, serta sebarang data milik pengguna anda. Sunting token daripada petikan log sebelum ia sampai ke prompt. Satu kes yang tidak jelas: output docker compose config mempunyai nilai .env anda yang disisipkan ke dalamnya, jadi gunakan docker compose config -q, yang mengesahkan fail tersebut dan tidak mencetak apa-apa.

Adakah selamat untuk membiarkan Claude menjalankan perintah pada VPS pengeluaran?

Anggap ia seperti pentadbir baharu tanpa konteks: selamat untuk membaca, semakan diperlukan untuk menulis. Pada pengeluaran, minta penjelasan dan jalankan perintah itu sendiri. Jika anda mahu ejen melaksanakan perintah, berikan akaun tanpa keistimewaan yang khusus tanpa sudo menyeluruh, dan mulakan pada kotak staging di mana kesilapan hanya menyebabkan pembinaan semula dan bukannya gangguan perkhidmatan.

Mengapa Claude mencadangkan flag yang tidak wujud?

Kerana ia meramalkan teks yang munasabah, dan flag yang munasabah kelihatan sama seperti yang sebenar. Ia paling kerap berlaku dengan CLI vendor dan subperintah yang lebih baharu, di mana dokumentasi di sebalik model adalah terhad atau telah berubah sejak itu. --help dan man adalah penentu, dan sebarang perintah yang memadam atau menulis ganti perlu dijalankan secara dry run terlebih dahulu.

Bagaimanakah cara saya menyemak unit systemd sebelum saya mendayakannya?

Jalankan sudo systemd-analyze verify /etc/systemd/system/myapp.service. Ia menghuraikan fail dengan penghurai systemd sendiri, melaporkan arahan yang tidak diketahui berserta nombor barisnya, dan menandakan binari ExecStart yang hilang atau tidak boleh dilaksanakan. Kemudian jalankan daemon-reload, start, dan baca systemctl status sebelum anda enable unit tersebut, kerana unit yang dimuatkan dengan bersih masih boleh gagal pada percubaan pertama.