Ihsan Dogan's Solaris Blog

Jörg Mollenkamp hat gestern eine überarbeitete Version seines Buches “Less known Solaris Features” veröffentlicht und wird als PDF zum Download angeboten.

Anfangs Woche veröffentlichte Wietse Venema die Version 2.6.0 von Postfix. Die 2.6.0 Pakete für Solaris sind nun jetzt unter ihsan.dogan.ch/postfix verfügbar. makePostfixPkg wurde an Postfix 2.6.0 angepasst und ist jetzt in der Version 0.3.3 verfügbar.

Seit Solaris 10 Update 6 ist es möglich, von ZFS zu booten und dieses für die Root Partition einzusetzen. In Verbindung mit Live Upgrade ist es möglich, eine relativ schmerzlose Migration von UFS nach ZFS zu bewerkstelligen. In folgendem Beispiel erkläre ich wie man ein mit SDS gespiegeltes System nach ZFS migriert.

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     -

Bind, welches als authorativer und rekursiver DNS arbeitet, der Platzhirsch in Sachen DNS Server Software. Es ist allerdings auch bekannt, dass Bind, obwohl die Version 9 ein Rewrite ist, gravierende Design Probleme hat, welche sich im vergangen Jahr in Form von teils gravierenden Sicherheitslücken gezeigt hat. Auf diese Problematik hat in der Vergangenheit bereits Dan Bernstein hingewiesen und djbdns geschrieben, welches aber ziemlich eigen ist. Auch wurde die  Entwicklung  von djbdns eingestellt, wobei die spezielle Lizenz von djb nicht unschuldig daran ist. Die Kritik gegenüber Bind wird vom ISC insofern bestätigt, dass das Design der Kommenden Version 10 geändert wird – darauf kann man aber 5 Jahre lang warten.

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.

In Verbindung mit ZFS kommt das Solaris Feature Live Upgrade so richtig zur geltung. Neben dem regulären update der Solaris Version ist es auch möglich, Patches zu installieren. Auch hier ist es möglich, PCA zu benutzen.

Wie üblich, müssen die Patches zuerst mit PCA runter geladen werden:

# pca -y -d -a -t 4

Da die Patches nicht mit pca selber installiert werden, müssen die Patches zuerst entpackt werden:

# for i in *.zip ; do unzip -q $i ; done

Danach muss mit pca ein Patch Order File erstellt werden, damit die Patches in der richtigen Reihenfolge installiert werden.

# pca --noheader --format '%p-%c' > patch-order

Im nächsten Schritt muss ein neues Boot Environment erstellt werden:

# lucreate -n s10xu7p1

Falls das aktuelle Boot Environment noch keinen Namen hat, muss diesem noch ein Namen zugeteilt werden:

# lucreate -c s10xu7 -n s10xu7p1

Die Patches können mit luupgrade installiert werden. Die Option -s gibt den Pfad zu den extrahierten Patches an.

# luupgrade -n s10xu7p1 -t -s . `cat patch-order`

So bald die Installation der Patches fertig ist, muss das neue Boot Environment aktiviert werden und das System neu gestartet werden.

# luactivate s10xu7p1
# init 6

Nach dem Booten des System kann das alte Boot Environment gelöscht werden.

# ludelete s10xu7

Letzte Woche wurde bekannt, dass Oracle Sun übernehmen werde. Diese Meldung kam doch sehr überraschend, da niemand damit gerechnet hat. Durch den Abbruch der Gespräche mit IBM hatte man erwartet, dass diese wieder aufgenommen werden könnten.

Was bedeutet die Übernahme von Sun durch Oracle? Das ist eine der Fragen, welche die IT Industrie in den vergangenen Wochen beschäftig hat, welche insbesondere dadurch gestärkt wurde, da Oracle keine Pläne zu dieser Übernahme präsentiert hat. Es stellt sich natürlich die Frage, ob diese Übernahme geplant war oder nicht. Falls sie geplant war, dann rückt das die Gespräche mit IBM in ein ganz anderes Licht, da diese dann nur noch ein Teil des Spiels war.

Erstaunt hat mich, dass viele Leute, insbesondere aus der Linux Ecke, gefragt haben, was jetzt mit OpenOffice und MySQL passiert. Meines Erachtens ist diese Frage bei diesen beiden Produkten gar nicht Relevant, da diese Frage sich selber beantwortet, wenn man die Verbreitung und die Lizenz dieser Produkte anschaut. Mir scheint es, dass hier einige OSS Evangelisten nicht ganz begriffen haben, wie das mit OSS genau funktioniert.

Viel interessanter dürfte hingegen sein, was mit dem ganzen Hardware- und Softwareportfolio passieren wird. Oracle hat letzte Woche ein halbherziges commitment gemacht, dass Oracle die Sparc CPU weiterführen möchte. Das ist natürlich schon mal etwas, ich habe mir allerdings sagen lassen, dass Sun in Sachen Sun vertraglich geregelte Verpflichtungen mit anderen Firmen hat.

Auch Solaris dürfte nicht zum Opfer fallen. Zum einen hat Oracle jetzt das Unix in der Hand, welches im Server bereich am weitesten verbreitet ist. Ausserdem ist Solaris unter der CDDL Lizenz OSS und wird auch Solaris kein Opfer werden.

Produkte aus der JES Palette dürften eher die fraglichen Produkte sein. Oracle hat hier einige Produkte in doppelter und teilweise auch dreifacher ausführung (App Server). Die Tatsache, dass Sun in letzter Zeit Produkte aus diesem Bereich unter Open Source gestellt zeigt, dass man bereits wusste bzw. eine Vorahnung hatte. Diese Strategie könnte aber dadurch aufgehen, dass durch die Open Source Lizenz die Verbreitung der einzellnen Produkte gefördert wird und Oracle sich später dann für die Sun Produkte entscheiden wird, während die Produkte von Oracle bzw. Bea eingestellt werden, da es schlicht und einfach keinen Sinn macht Produkte doppelt im Portfolio zu führen.

