Før du kører et fællesskabsscript på din Proxmox-server: fem ting at læse
Fællesskabsscripts bærer ægte viden og sparer ægte timer. De køres også som regel som root på den ene maskine, du ikke har råd til at miste, fra én indsat linje, som ingen har læst. Løsningen er ikke at undgå dem, men at læse dem.
AtlasPVE ·
Denne artikel besvarer
- er proxmox community scripts sikre
- proxmox community scripts
- installere helper script proxmox
- curl bash script risiko
- installere script på proxmox server
Fællesskabsscripts er virkelig gode. De bærer viden, som nogen har betalt for med spildte aftener, de håndterer de kedelige tilfælde, du ville være løbet ind i ved midnat, og til mange opgaver er scriptet bedre end det, du selv ville have skrevet. Denne artikel er ikke et argument imod dem.
Den handler om ét bestemt hul. En pakkeinstallation og et indsat enlinjes script ser lige så dagligdags ud på skærmen, og de er slet ikke det samme.
Hvad en pakke giver, som en indsat linje ikke gør
En signatur. Pakker er signeret, og signaturen kontrolleres. En adresse kontrolleres kun mod din antagelse om, at adressen er den rigtige.
En version. Du kan sige, hvilken version du har, og det kan den, der hjælper dig, også. "Scriptet fra readme, for et par uger siden" er ingen version.
En afinstallationsvej. Pakker noterer, hvad de har lagt, og kan fjerne det. Et script lægger ofte filer seks steder og husker det ikke.
Et forhold til en vedligeholder. Ændrer en pakke adfærd, findes der en ændringslog. Et script kan ændre sig under samme adresse uden at efterlade noget at læse.
Intet af dette gør scripts dårlige. Det gør dem til en anden slags ting, der fortjener en anden vane.
De fem ting at læse
Ikke hele scriptet, og ikke linje for linje. De fem svar er som regel synlige i én gennemlæsning.
① Hvad rører det uden for sin egen mappe? Et script, der kun skriver under sin egen mappe, er let at overskue. Et, der redigerer filer i systemets konfigurationsmapper, laver ændringer, der overlever det selv.
② Tilføjer det et repository eller en nøgle? Det er den linje med de tungeste følger i de fleste scripts, og den suser forbi på et sekund. At tilføje en pakkekilde betyder, at enhver fremtidig opdatering på den maskine stoler på en ny part. Det kan være helt rimeligt, og det bør være en beslutning, ikke en sidegevinst.
③ Rører det opstart, kerne eller netværk? Det er de tre, der kan gøre en server uopnåelig eller ustartbar, og på en hypervisor betyder det, at alt ovenpå følger med. Et script, der installerer en webapplikation, har intet at gøre i bootloaderens konfiguration, og gør det det alligevel, er det værd at forstå, før det kører.
④ Findes der en vej tilbage? Se efter en afinstallationsrutine eller i det mindste en liste over, hvad det oprettede. Mangler begge, er din vej tilbage et øjebliksbillede taget på forhånd, hvilket betyder, at du skal tage et.
⑤ Hvad sker der, hvis det kører to gange? Mange scripts er skrevet til en ren maskine, og en anden omgang fordobler poster, nulstiller konfiguration, du havde ændret, eller fejler halvvejs og efterlader en halv tilstand. Du kommer til at køre det to gange på et tidspunkt, som regel fordi første omgang så ud til at fejle.
Den indsatte linje, specifikt
Mønsteret med at hente et script og sende det direkte ind i en skal har én egenskab, der fortjener at blive nævnt: du kan ikke læse det, du kørte. Ikke "du gjorde det ikke", du kan ikke, for det var aldrig en fil.
Der findes også en finere variant. At læse scriptet i browseren og at køre hent-og-send-kommandoen er to adskilte forespørgsler. Intet garanterer, at de returnerede de samme bytes.
Løsningen koster ét ekstra skridt. Hent filen, kig på den, kør så den lokale kopi. Nu ved du, hvad der kørte, du kan køre det identiske igen senere, og går noget i stykker, har du den faktiske tekst i stedet for erindringen om en webside.
En hypervisor er ikke stedet at prøve sig frem
Det er dette, der skiller en Proxmox-server fra en bærbar. Alt andet på maskinen ligger under den. Et script, der efterlader en bærbar i en mærkelig tilstand, koster dig en aften; det samme script på en server tager hver eneste virtuelle maskine med sig.
To vaner gør næsten alt dette sikkert:
Kør det først i en virtuel maskine, hvis det plausibelt kan lade sig gøre. De fleste scripts, der installerer en tjeneste, behøver slet ikke at være på serveren. Det er ingen omvej, det er som regel det rigtige sted.
Skal det virkelig køre på serveren, så øjebliksbillede først. Ikke fordi scriptet er mistænkeligt, men fordi "jeg prøver lige" er præcis den sætning, der går forud for behovet for en vej tilbage.
Hvad denne artikel ikke er
Ingen grund til at mistro fællesskabet. De delte scripts hører til det bedste i dette økosystem, og de, der skriver dem, er som regel mere omhyggelige end dem, der kører dem.
Ingen grund til at læse hver linje. Fem spørgsmål i én gennemlæsning er nok til at fange den slags overraskelse, der virkelig gør ondt.
Hvad Atlas gør
Atlas tager et øjebliksbillede før handlinger, der ændrer serverens tilstand, så vejen tilbage findes, uden at du skal huske at lave den. Det dækker punkt fire på listen ovenfor, altså det, man springer over.
Revisionsloggen noterer, hvem der kørte hvad, hvornår, på hvad og med hvilket resultat, hvilket gør "der ændrede sig noget i tirsdags" til et læsbart svar i stedet for en efterforskning.
Ressourcekæden hjælper mere bagefter end ved beslutningen: opfører noget sig anderledes efter en installation, viser kortet, hvordan maskinen faktisk ser ud nu, fra gæsterne ned til de fysiske diske.
Og hvor Atlas selv installerer software, gennem applikationskataloget, er versionen låst, kilden fast, og der tages et gendannelsespunkt, før installationen begynder. Det er en bevidst smal og kurateret vej, og den erstatter ikke fællesskabsscripts. Det er ganske enkelt de samme fem spørgsmål, besvaret på forhånd for de applikationer, den fører.
Kilder
Proxmox’ egen dokumentation. På engelsk, og den har det sidste ord i dette spørgsmål.