సిస్టమ్ అడ్మిన్ల కోసం Claude: రోజువారీ server పనులు

సిస్టమ్ అడ్మినిస్ట్రేటర్ల కోసం Claude: ముందుగా సలహా, తరువాత అమలు

Claude ను సిస్టమ్ అడ్మినిస్ట్రేటర్‌గా ఉపయోగించినప్పుడు, అది reviewer గా పనిచేసినపుడే ఉత్తమ ఫలితాలు ఇస్తుంది. మీరు log లోని కొంత భాగం, config file, మీకు తెలియని command లేదా error string ను ఇస్తే, server లో ఏదైనా మార్చే ముందు మీరు ధృవీకరించగల వివరణను అది అందిస్తుంది. మీరు ఆ సూచనను అమలు చేసే వరకు తప్పు సమాధానం వల్ల ఎటువంటి నష్టం జరగదు. అందువల్ల model ను సలహా పరిధిలోనే ఉంచడం మొత్తం భద్రతా విధానానికి ఆధారం.

అద్దె Linux VPS (virtual private server)లో ప్రతి వారం తరచుగా ఎదురయ్యే ఆరు పనులు ఉన్నాయి. కింద ప్రతి పనికి పనిచేసే prompt నమూనా, సమాధానాన్ని నిర్ధారించే command, అలాగే మీరు ఆశించాల్సిన వైఫల్య విధానం ఇవ్వబడ్డాయి. వీటిలో ఏ పనికీ model కు మీ server పై access అవసరం లేదు. మీరు browser tab లేదా మీ స్వంత desktop లోని window నుంచి సమాచారాన్ని paste చేయవచ్చు, ఎందుకంటే Claude Linux లో desktop app మరియు CLI రెండింటిగానూ స్థానికంగా నడుస్తుంది.

Production boxలో ఈ క్రమం ముఖ్యం: ముందుగా వివరణ చదవండి, check ను మీరే అమలు చేయండి, తరువాత నిర్ణయం తీసుకోండి. Scratch VMలో autonomy సరైనదే. మీ customers కు సేవలందించే boxలో review కు ప్రాధాన్యం ఇవ్వాలి, ఎందుకంటే model తాను ఊహిస్తున్న వ్యవస్థ స్థితిని చూడలేడు.

మీరు ఎప్పటికీ paste చేయకూడనివి

Prompt లోని మొత్తం సమాచారం మీ server ను విడిచిపెడుతుంది. ఈ నాలుగు వర్గాల సమాచారం server లోనే ఉండాలి:

• Private keys: ~/.ssh/id_ed25519, /etc/ssh/ssh_host_*_key, అలాగే /etc/letsencrypt/live/ కింద ఉన్న ఏదైనా TLS (transport layer security) key.
• Credential files: .env, ~/.aws/credentials, /root/.docker/config.json, అలాగే ఏదైనా file లేదా log line లోని database passwords.
• Account data: /etc/shadow మరియు /etc/gshadow. ఏ sysadmin ప్రశ్నకు సమాధానం ఇవ్వడానికి password hash అవసరం లేదు.
• మీ users కు చెందిన ఏదైనా సమాచారం: email addresses, order rows, session cookies లేదా PII (personally identifiable information) కలిగిన request logs.

Public keys ను paste చేయడం సురక్షితం. Private keys ను paste చేయకూడదు. ఈ రెండు files మొదటి చూపులో ఒకేలా కనిపించవచ్చు. అందువల్ల copy చేసే ముందు మొదటి line చదవండి: మొదటి line లో BEGIN OPENSSH PRIVATE KEY ఉన్న file ను prompt లో ఎప్పటికీ చేర్చకండి. మీ SSH key material ను సరిగ్గా వేరు చేసుకోవడం కోసం పది నిమిషాలు కేటాయించడం ప్రయోజనకరం.

200 lines లోని ఒక్క token ను గుర్తించగలనని మీపై మీరు ఆధారపడకుండా, paste చేసే ముందు సమాచారాన్ని redact చేయండి:

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

