Sysadmins-க்கு Claude: சர்வர் பணிகளை எளிதாக்குவது எப்படி?

Sysadmins-க்கான Claude: முதலில் ஆலோசனை, பிறகு செயல்பாடு

Sysadmins-க்கு Claude ஒரு சிறந்த மதிப்பாய்வாளராக (reviewer) செயல்படுகிறது. ஒரு log-ன் பகுதி, config file, உங்களுக்குத் தெரியாத command, அல்லது error string ஆகியவற்றை நீங்கள் இதில் பதிவிடலாம். நீங்கள் server-ல் எதையும் மாற்றும் முன், அது தரும் விளக்கத்தைச் சரிபார்க்கலாம். நீங்கள் ஒரு command-ஐ இயக்கும் வரை தவறான பதிலால் எந்த பாதிப்பும் ஏற்படாது; எனவே, மாதிரியை (model) ஆலோசனை வழங்கும் நிலையில் மட்டும் வைத்திருப்பதே பாதுகாப்பான முறையாகும்.

வாடகைக்கு எடுக்கப்பட்ட Linux VPS-ல் (virtual private server) வாரந்தோறும் ஆறு வகையான பணிகள் வருகின்றன. கீழே உள்ள ஒவ்வொன்றிற்கும் ஒரு பயனுள்ள prompt pattern, பதிலை உறுதிப்படுத்தும் command, மற்றும் நீங்கள் எதிர்பார்க்க வேண்டிய failure mode கொடுக்கப்பட்டுள்ளன. இவற்றில் எதற்கும் உங்கள் server-ஐ மாதிரி அணுக வேண்டிய அவசியமில்லை. நீங்கள் browser tab-லிருந்தோ அல்லது உங்கள் desktop-லிருந்தோ தகவலைப் பதிவிடலாம், ஏனெனில் Claude ஆனது Linux-ல் desktop app மற்றும் CLI என இரண்டாகவும் இயங்குகிறது.

Production server-ல் வரிசைமுறை முக்கியமானது: விளக்கத்தைப் படியுங்கள், நீங்களே சரிபார்க்கும் command-ஐ இயக்குங்கள், பிறகு முடிவெடுங்கள். ஒரு scratch VM-ல் தன்னிச்சையாகச் செயல்படுவது தவறில்லை. ஆனால், வாடிக்கையாளர்களுக்குச் சேவை வழங்கும் server-ல், மதிப்பாய்வு செய்வதே சிறந்தது, ஏனெனில் மாதிரி (model) தான் ஊகிக்கும் server-ன் தற்போதைய நிலையை நேரடியாகப் பார்க்க முடியாது.

நீங்கள் ஒருபோதும் பகிரக்கூடாத தகவல்கள்

உங்கள் 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, மற்றும் ஏதேனும் ஒரு கோப்பு அல்லது log வரியில் உள்ள database கடவுச்சொற்கள்.
• Account data: /etc/shadow மற்றும் /etc/gshadow. எந்தவொரு sysadmin கேள்விக்கும் password hash-ஐப் பகிர வேண்டிய அவசியம் இல்லை.
• உங்கள் பயனர்களுக்குச் சொந்தமான தகவல்கள்: மின்னஞ்சல் முகவரிகள், order வரிசைகள், session cookies அல்லது PII (தனிப்பட்ட அடையாளத் தகவல்கள்) கொண்ட request logs.

Public keys-ஐப் பகிர்வதில் சிக்கல் இல்லை. ஆனால் Private keys-ஐப் பகிரக்கூடாது. இவ்விரு கோப்புகளும் பார்ப்பதற்கு ஒரே மாதிரியாக இருக்கும் என்பதால், நகலெடுக்கும் முன் முதல் வரியைச் சரிபார்க்கவும்: ஒரு கோப்பின் முதல் வரியில் BEGIN OPENSSH PRIVATE KEY இருந்தால், அதை ஒருபோதும் பகிரக்கூடாது. உங்கள் SSH key-களை முறையாகப் பராமரித்தல் என்ற தலைப்பில் இதைப் பற்றி விரிவாகப் படிக்கலாம்.

