Claude para sa Sysadmin: 6 Gawain sa Linux Server

Claude para sa mga sysadmin: payo muna, execution pagkatapos

Pinakamahusay gamitin ang Claude bilang reviewer ng mga sysadmin. Mag-paste ka ng bahagi ng log, configuration 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 mawawala sa iyo kapag mali ang sagot hanggang sa patakbuhin mo ito. 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). Para sa bawat isa sa ibaba, may gumaganang prompt pattern, command na nagpapatunay sa sagot, at failure mode na dapat mong asahan. Hindi kailangan ng alinman sa mga ito na magkaroon ng access ang model sa server mo. Maaari kang mag-paste mula sa browser tab o mula sa window sa sarili mong desktop, dahil native na tumatakbo ang Claude sa Linux bilang desktop app at CLI.

Mahalaga ang pagkakasunod-sunod sa isang production box: basahin ang paliwanag, ikaw mismo ang magpatakbo ng check, saka magpasya. Ayos ang autonomy sa isang scratch VM. Sa server na nagsisilbi sa mga customer mo, mas mainam ang pagsusuri dahil hindi nakikita ng model ang aktuwal na state na hinuhulaan nito.

Mga bagay na hindi mo dapat kailanman i-paste

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 password ng database sa anumang file o linya ng log.
• Data ng account: /etc/shadow at /etc/gshadow. Walang sysadmin question na nangangailangan ng password hash para masagot.
• Anumang pag-aari ng mga user mo: mga email address, order row, request log na may session cookie o PII (personally identifiable information).

Ligtas i-paste ang mga public key. Hindi ligtas ang mga 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 basahin ang Pagpapanatiling maayos ng iyong SSH key material.

Mag-redact bago mag-paste, sa halip na umasa sa sarili mong matutukoy ang isang token sa loob ng 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 panganib sa Docker. Ini-interpolate ng docker compose config ang iyong mga value ng .env sa output na ipinapakita nito. Dahil dito, secret ang output kahit hindi secret ang file sa disk. Gamitin ang docker compose config -q, na nagva-validate at walang ipinapakitang output. Para sa mas malawak na policy tungkol sa mga bagay na maaaring makita ng isang agent, ipinapaliwanag ng Pag-iwas na mailantad ang mga secret sa AI agent ang tungkol sa environment.

Job 1: bakit nag-fail ang service?

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 mag-fail ito. Unahin mong itanong ang mekanismo.

Ubuntu 24.04. myapp.service ay gumagana 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.

Mahalaga ang “Wala munang fix” sa prompt na ito. Itinatago ng mga log ang unang failure sa ilalim ng mga retry na idinulot nito, kaya kapag fix ang hiniling sa model, ipaliliwanag nito ang huling linyang nakita nito. Karaniwan, ang mahalagang linya ay nasa dalawampung linya bago ang ingay.

Ang makukuha mong resulta ay isang linyang gaya ng Main PID: 1841 (code=exited, status=203/EXEC). Ang exit status na 203/EXEC ay nangangahulugang hindi na-execute ng kernel ang file na nakasaad sa ExecStart: maaaring hindi umiiral ang path, o umiiral ang file ngunit hindi ito executable. Ang #! line na tumutukoy sa interpreter na hindi naka-install ay nagbubunga rin ng parehong status. Masusuri ang lahat ng ito gamit ang ls -l at head -1.

Failure mode: inimbentong sanhi. Kapag kulang ang iyong i-paste, pupunan ng model ang puwang gamit ang generic na paliwanag, gaya ng “ginagamit na ng ibang process ang port”. Ang tamang hakbang ay magtanong pabalik: “Aling linya sa ibinigay ko ang sumusuporta rito?” Ang sanhi na walang matutukoy na batayan sa text ay hula lamang.

Trabaho 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 na may non-zero status. 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

systemd-analyze verify ang nagpa-parse sa file ayon sa paraan ng pag-parse ng systemd, kaya nahuhuli nito ang mga detalyeng maaaring hindi mapansin ng tao. Kapag mali ang spelling ng directive, nagpi-print ito ng /etc/systemd/system/myapp.service:7: Unknown key name 'Enviroment' in section 'Service', ignoring.. Kapag walang binary, nagpi-print ito ng Command /usr/local/bin/myapp is not executable: No such file or directory. Pareho itong walang output habang nasa daemon-reload, kaya maaaring ma-load nang maayos ang unit ngunit mabigo agad kapag pinatakbo.

