Sysadmin-দের দৈনন্দিন server কাজের জন্য Claude

Sysadmin-দের জন্য Claude: আগে পরামর্শ, পরে প্রয়োগ

Claude একজন reviewer হিসেবে সবচেয়ে ভালো কাজ করে। আপনি একটি log excerpt, configuration file, আপনার অচেনা কোনো command অথবা error string paste করলে, কোনো পরিবর্তন করার আগে যাচাই করার মতো ব্যাখ্যা পেতে পারেন। ভুল উত্তরের কোনো ক্ষতি হয় না, যতক্ষণ না আপনি সেটি চালাচ্ছেন। তাই 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-এ কাজের ক্রম গুরুত্বপূর্ণ: ব্যাখ্যাটি পড়ুন, নিজে check চালান, তারপর সিদ্ধান্ত নিন। Scratch VM-এ autonomy গ্রহণযোগ্য। কিন্তু আপনার customer-দের service দেওয়া box-এ review-কে অগ্রাধিকার দিন, কারণ model যে state সম্পর্কে অনুমান করছে, সেটি সে নিজে দেখতে পারে না।

যা কখনো paste করবেন না

Prompt-এ থাকা সবকিছু আপনার server-এর বাইরে চলে যায়। নিচের চার ধরনের তথ্য server-এই রাখতে হবে:

• Private key: ~/.ssh/id_ed25519, /etc/ssh/ssh_host_*_key এবং /etc/letsencrypt/live/-এর অধীনে থাকা যেকোনো TLS (transport layer security) key।
• Credential file: .env, ~/.aws/credentials, /root/.docker/config.json এবং যেকোনো file বা log line-এ থাকা database password।
• Account data: /etc/shadow এবং /etc/gshadow। কোনো sysadmin প্রশ্নের উত্তর দেওয়ার জন্য password hash প্রয়োজন হয় না।
• আপনার user-দের যেকোনো তথ্য: email address, order row, session cookie-সহ request log বা PII (personally identifiable information)।

Public key paste করা নিরাপদ। Private key নিরাপদ নয়। দুই ধরনের file দেখতে কাছাকাছি হওয়ায় copy করার আগে প্রথম line পড়ুন: যে file-এর প্রথম line-এ BEGIN OPENSSH PRIVATE KEY আছে, সেটি কখনো prompt-এ দেবেন না। আপনার SSH key material সঠিকভাবে আলাদা রাখা-এর জন্য আলাদাভাবে দশ মিনিট সময় দেওয়া উপকারী।

কোনো token 200টি line-এর মধ্যে আছে কি না নিজে খুঁজে বের করার ওপর নির্ভর না করে paste করার আগে 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 value output-এ বসিয়ে দেয়, তাই disk-এর file-এ secret না থাকলেও এটি যে output print করে, সেটি secret। docker compose config -q ব্যবহার করুন; এটি validation করে, কিন্তু কিছু print করে না। কোনো agent কী দেখতে পারবে, সে বিষয়ে বিস্তৃত policy-এর জন্য AI agent-এর বাইরে secret রাখা environment-সংক্রান্ত দিকটি ব্যাখ্যা করে।

কাজ 1: এই service কেন ব্যর্থ হলো?

উত্তরটি যে দুটি command-এ আছে, সেগুলো দিয়ে শুরু করুন:

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

দুটি command-এর output পেস্ট করুন। এর সঙ্গে এমন context দিন, যা model নিজে অনুমান করতে পারবে না: distribution ও version, সর্বশেষ কী পরিবর্তন করেছেন, service-টি আগে কখনও কাজ করেছিল কি না, এবং কতক্ষণ আগে এটি ব্যর্থ হয়েছে। প্রথমে mechanism ব্যাখ্যা করতে বলুন।

Ubuntu 24.04। myapp.service সম্পাদনা করার আগ পর্যন্ত এটি ঠিকঠাক চলছিল; এক ঘণ্টা আগে unit-টি সম্পাদনা করেছি। এখানে systemctl status এবং journal-এর সর্বশেষ 100টি line আছে। প্রথম প্রকৃত error কোন line-এ, এবং এর অর্থ কী? এখনো কোনো fix দেবেন না।