200 வரிகளில் ஒரு குறிப்பிட்ட token-ஐத் தேடி நீக்குவதை விட, தகவலைப் பகிரும் முன்பே அதை நீக்கிவிடுவது (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 மதிப்புகளை வெளியீட்டில் (output) காட்டும். எனவே, வட்டில் உள்ள கோப்பு ரகசியமாக இருந்தாலும், அதன் வெளியீடு ரகசியத்தை வெளிப்படுத்திவிடும். docker compose config -q-ஐப் பயன்படுத்தவும்; இது தகவலைச் சரிபார்க்குமே தவிர, எதையும் திரையில் காட்டாது. ஒரு AI agent எதைப் பார்க்க அனுமதிக்கப்பட வேண்டும் என்பது குறித்த விரிவான கொள்கைக்கு, AI agent-களிடமிருந்து ரகசியங்களைப் பாதுகாத்தல் என்ற பகுதியை அணுகவும்.

பணி 1: இந்த service ஏன் தோல்வியடைந்தது?

பதிலைக் கண்டறிய உதவும் இரண்டு கட்டளைகளுடன் தொடங்கவும்:

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

இரண்டையும் பதிவிடவும், அதனுடன் model-ஆல் யூகிக்க முடியாத சூழலையும் குறிப்பிடவும்: distribution மற்றும் version, கடைசியாக நீங்கள் என்ன மாற்றினீர்கள், இது எப்போதாவது சரியாக வேலை செய்ததா, மற்றும் எவ்வளவு காலத்திற்கு முன்பு இது செயலிழந்தது. முதலில் அதன் செயல்பாட்டு முறையைக் கேட்கவும்.

Ubuntu 24.04. ஒரு மணி நேரத்திற்கு முன்பு unit-ஐ மாற்றிய வரை myapp.service சரியாக இருந்தது. இதோ systemctl status மற்றும் கடைசி 100 journal வரிகள். இதில் முதல் உண்மையான பிழை எது, அதன் பொருள் என்ன? இதுவரை எந்த தீர்வும் செய்யப்படவில்லை.

"இதுவரை எந்த தீர்வும் செய்யப்படவில்லை" (No fix yet) என்பது இந்த prompt-ல் முக்கியமானது. Logs-ல் ஏற்படும் தொடர் முயற்சிகளால் (retries) உண்மையான முதல் பிழை மறைந்துவிடும், எனவே தீர்வை மட்டும் கேட்டால், model கடைசியாகப் பார்த்த வரியை வைத்து விளக்கும். முக்கியமான வரி பொதுவாக இரைச்சலுக்கு (noise) இருபது வரிகளுக்கு மேலே இருக்கும்.

இதன் பலன் Main PID: 1841 (code=exited, status=203/EXEC) போன்ற ஒரு வரியாக இருக்கும். Exit status 203/EXEC என்றால், ExecStart-ல் குறிப்பிடப்பட்டுள்ள கோப்பை kernel-ஆல் இயக்க முடியவில்லை என்று பொருள்: ஒன்று அந்தப் பாதை (path) இல்லை, அல்லது கோப்பு உள்ளது ஆனால் அது இயங்கக்கூடியதாக (executable) இல்லை. நிறுவப்படாத ஒரு interpreter-ஐக் குறிப்பிடும் #! வரியும் இதே நிலையை உருவாக்கும். இவை அனைத்தையும் ls -l மற்றும் head -1 மூலம் சோதிக்கலாம்.

தோல்வி முறை: கற்பனையான காரணம். மிகக் குறைந்த தகவலைப் பதிவிட்டால், "port ஏற்கனவே பயன்பாட்டில் உள்ளது" என்பது போன்ற பொதுவான காரணத்தை model குறிப்பிடும். இதற்கான தீர்வு, ஒரு கேள்வியைத் திரும்பக் கேட்பதுதான்: "நீங்கள் கொடுத்த தகவலில் எந்த வரி இதை உறுதிப்படுத்துகிறது?" உரையில் எவராலும் சுட்டிக்காட்ட முடியாத ஒரு காரணம் வெறும் ஊகம் மட்டுமே.

பணி 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 போலவே கோப்பைப் பகுப்பாய்வு செய்வதால், மனிதக் கண்களுக்குத் தப்பிவிடும் பிழைகளை இது கண்டறியும். தவறாக எழுதப்பட்ட 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 கட்டமைக்கப்பட்டுவிட்டது என்று மட்டுமே குறிக்கும், IP address தயாராக உள்ளது என்று அர்த்தமல்ல. ஒரு குறிப்பிட்ட IP-ல் bind ஆகும் service, boot-ன் போது bind: Cannot assign requested address பிழையுடன் தோல்வியடையும். இதற்கு Wants=network-online.target மற்றும் After=network-online.target ஆகியவற்றைச் சேர்ப்பதே தீர்வாகும். இரண்டாவது, daemonize ஆகும் ஒரு நிரலுக்கு Type=simple-ஐப் பயன்படுத்துவது. systemd முதல் process-ஐ மட்டுமே service-ஆகக் கருதும்; parent process உடனடியாக வெளியேறிவிடும், உண்மையான process தொடர்ந்து இயங்கினாலும், unit 'dead' என்று குறிக்கப்படும். ஒரு binary fork ஆகுமா என்பதை உங்கள் கட்டளையை வைத்து மட்டும் கணிக்க முடியாது என்பதால், AI மாதிரிகள் இந்தத் தவறைச் செய்ய அதிக வாய்ப்புள்ளது. எனவே, வரைவை ஏற்றுக்கொள்வதற்கு முன் ஒவ்வொரு Type= மதிப்பும் systemd-க்கு என்ன உறுதி அளிக்கிறது என்பதை அறிந்துகொள்வது அவசியம்.

ஒரு கால அட்டவணைக்கு (schedule), அதை வாசிப்பதற்குப் பதிலாகச் சரிபார்க்கவும்:

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

இது இயல்பாக்கப்பட்ட வடிவத்தையும், அந்த expression அடுத்ததாக எப்போது இயங்கும் என்பதையும் அச்சிடும்; இது அதன் அர்த்தம் குறித்த அனைத்து விவாதங்களையும் முடிவுக்குக் கொண்டுவரும். நீங்கள் timer அல்லது crontab-க்கு இடையே தேர்வு செய்கிறீர்கள் என்றால், VPS-ல் systemd services மற்றும் timers அதன் சாதக பாதகங்களை விளக்குகிறது.

Cron-ல் ஒரு பொறி உள்ளது, அதைப் பற்றி நீங்கள் கேட்காதவரை எந்த மாதிரியும் உங்களுக்கு எச்சரிக்கை செய்யாது. Cron மிகக் குறைந்த சூழலில் (minimal environment) வேலைகளை இயக்குகிறது; எனவே PATH என்பது தோராயமாக /usr/bin:/bin ஆகும், மேலும் உங்கள் shell profile ஒருபோதும் வாசிக்கப்படாது. உங்கள் terminal-ல் ஒட்டும்போது வேலை செய்யும் ஒரு பணி, cron-ன் கீழ் /bin/sh: 1: docker: not found பிழையுடன் தோல்வியடையும், ஏனெனில் அந்த binary /usr/local/bin-ல் உள்ளது. Crontab-களில் absolute paths-ஐப் பயன்படுத்தவும். ஒரு unit file-ல் user, environment மற்றும் dependencies-ஐக் குறிப்பிடுவது ஒரு crontab வரியை விட அதிக வேலை போலத் தோன்றினால், systemd எதற்காக உருவாக்கப்பட்டது என்பது அந்த விரிவான அமைப்பின் அவசியத்தை விளக்கும்.

பணி 3: Nginx அல்லது Compose கோப்பை நேரலையில் வெளியிடும் முன் ஆய்வு செய்தல்

இந்த பணி மிகச்சிறந்த பலனைத் தரும். கோப்பை உள்ளீடு செய்து, அது என்ன செய்ய வேண்டும் என்பதைத் தெரிவித்து, ஒவ்வொரு வரியும் உண்மையில் என்ன செய்கிறது என்பதை விளக்கக் கோரவும்.

இந்த vhost, example.com-ஐ HTTPS வழியாக வழங்க வேண்டும் மற்றும் /api-ஐ 8080 என்ற port-ல் உள்ள local service-க்கு proxy செய்ய வேண்டும். இதை வாசித்து, இந்த விளக்கத்துடன் பொருந்தாத எதையும் சுட்டிக்காட்டவும்.

பின்பு, அதன் இலக்கணத்தை அறியும் கருவியை இயக்கவும்:

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-ல் உள்ளது போல கோப்பின் பெயரையும் வரியையும் குறிப்பிடும். docker compose config -q கட்டளையானது கோப்பு சரியாக இருந்தால் எதையும் அச்சிடாது, உங்கள் indentation தவறாக இருந்தால் yaml: line 7: did not find expected key போன்ற நேரடியான செய்தியை மட்டும் காட்டும்.

இந்தக் கருவிகள் எவையும் உங்கள் நோக்கத்தைச் சரிபார்க்காது. nginx -t சோதனையில் தேர்ச்சி பெறும் ஒரு config, தவறான port-க்கு proxy செய்யலாம் அல்லது நீங்கள் 127.0.0.1 என்று நினைத்த இடத்தில் 0.0.0.0-ல் listen செய்யலாம். இந்த இடைவெளியில்தான் AI மாதிரி தனது முக்கியத்துவத்தை நிரூபிக்கிறது, அதே சமயம் இதுவே அதன் தோல்வியும் ஆகும்: ஒரு directive-ஐ மட்டும் திருத்தக் கேட்டால், அது பெரும்பாலும் முழு கோப்பையும் மாற்றி எழுதி, உங்கள் இரண்டு directive-களை அமைதியாக நீக்கிவிடும். மாற்றப்பட்ட வரிகளையும் அதற்கான காரணத்தையும் மட்டும் கேட்டு, நீங்களே கைகளால் திருத்தங்களைச் செய்யவும்.

நீங்கள் உண்மையில் எதை வெளிப்படுத்தியுள்ளீர்கள் என்பதை உறுதிப்படுத்தவும்:

sudo ss -tulpn

sudo இல்லாமல், நீங்கள் listening sockets-ஐ மட்டுமே பார்க்க முடியும், அவற்றை நிர்வகிக்கும் processes-ஐப் பார்க்க முடியாது. அந்த வெளியீடு உங்களுக்கு ஆச்சரியமாக இருந்தால், ports என்றால் என்ன மற்றும் Linux அவற்றை எவ்வாறு இணைக்கிறது என்பது குறுகிய வாசிப்பாக இருக்கும்.

பணி 4: ஒரு புதிய கட்டளையை இயக்கும் முன் அதை விளக்குதல்

கட்டளையை நகலெடுத்து, அதைப் பற்றி நான்கு கேள்விகளைக் கேளுங்கள்: ஒவ்வொரு flag-ம் என்ன செய்கிறது, அது எதை எழுதுகிறது, அது எதை நீக்குகிறது, மற்றும் அதை இரண்டு முறை இயக்கினால் என்ன நடக்கும்? இதில் கடைசி கேள்விதான் மற்றவற்றை விட அதிக பாதிப்புகளைத் தடுக்கும்.

find /var/log -name '*.gz' -mtime +7 -delete-ஐ எடுத்துக்கொள்வோம். ஒரு சிறந்த பதில், -mtime +7 என்பது முழுமையான 24 மணிநேர கால அளவுகளை மட்டுமே கணக்கிடும் என்றும், மீதமுள்ள பகுதிகளைத் தவிர்த்துவிடும் என்றும் கூறும்; எனவே இது 7 நாட்களுக்குப் பதிலாக, குறைந்தது 8 நாட்களுக்கு முந்தைய கோப்புகளைத் தேர்ந்தெடுக்கும். மேலும், find அதன் expression-ஐ இடமிருந்து வலமாக மதிப்பிடும் என்றும், அதனால் -delete-ஐ -name-க்கு முன்னால் நகர்த்தினால், தொடக்கப் பாதையில் உள்ள அனைத்தும் நீக்கப்படும் என்றும் அது விளக்கும். அந்த இரண்டாவது குறிப்பு find man page-ல் ஒரு எச்சரிக்கையாக உள்ளது, மேலும் இது பலரது /var/log-ஐ இழக்கச் செய்துள்ளது.

அல்லது rsync -a --delete /srv/app/ /backup/app/-ஐ எடுத்துக்கொள்வோம். source-ன் இறுதியில் உள்ள slash, "இந்த directory-ல் உள்ள உள்ளடக்கங்கள்" என்று பொருள்படும். அதை நீக்கினால், உங்களுக்கு /backup/app/app/ கிடைக்கும். --delete-ஐச் சேர்த்தால், source-ல் இல்லாத destination-ல் உள்ள அனைத்தும் நீக்கப்படும்; இது ஒரு mirror-க்குச் சரியானது, ஆனால் source path தவறாக இருந்தால் இது ஒரு பேரழிவாகும்.

மாதிரியை நம்பாமல், கருவியைக் கொண்டு சரிபார்க்கவும்:

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

-delete இல்லாமல் find-ஐ இயக்கினால், தரவு இழப்புக்கு பதிலாக ஒரு பட்டியல் மட்டுமே கிடைக்கும்.

தோல்வி முறை: flag hallucination. முப்பது ஆண்டுகால ஆவணங்களைக் கொண்ட கருவிகளில் இந்த மாதிரி நம்பகத்தன்மையுடன் செயல்படும்; ஆனால் vendor CLI (command line interfaces) மற்றும் சமீபத்திய subcommand-களில் இது பலவீனமாக இருக்கும். அப்போது, பார்ப்பதற்குச் சரியாகத் தோன்றும் ஆனால் உண்மையில் இல்லாத ஒரு flag-ஐ அது உருவாக்கக்கூடும். --help இதை ஒரு நொடியில் தெளிவுபடுத்தும். Quoting என்பது மற்றொரு பலவீனமான பகுதி; எனவே ஒரு கட்டளை $(...) expression-ஐ உள்ளடக்கியிருக்கும்போது, விளக்கத்தை நம்புவதற்குப் பதிலாக கட்டளை இயங்குவதற்கு முன் command substitution எவ்வாறு விரிவடைகிறது என்பதைப் படிக்கவும்.

பணி 5: உங்கள் shell history-ஐ ஒரு runbook-ஆக மாற்றுதல்

ஏதோ ஒன்றைச் சரிசெய்ய நீங்கள் இரண்டு மணிநேரம் செலவிட்டிருப்பீர்கள். அந்த அறிவு உங்கள் scrollback-ல் மட்டுமே இருக்கும், அடுத்த மாதம் அது அழிந்துவிடும்.

history 200 > /tmp/session.txt

அந்தக் கோப்பை வாசித்து, கடவுச்சொல், token அல்லது வாடிக்கையாளர் அடையாளங்காட்டி உள்ள ஒவ்வொரு வரியையும் நீக்கிவிட்டு, அதை எங்கும் பகிரவும். Linux கணினியில் ரகசியங்களைக் கண்டறிய மிகவும் நம்பகமான இடங்களில் shell history-யும் ஒன்று, ஏனெனில் அனைவரும் ஒருமுறையாவது அதை நேரடியாகத் தட்டச்சு செய்கிறார்கள். உங்கள் ~/.bashrc-ல் HISTCONTROL=ignorespace-ஐ அமைத்தால், ஒரு இடைவெளியுடன் (leading space) தொடங்கும் கட்டளைகள் history-ல் சேமிக்கப்படாது.

பயன்படுத்தக்கூடிய runbook-ஐ உருவாக்கும் prompt, வெறும் படிகளை மட்டும் கேட்காமல், சரிபார்ப்புகளையும் கேட்க வேண்டும்:

இது ஒரு புதிய Debian 13 கணினியில் Postgres-ஐ நிறுவிய shell session. இதை எண்ணிடப்பட்ட runbook-ஆக எழுது. ஒவ்வொரு படிக்கும் ஒரு கட்டளை மட்டும் இருக்க வேண்டும். ஒவ்வொரு படிக்குப் பிறகும், அது வேலை செய்கிறதா என்பதை உறுதிப்படுத்தும் கட்டளையைக் கொடுத்து, சரியான output எப்படி இருக்கும் என்று விவரி. எனது குறிப்பிட்ட host-ஐச் சார்ந்திருக்கும் எந்தப் படியையும் குறித்து வை.

தோல்விக்கான காரணம்: ஒரு நேர்த்தியான கதை. உங்கள் session-ல் நீங்கள் இரண்டு முறை தவறு செய்து, பின் சரிசெய்த ஒரு படி இருந்திருக்கலாம். அந்தப் படிதான் மிக முக்கியமானது, ஆனால் transcript-ல் அது நீக்கப்பட வாய்ப்புள்ளது. உங்கள் history-உடன் runbook-ஐ ஒப்பிட்டு, அந்தத் திருத்தத்தை மீண்டும் சேர்க்கவும். இது நம்பகமான சரிபார்ப்புக் கட்டளைகளை உருவாக்கும், எனவே கோப்பைச் சேமிக்கும் முன் அது எழுதிய ஒவ்வொரு சரிபார்ப்பையும் நீங்களே இயக்கிப் பார்க்கவும். இந்த runbook ஒரு முதல் boot-ஐப் பற்றியது என்றால், புதிய VPS-ல் முதல் பத்து நிமிடங்கள் என்ற ஆவணத்துடன் ஒப்பிட்டுப் பார்க்கவும். அப்போதுதான் ஏற்கனவே தீர்க்கப்பட்ட ஒரு சிக்கலுக்கு மோசமான தீர்வை நீங்கள் எழுத மாட்டீர்கள்.

பணி 6: பிழைச் செய்தியைத் தீர்வாக மாற்றுதல்

துல்லியமான பிழைச் செய்தி, அதை உருவாக்கிய கட்டளை (command), மற்றும் அது தோன்றுவதற்கு முன்பு நீங்கள் மாற்றிய ஒரு விஷயம் ஆகியவற்றை உள்ளிடவும். சாத்தியமான காரணங்களை வரிசைப்படுத்தி, ஒவ்வொன்றையும் உறுதிப்படுத்த அல்லது நிராகரிக்க ஒரு கட்டளையைக் கேட்கவும். இது பதில்களைச் சோதிக்கக்கூடியதாக மாற்றும்.

nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use). சாத்தியமான காரணங்களை வரிசைப்படுத்தி, ஒவ்வொரு காரணத்தையும் உறுதிப்படுத்த அல்லது நிராகரிக்க ஒரு கட்டளையை வழங்கவும்.

