• What’s New in OpenSolaris 2010.05

Interessant bei dieser Entscheidung ist aber folgende Aussage auf der OpenSolaris Malingliste:

The Opera staff asked – as usual – for help to circumvent a Solaris
bug. The (new) response, totally the opposite from Sun’s helpful
behavior of the past was:

1. Opera did not purchase support for Solaris
2. Without support Oracle will not answer technical questions or provide ANY help
3. Opera uses the SOLARIS trademark without permission
4. Opera will have to buy a full year of support for 502018 Euro to obtain questions to their answers

In wie fern diese Aussage stimmt ist schwer abzuschätzen. Es kann sich durch aus um FUD handeln, es wäre aber auch vorstellbar, dass auch eine Spur Wahrheit in dieser Aussage steckt.

root@planex:~# ipfstat | grep lost
fragment state(in):     kept 0  lost 0  not fragmented 0
fragment state(out):    kept 0  lost 0  not fragmented 0
packet state(in):       kept 33302919   lost 11264
packet state(out):      kept 8572793    lost 214808

Interessant sind hier die lost Werte. Schaut man sich die default Settings an, merkt man, dass die Einstellungen in der Tat doch recht konservativ sind:

root@planex:~# ipf -T list | grep fr_state
fr_statemax     min 0x1 max 0x7fffffff  current 4013
fr_statesize    min 0x1 max 0x7fffffff  current 5737

Um die Limite zu erhöhen, muss als erstes ipf deaktiviert werden und anschliessend wieder aktiviert werden. Zu beachten ist dabei, dass fr_statemax ca. 70% so gross ein sollte wie fr_statesize.

root@planex:~# svcadm disable ipfilter
root@planex:~# /usr/sbin/ipf -T fr_statemax=24500,fr_statesize=35000
root@planex:~# svcadm enable ipfilter

root@planex:~# ipf -T list | grep fr_state
fr_statemax     min 0x1 max 0x7fffffff  current 24500
fr_statesize    min 0x1 max 0x7fffffff  current 35000

Damit die neuen Werte auch über die Reboot-Grenze erhalten bleiben, sollte folgender Eintrag in der /usr/kernel/drv/ipf.conf stehen:

name="ipf" parent="pseudo" instance=0; fr_statemax=24500 fr_statesize=35000;

Abschliessend sollte das Device mit devfsadm konfiguriert werden:

root@planex:~# devfsadm -i ipf

Als Workaround empfiehlt es sich das System in den maintenance mode zu booten und den Fehlerhaften Eintrag in der /etc/vfstab zu entfernen

• Two-Terabyte Disk Support for Installing and Booting the Solaris OS
• pcitool Utility
• ZFS and Flash installation support
• Setting ZFS user and group quotas
• Using ZFSACL pass through inheritance for execute permission
• Using cache devices in your ZFS storage pool
• ZFS property enhancements
• ZFS log device recovery
• Using ZFS ACL Sets
• nss_ldap shadowAccount Support
• SunValidationTest Suite 7.0 Patch Set 6
• Turbo-Charging SVR4 Packaging
• Zones Parallel Patching
• PVIO Drivers in Solaris 10 Guest Domains
• iSCSI Initiator SMF Service
• LSI 6180 Controller Support in Solaris MPxIO
• Callout SubsystemScalability
• Driver for LSI MPT 2.0-Compliant SAS2.0 Controllers
• x86: BroadcomNetXtreme II Gigabit Ethernet Driver
• x86: Interrupt Remapping Support for Intel Vt-d
• x86: SATATape Devices Supported by the AHCI Driver
• Sun StorageTek 6Gb/s SAS PCIe RAID HBA Driver
• Intel 82599 10Gb PCI Express Ethernet Controller
• Intel 82598 10Gb PCI Express Ethernet Controller
• NTPVersion 4.2.5

Quelle: 821-0382-10, Solaris 10 10/09What’s New

kSar schafft hier Abhilfe. kSar ist ein in Java geschrieben Sar Grapher, welche die mit sar -A exportierten Daten graphisch darstellt.

Als Vorbereitung muss man, wie bei Live Upgrade üblich, zuerst die vorhandenen Pakete deinstalieren (falls vorhanden) und die aktuellste Version installieren.

# pkgrm SUNWlucfg SUNWluu SUNWlur
# pkgadd -d /path/to/Solaris SUNWlucfg SUNWluu SUNWlur

Anschliessend müssen die Patches gemäss dem Infodoc 206844 installiert werden.

Nachdem alles Patches installiert wurden und das System neu gestartet wurde, kann mit der eigentlichen Migration begonnen werden. Da für die Migration der Spiegel aufgebrochen werden muss, empfiehlt sich folgender Eintrag in der /etc/system, da Solaris nicht bootet, wenn weniger als 50% der metadbs verfügbar sind.

set md:mirrored_root_flag=1

Anschliessend kann damit begonnen werden, den Mirror aufzubrechen.

