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 ભૂલો તરીકે દેખાય છે જે જાતે રીસ્ટાર્ટ કરવાથી અદૃશ્ય થઈ જાય છે.