இந்த பிழைக்கான காரணம் தெளிவானது: மற்றொரு process ஏற்கனவே port 80-ஐப் பிடித்துள்ளது, அதை sudo ss -tulpn | grep ':80 ' அடையாளம் காட்டும். பெரும்பாலும், தோல்வியுற்ற reload-க்குப் பிறகு எஞ்சியிருக்கும் இரண்டாவது nginx master process அல்லது dependency-ஆக நிறுவப்பட்டு தானாகத் தொடங்கிய Apache-ஆக இது இருக்கலாம்.

தோல்வி முறை: காரணத்தை மறைப்பதன் மூலம் செயல்படும் ஒரு தீர்வு. chmod 777, --privileged, SELinux-ஐ முடக்குதல், மற்றும் service-ஐ root பயனராக இயக்குதல் போன்றவை பிழையை மறைத்துவிடும். குறுகிய அனுமதி (narrow permission) ஏன் தோல்வியடைந்தது என்பதை விளக்கும் வரை, அனுமதிகளை விரிவுபடுத்தும் எந்தவொரு தீர்வையும் ஏற்க வேண்டாம். அந்த விளக்கமே உண்மையான பதில். ஒரு தற்காலிகத் தீர்வு (workaround) பிழையை அமைதிப்படுத்துமே தவிர, அதைச் சரிசெய்யாது.

