Sysadmin பணிகளுக்கு Claude-ஐ பயன்படுத்துவது எப்படி?

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

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

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

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

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

நீங்கள் உள்ளிடும் அனைத்தும் உங்கள் 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-ல் சேர்க்கிறது. எனவே, வட்டில் உள்ள கோப்பு ரகசியமாக இல்லாவிட்டாலும், அதன் output ரகசியமானதாக மாறுகிறது. docker compose config -q-ஐப் பயன்படுத்தவும்; இது சரிபார்ப்பை மட்டும் செய்யும், எதையும் அச்சிடாது. ஒரு 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-ஆல் யூகிக்க முடியாத சூழலையும் குறிப்பிடவும்: OS விநியோகம் மற்றும் பதிப்பு, கடைசியாக நீங்கள் மாற்றியது என்ன, இது இதற்கு முன்பு சரியாக வேலை செய்ததா, மற்றும் எவ்வளவு காலத்திற்கு முன்பு இது செயலிழந்தது. முதலில் அதன் செயல்பாட்டு முறையைப் பற்றி கேட்கவும்.

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

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

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

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

பணி 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-ஐப் பயன்படுத்துவதே தீர்வு. இரண்டாவது, தானாகவே daemon-ஆக மாறும் ஒரு நிரலுக்கு Type=simple-ஐப் பயன்படுத்துவது. systemd முதல் process-ஐ மட்டுமே service-ஆகக் கருதும்; parent process உடனே வெளியேறிவிடும், உண்மையான process தொடர்ந்து இயங்கினாலும், அந்த unit 'dead' என்று குறிக்கப்படும்.

ஒரு கால அட்டவணைக்கு (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-ஐப் பயன்படுத்தவும்.

பணி 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 மணிநேர கால அளவுகளை மட்டுமே கணக்கிட்டு, மீதமுள்ள பகுதிகளைத் தவிர்த்துவிடும் என்பதை ஒரு சிறந்த விளக்கம் உங்களுக்குத் தெரிவிக்கும். எனவே, இது ஏழு நாட்களுக்குப் பதிலாக, குறைந்தது எட்டு நாட்களுக்கு முந்தைய கோப்புகளை மட்டுமே கண்டறியும். மேலும், 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 தவறாக இருந்தால் இது ஒரு பேரழிவாக முடியும்.

கருவியைக் கொண்டு சரிபார்க்கவும், model-ஐ மட்டும் நம்ப வேண்டாம்:

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

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

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

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

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

history 200 > /tmp/session.txt

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

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

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

தோல்விக்கான வாய்ப்பு: ஒரு நேர்த்தியான கதை. உங்கள் session-ல் நீங்கள் இரண்டு முறை தவறு செய்து, பின் சரிசெய்த ஒரு படி இருந்திருக்கும். அந்தப் படியை AI நீக்கிவிடக்கூடும், ஏனெனில் பிழைகள் இல்லாத 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 ' அந்த process-ன் பெயரைத் தெரிவிக்கும். பெரும்பாலும், தோல்வியடைந்த reload-க்கு பிறகு எஞ்சியிருக்கும் இரண்டாவது nginx master process அல்லது dependency-ஆக நிறுவப்பட்டு தானாகத் தொடங்கிய Apache இதற்குக் காரணமாக இருக்கலாம்.

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

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

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

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

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-ஐயும் உருவாக்குவது போலவே இதற்கும் ஒரு கணக்கை உருவாக்கவும்.

FAQ

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

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

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

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

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

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

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

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

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

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