এই prompt-এ "এখনো কোনো fix দেবেন না" কথাটি গুরুত্বপূর্ণ। Log-এ প্রথম failure-এর পরে হওয়া retry-গুলো সেই failure-কে আড়াল করে। তাই fix চাইলে model সাধারণত দেখা সর্বশেষ line-টির ব্যাখ্যা দেবে। গুরুত্বপূর্ণ line-টি সাধারণত noise-এর প্রায় বিশ line আগে থাকে।

ফলে Main PID: 1841 (code=exited, status=203/EXEC)-এর মতো একটি line পাওয়া যেতে পারে। Exit status 203/EXEC-এর অর্থ, ExecStart-এ উল্লেখ করা file-টি kernel execute করতে পারেনি। এর কারণ হতে পারে path-টি বিদ্যমান নয়, অথবা file-টি আছে কিন্তু executable নয়। এমন interpreter উল্লেখ করা #! line, যা system-এ installed নয়, একই status তৈরি করে। ls -l এবং head -1 ব্যবহার করে এগুলো যাচাই করা যায়।

ব্যর্থতার ধরন: অনুমান করে কারণ তৈরি করা। খুব কম তথ্য পেস্ট করলে model একটি সাধারণ কারণ বসিয়ে দেয়, যেমন "port-টি ইতিমধ্যে ব্যবহৃত হচ্ছে"। এর প্রতিকার হলো পাল্টা জিজ্ঞাসা করা: "আমি যে তথ্য দিয়েছি, তার কোন line এই দাবির সমর্থন করে?" যে কারণের পক্ষে পাঠ্যের কোনো নির্দিষ্ট line দেখানো যায় না, সেটি অনুমান।

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 করে, সেভাবেই এটি 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 configured হয়েছে; 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 process সঙ্গে সঙ্গে exit করে। তখন unit-কে dead হিসেবে চিহ্নিত করা হয়, আর আসল process unmanaged অবস্থায় চলতে থাকে। এই ভুলটি কোনো model আপনাকে দেওয়ার সম্ভাবনা বেশি। কারণ আপনার command দেখে binary fork করে কি না, model তা বুঝতে পারে না। তাই খসড়াটি গ্রহণ করার আগে প্রতিটি Type= value systemd-কে কী প্রতিশ্রুতি দেয় তা জেনে নিন।

কোনো schedule পড়ে নয়, পরীক্ষা করে যাচাই করুন:

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

এটি normalised form এবং expression-টি পরের বার কখন কার্যকর হবে তা দেখায়। এতে expression-এর অর্থ নিয়ে যে কোনো বিতর্কের অবসান হয়। timer এবং crontab-এর মধ্যে বেছে নিতে হলে একটি VPS-এ systemd services এবং timers-এ পার্থক্যগুলো ব্যাখ্যা করা হয়েছে।

Cron-এর একটি ফাঁদ আছে, যা না জিজ্ঞেস করলে কোনো model আপনাকে সতর্ক করবে না। Cron job-গুলো minimal environment-এ চালায়। তাই PATH মোটামুটি /usr/bin:/bin এবং আপনার shell profile কখনো পড়া হয় না। Terminal-এ command paste করলে কাজ করলেও cron-এর অধীনে job /bin/sh: 1: docker: not found দিয়ে ব্যর্থ হয়। কারণ binary-টি /usr/local/bin-এ আছে। crontab-এ absolute path ব্যবহার করুন। একটি crontab line-এর তুলনায় কোনো unit file user, environment এবং dependency স্পষ্টভাবে উল্লেখ করার ওপর জোর দিলে তা অতিরিক্ত আনুষ্ঠানিক মনে হতে পারে। systemd যে সমস্যাগুলো সমাধানের জন্য তৈরি করা হয়েছিল সেই verbosity-এর কারণ ব্যাখ্যা করে।

কাজ 3: live করার আগে একটি nginx বা Compose ফাইল পর্যালোচনা করুন

এই কাজটির ফলন সবচেয়ে বেশি। ফাইলটি পেস্ট করুন, এটি কী করার কথা তা লিখুন, এবং এটি বাস্তবে কী করছে তার লাইন-বাই-লাইন ব্যাখ্যা চাইুন।

এই 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 ও line উল্লেখ করে। ফাইলটি parse হলে docker compose config -q কিছুই প্রিন্ট করে না। Indentation-এ ভুল হলে yaml: line 7: did not find expected key-এর মতো সরাসরি error দেখায়।

