OpenVPN startte, mar printe neat: kontrolearje earst log-append

Do startest OpenVPN út in shell mei in konfiguraasjebestân, en de terminal sit dêr sûnder ien útfier. Gjin banner, gjin flater, gjin prompt. It ynstinkt seit dat de start mislearre, dus do startest noch in kopy, dan noch ien, en de masine einiget mei ferskate heal-konfigurearre eksimplaren. Kontrolearje foar dat alles it profyl op in rjochtyn dy't it log al earne oars hinne stjoerd hat. Stilte is in eigenskip fan 'e konsola, net fan it proses.

Stilte hat twa hiel ferskillende ferklearrings

De earste is dat it proses goed rint en skriuwt nei in bestân datsto net besjochst. De twadde is dat it daliks ôfsletten is mei in flater dy't yn itselde bestân fêstlein is.

Beide litte in lege terminal efter, en ien fraach skiedt se: is der no in proses, en wat stiet yn it bestân dêr't it nei skriuwe moast. Beäntwurdzje dat foardatsto de konfiguraasje wer oanrekkest. Op 'e nij starte om útfier te krijen is hoe't twa eksimplaren fjochtsje oer ien tunnelapparaat en deselde poarte, wat flaters jout dy't neat mei it oarspronklike probleem te meitsjen hawwe.

Fyn de rjochtyn, fyn dan it proses.

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

Fyn de bestimming dy't it rinnende proses brûkt

Lês it profyl wêrmei't it proses echt start is, net datst bewurke hast. In tsjinstbeheard eksimplaar laded meastentiids in oar paad en rint mei in oare wurkmap, dus in relative bestânsnamme wurdt earne oplost dêr'tst it net ferwachte hast.

In eksplisite cd-rjochtyn makket dat ûnderskie skerper, want it relative paad ferpleatst mei de mapferoaring. As do dizze konfiguraasje erfd hast, kin it bestân earne lizze dêr't no nimmen it sykje soe.

Fergelykje de wizigingstiid fan it bestân mei it momint datst it startest. In log fan ferline wike is bewiis oer ferline wike. Lês dan de lêste rigels fan it bestân dat feroare is, en beskôgje wat dêr stiet as it startberjocht datst mist hast.

log tsjin log-append: bewiis en wiskjen

log-append foeget ta oan wat al yn it bestân stiet. log iepenet it bestân foar skriuwen en snijt it ôf, dus wikselje tusken beide kin de run wiskje dy'tst krekt lêze soest.

As immen de rjochtyn by it debuggen feroare hat, is it eardere bewiis al fuort en sil de grutte fan it bestân fertocht lyts lykje. Dat is goed om te witten foardatst twa runs fergelikest en konkludearrest dat der wat feroare is. Wiskje in log mei sin, of hâld it, mar witte watsto dien hast. Bewiis datst bewust fuorthelle hast is makliker te beredenearjen as bewiis datst by ûngelok ferlern hast.

Gjin fan beide opsjes makket ûntbrekkende âlderlike mappen oan, en gjin fan beide jout tagong fia bestânsysteemrjochten of in tsjinst-sandbox. In paad dat yn 'e konfiguraasje goed liket, kin noch altyd net skriuwber wêze foar it akkount dêr't de daemon ûnder rint, en dan kin de daemon mislearje foardat er wat melde kin. Kontrolearje oft de map bestiet en wa't de eigner is, foardatst oannimst dat de bestânsnamme it probleem is.

As in tsjinstwrapsel de útfier fangt

Under systemd gean standertútfier en -flater nei it journal, útsein as in eksplisite bestânsrjochtyn foarrang krijt, en in leveransierswrapsel kin se hielendal earne oars fange.

Dêrom gedraacht itselde profyl him oars út in shell en út in unit. De omjouwing fan 'e unit, syn wurkmap en syn standertstreamen ferskille allegear fan dyn ynteraktive shell. In relatýf paad kin yn it iene kontekst oplost wurde en yn it oare nearne belânje. Lês de unit-definysje as de beide fan betinken ferskille, net it profyl.

Fergelykje de twa startregelingen ynstee fan te konkludearjen dat ien fan beide stikken is. Lês de opdrachtline fan 'e unit en syn omjouwing, en lês dan it journal foar itselde tiidfinster. As it wrapsel de útfier nei syn eigen bestân ferwiist, is dat bestân no dyn log, en de OpenVPN-rjochtynen binne net fan belang foar wêr't de berjochten hinne gien binne.

Sette de wiidweidigens pas heger as'tst it lêze kinst

Wiidweidigens ferheegje foardatst de bestimming fûn hast, produsearret allinnich mear tekst op in plak dêr'tst net sjochst.

Sadree'tst witst wêr't de útfier belânet, lit in matich nivo sjen dat it profyl parsed wurdt en de ferbining besocht wurdt. Twa of trije is genôch foar in startprobleem. Hegere nivo's fertsjinje har plak as de flater in ûnderhannelingsdetail is, en se litte it bestân ek fluch groeie.

Lês dan de echte flater. In stille terminal bewiist neat oer oft de tunnel omheech kaam, en de flater dy't yn it bestân fêstlein is, is dejinge dy't it wurdich is om te reparearjen.