الخدمة التي تبدأ بالعمل ليست سوى الخطوة الأولى.

نقطة البداية.

نشرت FreeRADIUS في بيئة Linux قائمة على Docker ضمن أعمالي في البنية التحتية. وكان على الحاوية أن تبدأ العمل بشكل موثوق وأن تقرأ ملفات الإعداد المُركَّبة فيها، دون كشف منافذ المصادقة على نطاق أوسع مما هو مقصود.

ما قمت به.

1. تحققت من حساب الخدمة في صورة الحاوية ومن مسارات الإعداد. وكان الحساب freerad يستخدم UID وGID بالقيمة 101 في الصورة التي فحصتها.
2. شخّصت مشكلة في أذونات الإعداد، وصحّحت ملكية المجموعة لملفات الإعداد المُركَّبة بدلًا من جعلها قابلة للكتابة من قِبل الجميع.
3. تأكدت من أن الحاوية ظلت قيد التشغيل، وفحصت ربط منافذ UDP. وخلال الاختبار المسجَّل، كان المنفذان 1812 و1813 مربوطين بعنوان loopback.

القرارات والمفاضلات.

فحص الحالة الصحية للخدمة وحدود الوصول.

أوامر مُعاد بناؤها، تقتصر على القراءة. ولا تتضمن أسرارًا مشتركة، ولا عناوين شبكة فعلية، ولا ملفات إعداد مُصدَّرة.

docker inspect --format \
  'Status={{.State.Status}} Restarts={{.RestartCount}}' freeradius

docker port freeradius

docker exec freeradius sh -c \
  'id freerad || id radius; for d in /etc/raddb /etc/freeradius; do [ -e "$d" ] && ls -ld "$d"; done; true'

# Confirm the intended bind address, not just the port number.

ما تحققت منه.

تحققت من حساب الخدمة، وفحصت علاقته بمجلد الإعداد، وراجعت حالة الحاوية وعدد مرات إعادة تشغيلها، ودققت في ربط المنافذ المنشورة. وقد أرسى ذلك خط أساس مستقرًا لخدمة محلية، لا نشرًا كاملًا للوصول إلى الشبكة في بيئة الإنتاج.