F11 ist da und die Installation fies.

Ja ich war im Urlaub, während sich Fedora 11 alias Leonidas auf dem Weg zu den Spiegel Servern gemacht hat.

Kaum war ich wieder in DSL Reichweite, wurde auch schon der torrent gestartet und mein Netbook auf einer Ersatz-Partition damit beglückt.

Na so einfach wie es jetzt scheinen Mag war es aber leider gar nicht. Ich bin nun mal einfach gestrickt. wenn mir was angeboten wird, greife ich zu. #fail aber so richtig.

Die Partitionierung in so ziemlich jedem Installer lässt es zu andere Partion mit einem Mountpoint und somit zum automatischen Mounten vorzusehen. Das mache ich gern wenn ich 2 oder mehr verschiedene Betriebssysteme auf einem Rechner habe, damit ein System das andere reparieren kann. Der Datenaustausch ist auch viel leichter. Grundsätzlich ist da ja nichts gegen zu sagen.

Da hat man wohl aber SELinux auf der Rechnung vergessen.

Also so ein SELinux-Kontext Rollout über “/” ist da nämlich so richtig dämlich.  Ja ich war schon immer der Meinung, dass ein /.autorelabel nicht der Weisheit letzter Schluss ist. Ergo was passiert, wenn wie im Fall F11 die Kontexte total anders sind als bei dem anderen Sytem (in meinem Fall F10)? Genau ich zerschieße mir meinen Kontext auf der anderen root Partition.

Wann genau aber ein autorelabel läuft, weiß nicht jeder, oder? Die Fälle die mir bekannt sind:

• beim booten wenn eine /.autorelabel Datei existiert. Wird auch automatisch angelegt, wenn man beim boot ein selinux=disable angibt. d.h. nächster boot dann ein relabel
• beim “firstboot”
• sobald das selinux-policy-*.rpm upgedatet wird im postscript

Mehr automatische/impliziete kenne ich nicht, nur eben die manuellen Verfahren wie fixfiles oder restorecon

Nur so als Warnung an alle User:

Niemals bei (SELinux enableden) Linux eine andere rootplatte mouten bzw. automatisch mounten lassen, außer mal kurz temporär. ist zwar bääääh, macht euch das Leben aber sichtlich einfacher.

Warum? Mein F10 wollte nach dieser Aktion nicht mehr mit mir reden und im grafischen Boot wurde einfach das Bild dunkel. Im detailierten View sah man, dass da viel “fehlgeschlagen” war.

Es gibt das Böse aus dem Erdgeschoß noch.

Fast 2 Monate nichts geblogt, ja ich schähme mich. Gerüchte über mein Ableben sind im Vergleich zu #MJ übertrieben.

4b von 11 der Fluch der shared rawLUN

Auf geschoben ist nicht aufgehoben, dass trifft leider auch auf die ungeliebten Arbeiten zu. Ja ich habe mir die Cluster aufgehoben. Schließlich sind das meine Prunkstücke, etwas edles, die Diven unserer Sammlung virtueller Server. Derartig wollen diese auch behandelt werden. Aber ach, da hat uns VMWare noch ein schönes Osterei beschert. Aber der Reihe nach, erstmal das angewendete Konzept:

• alle VM Gastsysteme stoppen (ganzer Cluster)
• alle VM im alten VC deregistrieren
• alle VM im neuen VC registrieren
• die rawLUN mapping aller VMs löschen
• alle VMs neu konfigurieren (VM Hardwareversion von 3 auf 4, Netzumbau)
• alle VMs starten
• VMWare-Tools updaten
• alle VMs stoppen

4a von 11 jenseits von GsdF

morgen ist also “Wartungsfenster” … die Vorboten stehen mitten im Zimmer und der Stressfaktor geht hoch.

Seit gestern haben wir nun die VMs in den Fingern die RawLUN mappings haben. Daraus ergibt sich eine Erweiterung des normalen Konzeptes:

• VM Gastsystem stoppen
• VM im alten VC deregistrieren
• VM im neuen VC registrieren
• die rawLUN mapping löschen
• VM neu konfigurieren (VM Hardwareversion von 3 auf 4, Netzumbau)
• VM starten
• VMWare-Tools updaten
• VM stoppen
• Migration mit Verschiebung des Plattenplatzes bei nicht laufender VM (vmdk-Dateien also die Systemplatten der VM)
• Anbinden der rawLUN vom alten Speicher
• VM starten
• Downtime 1 normalerweise  30-60 Minuten abhängig von Umgebung und Größe der Systemplatten
• Anbinden der rawLUN vom neuen Speicher während die VM läuft.
• Spiegelmöglichkeiten der Gastbetriebssysteme nutzend von alt auf neu die Daten kopieren
• VM stoppen
• die rawLUN mapping zum alten Speicher löschen
• VM starten
• Downtime 2 normalerweise weniger als 3 Minuten