இது தவறாகப் புரிந்துகொள்ளும் விஷயங்கள்

• இது உங்கள் server-ஐ நேரடியாகப் பார்க்க முடியாது. நீங்கள் வழங்கிய தகவல்களின் அடிப்படையில் மட்டுமே பதில்கள் அமையும்; நீங்கள் கொடுத்த விவரங்கள் போதுமானதாக இல்லை என்றால் அது உங்களுக்குத் தெரிவிக்காது.
• இது பதிப்புகளை (versions) குழப்பிக்கொள்ளும். Linux distributions மற்றும் releases மாறும்போது package பெயர்களும் default flags-களும் மாறும்; இந்த model அனைத்தையும் பொதுவான ஒன்றாகக் கருதி பதிலளிக்கும்.
• இது தவறான தகவலையும் மிகத் தெளிவாகக் கூறும். தவறான வழிமுறைகளும் சரியானதைப் போலவே தோன்றும் என்பதால், மேலே குறிப்பிடப்பட்ட ஒவ்வொரு காரணத்தையும் சரிபார்க்க ஒரு command கொடுக்கப்பட்டுள்ளது.
• நீண்ட உரையாடல்களில் இது மையக்கருத்தை மறந்துவிடும். இரண்டு மணிநேர உரையாடலின் தொடக்கத்தில் பேசப்பட்ட விஷயங்கள், உரையாடலின் இறுதியில் அதன் பதில்களில் தாக்கத்தை ஏற்படுத்தாது.

