Sysadmin साठी Claude: रोजची server कामे

Sysadmins साठी Claude: आधी सल्ला, नंतर अंमलबजावणी

Claude चा reviewer म्हणून वापर केल्यास तो sysadmins साठी सर्वाधिक उपयुक्त ठरतो. तुम्ही log मधील उतारा, configuration file, ओळखता न आलेली command किंवा error string paste करता आणि box वर काहीही बदलण्यापूर्वी पडताळता येईल असे स्पष्टीकरण मिळवता. चुकीच्या उत्तरामुळे काहीही नुकसान होत नाही, जोपर्यंत तुम्ही ते run करत नाही. त्यामुळे model ला त्या मर्यादेच्या सल्ला देण्याच्या बाजूला ठेवणे हेच संपूर्ण safety model आहे.

भाड्याने घेतलेल्या Linux VPS (virtual private server) वर दर आठवड्याला सहा प्रकारची कामे येतात. खालील प्रत्येक कामासाठी उपयुक्त prompt pattern, उत्तराची पुष्टी करणारी command आणि अपेक्षित failure mode दिला आहे. यापैकी कोणत्याही कामासाठी model ला तुमच्या server चा access आवश्यक नाही. तुम्ही browser tab किंवा तुमच्या desktop वरील window मधून मजकूर paste करू शकता, कारण Claude Linux वर desktop app आणि CLI या दोन्ही स्वरूपांत native पद्धतीने चालतो.

Production box वर क्रम महत्त्वाचा आहे: explanation वाचा, check स्वतः run करा आणि त्यानंतर निर्णय घ्या. Scratch VM वर autonomy योग्य आहे. तुमच्या customers साठी सेवा देणाऱ्या box वर review अधिक सुरक्षित ठरतो, कारण model ज्या state बद्दल अंदाज लावत आहे ती state त्याला दिसत नाही.

तुम्ही कधीही पेस्ट करू नये अशा गोष्टी

प्रॉम्प्टमधील सर्व मजकूर तुमच्या सर्व्हरबाहेर जातो. खालील चार प्रकार सर्व्हरवरच ठेवावेत:

• 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 आणि कोणत्याही फाइलमधील किंवा 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 पेस्ट करू नका. दोन्ही फाइल्स वरवर पाहता सारख्या दिसू शकतात. त्यामुळे copy करण्यापूर्वी पहिली ओळ वाचा: ज्या फाइलच्या पहिल्या ओळीत BEGIN OPENSSH PRIVATE KEY आहे, ती कधीही prompt मध्ये देऊ नका. तुमचे SSH key material व्यवस्थित वेगळे ठेवणे यासाठी स्वतंत्रपणे दहा मिनिटे देणे उपयुक्त आहे.

पेस्ट करण्यापूर्वी redact करा. 200 lines मध्ये एक token ओळखण्याच्या स्वतःच्या क्षमतेवर विसंबू नका:

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

Docker शी संबंधित एक विशिष्ट अडचण आहे. docker compose config त्याच्या output मध्ये छापण्यासाठी तुमची .env values interpolate करते. त्यामुळे disk वरील file मध्ये secret नसले तरी ते output secret ठरते. docker compose config -q वापरा. ते validation करते आणि काहीही print करत नाही. 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

दोन्ही commands सोबत model ला स्वतःहून कळू शकत नाही असा context द्या: distribution आणि version, तुम्ही शेवटचे काय बदलले, सेवा पूर्वी कधी कार्यरत होती का, आणि ती अयशस्वी होऊन किती वेळ झाला. प्रथम mechanism समजावून सांगण्यास सांगा.

Ubuntu 24.04. myapp.service मी unit एक तासापूर्वी संपादित करेपर्यंत व्यवस्थित कार्यरत होती. येथे systemctl status आणि journal मधील शेवटच्या 100 lines आहेत. पहिली खरी error कोणती आहे आणि तिचा अर्थ काय? अद्याप उपाय सांगू नका.

