Reproducerbar installation ?

Ad a: Jeg har haft positive erfaringer med AutoYast under Suse og specielt Debian preseeding. Sidstnævnte er pt. min favorit da den er nem at "bygge" fra grunden med en teksteditor. Min erfaring med Suse var, at den krævede en "reference" platform, hvis man skulle gøre det blot nogenlunde hurtigt.

Det er Rigtigt Rart, at kunne installere fra en USB memory stick på under 10 minutter.

Ad b: Både Suse og Debian kan styres via et pakke bibliotek på det lokale netværk.

Jeg har ikke prøvet, men Nexenta (Ubuntu/Debian på en OpenSolaris kerne) påstår at de kan lave transaktionsbaserede opgraringer ved at kombinere ZFS snapshort med dpkg pakkemanageren. Rollback proceduren består i at vælge en option under boot, så det lyder da som det du efterspørger.

Ad c: Besparelserne i forhold til at skulle købe alt muligt high-availability snask er vel nok business case. Hvad angår ISOxxxx og Datatilsynet, så er udfordringerne nok ca. de samme som med de almindelige driftsprocedurer, bortset fra, at der nok er lidt vundet ved at alting er automatiseret i en krisesituation (dvs. mindre risiko for at ting går galt, selv når folk er presset).

Jeg vil anbefale du kigger på RPM, DEB eller ligende, de kan stort set alt det du godt vil og så har man gjort det i årevis. For praktiske implementationen vælg en tilfældig Linux distribution, de flest har installations scripts eller meta pakker der kan vælge din opsætning, så det hele kan gøres med en kommando.

Jeg har i et par år, gået og tænkt over det, men med:

C) Processen skal kunne forklares og "sælges" til små og store PC-byggere.

D) Det skal være muligt at gøre det på grundlag af en installation der af en eller anden grund er holdt op med at virke.

E) Gamle Fru. Hansen skal kunne gøre det derhjemme, med et relativt få antal klik, og uden spørgsmål hun ikke har noget forudsætninger for at svare på.

...jeg er endnu ikke nået frem til en fornuftig løsning.
Vi har muligheden for at lade alle programmer, udvidelser, osv. registrere sig, så vi kun skal lede efter dem der ikke aktivt kan registrere sig. Når vi så kender listen over programmer og udvidelser, så kan vi begynde at hente de seneste versioner der med sikkerhed kan køre på den valgte udgave af systemer.

Jeg vil mene at det største problem ligger i A (og for mig; E), men det kan have noget a gøre med forskellen på vores systemer. De forsøg jeg har gjort hidtil, har vist at det mest praktiske har været at lave et nyt install medie, hvor alt softwaren er lagt på, så der bare skal opdateres med brugernes data bagefter.
Det at der ikke skal opdateres software separat, gør at det ikke er nødvendig at involvere mennesker, eller foretage gæt, hvor man ikke kan være sikker på at svaret altid er 100% korrekt. På en server kan man naturligvis være mere sikker på at et gæt er korrekt, eller at den der besvarer spørgsmål, ved hvad det handler om, men der er stadig en lidt usikker strategi, at satse på andre folks kompetencer.

Jeg ved ikke med c), men hvis det er noget, der skal gøres ofte, er det en mulighed at have en buildserver, der har arkiveret alle de relevante versioner af operativsystemet og deler dem med NFS. Man kan have ét installations-directory per klient, hvor de klient-specifikke config-filer er gemt. Alle fælles installationsfiler deles via sym-links.

Directoriet indeholder et færdiginstalleret OS og ikke bare installationsfilerne fra installationsmediet. Så slipper man helt for installationsproceduren på klienten, men kan nøjes med at kopiere filerne over på en tom disk. Applikationer kan gemmes i det foretrukne pakke-system eller direkte i installations-directoriet inkl. alle klient-specifikke config-filer.

I klientens BIOS sætter man boot-rækkefølgen til 1) Hard Disk og 2) PXE. Når en klient skal reinstalleres, smadrer man klientens MBR og rebooter. Klienten booter nu diskless over netværket med PXE, eftersom den lokale disk ikke længere kan bruges (DHCP sørger for, at der bootes fra /buildserver/diskless/klient1).

Et script i diskless-directoriet går straks i gang med at formattere klientens harddisk (MBR genetableres) og kopierer indholdet af /buildserver/install/klient1/last-known-good ned på klientens disk. Backup hentes fra /backupserver/klient1. Scriptet rebooter klienten, som nu booter den spritnye installation fra harddisken, eftersom MBR er genetableret.

Hele installationsprocessen bør tage under 10 min, afhængig af boot-tider og størrelsen af backupdata. Giver det mening?

