Cara Guna Claude AI untuk Pentadbiran 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 dikenali, atau rentetan ralat, dan anda akan mendapat penjelasan yang boleh disemak sebelum anda mengubah apa-apa pada pelayan. Jawapan yang salah tidak mendatangkan kesan sehingga anda 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 daripada tugasan ini memerlukan model mempunyai akses kepada pelayan anda.

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

Perkara yang tidak boleh ditampal

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

• Kunci peribadi (Private keys): ~/.ssh/id_ed25519, /etc/ssh/ssh_host_*_key, dan sebarang kunci TLS (transport layer security) di bawah /etc/letsencrypt/live/.
• Fail kelayakan (Credential files): .env, ~/.aws/credentials, /root/.docker/config.json, serta kata laluan pangkalan data dalam mana-mana fail atau baris log.
• Data akaun: /etc/shadow dan /etc/gshadow. Tiada soalan pentadbiran 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 (Public keys) 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, jangan hanya bergantung pada keupayaan anda 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 terhadap nilai .env anda ke dalam output yang dicetak, jadi output tersebut menjadi rahsia walaupun fail pada cakera tidak mengandungi rahsia. Gunakan docker compose config -q, yang melakukan pengesahan tanpa mencetak apa-apa. Bagi polisi yang lebih luas tentang perkara yang boleh dilihat oleh ejen, menjauhkan rahsia daripada ejen AI merangkumi aspek persekitaran.

Tugasan 1: mengapa servis ini gagal?

Mulakan dengan dua arahan yang mengandungi jawapan:

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

Tampalkan 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 yang terakhir. Baris manakah ralat sebenar yang pertama, dan apakah maksudnya? Tiada pembaikan lagi.

"Tiada pembaikan lagi" (No fix yet) memainkan peranan penting dalam prompt tersebut. Log akan 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). Exit status 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 (not executable). Baris #! yang menamakan penterjemah (interpreter) yang tidak dipasang akan menghasilkan status yang sama. Semua itu boleh diuji dengan ls -l dan head -1.

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

Tugasan 2: merangka unit systemd atau entri cron

Berikan fakta yang diperlukan oleh fail unit: arahan tepat, pengguna yang menjalankannya, direktori kerja, sama ada ia perlu menunggu rangkaian, dan perkara yang perlu berlaku apabila ia keluar dengan status bukan sifar. Kemudian, sahkan perkara yang dikembalikan 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 mata 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 bersih 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) kepada 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) keluar serta-merta, dan unit ditandakan sebagai mati manakala proses sebenar terus berjalan tanpa pengurusan.

Untuk jadual, semak ia dan bukannya membacanya:

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

Itu mencetak bentuk ternormal dan masa seterusnya ungkapan itu akan dicetuskan, yang menyelesaikan sebarang pertikaian 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 yang 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 itu berada dalam /usr/local/bin. Gunakan laluan mutlak (absolute paths) dalam crontab.

Tugasan 3: semak fail nginx atau Compose sebelum ia dilancarkan

Tugasan ini memberikan hasil yang paling berbaloi. Tampal fail tersebut, nyatakan fungsi yang sepatutnya, 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 dihurai, dan mencetak sesuatu yang 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 di situ juga ia boleh gagal: apabila diminta 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 sunting secara manual.

Sahkan apa yang sebenarnya anda dedahkan:

sudo ss -tulpn

Tanpa sudo anda hanya 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 tanya 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 mengabaikan pecahan, jadi ia memadankan fail yang sekurang-kurangnya lapan hari lama 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". Jika anda membuangnya, 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 perintah) vendor serta sub-arahan terkini, di mana ia menghasilkan flag yang kedengaran sempurna tetapi tidak wujud. --help menyelesaikannya dalam satu saat. Pemetik kata (quoting) adalah satu lagi kelemahan, jadi apabila sesuatu arahan membungkus ekspresi $(...), baca bagaimana penggantian arahan dikembangkan sebelum arahan dijalankan daripada mempercayai penjelasan tersebut.

Tugasan 5: Tukarkan sejarah shell anda menjadi buku panduan (runbook)

Anda baru sahaja menghabiskan dua jam untuk memastikan sesuatu berfungsi. Pengetahuan tersebut tersimpan dalam tatalan (scrollback) anda dan akan hilang pada bulan hadapan.

history 200 > /tmp/session.txt

Baca fail tersebut dan padam 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 mesin Linux, kerana semua orang pasti pernah menaipnya secara terus 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 buku panduan yang boleh digunakan memerlukan pemeriksaan, bukan sekadar langkah-langkah:

Ini adalah sesi shell yang menukar kotak Debian 13 yang baharu kepada pemasangan Postgres yang berfungsi. Tuliskan ia sebagai buku panduan 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 sebanyak dua kali sebelum membetulkannya, dan itu adalah langkah yang akan dilicinkan oleh model, kerana transkrip tersebut kelihatan lebih bersih tanpanya. Bandingkan buku panduan tersebut dengan sejarah anda dan masukkan semula pembetulan tersebut. Ia juga akan mencipta arahan pengesahan yang munasabah, jadi jalankan setiap pemeriksaan yang ditulisnya sebelum anda menyimpan fail tersebut. Jika buku panduan tersebut merangkumi 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 kedudukan punca yang mungkin berserta arahan pembeza untuk 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). Kedudukan punca yang mungkin dan berikan saya satu arahan bagi setiap punca yang mengesahkan atau menolak punca tersebut.

Bagi ralat itu, mekanismenya tidak samar: proses lain sudah memegang port 80, dan sudo ss -tulpn | grep ':80 ' menamakannya. Selalunya ia 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 semuanya membuatkan ralat itu 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 membuatkan ralat itu senyap.

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 ketika salah. Mekanisme yang direka-reka (hallucinated) dibaca sama seperti mekanisme 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 merupakan 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 perkhidmatan anda. Berikan ia pengguna tanpa keistimewaan (unprivileged user) sendiri dan bukannya root, jauhkan ia daripada pelayan pengeluaran (production box) semasa anda mempelajari tabiatnya, dan ambil syot kilat (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 perkhidmatan, 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 dari 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 gesaan. Satu kes yang tidak jelas: output docker compose config mempunyai nilai .env anda yang diinterpolasi ke dalamnya, jadi gunakan docker compose config -q, yang mengesahkan fail tersebut dan tidak mencetak apa-apa.

Adakah selamat 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 anda membina semula sistem 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 tersebut 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.