Claude para sa sysadmins: 6 na server task

Claude para sa sysadmins: payo muna, execution pagkatapos

Pinakamahusay gamitin ang Claude bilang reviewer para sa mga sysadmin. Mag-paste ka ng bahagi ng log, config file, command na hindi mo nakikilala, o error string, at makakakuha ka ng paliwanag na maaari mong i-check bago ka magbago ng anuman sa server. Walang magiging epekto ang maling sagot hangga't hindi mo ito ine-execute, kaya ang pagpapanatili sa model sa panig ng pagpapayo ang pangunahing safety model.

Anim na gawain ang karaniwang lumilitaw bawat linggo sa isang nirentahang Linux VPS (virtual private server). May prompt pattern para sa bawat gawain na gumagana, ang command na nagpapatunay sa sagot, at ang failure mode na dapat mong asahan. Wala sa mga ito ang nangangailangan ng access ng model sa server mo.

Mahalaga ang pagkakasunod-sunod sa production box: basahin ang paliwanag, ikaw mismo ang magpatakbo ng check, at saka magpasya. Ayos ang autonomy sa isang scratch VM. Sa box na nagseserve sa iyong mga customer, mas ligtas ang review dahil hindi nakikita ng model ang aktuwal na state na hinuhulaan nito.

Mga bagay na hindi mo dapat i-paste kailanman

Lumalabas sa server mo ang lahat ng nasa prompt. Apat na kategorya ang dapat manatili sa server:

• Mga private key: ~/.ssh/id_ed25519, /etc/ssh/ssh_host_*_key, at anumang TLS (transport layer security) key sa ilalim ng /etc/letsencrypt/live/.
• Mga credential file: .env, ~/.aws/credentials, /root/.docker/config.json, at mga database password sa anumang file o log line.
• Data ng account: /etc/shadow at /etc/gshadow. Walang sysadmin question na nangangailangan ng password hash para masagot.
• Anumang pagmamay-ari ng mga user mo: email address, order row, at request log na naglalaman ng session cookie o PII (personally identifiable information).

Ligtas i-paste ang mga public key. Hindi ligtas ang private key. Magkahawig ang dalawang file sa unang tingin, kaya basahin ang unang linya bago kumopya: ang file na may BEGIN OPENSSH PRIVATE KEY sa unang linya ay hindi kailanman dapat ilagay sa prompt. Sulit ang sampung minuto para sa Maayos na paghawak sa iyong SSH key material.

Mag-redact bago mag-paste, sa halip na umasa sa sarili mong matukoy ang isang token sa 200 linya:

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

May isang partikular na bitag sa Docker. Ini-interpolate ng docker compose config ang mga value ng .env mo sa output na pini-print nito, kaya secret ang output na iyon kahit hindi secret ang file sa disk. Gamitin ang docker compose config -q, na nagva-validate pero walang pini-print. Para sa mas malawak na policy tungkol sa impormasyong maaaring makita ng isang agent, ipinapaliwanag ng Pag-iwas na mailabas ang mga secret sa AI agent ang bahagi tungkol sa environment.

Job 1: bakit nag-fail ang service na ito?

Magsimula sa dalawang command na naglalaman ng sagot:

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

I-paste ang dalawang ito kasama ang context na hindi mahuhulaan ng model: ang distribution at version, ang huli mong binago, kung gumana na ba ito dati, at kung gaano na katagal mula nang masira ito. Itanong muna ang mekanismo.

Ubuntu 24.04. Maayos ang myapp.service hanggang i-edit ko ang unit isang oras na ang nakalipas. Narito ang systemctl status at ang huling 100 linya ng journal. Aling linya ang unang tunay na error, at ano ang ibig sabihin nito? Wala munang fix.

May mahalagang silbi ang "Wala munang fix" sa prompt na iyon. Tinatabunan ng logs ang unang failure ng mga retry na idinulot nito, kaya kapag fix ang hiningi sa model, ang huling linyang nakita nito ang ipapaliwanag nito. Karaniwang nasa dalawampung linya bago ang ingay ang mahalagang linya.