கடைசியாகக் குறிப்பிட்டது model-ன் குறைபாட்டை விட, பயன்பாட்டுச் சிக்கலாகும். managing context in a long Claude Code session என்பது இதற்கான நடைமுறைத் தீர்வாகும்: உரையாடல்களைச் சுருக்கமாக வைத்துக்கொண்டு, ஒவ்வொரு முறையும் ஒரு பணியை மட்டும் மேற்கொள்ளுங்கள்.

Agent-ஐ server-லேயே நிறுவுதல்

மேலே உள்ள அனைத்தும் copy and paste செய்யக்கூடியவை என்பதால், model உங்கள் machine-ஐ அணுகாது. இது server-ல் இயங்கி, கோப்புகளைப் படித்து, கட்டளைகளை நிறைவேற்றத் தொடங்கும்போது, ஆபத்தின் தன்மை மாறுகிறது: ஒரு தவறான கட்டளை உங்கள் service-ஐப் பாதிக்கலாம். இதை root-ஆக இயக்காமல், தனி unprivileged user-ஐ உருவாக்கி அதில் இயக்கவும். இதன் செயல்பாடுகளைக் கற்றுக்கொள்ளும் வரை, production server-ல் இதைத் தவிர்க்கவும். தொடங்குவதற்கு முன் ஒரு snapshot எடுக்கவும். VPS-ல் Claude Code-ஐப் பாதுகாப்பாக இயக்குதல் என்ற கட்டுரை, sandboxing மற்றும் permission model பற்றி விளக்குகிறது. tmux-க்குள் Claude Code-ஐ இயக்குதல் மற்ற சிக்கலைத் தீர்க்கிறது, ஏனெனில் SSH (secure shell) session துண்டிக்கப்பட்டால், பாதியில் இயங்கிக்கொண்டிருக்கும் agent செயல்பாடு நின்றுவிடும். VPS-ல் குறைந்தபட்ச அதிகாரங்களைக் கொண்ட பயனர்கள் என்ற கட்டுரையில் விவரிக்கப்பட்டுள்ளபடி, ஒரு service account-ஐ உருவாக்குவது போலவே இதற்கும் account-ஐ உருவாக்கவும்.