wie zu erwarten war etwas umständlicher und diese VMs bedurften also etwas mehr Handarbeiten…<to be continued>

3 von 11 storageVMotion

Ein neues Feature in ESX 3.5.4 und dazu gedacht um eine VM im laufenden Betrieb zwischen 2 Plattenspeichern hin und her zu schieben. Für unsere Migration eigentlich genau was wir brauchen.

Der Tag war gesäumt von Vorbereitungen für die erste abendliche Session. Wir arbeiten bei produktiven VMs ohne rawLUN nach einem einfachen Konzept:

• VM Gastsystem stoppen
• VM im alten VC deregistrieren
• VM im neuen VC registrieren
• VM neu konfigurieren (VM Hardwareversion von 3 auf 4, Netzumbau)
• VM starten
• VMWare-Tools updaten
• VM (WIN) oder Netzwerk (Linux) neustarten
• (Anm.: downtime normalerweise max. 10-15 Minuten)
• storageVMotion am Abend bei laufender VM

Aber wir haben eben immer noch nach dem VMware 2.5 Schema jede Platte >50GB als rawLUN angelegt. Außerdem haben wir noch einige andere VM’s die einen Cluster beherbergen, also eine rawLUN als shared Storage benutzen. Diese haben bislang einen zweiten SCSI-Adapter im shared Modus und je eine rawLUN Mapping auf die gleiche Platte/LUN. Dazu mehr später …<to by continued>

2 von 11 oder auf du und du mit dem IPStor CLI

Die Nachfrage nach LUNs des IPStor (SAN Virtualisierer auf RHEL 5.1 Basis) stieg an diesem Tag von 6 (Startposition) auf nunmehr ~70 (Stand alte Umgebung) an.

Die GUI des IPStore ist schön zum spielen und für einen Operator, aber ein wahrer Admin noch dazu in eine Bash, nutzt nur ein CLI. *harharhar*

Wobei ich anmerken muss, dass der CLI des IPStor keine Abfrage nach der VID (also die Zahl mit der der IPStor intern die LUNs zählt, die er anlegt) als einzelnen Subbefehl bereit stellt. Er vergibt diese natürlich beim Anlegen und im Antworttext steht die auch irgendwo, aber später kommt man nicht wirklich einfach an diese ran, benötigt diese allerdings um viele der CLI Aktionen zu machen. Darunter auch die LUN einem Server zuweisen.

Ergebnis war nach mehreren Stunden einige Bashscripte (Anm.: so bald ich die Freigabe habe veröffentliche ich die) zum Löschen, Anlegen, Zuweisen und Wegnehmen von LUNs aus dem IPStor oder respektive dessen Clients.

Was ich sagen muss, so komplex das Thema auch sein mag, ich bin froh dass ich mich durchgesetzt habe und kein DataCore genommen habe. Auf einer RHEL Konsole ist der RHCE eben doch beheimatet.

Großes Lob an die Entwickler der Firma FalconStor, nice work.

Die Kollegen haben während dessen, das VC gepimpt (Zusatztools von VMWare und M$ eingespielt) und die ersten produktiven Systeme migriert. Schon nahm das Unheil seinen Lauf, wir verlohren urplötzlich die Verbindung zu VMs bzw. zu einzelnen ConsoleOS der ESX Server. Schuld waren die 10 GBit NICs onboard (Broadcom 57711E) die mit den angeschlossenen Ciscos(3020) oder mit dem VMWare Treiber nicht arbeiten wollten….<to be continued>

1a von 11 Nebenkriegsschauplätze

Ja so ist es mit diesem Murphy. Er kommt immer dann um die Ecke, wenn die Kacke gerade am dampfen ist.

Dies war initial dieser Woche eine Mail mit “wir brauchen dringend bis nächste Woche 2 $neueVMs”

Okay ich führe bei Bedarf eine ToDo Liste. Allein deren existens spricht für mehr Arbeit als Zeit. Dies hier war der allerdings erste Fall von “won’t fix” meiner Adminlaufbahn.  Ergo wurde einer der bereits abgezogenen Kollegen temporär Zurückzititiert und mußte denn Job machen, denn wir wegen der laufenden Migration nicht mehr unterbringen konnten. Letztlich zog diese Schlacht aber wie ein Kugelblitz hin und her durch das Haus sogar bis in die Chefetage.