Ang resulta ay maaaring isang linyang tulad ng Main PID: 1841 (code=exited, status=203/EXEC). Ibig sabihin ng exit status 203/EXEC, hindi na-execute ng kernel ang file na tinukoy sa ExecStart: maaaring wala ang path, o umiiral ang file pero hindi ito executable. Nagbibigay rin ng parehong status ang #! line na tumutukoy sa interpreter na hindi naka-install. Maaaring i-test ang lahat ng ito gamit ang ls -l at head -1.

Failure mode: imbentong sanhi. Kapag masyadong kaunti ang iyong na-paste, pupunan ng model ang puwang gamit ang generic na paliwanag, gaya ng "ginagamit na ng iba ang port". Ang lunas ay isang tanong pabalik: "Aling linya sa ibinigay ko ang sumusuporta rito?" Ang sanhi na walang matukoy na batayan sa text ay hula.

Job 2: Gumawa ng systemd unit o cron entry

Ibigay ang mga impormasyong kailangan ng unit file: ang eksaktong command, ang user na gagamit nito, ang working directory, kung kailangan nitong maghintay sa network, at kung ano ang dapat mangyari kapag nag-exit ito nang non-zero. Pagkatapos, i-verify ang resulta bago mo i-enable ang anuman.

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

Ipa-parse ng systemd-analyze verify ang file sa parehong paraan na ginagamit ng systemd para ma-detect nito ang mga bagay na maaaring hindi mapansin ng tao. Kapag may maling spelling na directive, magpi-print ito ng /etc/systemd/system/myapp.service:7: Unknown key name 'Enviroment' in section 'Service', ignoring.. Kapag may nawawalang binary, magpi-print ito ng Command /usr/local/bin/myapp is not executable: No such file or directory. Parehong hindi lumalabas ang mga error na ito sa daemon-reload. Kaya maaaring ma-load nang maayos ang isang unit at mabigo pa rin sa sandaling tumakbo ito.

Dalawang pagkakamali sa pagbuo ng unit ang paulit-ulit na nangyayari. Una ang After=network.target. Ibig sabihin lamang nito ay naka-configure na ang network stack, hindi na mayroon nang address. Kung nagbi-bind ang isang service sa partikular na IP, mabibigo ito sa boot at maglalabas ng bind: Cannot assign requested address. Ang ayos ay Wants=network-online.target kasama ng After=network-online.target. Ikalawa ang Type=simple para sa program na nag-daemonise. Itinuturing ng systemd na service ang unang process. Agad na nag-e-exit ang parent, kaya namamarkahan ang unit bilang dead habang patuloy na tumatakbo ang totoong process nang hindi mina-manage.

Para sa schedule, i-check ito sa halip na basahin lamang:

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

Ipi-print nito ang normalized na anyo at ang susunod na oras kung kailan tatakbo ang expression. Nilulutas nito ang anumang pagtatalo tungkol sa kahulugan nito. Kung namimili ka sa pagitan ng timer at crontab, tinatalakay sa systemd services at timers sa isang VPS ang mga trade-off.

May trap ang Cron na hindi babanggitin ng anumang model maliban kung itanong mo. Minimal ang environment na ginagamit ng Cron sa pagpapatakbo ng mga job. Kaya ang PATH ay humigit-kumulang /usr/bin:/bin, at hindi kailanman binabasa ang shell profile mo. Ang job na gumagana kapag ini-paste mo sa terminal ay mabibigo sa ilalim ng cron at maglalabas ng /bin/sh: 1: docker: not found, dahil nasa /usr/local/bin ang binary na iyon. Gumamit ng absolute path sa mga crontab.

Job 3: Suriin ang nginx o Compose file bago ito i-deploy

Ito ang may pinakamalaking pakinabang. I-paste ang file, sabihin kung ano ang dapat nitong gawin, at hilingin ang paliwanag sa bawat linya kung ano talaga ang ginagawa nito.