Docker కు సంబంధించిన ఒక ప్రత్యేక ప్రమాదం ఉంది. docker compose config మీరు ఇచ్చిన .env values ను తాను print చేసే output లోకి interpolate చేస్తుంది. అందువల్ల disk లోని file లో secret లేకపోయినా, ఆ output secret అవుతుంది. ఏదీ validate చేసి print చేయని docker compose config -q ను ఉపయోగించండి. Agent ఏమి చూడటానికి అనుమతించబడుతుందనే విస్తృత విధానం కోసం, AI agents నుండి secrets ను దూరంగా ఉంచడం environment స్థాయిలోని అంశాలను వివరిస్తుంది.

పని 1: ఈ సేవ ఎందుకు విఫలమైంది?

సమాధానం ఉన్న రెండు commands తో ప్రారంభించండి:

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

వాటిని రెండింటినీ paste చేయండి. Model ఊహించలేని context కూడా ఇవ్వండి: distribution మరియు version, మీరు చివరిగా మార్చిన విషయం, ఈ సేవ ఎప్పుడైనా సరిగ్గా పనిచేసిందా, అది విఫలమై ఎంత సమయం అయింది. ముందుగా కారణ విధానాన్ని వివరించమని అడగండి.

Ubuntu 24.04. myapp.service ను ఒక గంట క్రితం unit edit చేసే వరకు సరిగ్గా పనిచేసింది. systemctl status మరియు చివరి 100 journal lines ఇవి. మొదటి నిజమైన error ఏ line లో ఉంది, దాని అర్థం ఏమిటి? ఇప్పటికైతే పరిష్కారం చెప్పవద్దు.

ఈ prompt లో "ఇప్పటికైతే పరిష్కారం చెప్పవద్దు" అనే సూచన ముఖ్యమైన పని చేస్తుంది. Retryల కారణంగా ఏర్పడిన errors మొదటి failure ను logs లో కప్పివేస్తాయి. Fix అడిగితే model సాధారణంగా తాను చూసిన చివరి line ను వివరిస్తుంది. సాధారణంగా ముఖ్యమైన line noise కు ఇరవై lines ముందు ఉంటుంది.

దీని ప్రయోజనం Main PID: 1841 (code=exited, status=203/EXEC) వంటి line ను గుర్తించడంలో కనిపిస్తుంది. Exit status 203/EXEC అంటే ExecStart లో పేర్కొన్న file ను kernel execute చేయలేకపోయిందని అర్థం. Path ఉనికిలో లేకపోవచ్చు, లేదా file ఉన్నప్పటికీ executable కాకపోవచ్చు. ఇన్‌స్టాల్ చేయని interpreter ను పేర్కొనే #! line కూడా ఇదే status ను ఉత్పత్తి చేస్తుంది. వీటన్నింటినీ ls -l మరియు head -1 తో పరీక్షించవచ్చు.

విఫలమయ్యే విధానం: ఊహించిన కారణం. చాలా తక్కువ సమాచారం paste చేస్తే model ఖాళీని "port ఇప్పటికే ఉపయోగంలో ఉంది" వంటి సాధారణ కారణంతో నింపుతుంది. దీనికి పరిష్కారం, ఒక ప్రశ్నను తిరిగి అడగడం: "నేను ఇచ్చిన సమాచారంలో ఏ line దీనికి ఆధారం?" Text లో ఎవరూ చూపించలేని కారణం కేవలం ఊహ మాత్రమే.

Job 2: systemd unit లేదా cron entry ను రూపొందించండి