1 von 11

Ja, es war eine lange und harte “Woche”.

Ich konnte zwar twittern, aber zum bloggen blieb leider keine Zeit.

Darum möchte ich so einiges nun noch nach bloggen.

Warum kam es eigentlich dazu, dass ist schlecht zum anonymisieren, aber last es mich so umschreiben: Wir sind zu viert oder besser waren es . Nun hab ich da ja meine Affaire die zwei von uns eigentlich so ziemlich voll auslasten würde. Der Rest vom Team hat uns bislang den Rücken freigehalten in dem sie den täglichen Adminkram erledigt haben. Nun aber hat man beiden einen neuen Job angeboten und wir die sowieso schon zu viel zu tun haben/hatten, arbeiten nun statt 150% nun eher 300%. Ja, wir haben ein wenig Geld mehr, aber im Verhältnis zur dreifachen  Arbeit bei weitem nicht angemessen.

Also nach dem wir nun also um 50% gesund geschrumpft wurden, war es eigentlich genau die richtige Zeit um endlich mal die neue Hardware mit Produktions-VMs zu befüllen. Sprich wir ziehen um, neue Hardware (Blades, VM ESX 3.5.4), eine SAN – Virtualisierung erstmals bei uns im Einsatz und somit auch neu, und um es auch wirklich spannend zu machen, haben wir auch einen neuen Plattenturm.

Jedem Admin dreht sich da der Magen um, so ging es uns auch, einige andere Begebenheiten brachten uns in die Not, dieses Unterfangen nun doch in Angriff zu nehmen.

Als Netz für den Notfall und weitere helfende Hand haben wir uns einen VMWare Profi geholt. (Anm. ohne ihm wäre alles noch so viel schlimmer gekommen)

Am ersten Tag war noch der Frust der Versetzungen und der Ärger mit dem Deployment (Altiris auf W2k3 Basis) im Vordergrund des Geschehens, sowie seitens der SAN Virtuallisierung erste LUNs zu präsentieren. Mehr als den Aufbau des VC-Servers und der ersten Testmigrationen war dann nicht mehr machbar. … <to be continued>

0 von 11

Es war das Osterwochenende, ich hatte meinen verlängerten Adminarm (Latop mit UMTS) mit zu hause, wo er die kommenden Tage auch verweilen sollte.

Warum ich mir das Wochenende so frei willig versaut habe, dass ist leicht erzählt:

Ich brauchte am Dienstag 8 ESX Server fertig installiert und betriebsbereit. Da mein Kollege auch nicht zum Deployen kam und die Software auch nicht wirklich einfach zu durchschauen ist, habe ich mich eben geopfert. Ja ein weiters mal und wieder völlig umsonst.

Jedenfalls ein Kickstart file war schnell gefunden aber sehr schwer an unsere Umstände und das Deployment selbst anzupassen. Nach 45 Stunden intensivsten try-and-error hatte ich letztlich doch kein generisches ks.cfg für Alle, sondern für jeden ESX eine individuale Kopie angelegt und 2 Stunden später auch alle ESX betankt und überprüft.

Dabei vielen mir schon erste NICs auf, deren Link down war, bei Blades geht es nicht wirklich, ein Netzwerkkabel zu ziehen. Aber das konnte ich ohne Netzadmin und von zuhause nicht klären.

Naja von Ostern hatte ich also nur den Montag und sonst nix. Ich fuhr also nicht gerade froh über die neue Umgebung am Dienstag noch im Dunkeln gen Büro… <to be continued>

Fedora Sticker

Es geschehen doch noch Wunder. Nach dem ein eeePC Case Mod (Skin) zum Fedora 10 Theme bei Amazon gelistet wurde suche ich eine Fedora Sticker für mein NC10. Oben genannten Skin gibt es außer für den eee1000 nun auch für den eee901, den Dell mini 9, den Acer Aspire und den HP Mini 2133, aber nicht für den Samsung NC10. Ach das geht noch weiter, da wäre die PSP, die Wii, die GamePads xBox360 bzw. PS3 , der iPod, den Gameboy DS …. usw. und jetzt habe ich keine Lust mehr.

Okay, trotz dem zu erwarteten “Heul doch!!” es gibt auch einen Lichtblick, einen kleinen. Linux-onlineshop.de ein Partner meiner Lieblingsseite für Admin-Geek-Nerd-Pausenunterhaltung Holarse, hat nun auch einen Fedora-Logo-Sticker in Gehäuse-Logo-Größe (2,5×2,5cm). Der war mehr als überfällig. Ich weiß nicht warum, aber Fedora Fanartikel gibt es online kaum.