Til det formål. Det har jeg ihvertfald brugt mange forskellige steder med stor success.

Dog skal man være forsigtig når man skriver sine regler, før man godkender dem til 100+ hosts og pludselig får gjort noget uheldigt, fordi man ikke testede sine ting først :)

Men det gælder vel med alt, i større eller mindre omfang.

Så har jeg normalt bare regelsættet og tilhørende filer i svn - så kan jeg rulle tilbage ganske nemt.

Det lyder som en sød lille opgave, som man kan bruge meget tid på at få løst. Jeg er bestemt enig i at det er den måde som vigtige operationelle systemer skal kunne genetableres på. Grundighed og kvalitet er væsentlige nøgleord i sådan en løsning.

Jeg er selv meget interesseret i svar på dette. Jeg synes det er top-rimelige krav at stille.

Problemet ved "reproducérbar" er at man skal kunne teste og garantere reproducerbarheden. ;-)

Nu ved jeg at "nogen" foretrækker FreeBSD. Jeg antager at der findes tilsvarende alternativer til FreeBSD, som dem jeg nævner her:

Mit foreløbigt bedste forslag:

Ad A)
A1) installér fra debian's installer. Svar X, Y, og Z på spørgsmålene 1, 2 og 3. (Evt. brug preseeding / custom installer for at reducere antallet af spørgsmål).

A2) Hvis du selv vil styre pakkelisten inkl. versioner, så brug en rsync-kopi af et debian mirror, ellers ville jeg bruge "debian stable" som den ser ud på installationstidpunktet (vel vidende at det så ikke bliver præcist reproducérbart). Opret en pakke der kun indeholder dependencies til andre pakker, sådan at installation af denne pakke automatisk installerer de 204 andre pakker. Således består A af "installér fra CD rom, tilføj http://somewhere til sources.list og installer pakke xyz."

Ad B)
B1) Brug noget som puppet til at styre konfigurationen af maskinen når først pakkerne er installeret. (Så der ikke skal hackes i 1034 forskellige filer under /etc og /usr/share...)
B2) Sørg for at bruge LVM (eller FreeBSD alternativet) til at lave snapshots før upgrade, og slet dem efter endt og vellykket upgrade. Bootsekvensen hackes (via puppet) til at detektere fejlet upgrade og restore/rollback fra LVM snapshot. (Detaljer her om B2 er noget udtydelige, ved jeg godt.)

Ad C) You're on your own, mate!

Pris for første: 1 mandeuge når man ved hvad man gør, 2 ellers (lidt afhængig af "puppet" kompleksitet). 4 dage oveni hvis man skal have en custom installer.

Pris for næste 10: 1 mandedag totalt.

Hvis man vil følge med "debian stable" eller "FreeBSD stable" (eller hvad den nu end hedder) må man påregne vedligeholdsomkostninger.

Er meget interesseret i at høre hvordan det gøres smartere.

Ubuntu har en closed-source: http://www.ubuntu.com/news/landscape Ved ikke helt om den rammer plet. Jeg vil nu helst selv finde et open-source alternativ.

Peter

http://nixos.org

alternativ:
cd /
git init
git commit -a

Virtualisering burde kunne klare alle kravene.

Hvis man bruger FreeBSD er det muligt at anvende install.cfg

Se:

/usr/src/release/sysinstall/install.cfg

Filen kunne evt dannes automatisk ud fra et repositorie med alle server settings og efterfølgende gemmes i en CMDB.

• Hvordan vil I gøre det?

Jeg har brugt to forskellige tilgange alt efter behovet:

1) Små fysiske systemer (soekris, alix og venner) der kørte specifikke applikationer.

Her byggede jeg images vha. : http://www.freebsd.org/doc/en/articles/nanobsd/index.html

a) Image bygges og skrives til device herefter kører et enkelt script hvor jeg satte den til at hente varians konfigurations varians fra en subversion server.
b) Opdateringer klares indefra styresystemet hvor et nyt image uploades, installeres, rebootes og den nye installation vælges.

2) Til større ikke-fysiske (virtualiserede servere) har jeg brugt:

https://launchpad.net/vmbuilder
https://help.ubuntu.com/community/JeOS

a) Maskinen bygges (2min) med specifik konfiguration: "vmbuilder esxi ubuntu -c webserver01.cfg", maskinen uploades til hypervisor (3min).
Herefter mountes data.
b) "Sikkerheds opdateringer" kan klares løbende, større opdateringer gentages a)
De fleste "hypervisore" kan med snapshots klare mange ubehagelige situationer der ellers kan opstå i b).