या prompt मधील "अद्याप उपाय सांगू नका" हे महत्त्वाचे आहे. Logs मध्ये पहिल्या failure मुळे झालेल्या retries मुळे मूळ failure लपून जाते. त्यामुळे model ला उपाय विचारल्यास ते त्याला दिसलेली शेवटची line समजावून सांगते. महत्त्वाची line सहसा या गोंधळाच्या सुमारे 20 lines वर असते.

यातून Main PID: 1841 (code=exited, status=203/EXEC) सारखी line मिळू शकते. Exit status 203/EXEC म्हणजे kernel ExecStart मध्ये नमूद केलेली file execute करू शकले नाही: path अस्तित्वात नाही किंवा file अस्तित्वात असूनही executable नाही. Installed नसलेल्या interpreter चे नाव देणारी #! line देखील हाच status निर्माण करते. हे सर्व ls -l आणि head -1 वापरून तपासता येते.

अपयशाचा प्रकार: बनावट कारण. खूप कमी मजकूर paste केल्यास model ही उणीव एखाद्या सर्वसाधारण कारणाने भरते, जसे की "port आधीच वापरात आहे". त्यावर पुन्हा एकच प्रश्न विचारा: "मी दिलेल्या मजकुरातील कोणती line याला आधार देते?" मजकुरात ज्याकडे निर्देश करता येत नाही असे कारण म्हणजे अंदाज.

Job 2: systemd unit किंवा cron entry तयार करा

Unit file ला आवश्यक असलेली तथ्ये द्या: अचूक command, तो कोणत्या user म्हणून चालेल, working directory, network साठी प्रतीक्षा करणे आवश्यक आहे का आणि तो non-zero सह बंद झाल्यावर काय झाले पाहिजे. त्यानंतर काही enable करण्यापूर्वी प्रत्यक्ष output तपासा.

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 ही file systemd ज्या पद्धतीने parse करते त्याच पद्धतीने 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 होऊ शकते आणि चालू होताच अपयशी ठरू शकते.

Draft तयार करताना दोन चुका वारंवार होतात. पहिली म्हणजे After=network.target. याचा अर्थ फक्त network stack configure झाला आहे; address अद्याप उपलब्ध आहेच असे नाही. एखादी service विशिष्ट IP ला bind करत असल्यास 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 म्हणून mark केली जाते, पण वास्तविक process unmanaged पद्धतीने चालू राहतो. ही चूक model कडून मिळण्याची शक्यता सर्वाधिक असते, कारण तुमच्या command वरून binary fork करते का हे त्याला कळत नाही. त्यामुळे draft स्वीकारण्यापूर्वी प्रत्येक Type= value 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 कधीही read केले जात नाही. Terminal मध्ये command paste केल्यावर चालणारे job cron अंतर्गत /bin/sh: 1: docker: not found सह अपयशी ठरते, कारण तो binary /usr/local/bin मध्ये आहे. Crontab मध्ये absolute paths वापरा. एका crontab line च्या तुलनेत unit file ने user, environment आणि dependencies स्पष्टपणे लिहिण्याचा आग्रह अनावश्यक औपचारिकता वाटत असल्यास, systemd सोडवण्यासाठी तयार केलेल्या समस्या ही verbosity का आली हे स्पष्ट करतात.

Job 3: nginx किंवा Compose file live करण्यापूर्वी त्याचे पुनरावलोकन करा

या कामातून सर्वाधिक फायदा मिळतो. File paste करा, ती नेमकी काय करणार आहे ते सांगा आणि प्रत्यक्षात ती काय करते याचे line by line स्पष्टीकरण मागा.

हा vhost example.com HTTPS वर serve करावा आणि /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 print होते किंवा nginx: [emerg] unknown directive "proxy_pas" in /etc/nginx/conf.d/app.conf:12 प्रमाणे file आणि line नमूद केली जाते. File parse झाल्यावर docker compose config -q काहीही print करत नाही. Indentation चुकल्यास yaml: line 7: did not find expected key सारखा थेट error दिसतो.