কোনো tool-ই আপনার উদ্দেশ্য যাচাই করে না। nginx -t পাস করা একটি config তবুও ভুল port-এ proxy করতে পারে, অথবা আপনি 127.0.0.1 বোঝালেও 0.0.0.0-এ listen করতে পারে। এই ব্যবধানেই model-এর উপযোগিতা দেখা যায়, এবং এখানেই এটি ব্যর্থও হয়: একটি directive ঠিক করতে বললে এটি প্রায়ই পুরো file নতুন করে লিখে ফেরত দেয় এবং আপনার দুটি directive নিঃশব্দে বাদ পড়ে যায়। কোন কোন line পরিবর্তন করা হয়েছে এবং প্রতিটির কারণ জানতে চান। এরপর নিজে edit করুন।

বাস্তবে কোন service expose করেছেন, তা নিশ্চিত করুন:

sudo ss -tulpn

sudo ছাড়া listening socket দেখা যায়, কিন্তু সেগুলোর মালিক process দেখা যায় না। output অপ্রত্যাশিত হলে port কী এবং Linux কীভাবে port bind করে বিষয়টির সংক্ষিপ্ত ব্যাখ্যাটি পড়ুন।

কাজ 4: অপরিচিত কোনো command চালানোর আগে সেটি ব্যাখ্যা করুন

command-টি পেস্ট করে এটি সম্পর্কে চারটি প্রশ্ন করুন: প্রতিটি flag কী করে, এটি কী লেখে, কী মুছে ফেলে, এবং এটি দুবার চালালে কী হয়। শেষের প্রশ্নটি অন্যগুলোর চেয়ে বেশি ক্ষতি শনাক্ত করে।

find /var/log -name '*.gz' -mtime +7 -delete দেখুন। একটি ভালো উত্তরে বলা হবে যে -mtime +7 পূর্ণ 24 ঘণ্টার সময়কাল গণনা করে এবং ভগ্নাংশ বাদ দেয়। তাই এটি সাত দিনের নয়, অন্তত আট দিন পুরোনো ফাইলের সঙ্গে মেলে। উত্তরে আরও বলা হবে যে find তার expression বাম থেকে ডানে মূল্যায়ন করে। তাই -delete-কে -name-এর আগে বসালে starting path-এর অধীনে থাকা সবকিছু মুছে যায়। এই দ্বিতীয় বিষয়টি find man page-এ সতর্কতা হিসেবে উল্লেখ আছে। এর কারণে মানুষের /var/log নষ্ট হয়েছে।

অথবা rsync -a --delete /srv/app/ /backup/app/ দেখুন। source-এর শেষে থাকা slash-এর অর্থ হলো “এই directory-এর contents”। এটি বাদ দিলে আপনি /backup/app/app/ পাবেন। --delete যোগ করলে destination-এ থাকা কিন্তু source-এ অনুপস্থিত সবকিছু মুছে যায়। 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 ছাড়া চালালে ক্ষতি না করে একটি তালিকা পাবেন।

ব্যর্থতার ধরন: flag hallucination। ত্রিশ বছরের documentation থাকা tool-এর ক্ষেত্রে model সাধারণত নির্ভরযোগ্য। কিন্তু vendor CLI (command line interfaces) এবং সাম্প্রতিক subcommand-এর ক্ষেত্রে এটি অনেক কম নির্ভরযোগ্য। সেখানে এটি এমন একটি flag তৈরি করে যা পড়লে সম্পূর্ণ সঠিক মনে হয়, কিন্তু বাস্তবে সেটি নেই। --help এক সেকেন্ডে বিষয়টি নিশ্চিত করে। Quoting আরেকটি দুর্বল দিক। তাই কোনো command যখন $(...) expression ব্যবহার করে, তখন explanation-এর ওপর নির্ভর না করে command চলার আগে command substitution কীভাবে expand হয় পড়ুন।

Job 5: shell history-কে runbook-এ রূপ দিন

কোনো কিছু সচল করতে আপনি মাত্র দুই ঘণ্টা ব্যয় করেছেন। সেই জ্ঞান আপনার scrollback-এ আছে, এবং আগামী মাসে তা আর থাকবে না।

history 200 > /tmp/session.txt

