A portaudit szépen szólt, hogy a python25 csomag több hibát is tartalmaz, célszerű lenne frissíteni, de mivel ez a template része, ezért ez "közös" csomag, minden jail örökölte. Ennek ellenére az összes jail-on belül futtathatjuk a portupgrade parancsot, hogy frissítsük, az elhasznált hely kevésbé fontos, mint a biztonsági kockázat.
A jail technológia egyetlen hátránya a jail frissítésének nehézsége – de csak akkor, ha a megszokott módon műveljük. ZFS esetén a template tartalmát átmásolhatjuk egy újabb alkönyvtárban, amelyet verziózhatunk. Én eddig a /jails/system_v1.0.3/ verziónál tartok, ez nagyjából azt jelenti, hogy alaprendszert nem változtattam, az első csomagkészlethez képest nem került újabb csomag a template-be, de már három frissítés történt a jail mintában. Mivel sok helyen előfordult a java szükségessége, ezért úgy döntöttem, hogy a template része lesz a Sun JDK6.0 is, így az elkövetkező verziószám a v1.1.0 lesz.
A jail frissítését célszerű script-re bízni, így nem lesz túl sok munkánk a frissítéssel:
#!/usr/local/bin/bash if ( test "$1" = "" ) then echo "Usage:" echo "$0 <from directory> <to directory>" exit -1 fi if ( test "$2" = "" ) then echo "Usage:" echo "$0 <from directory> <to directory>" exit -2 fi FROM=$1 TO=$2 HOSTNAME="logserver.system.jails.javaforum.hu" JAILNAME="syslogserv" echo "Checklist:" echo " Installed extra packages in jail:" echo " openfwtk" echo "" echo "Sleep for 10 seconds - [Ctrl-C]" sleep 10 echo "Copy /etc/rc.conf" cp $FROM/etc/rc.conf $TO/etc/ echo "Copy /usr/local/etc/syslog-ng.conf" cp $FROM/usr/local/etc/syslog-ng.conf $TO/usr/local/etc/ echo "Copy munin-node plugins: amavis postgrey" cp $FROM/usr/local/etc/munin/plugins/amavis $TO/usr/local/etc/munin/plugins/ cp $FROM/usr/local/etc/munin/plugins/postgrey $TO/usr/local/etc/munin/plugins/ echo "Copy munin-node plugins.conf" cp $FROM/usr/local/etc/munin/plugin-conf.d/plugins.conf $TO/usr/local/etc/munin/plugin-conf.d/ echo "Copy munin-node states" cp $FROM/usr/local/var/munin/plugin-state/* $TO/usr/local/var/munin/plugin-state/ echo "Stop jail" /etc/rc.d/jail stop $JAILNAME echo "Remount dpool/jails/data/system/logserver" zfs set mountpoint=$TO/var/log dpool/jails/data/system/logserver echo "Set 192MByte quota on dpool$FROM" zfs set quota=192M dpool$FROM echo "Todo:" echo " Update /etc/rc.conf (modify jail directory)" echo " Update portsnap.sh (modify jail directory)" echo " Check jail's /etc/rc.conf for installed new services" echo " Start jail: /etc/rc.d/jail start $JAILNAME"
Kissé nagy ugrás történt a naplóban, ugyanis minden eddigi szolgáltatás migrálása megtörtént, több lépéssel tovább is haladtam, mint ami jelenleg le van dokumentálva, de majd utólag csak sikerül ledokumentálni. A wiki jópár oldalán vannak ilyen töredékek, illetve félig kész leírások... amint időm engedi, ezeket rendbeszedem... 
Az üzemeltetés során szükséges idővel újabb és újabb ZFS alapokat készíteni, amelyekből klónozni lehet a rendszer szolgáltatásait. Egy kör már lement ezügyben, és rájöttem a ZFS egyik apró problémájára: akkor lehet átnevezni egy ZFS fájlrendszert, ha alatta az összes fájlrendszer lecsatolható – tehát az átnevezendő fájlrendszer alatt nem lehet foglalt fájl.
Azon célkitűzés felé haladok, hogy a szerver magas rendelkezésreállással működjön, értve ez alatt a frissítésekből adódó leállásoktól való mentességet, mint a hardver hibáját – amely ellen jelenleg nem tudok védekezni. A jelenlegi struktúrát ezért kissé meg kell bontani, és elő kell készíteni a cluster technológiák használatára. Jail-ek esetén lehetőség van egy gépen is cluster jellegű használatra, hiszen különálló IP címek és fájlrendszerek között kiválóan lehet cluster-t építeni.
Egy hibásan frissített syslog-ng képes volt megölni a gépet, egyszerűen azzal, hogy a logot teleírta az alábbival (~4G méretig, a tömörített fájlrendszeren csak ~20MBájtot foglalt), és ez még nem volt elég a ZFS számára, hanem amikor olvasni akartam belőle tail-el, miközben másodpercenként több ezer sor került bele a fájlba, akkor a load elszállt az egekig... és ez már megölte a ZFS alrendszert. Nos, a ZFS még nem stabil, valóban...
Sep 2 21:57:53 logserver syslog-ng[8521]: Error opening file for writing; filename='/dev/console', error='Operation not supported (45)'
Kértem újraindítást, meg is tették röpke fél óra alatt, utána viszont azt vettem észre, hogy az LDAP adatbázis megsérülhetett (pedig tudtommal nem írtam bele az utóbbi pár órában). A sérülés alapján egy darabig működött, majd eldobta az adatbázisát. Ja jó időben csináltam egy ldapsearch kérést, akkor visszakaptam a teljes tartalmat, majd az adatbázis törlése után visszatöltöttem ezt és minden megjavult. A probléma az volt, hogy minden szépen elindult – ami LDAP alapú, aztán megállt (DNS, levelezés).
Hm... ez nem hangzik túl jól:
[root@freebsd:~]$ zpool status -xv
pool: dpool
state: ONLINE
status: One or more devices has experienced an error resulting in data
corruption. Applications may be affected.
action: Restore the file in question if possible. Otherwise restore the
entire pool from backup.
see: http://www.sun.com/msg/ZFS-8000-8A
scrub: none requested
config:
NAME STATE READ WRITE CKSUM
dpool ONLINE 0 0 0
da0s2e ONLINE 0 0 0
errors: Permanent errors have been detected in the following files:
<0x4b>:<0xf4>
A gépben lévő RAID vezérlővel akadt némi probléma, a FreeBSD nem szerette igazán, ezért kis kutakodás után kiderült, hogy a hardver beállításait használja, a hardverben pedig alapból le van tiltva a write cache. Ez felülbírálható:
hw.mpt.enable_sata_wc=1
[root@freebsd:~]$ dd if=/dev/zero of=testfile ibs=64k count=32k 32768+0 records in 4194304+0 records out 2147483648 bytes transferred in 44.881676 secs (47847671 bytes/sec) [root@freebsd:~]$ dd of=/dev/null if=testfile ibs=64k count=32k 32768+0 records in 4194304+0 records out 2147483648 bytes transferred in 37.648894 secs (57039754 bytes/sec)
[root@freebsd:/tmp]$ dd if=/dev/zero of=testfile ibs=64k count=32k 32768+0 records in 4194304+0 records out 2147483648 bytes transferred in 105.221092 secs (20409251 bytes/sec) [root@freebsd:/tmp]$ dd of=/dev/null if=testfile ibs=64k count=32k 32768+0 records in 4194304+0 records out 2147483648 bytes transferred in 34.791732 secs (61723965 bytes/sec)
Kissé vissza van fojtva a ZFS, mert a gépben csak 1G memória van egyelőre. De így már más a helyzet.
Vágjunk kissé rendet a fájlrendszerek között:
[root@freebsd:~]$ zfs list | grep bpool bpool 1.09G 6.72G 18K /bpool bpool/tmp 369K 6.72G 347K /tmp bpool/tmp@install 22K - 23K - bpool/usr 1.01G 6.72G 221M /usr bpool/usr@install 198M - 214M - bpool/usr/local 260M 6.72G 228M /usr/local bpool/usr/local@install 31.2M - 90.8M - bpool/usr/obj 18K 6.72G 18K /usr/obj bpool/usr/ports 193M 6.72G 152M /usr/ports bpool/usr/ports@20080822 41.1M - 146M - bpool/usr/src 164M 6.72G 153M /usr/src bpool/usr/src@20080822 10.8M - 153M - bpool/var 76.2M 6.72G 75.7M /var bpool/var@install 190K - 244K - [root@freebsd:~]$ zfs rename bpool/usr/src@20080822 bpool/usr/src@install [root@freebsd:~]$ zfs snapshot bpool/usr@stable [root@freebsd:~]$ zfs snapshot bpool/usr/local@stable [root@freebsd:~]$ zfs snapshot bpool/var@stable [root@freebsd:~]$ zfs destroy bpool/tmp@install [root@freebsd:~]$ zfs destroy bpool/usr@install [root@freebsd:~]$ zfs destroy bpool/usr/local@install [root@freebsd:~]$ zfs destroy bpool/var@install [root@freebsd:~]$ zfs destroy bpool/usr/ports@20080822 [root@freebsd:~]$ zfs list | grep bpool bpool 845M 6.99G 18K /bpool bpool/tmp 347K 6.99G 347K /tmp bpool/usr 766M 6.99G 221M /usr bpool/usr@stable 33K - 221M - bpool/usr/local 229M 6.99G 228M /usr/local bpool/usr/local@stable 217K - 228M - bpool/usr/obj 18K 6.99G 18K /usr/obj bpool/usr/ports 152M 6.99G 152M /usr/ports bpool/usr/src 164M 6.99G 153M /usr/src bpool/usr/src@install 10.8M - 153M - bpool/var 76.1M 6.99G 75.7M /var bpool/var@stable 127K - 75.7M -
Azok a snapshot-ok, amelyeket a teleptésnél hoztunk létre – már nem kellenek, helyettük célszerű egy @stable létrehozása, amely a rendszerünk jelenlegi stabil állapotát jelenti. Egyedül a /usr/src fájlrendszeren célszerű meghagyni a snapshot-ot, de nevezzük át @install névre, hiszen ebből tudunk olyan kernelt és alaprendszert fordítani, amely megegyezik a rendszerünk jelenlegi állapotával – ugyanakkor lehetővé válik a források folyamatos frissítése is.
A ports fát érdemes naponta frissíteni, ezért erre állítsunk be egy megfelelő crontab bejegyzést, erről levelet fogunk kapni (a `cron` paraméter azt jelenti, hogy a portsnap program maximum egy órát vár véletlenszerűen választott ideig, mielőtt indulna, ezzel tehermentesíti a snap szervert, mivel szép egész órákra szoktak a rendszergazdák programokat időzíteni – ahogy mi is):
0 12 * * * /usr/sbin/portsnap cron
Az eredményt levélben kapjuk (valamikor dél és egy óra között):
Ezen túl az alaprendszer forrását hetente egyszer frissítsük, hátha olyan részt javítanak, amely fontos lehet:
0 12 * * 1 /usr/local/bin/cvsup -g /usr/local/etc/supfile.sources
Az eredmény itt is levélben jön:
Connected to cvsup.hu.FreeBSD.org Updating collection src-all/cvs Edit src/lib/libarchive/test/test_compat_tar_hardlink.c Edit src/lib/libarchive/test/test_pax_filename_encoding.c Edit src/lib/libarchive/test/test_tar_large.c Edit src/lib/libarchive/test/test_ustar_filenames.c Edit src/lib/libarchive/test/test_write_disk_hardlink.c Edit src/lib/libarchive/test/test_write_format_tar_ustar.c Edit src/share/colldef/Makefile Checkout src/share/colldef/no_NO.ISO8859-1.src Checkout src/share/colldef/no_NO.ISO8859-15.src Edit src/share/timedef/Makefile Checkout src/share/timedef/nb_NO.ISO8859-1.src Checkout src/share/timedef/nb_NO.UTF-8.src Delete src/share/timedef/no_NO.ISO8859-1.src Delete src/share/timedef/no_NO.UTF-8.src Edit src/sys/boot/sparc64/loader/main.c Edit src/sys/conf/options.sparc64 Edit src/sys/dev/pci/pci.c Edit src/sys/dev/pci/pci_pci.c Edit src/sys/dev/pci/pcivar.h Edit src/sys/dev/usb/hid.c Edit src/sys/dev/usb/ums.c Edit src/sys/kern/vfs_mount.c Edit src/sys/sparc64/include/asi.h Edit src/sys/sparc64/include/cache.h Edit src/sys/sparc64/include/cpufunc.h Edit src/sys/sparc64/include/pcpu.h Edit src/sys/sparc64/pci/ofw_pci.h Edit src/sys/sparc64/pci/ofw_pcibus.c Edit src/sys/sparc64/pci/psycho.c Edit src/sys/sparc64/sparc64/cheetah.c Edit src/sys/sparc64/sparc64/clock.c Edit src/sys/sparc64/sparc64/exception.S Edit src/sys/sparc64/sparc64/locore.S Edit src/sys/sparc64/sparc64/machdep.c Edit src/sys/sparc64/sparc64/mp_locore.S Edit src/sys/sparc64/sparc64/mp_machdep.c Edit src/sys/sparc64/sparc64/pmap.c Edit src/sys/sparc64/sparc64/prof_machdep.c Edit src/sys/sparc64/sparc64/spitfire.c Edit src/sys/sparc64/sparc64/support.S Edit src/sys/sparc64/sparc64/swtch.S Edit src/sys/sparc64/sparc64/tick.c Edit src/sys/sparc64/sparc64/tlb.c Edit src/sys/sparc64/sparc64/trap.c Edit src/usr.bin/tar/Makefile Edit src/usr.bin/tar/bsdtar.c Edit src/usr.bin/tar/matching.c Edit src/usr.bin/tar/test/Makefile Edit src/usr.bin/tar/test/test_copy.c Edit src/usr.bin/tar/test/test_option_T.c Checkout src/usr.bin/tar/test/test_option_q.c Edit src/usr.bin/tar/test/test_patterns.c Checkout src/usr.bin/tar/test/test_patterns.tgz.err.uu Checkout src/usr.bin/tar/test/test_patterns.tgz.out.uu Checkout src/usr.bin/tar/test/test_patterns.tgz.uu Finished successfully
Ami esetleg még fontos lehet, hogy a jail-ek ports fáját is frissítsük, ez némi ZFS karbantartást is igényel, ezért erre írjunk egy script-et (egyelőre belekódoljuk a jail-ek elérési útját, ezen majd változtatunk a későbbiekben):
#!/usr/local/bin/bash /usr/sbin/portsnap -p /jails/template/usr/ports cron /sbin/zfs destroy dpool/jails/ports/system/dns /sbin/zfs destroy dpool/jails/ports/system/ldap /sbin/zfs destroy dpool/jails/ports/system/logserver /sbin/zfs destroy dpool/jails/ports/system/mail /sbin/zfs destroy dpool/jails/ports/template@now /sbin/zfs snapshot dpool/jails/ports/template@now /sbin/zfs clone dpool/jails/ports/template@now dpool/jails/ports/system/dns /sbin/zfs clone dpool/jails/ports/template@now dpool/jails/ports/system/ldap /sbin/zfs clone dpool/jails/ports/template@now dpool/jails/ports/system/logserver /sbin/zfs clone dpool/jails/ports/template@now dpool/jails/ports/system/mail /sbin/zfs set readonly=on dpool/jails/ports/system/dns /sbin/zfs set readonly=on dpool/jails/ports/system/ldap /sbin/zfs set readonly=on dpool/jails/ports/system/logserver /sbin/zfs set readonly=on dpool/jails/ports/system/mail /sbin/zfs set mountpoint=/jails/system/dns/usr/ports dpool/jails/ports/system/dns /sbin/zfs set mountpoint=/jails/system/ldap/usr/ports dpool/jails/ports/system/ldap /sbin/zfs set mountpoint=/jails/system/logserver/usr/ports dpool/jails/ports/system/logserver /sbin/zfs set mountpoint=/jails/system/mail/usr/ports dpool/jails/ports/system/mail
Ezt is tegyük bele a crontab-ba:
0 13 * * * /root/bin/cron/jails/portsnap.sh
A wiki-n leírt összes tartalom felment a szerverre, így most up-to-date az írás és a valóság.
Kisebb-nagyobb nehézségek árán ugyan – de sikerült feltelepíteni kettő FreeBSD-t a szerverre. Érdekességképpen, a telepítés során iszonyú lassan reagált a gép, ami eléggé riasztó volt (200-300kBájt/s írás!), de újraindítás után már megfelelő sebességgel működött. Az új alaprendszert és kernelt már otthon fordítottam és single-user mód helyett multi-user módban kapta az installworld és az installkernel parancsokat, majd ezek után újraindítottam. Egyelőre nincs nyoma annak, hogy ez hátránnyal járt volna.
A RAID vezérlő nem győzött meg igazán:
root@freebsd:~$ dd if=/dev/zero of=/root/testfile ibs=65536 count=16384
16384+0 records in
2097152+0 records out
1073741824 bytes transferred in 161.619783 secs (6643629 bytes/sec)
root@freebsd:~$ dd if=/root/testfile of=/dev/null ibs=1024
1048576+0 records in
2097152+0 records out
1073741824 bytes transferred in 16.862023 secs (63678115 bytes/sec)
6MBájt/s írás és 60MBájt/s olvasás nem tűnik jónak, legalábbis a 6MBájt/s kevés... nemde?