Dapat ihatid ng vhost na ito ang example.com gamit ang HTTPS at i-proxy ang /api sa isang local service sa port 8080. Basahin ito pabalik sa akin at tukuyin ang anumang hindi tumutugma sa paglalarawang ito.

Pagkatapos, patakbuhin ang tool na nakakaalam ng grammar:

sudo nginx -t
docker compose config -q

Ipinapakita ng nginx -t ang nginx: configuration file /etc/nginx/nginx.conf test is successful, o tinutukoy nito ang file at linya, gaya ng nasa nginx: [emerg] unknown directive "proxy_pas" in /etc/nginx/conf.d/app.conf:12. Walang inilalabas ang docker compose config -q kapag tama ang parsing ng file, at naglalabas ito ng diretsahang mensahe gaya ng yaml: line 7: did not find expected key kapag nagkamali ang indentation.

Wala sa dalawang tool ang sumusuri sa intent. Maaaring pumasa sa nginx -t ang isang configuration pero nagpo-proxy pa rin sa maling port, o nakikinig sa 0.0.0.0 kahit ang kailangan mo ay 127.0.0.1. Dito nagiging kapaki-pakinabang ang model, pero dito rin ito nagkakamali: kapag hiniling mong ayusin ang isang directive, madalas nitong ibinabalik ang buong file na may tahimik na nawawalang dalawa sa iyong directives. Hilingin ang binagong mga linya at ang dahilan ng bawat pagbabago, pagkatapos ay manu-mano itong i-edit.

Kumpirmahin kung ano talaga ang inilantad mo:

sudo ss -tulpn

Kung wala ang sudo, makikita mo ang listening sockets pero hindi ang mga process na nagmamay-ari sa mga ito. Kung nakakagulat ang output na iyon, mas maikli ang basahin na kung ano ang ports at kung paano ito bina-bind ng Linux.

Trabaho 4: ipaliwanag muna ang hindi pamilyar na command bago ito patakbuhin

I-paste ang command at magtanong ng apat na bagay tungkol dito: ano ang ginagawa ng bawat flag, ano ang sinusulat nito, ano ang binubura nito, at ano ang mangyayari kung patakbuhin ko ito nang dalawang beses. Mas maraming damage ang naiiwasan ng huling tanong kaysa sa iba.

Tingnan ang find /var/log -name '*.gz' -mtime +7 -delete. Dapat ipaliwanag ng magandang sagot na binibilang ng -mtime +7 ang kumpletong 24 hour period at itinatapon ang fraction, kaya tumutugma ito sa mga file na hindi bababa sa walong araw na ang edad, hindi pitong araw. Dapat ding sabihin nito na sinusuri ng find ang expression nito mula kaliwa pakanan, kaya kapag inilagay ang -delete bago ang -name, buburahin nito ang lahat sa ilalim ng starting path. Nasa find man page ang ikalawang puntong ito bilang babala, at naging sanhi na ito ng pagkawala ng /var/log ng mga tao.

O tingnan ang rsync -a --delete /srv/app/ /backup/app/. Ibig sabihin ng trailing slash sa source ay “ang laman ng directory na ito”. Kapag inalis mo ito, makukuha mo ang /backup/app/app/. Kapag idinagdag ang --delete, aalisin ang anumang nasa destination na wala sa source. Tama ito para sa isang mirror, pero magiging disaster kapag mali ang source path.

I-verify gamit ang tool, hindi gamit ang model:

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

Patakbuhin ang find nang walang -delete at makakakuha ka ng listahan sa halip na pagkawala ng data.

Failure mode: hallucination ng flag. Maaasahan ang model sa mga tool na may tatlumpung taon nang documentation, pero mas mahina ito sa vendor CLI (command line interface) at mga bagong subcommand, kung saan gumagawa ito ng flag na mukhang tama ngunit hindi naman umiiral. Tinutukoy ito ng --help sa loob ng isang segundo. Isa pang mahina nitong bahagi ang quoting, kaya kapag gumagamit ang isang command ng $(...) expression, basahin ang kung paano nag-e-expand ang command substitution bago tumakbo ang command sa halip na basta umasa sa paliwanag.

