OpenVPN શરૂ થયું પણ કંઈ છાપ્યું નહીં: પહેલાં log-append તપાસો

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

મૌનની બે ખૂબ જ અલગ સમજૂતીઓ છે

પહેલી એ છે કે પ્રક્રિયા બરાબર ચાલી રહી છે અને એવી ફાઇલમાં લખે છે જે તમે જોતા નથી. બીજી એ છે કે તે એ જ ફાઇલમાં નોંધાયેલી ભૂલ સાથે તરત જ બહાર નીકળી ગઈ.

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

સૂચના શોધો, પછી પ્રક્રિયા શોધો.

ps -o pid,args= -C openvpn
grep -nE '^\s*(log|log-append|cd|daemon|verb)\b' /etc/openvpn/server/server.conf

ચાલતી પ્રક્રિયા જે ગંતવ્ય વાપરે છે તે શોધો

પ્રક્રિયા ખરેખર જે પ્રોફાઇલ સાથે શરૂ થઈ તે વાંચો, તમે સંપાદિત કરેલી નહીં. સેવા-સંચાલિત ઘટક સામાન્ય રીતે અલગ પથ લોડ કરે છે અને અલગ કાર્ય ડિરેક્ટરીમાં ચાલે છે, તેથી સાપેક્ષ ફાઇલનામ એવી જગ્યાએ ઉકેલાય છે જ્યાં તમે અપેક્ષા નહોતી રાખી.

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

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

log વિરુદ્ધ log-append: પુરાવો અને ભૂંસવું

log-append ફાઇલમાં પહેલેથી જે છે તેમાં ઉમેરે છે. log ફાઇલને લખવા માટે ખોલે છે અને તેને કાપી નાખે છે, તેથી બંને વચ્ચે અદલાબદલી તમે વાંચવા જઈ રહ્યા હતા તે રનને ભૂંસી શકે છે.

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

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

જ્યારે સેવા રેપર આઉટપુટ પકડે છે

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

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

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

વિગતવારતા ત્યારે જ વધારો જ્યારે તમે તે વાંચી શકો

ગંતવ્ય શોધ્યા પહેલાં વિગતવારતા વધારવાથી ફક્ત એવી જગ્યાએ વધુ લખાણ ઉત્પન્ન થાય છે જ્યાં તમે જોતા નથી.

આઉટપુટ ક્યાં પડે છે તે જાણ્યા પછી, મધ્યમ સ્તર દર્શાવે છે કે પ્રોફાઇલ પાર્સ થઈ રહી છે અને જોડાણનો પ્રયાસ થઈ રહ્યો છે. શરૂઆતની સમસ્યા માટે બે કે ત્રણ પૂરતા છે. ઊંચા સ્તરો ત્યારે જ સ્થાન પામે છે જ્યારે નિષ્ફળતા વાટાઘાટની વિગત હોય, અને તે ફાઇલને ઝડપથી વધારે છે પણ.

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