Unit file కు అవసరమైన వివరాలను ఇవ్వండి: ఖచ్చితమైన command, అది ఏ user గా నడవాలి, working directory, network కోసం వేచి ఉండాలా, అలాగే అది non-zero తో exit అయినప్పుడు ఏమి జరగాలి. తరువాత ఏదైనా enable చేయడానికి ముందు వచ్చిన ఫలితాన్ని ధృవీకరించండి.

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 systemd ఎలా చేస్తుందో అదే విధంగా file ను parse చేస్తుంది. అందువల్ల మానవ దృష్టికి కనిపించకుండా పోయే పొరపాట్లను కూడా ఇది గుర్తిస్తుంది. తప్పుగా వ్రాసిన directive కు /etc/systemd/system/myapp.service:7: Unknown key name 'Enviroment' in section 'Service', ignoring. ముద్రిస్తుంది. binary కనిపించకపోతే Command /usr/local/bin/myapp is not executable: No such file or directory ముద్రిస్తుంది. daemon-reload సమయంలో ఈ రెండూ ఎలాంటి సందేశం ఇవ్వవు. అందుకే unit సరిగ్గా load అయినప్పటికీ, అమలు చేసిన వెంటనే విఫలమవుతుంది.

రూపకల్పనలో రెండు పొరపాట్లు మళ్లీ మళ్లీ కనిపిస్తాయి. మొదటిది After=network.target. దీనర్థం network stack configure అయిందని మాత్రమే; ఇంకా address అందుబాటులో ఉందని కాదు. ఒక నిర్దిష్ట IP కు bind అయ్యే service boot సమయంలో bind: Cannot assign requested address తో విఫలమవుతుంది. దీనికి పరిష్కారం Wants=network-online.target తో పాటు After=network-online.target. రెండవది daemonise అయ్యే program కోసం Type=simple ఉపయోగించడం. systemd మొదటి process నే service గా పరిగణిస్తుంది. parent వెంటనే exit అవుతుంది. నిజమైన process నిర్వహణ లేకుండా నడుస్తూనే ఉండగా unit dead గా గుర్తించబడుతుంది. మీ command చూసి binary fork అవుతుందో లేదో model గుర్తించలేడు. అందువల్ల draft ను అంగీకరించే ముందు ప్రతి Type= value systemd కు ఏమి హామీ ఇస్తుందో తెలుసుకోవడం ఉపయోగకరం.

Schedule కోసం దాన్ని చదవకుండా పరీక్షించండి:

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

ఇది normalized form ను, అలాగే expression తదుపరి సారి అమలయ్యే సమయాన్ని ముద్రిస్తుంది. దాని అర్థంపై ఉన్న సందేహాన్ని ఇది నివృత్తి చేస్తుంది. timer మరియు crontab మధ్య ఎంచుకుంటే, VPS లో systemd services మరియు timers వాటి మధ్య తేడాలను వివరిస్తుంది.

మీరు అడగకపోతే ఏ model హెచ్చరించని ఒక trap Cron లో ఉంది. Cron jobs ను minimal environment తో నడుపుతుంది. అందువల్ల PATH దాదాపు /usr/bin:/bin గా ఉంటుంది. మీ shell profile ఎప్పుడూ చదవబడదు. Terminal లో paste చేసినప్పుడు పనిచేసే job, cron కింద /bin/sh: 1: docker: not found తో విఫలమవుతుంది. కారణం ఆ binary /usr/local/bin లో ఉంటుంది. crontab లో absolute paths ఉపయోగించండి. ఒకే crontab line తో పోలిస్తే user, environment, dependencies ను స్పష్టంగా పేర్కొనాలని unit file పట్టుబట్టడం అవసరం లేని ఆచారంలా అనిపిస్తే, systemd పరిష్కరించడానికి రూపొందించబడిన సమస్యలు ఆ verbosity ఎలా ఏర్పడిందో వివరిస్తాయి.

Job 3: nginx లేదా Compose file ను production లోకి పంపే ముందు పరిశీలించండి

ఈ పనికి అత్యధిక ప్రయోజనం ఉంటుంది. File ను paste చేసి, అది ఏమి చేయాలి అనేది వివరించండి. అది వాస్తవంగా ఏమి చేస్తుందో line by line వివరించమని అడగండి.

ఈ vhost HTTPS ద్వారా example.com ను అందించాలి. అలాగే /api ను port 8080 పై ఉన్న local service కు proxy చేయాలి. దీన్ని నాకు తిరిగి వివరించి, ఈ వివరణతో సరిపోని అంశాలను పేర్కొనండి.