Job 5: gawing runbook ang shell history mo

Dalawang oras mong inayos ang isang bagay para gumana ito. Nasa scrollback ang kaalamang iyon, at mawawala ito sa susunod na buwan.

history 200 > /tmp/session.txt

Basahin ang file na iyon at tanggalin ang bawat linyang may password, token, o customer identifier bago ito mapunta kung saanman. Isa ang shell history sa mga pinaka-maaasahang lugar para maghanap ng secret sa Linux box, dahil kahit minsan ay may nagta-type nito nang inline. I-set ang HISTCONTROL=ignorespace sa ~/.bashrc mo, at ang command na tina-type na may leading space ay hindi na talaga isinusulat sa history.

Ang prompt na gumagawa ng kapaki-pakinabang na runbook ay humihingi ng mga check, hindi lamang ng mga hakbang:

Isa itong shell session na nagdala sa isang bagong Debian 13 box sa gumaganang Postgres install. Isulat ito bilang numbered runbook. Isang command bawat hakbang. Pagkatapos ng bawat hakbang, ibigay ang command na nagpapatunay na gumana ito at ilarawan kung ano ang hitsura ng healthy output. Markahan ang bawat hakbang na nakadepende sa partikular kong host.

Failure mode: maayos na kuwento. May hakbang sa session mo na dalawang beses mong nagawa nang mali bago mo ito naayos, at iyon ang hakbang na pinapakinis ng model, dahil mas malinis basahin ang transcript kung wala ito. Ihambing ang runbook sa history mo at ibalik ang correction. Nag-iimbento rin ito ng mga mukhang makatwirang verification command, kaya patakbuhin ang bawat check na isinulat nito bago mo i-save ang file. Kung saklaw ng runbook ang first boot, basahin ito kasabay ng unang sampung minuto sa bagong VPS para hindi ka makapagsulat ng mas masamang bersyon ng problemang nalutas na.

Gawain 6: gawing fix ang isang error message

I-paste ang eksaktong string, ang command na gumawa nito, at ang nag-iisang bagay na binago mo bago ito lumitaw. Humingi ng naka-rank na mga sanhi at tig-isang command para sa bawat isa na makapaghihiwalay sa mga ito. Dahil dito, nagiging nasusuri ang sagot.

nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use). I-rank ang malamang na mga sanhi at magbigay ng tig-isang command para sa bawat sanhi na kumukumpirma o nag-aalis dito.

Para sa error na iyon, malinaw ang mekanismo: may ibang process na gumagamit na ng port 80, at tinutukoy ito ng sudo ss -tulpn | grep ':80 '. Kadalasan, isa itong ikalawang nginx master na naiwan matapos mabigong mag-reload, o Apache na naisama bilang dependency at sinimulan ng sarili nitong package.

Failure mode: isang fix na gumagana sa pamamagitan ng pagtatago sa sanhi. Ang chmod 777, --privileged, pag-disable sa SELinux, at pagpapatakbo ng service bilang root ay pawang nagpapawala sa error. Tanggihan ang anumang fix na nagpapaluwag ng permissions hanggang maipaliwanag ng model kung bakit nabigo ang mas limitadong permission. Ang paliwanag na iyon ang aktuwal na sagot. Pinapatahimik lamang ng workaround ang error.

Mga bagay na palaging mali

• Hindi nito nakikita ang server mo. Nakabatay ang bawat sagot sa ipinasa mong content, at hindi nito sasabihin kung masyadong maikli ang excerpt.
• Nagkakamali ito sa mga version. Nagbabago ang mga pangalan ng package at default flag depende sa distribution at release, at nag-a-average ang model sa lahat ng ito.
• Maayos itong magsalita kahit mali. Ang isang inimbentong mekanismo ay maaaring basahin na parang tama, kaya bawat cause sa itaas ay may command na sumusubok dito.
• Nawawala ang konteksto sa mahahabang session. Ang mga impormasyong nasa simula ng dalawang oras na conversation ay hindi na nakaaapekto sa mga sagot sa hulihan.

