د systemd خدمت پراکسي ته رسېږي، خو CA فایل ته نه

تاسو منل شوې CA ټولګه نصب کړې او غوښتنه په ټرمینل کې کار کوي. خدمت لا د سند د بارولو تېروتنه ښيي. د پراکسي IP له بدلولو مخکې وګورئ چې پروسه هماغه فایل پرانیستلای شي که نه.

خدمت د بل Unix کاروونکي په نوم چلېدای شي، په بله ډایرکټرۍ کې پیلېدای یا محدود فایل سیستم لیدلای شي. هغه لاره چې ستاسو ننوتلو ته سمه ده، په اوتومات ډول خدمت ته سمه نه ده.

له مطلقې لارې پیل وکړئ

په رښتیني کلاینټ کې ټاکل شوې لاره وګورئ. د بېلګې په توګه، په curl کې --cacert د موخې CA ټولګه ټاکي؛ HTTPS پراکسي جلا پراکسي CA انتخابونه لري. نور کلاینټونه خپل تنظیماتي کیلي یا چاپېریالي متغیرونه کاروي.

فایل او هغه ته رسوونکې ډایرکټرۍ دواړه وګورئ:

namei -l /home/alex/certs/approved-ca.pem
systemctl show example.service -p User -p Group -p ProtectHome -p RootDirectory

دا تشخیصي بېلګې دي، نه د ټولو لپاره د فایل د لیکلو اجازه ورکولو لارښوونې. د ډایرکټریو له منځه د تېرېدو اجازه هم د وروستي فایل د لوستلو هومره مهمه ده.

اجازې ښايي ټوله ستونزه نه وي

له ProtectHome=yes سره systemd د کور ډایرکټریو عادي ځایونه خدمت ته د لاسرسي وړ نه پرېږدي. د سند فایل حالت بدلول د نوم فضا محدودیت نه لرې کوي. ټاکل شوې ریښه ډایرکټري هم د خدمت دننه د مطلقې لارې معنا بدلولای شي.

د خدمت تنظیم لپاره مناسب ځای وکاروئ، لکه د اپلېکېشن لپاره ډایرکټري تر /etc لاندې، او یوازې اړینه لوست اجازه ورکړئ. د کلاینټ CA لاره بدله کړئ. یوازې ځکه چې لومړۍ کاپي ستاسو شخصي کور ډایرکټرۍ کې وه، نامربوط فایلي محدودیتونه مه لرې کوئ.

لومړۍ ګټوره تېروتنه ولولئ

«CA فایل نه شي بارېدای» او «د سند لړۍ باوري نه ده» جلا تېروتنې دي. لومړۍ د هر ډول تایید تر مخه راتلای شي. دویمه ښايي دا وي چې لوستل کېدونکې ټولګه ناسمه اداره لري یا پر ناسم TLS اتصال کارول کېږي.

له لاسرسي سمولو وروسته د خدمت له سیاقه بیا وازمویئ. بریالی ټرمینل امر لا ګټوره پرتله ده، خو نه ثابتوي چې خدمت کوم فایلونه ویني یا کلاینټ کوم باور تنظیم کاروي.