root@v240lu:~# metastat -c
d0               m   23GB d7 d8
    d7           s   23GB c1t0d0s0
    d8           s   23GB c1t1d0s0
d3               m  8.0GB d5 d6
    d5           s  8.0GB c1t0d0s3
    d6           s  8.0GB c1t1d0s3
d1               m  2.0GB d2 d4
    d2           s  2.0GB c1t0d0s1
    d4           s  2.0GB c1t1d0s1

root@v240lu:~# metadetach d0 d8
d0: submirror d8 is detached
root@v240lu:~# metadetach d3 d6
d3: submirror d6 is detached
root@v240lu:~# metadetach d1 d4
d1: submirror d4 is detached

root@v240lu:~# metaclear d8
d8: Concat/Stripe is cleared
root@v240lu:~# metaclear d6
d6: Concat/Stripe is cleared
root@v240lu:~# metaclear d4
d4: Concat/Stripe is cleared

Auch die metadb darf nicht vergessen werden:

root@v240lu:~# metadb
        flags           first blk       block count
     a m  p  luo        16              8192            /dev/dsk/c1t0d0s7
     a    p  luo        8208            8192            /dev/dsk/c1t0d0s7
     a    p  luo        16400           8192            /dev/dsk/c1t0d0s7
     a    p  luo        24592           8192            /dev/dsk/c1t0d0s7
     a    p  luo        16              8192            /dev/dsk/c1t1d0s7
     a    p  luo        8208            8192            /dev/dsk/c1t1d0s7
     a    p  luo        16400           8192            /dev/dsk/c1t1d0s7
     a    p  luo        24592           8192            /dev/dsk/c1t1d0s7

root@v240lu:~# metadb -d c1t1d0s7

Jetzt mus die zweite Disk, die c1t1d0 neu partitioniert werden. Um von ZFS booten zu können, wird ein SMI label auf der Disk benötigt. In diesem Beispiel habe ich mich entschieden, den Slice 0 auf die grösse der Disk zu setzen. In diesen Slice wird jetzt das neue ZFS erstellt.

root@v240lu:~# zpool create -f rpool c1t1d0s0

Im nächsten Schritt wird das Boot Environment erzeugt. Das alte Boot Environment wird hier s10su6 und das neue s10su7 benannt.

root@v240lu:~# lucreate -c s10su6 -n s10su7 -p rpool

Wenn das neue Boot Environment erfolgreich erzeugt wurde und die aktuelle Solaris installation auf die Disk kopiert wurde, sollte man folgende Situation haben:

root@v240lu:~# zfs list
NAME                USED  AVAIL  REFER  MOUNTPOINT
rpool              8.29G  24.9G  92.5K  /rpool
rpool/ROOT         4.29G  24.9G    18K  /rpool/ROOT
rpool/ROOT/s10su7  4.29G  24.9G  4.29G  /
rpool/dump            2G  26.9G    16K  -
rpool/swap         2.00G  26.9G    16K  -

root@v240lu:~# lustatus
Boot Environment           Is       Active Active    Can    Copy
Name                       Complete Now    On Reboot Delete Status
-------------------------- -------- ------ --------- ------ ----------
s10su6                     yes      yes    yes       no     -
s10su7                     yes      no     no        yes    -

Jetzt kann mit dem Upgrade begonnen werden:

root@v240lu:~# luupgrade -n s10su7 -u -s /path/to/solaris

Wenn dies ebenfalls erfolgreich abgeschlossen wurde, kann das neue Boot Environment aktiviert werden:

root@v240lu:~# luactivate s10su7

Falls dies mit folgender Fehlermeldung abbrechen sollte, ist man Opfer des Bugs 6824589 geworden.

/usr/sbin/luactivate: /etc/lu/DelayUpdate/: cannot create

Als Workaround muss die Variable BOOT_MENU_FILE gesetzt werden und luactivate erneut ausgeführt werden.

root@v240lu:~# export BOOT_MENU_FILE="menu.lst"
root@v240lu:~# luactivate s10su7

Anschliessend kann das System neu gestartet werden.

root@v240lu:~# init 6

Das System sollte jetzt mit dem aktualisierten Solaris auf ZFS booten. Sofern der Upgrade geglückt ist, kann das alte Boot Environment sowie die verbleibende Hälfte des Mirrors gelöscht werden. Wichtig ist dabei, dass die Reihenfolge eingehalten wird und das Boot Environment zuerst gelöscht wird.

root@v240lu:~# ludelete s10su6

Und wie folgt den verbleibenden Mirror und die Metadbs entfernen:

root@v240lu:~# metastat -c
d0               m   23GB d7
    d7           s   23GB c1t0d0s0
d3               m  8.0GB d5
    d5           s  8.0GB c1t0d0s3
d1               m  2.0GB d2
    d2           s  2.0GB c1t0d0s1

root@v240lu:~# metaclear d0
d0: Mirror is cleared
root@v240lu:~# metaclear d3
d3: Mirror is cleared
root@v240lu:~# metaclear d1
d1: Mirror is cleared
root@v240lu:~# metaclear d7
d7: Concat/Stripe is cleared
root@v240lu:~# metaclear d5
d5: Concat/Stripe is cleared
root@v240lu:~# metaclear d2
d2: Concat/Stripe is cleared