Mas praktikal na problema ang huli kaysa problema ng model, at ang praktikal na solusyon ay pamamahala ng context sa isang mahabang Claude Code session: mas maiikling session, tig-iisang task.

Ang paglalagay ng agent mismo sa server

Copy-and-paste lamang ang lahat ng nasa itaas, kaya hindi naa-access ng model ang machine mo. Kapag tumatakbo na ito sa server at nakakabasa ng mga file at nakakapagpatupad ng mga command, nagbabago ang uri ng panganib: ang maling command ay maaaring magpatigil ng isang service. Gumawa ng sarili nitong unprivileged user sa halip na gamitin ang root, huwag muna itong patakbuhin sa production box habang inaalam mo ang mga gawi nito, at gumawa muna ng snapshot. Sinasaklaw ng Ligtas na pagpapatakbo ng Claude Code sa isang VPS ang sandboxing at permission model. Nilulutas naman ng Pagpapatakbo ng Claude Code sa loob ng tmux ang kabilang problema, dahil kapag naputol ang SSH (secure shell) session, namamatay ang foreground agent habang isinasagawa nito ang trabaho. I-set up ang account gaya ng pag-set up mo ng anumang service account, na detalyadong ipinapaliwanag sa mga user na may least privilege sa isang VPS.

FAQ

Mababasa ba ni Claude nang direkta ang server logs ko?

Hindi nang mag-isa. Nakikita lamang ng chat interface ang text na ipinapaste mo rito. Ang Claude Code, kapag pinatakbo sa server bilang command line tool, ay makakabasa ng mga file at makakapagpatakbo ng mga command gamit ang permissions ng user na nag-start nito, kaya mas malaking trust decision ito. Para sa karaniwang support question, mas mabilis at mas ligtas ang pag-paste ng redacted na 100-line excerpt kaysa bigyan ang agent ng shell access.

Ano ang hindi ko dapat kailanman i-paste mula sa server?

Mga private key, .env files at iba pang credential store, /etc/shadow, at anumang data na pagmamay-ari ng iyong mga user. I-redact ang mga token mula sa log excerpts bago makarating ang mga ito sa prompt. Isang hindi agad halatang kaso: naka-interpolate sa output ng docker compose config ang iyong .env values, kaya gamitin ang docker compose config -q, na nagva-validate sa file at walang ipiniprint.

Ligtas bang payagan si Claude na magpatakbo ng mga command sa isang production VPS?

Ituring ito na parang bagong admin na walang context: ayos lang para sa pagbabasa, pero kailangan ng review para sa pagsusulat. Sa production, hingin ang paliwanag at ikaw mismo ang magpatakbo ng command. Kung gusto mong may agent na mag-execute, bigyan ito ng dedicated unprivileged account na walang blanket sudo, at magsimula sa staging box kung saan ang pagkakamali ay magreresulta sa rebuild sa halip na outage.

Bakit nagmumungkahi si Claude ng flag na hindi naman umiiral?

Dahil hinuhulaan nito ang posibleng text, at pareho ang hitsura ng isang posibleng flag at ng totoong flag. Pinakamadalas itong mangyari sa vendor CLI at mas bagong subcommand, kung saan limitado o nagbago na ang documentation na nasa likod ng model. Ang --help at man ang arbiter, at anumang command na nagde-delete o nag-o-overwrite ay dapat munang patakbuhin sa dry run.

Paano ko susuriin ang isang systemd unit bago ko ito i-enable?

Patakbuhin ang sudo systemd-analyze verify /etc/systemd/system/myapp.service. Ipa-parse nito ang file gamit ang sariling parser ng systemd, iuulat ang mga unknown directive kasama ang line number ng mga ito, at magfa-flag ng ExecStart binary na nawawala o hindi executable. Pagkatapos, patakbuhin ang daemon-reload, start, at basahin ang systemctl status bago mo ito enable, dahil maaaring ma-load nang maayos ang isang unit pero mabigo pa rin sa unang pag-run nito.