محتوای آموزشی وبلاگ نت‌آرام
سرویس شما پس از انتقال سرور، نصب مجدد برنامه یا تغییر تنظیمات دیگر بالا نمی‌آید. دستور
systemctl status به جای اجرای برنامه، عبارت status=217/USER را نشان می‌دهد. معنای ساده‌اش این است که systemd در مرحله آماده کردن هویت کاربر یا فضای کاربریِ سرویس به مشکل خورده است. نام کاربری اشتباه یا حسابی که وجود ندارد علت‌های رایجی هستند، اما تنها علت‌های ممکن نیستند.در این راهنما اول مشخص می‌کنیم سرویس قرار است با کدام حساب اجرا شود؛ سپس بسته به نتیجه، نام اشتباه را اصلاح می‌کنیم یا حساب از دست‌رفته را با روش مناسب برمی‌گردانیم. هدف این نیست که برای خلاص شدن از خطا، همه برنامه‌ها را با کاربر قدرتمند root اجرا کنیم.
دستورهای نمونه برای یک سرویس سیستمی روی Ubuntu یا AlmaLinux نوشته شده‌اند. به SSH و کاربری با مجوز sudo نیاز دارید.
myapp.service و myappsvc نمونه هستند؛ نام واقعی سرویس و حساب مورد انتظار خود را جایگزین کنید. اگر این سرویس مربوط به یک محصول نصب‌شده است، پیش از تغییر نام کاربر یا ساخت حساب، مستندات همان محصول و نسخه آن را ببینید.۱. پیام دقیق خطا را پیدا کنید
در SSH وضعیت سرویس را ببینید:
کد / دستورsudo systemctl status myapp.service --no-pager -l
اگر در خروجی
status=217/USER می‌بینید، خطا مربوط به مرحله آماده‌سازی هویت یا فضای نام کاربری است. اگر به جای آن 203/EXEC دیده می‌شود، معمولاً باید مسیر یا اجرای فایل برنامه را بررسی کنید؛ راهنمای خطای 203/EXEC برای آن حالت نوشته شده است.حالا گزارش همین بوت را باز کنید:
کد / دستورsudo journalctl -u myapp.service -b --no-pager -n 80
خطوط نزدیک زمان شکست را بخوانید. عبارت‌هایی مانند نام کاربر نامعتبر، خطای lookup یا خطاهای مربوط به namespace سرنخ‌اند. ممکن است فقط کد ۲۱۷ ثبت شده باشد؛ در این حالت باید سراغ تنظیم و منبع حساب بروید. متن خروجی می‌تواند مسیرها و اطلاعات داخلی برنامه را نشان دهد، پس پیش از ارسال برای دیگران اطلاعات حساس را حذف کنید.
۲. سرویس با کدام حساب اجرا می‌شود؟
فایل اصلی و تنظیمات تکمیلی سرویس را با هم ببینید:
کد / دستورsudo systemctl cat myapp.service
در بخش
کد / دستور[Service] به User=، Group=، DynamicUser= و در صورت وجود PrivateUsers= توجه کنید. چند فایل ممکن است نمایش داده شود؛ تغییرات یک فایل تکمیلی می‌تواند روی مقدار نهایی اثر بگذارد. برای دیدن مقادیر مؤثر از systemd نیز استفاده کنید:systemctl show myapp.service -p User -p Group -p DynamicUser -p PrivateUsers
اگر در نسخه شما بعضی ویژگی‌ها نمایش داده نشدند، خروجی
systemctl cat و مستندات همان نسخه را ملاک بگیرید. خالی بودن User= در سرویس سیستمی لزوماً به معنی خطا نیست؛ حالت پیش‌فرض ممکن است اجرای سرویس با root باشد. نام واقعی حساب مورد انتظار را از راهنمای برنامه یا تنظیمات قبلی پیدا کنید، نه از روی حدس.فرض کنیم مقدار مؤثر
کد / دستورUser=myappsvc است و سرویس از کاربر پویا استفاده نمی‌کند. حالا بررسی کنید سیستم این نام را می‌شناسد:getent passwd myappsvc
اگر یک خط برگردد، حساب در منبع نام کاربران قابل پیدا کردن است. بخش سوم و چهارم خط معمولاً شناسه عددی کاربر و گروه هستند. اگر هیچ خطی برنگشت، نام را دوباره با مقدار سرویس مقایسه کنید. برای دیدن شناسه‌ها و گروه‌های آن حساب:
کد / دستورid myappsvc
پیام
کد / دستورno such user یعنی در همان لحظه حساب پیدا نشده است. اگر در سرویس Group= جداگانه تنظیم شده، وجود آن گروه را نیز با نام واقعی‌اش بررسی کنید:getent group myappgroup
خطای مربوط به گروه ممکن است کد متفاوتی مانند
216/GROUP داشته باشد. کاربر و گروه را یکسان فرض نکنید.۳. اگر نام کاربر در سرویس اشتباه است
فرض کنید مستندات برنامه می‌گویند حساب درست
کد / دستورmyappsvc است، این حساب با getent پیدا می‌شود، ولی در فایل سرویس نامی اشتباه نوشته شده است. به‌جای ویرایش مستقیم فایل متعلق به بسته، یک تنظیم تکمیلی بسازید:sudo systemctl edit myapp.service
ویرایشگر باز می‌شود. در بخش محتوای قابل ویرایش، این دو خط را با نام تأییدشده حساب خودتان بگذارید و فایل را ذخیره کنید:
کد / دستور[Service]
User=myappsvc
اگر ویرایشگر باز نشد یا تغییر ذخیره نشد، پیام آن را بخوانید؛ محل ویرایش در نسخه‌های مختلف ممکن است با خطوط راهنما مشخص شود. فقط وقتی
Group= هم اشتباه است و گروه درست را می‌شناسید، آن را جداگانه اصلاح کنید. تغییر کاربر ممکن است دسترسی به فایل‌های برنامه را عوض کند؛ بنابراین قبل از راه‌اندازی مجدد بررسی کنید حساب جدید واقعاً حساب مجاز همان برنامه است.systemd معمولاً هنگام ذخیره ویرایش، تنظیمات را بازخوانی می‌کند؛ برای اطمینان، بازخوانی و سپس مشاهده مقدار مؤثر را اجرا کنید:
کد / دستورsudo systemctl daemon-reload
کد / دستورsystemctl show myapp.service -p User -p Group
نام مورد انتظار باید در خروجی باشد. پیش از راه‌اندازی مجدد مطمئن شوید قطع کوتاه سرویس در آن زمان مجاز است:
کد / دستورsudo systemctl restart myapp.service
کد / دستورsudo systemctl status myapp.service --no-pager -l
اگر سرویس
active (running) شد، یک درخواست واقعی به برنامه بفرستید؛ فعال بودن سرویس به‌تنهایی سلامت کار برنامه را ثابت نمی‌کند.۴. اگر حساب وجود ندارد
ابتدا بفهمید چه اتفاقی افتاده است. اگر سرویس از بسته‌ای مثل وب‌سرور یا پایگاه داده آمده، حساب آن معمولاً بخشی از روش نصب محصول است. راهنمای نصب یا بازیابی همان محصول و نسخه را دنبال کنید؛ ساختن یک حساب با نام مشابه و شناسه عددی جدید ممکن است فایل‌های قدیمی را غیرقابل دسترس کند. اگر کاربران سازمان از LDAP یا Active Directory دریافت می‌شوند، در دسترس نبودن منبع هویت یا تنظیم اشتباه NSS نیز ممکن است موجب خالی بودن
getent شود. در آن حالت اتصال و سرویس هویت را با مدیر سازمان اصلاح کنید و یک حساب محلی همنام نسازید.برای بررسی اینکه سرویس قبلاً با چه شناسه‌ای به فایل‌های خودش دسترسی داشته، مسیر نمونه را با مسیر واقعی و مشخص برنامه جایگزین کنید:
کد / دستورls -ldn /srv/myapp
خروجی، مالک و گروه را به‌صورت عددی نشان می‌دهد. این دستور فقط همان پوشه را می‌خواند و مالک همه فایل‌ها را ثابت نمی‌کند. از اطلاعات نسخه پشتیبان، تنظیمات قبلی و مسئول برنامه برای تشخیص شناسه درست کمک بگیرید. به‌خصوص بعد از انتقال دیسک، یک نام یکسان با UID متفاوت می‌تواند به فایل‌های نامربوط دسترسی بدهد یا دسترسی لازم را قطع کند.
فقط برای برنامه سفارشی تازه‌ای که خودتان ساخته‌اید، هیچ مالکیت قدیمی برای بازیابی ندارد و مستند آن ایجاد حساب اختصاصی را لازم می‌داند، می‌توانید پس از اطمینان از آزاد بودن نام و سیاست سرور حساب سیستمی بسازید. ابتدا مسیر
کد / دستورnologin را پیدا کنید:command -v nologin
در اوبونتو معمولاً مسیر
کد / دستور/usr/sbin/nologin است؛ ممکن است در AlmaLinux مسیر دیگری مثل /sbin/nologin باشد. سپس با جایگزین کردن مسیر تأییدشده و نام مجاز خود:sudo useradd --system --no-create-home --shell /usr/sbin/nologin myappsvc
این دستور یک حساب سیستمی بدون ساخت پوشه خانگی می‌سازد و ورود تعاملی معمول را با آن پوسته محدود می‌کند. به‌خودی‌خود پوشه یا دسترسی برنامه را درست نمی‌کند. دوباره
getent passwd myappsvc و id myappsvc را اجرا کنید. دسترسی پوشه‌های لازم را طبق مستند برنامه و فقط در همان مسیرهای مشخص تنظیم کنید؛ دستورهای گسترده مثل chown -R روی مسیرهای نامعلوم می‌توانند مالکیت اطلاعات مهم را تغییر دهند.۵. اگر DynamicUser یا فضای کاربری استفاده می‌شود
وقتی
DynamicUser=yes فعال است، systemd می‌تواند هنگام شروع سرویس یک حساب موقت اختصاص دهد؛ نبودن آن در /etc/passwd قبل از شروع، به‌تنهایی نشانه خرابی نیست. یک حساب دائمی همنام نسازید و این گزینه را بدون بررسی خاموش نکنید. گزارش سرویس، نسخه systemd، تنظیمات بسته و شرایط محیطی مانند کانتینر یا محدودیت namespace را با مستندات محصول مقایسه کنید.برای ثبت نسخه systemd:
کد / دستورsystemctl --version
اگر خطا پس از تغییر تنظیمات امنیتی یا مهاجرت به محیط محدود ایجاد شده، همان تغییر را با مسئول زیرساخت بررسی و در صورت نیاز در محیط آزمایشی به وضعیت تأییدشده قبلی برگردانید. غیرفعال کردن کورکورانه
PrivateUsers یا اجرای سرویس با root ممکن است یک محافظ امنیتی را حذف کند.۶. وقتی کد خطا عوض شد چه کنیم؟
پس از اصلاح هویت، ممکن است خطای ۲۱۷ برطرف شود اما برنامه به دلیل مجوز فایل، مسیر اجرایی یا تنظیم خودش همچنان بالا نیاید. وضعیت و گزارش تازه را دوباره ببینید؛ به پیام جدید پاسخ دهید، نه به خطای قبلی. در پایان، هم وضعیت سرویس و هم کار واقعی آن، مثلاً پاسخ صفحه یا پردازش یک کار آزمایشی، باید درست باشد.
این راهکارها برای سرویس‌های لینوکسی روی سرور مجازی ایران و همچنین سرور اختصاصی ایران کاربرد دارند. توضیح رسمی تفاوت
User= و DynamicUser= و معنای کدها در مستند systemd.exec آمده است.اشتراک‌گذاری:
لینکدینتلگرامایکس
مقاله قبلی
مقاله قبلی وجود ندارد.
مقاله بعدی
دیدگاه‌ها (۰)
دیدگاه‌های تاییدشده و پاسخ‌های تیم نت‌آرام