کاربرد Claude برای مدیران سیستم و مدیریت سرور لینوکس

کلود برای مدیران سیستم: ابتدا مشاوره، سپس اجرا

کلود برای مدیران سیستم، در نقش بازبین بهترین عملکرد را دارد. شما بخشی از یک لاگ، یک فایل پیکربندی، دستوری که نمی‌شناسید یا یک رشته خطا را کپی می‌کنید و توضیحی دریافت می‌کنید که می‌توانید پیش از اعمال هر تغییری روی سرور، آن را بررسی کنید. پاسخ اشتباه تا زمانی که آن را اجرا نکنید هزینه‌ای برای شما ندارد، بنابراین نگه داشتن مدل در سمتِ «مشاوره» از این مرز، کل مدل ایمنی کار است.

هر هفته 6 وظیفه روی یک VPS (سرور مجازی) اجاره‌ای لینوکس پیش می‌آید. هر یک از موارد زیر دارای یک الگوی پرامپت کاربردی، دستوری برای اثبات پاسخ و حالت شکستی است که باید انتظارش را داشته باشید. هیچ‌کدام از این موارد نیازی ندارند که مدل به سرور شما دسترسی داشته باشد. شما می‌توانید از تب مرورگر یا پنجره‌ای در دسکتاپ خود کپی کنید، چرا که کلود به‌صورت بومی روی لینوکس هم به‌عنوان اپلیکیشن دسکتاپ و هم به‌عنوان CLI اجرا می‌شود.

ترتیب کار روی سرور عملیاتی اهمیت دارد: ابتدا توضیح را بخوانید، سپس خودتان بررسی را انجام دهید و در نهایت تصمیم بگیرید. خودمختاری در یک VM آزمایشی مشکلی ندارد. روی سروری که به مشتریان شما سرویس می‌دهد، بازبینی اولویت دارد، زیرا مدل نمی‌تواند وضعیتی را که درباره آن حدس می‌زند، مشاهده کند.

مواردی که هرگز نباید کپی کنید

همهٔ محتوایی که در prompt قرار می‌دهید، از سرور شما خارج می‌شود. چهار دسته از اطلاعات باید همیشه روی سرور باقی بمانند:

• کلیدهای خصوصی: ~/.ssh/id_ed25519، /etc/ssh/ssh_host_*_key و هر کلید TLS (امنیت لایه انتقال) در مسیر /etc/letsencrypt/live/.
• فایل‌های حاوی اعتبارنامه: .env، ~/.aws/credentials، /root/.docker/config.json و رمزهای عبور پایگاه داده در هر فایل یا خطی از لاگ‌ها.
• داده‌های حساب کاربری: /etc/shadow و /etc/gshadow. هیچ پرسش مدیریتی برای پاسخ داده شدن به هش رمز عبور نیاز ندارد.
• هر چیزی که متعلق به کاربران شماست: آدرس‌های ایمیل، ردیف‌های سفارش، لاگ‌های درخواست که حاوی کوکی‌های نشست یا PII (اطلاعات قابل شناسایی شخصی) هستند.

اشتراک‌گذاری کلیدهای عمومی بلامانع است. کلیدهای خصوصی نباید به اشتراک گذاشته شوند. از آنجا که این دو فایل در نگاه اول شبیه به هم هستند، پیش از کپی کردن، خط اول را بخوانید: فایلی که خط اول آن شامل BEGIN OPENSSH PRIVATE KEY است، هرگز نباید در prompt قرار بگیرد. مطالعهٔ مدیریت صحیح کلیدهای SSH به اندازه 10 دقیقه وقت گذاشتن ارزش دارد.

پیش از کپی کردن، اطلاعات حساس را حذف (Redact) کنید؛ به جای اینکه به خودتان اعتماد کنید که یک توکن را در میان 200 خط پیدا می‌کنید:

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 شما را در خروجی چاپ می‌کند؛ بنابراین آن خروجی حاوی اطلاعات محرمانه است، حتی اگر فایل روی دیسک چنین نباشد. از docker compose config -q استفاده کنید که فقط اعتبارسنجی را انجام می‌دهد و چیزی چاپ نمی‌کند. برای سیاست‌های کلی در مورد آنچه یک عامل (Agent) مجاز به دیدن آن است، مطلب دور نگه داشتن اسرار از عامل‌های هوش مصنوعی جنبه‌های محیطی را پوشش می‌دهد.

