10 dec. 2004 ?

Jeg vil med det samme nævne at det ikke var verdenspremieren på "Ocean's 12" eller for den sags skyld Human Rights Day jeg refererer til i overskriften, men istedet den dag, en server jeg lige har dekommisioneret sidst blev bootet:

# uptime
2:01AM up 1171 days, 11:30, [...]

I princippet var der ingen presserende grund til at opdatere maskinen, men behovet for et nyt mail-setup gjorde det til en fornuftig disposition, diskene er ved at nå til en suspekt alder og FreeBSD 4 er ved at være lidt geriatisk.

Det irriterer mig gevaldigt og har gjort det i ca. 20 år, at der ikke findes en fornuftig måde at opdatere et operativsystem på, ud over en geninstallation.

Den måde jeg er nået frem til at håndtere det på, er at give systemerne to ens partitioner på ca. 10GB til operativsystemet.

Et møjsommeligt opbygget shell-script kan derefter bygget et nyt system på "den modsatte" partition så man kan sammenligne, fil for fil, hvad der er forskellen på det kørende system og et nyinstalleret.

På den måde er det nemt at finde de rettelser til underlige konfigurationsfiler som man skal huske at overføre næste gang man opgraderer og skulle opgraderingen gå skævt, så booter man bare fra den oprindelige partition igen indtil man finder problemet.

Faktisk undrer det mig mere og mere hvorfor det ikke er de normale måde at gøre tingene på.

Hvorfor skulle det være acceptabelt at der ikke er en "undo" mulighed, blot fordi det drejer sig om en opdatering af et operativsystem ?

phk

Kommentarer (10)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Lars Balker

Det er en interessant diskussion. Best practice systemadministration er jo at dokumentere ALT hvad man laver, gerne så det kan reviewes inden man sætter det i produktion. Det er bare bøvlet, brugerne har sjældent forståelse for ventetiden, systemet kan have brug for et hot-fix og det kræver en solid bunke disciplin at gøre det hver gang.

Jeg har i et tidligere liv da jeg var solaris-admin tit brugt et script til at lave et totalt system-diff mellem to ens patchede maskiner, men hvor den ene er frisk installeret (selvf. med de lokale tilrettelser). Det er meget belærende at få en liste af ændringer ind i editoren, hvor man kan sidde og fjerne ting der er ligegyldige, midlertidige osv. indtil man har en reel liste der identificerer den box man prøver at forstå. Highly recommended.

  • 0
  • 0
Flemming Riis

det ville være dejligt at kunne på en Windows maskine , problemet er bare man vil få 1245 sider med mærkelige registry keys alle under lige applikationer har sat så det vil være fuldstændigt overskuelidt.

Dumt spørgsmål , ligger alle apps sig pænt med en config fil hos sig selv eller kan det også ligge spredt over det hele ?

  • 0
  • 0
Michael Rasmussen

På den OS'er jeg har fingerene i, findes config filerne på en af følgende måder:

/etc/apps.conf
/etc/apps/apps.conf
/usr/apps/apps.conf

Undtagelsesvis kan man finde conf under /var

man apps har som regel en beskrivelse af standardplaceringen af conf filen.

  • 0
  • 0
Troels Arvin

Med RPM-pakke-baserede systemer har jeg haft stor glæde af "rpm -Va": Den viser, hvilke filer som er ændrede siden installationen, hvilket i praksis fortæller mig: Hvor kan der være tale om, at der er ændret i forhold til standardværdier? En sådan liste er ret nyttig i forhold til at få skåret ned på antallet af filer/konfigurationer, som skal tænkes over.

  • 0
  • 0
Michael Rasmussen

På Debian baserede systemer skulle nedenstående lille script kunne løse problemet. Skal dog lige tilpasses den konkrete situation.

!/bin/sh

PATH=/bin:/sbin:/usr/bin:/usr/sbin

NEW= # mount point for new partitioin
LOG= # log file
PACKAGES=$(dpkg --get-selections |cut -f1)

for P in $PACKAGES
do
if [ -z $LOG ]
then
LOG=/dev/stdout
fi
FILES=$(dpkg -L $P)
for F in $FILES
do
if [ -f $F ]
then
diff -urN $F $NEW$F > $LOG
echo $F > $LOG
fi
done
done

exit 0

  • 0
  • 0
Kim Højgaard-hansen

@PHK

det lyder som en ganske god KISS løsning, men vil det også virke når man ikke har fysisk adgang til en server? Det er oftest der man hører det går helt galt.

Linux arbejder med at udvikle muligheden for at migrere over på en ny kerne "live", men det er vist lidt ønsketænkning foreløbig :)

Jeg er dog lidt forundret over at der ikke har været et eneste bug/exploit der har krævet en genstart. Det er vel ikke fordi man har undladt sikkerhedsupdates i base-systemet? :) Selv en BSD bliver der jo fundet huller i, men du har den måske isoleret sådan at du kan nøjes med at vedligeholde servicen?

Personligt har jeg valgt vmware-server løsningen til den suk windows server jeg er tvunget til at drive, så jeg kan lave et snapshot inden jeg installerer sikkerheds opdateringer. Der er dog stadig et OS nedenunder der bør opgraderes, men det hele bliver lidt mere fleksibelt.

Andre bruger simpelthen den løsning at det passer med at hw er udrangeret når levetiden for FreeBSD-X er ved at være nået. Så køber man nyt hw og kører en parallel løsning op.

  • 0
  • 0
Flemming Dalsgaard

Igennem de sidste ca. 10 års versioner af Solaris og nu også opensolaris har der været indbygget mulighed for at opgradere et OS uden at lokale konfigurationer bliver væk. Man skal faktisk fra vælge det under installationen hvis det ikkke er ønskeligt.

Fra Solaris 8 og frem er der også mulighed for at lave en "Live upgrade" hvilket dækker over at man laver en kopi af det kørende OS på en anden disk/partition også opgradere denne til den ønskede Solaris version. Derefter kan man så tilrette/patche denne nye OS efter behov og når den er klar, skifte over med kun en reboot som downtime. Selvfølgelig kan man altid skifte tilbage igen om nødvendigt.

Det virker ( med samme forbehold som for det meste software selvfølgelig :)

  • 0
  • 0
Søren Lund

"Hvorfor skulle det være acceptabelt at der ikke er en "undo" mulighed, blot fordi det drejer sig om en opdatering af et operativsystem ?"

Checkpoints og Rollback i ZFS ville vel give netop en "undo" af hvad som helst, der blev lagt på filsystemet - også et operativsystem.

Jeg har (desværre) ingen erfaring med ZFS, jeg venter på en Linux-port. Men FreeBSD-porteringen burde være lige på trapperne, er der nogen med erfaringer?

  • 0
  • 0
Log ind eller Opret konto for at kommentere