OpenVPNની બહુવિધ --up સ્ક્રિપ્ટોની ચેતવણી: ફક્ત એક જ ચાલે છે

બહુવિધ સ્ક્રિપ્ટોની ચેતવણી શેડ્યુલિંગની ફરિયાદ જેવી સંભળાય છે, તેથી સ્પષ્ટ ઉકેલ એ છે કે લાઇનો ફરીથી ગોઠવો જ્યાં સુધી તે અદૃશ્ય ન થાય. તે શેડ્યુલિંગની ફરિયાદ નથી. પછીની --up વ્યાખ્યા તે તબક્કા માટે પહેલેથી સંગ્રહિત આદેશને બદલી નાખે છે, અને પાર્સર એમ કહે છે, એટલે કે તમારી બે સ્ક્રિપ્ટોમાંથી બરાબર એક જ ક્યારેય ચાલી છે. બીજી તેની પાછળ કતારમાં નથી; તે ગઈ છે.

તેથી ચેતવણી ધ્યાન યોગ્ય છે, જોકે તે ઘાતક નથી: તે જે આગાહી કરે છે તે DNS અપડેટ અથવા રૂટ ફેરફાર છે જે શાંતિથી થવાનું બંધ થઈ ગયું છે.

ચેતવણી ક્રમ વિશે નથી

OpenVPN up તબક્કા માટે એક જ વપરાશકર્તા-સ્ક્રિપ્ટ આદેશ સંગ્રહે છે. જ્યારે પાર્સરને બીજી વ્યાખ્યા મળે છે, પ્રોફાઇલમાંથી, સમાવિષ્ટ ફાઇલમાંથી અથવા કમાન્ડ લાઇનમાંથી, ત્યારે તે પહેલેથી રાખેલું બદલી નાખે છે અને ચેતવણી બહાર પાડે છે. કંઈ જ જોડાતું નથી, કંઈ બે વાર ચાલતું નથી, અને ક્રમનો કોઈ પ્રશ્ન જ નથી. જે આદેશ ટકી રહે છે તે પાર્સરે છેલ્લે જોયેલો આદેશ છે, તેથી લાઇન ખસેડવાથી વિજેતા બદલાઈ શકે છે જ્યારે બીજી સ્ક્રિપ્ટ મૃત રહે છે.

આ જ પેટર્ન અન્ય સ્ક્રિપ્ટ તબક્કાઓને પણ લાગુ પડે છે: દરેક માટે એક આદેશ. જો બે કામ બંને થવા જોઈએ, તો તેમને એક પ્રવેશબિંદુની જરૂર છે, યાદી જેવા દેખાતા બે નિર્દેશોની નહીં.

વાસ્તવિક લોન્ચમાં બંને વ્યાખ્યાઓ શોધો

તમે સંપાદિત કરેલી પ્રોફાઇલથી નહીં, પરંતુ ડેમનને ખરેખર શું મળ્યું તેનાથી શરૂ કરો. ps -ef અને યુનિટનું ExecStart કમાન્ડ લાઇન દર્શાવે છે, જે કન્ટેનર પ્રવેશબિંદુ અથવા રેપરમાંથી --up ઉમેરી શકે છે; ડિસ્ટ્રિબ્યુશનની init ફાઇલ પણ એ જ કરી શકે છે. systemctl cat openvpn-server@server સેવા પોતે શું ઉમેરે છે તે દર્શાવે છે, અને કન્ફિગરેશન ડિરેક્ટરી પરનું પુનરાવર્તિત grep ફાઇલ-સ્તરની વ્યાખ્યાઓ શોધે છે. નકલો સામાન્ય રીતે જુદા જુદા સ્તરોમાંથી આવે છે, અને એટલે જ એક ફાઇલ સંપાદિત કરવાથી કંઈ બદલાતું નથી.

સ્ક્રિપ્ટને બીજી ડિરેક્ટરીમાં કૉપિ કરવી અથવા નામ બદલવું પણ નિર્દેશ દૂર કરતું નથી. પાર્સર ફાઇલો નહીં, વ્યાખ્યાઓ ગણે છે.

એક hook જ કામનો માલિક બને

ટકાઉ ઉકેલ એ એક જ ડિસ્પેચર છે જે બંને ક્રિયાઓ જાણી જોઈને ક્રમમાં ચલાવે. set -eu સાથેની ટૂંકી shell સ્ક્રિપ્ટ જરૂરી ઇન્ટિગ્રેશન અને પછી સ્થાનિક ક્રિયા બોલાવે છે, અને દલીલોની સીમાઓ ટકી રહે તે માટે "$@" પસાર કરે છે, જેથી વર્તન એક ચકાસી શકાય તેવી જગ્યાએ રહે. દલીલો પસાર કરવી તેમને ફક્ત સાચવે છે; તે સાબિત કરતું નથી કે બંને સહાયક સમાન ઇન્ટરફેસ ધારે છે, તેથી દરેકનો કરાર વાંચો. નિષ્ફળતાએ શું કરવું અને આંશિક ફેરફારો ઉલટાવવા જોઈએ કે નહીં તે નક્કી કરો.

જો લોન્ચર સમર્થિત એક્સ્ટેન્શન hook આપે છે, તો હાથે બનાવેલી સાંકળ કરતાં તેને પસંદ કરો. કન્ટેનર ઇમેજ અથવા વેન્ડર પેકેજમાં વધારાના કામ માટે ઘણી વાર દસ્તાવેજીકૃત જગ્યા હોય છે, અને તેનો ઉપયોગ અપગ્રેડને તમારા ડિસ્પેચર પર લખવાથી રોકે છે.

સફાઈ સંબંધિત down તબક્કાની છે. DNS ફરીથી લખતી અથવા રૂટ ઉમેરતી up ક્રિયાને દસ્તાવેજીકૃત ઉલટાવવાની જરૂર છે, અને ફક્ત શરૂઆત સંભાળતું ડિસ્પેચર અડધી ડિઝાઇન છે.

એકીકરણની ખાતરી કરો, ફક્ત મૌનની નહીં

ડુપ્લિકેટ ચેતવણી દૂર કરવી સહેલો ભાગ છે; એકીકરણે હજી કામ કરવું પડશે. કનેક્ટ થયા પછી resolvectl status વડે અથવા /etc/resolv.conf વાંચીને રિઝોલ્વરની સ્થિતિ તપાસો, અને ip route વડે રૂટની ખાતરી કરો. પછી ડિસ્કનેક્ટ કરો અને ફરી કનેક્ટ કરો, કારણ કે ઉતાવળે જોડાયેલું hook સામાન્ય રીતે અગાઉના સત્રમાંથી કંઈક છોડી દે છે. journalctl -u openvpn-server@server -b બતાવે છે કે તમારું ડિસ્પેચર ચાલ્યું અને શું છાપ્યું.

hookની વિશેષાધિકારો જ્યાં હોવા જોઈએ ત્યાં જ રાખો. script-security વધારવું અથવા ડેમનને વધુ અધિકારો સાથે ચલાવવું બદલાયેલા hook માટે ઉકેલ નથી; તે દરેક ભવિષ્યની સ્ક્રિપ્ટ શું કરી શકે તે વિસ્તારે છે, જેમાં હુમલાખોર નામ આપે તે પણ સામેલ છે.

ઉકેલ સાચો છે તેની નિશાની લોગમાં મૌન નથી. તે DNS જવાબ, રૂટ એન્ટ્રી અને સફાઈ છે, જે બે પુનઃકનેક્શન પછી બધું બરાબર ચાલે છે.