وظیفه 1: چرا این سرویس با شکست مواجه شد؟

با دو دستوری شروع کنید که پاسخ را در خود دارند:

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

هر دو را به همراه متنی که مدل نمی‌تواند حدس بزند جای‌گذاری کنید: توزیع و نسخه، آخرین تغییری که اعمال کردید، اینکه آیا قبلاً کار می‌کرده است یا خیر، و چه مدت پیش از کار افتاده است. ابتدا درباره مکانیزم پرسش کنید.

Ubuntu 24.04. myapp.service تا پیش از آنکه یک ساعت پیش unit را ویرایش کنم، به‌درستی کار می‌کرد. در اینجا systemctl status و 100 خط آخر journal را قرار می‌دهم. اولین خطای واقعی کدام است و چه معنایی دارد؟ هنوز هیچ اصلاحی انجام نشده است.

عبارت "هنوز هیچ اصلاحی انجام نشده است" (No fix yet) در این درخواست نقش مهمی ایفا می‌کند. لاگ‌ها اولین خطا را زیر انبوهی از تلاش‌های مجدد (retries) که خودشان ایجاد کرده‌اند، دفن می‌کنند؛ بنابراین اگر از مدل بخواهید که مشکل را اصلاح کند، آن مدل تنها آخرین خطی را که دیده است توضیح می‌دهد. خطی که اهمیت دارد معمولاً بیست خط بالاتر از این نویزها قرار دارد.

نتیجه، خطی مانند Main PID: 1841 (code=exited, status=203/EXEC) است. وضعیت خروج 203/EXEC به این معناست که هسته سیستم‌عامل نتوانسته فایلی را که در ExecStart نام برده شده اجرا کند: یا مسیر وجود ندارد، یا فایل وجود دارد اما قابل‌اجرا (executable) نیست. یک خط #! که مفسری را نام می‌برد که نصب نشده است، وضعیت مشابهی ایجاد می‌کند. تمام این موارد با ls -l و head -1 قابل‌تست هستند.

حالت شکست: علت اختراعی. اگر اطلاعات کمی جای‌گذاری کنید، مدل شکاف را با یک دلیل کلی پر می‌کند، مثلاً "پورت در حال استفاده است". درمان این مشکل، یک پرسش بازگشتی است: "کدام خط در متنی که به شما دادم، این ادعا را تأیید می‌کند؟" علتی که هیچ‌کس نتواند در متن به آن اشاره کند، صرفاً یک حدس است.

وظیفه 2: پیش‌نویس یک systemd unit یا یک ورودی cron

اطلاعات مورد نیاز فایل unit را مشخص کنید: دستور دقیق، کاربری که آن را اجرا می‌کند، دایرکتوری کاری، اینکه آیا باید منتظر شبکه بماند یا خیر، و در صورت خروج با کد غیر صفر چه اتفاقی باید بیفتد. سپس پیش از فعال‌سازی هر چیزی، خروجی را بررسی کنید.

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 می‌خواند، تجزیه می‌کند؛ بنابراین خطاهایی را که از چشم انسان پنهان می‌ماند، شناسایی می‌کند. یک دستورالعمل اشتباه تایپ‌شده، /etc/systemd/system/myapp.service:7: Unknown key name 'Enviroment' in section 'Service', ignoring. را چاپ می‌کند. یک فایل اجرایی گم‌شده، Command /usr/local/bin/myapp is not executable: No such file or directory را چاپ می‌کند. هر دو در حین daemon-reload ساکت می‌مانند، به همین دلیل است که یک unit ممکن است بدون خطا بارگذاری شود اما در لحظه اجرا شکست بخورد.

دو اشتباه در پیش‌نویس‌نویسی مدام تکرار می‌شوند. اولی After=network.target است که فقط به این معنی است که پشته شبکه پیکربندی شده، نه اینکه لزوماً آدرسی وجود داشته باشد. سرویسی که به یک IP خاص متصل می‌شود، در زمان boot با bind: Cannot assign requested address شکست می‌خورد و راه‌حل آن استفاده از Wants=network-online.target به همراه After=network-online.target است. دومی Type=simple برای برنامه‌ای است که daemonize می‌شود: systemd اولین پردازش را به عنوان سرویس در نظر می‌گیرد، والد بلافاصله خارج می‌شود و unit به عنوان dead علامت‌گذاری می‌شود، در حالی که پردازش اصلی همچنان بدون مدیریت به کار خود ادامه می‌دهد. این اشتباهی است که مدل‌ها احتمالاً به شما تحویل می‌دهند، زیرا نمی‌توانند از روی دستور شما تشخیص دهند که آیا فایل اجرایی fork می‌کند یا خیر؛ بنابراین ارزشش را دارد که پیش از پذیرش پیش‌نویس، بدانید هر مقدار Type= چه تعهدی به systemd می‌دهد.

