Claude తో sysadmins చేసే రోజువారీ Linux server పనులు

sysadmins కోసం Claude: ముందుగా సలహా, తరువాత అమలు

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

అద్దె Linux VPS (virtual private server)లో ప్రతి వారం ఆరు పనులు తరచుగా ఎదురవుతాయి. కింది ప్రతి పనికి పనిచేసే prompt pattern, సమాధానాన్ని నిర్ధారించే command, అలాగే మీరు ఆశించాల్సిన failure mode ఇవ్వబడ్డాయి. వీటిలో ఏదానికీ model కు మీ server కు access అవసరం లేదు.

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

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

Prompt‌లోని మొత్తం సమాచారం మీ server‌ను విడిచిపెడుతుంది. కింది 4 వర్గాల సమాచారం మాత్రం 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‌ను పేస్ట్ చేయడం సురక్షితం. Private keys‌ను పేస్ట్ చేయకూడదు. ఈ 2 files పైకి చూసినప్పుడు ఒకేలా కనిపించవచ్చు. అందువల్ల copy చేసే ముందు మొదటి line‌ను చదవండి: మొదటి line‌లో BEGIN OPENSSH PRIVATE KEY ఉన్న file‌ను ఎప్పటికీ prompt‌లో పెట్టకండి. మీ SSH key material‌ను సరిగ్గా వేరు చేసుకోవడం కోసం 10 minutes కేటాయించడం విలువైనదే.

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

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 అవుతుంది. బదులుగా docker compose config -q ఉపయోగించండి. ఇది validate చేస్తుంది, కానీ ఏ output‌ను print చేయదు. Agent చూడటానికి అనుమతించే సమాచారం గురించి విస్తృత policy కోసం, 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 ఊహించలేని సందర్భ సమాచారాన్ని కూడా ఇవ్వండి: distribution మరియు version, మీరు చివరిగా మార్చినది ఏమిటి, ఇది ఎప్పుడైనా సరిగ్గా పనిచేసిందా, మరియు సమస్య ఏర్పడి ఎంత సమయం అయింది. ముందుగా mechanism గురించి అడగండి.

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

ఈ prompt లో "ఇంకా ఎలాంటి పరిష్కారం చెప్పవద్దు" అనే మాటకు ముఖ్యమైన ప్రయోజనం ఉంది. Logs లో మొదటి failure వల్ల ఏర్పడిన retries కారణంగా అసలు failure తరువాతి సందేశాల కింద దాగిపోతుంది. Model ను fix అడిగితే, అది సాధారణంగా కనిపించిన చివరి line ను వివరిస్తుంది. ముఖ్యమైన line సాధారణంగా noise కు ఇరవై lines ముందు ఉంటుంది.

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

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

పని 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 ఎలా parse చేస్తుందో అదే విధంగా 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 అవుతుంది. Unit dead గా గుర్తించబడుతుంది. నిజమైన process మాత్రం systemd నిర్వహణ లేకుండా నడుస్తూనే ఉంటుంది.

Schedule కోసం దాన్ని చదవకుండా తనిఖీ చేయండి:

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

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

మీరు అడగకపోతే ఏ model కూడా హెచ్చరించని ఒక సమస్య 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 entries లో absolute paths ఉపయోగించండి.

ప్రత్యక్షంగా అమలు చేయడానికి ముందు nginx లేదా Compose ఫైల్‌ను పరిశీలించడం

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

ఈ vhost example.com ను HTTPSపై అందించాలి. అలాగే /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 మరియు line ను చూపిస్తుంది. ఫైల్ parse అయినప్పుడు docker compose config -q ఏమీ ముద్రించదు. indentation తప్పితే yaml: line 7: did not find expected key వంటి స్పష్టమైన సందేశాన్ని చూపిస్తుంది.

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

వాస్తవంగా ఏవి బయటకు అందుబాటులోకి వచ్చాయో నిర్ధారించండి:

sudo ss -tulpn

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

Job 4: అమలు చేయడానికి ముందు తెలియని command ను వివరించండి

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

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

లేదా rsync -a --delete /srv/app/ /backup/app/ ను పరిశీలించండి. source పై ఉన్న trailing 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

-delete లేకుండా find ను అమలు చేస్తే నష్టానికి బదులుగా ఒక జాబితా వస్తుంది.

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

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

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

history 200 > /tmp/session.txt

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

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

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

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

పని 6: ఒక error message ను పరిష్కారంగా మార్చడం

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

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

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

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

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

• ఇది మీ server ను చూడలదు. ప్రతి సమాధానం మీరు paste చేసిన సమాచారంపై మాత్రమే ఆధారపడి ఉంటుంది. ఇచ్చిన excerpt చాలా చిన్నదని ఇది చెప్పదు.
• Versionల విషయంలో ఇది క్రమంగా తప్పుతుంది. వివిధ 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 ను ఎప్పుడూ తాకదు. అది box పై అమలై files చదవడం, commands execute చేయడం ప్రారంభించిన తర్వాత risk స్వరూపం మారుతుంది. ఇప్పుడు తప్పు command వల్ల ఒక service ఆగిపోవచ్చు. దానికి root బదులుగా స్వంత unprivileged user ఇవ్వండి. దాని పని విధానాన్ని అర్థం చేసుకునే వరకు production box పై దాన్ని అమలు చేయవద్దు. ముందుగా 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 చేసి ఏ output ను print చేయని docker compose config -q ను ఉపయోగించండి.

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

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

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

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

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

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