Før du kjører et fellesskapsskript på Proxmox-tjeneren din: fem ting å lese

Fellesskapsskript bærer ekte kunnskap og sparer ekte timer. De kjøres også som regel som root på den ene maskinen du ikke har råd til å miste, fra én innlimt linje ingen har lest. Løsningen er ikke å unngå dem, men å lese dem.

AtlasPVE ·

Denne artikkelen svarer på

  • er proxmox community scripts trygge
  • proxmox community scripts
  • installere helper script proxmox
  • curl bash skript risiko
  • installere skript på proxmox tjener

Fellesskapsskript er virkelig gode. De bærer kunnskap noen har betalt for med bortkastede kvelder, de tar hånd om de kjipe tilfellene du ville truffet ved midnatt, og for mange oppgaver er skriptet bedre enn det du selv ville skrevet. Denne artikkelen argumenterer ikke mot dem.

Den handler om ett bestemt gap. En pakkeinstallasjon og et innlimt enlinjes skript ser like hverdagslige ut på skjermen, og de er slett ikke det samme.

Hva en pakke gir som en innlimt linje ikke gir

En signatur. Pakker er signert og signaturen kontrolleres. En adresse kontrolleres bare mot din antakelse om at adressen stemmer.

En versjon. Du kan si hvilken versjon du har, og den som hjelper deg også. "Skriptet fra lesmeg-filen, for noen uker siden" er ingen versjon.

En avinstallasjonsvei. Pakker noterer hva de la ut og kan fjerne det. Et skript legger ofte filer på seks steder og husker ikke at det gjorde det.

Et forhold til en vedlikeholder. Når en pakke endrer oppførsel finnes en endringslogg. Et skript kan endre seg under samme adresse uten å etterlate noe å lese.

Ingenting av dette gjør skript dårlige. Det gjør dem til en annen slags ting som fortjener en annen vane.

De fem tingene å lese

Ikke hele skriptet, og ikke linje for linje. Disse fem svarene ser du som regel i én gjennomlesing.

① Hva rører det utenfor sin egen katalog? Et skript som bare skriver under sin egen mappe er lett å overskue. Et som endrer filer i systemets konfigurasjonskataloger gjør endringer som overlever det selv.

② Legger det til et repository eller en nøkkel? Det er linjen med tyngst følger i de fleste skript, og den suser forbi på ett sekund. Å legge til en pakkekilde betyr at hver framtidig oppdatering på den maskinen stoler på en ny part. Det kan være helt rimelig, og det bør være en beslutning, ikke en bivirkning.

③ Rører det oppstart, kjerne eller nettverk? Det er de tre som kan la en tjener bli uoppnåelig eller ustartbar, og på en hypervisor betyr det at alt oppå følger med. Et skript som installerer en nettapplikasjon har ingenting i oppstartslasterens konfigurasjon å gjøre, og gjør det likevel det, er det verdt å forstå før det kjøres.

④ Finnes en vei tilbake? Se etter en avinstallasjonsrutine, eller i det minste en liste over hva det opprettet. Mangler begge, er veien tilbake et øyeblikksbilde tatt på forhånd, altså må du ta ett.

⑤ Hva skjer om det kjøres to ganger? Mange skript er skrevet for en ren maskin, og en runde til dobler oppføringer, nullstiller konfigurasjon du hadde endret, eller feiler halvveis og etterlater en halv tilstand. Du kommer til å kjøre det to ganger en gang, som regel fordi første runde så ut til å feile.

Den innlimte linjen, spesifikt

Mønsteret med å hente et skript og sende det rett inn i et skall har én egenskap verdt å navngi: du kan ikke lese det du kjørte. Ikke "du gjorde det ikke", du kan ikke, for det var aldri en fil.

Det finnes også en finere variant. Å lese skriptet i nettleseren og å kjøre hent-og-send-kommandoen er to atskilte forespørsler. Ingenting garanterer at de ga de samme bytene.

Løsningen koster ett ekstra steg. Last ned filen, se på den, kjør så den lokale kopien. Nå vet du hva som kjørte, du kan kjøre det identiske senere, og går noe i stykker har du den faktiske teksten i stedet for minnet om en nettside.

En hypervisor er ikke stedet å prøve seg

Dette skiller en Proxmox-tjener fra en bærbar. Alt annet på maskinen ligger under den. Et skript som setter en bærbar i en rar tilstand koster deg en kveld; det samme skriptet på en tjener tar med seg hver eneste virtuelle maskin.

To vaner gjør nesten alt dette trygt:

Kjør det først i en virtuell maskin hvis det rimeligvis går. De fleste skript som installerer en tjeneste trenger ikke å være på tjeneren i det hele tatt. Det er ingen omvei, det er som regel riktig sted.

Må det virkelig kjøres på tjeneren, ta øyeblikksbilde først. Ikke fordi skriptet er mistenkelig, men fordi "jeg bare prøver" er nøyaktig setningen som kommer før behovet for en vei tilbake.

Hva denne artikkelen ikke er

Ingen grunn til å mistro fellesskapet. Skriptene folk deler er blant det beste i dette økosystemet, og de som skriver dem er som regel mer nøye enn de som kjører dem.

Ingen grunn til å lese hver linje. Fem spørsmål i én gjennomlesing holder for å fange den typen overraskelse som faktisk gjør vondt.

Hva Atlas gjør

Atlas tar et øyeblikksbilde før operasjoner som endrer tjenerens tilstand, slik at veien tilbake finnes uten at du må huske å lage den. Det dekker punkt fire på listen over, altså det man hopper over.

Revisjonsloggen noterer hvem som kjørte hva, når, på hva og med hvilket resultat, og gjør "noe endret seg forrige tirsdag" til et lesbart svar i stedet for en etterforskning.

Ressurskjeden hjelper mer i etterkant enn ved beslutningen: oppfører noe seg annerledes etter en installasjon, viser kartet hvordan maskinen faktisk ser ut nå, fra gjestene ned til de fysiske diskene.

Og der Atlas selv installerer programvare, gjennom applikasjonskatalogen, er versjonen låst, kilden fast, og et gjenopprettingspunkt tas før installasjonen begynner. Det er en bevisst smal og kuratert vei, og den erstatter ikke fellesskapsskript. Den er rett og slett de samme fem spørsmålene, besvart på forhånd for applikasjonene den fører.

Kilder

Proxmox sin egen dokumentasjon. På engelsk, og den har siste ord i denne saken.

Relaterte artikler

Hvordan ser dette ut inne i Atlas?

Gå til produktsiden