برای یک زمان‌بندی، به جای خواندن آن، آن را بررسی کنید:

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

این دستور فرم نرمال‌شده و زمان بعدی اجرای عبارت را چاپ می‌کند که هرگونه بحث درباره معنای آن را پایان می‌دهد. اگر بین یک timer و یک crontab تردید دارید، سرویس‌ها و تایمرهای systemd روی یک VPS تفاوت‌ها را بررسی کرده است.

Cron تله‌ای دارد که هیچ مدلی درباره آن به شما هشدار نمی‌دهد مگر اینکه بپرسید. Cron کارها را با یک محیط حداقلی اجرا می‌کند، بنابراین PATH تقریباً برابر با /usr/bin:/bin است و پروفایل shell شما هرگز خوانده نمی‌شود. کاری که وقتی آن را در ترمینال خود کپی می‌کنید کار می‌کند، در cron با /bin/sh: 1: docker: not found شکست می‌خورد، زیرا آن فایل اجرایی در /usr/local/bin قرار دارد. در crontabها از مسیرهای مطلق استفاده کنید. اگر اصرار فایل unit بر تعیین کاربر، محیط و وابستگی‌ها در مقایسه با یک خط crontab ساده، بیش از حد تشریفاتی به نظر می‌رسد، مشکلاتی که systemd برای حل آن‌ها ساخته شد توضیح می‌دهد که این پرگویی از کجا ناشی می‌شود.

وظیفه 3: بررسی فایل Nginx یا Compose پیش از عملیاتی کردن

این وظیفه بیشترین بازدهی را دارد. فایل را جای‌گذاری کنید، هدف آن را شرح دهید و بخواهید خط‌به‌خط توضیح دهد که در واقع چه کاری انجام می‌دهد.

این vhost باید example.com را از طریق HTTPS ارائه دهد و /api را به یک سرویس محلی روی پورت 8080 پروکسی کند. آن را برای من بازخوانی کنید و هر چیزی که با این توصیف مطابقت ندارد را نام ببرید.

سپس ابزاری را اجرا کنید که گرامر را می‌شناسد:

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 نمایش می‌دهد.

هیچ‌کدام از این ابزارها قصد (intent) شما را بررسی نمی‌کنند. پیکربندی‌ای که از nginx -t عبور می‌کند، همچنان ممکن است به پورت اشتباه پروکسی کند یا روی 0.0.0.0 گوش دهد در حالی که منظور شما 127.0.0.1 بوده است. این شکاف همان جایی است که مدل ارزش خود را نشان می‌دهد و البته همان جایی است که ممکن است شکست بخورد: وقتی از آن می‌خواهید یک دستورالعمل را اصلاح کند، اغلب کل فایل را بازنویسی کرده و دو مورد از دستورالعمل‌های شما را بی‌سروصدا حذف می‌کند. از مدل بخواهید فقط خطوط تغییریافته و دلیل هر تغییر را ارائه دهد، سپس خودتان به‌صورت دستی ویرایش کنید.

آنچه واقعاً در معرض دید قرار داده‌اید را تأیید کنید:

sudo ss -tulpn

بدون sudo، شما سوکت‌های در حال گوش دادن را می‌بینید اما پردازش‌هایی که مالک آن‌ها هستند را مشاهده نمی‌کنید. اگر این خروجی شما را غافلگیر کرد، پورت‌ها چیستند و لینوکس چگونه آن‌ها را bind می‌کند مطالعه کوتاه‌تری است.

وظیفه 4: پیش از اجرای یک دستور ناآشنا، آن را تحلیل کنید

دستور را کپی کنید و چهار پرسش درباره آن بپرسید: هر فلگ چه کاری انجام می‌دهد، چه چیزی می‌نویسد، چه چیزی را حذف می‌کند و اگر آن را دو بار اجرا کنم چه اتفاقی می‌افتد؟ پرسش آخر، آسیب‌های احتمالی بیشتری را نسبت به سایر موارد آشکار می‌کند.

