OpenVPN په شل کې کار کوي خو د cron لاندې ناکامېږي: ستونزه PATH ده

هماغه کمانډ له شل څخه نښلېږي او د cron لاندې مري، نو طبیعي پایله دا ده چې تونل یا سند ګناهکار دی۔ مخکې له دې چې په دې باور وکړئ، وګورئ چې دوه چلونې څه مشترک لري: باینري، ترتیبات او اعتبارنامې یو شان دي، او یوازې د پروسې چاپېریال بدل شوی دی۔ کله چې برنامه حتی ونه موندل شي، د TLS د سمون هېڅ اندازه مرسته نه کوي۔ سمون معمولاً په یوه لاره، یوه کاري فولډر او څو چاپېریالي متغیرونو کې وي، په VPN کې نه۔

command -v openvpn په هغه شل کې چې کار کوي ځواب چاپوي، او ډېری وخت /usr/sbin/openvpn وي، یعنې هغه فولډر چې cron یې په خپله پلټنې لاره کې نه ږدي۔

تونل هېڅکله پیل نه شو، نو تونل ستونزه نه ده

هغه کارونه چې cron پیلوي لږترلږه چاپېریال په میراث اخلي، معمولاً PATH=/usr/bin:/bin، او کوم کنټرول ټرمینل نه اخلي۔ هر څه چې په /usr/sbin یا /usr/local/sbin کې نصب دي، په ساده ډول له هغه لیست څخه غایب دي، او د لاګ کرښه د TLS غلطۍ پرځای openvpn: not found لولي۔ د Python subprocess په بل ډول ناکامېږي: دا د ژباړونکې پروسې چاپېریال په میراث اخلي، کوم چې ممکن له cron څخه بډایه وي خو لا هم د ټیلډا پرانیستلو لپاره شل نه لري۔ دواړه ناکامۍ مخکې له دې پېښېږي چې یو پاکټ هم کوربه پرېږدي۔

د هغوی د توپیر ژر لاره دا ده چې لومړنۍ تېروتنه ولولئ نه وروستنۍ۔ ورکه باینري د شل یا Python استثنا راولي، خراب ترتیب د OpenVPN کارولو پیغام راولي، او ریښتینې لاس ورکولو ناکامي وخت مهرونه او د سیال پتې راولي۔ یوازې درېیمه د تونل ستونزه ده۔

مطلقې لارې او د استدلال لیستونه د شل تارونو څخه غوره دي

حل شوې لاره په ښکاره توګه ورکړئ او شل په بشپړه توګه پرېږدئ۔ subprocess.run(["/usr/sbin/openvpn", "--config", config, "--verb", "4"], capture_output=True, text=True, timeout=90) تاسو ته د بیرته راستنېدو کوډ، stdout او stderr درکوي پرته له دې چې له شل څخه د فایل نوم تشریح وغواړئ۔ د ترتیباتو لاره له os.environ["HOME"] یا pathlib.Path.home() څخه جوړه کړئ، ترڅو ټیلډا هېڅکله پرانیستل نه شي۔ کله چې واقعاً د شل نحوې ته اړتیا لرئ، shlex.split وکاروئ، ځکه چې د .split() سره د تار وېشل په هره لاره کې چې تشه ولري ماتېږي۔ stderr هم ولولئ، ځکه OpenVPN خپلې ډېرې لومړنۍ ناکامۍ هم هلته لیکي۔

هماغه قاعده د cron لپاره هم ده: د کار کرښه د ننوتلو شل نه ده، نو هېڅ شی ستاسو پروفایل نه باروي او هېڅ شی ستاسو لقبونه نه تعریفوي۔

crontab واقعاً څه په میراث اخلي

د crontab ننوتنه هغه چاپېریال ترلاسه کوي چې crontab یې اعلانوي او څو میراثي ډیفالټ ارزښتونه، نو لاره بشپړ ولیکئ یا غوښتنه په داسې سکریپټ کې وتړئ چې دا کار کوي۔ د فایل په سر کې د PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin په څېر کرښه معمول د نصب ځایونه پوښي، او د >> cron.log 2>&1 سره بیاځلې لارښوونه هغه څه ده چې بل ناکامي لوستل کېدونکې کوي۔ د پاسفریز له خوا ساتل شوی پروفایل د cron لاندې د خپل راز غوښتلو لاره نه لري، ځکه د پوښتنې لپاره ټرمینل نشته۔ داسې اړیکه باید په systemd واحد کې وي چې د اعتبارنامې فایل لوستلی شي، نه په هغه کار کې چې ځان متقابل ښکاره کوي۔

نسبي لارې دوهمه تله ده۔ ازموینه ډېری وخت له هغه فولډر څخه کېږي چې پروفایل لري، او د cron کار په بشپړه توګه بل ځای پیلېږي، نو --config office.ovpn په داسې فایل حل کېږي چې هلته نه دی او پیغام د ورک تونل پرځای د ورک فایل په توګه لوستل کېږي۔

د چاپېریال په لرې کولو سره یې ثابت کړئ

لږترلږه چاپېریال مستقیم بیا جوړ کړئ: env -i PATH=/usr/bin:/bin /usr/sbin/openvpn --config office.ovpn --verb 4۔ له هغې چلونې څخه د لارې یا ټرمینل شکایت مانا دا ده چې ستونزه د VPN له پاسه ده۔ که نښلېږي، پاتې شکمن د هغه حساب چې تر لاندې یې کار کوي، هغه فولډر چې پکې پیلېږي، او هغه اعتبارنامه چې وړاندې کوي دي۔ د دواړو پایلو څخه هر یوه د سندونو د کتنې له بل پړاو څخه غوره ده۔

بیا پوښ د ځان راپور ورکوونکی کړئ۔ د هر هغه پړاو لپاره چې رسېدلی یې جدا حالت سره ووځئ، دواړه بهیرونه د وخت مهر سره لاګ کړئ، او بله ناکامي به تاسو ته ووایي چې آیا د لارې په حل، په تصدیق، یا وروسته له دې چې تونل لا پورته و مړ شو۔

واحد ته سم ترتیب هم اړین دی: Wants=network-online.target له After=network-online.target سره د پیلېدو مخه نیسي ترڅو د پتې یا ډیفالټ لارې شتون نه وي، کوم چې که نه وي د سند یا TLS د غلطیو په توګه ښکاري او په لاسي بیا پیل کېدو سره ورکېږي۔