తరువాత grammar ను అర్థం చేసుకునే tool ను అమలు చేయండి:

sudo nginx -t
docker compose config -q

nginx -t, nginx: configuration file /etc/nginx/nginx.conf test is successful ను ప్రింట్ చేస్తుంది. లేదా nginx: [emerg] unknown directive "proxy_pas" in /etc/nginx/conf.d/app.conf:12 లో ఉన్నట్లుగా file name మరియు line number ను చూపిస్తుంది. File parse అయినప్పుడు docker compose config -q ఏమీ ప్రింట్ చేయదు. Indentation తప్పితే yaml: line 7: did not find expected key వంటి స్పష్టమైన error ను చూపిస్తుంది.

ఏ tool కూడా intent ను పరిశీలించదు. nginx -t ను విజయవంతంగా దాటిన config, తప్పు port కు proxy చేయవచ్చు. మీరు 127.0.0.1 అనుకున్నప్పుడు అది 0.0.0.0 పై listen చేయవచ్చు. Model ఉపయోగకరంగా ఉండేది ఈ తేడాను గుర్తించడంలోనే. అయితే ఇదే చోట అది విఫలమవుతుంది కూడా. ఒక directive ను మాత్రమే సరిచేయమని అడిగితే, అది తరచుగా మొత్తం file ను తిరిగి రాస్తుంది. అందులో మీ directives లో రెండు నిశ్శబ్దంగా తొలగిపోవచ్చు. మార్చిన lines మరియు ప్రతి మార్పుకు కారణాన్ని అడగండి. తరువాత చేతితో edit చేయండి.

మీరు వాస్తవంగా ఏవి expose చేశారో నిర్ధారించండి:

sudo ss -tulpn

sudo లేకుండా listening sockets మాత్రమే కనిపిస్తాయి. వాటిని కలిగి ఉన్న processes కనిపించవు. ఆ output ఊహించనిదిగా ఉంటే, ports అంటే ఏమిటి, Linux వాటిని ఎలా bind చేస్తుంది అనే సంక్షిప్త వివరణను చదవండి.

పని 4: పరిచయం లేని command ను అమలు చేయడానికి ముందు దాన్ని వివరించండి

ఆ command ను paste చేసి, దాని గురించి నాలుగు ప్రశ్నలు అడగండి: ప్రతి flag ఏమి చేస్తుంది, అది ఏమి రాస్తుంది, ఏమి తొలగిస్తుంది, దాన్ని రెండుసార్లు అమలు చేస్తే ఏమి జరుగుతుంది. మిగిలిన ప్రశ్నలకన్నా చివరి ప్రశ్న ఎక్కువ నష్టాన్ని గుర్తిస్తుంది.

find /var/log -name '*.gz' -mtime +7 -delete ను పరిశీలించండి. మంచి సమాధానం -mtime +7 పూర్తి 24 గంటల కాలాలను లెక్కించి, మిగిలిన భాగాన్ని తొలగిస్తుందని చెబుతుంది. అందువల్ల ఇది ఏడు రోజుల కంటే కనీసం ఎనిమిది రోజుల పాత files కు సరిపోతుంది. అలాగే find తన expression ను ఎడమ నుంచి కుడికి evaluate చేస్తుందని కూడా చెబుతుంది. కాబట్టి -delete ను -name ముందు ఉంచితే, ప్రారంభ path కింద ఉన్న ప్రతిదీ తొలగిపోతుంది. ఈ రెండవ విషయం find man page లో warning గా ఉంది. దీని వల్ల కొందరు తమ /var/log కోల్పోయారు.

rsync -a --delete /srv/app/ /backup/app/ ను కూడా పరిశీలించండి. source చివర ఉన్న slash అంటే “ఈ directory లోని contents” అని అర్థం. దాన్ని తీసివేస్తే /backup/app/app/ లభిస్తుంది. --delete ను జోడిస్తే source లో లేని destination లోని ప్రతిదీ తొలగించబడుతుంది. Mirror కోసం ఇది సరైనదే, కానీ source path తప్పుగా ఉంటే ఇది తీవ్రమైన నష్టానికి దారితీస్తుంది.