यापैकी कोणतेही tool configuration चा हेतू तपासत नाही. nginx -t यशस्वी झालेले configuration देखील चुकीच्या port कडे proxy करू शकते किंवा तुम्हाला 127.0.0.1 अपेक्षित असताना 0.0.0.0 वर listen करू शकते. याच अंतरात model उपयुक्त ठरते; पण याच ठिकाणी ते चुका देखील करते. एखादा directive दुरुस्त करण्यास सांगितल्यावर ते अनेकदा संपूर्ण file पुन्हा लिहून देते आणि तुमचे दोन directive शांतपणे काढून टाकते. बदललेल्या lines आणि प्रत्येक बदलाचे कारण मागा. त्यानंतर स्वतः हाताने edit करा.

प्रत्यक्षात काय expose झाले आहे ते तपासा:

sudo ss -tulpn

sudo शिवाय listening sockets दिसतात; पण ते वापरणारे processes दिसत नाहीत. Output अनपेक्षित असल्यास, ports म्हणजे काय आणि Linux त्यांना कसे bind करते हा अधिक संक्षिप्त संदर्भ वाचा.

Job 4: अपरिचित command चालवण्यापूर्वी त्याचे स्पष्टीकरण घ्या

Command पेस्ट करा आणि त्याबद्दल चार प्रश्न विचारा: प्रत्येक 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वरील शेवटचा slash म्हणजे “या directoryमधील contents”. तो काढल्यास /backup/app/app/ मिळते. --delete जोडल्यास sourceमध्ये नसलेली destinationमधील प्रत्येक गोष्ट हटवली जाते. Mirrorसाठी हे योग्य आहे; पण source path चुकीचा असल्यास ही गंभीर समस्या ठरते.

Modelवर नव्हे, तर tool वापरून पडताळा:

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

find हे -delete शिवाय चालवल्यास नुकसान होण्याऐवजी list मिळते.

अपयशाचा प्रकार: flagबाबत चुकीची कल्पना. तीस वर्षांचे documentation असलेल्या toolsबाबत model तुलनेने विश्वासार्ह असते. मात्र vendor CLIs (command line interfaces) आणि अलीकडील subcommandsबाबत ते कमी विश्वासार्ह असते. अशा वेळी ते योग्य दिसणारा, पण अस्तित्वात नसलेला flag तयार करू शकते. --help एका सेकंदात याची खात्री करते. Quoting हा दुसरा कमकुवत भाग आहे. त्यामुळे commandमध्ये $(...) expression वापरली असल्यास, स्पष्टीकरणावर विश्वास ठेवण्याऐवजी command चालण्यापूर्वी command substitution कशी expand होते ते वाचा.

शेल इतिहासाचे runbook मध्ये रूपांतर करा

एखादी गोष्ट कार्यरत करण्यासाठी तुम्ही नुकतेच दोन तास खर्च केले. हे ज्ञान तुमच्या scrollback मध्ये आहे आणि पुढील महिन्यात ते उपलब्ध नसेल.

history 200 > /tmp/session.txt

ही फाइल वाचा आणि ती कुठेही वापरण्यापूर्वी password, token किंवा ग्राहक ओळखकर्ता असलेली प्रत्येक ओळ हटवा. Linux box वर secret शोधण्यासाठी shell history ही सर्वात विश्वासार्ह ठिकाणांपैकी एक आहे, कारण प्रत्येकजण किमान एकदा तरी तो inline टाइप करतो. तुमच्या ~/.bashrc मध्ये HISTCONTROL=ignorespace सेट करा. त्यानंतर सुरुवातीला space असलेली command history मध्ये अजिबात लिहिली जाणार नाही.

उपयुक्त runbook तयार करणारा prompt केवळ steps नव्हे, तर checks मागतो:

ही shell session fresh Debian 13 box वर कार्यरत Postgres install पर्यंत पोहोचली. तिचे numbered runbook म्हणून लेखन करा. प्रत्येक step मध्ये एकच command द्या. प्रत्येक step नंतर ते यशस्वी झाल्याचे सिद्ध करणारी command द्या आणि healthy output कसा दिसतो ते वर्णन करा. माझ्या विशिष्ट host वर अवलंबून असलेला कोणताही step चिन्हांकित करा.

अपयशाचा प्रकार: नीटनेटकी कथा. एखादी दुरुस्ती करण्यापूर्वी तुम्ही session मधील एक step दोनदा चुकीचा केला होता. Transcript मध्ये तो भाग नसल्यास मजकूर अधिक स्वच्छ दिसतो, म्हणून model तो भाग गुळगुळीत करून काढून टाकतो. Runbook ची तुमच्या history शी तुलना करा आणि ती correction पुन्हा समाविष्ट करा. तो विश्वसनीय वाटणाऱ्या verification commands देखील तयार करतो. त्यामुळे फाइल जतन करण्यापूर्वी त्याने लिहिलेली प्रत्येक check प्रत्यक्ष चालवून पाहा. Runbook मध्ये first boot समाविष्ट असल्यास, नवीन VPS वरील पहिल्या दहा मिनिटांशी त्याची तुलना करा, जेणेकरून आधीच सोडवलेल्या समस्येची अधिक वाईट आवृत्ती तुम्ही लिहून ठेवणार नाही.

नोकरी 6: त्रुटी संदेशाचे निराकरणात रूपांतर करा

अचूक संदेश, तो निर्माण करणारी command आणि तो दिसण्यापूर्वी तुम्ही बदललेली एकमेव गोष्ट पेस्ट करा. प्रत्येक संभाव्य कारणासाठी वेगळे ओळखणारे 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 ' तिचे नाव दाखवते. अनेकदा failed reload नंतर दुसरा nginx master process सुरू राहतो. किंवा Apache dependency म्हणून समाविष्ट होऊन त्याच्या package मार्फत सुरू होतो.

अपयशाची पद्धत: कारण लपवून काम करणारे निराकरण. chmod 777, --privileged, SELinux अक्षम करणे आणि सेवा root म्हणून चालवणे यामुळे त्रुटी अदृश्य होते. अरुंद permission का अपयशी ठरली हे मॉडेलने स्पष्ट करेपर्यंत permissions अधिक व्यापक करणारे कोणतेही निराकरण स्वीकारू नका. ते स्पष्टीकरणच खरे उत्तर आहे. Workaround मुळे फक्त त्रुटी शांत होते.

ते सातत्याने काय चुकीचे करते

• ते तुमचा सर्व्हर पाहू शकत नाही. प्रत्येक उत्तर तुम्ही दिलेल्या मजकुरावर आधारित असते. दिलेला उतारा अपुरा आहे, असे ते सांगणार नाही.
• आवृत्त्यांबाबत त्याची माहिती बदलत राहते. विविध distributions आणि releases मध्ये package names आणि default flags बदलतात. Model या सर्वांवर आधारित सरासरी उत्तर देते.
• चुकीचे असतानाही ते प्रवाहीपणे उत्तर देते. कल्पित mechanism अगदी अचूक mechanism सारखेच वाटते. म्हणूनच वरील प्रत्येक कारणासोबत ते तपासण्यासाठी एक command दिलेली आहे.
• दीर्घ sessions मध्ये ते संदर्भाचा धागा गमावते. दोन तासांच्या संभाषणाच्या सुरुवातीला दिलेली माहिती शेवटच्या उत्तरांवर परिणाम करेनाशी होते.

शेवटची समस्या model पेक्षा काम करण्याच्या पद्धतीशी अधिक संबंधित आहे. दीर्घ Claude Code session मधील context व्यवस्थापित करणे हा तिचा व्यावहारिक उपाय आहे: sessions लहान ठेवा आणि प्रत्येक session मध्ये एकच task करा.

सर्व्हरवरच agent ठेवणे

