D.h. ich werde jetzt AIX-Admin mit Migrationshintergrund.

P.S.

Ich wünsche den Sunnies beim Merge mit Oracle noch alles Gute und hoffe, dass ich Solaris nicht allzu sehr hinterhertrauern muss…

Kurierdienst bringt Paket, 20min später steht der Sun/STK-Techniker vor der Tür. Da sich der Picker nicht mehr bewegt, wird er vom Techniker in Parkposition gebracht. Dazu nimmt er die Frontblende ob und bewegt mit einer originellen Ausziehmechanik den Seilzug, der den Picker nach oben verfrachtet. Jetzt kann die Robotik inc. Picker in einem Stück herausgezogen werden.

Nach Ein- und Ausschalten, Selbsttest und Inventory leuchten keine Service-LEDs mehr. Ein Blick in die SL-Console soll Klarheit verschaffen:

Die Hardware scheint also wieder i.O. zu sein.

Nun den EMC Networker mit /etc/init.d/networker start wieder hochfahren.

Den Start z.B. mit nsrwatch verfolgen und auf Fehler prüfen.

root # grep ready /nsr/logs/daemon.raw > – | nsr_render_log -
42506 08/18/08 12:50:05  2 0 0 1 15744 0 senbackup1 nsrd media info: Jukebox `senlib3′ Hardware status of jukebox ‘senlib3′ is ‘ready’

Nun die Tape Library und deren Laufwerke im Networker ggf. wieder auf Enable setzen. Anschließend Reset und Inventory durchführen. Jetzt testweise Bänder Laden/Entladen, an der Tape Library kontrollieren.

Alles perfekt, bis auf… Band 186 fehlt?!?

Der Techniker gibt Entwarnung – es steckt noch im alten Gripper. Daraus wird es befreit und in einen Cap-Slot gesteckt. Per deposit wandert es wieder in einen freien Slot.

Die ersten Sicherungen laufen automatisch an und beenden sich fehlerfrei.

Fazit:

Mission accomplished!

P.S.

Der Ausfall einer Tape-Library kann fatale Folgen haben, selbst wenn kein Restore/Recovery benötigt wird.

• Meistens wird die Tape Library auch zum Staging für AFTDs benutzt (Verschieben von Daten auf Backup to Disk devices nach gewissen Regeln auf Band). Wenn die Library nicht läuft wird auch kein Staging erfolgreich verlaufen. Wer hier zu wenig Freiraum im Advanced Filetype device gelassen hat bekommt nun das nächste Problem: Disk full…
• Datenbanken wie Oracle RDBMS, Microsoft SQL Server und Exchange, IBM DB2… führen i.d.R. Transaktionsprotokolle auf Disk. Wer hier beim Plattenplatz gegeizt hat – ebenfalls viel Spaß. Ich sag nur Archiverstuck…

Wie man sieht ist es ratsam bei nicht redundanter Hardware sich Gedanken über Problemfälle zu machen. Am Besten bevor diese auftreten

Na klasse! Vor Ort blinkt einem gelb entgegen “Service Robot” und “Service required”:

Also bleibt nichts anderes übrig als mal einen Blick in die Höhle des Löwen zu werfen. Dazu “Open Door” drücken und Schlüssel drehen.

Komisch dabei ist, dass die Robotik sich nicht nach ganz oben oder unten aus dem Staub gemacht hat. Sie steht im unteren Drittel, knapp unterhalb der LTO-3 Drives.

Ich nehme alle Bänder aus den Drives, stecke sie in freie Schächte und drücke alle Bänder zur Sicherheit nochmals in ihre Slots.

Danach schließe ich die Türe der Tape Library wieder und diese beginnt mit dem Inventory.

Zum Ende des Inventory fährt die Robotik wieder in die Position im unteren Drittel, gibt kurz knarrzende Geräusche von sich und die Service-LEDs sind wieder aktiv.

Ein Reboot über die SL Console führt zum selben Ergebnis.

Dann eben mal die Holzhammer-Methode: Strom aus…

Das wäre auch zu schön gewesen – natürlich das selbe Ergebnis wie zuvor.

Da also nichts mehr zu retten ist habe ich den Networker per Holzhammer beendet:

root # nsr_shutdown -f -t 10

Der Backup Server darf also jetzt mal eine Verschnaufpause einlegen.

Die SL Console gibt im Errorlog folgendes bekannt:

                     Time : 2008-08-16T16:15:55.267
                     Device Address : 0.0.0.0.0
                     User : unknown
                     Requester : default
                     Activity : 0000
                     Request Id : /usr/local/bin/Ifm
                     Level : error
                     Result Code : 5014
                     Text : , “Director – auditResponse() : cmo_user_audit: Failed target calibration for (LMRC) 0,3,1,9, result code=5014″
                 
              
                     Time : 2008-08-16T16:15:55.300
                     Device Address : 0.0.0.0.0
                     User : unknown
                     Requester : default
                     Activity : 0100
                     Request Id : (null)
                     Level : error
                     Result Code : 3717
                     Text : , “IfmInitThread:Failure to Initialize…reason==Robot initialization failed – GOING INOP”

Fazit:

Call bei Sun/STK geöffnet…

Die Preisfrage lautet jetzt: ” Was ist mit der Tape Library los? Liegt das Problem auf Seite des Hosts oder Jukebox?”

Dazu erst einmal das Networker-Log in ein brauchbares Format konvertieren:

root # nsr_render_log /nsr/logs/daemon.raw > /tmp/daemon.log

Nun mit dem Editor der Wahl o.ä. zum Ende des Protokolls und dann zum Beginn des Fehlers zurückblättern:

Ende des Logs:

…

7224 08/15/08 19:05:12  2 0 0 1 17996 0 senbackup1 nsrd [Jukebox `senlib3', operation # 3547]. Jukebox `senlib3′ is not ready or it is busy.
39078 08/15/08 19:05:13  0 0 2 3 18486 0 senbackup1 nsrlcpd#1 Jukebox error: Jukebox:senlib3 access:/dev/scsi/changer/c3t500104F0007E9B64d0 failed:MOVE MEDIUM key:2 status:CHECK CONDITION No Additional Sense, Logical Unit Not Ready, Manual Intervention Required
0 08/15/08 19:05:14  2 0 0 1 18471 0 senbackup1 nsrmmgd lcpd 1 at host senbackup1 reported error ‘Jukebox `senlib3′ is not ready or it is busy.’ for the command `4′.
7224 08/15/08 19:05:14  2 0 0 1 17996 0 senbackup1 nsrd [Jukebox `senlib3', operation # 3548]. Jukebox `senlib3′ is not ready or it is busy.
4690 08/15/08 19:05:14  2 0 0 1 18471 0 senbackup1 nsrmmgd Jukebox `senlib3′ is not ready or it is busy.
7224 08/15/08 19:05:14  2 0 0 1 17996 0 senbackup1 nsrd [Jukebox `senlib3', operation # 3548]. Jukebox `senlib3′ is not ready or it is busy.
12361 08/15/08 19:05:15  2 0 0 1 17996 0 senbackup1 nsrd [Jukebox `senlib3', operation # 3547]. Finished with status: retryable

…

Beginn des Fehlers:

…

42506 08/14/08 22:33:05  2 0 0 1 17996 0 senbackup1 nsrd write completion notice: Writing to volume 000061 complete
0 08/14/08 22:34:10  2 0 0 1 17996 0 senbackup1 nsrd Operation 277 started : Unload jukebox device `/dev/rmt/2cbn’..
38752 08/14/08 22:34:12  2 0 0 1 17996 0 senbackup1 nsrd /dev/rmt/2cbn Eject operation in progress
39078 08/14/08 22:36:55  0 0 2 3 18486 0 senbackup1 nsrlcpd#1 Jukebox error: Jukebox:senlib3 access:/dev/scsi/changer/c3t500104F0007E9B64d0 failed:MOVE MEDIUM key:4 status:CHECK CONDITION No Additional Sense, Diagnostic Failure on Component 0×01
0 08/14/08 22:36:56  2 0 0 1 18471 0 senbackup1 nsrmmgd lcpd 1 at host senbackup1 reported error ‘Jukebox:senlib3 access:/dev/scsi/changer/c3t500104F0007E9B6
4d0 failed:MOVE MEDIUM key:4 status:CHECK CONDITION No Additional Sense, Diagnostic Failure on Component 0×01′ for the command `5′.
7224 08/14/08 22:36:56  2 0 0 1 17996 0 senbackup1 nsrd [Jukebox `senlib3', operation # 277]. Jukebox:senlib3 access:/dev/scsi/changer/c3t500104F0007E9B64d0
failed:MOVE MEDIUM key:4 status:CHECK CONDITION No Additional Sense, Diagnostic Failure on Component 0×01
4690 08/14/08 22:36:56  2 0 0 1 18471 0 senbackup1 nsrmmgd Jukebox:senlib3 access:/dev/scsi/changer/c3t500104F0007E9B64d0 failed:MOVE MEDIUM key:4 status:CHECK CONDITION No Additional Sense, Diagnostic Failure on Component 0×01
7224 08/14/08 22:36:56  2 0 0 1 17996 0 senbackup1 nsrd [Jukebox `senlib3', operation # 277]. Jukebox `senlib3′ failed to unload the requested volume from de
vice `/dev/rmt/2cbn’.
7224 08/14/08 22:36:56  2 0 0 1 17996 0 senbackup1 nsrd [Jukebox `senlib3', operation # 277]. Jukebox:senlib3 access:/dev/scsi/changer/c3t500104F0007E9B64d0
failed:MOVE MEDIUM key:4 status:CHECK CONDITION No Additional Sense, Diagnostic Failure on Component 0×01
12361 08/14/08 22:37:00  2 0 0 1 17996 0 senbackup1 nsrd [Jukebox `senlib3', operation # 277]. Finished with status: retryable
42506 08/14/08 22:37:28  2 0 0 1 17996 0 senbackup1 nsrd media warning: Jukebox `senlib3′ Hardware status of jukebox ‘senlib3′ changed from ‘ready’ to ‘needs
attention’
…

Aha. Scheinbar ist das Entladen eines Tapes fehlgeschlagen. Seitdem reagiert die Jukebox nicht mehr.

Es handelt sich hier um eine Sun/STK SL500 Tape-Library, die per Fibrechannel-Fabric angebunden ist. Jetzt also erst mal prüfen, ob es ggf. Probleme im SAN gibt.

Zunächst einmal gilt es Infos zur Jukebox-Konfiguration in Erfahrung zu bringen. Aus den obigen Fehlermeldungen wissen wir bereits, dass das Jukebox-Changer-Device /dev/scsi/changer/c3t500104F0007E9B64d0 heißt und somit am Controller 3 angeschlossen ist.

root@senbackup1 # ls -l /dev/scsi/changer
total 2
lrwxrwxrwx   1 root     root          89 Sep 11  2007 c3t500104F0007E9B64d0 -> ../../../devices/pci@7c0/pci@0/pci@8/SUNW,qlc@0,1/fp@0,0/sgen@w500104f0007e9b64,0:changer

root # ls -l /dev/rmt/*cbn
lrwxrwxrwx   1 root     root          80 Sep 13  2007 /dev/rmt/0cbn -> ../../devices/pci@7c0/pci@0/pci@8/SUNW,qlc@0,1/fp@0,0/st@w500104f0007e9b71,0:cbn
lrwxrwxrwx   1 root     root          80 Sep 13  2007 /dev/rmt/1cbn -> ../../devices/pci@7c0/pci@0/pci@8/SUNW,qlc@0,1/fp@0,0/st@w500104f0007e9b6e,0:cbn
lrwxrwxrwx   1 root     root          80 Sep 13  2007 /dev/rmt/2cbn -> ../../devices/pci@7c0/pci@0/pci@8/SUNW,qlc@0,1/fp@0,0/st@w500104f0007e9b74,0:cbn
lrwxrwxrwx   1 root     root          80 Sep 13  2007 /dev/rmt/3cbn -> ../../devices/pci@7c0/pci@0/pci@9/SUNW,qlc@0,1/fp@0,0/st@w500104f0007e9b77,0:cbn
lrwxrwxrwx   1 root     root          80 Sep 13  2007 /dev/rmt/4cbn -> ../../devices/pci@7c0/pci@0/pci@9/SUNW,qlc@0,1/fp@0,0/st@w500104f0007e9b7d,0:cbn
lrwxrwxrwx   1 root     root          80 Apr 30 13:34 /dev/rmt/5cbn -> ../../devices/pci@7c0/pci@0/pci@9/SUNW,qlc@0,1/fp@0,0/st@w500104f0007e9b7a,0:cbn

Aus dem Hardwarepfad ist ersichtlich, daß je 3 Laufwerke an 2 seperaten FC-HBAs angeschlossen sind.

root # ls -l /dev/cfg/ | grep devices/pci@7c0/pci@0/pci@8/SUNW,qlc@0,1/fp@0,0
lrwxrwxrwx   1 root     root          56 Aug 24  2007 c3 -> ../../devices/pci@7c0/pci@0/pci@8/SUNW,qlc@0,1/fp@0,0:fc
root # ls -l /dev/cfg/ | grep devices/pci@7c0/pci@0/pci@9/SUNW,qlc@0,1/fp@0,0
lrwxrwxrwx   1 root     root          56 Aug 24  2007 c5 -> ../../devices/pci@7c0/pci@0/pci@9/SUNW,qlc@0,1/fp@0,0:fc

Tape 0,1,2 und die Robotik hängen also am Controller 3, Tape 3,4,5 am Controller 5.

root # fcinfo hba-port -l

…

HBA Port WWN: 2101001b323f0a1d
OS Device Name: /dev/cfg/c3
Manufacturer: QLogic Corp.
Model: 375-3356-01
Firmware Version: 4.2.2
FCode/BIOS Version:  BIOS: 1.24; fcode: 1.26; EFI: 1.8;
Type: N-port
State: online
Supported Speeds: 1Gb 2Gb 4Gb
Current Speed: 4Gb
Node WWN: 2001001b323f0a1d
…

HBA Port WWN: 210100e08bb2d018
OS Device Name: /dev/cfg/c5
Manufacturer: QLogic Corp.
Model: 375-3356-01
Firmware Version: 4.2.2
FCode/BIOS Version:  BIOS: 1.24; fcode: 1.26; EFI: 1.8;
Type: N-port
State: online
Supported Speeds: 1Gb 2Gb 4Gb
Current Speed: 4Gb
Node WWN: 200100e08bb2d018
…

Nun sind also die WWPNs der Controller bekannt. Damit lässt sich abfragen, welche LUNs der Server auf diesen Ports sieht:

root # fcinfo remote-port -p 2101001b323f0a1d -s
Remote Port WWN: 500104f0007e9b64
Active FC4 Types: SCSI
SCSI Target: yes
Node WWN: 500104f0007e9b63
LUN: 0
Vendor: STK
Product: SL500
OS Device Name: /devices/pci@7c0/pci@0/pci@8/SUNW,qlc@0,1/fp@0,0/sgen@w500104f0007e9b64,0
…
Remote Port WWN: 500104f0007e9b6e
Active FC4 Types: SCSI
SCSI Target: yes
Node WWN: 500104f0007e9b6d
LUN: 0
Vendor: HP
Product: Ultrium 3-SCSI
OS Device Name: /dev/rmt/1n
Remote Port WWN: 500104f0007e9b71
Active FC4 Types: SCSI
SCSI Target: yes
Node WWN: 500104f0007e9b70
LUN: 0
Vendor: HP
Product: Ultrium 3-SCSI
OS Device Name: /dev/rmt/0n
Remote Port WWN: 500104f0007e9b74
Active FC4 Types: SCSI
SCSI Target: yes
Node WWN: 500104f0007e9b73
LUN: 0
Vendor: HP
Product: Ultrium 3-SCSI
OS Device Name: /dev/rmt/2n

Am Controller 3 sind 3 HP LTO-3 Tape Drives und der Changer der SL500 (über sgen-Treiber) sichtbar.

root # fcinfo remote-port -p 210100e08bb2d018 -s
…
Remote Port WWN: 500104f0007e9b77
Active FC4 Types: SCSI
SCSI Target: yes
Node WWN: 500104f0007e9b76
LUN: 0
Vendor: HP
Product: Ultrium 3-SCSI
OS Device Name: /dev/rmt/3n
Remote Port WWN: 500104f0007e9b7a
Active FC4 Types: SCSI
SCSI Target: yes
Node WWN: 500104f0007e9b79
LUN: 0
Vendor: HP
Product: Ultrium 3-SCSI
OS Device Name: /dev/rmt/5n
Remote Port WWN: 500104f0007e9b7d
Active FC4 Types: SCSI
SCSI Target: yes
Node WWN: 500104f0007e9b7c
LUN: 0
Vendor: HP
Product: Ultrium 3-SCSI
OS Device Name: /dev/rmt/4n

Am Controller 5 sind 3 HP LTO-3 Tape Drives sichtbar.

Fazit: Im SAN scheint es zumindest auf den ersten Blick kein Problem zu geben.

Der Networker bietet auch noch Befehle zum Thema an:

root # inquire -l

-l flag found: searching all LUNs, which may take over 10 minutes per adapter
for some fibre channel adapters.  Please be patient.
…
scsidev@3.3.0:HP      Ultrium 3-SCSI  M21S|Tape, /dev/rmt/1cbn
S/N: HU107120CY
ATNN=HP      Ultrium 3-SCSI  HU107120CY
WWNN=50060B000036F6EA
WWPN=500104F0007E9B6E
WW2N=500104F0007E9B6D
PORT=00000001
scsidev@3.4.0:HP      Ultrium 3-SCSI  M21S|Tape, /dev/rmt/0cbn
S/N: HU107120BG
ATNN=HP      Ultrium 3-SCSI  HU107120BG
WWNN=50060B000036F686
WWPN=500104F0007E9B71
WW2N=500104F0007E9B70
PORT=00000001
scsidev@3.7.0:HP      Ultrium 3-SCSI  L58S|Tape, /dev/rmt/2cbn
S/N: HU10704J3U
ATNN=HP      Ultrium 3-SCSI  HU10704J3U
WWNN=500110A00058B456
WWPN=500104F0007E9B74
WW2N=500104F0007E9B73
PORT=00000001
…
scsidev@5.1.0:HP      Ultrium 3-SCSI  L58S|Tape, /dev/rmt/3cbn
S/N: HU107070AD
ATNN=HP      Ultrium 3-SCSI  HU107070AD
WWNN=500110A00058D182
WWPN=500104F0007E9B77
WW2N=500104F0007E9B76
PORT=00000001
scsidev@5.3.0:HP      Ultrium 3-SCSI  L58S|Tape, /dev/rmt/5cbn
S/N: HU10704J4A
ATNN=HP      Ultrium 3-SCSI  HU10704J4A
WWNN=500110A00058B446
WWPN=500104F0007E9B7A
WW2N=500104F0007E9B79
PORT=00000001
scsidev@5.6.0:HP      Ultrium 3-SCSI  L58S|Tape, /dev/rmt/4cbn
S/N: HU10704J4R
ATNN=HP      Ultrium 3-SCSI  HU10704J4R
WWNN=500110A00058B42A
WWPN=500104F0007E9B7D
WW2N=500104F0007E9B7C
PORT=00000001

Verdächtig: inquire findet die Robotik nicht…

root # jbverify
14866:jbverify:
Jbverify is running on host senbackup1, SunOS 5.10
….
14917:jbverify:
Finished processing stand-alone devices.
14918:jbverify:
Processing jukebox devices…
14920:jbverify:
Processing jukebox senlib3:
39078:jbverify: SYSTEM error: Device busy
39077:jbverify: error, Cannot initialize jukebox! Driver may not be loaded!
14926:jbverify:
Failed while processing jukebox senlib3 on senbackup1
14929:jbverify:
Finished processing jukebox devices.
**********************************************************************

Summary report of jbverify
======= ====== == ========

Hostname   Device Handle    Blocksize  Jukebox  Drv No. Status
——–   ————-    ———  ——-  ——- ——
senbackup1 /AFTD/Exchange/_AF_readonly 131072 N/A N/A   Pass
senbackup1 /AFTD/Arriba/_AF_readonly 131072 N/A N/A     Pass
senbackup1 /AFTD/Windows/_AF_readonly 131072 N/A N/A     Pass
senbackup1 /AFTD/UNIX/_AF_readonly 131072 N/A   N/A     Pass
senbackup1 /AFTD/SQL/_AF_readonly 131072 N/A    N/A     Pass
senbackup1 /AFTD/Exchange   131072     N/A      N/A     Pass
senbackup1 /AFTD/default/_AF_readonly 131072 N/A N/A     Pass
senbackup1 /AFTD/Arriba     131072     N/A      N/A     Pass
senbackup1 /AFTD/UNIX       131072     N/A      N/A     Pass
senbackup1 /AFTD/SQL        131072     N/A      N/A     Pass
senbackup1 /AFTD/default    131072     N/A      N/A     Pass
senbackup1 /AFTD/Windows    131072     N/A      N/A     Pass
senbackup1 Unknown          N/A        senlib3  N/A     Fail

**********************************************************************

14938:jbverify:
Exiting jbverify with failures.

root # jbverify -j -v -v
14866:jbverify:
Jbverify is running on host senbackup1, SunOS 5.10
14890:jbverify:
turning verbose mode on.
14900:jbverify:
No. of retries set by default to 10.
14902:jbverify:
Using senbackup1 as NetWorker server.
14918:jbverify:
Processing jukebox devices…
14920:jbverify:
Processing jukebox senlib3:
39078:jbverify: SYSTEM error: Device busy
39077:jbverify: error, Cannot initialize jukebox! Driver may not be loaded!
14926:jbverify:
Failed while processing jukebox senlib3 on senbackup1
14929:jbverify:
Finished processing jukebox devices.
**********************************************************************

Summary report of jbverify
======= ====== == ========

Hostname   Device Handle    Blocksize  Jukebox  Drv No. Status
——–   ————-    ———  ——-  ——- ——
senbackup1 Unknown          N/A        senlib3  N/A     Fail

**********************************************************************

14938:jbverify:
Exiting jbverify with failures.

Damit wird es nun offensichtlich, dass wohl ein Problem in der Tape-Library selbst besteht. Deshalb nun der Griff zur Library Console:

Oh je, das sieht verdächtig nach Hardware-Problem aus…

Ein Blick in die Networker Management Console lässt nichts Gutes ahnen:

Es laufen erfahrungsgemäß niemals so viele Savegroups gleichzeitig. Ein Blick in die Save Sessions zeigt, dass aktuell trotz Unmengen gestarteter Savegroups nichts passsiert, also nichts gesichert wird:

Die Alerts weisen dann die richtige Spur. Die Savegroups warten auf Bänder:

An fehlenden Bändern scheitert das aber nicht. Es stehen noch genügend Bänder in den zuvor genannten Pools zur Verfügung, die überschrieben werden dürfen (expired, recycable):

Unter Operations sieht man, dass zahlreiche Versuche Bänder in die Jukebox zu laden fehlgeschlagen sind:

In der Rubrik devices wird nun offensichtlich, dass die Laufwerke deaktiviert wurden (service mode):

Auf der Shell bekommt man mit “nsrwatch” diese Infos schnell und übersichtlich:

Fazit: Die Bandlaufwerke wurden deaktiviert, deshalb können Savegroups nicht ordnungsgemäß funktionieren. Das Laden der Bänder aus den entsprechenden Pools schlägt fehl.

Der erste Artikel “Sonnenaufgang” vergleicht Fedora 9, OpenSolaris 2008.05 und Ubuntu 8.04 und zeigt Erfahrungen bei der Installation auf unterschiedlicher Notebook- und PC-Hardware.

Fazit zu OpenSolaris:

Für eine erste Version ist OpenSolaris gut gelungen, wird wegen der diversen Ecken und Kanten jedoch eher erfahrene Anwender und Entwickler ansprechen. Um die OpenSolaris-Community auszubauen, sollte Sun Microsystems zunächst die Entwicklung eines Partitionierungsassisten für den Installer und eines grafischen Einrichtungsprogramms fürs Netzwerk forcieren. Mit einer breiteren Nutzerbasis wird auch eine bessere Hardware-Kompatibiliät einhergehen.

Der zweite Beitrag “Fremd und doch vertraut” gibt Tips und Tricks für die ersten Schritte auf OpenSolaris 2008.05. Zum Beispiel wird das Einbinden des Blastwave-Repositorys und erste Schritte mit ZFS und SMF erklärt.

Jeff Bonwick, Chief Technical Officer (CTO) of Storage Technologies bei Sun, hat in seinem jüngsten Blogbeitrag Photos mit Linus Torvalds und dem vielversprechenden Hinweis “stay tuned” veröffentlicht. Man sollte dazu auch wissen, daß Bonwick Leiter des ZFS-Entwicklungsteams ist.

Was man nun in dieses Treffen hineininterpretieren kann überlasse ich dem Leser. Nur so viel vorab: das Thema CDDL und GPL v2/3 dürfte eine Rolle gespielt haben.

Interessant dazu dürfte der Blogeintrag von Jim Grisanzio, Mitglied des OGB, und die Auflösung des Bilderrätsels im Blog von Leon Koll sein.

Na, alles klar?

Wer die turbulente Historie nicht verfolgt hat könnte jetzt leicht verwirrt sein. Deshalb hier ein kurzer Geschichtsunterricht:

Was bisher geschah…

Sun Microsystems kommt 2004 auf die Idee den Sourcecode für Solaris unter einer OpenSource-Lizenz zu veröffentlichen. Im Laufe von 1-2 Jahren entsteht eine Community mit Verwaltungsrat (OGB). OpenSolaris dient in erster Linie als Entwicklungsbasis für das kommerzielle Sun Solaris, was fehlt ist eine Binärdistribution. Diese reicht Sun später mit Solaris Express (Community und Developer Edition – SXCE/SXDE) nach. Für diese gibt es keinen Support und Patches, nur Upgrades des OS in kurzen Zeitabständen. Darüber hinaus gibt es auch noch weitere Binärdistributionen wie Nexenta, Belenix, Schillix und Martux, denen der OpenSolaris-Sourcecode zugrunde liegt. 2007 wechselt Ian Murdock zu Sun (Gründer von Debian Linux) und startet das Projekt Indiana, welches neue experimentelle Technologien aus der OpenSolaris-Community enthalten soll (z.B. ZFS Boot). Bei einem Wechsel des Namens der Distribution auf “OpenSolaris Developer Preview” kommt es zu Zoff zwischen dem OGB und Sun. Letztendlich setzte Sun als Inhaber der Markenrechte durch, daß daraus nun die Standard-Binärdistribution von OpenSolaris wurde.

Wodurch grenzt sich OpenSolaris 2008.05 von SXCE/SXDE ab?

• ZFS als Standard-Filesystem, auch für Boot-Devices
• Weiterentwicklung des Liveupgrade genannten OS-Upgrades mit Hilfe von ZFS-Snapshots
• Neue Softwarepaketverwaltung IPS, ähnlich APT unter Linux
• Download-Repositories
• Möglichkeit für kommerziellen Support
• standardmäßige Integration von GNU-Tools
• keine Installation per Jumpstart/Jet und CLI z.Z. möglich

Man stellt im Schreiben an Sun nüchtern fest, daß die Markenrechte an der trademark OpenSolaris bei Sun liegen und deshalb Sun rechtlich gesehen damit tun und lassen kann was für gut befunden wird. Trotzdem wird auf den Kollateralschaden in der Community hingewiesen, den die Auseinandersetzung um das Projekt Indiana aka. “OpenSolaris Developer Preview” gebracht hat. Zuletzt wird der Wunsch auf eine bessere zukünftige Zusammenarbeit zwischen Sun und dem OGB betont.

Stephen O’Grady fasste in seinem Blog hier und hier die zu klärenden Positionen zwischen Sun und den Vertretern der OpenSolaris Community, dem OpenSolaris Governance Board (OGB), zusammen. Die wichtigste Frage lautete hier eigentlich: “Was ist mit den anderen auf OpenSolaris-Sourcecode basierenden Distributionen wie Belenix, Nexenta, Martux oder Schillix? Dürfen diese nun auch OpenSolaris im Namen tragen?”

Sun hat sich gehörig Zeit für eine Antwort gelassen, diese aber nun doch formuliert. Zunächst einmal wird klargestellt, daß die Rechte am Namen OpenSolaris einzig und allein bei Sun liegen und sich daran auch nichts ändern wird. Für die Verwendung des Namens OpenSolaris wird ein Leitfaden erstellt, dessen aktuelle Fassung hier nachzulesen ist.

Zusammenfassend interpretiere ich das nun so:

• Die aus dem Project Indiana hervorgegangene OpenSolaris Binärdistribution wird die zukünftige Basis-Distribution und trägt den Namen OpenSolaris. Anderen, ebenfalls aus OpenSolaris-Sourcecode hervorgegangenen Binärdistributionen ist die Verwendung des Namens somit nicht bzw. nur bedingt gestattet.
• Es gibt die Möglichkeit für andere Distributionen oder Software den Namens OpenSolaris unter bestimmten Voraussetzungen zu verwenden, z.B. “based on OpenSolaris” wenn es sich um eine auf Indiana basierende Distribution handelt oder “built for OpenSolaris” wenn Software zum Paketformat von Indiana kompatibel ist.

Danke hiermit an Glynn Foster, der den aktuellen Stand der Entwicklung beim Project Indiana zusammengefasst hat. Er stellt fest, dass die Reibereien zwischen Sun und dem OGB nicht spurlos vorübergegangen sind, ist aber andererseits auch froh, daß die Verhältnisse nun klarer sind.

Über die Ergebnisse der Verhandlungen zwischen OGB und Sun ist wohl nicht zwingend jeder erfreut. Hoffen wir das Beste für die Zukunft der OpenSolaris Community…

Schönen Gruß noch an Constantin, der das Alles recht unkompliziert durchgeführt hat. Die Ausdehnung der Systemhelden auf andere Länder finde ich klasse und es spricht für euer gelungenes Konzept.

Zum Thema Ausbildung in der IT möchte ich noch auf die Fachinformatiker Community für Ausbilder und Azubis verweisen. Das Standardwerk IT-Handbuch für Fachinformatiker steht nun auch online und als Download zur Verfügung.

Wie sieht denn nun die postgres-Strategie aus?

Im Anschluß nahm Constantin von systemhelden.com mit mir einen Beitrag zum Heldenfunk-Podcast auf. Die Themen waren u.a. mein Nebenjob als Ausbilder für Fachinformatiker bei der Max Bögl Bauservice GmbH und mein Weg zum Bloggen.

Bei dieser Gelegenheit möchte ich darauf aufmerksam machen, daß bei uns im Hauptsitz bei Neumarkt i.d.OPf. eine Stelle als Oracle DBA offen ist.

P.S.

Constantin verriet mir, daß aktuell neue Dreharbeiten laufen. Man darf gespannt sein, was die Stars aus CSI Munich sich dieses Mal ausgedacht haben…

Im Anschluß werde ich Constantin Gonzales vom Heldenfunk / systemhelden.com einen Besuch abstatten. Es besteht allerdings die Gefahr, daß das Gespräch mit ihm recht monologartig werden könnte. Mir wurde aus sicherer Quelle berichtet, daß er zuvor einen Zahnarzt besucht.

P.S.

Mir schaudert schon beim Gedanken an den Zahnarzt. Letztes Mal kam ich mit halbseitiger Gesichtslähmung, Sabber im Mundwinkel und Sprachstörung wieder heraus. Zum Glück war der Zustand nur temporär.