find /var/log -name '*.gz' -mtime +7 -delete را در نظر بگیرید. یک پاسخ مناسب به شما می‌گوید که -mtime +7 دوره‌های کامل 24 ساعته را محاسبه کرده و کسر باقی‌مانده را نادیده می‌گیرد، بنابراین فایل‌هایی با حداقل 8 روز قدمت را پیدا می‌کند، نه 7 روز. همچنین به شما می‌گوید که find عبارت خود را از چپ به راست ارزیابی می‌کند، بنابراین جابه‌جایی -delete به قبل از -name، همه چیز را در مسیر شروع حذف می‌کند. آن نکته دوم در صفحه راهنمای find به عنوان یک هشدار ذکر شده و برای بسیاری افراد به قیمت از دست رفتن /var/log تمام شده است.

یا rsync -a --delete /srv/app/ /backup/app/ را در نظر بگیرید. اسلش انتهایی در مبدأ به معنای «محتویات این دایرکتوری» است. اگر آن را حذف کنید، نتیجه /backup/app/app/ خواهد بود. اگر --delete را اضافه کنید، هر چیزی که در مقصد وجود دارد و در مبدأ نیست حذف می‌شود؛ این رفتار برای یک mirror صحیح است، اما اگر مسیر مبدأ اشتباه باشد، یک فاجعه به بار می‌آورد.

با استفاده از ابزار تأیید کنید، نه با مدل:

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

find را بدون -delete اجرا کنید تا به جای از دست دادن داده‌ها، فقط یک لیست دریافت کنید.

حالت شکست: توهم در فلگ‌ها. مدل در مورد ابزارهایی که 30 سال مستندات دارند قابل‌اعتماد است، اما در مورد CLIهای (رابط خط فرمان) اختصاصی و زیردستورهای جدید ضعیف‌تر عمل می‌کند؛ جایی که ممکن است فلگی را پیشنهاد دهد که کاملاً منطقی به نظر می‌رسد اما وجود خارجی ندارد. --help این موضوع را در یک ثانیه مشخص می‌کند. کوتیشن‌گذاری (Quoting) نقطه ضعف دیگر است، بنابراین وقتی یک دستور، عبارتی از $(...) را در بر می‌گیرد، به جای اعتماد به توضیحات، نحوه بسط جایگزینی دستور پیش از اجرای آن را مطالعه کنید.

وظیفه 5: تبدیل تاریخچه شل به کتابچه راهنمای عملیاتی (Runbook)

شما به‌تازگی دو ساعت وقت صرف کرده‌اید تا چیزی را به کار بیندازید. این دانش در اسکرول‌بک (scrollback) ترمینال شما باقی مانده و ماه آینده از بین خواهد رفت.

history 200 > /tmp/session.txt

آن فایل را بخوانید و پیش از انتقال به هر جای دیگر، تمام خطوط حاوی رمز عبور، توکن یا شناسه‌های مشتری را حذف کنید. تاریخچه شل یکی از مطمئن‌ترین مکان‌ها برای یافتن اسرار در یک سیستم لینوکسی است، زیرا هر کسی حداقل یک بار رمز عبور خود را در خط فرمان تایپ می‌کند. مقدار HISTCONTROL=ignorespace را در فایل ~/.bashrc خود تنظیم کنید تا دستوری که با یک فاصله (space) شروع می‌شود، هرگز در تاریخچه ثبت نشود.

پرامپتی که یک کتابچه راهنمای عملیاتی (runbook) قابل استفاده تولید می‌کند، علاوه بر مراحل، درخواست بررسی (check) نیز دارد:

این یک نشست شل است که یک سیستم Debian 13 خام را به یک نصب فعال Postgres رسانده است. آن را به صورت یک کتابچه راهنمای شماره‌گذاری‌شده بنویس. هر مرحله شامل یک دستور باشد. پس از هر مرحله، دستوری را بنویس که صحت عملکرد آن را اثبات کند و خروجی سالم را توصیف کن. هر مرحله‌ای که به مشخصات خاص میزبان من وابسته بوده است را علامت‌گذاری کن.