Model తో కాకుండా tool తో verify చేయండి:

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

find ను -delete లేకుండా అమలు చేస్తే, నష్టం కలగకుండా list లభిస్తుంది.

విఫలమయ్యే విధానం: flag hallucination. ముప్పై సంవత్సరాల documentation ఉన్న tools విషయంలో model సాధారణంగా నమ్మదగినదే. అయితే vendor CLIs (command line interfaces) మరియు ఇటీవలి subcommands విషయంలో ఇది తక్కువ నమ్మదగినది. అక్కడ అమలులో ఉన్నట్లు కనిపించే, కానీ వాస్తవానికి లేని flag ను model సృష్టించవచ్చు. --help దీన్ని ఒక సెకన్‌లో నిర్ధారిస్తుంది. Quoting మరో బలహీనమైన అంశం. అందువల్ల command ఒక $(...) expression ను ఉపయోగించినప్పుడు, వివరణను నమ్మకుండా command అమలుకు ముందు command substitution ఎలా expand అవుతుందో చదవండి.

Job 5: మీ shell history ను runbook గా మార్చండి

ఏదైనా పని చేయించడానికి మీరు ఇప్పుడే రెండు గంటలు వెచ్చించారు. ఆ పరిజ్ఞానం మీ scrollback లో మాత్రమే ఉంది. వచ్చే నెలకు అది కనిపించదు.

history 200 > /tmp/session.txt

ఆ file ను చదివి, అది ఎక్కడికైనా వెళ్లే ముందు password, token లేదా customer identifier ఉన్న ప్రతి line ను తొలగించండి. Linux box లో secret ను కనుగొనడానికి shell history అత్యంత నమ్మదగిన ప్రదేశాల్లో ఒకటి. ఎందుకంటే ప్రతి ఒక్కరూ కనీసం ఒకసారి అయినా secret ను command లోనే టైప్ చేస్తారు. మీ ~/.bashrc లో HISTCONTROL=ignorespace ను set చేయండి. అప్పుడు ప్రారంభంలో space ఉన్న command history లో అసలు రాయబడదు.

ఉపయోగకరమైన runbook ను రూపొందించే prompt కేవలం steps ను మాత్రమే కాకుండా checks ను కూడా అడుగుతుంది:

ఇది fresh Debian 13 box ను పనిచేసే Postgres install గా మార్చిన shell session. దీన్ని numbered runbook గా రాయండి. ప్రతి step కు ఒక command మాత్రమే ఉండాలి. ప్రతి step తర్వాత అది పనిచేసిందని నిరూపించే command ను ఇవ్వండి. ఆరోగ్యకరమైన output ఎలా కనిపించాలో వివరించండి. నా specific host పై ఆధారపడిన ప్రతి step ను గుర్తించండి.

విఫలమయ్యే విధానం: చక్కగా సవరించిన కథనం. మీరు ఒక step ను సరిచేయడానికి ముందు రెండుసార్లు తప్పుగా అమలు చేశారు. Transcript లో ఆ తప్పు లేకపోతే అది మరింత శుభ్రంగా కనిపిస్తుంది కాబట్టి model ఆ step ను సులభంగా తొలగిస్తుంది. మీ history తో runbook ను పోల్చి, ఆ correction ను తిరిగి చేర్చండి. అది నమ్మదగిన verification commands ను కూడా కల్పించవచ్చు. అందువల్ల file ను save చేయడానికి ముందు అది రాసిన ప్రతి check ను అమలు చేయండి. Runbook first boot ను వివరిస్తే, పరిష్కరించబడిన సమస్యకు మరింత చెడ్డ version ను రాయకుండా కొత్త VPS లో మొదటి పది నిమిషాలు తో పోల్చి చదవండి.

పని 6: దోష సందేశాన్ని పరిష్కారంగా మార్చడం

