Pritunl: kontrol-egoera sortutako profilaren aurrean

Artxibo batek Pritunl inplementazio erabilgarri bat leheneratzen du; besteak haren irudi bat baino ez. Bezero-profil batek, ostalariaren konfigurazio-kopia batek eta egoera-direktorioaren tarball batek babeskopia itxura dute guztiek, eta horietako batek ere ez du bakarrik Pritunlek kudeatzen dituen erakunde, erabiltzaile eta zerbitzari-definizioak itzultzen. Aldea jabetzan dago: egoeraren zati bat datu-basearena da, beste bat ostalariarena, eta beste bat berreraldatutako irteera da. Aukeratu geruza okerra eta leheneratzeak abiarazten, entzuten eta ezer ez dakien zerbitzari bat sortuko du. Konparazio honek hiru geruzak bereizten ditu, gordetzen duzun artxiboa berreskuratzen ari zaren hutsari egokitu dakion.

Bi objektuk babeskopia itxura dute eta bakarra leheneratzen du zerbitzua

Deskargatutako bezero-profil batek ziurtagiri bat, gako bat eta amaiera-puntu bat dauzka. Gailu bakar horretarako osoa da eta inplementazioaren erregistro gisa baliogabea: ez dakar erakunderik, ez erabiltzaile desgaitu, ez zerbitzari-bide, ez eta administrazio-konturik ere. Profilen karpeta batetik leheneratzeak ezeren aurka autentifikatu ezin duten bezeroak ematen ditu.

Ostalariaren konfigurazio-kopia bat ere partziala da. /etc/pritunl.conf ostalari-mailako ezarpenak ditu, datu-basera nola iritsi barne, eta ez ditu VPN objektuak berak.

Zer duen datu-baseak eta zer duen ostalariak

Pritunlek zerbitzari-definizioak, erabiltzaileak, erakundeak eta gakoak MongoDBn gordetzen ditu. Datu-base hori kontrol-plano autoritatiboa da, eta diskoan sortutako OpenVPN fitxategi bakoitza handik eratorritako irteera da. Sortutako fitxategi batean zuzenean egindako aldaketa hurrengo birsorkuntzara arte irauten du eta gero desagertu egiten da, horregatik exekuzio-fitxategiak editatzea ez da konponketa iraunkorra. Arau bera aplikatzen zaie bide eta interfaze eraginkorrei: kontrol-planoak sortu duena deskribatzen dute, sortu beharko lukeena ez.

Ostalariak balio multzo txikiagoa baina transferi ezina ematen du. Horietako bat /var/lib/pritunl/pritunl.uuid da, nodo zehatz horren identitatea.

Identitate hori garrantzitsuena da klusterrean. Ordezko ostalariek beren inskripzioa behar dute nodo aktibo baten UUIDaren klonaren ordez, bestela bik identitate beragatik borrokatzen dute. Erregistratu ostalari bakoitzaren, haren UUIDaren eta seinalatzen duen datu-basearen arteko mapaketa, datu-basearen isuri bakar batek ez baitu deskribatzen zein ostalari-ezarpen zein makinari zegokion. Software-bertsioek eta amaiera-puntu publikoen izenek erregistro berean sartu behar dute.

Egin isurketa koherente bat, ez direktorio-kopia bat

MongoDBren datu-direktorioa zerbitzua idazten ari den bitartean kopiatzeak baliteke datu-base erabilgarririk osatuko ez duten fitxategiak sortzen ditu. Erabili datu-baseak onartutako isurketa-bidea, duzun topologiaren aurka exekutatuta:

mongodump --uri="mongodb://127.0.0.1:27017/pritunl" --out=/var/backups/pritunl/db
sudo tar czf /var/backups/pritunl/host.tgz /etc/pritunl.conf /var/lib/pritunl/pritunl.uuid

Ostari autonomo batek forma soil hori onartzen du. Erreplika-multzo batek denboran puntu koherentea behar du, eta oplog-en oinarritutako isurketak isurketa soil batek ez dituen baldintzak ditu. Onartutako prozedura zure MongoDB bertsioaren eta topologiaren araberakoa da, beraz ez deduzatu datu-direktorio bat egoteagatik. Artxibatu ostalari-geruza isurketaren ondoan, exekuzio berean, denbora-zigilu berarekin.

Praktikatu leheneratzea behar duzun aurretik

Inork leheneratu gabeko babeskopia bat hipotesi bat da. Eraiki zerbitzua sare isolatu batean, leheneratu isurketa eta jarri ostalariaren fitxategiak berriro:

mongorestore --uri="mongodb://127.0.0.1:27017" --drop /var/backups/pritunl/db
sudo tar xzf /var/backups/pritunl/host.tgz -C /

Gero egiaztatu objektuak, prozesua ez: hasi saioa, konfirmatu erakundeak eta erabiltzaileak daudela, eta abiarazi probako bezero bat ezagutzen duzun zerbitzari-definizio baten aurka. Eragotzi leheneratutako ostalariak produkzio-amaiera-puntua iragartzea edo benetako konexioak onartzea helbideak eta identitateak nahita zehaztu arte. Hemen ere aurkitzen duzu artxiboak huts egin zuen makinan bakarrik bizi ziren kredentzialak behar dituela, beraz gorde leheneratze-kredentzialak leku independente batean. Justu galdu duzun ostalariaren mende dagoen leheneratze bat ez da leheneratze-plana.

Amaitzeko, gogoratu snapshot zahar batek erabaki zaharrak leheneratzen dituela. Administratzaile batek identitate bat desgaitu bazuen isurketa atera ondoren, leheneratzeak berriro gaitzen du. Berreskuratze osteko adiskidetzea prozeduraren parte da, ez geroagoko gogoeta.