حالت شکست: یک داستان مرتب و تمیز. نشست شما شامل مرحله‌ای بوده که دو بار اشتباه انجام داده‌اید و سپس اصلاح کرده‌اید؛ این همان مرحله‌ای است که مدل آن را حذف می‌کند، زیرا متن بدون آن تمیزتر به نظر می‌رسد. کتابچه راهنما را با تاریخچه خود مقایسه کنید و اصلاحات را بازگردانید. مدل همچنین ممکن است دستورات تأییدیه قابل‌قبولی را از خود بسازد، بنابراین پیش از ذخیره فایل، هر بررسی که نوشته شده است را اجرا کنید. اگر کتابچه راهنما مربوط به اولین بوت سیستم است، آن را با ده دقیقه اول روی یک VPS جدید مقایسه کنید تا نسخه بدتری از یک مشکل حل‌شده را ثبت نکنید.

وظیفه 6: تبدیل یک پیام خطا به یک راهکار

رشته دقیق خطا، دستوری که آن را تولید کرده و تنها تغییری که پیش از ظاهر شدن آن اعمال کردید را وارد کنید. از مدل بخواهید دلایل احتمالی را رتبه‌بندی کند و برای هر کدام یک دستور متمایز ارائه دهد تا پاسخ به چیزی قابل آزمایش تبدیل شود.

nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use). دلایل احتمالی را رتبه‌بندی کنید و برای هر دلیل، دستوری ارائه دهید که آن را تأیید یا رد کند.

برای این خطا، مکانیزم مبهم نیست: یک پردازش دیگر هم‌اکنون پورت 80 را در اختیار دارد و sudo ss -tulpn | grep ':80 ' نام آن را مشخص می‌کند. اغلب این مشکل ناشی از یک master process مربوط به Nginx است که پس از یک reload ناموفق باقی مانده، یا Apache است که به عنوان یک dependency نصب شده و توسط پکیج خود شروع به کار کرده است.

حالت شکست: راهکاری که با پنهان کردن علت اصلی کار می‌کند. chmod 777، --privileged، غیرفعال کردن SELinux و اجرای سرویس با کاربر root همگی باعث ناپدید شدن خطا می‌شوند. هر راهکاری که دسترسی‌ها را بدون توضیح مدل درباره علت شکست دسترسی محدود، افزایش دهد، رد کنید. آن توضیح، پاسخ واقعی است. یک workaround فقط خطا را ساکت می‌کند.

آنچه به‌طور قابل‌اعتمادی اشتباه متوجه می‌شود

• این ابزار نمی‌تواند سرور شما را ببیند. هر پاسخ تابعی از متنی است که شما جای‌گذاری کرده‌اید و به شما نمی‌گوید که متن ارسالی بیش از حد کوتاه بوده است.
• در مورد نسخه‌ها دچار انحراف می‌شود. نام بسته‌ها و فلگ‌های پیش‌فرض بین توزیع‌ها و نسخه‌های مختلف تغییر می‌کنند و مدل میانگینی از همه آن‌ها را ارائه می‌دهد.
• وقتی اشتباه می‌کند، بسیار سلیس و متقاعدکننده است. یک مکانیزم توهمی دقیقاً مانند یک مکانیزم صحیح خوانده می‌شود؛ به همین دلیل است که برای هر علت ذکر شده در بالا، دستوری برای تست کردن آن ارائه شده است.
• در نشست‌های طولانی، رشته کلام را از دست می‌دهد. حقایقی که در ابتدای یک گفتگوی دو ساعته مطرح شده‌اند، در انتهای گفتگو دیگر بر پاسخ‌ها تأثیرگذار نیستند.

مورد آخر بیشتر یک مشکل کاری است تا یک مشکل مربوط به مدل، و مدیریت کانتکست در یک نشست طولانی Claude Code راهکار عملی آن است: نشست‌های کوتاه‌تر و انجام هر بار فقط یک وظیفه.

قرار دادن عامل روی خود سرور