ఖచ్చితమైన string, దాన్ని ఉత్పత్తి చేసిన command, అది కనిపించే ముందు మీరు మార్చిన ఒక విషయాన్ని paste చేయండి. ప్రతి కారణాన్ని వేరు చేసే command తో పాటు కారణాలను సంభావ్యత క్రమంలో ఇవ్వమని అడగండి. దీంతో సమాధానాన్ని పరీక్షించగల రూపంలో ఇవ్వాల్సి వస్తుంది.

nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use). సంభావ్య కారణాలను క్రమబద్ధీకరించి, ప్రతి కారణాన్ని నిర్ధారించడానికి లేదా తోసిపుచ్చడానికి ఒక్కో command ఇవ్వండి.

ఆ దోషానికి కారణమైన విధానం స్పష్టంగానే ఉంది: మరో process ఇప్పటికే port 80 ను ఆక్రమించి ఉంది, దాన్ని sudo ss -tulpn | grep ':80 ' గుర్తిస్తుంది. విఫలమైన reload తర్వాత మిగిలిపోయిన రెండో nginx master కావచ్చు. లేదా dependency గా చేర్చబడిన Apache తన package ద్వారా ప్రారంభమై ఉండవచ్చు.

విఫల విధానం: కారణాన్ని దాచడం ద్వారా పనిచేసే పరిష్కారం. chmod 777, --privileged, SELinux ను disable చేయడం, service ను root గా నడపడం — ఇవన్నీ దోషం కనిపించకుండా చేస్తాయి. పరిమిత permission ఎందుకు విఫలమైందో model వివరించే వరకు permissions ను విస్తరించే ఏ పరిష్కారాన్నీ అంగీకరించవద్దు. ఆ వివరణే అసలు సమాధానం. Workaround దోషాన్ని మాత్రమే నిశ్శబ్దం చేస్తుంది.

ఇది నమ్మదగిన విధంగా చేసే తప్పులు

• ఇది మీ server ను చూడలదు. ప్రతి సమాధానం మీరు paste చేసిన సమాచారంపై ఆధారపడి ఉంటుంది. మీరు ఇచ్చిన excerpt చాలా చిన్నదని ఇది చెప్పదు.
• Versions విషయంలో ఇది తారుమారవుతుంది. వివిధ distributions మరియు releases మధ్య package names, default flags మారుతుంటాయి. Model వాటన్నింటి ఆధారంగా సగటు సమాధానం ఇస్తుంది.
• తప్పు అయినప్పుడు కూడా ఇది స్పష్టంగా, నమ్మదగినట్లుగా రాస్తుంది. ఊహించిన mechanism, సరైనదానిలాగే కనిపిస్తుంది. అందుకే పైన పేర్కొన్న ప్రతి కారణంతో పాటు దాన్ని పరీక్షించే command ఇవ్వబడుతుంది.
• దీర్ఘమైన sessions లో ఇది విషయసంబంధాన్ని కోల్పోతుంది. రెండు గంటల conversation ప్రారంభంలో ఉన్న facts, చివర్లోని సమాధానాలను ప్రభావితం చేయడం ఆపేస్తాయి.

చివరి సమస్య model సమస్యకన్నా పని విధానానికి సంబంధించినది. దీర్ఘమైన Claude Code session లో context నిర్వహణ దీనికి ఆచరణాత్మక పరిష్కారం: sessions ను చిన్నవిగా ఉంచండి, ప్రతి session కు ఒక task మాత్రమే కేటాయించండి.

సర్వర్‌పైనే agent ను ఉంచడం

