সিস্টেম অ্যাডমিনদের দৈনন্দিন server কাজে Claude

সিস্টেম অ্যাডমিনদের জন্য Claude: প্রথমে পরামর্শ, পরে প্রয়োগ

সিস্টেম অ্যাডমিনদের কাজে Claude একটি reviewer হিসেবে সবচেয়ে ভালো কাজ করে। আপনি কোনো log excerpt, configuration file, অচেনা command বা error string দিলে, কোনো পরিবর্তন করার আগে যাচাই করা যায়—এমন একটি ব্যাখ্যা আপনি পেতে পারেন। ভুল উত্তরের কোনো ক্ষতি হয় না, যতক্ষণ না আপনি সেটি চালাচ্ছেন। তাই model-কে পরামর্শের সীমার মধ্যে রাখাই সম্পূর্ণ নিরাপত্তা পদ্ধতি।

ভাড়া নেওয়া Linux VPS (virtual private server)-এ প্রতি সপ্তাহে ছয় ধরনের কাজ বারবার আসে। নিচে প্রতিটির জন্য কার্যকর prompt pattern, উত্তরটি যাচাই করার command এবং প্রত্যাশিত failure mode দেওয়া হয়েছে। কোনো কাজের জন্যই model-এর আপনার server-এ access থাকা প্রয়োজন নেই।

Production box-এ কাজের ক্রম গুরুত্বপূর্ণ: ব্যাখ্যাটি পড়ুন, নিজে check চালান, তারপর সিদ্ধান্ত নিন। Scratch VM-এ autonomy গ্রহণযোগ্য। কিন্তু যে box আপনার customer-দের service দেয়, সেখানে review বেশি নিরাপদ, কারণ model যে অবস্থার অনুমান করছে, তা সে সরাসরি দেখতে পারে না।

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

Prompt-এ থাকা সবকিছু আপনার server-এর বাইরে চলে যায়। 4টি শ্রেণির তথ্য 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 বা PII (personally identifiable information) বহনকারী request log।

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

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

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

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

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

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

ব্যর্থতার ধরন: বানানো কারণ। খুব কম তথ্য paste করলে model ফাঁক পূরণ করতে generic কোনো কারণ বলে, যেমন "port ইতিমধ্যে ব্যবহৃত হচ্ছে"। এর প্রতিকার হলো একটি প্রশ্ন পাল্টা করা: "আমি যে তথ্য দিয়েছি, তার কোন line এই দাবিকে সমর্থন করে?" যে কারণের পক্ষে দেওয়া text-এ কেউ নির্দিষ্ট 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 করে, সেভাবেই এটি 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 হলেও চলার মুহূর্তে ব্যর্থ হতে পারে।

দুটি drafting mistake বারবার দেখা যায়। প্রথমটি হলো 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 সঙ্গে সঙ্গে exit করে। ফলে unit-টিকে dead হিসেবে চিহ্নিত করা হয়, আর প্রকৃত process unmanaged অবস্থায় চলতে থাকে।

কোনো 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 কখনও read হয় না। Terminal-এ command paste করলে যে job কাজ করে, cron-এর অধীনে সেটি /bin/sh: 1: docker: not found দিয়ে ব্যর্থ হতে পারে, কারণ ওই binary /usr/local/bin-এ রয়েছে। crontab-এ absolute path ব্যবহার করুন।

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

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

এই 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 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-ই intent যাচাই করে না। nginx -t পাস করা একটি config তবুও ভুল port-এ proxy করতে পারে, অথবা আপনি 127.0.0.1 চাইলেও 0.0.0.0-এ listen করতে পারে। এখানেই model-এর ব্যবহারিক মূল্য আছে, এবং এখানেই এটি ব্যর্থও হয়: একটি directive ঠিক করতে বললে এটি প্রায়ই পুরো file নতুন করে লিখে ফেরত দেয়, যেখানে আপনার দুটি directive নীরবে বাদ পড়ে। পরিবর্তিত line এবং প্রতিটির কারণ চাইুন। এরপর নিজে হাতে edit করুন।

আসলে কী expose করেছেন, তা নিশ্চিত করুন:

sudo ss -tulpn

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

কোনো অপরিচিত 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 যোগ করলে 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 ছাড়া চালালে ক্ষতির পরিবর্তে একটি তালিকা পাবেন।

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

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

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

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

জব 6: একটি error message-কে সমাধানে রূপ দিন

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

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

যা এটি নির্ভরযোগ্যভাবে ভুল করে

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

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

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

উপরের সবকিছু copy-and-paste ভিত্তিক, তাই model কখনো আপনার মেশিনে কাজ করে না। এটি server-এ চলতে শুরু করলে এবং file পড়া ও command চালানো শুরু করলে ঝুঁকির ধরন বদলে যায়: ভুল command এখন একটি service অচল করে দিতে পারে। root-এর পরিবর্তে agent-এর জন্য আলাদা unprivileged user তৈরি করুন, এর আচরণ বোঝার সময় production server থেকে দূরে রাখুন, এবং আগে একটি 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 log পড়তে পারে?

নিজে থেকে পারে না। Chat interface-এ আপনি যে text paste করেন, সেটুকুই দেখা যায়। Server-এ command line tool হিসেবে চালানো Claude Code, যে user এটি শুরু করেছে তার permission ব্যবহার করে file পড়তে এবং command চালাতে পারে। এটি তুলনামূলকভাবে বড় trust decision। সাধারণ support প্রশ্নের ক্ষেত্রে agent-কে shell access দেওয়ার চেয়ে redacted 100 line-এর একটি excerpt paste করা দ্রুত এবং নিরাপদ।

Server থেকে কোন জিনিস কখনো paste করা উচিত নয়?

Private key, .env file ও অন্যান্য credential store, /etc/shadow, এবং আপনার user-দের মালিকানাধীন যেকোনো data। Log excerpt prompt-এ দেওয়ার আগে token redacted করুন। একটি কম-স্পষ্ট উদাহরণ হলো: docker compose config-এর output-এ আপনার .env value interpolated থাকে। তাই docker compose config -q ব্যবহার করুন; এটি file validate করে এবং কোনো output দেয় না।

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

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

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

কারণ এটি সম্ভাব্য text অনুমান করে, আর সম্ভাব্য flag দেখতে বাস্তব flag-এর মতোই হয়। Vendor CLI এবং নতুন subcommand-এর ক্ষেত্রে এটি বেশি ঘটে, কারণ model-এর কাছে থাকা documentation অসম্পূর্ণ হতে পারে বা পরে পরিবর্তিত হয়ে থাকতে পারে। --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 directive-এর line number জানায়, এবং কোনো ExecStart binary অনুপস্থিত বা executable নয় কি না তা শনাক্ত করে। এরপর daemon-reload এবং start চালান। systemctl status পড়ে তারপর enable করুন, কারণ কোনো unit error ছাড়াই load হলেও প্রথম run-এ ব্যর্থ হতে পারে।