Was auch interessant sein dürfte, was mit dem Namen “Sun” passiert. Dieser Name ist bereits fest in der IT verankert und stellt sich, berechtigterweise, die Frage, was damit passiert. Da es im Gegensatz zu EMC und VmWare zwischen Oracle und Sun doch einige Überschneidungen gibt, ist es wahrscheinlich, dass der Name Sun längerfristig entweder von der Bildfläche verschwinden wird oder wie StorageTek gehanhabt wird.

Nach langer Zeit habe ich endlich wieder mal die Postfix Pakete für Solaris aktualisiert. Die mit makePostfixPkg 0.3.1 erzeugten Pakete sollten jetzt endlich “zone safe” sein. Das ist leider bis jetzt nicht zu 100% getestet, deshalb bin ich für Feedback dankbar.

Neu ist auch, dass das File /etc/mail/aliases erstellt wird, sofern dieses nicht vorhanden ist.

Die Pakete sind dazu gedacht, den mit Solaris mitgelieferten Sendmail zu ersetzen und sind unter ihsan.dogan.ch/postfix/ verfügbar.

Nach langer langer Zeit hat Adobe jetzt endlich wieder neben der Sparc Version auch eine Version für x86 zur Verfügung. Es stellt sich jetzt aber die Frage, wie lange es eine Sparc Version noch geben wird, da Sun die Produktion von Sparc Workstations eingestellt hat.

Adobe Reader 9.1 unter Solaris 10 x86

Gemäss Zeitungsberichten soll IBM mit Sun Verhandlungen über eine mögliche übernahme verhandeln. Ich hätte erwartet, dasss Sun von Fujitsu übernommen werden würde, da die beiden Untermehmen synergien nutzen könnte. Bei einer Übernahme der Sun durch IBM stellt sich die Frage, in wie weit die Produkte von Sun erhalten bleiben, da IBM einer der grössten Mitbewerber der Sun ist.

Folgende Aussage ist Interessant:
In recent months, Sun has approached a number of large tech companies in the
hopes of being acquired, say people familiar with the matter. The world’s
largest tech company, Hewlett-Packard, declined the offer, says a person
briefed on the matter. A spokesman for Dell Inc., the world’s third-largest
server maker, declined to comment.

Es scheint, dass Sun übernommen werden möchte. Dies wäre ein klarer Wiederspruch zu Scott McNeally’s früheren Aussagen, dass Sun unabhängig bleiben soll. Erstaunlich ist, dass Sun bereits HP und Dell bereits betreffend einer Übernahme angefragt haben soll.

DJ IBM verhandelt mit Sun über Übernahme – WSJ
18.03.09 08:44:00- DJGC
NEW YORK (Dow Jones)–In der Branche der Serverhersteller bahnt sich einem
Zeitungsbericht zufolge eine milliardenschwere Übernahme an. Wie das “Wall
Street Journal” (WSJ) am Mittwoch berichtet, verhandelt die International
Business Machines Corp (IBM) mit dem Wettbewerber Sun Microsystems Inc
über einen Kauf. Die Zeitung beruft sich dabei auf mit der Angelegenheit
vertraute Personen.
Es sei momentan noch unklar, ob eine Übernahme zustandekomme, heißt
es im WSJ. Sollte es jedoch zu einer Einigung kommen, dann müsse IBM
mindestens 6,5 Mrd USD in bar zahlen, um Sun zu übernehmen, hätten
die informierten Personen gesagt. Das wäre mehr als das Doppelte des
Schlusskurses von Sun am Dienstag.
Beiden Unternehmen gemeinsam ist der Zeitung zufolge, dass sie Computersysteme
für Firmenkunden herstellen, die nicht auf das Betriebssystem “Windows”
von Microsoft oder Chips von Intel angewiesen sind. IBM und Sun seien zudem
starke Unterstützer von Software mit offenem Quellcode wie Linux und
Java-Internetanwendungen.
In den vergangenen Monaten habe Sun eine Reihe von Technologieunternehmen
angesprochen, ob sie nicht an einer Übernahme interessiert seien, schreibt
das WSJ mit Bezug auf informierte Personen weiter. Die Nummer zwei im
Servermarkt, der kalifornische Hersteller Hewlett-Packard Co (HP), habe
abgelehnt.
Laut einer Analyse der Marktforscher von IDC hatte IBM im Jahr 2008 einen
Marktanteil von 31,4%. HP kam demnach auf einen Anteil von 29,5%, Dell Inc
bediente 11,6%. Sun lag auf dem vierten Rang mit einem Anteil von 10,6%.
Webseiten: http://online.wsj.com

DJG/DJN/mmr/cbr
Besuchen Sie unsere neue Webseite http://www.dowjones.de
(END) Dow Jones Newswires
March 18, 2009 03:44 ET (07:44 GMT)
Copyright (c) 2009 Dow Jones & Company, Inc.

UPDATE:
Heise und Golem berichten mittlerweile auch darüber.

Ich habe heute auf meinem MacBook Pro Solaris 10 Update 6 als virtuelle Maschine innerhalb von VMware Fusion installiert. Da der mit Solaris mitgelieferte X.Org die WXGA+ Aulfösung von 1440×900 Auflösung von Haus aus nicht beherscht, ist in der /etc/x11/xorg.conf unter Section “Monitor” Identifier “vmware” folgender Eintrag notwendig:

ModeLine "1440x900" 100 1440 1500 1600 1700 900 1000 1100 1200