పైన ఉన్న ప్రతిదీ copy and paste చేయాల్సినదే. అందువల్ల model మీ machine ను ఎప్పుడూ తాకదు. అది server పై నడుస్తూ files చదవడం మరియు commands అమలు చేయడం ప్రారంభించిన తర్వాత risk స్వరూపం మారుతుంది. తప్పు command ఇప్పుడు ఒక service ను నిలిపివేయవచ్చు. root కు బదులుగా దానికి స్వంత unprivileged user ఇవ్వండి. దాని పని విధానాన్ని అర్థం చేసుకునే వరకు దాన్ని production server నుంచి వేరుగా ఉంచండి. ముందుగా snapshot తీసుకోండి. VPS పై Claude Code ను సురక్షితంగా నడపడం sandboxing మరియు permission model ను వివరిస్తుంది. tmux లో Claude Code ను నడపడం మరో సమస్యను పరిష్కరిస్తుంది. SSH (secure shell) session మధ్యలో disconnect అయితే foreground agent పని మధ్యలోనే ఆగిపోతుంది. ఏ service account ను సృష్టించినట్టే ఈ account ను కూడా రూపొందించండి. VPS పై least privilege users దీనిని వివరంగా చెబుతుంది.

FAQ

Claude నా server logs ను నేరుగా చదవగలదా?

తనంతట తాను కాదు. Chat interface లో మీరు paste చేసిన text మాత్రమే కనిపిస్తుంది. Server పై command line tool గా నడిచే Claude Code, దాన్ని ప్రారంభించిన user permissions తో files చదవగలదు మరియు commands నడపగలదు. ఇది ఎక్కువ trust అవసరమైన నిర్ణయం. సాధారణ support ప్రశ్నకు agent కు shell access ఇవ్వడం కంటే, redacted 100 line excerpt ను paste చేయడం వేగంగా మరియు సురక్షితంగా ఉంటుంది.

Server నుంచి నేను ఎప్పుడూ ఏవి paste చేయకూడదు?

Private keys, .env files మరియు ఇతర credential stores, /etc/shadow, అలాగే మీ users కు చెందిన ఏ data అయినా paste చేయకూడదు. Log excerpts prompt కు చేరే ముందు tokens ను redact చేయండి. ఒక స్పష్టంగా కనిపించని విషయం: docker compose config output లో మీ .env values interpolated అయి ఉంటాయి. అందువల్ల file ను validate చేసి ఏమీ print చేయని docker compose config -q ను ఉపయోగించండి.

Production VPS పై Claude ను commands నడపనివ్వడం సురక్షితమేనా?

దాన్ని context లేని కొత్త admin లాగా పరిగణించండి: చదవడానికి అనుమతించవచ్చు, రాయడానికి review అవసరం. Production లో explanation అడిగి, command ను మీరే నడపండి. Agent commands execute చేయాలని మీరు కోరుకుంటే, blanket sudo లేకుండా dedicated unprivileged account ఇవ్వండి. మొదట staging box పై ప్రారంభించండి. అక్కడ పొరపాటు వల్ల outage కాకుండా rebuild చేయాల్సి వస్తుంది.

లేని flag ను Claude ఎందుకు సూచిస్తుంది?

Claude సాధ్యమైనట్లు కనిపించే text ను predict చేస్తుంది. అందువల్ల plausible flag మరియు నిజమైన flag ఒకేలా కనిపిస్తాయి. Vendor CLIs మరియు కొత్త subcommands విషయంలో ఇది ఎక్కువగా జరుగుతుంది. వీటి documentation model కు పరిమితంగా ఉండవచ్చు లేదా తరువాత మారి ఉండవచ్చు. --help మరియు man తుది ఆధారం. ఏదైనా command delete లేదా overwrite చేస్తే ముందుగా dry run చేయాలి.

Enable చేయడానికి ముందు systemd unit ను ఎలా తనిఖీ చేయాలి?

sudo systemd-analyze verify /etc/systemd/system/myapp.service ను run చేయండి. ఇది systemd స్వంత parser తో file ను parse చేస్తుంది, unknown directives ను వాటి line numbers తో report చేస్తుంది, అలాగే కనిపించని లేదా executable కాని ExecStart binary ను flag చేస్తుంది. తరువాత daemon-reload, start ను run చేసి, systemctl status ను చదవండి. ఆ తర్వాతే దాన్ని enable చేయండి. సరిగ్గా load అయిన unit మొదటి run లోనే fail కావచ్చు.