FAQ

Claude-ஆல் எனது server logs-ஐ நேரடியாகப் படிக்க முடியுமா?

தனியாக முடியாது. நீங்கள் chat interface-ல் பதிவிடும் உரையை மட்டுமே Claude பார்க்கும். server-ல் command line tool-ஆக இயங்கும் Claude Code, கோப்புகளைப் படிக்கவும், அதைத் தொடங்கிய பயனரின் அனுமதியுடன் கட்டளைகளை இயக்கவும் முடியும்; இது ஒரு பெரிய பாதுகாப்பு முடிவாகும். சாதாரண ஆதரவு கேள்விகளுக்கு, 100 வரிகள் கொண்ட திருத்தப்பட்ட (redacted) பகுதியை நகலெடுத்துப் பதிவிடுவது, ஒரு agent-க்கு shell access வழங்குவதை விட வேகமானது மற்றும் பாதுகாப்பானது.

server-லிருந்து எதை ஒருபோதும் பதிவிடக்கூடாது?

Private keys, .env கோப்புகள் மற்றும் பிற credential சேமிப்பகங்கள், /etc/shadow, மற்றும் உங்கள் பயனர்களுக்குச் சொந்தமான எந்தவொரு தரவும். log-களிலிருந்து தகவல்களைப் பதிவிடும் முன், அதில் உள்ள tokens-ஐ நீக்கிவிடவும். கவனிக்க வேண்டிய ஒரு விஷயம்: docker compose config-ன் வெளியீட்டில் உங்கள் .env மதிப்புகள் இணைக்கப்பட்டிருக்கும், எனவே docker compose config -q-ஐப் பயன்படுத்தவும்; இது கோப்பைச் சரிபார்த்து எதையும் திரையில் காட்டாது.