root@v240lu:~# metadb
        flags           first blk       block count
     a m  pc luo        16              8192            /dev/dsk/c1t0d0s7
     a    pc luo        8208            8192            /dev/dsk/c1t0d0s7
     a    pc luo        16400           8192            /dev/dsk/c1t0d0s7
     a    pc luo        24592           8192            /dev/dsk/c1t0d0s7

root@v240lu:~# metadb -fd c1t0d0s7

Abschliessend wir die gerade vom SDS befreite Disk in den Zpool eingebunden. Beachten sollte man dabei, dass es sich hier um eine Boot Disk mit einem SMI Label handelt und diese von der bereits vorhandenen Disk kopiert werden sollte.

root@v240lu:~# prtvtoc /dev/rdsk/c1t1d0s2 | fmthard -s – /dev/rdsk/c1t0d0s2
root@v240lu:~# zpool attach rpool c1t1d0s0 c1t0d0s0

Jetzt sollte man folgenden Stand haben:

root@v240lu:~# zpool status
  pool: rpool
 state: ONLINE
status: One or more devices is currently being resilvered.  The pool will
        continue to function, possibly in a degraded state.
action: Wait for the resilver to complete.
 scrub: resilver in progress for 0h0m, 0.33% done, 0h55m to go
config:

        NAME          STATE     READ WRITE CKSUM
        rpool         ONLINE       0     0     0
          mirror      ONLINE       0     0     0
            c1t1d0s0  ONLINE       0     0     0
            c1t0d0s0  ONLINE       0     0     0

errors: No known data errors

root@v240lu:~# lustatus
Boot Environment           Is       Active Active    Can    Copy
Name                       Complete Now    On Reboot Delete Status
-------------------------- -------- ------ --------- ------ ----------
s10su7                     yes      yes    yes       no     -

Für den, der nicht so lange warten mag, ist NSD die Alternative zu Bind. NSD wurde von der NLnet Labs in zusammenarbeit mit der RIPE NCC entwickelt. Ein Hauptaugenmerk der Entiwicklung war dabei nicht nur die Performance, sondern auch die Sicherheit, weshalb NSD per Design nur ein authorativer DNS Server ist.

Die Installation von NSD ist mit OpenCSW denkbar einfach:

# pkg-get install nsd

Nach der Installation muss man das Konfigurationsfile nsd.conf bearbeiten, welches unter /etc/opt/csw/nsd zu finden ist. Das File ist selbsterklärend und mit der dazugehörigen Mangpage ist auch ausreichend Dokumentationvorhanden.

Um eine Zone erstellen, ist Beispielsweise folgender Eintrag notwendig:

zone:
   name: "opencsw.org"
   zonefile: "master/db.opencsw.org"
   outgoing-interface: 147.87.98.73

   # secondary: ns2.sixxs.net
   notify: 193.109.122.62 NOKEY
   provide-xfr: 193.109.122.62 NOKEY

   # secondary: ns1.tomppa.ch
   notify: 195.182.53.134 NOKEY
   provide-xfr: 195.182.53.134 NOKEY

Das für Bind erstellte Zone File kann man dabei 1:1 übernehmen und es ist keinerlei Anpassung notwendig.

Nachdem die nsd.conf bearbeitet wurde, kann man mit

# nsd-checkconf /etc/opt/csw/nsd/nsd.conf

das File auf allfällige Fehlber überprüft werden.

Der grösste Unterschied zu Bind dürfte sein, dass NSD nicht direkt die Zonenfiles lädt, sondert eine Datenbank, welche zuerst mit zonec erstellt wurde. Das tönt zwar umständlich, hat aber den Vorteil, dass NSD in grösseren Konfigurationen sehr schnell gestartet werden kann.

# nsdc rebuild

Erstellt die Datenbank /var/opt/csw/nsd/nsd.db. Nachdem die Datenbank erstellt worden ist, kann NSD gestartet werden.

WICHTIG: Alfällige Fehlermeldungen, dass Slave Zonen nicht gefunden werden können, können ignoriert werden.

# svcadm enable svc:/network/cswnsd:default

Abschliessend ist ein Eintrag in der crontab notwendig:

42 4 * * *      /opt/csw/sbin/nsdc patch >/dev/null 2>&1

Dieser Eintrag bewirkt, dass die Slave Zonen von der ixfr.db in die in der nsd.conf angebenen Zonen Files geschrieben werden und das die ixfr.db mit der Zeit nicht zu gross wird. Es empfiehlt sich, nsd-patch ein mal am Tag laufen zu lassen.

Mehr Dokumentation zu NSD ist in den Mitgelieferten Manpages nsdc(8), nsd.conf(5), nsd-checkconf(8), nsd-notify(8), nsd-patch(8), nsd-xfer(8) und zonec(8) zu finden.