वरील सर्व मजकूर copy आणि paste करण्यापुरताच आहे, त्यामुळे model तुमच्या मशीनवर थेट कोणतीही क्रिया करत नाही. तो box वर चालू झाल्यानंतर files वाचतो आणि commands execute करतो. त्यामुळे जोखमीचे स्वरूप बदलते: चुकीच्या command मुळे आता एखादी service बंद पडू शकते. root ऐवजी त्याच्यासाठी स्वतंत्र unprivileged user द्या. त्याच्या कार्यपद्धतीची माहिती होत असताना त्याला production box पासून दूर ठेवा. तसेच आधी snapshot घ्या. VPS वर Claude Code सुरक्षितपणे चालवणे यात sandboxing आणि permission model स्पष्ट केले आहे. tmux मध्ये Claude Code चालवणे या समस्येचा दुसरा भाग सोडवते, कारण SSH (secure shell) session तुटल्यास foreground agent त्याचे काम अर्धवट असताना बंद होतो. हा account कोणत्याही service account प्रमाणे तयार करा. VPS वरील least privilege users मध्ये त्याची सविस्तर पद्धत दिली आहे.

FAQ

Claude माझे server logs थेट वाचू शकतो का?

स्वतःहून नाही. Chat interface मध्ये तुम्ही paste केलेला textच दिसतो. Server वर command line tool म्हणून चालणारा Claude Code, तो सुरू करणाऱ्या user च्या permissions सह files वाचू आणि commands चालवू शकतो. त्यामुळे हा अधिक मोठा trust decision आहे. सामान्य support प्रश्नासाठी agent ला shell access देण्यापेक्षा redacted 100 line excerpt paste करणे अधिक जलद आणि सुरक्षित आहे.

Server मधून मी काय कधीही paste करू नये?

Private keys, .env files आणि इतर credential stores, /etc/shadow, तसेच तुमच्या users शी संबंधित कोणताही data. Log excerpts prompt पर्यंत पोहोचण्यापूर्वी त्यांतील tokens redact करा. एक सहज लक्षात न येणारे उदाहरण म्हणजे docker compose config च्या output मध्ये तुमची .env values interpolated केलेली असतात. त्यामुळे docker compose config -q वापरा. ते file validate करते आणि काहीही print करत नाही.

Claude ला production VPS वर commands चालवू देणे सुरक्षित आहे का?

त्याला कोणताही context नसलेला नवीन admin समजा: वाचण्यासाठी ठीक, पण लिहिण्यासाठी review आवश्यक आहे. Production वर explanation मागा आणि command स्वतः चालवा. Agent कडून commands execute करून घ्यायचे असल्यास, त्याला blanket sudo नसलेले स्वतंत्र unprivileged account द्या. सुरुवात staging box वर करा. त्यामुळे चुकल्यास outage ऐवजी server पुन्हा build करावा लागेल.

अस्तित्वात नसलेला flag Claude का सुचवतो?

कारण ते plausible text predict करते आणि plausible flag व real flag दिसायला सारखेच असतात. Vendor CLIs आणि नवीन subcommands मध्ये हे अधिक वेळा घडते. अशा वेळी model मागील documentation अपुरी असू शकते किंवा ती नंतर बदललेली असू शकते. --help आणि man हे अंतिम प्रमाण मानावे. कोणताही command delete किंवा overwrite करत असल्यास आधी dry run करा.

एखादा systemd unit enable करण्यापूर्वी तो कसा तपासू?

sudo systemd-analyze verify /etc/systemd/system/myapp.service चालवा. ते systemd च्या स्वतःच्या parser ने file parse करते, unknown directives त्यांच्या line numbers सह दाखवते आणि missing किंवा executable नसलेला ExecStart binary असल्यास flag करते. त्यानंतर daemon-reload, start चालवा आणि systemctl status वाचा. मगच तो enable करा, कारण cleanly load होणारा unit पहिल्यांदा चालू झाल्यावरही fail होऊ शकतो.