Jeg har ikke svaret på c) for jeg ved ikke hvad ISO9000 og datatilsynet kræver :)
Men håber at i derude måske kan fortælle mig om de ovennævnte metoder ville være acceptable?

Jeg har været tilfreds med begge løsninger til hver deres formål et af success kriterierne har været at styresystem/applikationer har været adskildt fra data.

• Hvad vil det koste for den første server ?

Det samme som det koster at nedfælde konfiguration og funktion, noget man jo alligevel gør... ikke?
De skal dog omformes fra det krøllede stykke papir på skrivebordet til nogle scripts og konfigurations filer men det er ikke en overvældende byrde.

Hvad koster det for de næste ti servere, der alle har unikke konfigurationer og funktioner, men meget fælles basissoftware ?

5 minutters build / deploy af maskine, varians hives ud af subversion.

• Er det rimelige krav at stille ?

Jeg kan ikke udtale mig om c) men a) og b) er ganske rimelige krav i min verden.
Det er forfærdeligt at stå med en server i drift som man ikke tør køre en apt-get update, windows update, port-upgrade eller anden operation der kan sætte maskinen ud af drift fordi man ikke har kunne afprøve det på en klon inden.
Eller bare for gode nattesøvns skyld have klonen klar hvis den primære fejler.

Jeg ser at vmbuilder allerede er foreslået. Det er også den vej jeg ville gå. Der er en howto her:

https://help.ubuntu.com/8.10/serverguide/C/jeos-and-vmbuilder.html

Det er i princippet beregnet til virtuelle servere men burde nemt kunne bruges til fysiske servere også.

Hvis du er grundig så bygger du deb pakker for alt specialsoftware / egetudviklet software og sørger for at alle konfigurationsfiler kan sættes med kommandolinjeparametre til vmbuilder.

Det er det hele værd at kunne installere en frisk kopi af produktionsserverne med en enkelt kommando og at kunne indarbejde det i en QA proces.

Jeg ved ikke rigtig om jeg vil kommentere, men dit udsagn:

Her er en lille ting i kan gå og tænke over i påsken[/qoute]
Synes jeg ikke hører nogen steder hjemme, da jeg vil tro, at læsere nok kan finde ud af at tænke selv.

Men jeg vil anbefale dig at kigge på en *nix distribution kørende i en WMware - har selv nogle stykker kørende i WMware med TTYLinux, som opfylder dine krav:
[quote]reproduceres sterilt fra installationsmedia

Gem filen, og start forfra så tit man vil..

opdateres løbende....

Gem så mange inkarnationer af WM'en som du vil...

Processen skal kunne forklares og "sælges" til C-teamet, ISO9000-revisoren og Datatilsynet.

C-teamet ved jeg ikke hvad er, ISO9000, er vist fra sidste årtusinde, Datatilsynet har kun noget med Persondata at gøre.
Hvis du tænker på revision som sådan, så tænk gerne på Rigsrevisionen.

Hvordan vil I gøre det ?

Nu er det lidt usammenhængende, det du skriver, men jeg vil anbefale dig at sætte dig ind i lidt større systemer - og sammenhænge - i stedet for at fokusere på enkeltdele.
Hvis du gør det, ville du kende svaret på det spørgsmål.

Mit råd - take it or leave it:
Udvid din horisont, og tænk heterogent i stedet for at tænke homogent.

ISO9000, er vist fra sidste årtusinde

ISO9000 lever skam i bedste velgående, og ligger til grund for flere standarder, bl.a AS9000 der bruges i flyindustrien og AQAP2110, der bruges af NATO.

C-teamet ved jeg ikke hvad er, ISO9000, er vist fra sidste årtusinde, Datatilsynet har kun noget med Persondata at gøre.
Hvis du tænker på revision som sådan, så tænk gerne på Rigsrevisionen.

ISO9000 er, som Per Michael siger, alive and kicking. Den er faktisk en ordentlig og gennemarbejdet standard i modsætning til sådanne makværk som DS484... I forhold til opgaven, er det ISO9000 rimeligt lige til. Sålænge systemdokumentationen, samt dokumentationen af selve processen er på plads.

Datatilsynet kan bestemt være relevant hvis systemet indeholder personhenførbare oplysninger. Problemet med datatilsynet er at de ikke er voldsomt konkrete i deres krav, og de heller ikke vil give nogen konkrete svar hvis man henvender sig direkte.

Rigsrevisionen er jo så kun interessant hvis det drejer sig om en offentlig myndighed.

Poul-Henning, jeg syntes at du skylder os at fortælle os om dine erfaringer indenfor "påskegåden" :)