ফাইলটি পড়ুন এবং সেটি কোথাও পাঠানোর আগে password, token বা customer identifier থাকা প্রতিটি লাইন মুছে ফেলুন। Linux box-এ secret খুঁজে পাওয়ার সবচেয়ে নির্ভরযোগ্য জায়গাগুলোর একটি হলো shell history, কারণ সবাই অন্তত একবার inline অবস্থায় একটি secret টাইপ করে। আপনার ~/.bashrc-এ HISTCONTROL=ignorespace সেট করুন। তাহলে শুরুতে একটি space দিয়ে টাইপ করা command history-তে একেবারেই লেখা হবে না।

ব্যবহারযোগ্য runbook তৈরি করতে prompt-এ শুধু ধাপ নয়, check-ও চাইতে হবে:

এটি একটি shell session, যেখানে একটি fresh Debian 13 box-এ কার্যকর Postgres install করা হয়েছে। এটিকে numbered runbook হিসেবে লিখুন। প্রতিটি ধাপে একটি করে command রাখুন। প্রতিটি ধাপের পরে কাজটি সফল হয়েছে প্রমাণ করার command দিন এবং সুস্থ output কেমন দেখাবে তা বর্ণনা করুন। আমার নির্দিষ্ট host-এর ওপর নির্ভর করা প্রতিটি ধাপ চিহ্নিত করুন।

ব্যর্থতার ধরন: পরিপাটি গল্প। আপনার session-এ এমন একটি ধাপ ছিল, যা ঠিক করার আগে আপনি দুবার ভুল করেছিলেন। Transcript-টি সেটি বাদ দিলে আরও পরিষ্কার দেখায় বলে model ধাপটি মসৃণ করে বাদ দেয়। আপনার history-এর সঙ্গে runbook মিলিয়ে দেখুন এবং correction-টি আবার যুক্ত করুন। এটি সম্ভাব্য verification command-ও বানিয়ে নিতে পারে। তাই ফাইলটি সংরক্ষণ করার আগে এর লেখা প্রতিটি check নিজে চালান। Runbook-টি যদি first boot নিয়ে হয়, তাহলে নতুন VPS-এর প্রথম দশ মিনিট দেখে সেটির সঙ্গে মিলিয়ে নিন, যাতে সমাধান করা সমস্যার আরও খারাপ সংস্করণ লিখে না ফেলেন।

ত্রুটি বার্তাকে সমাধানে রূপান্তর করুন

সঠিক error string, সেটি তৈরি করা command এবং error দেখা দেওয়ার আগে আপনি যে একটিমাত্র পরিবর্তন করেছিলেন—এই তিনটি তথ্য দিন। প্রতিটি সম্ভাব্য কারণের জন্য আলাদা করে যাচাই করার 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 ' সেটির নাম দেখায়। অনেক সময় failed reload-এর পরে দ্বিতীয় একটি nginx master process চালু থাকে। আবার Apache কোনো dependency হিসেবে যুক্ত হয়ে নিজের package-এর মাধ্যমে start হয়ে থাকতে পারে।

ব্যর্থতার ধরন: কারণ আড়াল করে এমন একটি সমাধান। chmod 777, --privileged, SELinux নিষ্ক্রিয় করা এবং service-কে root হিসেবে চালানো—এসবেই error আর দেখা যায় না। কেন সীমিত permission ব্যর্থ হয়েছে তা মডেল ব্যাখ্যা না করা পর্যন্ত permission আরও বিস্তৃত করে এমন কোনো সমাধান গ্রহণ করবেন না। ওই ব্যাখ্যাই আসল উত্তর। Workaround শুধু error-টিকে নীরব করে।

এটি যেসব ক্ষেত্রে নিয়মিত ভুল করে

• এটি আপনার server দেখতে পারে না। প্রতিটি উত্তর আপনি যে তথ্য paste করেছেন তার ওপর নির্ভর করে। excerpt খুব ছোট হলেও এটি তা জানাবে না।
• Version নিয়ে এটি অসঙ্গত হয়। বিভিন্ন distribution ও release-এ package name এবং default flag পরিবর্তিত হয়। model সেগুলোর গড় অনুমান করে।
• ভুল হলেও এটি সাবলীল থাকে। বানানো mechanism ঠিক সঠিক mechanism-এর মতোই শোনায়। তাই ওপরের প্রতিটি কারণের সঙ্গে সেটি যাচাই করার command দেওয়া হয়েছে।
• দীর্ঘ session-এ এটি প্রসঙ্গ হারায়। দুই ঘণ্টার conversation-এর শুরুতে থাকা তথ্য শেষের উত্তরগুলোকে আর প্রভাবিত করে না।