Dalawang pagkakamali sa paggawa ng draft ang paulit-ulit na lumilitaw. Ang una ay After=network.target, na nangangahulugang naka-configure ang network stack, pero hindi nito pinatutunayang may address na. Kapag nag-bind ang service sa isang partikular na IP, mabibigo ito sa boot na may bind: Cannot assign requested address. Ang ayos ay Wants=network-online.target kasama ng After=network-online.target. Ang ikalawa ay Type=simple para sa program na nag-daemonise: itinuturing ng systemd na service ang unang process, agad na nag-e-exit ang parent, at minamarkahan ang unit bilang patay habang patuloy na tumatakbo ang totoong process nang walang pamamahala. Ito ang pagkakamaling malamang ibigay sa iyo ng isang model, dahil hindi nito matutukoy mula sa command kung nagfa-fork ang binary. Kaya mahalagang alamin ang pangako ng bawat Type= value sa systemd bago mo tanggapin ang draft.

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

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

Pi-print nito ang normalized form 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, ipinapaliwanag ng systemd services at timers sa isang VPS ang mga trade-off.

May trap ang Cron na hindi babalaan sa iyo ng model maliban kung itanong mo. Pinapatakbo ng Cron ang mga job gamit ang minimal environment, 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 na may /bin/sh: 1: docker: not found, dahil nasa /usr/local/bin ang binary na iyon. Gumamit ng absolute path sa crontab. Kung ang paggiit ng unit file na tahasang ilagay ang user, environment, at dependencies ay parang seremonya kumpara sa isang linya ng crontab, ipinapaliwanag ng mga problemang nilikha para lutasin ng systemd kung saan nagmula ang ganitong kalawak na configuration.

Gawain 3: suriin ang nginx o Compose file bago ito i-deploy

Pinakamalaki ang balik ng gawaing ito. I-paste ang file, sabihin kung ano ang dapat nitong gawin, at hilingin ang paliwanag sa bawat linya tungkol sa aktuwal nitong ginagawa.

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 iyon.

Pagkatapos, patakbuhin ang tool na nakakaalam ng grammar:

sudo nginx -t
docker compose config -q

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

Wala sa alinmang tool ang sumusuri sa intent. Maaaring pumasa sa nginx -t ang isang config ngunit nagpo-proxy pa rin sa maling port, o nakikinig sa 0.0.0.0 kahit 127.0.0.1 ang kailangan mo. Dito nagiging kapaki-pakinabang ang model, ngunit dito rin ito nagkakamali: kapag hiniling na ayusin ang isang directive, madalas nitong ibinabalik ang buong file na nirewrite at tahimik na nawawala ang dalawa sa iyong directive. Hilingin ang mga binagong linya at ang dahilan para sa bawat isa, pagkatapos ay manu-manong i-edit.

Kumpirmahin kung ano talaga ang inilantad mo:

sudo ss -tulpn

Kung wala ang sudo, makikita mo ang listening sockets ngunit hindi ang mga process na nagmamay-ari sa mga ito. Kung nakakagulat ang output na iyon, mas maikli ang paliwanag tungkol sa mga port at kung paano ito bina-bind ng Linux.

Gawain 4: Ipaliwanag 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 isinusulat nito, ano ang binubura nito, at ano ang mangyayari kung patakbuhin ko ito nang dalawang beses. Mas maraming pinsala ang nahuhuli ng huling tanong kaysa sa iba.

Isaalang-alang ang find /var/log -name '*.gz' -mtime +7 -delete. Dapat sabihin sa iyo ng isang mahusay na sagot na binibilang ng -mtime +7 ang buong 24-hour period at itinatapon ang natitirang bahagi, kaya tumutugma ito sa mga file na hindi bababa sa walong araw na ang edad, hindi pitong araw. Dapat sabihin din nito na sinusuri ng find ang expression mula kaliwa pakanan, kaya kapag inilipat ang -delete bago ang -name, binubura 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 maraming tao.

O isaalang-alang ang rsync -a --delete /srv/app/ /backup/app/. Ang trailing slash sa source ay nangangahulugang “mga 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, ngunit magiging malaking pinsala kapag mali ang source path.

I-verify ito 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 wala ang -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 taong dokumentasyon, ngunit mas mahina ito sa vendor CLI (command line interfaces) at mga bagong subcommand. Gumagawa ito ng flag na mukhang tama ngunit hindi naman umiiral. Agad itong napatutunayan ng --help. Isa pang karaniwang problema ang quoting. Kaya kapag gumagamit ang isang command ng $(...) expression, basahin ang kung paano ine-expand ang command substitution bago patakbuhin ang command sa halip na basta umasa sa paliwanag.

