10 dec. 2004 ?

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.

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 ?

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.

Øv, mangler stadigvæk en preview funktion!

/usr/apps/apps.conf skulle have været
/usr/lib/apps/apps.conf

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.

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

echo $F > $LOG skal selvfølgelig udkommenteres:-)

Mangler stadigvæk en preview funktion!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

@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.

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 :)

"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?