تمام موارد بالا کپی و پیست هستند، بنابراین مدل هرگز به دستگاه شما دسترسی مستقیم ندارد. هنگامی که عامل روی سرور اجرا می‌شود و شروع به خواندن فایل‌ها و اجرای دستورات می‌کند، ماهیت ریسک تغییر می‌کند: یک دستور اشتباه اکنون می‌تواند منجر به از دست رفتن یک سرویس شود. به جای استفاده از کاربر root، یک کاربر با دسترسی محدود (unprivileged) برای آن ایجاد کنید، تا زمانی که با رفتار آن آشنا نشده‌اید آن را روی سرور عملیاتی (production) اجرا نکنید و ابتدا یک snapshot تهیه کنید. اجرای ایمن Claude Code روی یک VPS به مباحث sandbox و مدل مجوزها می‌پردازد. اجرای Claude Code درون tmux نیمه دیگر مشکل را حل می‌کند، زیرا قطع شدن نشست SSH (secure shell) باعث می‌شود عامل در میانه کار متوقف شود. حساب کاربری را همان‌طور بسازید که هر سرویس دیگری را می‌سازید؛ موضوعی که در کاربران با حداقل دسترسی روی یک VPS به تفصیل توضیح داده شده است.

FAQ

آیا Claude می‌تواند لاگ‌های سرور من را مستقیماً بخواند؟

به‌تنهایی خیر. رابط کاربری چت فقط متنی را می‌بیند که شما در آن کپی می‌کنید. ابزار Claude Code که به‌عنوان یک ابزار خط فرمان روی سرور اجرا می‌شود، می‌تواند فایل‌ها را بخواند و دستورات را با مجوزهای کاربری که آن را اجرا کرده است، اجرا کند؛ این موضوع یک تصمیم امنیتی مهم‌تر است. برای پرسش‌های پشتیبانی معمولی، کپی کردن یک بخش 100 خطیِ ویرایش‌شده (redacted)، سریع‌تر و امن‌تر از دادن دسترسی shell به یک عامل (agent) است.

چه مواردی را هرگز نباید از سرور کپی و ارسال کنم؟

کلیدهای خصوصی (private keys)، فایل‌های .env و سایر مخازن اعتبارنامه، /etc/shadow، و هرگونه داده‌ای که متعلق به کاربران شماست. پیش از ارسال لاگ‌ها به پرامپت، توکن‌ها را از متن حذف کنید. یک مورد غیربدیهی: خروجی docker compose config مقادیر .env شما را در متن جای‌گذاری می‌کند؛ بنابراین از docker compose config -q استفاده کنید که فایل را اعتبارسنجی کرده و خروجی متنی نمایش نمی‌دهد.

آیا اجازه دادن به Claude برای اجرای دستورات روی یک VPS عملیاتی (Production) امن است؟

با آن مانند یک مدیر سیستم جدید که هیچ پیش‌زمینه‌ای ندارد رفتار کنید: برای خواندن مناسب است، اما برای نوشتن نیاز به بازبینی دارد. در محیط عملیاتی، از او بخواهید دستور را توضیح دهد و سپس خودتان آن را اجرا کنید. اگر قصد دارید یک عامل (agent) دستورات را اجرا کند، یک حساب کاربری اختصاصی و بدون امتیاز (unprivileged) بدون دسترسی sudo کامل به آن بدهید و ابتدا در یک محیط staging تست کنید که در آن یک اشتباه، به‌جای قطعی سرویس، فقط نیاز به بازسازی محیط داشته باشد.

چرا Claude فلگی (flag) را پیشنهاد می‌دهد که وجود ندارد؟

زیرا این مدل متن‌های محتمل را پیش‌بینی می‌کند و یک فلگِ محتمل، مشابه یک فلگ واقعی به نظر می‌رسد. این اتفاق بیشتر در CLIهای فروشندگان و زیردستورهای (subcommands) جدید رخ می‌دهد که مستندات پشت مدل برای آن‌ها ضعیف است یا تغییر کرده‌اند. --help و man مرجع نهایی هستند و هر دستوری که باعث حذف یا بازنویسی فایل‌ها می‌شود، ابتدا باید به‌صورت آزمایشی (dry run) اجرا شود.

چگونه یک unit در systemd را پیش از فعال‌سازی بررسی کنم؟

دستور sudo systemd-analyze verify /etc/systemd/system/myapp.service را اجرا کنید. این دستور فایل را با استفاده از پارسر خودِ systemd تحلیل می‌کند، دستورالعمل‌های ناشناخته را با شماره خط گزارش می‌دهد و اگر یک فایل باینری ExecStart وجود نداشته باشد یا قابل اجرا نباشد، هشدار می‌دهد. سپس daemon-reload و start را اجرا کنید و پیش از enable کردن، systemctl status را بخوانید؛ چرا که یک unit که به‌درستی بارگذاری می‌شود، ممکن است در اولین اجرا با خطا مواجه شود.