শেষের সমস্যাটি model-এর সমস্যার চেয়ে কাজের পদ্ধতির সমস্যা বেশি। এর ব্যবহারিক সমাধান হলো দীর্ঘ Claude Code session-এ context পরিচালনা করা: session ছোট রাখুন এবং প্রতিটি session-এ একটি করে কাজ করুন।

সার্ভারেই agent চালানো

উপরের সবকিছু copy এবং paste-নির্ভর, তাই model আপনার মেশিনে কখনও সরাসরি কাজ করে না। এটি server-এ চালু হয়ে file পড়া ও command execute শুরু করলে ঝুঁকির ধরন বদলে যায়: ভুল command-এর ফলে কোনো service বন্ধ হয়ে যেতে পারে। root-এর পরিবর্তে agent-এর জন্য একটি নিজস্ব unprivileged user তৈরি করুন, এর আচরণ বুঝে নেওয়ার সময় production box থেকে এটিকে দূরে রাখুন, এবং প্রথমে একটি snapshot নিন। VPS-এ Claude Code নিরাপদে চালানো-এ sandboxing ও permission model ব্যাখ্যা করা হয়েছে। tmux-এর ভিতরে Claude Code চালানো অন্য সমস্যাটিও সমাধান করে, কারণ SSH (secure shell) session বিচ্ছিন্ন হলে foreground agent কাজের মাঝপথে বন্ধ হয়ে যায়। যেভাবে একটি service account তৈরি করতেন, সেভাবেই এই account তৈরি করুন; VPS-এ least privilege user-এ এর বিস্তারিত দেওয়া আছে।

FAQ

Claude কি সরাসরি আমার server logs পড়তে পারে?

নিজে থেকে পারে না। Chat interface-এ আপনি যে text paste করেন, সেটুকুই দেখা যায়। 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 excerpt prompt-এ পাঠানোর আগে tokens redact করুন। একটি কম-স্পষ্ট উদাহরণ হলো: docker compose config-এর output-এ আপনার .env values interpolated থাকে। তাই docker compose config -q ব্যবহার করুন। এটি file validate করে এবং কিছু print করে না।

Production VPS-এ Claude-কে commands চালাতে দেওয়া কি নিরাপদ?

Claude-কে এমন একজন নতুন admin হিসেবে বিবেচনা করুন, যার কোনো context নেই: পড়ার কাজ ঠিক আছে, লেখার কাজ review সাপেক্ষে। Production-এ explanation চাইুন এবং command নিজে চালান। Agent-কে দিয়ে command চালাতেই চাইলে blanket sudo ছাড়া একটি dedicated unprivileged account দিন। শুরুতে staging box ব্যবহার করুন, যাতে ভুল হলে outage-এর বদলে rebuild করতে হয়।

Claude এমন flag কেন প্রস্তাব করে, যা আসলে নেই?

কারণ এটি সম্ভাব্য text অনুমান করে, আর সম্ভাব্য flag ও আসল flag দেখতে একই রকম। Vendor CLI এবং নতুন subcommand-এর ক্ষেত্রে এটি বেশি ঘটে। এসব বিষয়ে model-এর পেছনের documentation সীমিত হতে পারে বা পরে পরিবর্তিত হয়ে থাকতে পারে। --help এবং man-ই চূড়ান্ত যাচাইয়ের উৎস। যেকোনো command যা delete বা overwrite করে, সেটি আগে dry run-এ চালানো উচিত।

Enable করার আগে systemd unit কীভাবে পরীক্ষা করব?

sudo systemd-analyze verify /etc/systemd/system/myapp.service চালান। এটি systemd-এর নিজস্ব parser দিয়ে file parse করে, line number-সহ অজানা directives জানায়, এবং missing বা executable নয় এমন ExecStart binary শনাক্ত করে। এরপর daemon-reload এবং start চালান, এবং systemctl status পড়ুন। তারপর enable করুন, কারণ কোনো unit পরিষ্কারভাবে load হলেও প্রথমবার চালানোর সময় ব্যর্থ হতে পারে।