د -.mount واحد پټ شوی: د OpenVPN کلاینټ به پیل نشي

ستاسو خدمت د OpenVPN له چلېدو دمخه ناکامېږي، او تېروتنه د یوه نښلولو واحد په اړه خبرې کوي چې تاسو هیڅکله نه دی تنظیم کړی. دا هغه نښه ده: systemd ټوله معامله ردوي ځکه چې د ریښې د نښلولو واحد پټ شوی، او ستاسو VPN پروفایل لا نه دی لوستل شوی. عادي لامل په اجرا وخت د واحدونو په پوښه کې پاتې فایل دی، نه خراب fstab او نه ورک شوی سند. لومړی فایل تعقیب کړئ، ځکه چې دا د ردولو تر ټولو ارزانه توضیح ده.

تېروتنه د ریښې نښلول نوموي، نه ستاسو پروفایل

systemd پخپله د ریښې د نښلولو واحد د کرنل د نښلولو له معلوماتو جوړوي او واحد ته -.mount نوم ورکوي، ځکه چې کرښه د ریښې لار استازیتوب کوي. دا واحد معمولاً یوازې په حافظه کې وي او تر شا یې فایل نه وي. کله چې تېروتنه وایي چې پټ شوی، یو چا د واحد فایل هلته اېښی چې systemd به یې بار کړي او هغه فایل /dev/null ته اشاره کړی. پټول یو ریښتینی حالت دی، نه په پیغام کې د ټایپ تېروتنه.

د نمونې واحد ناکامېږي ځکه چې د دندو ګراف یې د ترتیب او د خپلو نښلولو غوښتنو له لارې ریښې نښلولو ته رسېږي. معامله د OpenVPN د باینري فایل له اجرا دمخه ردېږي، نو په کلاینټ ترتیباتو کې هېڅ شی نشي کولی لامل وي. ځکه د پروفایلونو، سندونو یا اعتبارنامو بدلول په دې ځانګړي ناکامۍ هېڅ اغېزه نه لري.

د OpenVPN له اصلاح کولو دمخه د اجرا وخت پوښه وګورئ

په اجرا وخت د واحدونو په پوښه کې د همدې دقیق نوم فایل ولټوئ، بیا له systemd وپوښتئ چې واحد څه ګڼي. دواړه ځوابونه ژر دي، او یوځای پاتې فایل له ریښتیني نښلولو ستونزې جلا کوي.

ls -l /run/systemd/system/-.mount
systemctl status -.mount
systemctl list-unit-files --state=masked | grep mount

عادي ماشین داسې فایل نه لري، او د پټ شویو په لیست کې د ریښې نښلول نشته. که لومړی حکم /dev/null ته سمبوليک تړاو چاپ کړي، تشخیص ټینګ دی. په همدې پوښه کې کېدای شي همدغو وسایلو جوړ کړی tmp.mount پټون وي، او هغه په بل نوم کې همدغه ډول ناکامي پیدا کوي. ټوله پوښه وګورئ، نه یوازې په تېروتنه کې نوم.

ls -la /run/systemd/system/*.mount

که پوښه پاکه وي او واحد لا هم پټ وي، پټون په لټون لار کې بل ځای کې دی، او systemctl cat -.mount به وښیي کوم فایل بارېږي.

فایل حذف کړئ، بیا بار کړئ او بیا پیل کړئ

د اجرا وخت فایل لرې کول او مدیر بیا بار کول بس دي، او له بستې راغلي هېڅ شي ته نه رسېږي. له پیل دمخه بیا بار کړئ، ځکه systemd د بار شوي واحد حالت ساتي ترڅو پوښه بیا ولولي.

sudo rm -f /run/systemd/system/-.mount /run/systemd/system/tmp.mount
sudo systemctl daemon-reload
systemctl status -.mount
sudo systemctl start [email protected]

بیا د خدمت خپل ژورنال ولولئ پرځای د دې چې فکر وکړئ اصلاح یې کار وکړ. پاک پیل یوازې دا ثابتوي چې systemd واحد ومنه؛ کلاینټ لا هم کېدای شي د ورک پروفایل، د نه رسېدونکي سیال یا د نه تصدیقېدونکي سند له امله مړ شي. دا د OpenVPN عادي ستونزې دي چې د پټ شوي واحد تر شا پټې وې. ژورنال لیکي کوم پروفایل بار شو او ایا تونل واقعاً جوړ شو. که واحد پیل شي او تونل نه، تاسو بلې ستونزې ته تللي یاست، او دا پرمختګ دی.

journalctl -u [email protected] -b --no-pager

څرنګه چې /run یو لنډمهاله فایل سیسټم دی، بیا پیلول فایل هم پاکوي. دا بیا پیلول ګټور ازموینه جوړوي: که خدمت له بیا پیلولو وروسته کار وکړ او د راتلونکي ځای پرځای کولو وروسته بیا ناکام شي، فایل په انځور کې پخېږي.

د انځور څخه د هغه د بېرته راتلو مخه ونیسئ

د کانټینر یا مجازي ماشین کالب چې د جوړېدو پر مهال نښلولو واحدونه پټوي، هغه پټون به هر کاپي ته یوسي. بل شی چې فایل سیسټم ته اړتیا لري ماتېږي، او پیغام نښلول ګرم بولي نه انځور چې له هغه راغلی. په یوه روانه نمونه کې اصلاح کول ستونزه تر راتلونکې نمونې جوړېدو پټوي.

په جوړېدو کانتکست کې د فایل نوم او هغه حکم ولټوئ چې جوړوي یې، بیا پټون له کالب څخه لرې کړئ او بیا جوړ یې کړئ. که پټون واقعاً د جوړېدو پر مهال اړین وي، په هماغه پوړ کې یې لرې کړئ چې جوړېدل پای ته رسوي، ترڅو لېږل شوی انځور پاک پیل شي. په نوې کاپي کې تصدیق کړئ نه په هغه ماشین چې په لاس مو اصلاح کړی. دا یوازینۍ ازموینه ده چې ثابتوي انځور بدل شوی.

هغه نښه چې باید په یاد وساتئ د تېروتنې او هغه څه ترمنځ ناسمونې ده چې تاسو یې تنظیمول. کله چې systemd د نښلولو شکایت کوي او تاسو د VPN کلاینټ پیلوئ، لومړی په پیغام کې د واحد نوم ولولئ او بیا د خدمت نوم.