Gregor Longariva, 12:28 Uhr in Solaris, Systemadministration
Oracle hat ja (leider) ganz schön viel umgestellt, eingestellt und verschlimmbessert was die Informationen rund um Solaris betrifft. Als altgedienter Solaris Administrator wurde es zunehmend schwerer Informationen zu finden.
Eine meiner liebsten Anlaufstellen war sunsolve.sun.com – von hier kam man auf alle möglichen Informationen rund um Solaris und Sun Hardware. Diese gibt es in dieser Form nicht mehr. Und das Flash Gelump welches jetzt die Oracle Support Seite darstellt kann man wirklich keinem antun.
Mittlerweile gibt es aber von der doch immer noch regen Solaris Community Seite eine Anlaufstelle. Auf We Sun Solve versucht man so viele Informationen wie möglich zusammenzutragen und erste Anlaufstelle für den Solaris Sysadmin zu sein.
Eigentlich schade, wenn Oracle das nicht selbst auf die Reihe bekommt. Aber offensichtlich ist das bei Oracle ja Programm.
Kommentare (1)
Gregor Longariva, 17:36 Uhr in Solaris, Systemadministration
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:
(überprüfen ob der richtige Publisher gesetzt ist und ggf. auf http://pkg.opensolaris.org/release/ setzen)
(neueste Updates holen)
(Updates auch von anderen Publishern ermöglichen, letzteres nur, wenn man extra auch konfiguriert hat)
(neuen Publisher (=Oracle) setzen)
(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)
…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.
Kommentare (2)
Gregor Longariva, 22:30 Uhr in Allgemeines
Da gibt’s wohl einen dummen Fehler in Solaris’ Live Upgrade Feature. Nach langem Probieren und Suchen und schließlich Googlen habe ich die Lösung gefunden.
Offensichtlich mag luupgrade nicht wenn in Paket-Info Dateien (pkginfo) von installierten Paketen ein leeres SUNW_LOC= drin steht.
In meinem Fall waren zwei Pakete betroffen:
stan 22:17 [/]# grep SUNW_LOC= /var/sadm/pkg/*/pkginfo | egrep ‘=$’
/var/sadm/pkg/SUNWse6130ui/pkginfo:SUNW_LOC=
/var/sadm/pkg/SUNWsesscs/pkginfo:SUNW_LOC=
Einfach mit dem Editor der Wahl die entsprechenden Zeilen löschen und schon klappt auch das luupgrade.
Übrigens: offensichtlich gab’s in früheren Versionen auch Probleme wenn der Name des luu Images länger als sieben Zeichen war. Ob dieses Problem gefixt wurde kann ich leider nicht sagen. Aber vielleicht ist es einen Versuch Wert, das Image mit lurename umzubenennen wenn ein luupgrade nicht klappt
Kommentare deaktiviert
Gregor Longariva, 14:52 Uhr in Solaris
Wenn im cron-log die Meldung “bad user” auftaucht, es den Account aber gibt (getent passwd) dann kann es auch daran liegen, dass der cron Daemon den Eintrag *LK* in /etc/shadow nicht mag. Diesen Eintrag in – z.B. – NP umwandeln und dann könnte es klappen.
Solaris und andere Unixes behandeln zu kurze Passwort-Einträge in /etc/passwd oder /etc/shadow als ungültig. Deshalb ist es im Prinzip egal was da drin steht (außer der Eintrag ist ganz leer, dann HAT der Benutzer kein Passwort – und der Admin ein Problem).
Es gibt eine Konvention die u.A. besagt, dass gelockte/gesperrte Benutzer einen Eintrag *LK* bekommen. NP würde “No Password” bedeuten, was aber für das System trotzdem nichts anderes bedeutet als “lass ihn nicht rein”.
Die Idee dahinter ist eigentlich einleuchtend: ein Benutzer der gesperrt (*LK*) ist, soll nichts mehr machen dürfen. Auch keine Jobs über den Cron Daemon laufen lassen. Darauf sollte man achten wenn man Wildcard Einträge für LDAP oder NIS macht. Für das Password-Feld also besser kein “*LK*” verwenden…
Kommentare deaktiviert