sale e pepe

Die Würze des Admin-Daseins

Inhalt

Update von OpenSolaris auf Solaris Express 11

Heute ist endlich mit Solaris Express 11 der Nachfolger von OpenSolaris erschienen. Das Upgrade von OpenSolaris 2009.06 auf Express 2010.11 sollte sich problemlos machen lassen.

Folgende Schritte sind notwendig:

  • # pkg publisher

(überprüfen ob der richtige Publisher gesetzt ist und ggf. auf http://pkg.opensolaris.org/release/ setzen)

  • # pkg image-update

(neueste Updates holen)

  • # pkg set-publisher --non-sticky opensolaris.org
  • # pkg set-publisher --non-sticky extra

(Updates auch von anderen Publishern ermöglichen, letzteres nur, wenn man extra auch konfiguriert hat)

  • # pkg set-publisher -P -g http://pkg.oracle.com/solaris/release/ solaris

(neuen Publisher (=Oracle) setzen)

  • # pkg image-update 2>&1 | less
  • # pkg image-update --accept

(Lizenz akzeptieren und Update machen – u.U. muss man vorher noch ein getrenntes Update für pkg selbst machen, was zu tun ist wird angezeigt)

  • # reboot

…und damit sollte der Server auf Oracle Solaris Express 11 2010.11 upgedated sein. Easy, huh?

Bleibt noch zu schauen, was an Nacharbeit zu machen ist. Das wird sich in den nächsten Tagen zeigen. Ich hoffe aber sehr, dass einige der dringendsten Problem gelöst sind.

 

Flattr this

ruby gems: eventmachine und thin auf Opensolaris installieren

Ein kleiner Tip: manche ruby gems lassen sich unter Solaris nicht installieren, da sie das GNU-make brauchen. Dieses kann man mit

pfexec pkg install SUNWgmake

nachinstallieren. Allerdings nennt sich dieses dann gmake und nicht make. Man könnte nun kurzzeitig /bin/make nach gmake umbiegen.

Was gmake implizit macht, ist die CXX Variable (die das Makefile einiger gems braucht) auf den korrekten Pfad zu setzen – also bei OpenSolaris auf /usr/sfw/bin/g++

Man kann dies aber auch „von Hand machen“. So kann man die beiden Edelsteine eventmachine und thin mit folgendem Befehl (bourne shell vorausgesetzt) installieren:

CXX=/usr/sfw/bin/g++ gem install eventmachine

CXX=/usr/sfw/bin/g++ gem install tin

Home Fileserver

Wie im letzten Blogpost angedeutet, möchte ich diesmal über meinen Home Fileserver schreiben. Ursprünglich wollte ich keinen dedizierten Server aufsetzen und meine Daten auf dem Mac Mini speichern. Die beiden externen USB Platten mit dem OS X Software Mirror hatten sich als nicht sehr zuverlässig herausgestellt. Ob das nun am USB, an der Mirror Software oder am Plattencontroller lag kann ich nicht sagen. Deshalb die Entscheidung für meine Daten und Filme ein zuverlässiges System aufzusetzen. Und was liegt für einen Solaris Admin näher als das Ganze mit OpenSolaris und ZFS zu machen. Bei der Hardware habe ich mich an Constantin Gonzalez‘ Blogpost A Small and Energy-Efficient OpenSolaris Home Server orientiert. Die Idee anstatt eines Intel Atoms einen energiesparenden AMD Athlon II X2 240e zu verwenden der ECC Speicher unterstützt ist bestechend. Wenn die Daten auf Platte Checksummen-überprüft werden – wieso nicht auch im Speicher, wo es durchaus auch mal vorkommen kann, dass ein Bit im Speicher kippt? Letztendlich habe ich den Server mit fast den gleichen Komponenten wie Constantin zusammengestellt:

– Prozessor: AMD Athlon II X2 240e – Motherboard: ASUS M3A78-CM SocketAM2+ mATX (6 SATA Anschlüsse) – Speicher: 2 x KINGSTON 2GB DDR2 PC2-6400 800MHZ CL6

Als Gehäuse habe ich ein altes PC-Gehäuse mit neuem Netzteil verwendet. Mein Server steht im Dachboden, da habe ich keine Platz- oder Lärm Probleme. Die beiden am Mac Mini ausprobierten 1TB USB Platten sind zum Glück „normale“ SATA Platten und tun mittlerweile ihren Dienst als ZFS Datenmirror. Zwei weitere 1,5TB Platten werden den Mirror erweitern, sobald die bestellung eingetroffen ist. Als root Platte dient eine nicht mehr verwendete Notebook Platte mit 110GB. Demnächst wird eine weitere 2,5″ Platte frei womit dann der ZFS Spiegel angelegt wird. Zugegeben – hier ist der aktuelle Zustand mit einer ungespiegelte Root Partition nicht das, was man von einem vorsichtigen Sysadmin erwartet. Aber wie gesagt – Abhilfe ist in Sicht. Zum Glück hatte ich noch einen alten Röhrenmonitor mit dem ich die Grundinstallation von OpenSolaris 2009.06 machen konnte. Aktuell läuft der Server ohne Bildschirm und ich bin guter Dinge, dass ich in nächster Zeit keine Konsole brauchen werde. In einer Mac Umgebung ist AppleTalk als Fileserver Protokoll praktisch. Für Unix Systeme gibt es das freie Netatalk, welches AFP für die Macs zur Verfügung stellt. Die Aktuelle Version 2.0.5 compiliert unter OpenSolaris 2009.08 problemlos – man brauch sich nur den gcc und die BerkeleyDB über das Contrib-Repository (http://pkg.opensolaris.org/contrib/) zu installieren. Eine generelle Anleitung wie man Netatalk auf OpenSolaris zum Laufen bekommt habe ich hier gefunden. Auch ich habe nur eine Handvoll Benutzer und so reicht es, die Benutzergenehmigungen von Hand einzutragen und über die passwd zu verwalten. Der Hauptgrund wieso ich Netatalk installiert habe ist, dass seit Version 2.0.5 TimeMachine Backups unterstützt werden. Es ist einfach beruhigend zu wissen, dass man ein Backup seines Notebooks hat und dieses auf einem zuverlässigen Dateisystem wie ZFS liegt 😉 OpenSolaris verwendet als Bonjour Service „dns-sd“ (Multicast DNS (mDNS) & DNS Service Discovery (DNS-SD) Test Tool). Eine Anleitung wie man dieses konfiguriert findet man hier. Damit findet der Mac Mini sein AFP Share für TimeMachine und macht – wenn er nicht grad „schläft“ – brav seine regelmäßigen Backups auf den Server. Als Alternative zu dns-sd gibt es auch avahi für OpenSolaris – ich habe mich aber für die von Haus aus installierte Variante entschieden. Aktuell kämpfe ich noch etwas mit IPv6: Gateway zum IPv6 Provider (in meinem Fall SixXS) dient mein OpenWrt Router. Über AICCU (Automatic IPv6 Connectivity Client Utility) den SixXS verwendet wird der Tunnel aufgebaut, der radvd (Router Advertisement Daemon) sorgt dann dafür, dass das entsprechende Advertising ins lokale Netz für das IPv6 AutoConfig gemacht wird. Theoretisch sollte das auch funktionieren. Mit den Macs klappt das auch wunderbar, OpenSolaris ist da etwas heikler. Ich habe das Problem noch nicht bis zum Schluss analysiert – Fakt ist aber, dass OpenSolaris nur dann eine IPv6 Autokonfiguration macht wenn der radvd in seiner config auf „UnicastOnly“ gesetzt wird. Solaris/OpenSolaris verwendet zur IPv6 Konfiguration den ndp (Neighbor Discovery Protocol) Daemon. Dieser kann sowohl Client als auch advertiser (bei einen Router) sein. Offensichtlich verstehen sich der radvd und der ndp nicht so gut. Vielleicht liegt das Problem aber auch ganz wo anders: der ndp bekommt erst dann eine config wenn OpenSolaris vorher die (lokale) IPv6 Adresse des Routers angepingt hat. Wie gesagt – ich bin noch am analysieren. Für mich ist IPv6 deshalb spannend, weil ich ein eigenes Subnetz habe und mich so vom Arbeitsplatz direkt mit die einzelnen Hosts zuhause verbinden kann. Mal schnell eben etwas umkonfigurieren, nachschauen, hinkopieren, … ohne NAT-Problematik ist genial. An weiteren Diensten ist der OpenSolaris mein lokaler NTP, DNS und DHCP Server. Weiteres wird u.U. noch folgen, wobei ich die Dienste des OpenWRT Routers vollständig übernehmen werde (FTP Server für die WebCams, IPv6 Gateway (wenn ich AICCU unter OpenSolaris zum compilieren bringen würde), dyndns cronjob und NFS Server für die (jetzt im Schlafzimmer stehende) dbox. Alles in allem kann ich sagen, dass ich – bis auf die ipv6 Problematik – mit meinem Setup zufrieden bin. Was Andere mit ihrem Linux-Home Server machen tut bei mir OpenSolaris mit dem Vorteil von ZFS für meine Daten, Fotos, Filme und Dokumente. Ein Enterprise-Grade NAS Server für Zuhause. Zumindest was File Services betrifft.

An dieser Stelle herzlichen Dank an Constantin für die Vorarbeit in Sachen Analyse für passende Hardware.

NFS Security mit OpenSolaris Client und Linux Server

Bei uns am RRZE ist das Problem aufgetaucht, dass ein Benutzer auf einem OpenSolaris NFS Client nicht auf sein Home auf einem Linux NFS Server zugreifen konnte. Nur Dateien die für jedermann (nobody) zugreifbar waren, konnten gelesen werden. Der Mount dieses speziellen Home Verzeichnisses wurde über den Automounter gemacht und funktioniert auf Solaris 10 einwandfrei.

Ein Mounten von Hand mit nfsv2 hat ebenfalls das gewünschte Resultat gebracht und mit Expliziter Angabe des security modes (-o sec=sys) hat es dann auch geklappt. Nur: woran liegt das und wie kann der Mount über den Automounter gemacht werden ohne diese Option in der automounter map mit anzugeben (was potenziell an anderer Stelle Probleme hätte bereiten können)?

Ein paar Nachforschungen haben ergeben, dass das Problem in der Linux NFS Server Implementierung liegt. „Buggy“ wäre das falsche Wort, ich würde sagen – missinterpretiert. Kurz gesagt sagt die NFS v3 Spezifikation, dass beim Initiieren der Kommunikation der Server dem Client ein Array mit den von ihm unterstützten Security modes schickt. Der Client sucht sich nun die erste aus, die er selbst unterstützt. Linux sendet aber als ersten Modus den Modus „NONE“, was soviel bedeutet, dass kein Mapping von Benutzern gemacht wird. Ein NFS Client/Benutzer kann nur das lesen, was für „other“ lesbar ist. Somit versucht OpenSolaris auch den ersten Modus den es kennt zu verwenden. Also klappt das mit dem UID/GID Mapping auf /etc/passwd bzw. /etc/group nicht. Dieses wäre nämlich sec=sys (also Security Mode AUTH_SYSTEM). Abhilfe schafft, dem OpenSolaris einfach den Security Mode „NONE“ abzugewöhnen (der sowieso so gut wie nie eingesetzt wird). Dazu in der Datei /etc/nfssec.conf die eine Zeile mit AUTH_NONE auskommentieren und den NFS Client Dienst neu starten. Und schon klappt’s auch mit den Linux NFS Servern.

Wieso OpenSolaris sich plötzlich strikter an die NFSv3 Spezifikationen hält als Solaris 10 ist ein anderes Thema. Fakt ist, dass die Linux Jungs da mal wieder was auf ihre Art und Weise implementiert haben. Denn neben Linux hat ja sowieso keiner eine Daseinsberechtigung. Manchmal erinnert mich das an Micro$oft…