production VPS-ல் Claude-ஐக் கட்டளைகளை இயக்க அனுமதிப்பது பாதுகாப்பானதா?

இதை எந்தப் பின்னணியும் இல்லாத ஒரு புதிய நிர்வாகியாகக் கருதுங்கள்: படிப்பதற்குச் சரி, ஆனால் எழுதுவதற்குச் சரிபார்ப்பு அவசியம். production-ல், விளக்கத்தைக் கேட்டுவிட்டு, கட்டளையை நீங்களே இயக்கவும். ஒரு agent-ஐ இயக்க விரும்பினால், அதற்கு sudo அதிகாரம் இல்லாத ஒரு பிரத்யேகக் கணக்கை வழங்கவும். தவறு நடந்தால் முழுமையாக மீண்டும் கட்டமைக்க வேண்டியிருக்கும் என்பதால், முதலில் staging box-ல் தொடங்கவும்.

இல்லாத ஒரு flag-ஐ Claude ஏன் பரிந்துரைக்கிறது?

ஏனெனில் அது சாத்தியமான உரையை மட்டுமே கணிக்கிறது; ஒரு போலியான flag-ம் உண்மையானது போலவே தோன்றும். vendor CLI மற்றும் புதிய subcommands-களில் இது அதிகம் நடக்கும், ஏனெனில் அந்த மாதிரிக்கான ஆவணங்கள் குறைவாக இருக்கலாம் அல்லது மாறியிருக்கலாம். --help மற்றும் man ஆகியவையே இறுதி முடிவெடுப்பவை. தரவை அழிக்கும் அல்லது மேலெழுதும் எந்தவொரு கட்டளையையும் முதலில் dry run செய்வது அவசியம்.

ஒரு systemd unit-ஐ enable செய்வதற்கு முன் அதை எப்படிச் சரிபார்ப்பது?

sudo systemd-analyze verify /etc/systemd/system/myapp.service-ஐ இயக்கவும். இது systemd-ன் சொந்த parser மூலம் கோப்பை ஆய்வு செய்து, தெரியாத directives-ஐ வரி எண்களுடன் காட்டும், மேலும் விடுபட்ட அல்லது இயங்க முடியாத ExecStart binary-ஐக் கண்டறியும். பிறகு daemon-reload, start ஆகியவற்றை இயக்கி, systemctl status-ஐப் படிக்கவும். அதன் பிறகு enable செய்யவும், ஏனெனில் சரியாக load ஆகும் unit கூட முதல் முறை இயங்கும்போது தோல்வியடையலாம்.