Ei gammal løysing flytta OpenVPN-køyrefila ein annan stad og lét ei shell-innpakking liggja på den opphavlege stien. Månader seinare kjem ei oppgradering, og å angre løysinga blir ei gjetting om kva fil som eigentleg er klienten. Kommandonamnet, køyrefila som er sett opp i tenesta og den eigne fillista til pakka kan alle peike på ulike objekt, og å reparere eitt av dei utan dei andre gjev ein vert som ser reparert ut og oppfører seg verre.

Byrja med stien som tenesta startar

Ein terminal og ei systemd-eining løyser ikkje køyrefiler på same måte. Skalet søkjer i ein PATH; eininga nemner ein sti, og drop-in-overstyringar kan byta han ut utan å røre fila du les. Den skilnaden forklarer det meste av forvirringa i denne oppgåva. Han avgjer òg kva fil reparasjonen din må rette seg mot.

Spør eininga kva ho køyrer, inkludert drop-in-filene som endrar ho, og les ExecStart-lina som kjem ut, i staden for brotet du trur er autoritativt. Følg deretter den stien gjennom kva symbolsk lenkje som helst til den endelege fila. Ei innpakking som endar med exec inn i ein skjult mappe er ei vanleg ordning frå desse gamle rettingane.

Skriv ned den løyste stien før du endrar noko.

systemctl cat [email protected] | grep -n 'ExecStart'
readlink -f "$(command -v openvpn)"

Samanlikn kommandonamnet med tenestestien

Dei to svara er ofte ulike, og den skilnaden er ikkje automatisk ein feil. Eit NetworkManager-innstikk kan starte sin eigen sti, og ein container kan montere ein annan.

Det som tel er å vite kven eigar som startar prosessen som tenar trafikken. Viss eininga køyrer /usr/local/sbin/openvpn-wrapper medan skalet ditt løyser /usr/sbin/openvpn, endrar reparasjonen av den andre fila ingenting på tenesta.

Spør kva pakke som eig kvar kandidat, og avgjer så om fila er pakkestyrt eller lagd lokalt. Ei fil utan eigarpakke er ei fil som nokon la der med vilje, og ho fortener eit namn, ein eigar og ein grunn før ho blir sletta. Den motsette feilen er òg vanleg: å overskrive ei pakkefil med ein gammal lagra binærfil fordi eit foruminnlegg brukte same mappa.

Lat pakkebasen tale om pakkefilene

Når programvara kom frå ei Debian-pakke, kan pakkebasen seie deg om filene hennar framleis svarar til det som vart installert. Det er eit trongt spørsmål om integritet, ikkje ein tryggleiksdom, og skilnaden er viktig når du avgjer kva du skal reparere. Eit avvik tyder på at fila vart endra etter installasjonen, noko som kan vera den gamle løysinga di eller ei legitim lokal endring. Utdata avgjer ikkje kva, så les dei som eit hint og ikkje som ein konklusjon.

Køyr kontrollen og les utdata i staden for å sjå på eit tomt resultat som prov på noko.

dpkg -S /usr/sbin/openvpn
dpkg --verify openvpn

dpkg-handboka dokumenterer at kontrollen samanliknar installerte filer med lokalt registrerte metadata, og brukar lagra kontrollsummar der dei finst. Han legg merke til ei endra pakkefil, og han kan ikkje seie deg om ein annan binærfil blir starta i staden.

Registrer tilstanden før du reparerer

Samle den løyste oppstartsstien, pakketilhøvet til fila, plasseringa til innpakkinga og endringsloggen som førte ho inn. Kopier innpakkinga til ein verna stad viss ho inneheld integreringsarbeid som trengst seinare.

Ikkje lim inn innhaldet i innpakkinga i ein støttetråd før du har lese det, for desse skripta ber av og til innloggingsdetaljar eller gateway-opplysningar.

Registrer kva profilar tenesta brukar og kven som er tilkopla medan du arbeider, fordi ein omstart av tunnelen kan bryte økta du administrerer verten frå.

Stadfest oppstarten og fjern deretter innpakkinga

Etter reparasjonen startar du tenesta og stadfestar at prosessen køyrer den stien du meinte. Ei versjonsførespurnad som blir køyrd for hand provar at fila verkar; ho provar ikkje at eininga brukar ho.

Kopla så til ein klient igjen og kontroller at profilen framleis autentiserer, fordi eit binærbyte som ignorerer dei opphavlege vala vil mislykkast på ein måte som ser ut som eit sertifikatproblem.

Fjern den fortrengde innpakkinga gjennom den same endringsloggen som førte ho inn. Den ferdige reparasjonen seier kva køyrefil som går, kvifor, og kva fil som vart fjerna; å gjenopprette eit filnamn og håpe er ikkje det same.

Relaterte artiklar