Gawain 5: gawing runbook ang shell history

Dalawang oras ang ginugol mo para mapagana ang isang bagay. 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 naglalaman ng password, token, o identifier ng customer bago ito mapunta sa iba. Ang shell history ang isa sa mga pinaka-maaasahang lugar para maghanap ng secret sa isang Linux box, dahil kahit minsan ay may nagta-type ng isa nang inline. Itakda ang HISTCONTROL=ignorespace sa iyong ~/.bashrc, at ang command na tina-type na may leading space ay hindi talaga isusulat sa history.

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

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

Failure mode: isang malinis na kuwento. May step sa session mo na dalawang beses mong nagawang mali bago ito naayos, at iyon ang step na pinapakinis ng model dahil mas malinis basahin ang transcript kapag 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 upang hindi ka magsulat ng mas masamang bersyon ng problemang nalutas na.

Gawain 6: gawing solusyon ang isang error message

I-paste ang eksaktong string, ang command na nagproduce nito, at ang nag-iisang bagay na binago mo bago ito lumitaw. Humingi ng mga posibleng sanhi na naka-ranggo, kasama ang isang command para sa bawat sanhi na magpapatunay o mag-aalis dito. Sa ganitong paraan, nagiging masusuri ang sagot.

nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use). I-ranggo ang mga posibleng sanhi at magbigay ng isang command sa bawat sanhi na magpapatunay o mag-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, ito ay pangalawang nginx master na naiwan matapos mabigo ang reload, o Apache na isinama 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 nagpapalawak ng permissions hangga't hindi naipapaliwanag kung bakit nabigo ang mas limitadong permission. Ang paliwanag na iyon ang aktuwal na sagot. Pinapatahimik lamang ng workaround ang error.

Madalas nitong nagagawa nang mali

• Hindi nito nakikita ang server mo. Nakabatay ang bawat sagot sa inilagay mong text, at hindi nito sasabihing masyadong maikli ang excerpt.
• Hindi ito pare-pareho sa mga version. Nagbabago ang mga package name at default flag sa bawat distribution at release, at pinaghahalo ng model ang impormasyon mula sa lahat ng ito.
• Mabilis itong sumagot kahit mali. Ang gawa-gawang mekanismo ay maaaring magmukhang eksaktong tama, kaya may command na sumusubok sa bawat sanhi sa itaas.
• Nawawala ang konteksto nito sa mahahabang session. Ang mga impormasyong nasa simula ng dalawang oras na pag-uusap ay hindi na nakaaapekto sa mga sagot sa dulo.

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

Agent sa mismong server

Copy at paste ang lahat ng nasa itaas, kaya hindi naa-access ng model ang iyong machine. Kapag tumatakbo na ito sa server at nagbabasa ng mga file at nagpapatupad ng mga command, nagbabago ang uri ng panganib: maaaring mawalan ka ng isang service dahil sa maling command. Gumawa ng sarili nitong unprivileged user sa halip na gamitin ang root, huwag muna itong patakbuhin sa production server 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 napuputol ng nawawalang SSH (secure shell) session ang foreground agent habang isinasagawa nito ang trabaho. I-configure ang account na parang service account ang ginagawa mo; malinaw itong inilalarawan sa mga user na may least privilege sa isang VPS.

FAQ

Mababasa ba ni Claude nang direkta ang mga server log ko?

Hindi, hindi nito magagawa 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 nagpasimula nito. 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 isang server?

Mga private key, mga .env file 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 excerpt bago ito makarating sa prompt. May isang hindi gaanong halatang kaso: ang output ng docker compose config ay may naka-interpolate na .env values, kaya gamitin ang docker compose config -q, na nagva-validate sa file at walang ini-print.

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

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

Bakit nagmumungkahi si Claude ng flag na hindi naman umiiral?

Dahil nagpe-predict ito ng posibleng text, at pareho ang hitsura ng isang posibleng flag at totoong flag. Pinakamadalas itong mangyari sa vendor CLI at mas bagong subcommand, kung saan limitado ang documentation na nasa model o nagbago na ito. Ang --help at man ang arbiter, at ang anumang command na nagde-delete o nag-o-overwrite ay dapat munang patakbuhin bilang 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. Pina-parse nito ang file gamit ang sariling parser ng systemd, iniuulat ang unknown directive kasama ang line number ng mga ito, at tina-flag ang 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 ngunit mabigo pa rin sa unang pag-run nito.