Category: Job und Beruf

Ich habe hier das Buch “Shell-Programmierung” (ISBN: 978-3-8362-1157-4) von Jürgen Wolf im Original im Hardcover liegen; ein rund 800 Seiten starker Trümmer randvoll mit praktischen Tipps, Anwendungsbeispielen und nachvollziehbaren Erklärungen rund um die Programmierung in den verbreitetsten Linux-Shells. Das Buch ist super! Ich schaue regelmäßig rein und finde nach wie vor immer wieder etwas neues. Besonders als Referenz finde ich es einsame spitze!

Da sich nun leider nach mehreren Jahren der regelmäßigen Benutzung die Bindung mancher Seiten in den wohlverdienten Ruhestand verabschieden, wollte ich eben mal schauen ob man das nicht zufällig als digitale Kopie erstehen kann.
Tatsächlich: Kann man! Und zwar inzwischen kostenlos als Galileo OpenBook!

Ich kann nur jedem an diesem Thema interessiertem empfehlen: Downloaden!

Ich beschäftige mich derzeit wieder massiv mit Puppet. Heute wollte ich den in Ruby und den Puppetmaster eingebauten Webserver “WEBrick” durch den Apache ersetzen. Das klappte auch alles ganz toll, nur leider beschwerte sich das Passenger – Modul nach jedem Lauf des lokalen Puppet Agents darüber, das es das SSL Zertifikat unter /var/lib/puppet/ssl/private_keys/ nicht mehr zugreifen kann. Und in der Tat: Ich habe folgendes in dieser Reihenfolge gemacht:

  • den Apache beendet
  • chown puppet:puppet /var/lib/puppet/ssl/private_keys/servername.pem
  • chmod 640 /var/lib/puppet/ssl/private_keys/servername.pem
  • den Apache gestartet

Prüft man nun die Berechtigungen auf /var/lib/puppet/ssl/private_keys/servername.pem ist alles prima; auch die Puppet Agents können auf den Apache zugreifen und alles klappt!

Sobald man aber auf dem Puppetmaster – Server den Puppet Agent auch nur einmal startet , gehört das Zertifikat wieder root:puppet und hat den Modus 600! Lässt man den Puppet Agent mit --debug laufen, gibt dieser das auch ganz offen zu:

debug: /File[/var/lib/puppet/ssl/certs/servername.pem]: Autorequiring File[/var/lib/puppet/ssl/certs]
debug: /File[/var/lib/puppet/ssl/public_keys/servername.pem]: Autorequiring File[/var/lib/puppet/ssl/public_keys]
debug: /File[/var/lib/puppet/ssl/private_keys/servername.pem]: Autorequiring File[/var/lib/puppet/ssl/private_keys]
debug: /File[/var/lib/puppet/ssl/private_keys/servername.pem]/owner: owner changed 'puppet' to 'root'
debug: /File[/var/lib/puppet/ssl/private_keys/servername.pem]/mode: mode changed '0640' to '0600'
debug: /File[/var/lib/puppet/ssl/public_keys/servername.pem]: Autorequiring File[/var/lib/puppet/ssl/public_keys]
debug: /File[/var/lib/puppet/ssl/certs/servername.pem]: Autorequiring File[/var/lib/puppet/ssl/certs]
debug: /File[/var/lib/puppet/ssl/private_keys/servername.pem]: Autorequiring File[/var/lib/puppet/ssl/private_keys]

Zum Glück kann man dieses aber mit der weniger populären Konfigurationsoption “manage_internal_file_permissions” in der Datei /etc/puppet/puppet.conf verhindern:

[agent]
...
manage_internal_file_permissions = false
...

Eigentlich sehr naheliegend, aber ich habe irgendwie nicht die richtigen Buzzwords gehabt und die Recherche hat mich 1,5 Stunden gekostet … :P

Ich habe gestern, am 26.3.2012 um 22:33 Uhr einen Artikel geschrieben. Das ist “einer dieser 08/15 – Artikel”, die einfach so nebenbei mal kommen und nicht wirklich etwas tiefgründigeres ausdrücken oder gar bewirken sollen. Jedoch schreibe ich darin etwas, was ich aus jetziger Sicht (rund 22 Stunden später) einfach um 180 Grad falsch dargestellt habe; zumindest konnte bei meiner nicht immer neutralen Schreibweise dieser Eindruck entstehen. Daher möchte ich hiermit so zu sagen sowohl eine Wiedergutmachung leisten, wie auch mein Gewissen beruhigen. Denn, auch wenn ich hier manchmal recht direkte Worte für bestimmte Dinge finde, schreibe ich jedoch stets die Wahrheit und nur Dinge, hinter denen ich zu 100% stehe.

Warum ich dafür einen neuen Artikel schreibe und nicht den ersten Artikel einfach profan verändere? Page Rank, Aufmerksamkeit auf neue Themen (Leute lesen sich einen nur leicht veränderten Artikel einfach kein zweites Mal durch), Langeweile, … wie auch immer ;)

In diesem Artikel habe ich mich unter anderem darüber enttäuscht gezeigt, das im Rahmen der Netways Puppet Schulung ein Raucherzimmer für mich gebucht wurde und das mir das unangenehm ist. Beim erneuten Lesen des Artikels bin ich richtig froh, das ich dazu gebracht wurde mir das nochmal anzusehen, denn selbst ohne folgendes Ereignis kann das Hotel nichts dazu, was für mich gebucht wurde.

Jedenfalls bin ich heute, einen Tag später gegen 12 Uhr, von Frau Tamara Zschiesche, der “Sales Executive” des Hotels park inn in Nürnberg, angesprochen worden:

Sie: “Sie sind doch der Herr Richter, nicht?”
Ich: “Ähh – ja … ?”
Sie: “Mir ist zugetragen worden, das sie mit Ihrem Zimmer nicht zufrieden sind. Sie können direkt umziehen wenn Sie wollen.”
Ich (denkend, das jemand auf meiner Arbeit meinen Blog gelesen und sich beschwert hat): “Ähh – naja: Es ist halt ein Raucherzimmer. Aber beschwert habe ich mich nicht.”
Sie: “Nein nein – trotzdem: Wenn Sie wollen weise ich gleich den Zimmerservice an Ihre Sachen in ein Nichtraucherzimmer umzuräumen!”

Habe ich zwar lieber alleine gemacht, aber: … WOW! Ich habe wenig später auf meiner Arbeit angerufen um das zu klären – aber da konnte sich auch keiner einen Reim drauf machen.

Als ich “umgezogen” bin konnte ich mir die Frage an Frau Zschiesche einfach nicht verkneifen, was denn nun dahinter steckt. Darauf musste sie lachen und meinte nur: “… sie haben einen Blog. Wir haben gewisse Monitorings auf solche Stichworte und Bewertungen.”.

Also erstmal: … nochmal WOW! Nicht nur das das “park inn Nürnberg” nichts dafür kann, das ein Raucherzimmer für mich gebucht wurde und nicht nur das hier innerhalb von offenbar Stunden ein diesbezüglicher Blogeintrag, abseits der großen Plattformen wie Facebook, Holiday Check oder verschiedenen Blog-Hoster auf einem selbstgehostetem Blog gefunden und an die Leiterin des Hotels gemeldet wird: Auch die überdurchschnittlich faire und zuvorkommende Art und Weise wie diese damit umgeht (mit einer zeitnahen, problemlosen Umbelegung auf ein neues Nichtraucher-Zimmer nämlich) finde ich einfach nur krass! Sowohl technisch, wie auch von Seiten des Hotels. Also “park inn” – Hotels? Zu 110% empfehlenswert!
Und in diesem speziellen Fall: Gleichwertig ein besonderes Dankeschön und Entschuldigung an das Nürnberger “park inn” – Hotel auf der Sandstraße 2-8 !

Obwohl es, wie gesagt, nicht die Schuld des Hotels war, habe ich folgende Widmung im neuen Zimmer vorgefunden:

"park inn" Hotel Nürnberg - Zimmer 2 - Grussschreiben

"park inn" Hotel Nürnberg – Zimmer 2 – Grussschreiben

Ansonsten, hier noch zwei Bilder des neuen Zimmers. Es mag sein das das nur für mich so aussieht, da ich die frische Luft eines Nichtraucherzimmers zum Vergleich mit heranziehen kann, aber ich finde das die folgenden Bilder deutlich weniger Nikotin-Gelbstich haben als die im ersten Artikel ;) :

"park inn" Hotel Nürnberg - Zimmer 2 - Fensterseite

"park inn" Hotel Nürnberg – Zimmer 2 – Fensterseite

"park inn" Hotel Nürnberg - Zimmer 2 - Türseite

"park inn" Hotel Nürnberg – Zimmer 2 – Türseite

UPDATE: Bitte diesen Artikel nicht lesen ohne darauf den zweiten Teil zu lesen!

Wie ihr ja eventuell wisst, bin ich zwischen Montag und Donnerstag abend in Nürnberg, um an der Puppet Schulung von Netaways teilzunehmen.

Das war mein erster Flug im Leben überhaupt, mit Ausnahme des einen Mals, als ich als … 10 jähriger oder so “im Reisegepäck” meiner Mutter mit nach Griechenland geflogen bin. Der Check-In war easy und witzig: Ich habe doch glatt vergessen mein Penner-Gewürz (Tränengas) aus meiner Tasche zu nehmen und durfte das dann erstmal entsorgen gehen …  ;-) Selbst schuld und sonst alles voll locker. Ich hatte einen großzügigen Puffer, also lief das alles auch stressfrei.

Der Flieger selbst sah komisch aus: Ich habe einen Riesenflieger erwartet, wo es alleine ‘ne Stunde dauert, bis alle eingestiegen sind. Stattdessen sah das aber aus wie ein mit Sitzplätzen vollgestopfter Privatjet: es gab nicht so eine Schleuse, die an den Flieger rausgefahren wird und man ebenerdig zusteigt, sondern so eine typische Klapptreppe und man wurde bis vor den Flieger gefahren.
Hinter mir sass leider so ein Asi, der den Ruf von uns echten Metal-Fans leider im Rest der Bevölkerung runter reißt: Kopfhörer dauer-aufgedreht, so das er im Wartebereich des Gates vom Personal schon übel (aber angemessen) zur Sau gemacht wurde; was ihn aber keineswegs davon abgehalten hat dasselbe im Flieger wieder zu machen. Naja, was soll’s; der Flug selbst dauerte ja nur eine knappe Stunde, da kann man auch so einen kleinen Scheisser am leben lassen.

Was mich mal wieder total genervt hat war, wie sehr die Gesellschaft doch eigentlich Zombies ähnelt. Es wurden z.B. während des Fluges kleine Plastiktüten mit Saltletts – Gebäck ausgeteilt. Sofort: *knister, Knister, KNISTER …* alle packen den Scheiss aus und fangen an zu fressen; egal ob die Bock auf was zu knabbern haben, oder nicht. Es wird ausgeteilt, es ist umsonst, also: *Nom, nom* … Ich habe meine nicht angerührt: Hier der Beweis:

Meine ungeöffnete Bordnahrung

Meine ungeöffnete Bordnahrung

 

Naja, auch egal. Die Taxifahrt war cool. Die Taxifahrerin hat gemerkt das ich im vorbeifahren total fasziniert diesen … mittelalterlichen Wall mitten durch Nürnberg angesehen habe. Da hat sie mir direkt noch eine kleine Hintergrundgeschichte der Stadt und den Sehenswürdigkeiten auf dem Weg gegeben. So auch (ungefragt!) wo das Rotlichtmilleu losgeht. Das lief in etwa so: “Und da, hinter dem Wall, da sind die Puffs und … oh, wir sind da!”. Mit anderen Worten: Das Hotel ist genau an der Puffmeile.
Naja, egal. Ich hatte, gerade angekommen, noch Hunger. Also machte ich mich auf den Weg in die Stadt … tote Hose. Was eigentlich gut ist: Ich habe keinen einzigen Dönergrill oder Pizzeria gefunden! Bei uns sind die ja häufiger als Wohnhäuser … dennoch fand ich nur ein Sausalitos. Da habe ich mir direkt eine Portion Hähnchen Fajitas, zwei Weizenbier und als Absacker einen Whiskey-Cola reingezogen :)

Auf dem Rückweg wollte ich mir diese echt coole Mauer reinziehen. Man muss sich das so vorstellen, das Hauptstraße, Mauer und Puffmeile genau parallel verlaufen. Also bin ich einfach kurzerhand durch die Puffmeile gelaufen; wohl als einziger auf der Welt, nur um sich die Mauer reinzuziehen ;D Mannomann – ich war in total schäbigen Straßenklamotten unterwegs: Jeansjacke, Kurze Hose, T-Shirt. Und trotzdem haben die Bordsteinschwalben fast Ihre Fenster eingeschlagen, weil da mal ein nicht-Asi (ich) langkommt … arme Schweine :P

Naja, wie auch immer. Jetzt lege ich mich mal in’s Bett und ruhe mich aus, ehe morgen der Schulungsstress losgeht. Ich hoffe ich kann hier schlafen; die Blödmänner haben mir ein Raucherzimmer gebucht … :P Naja, sonst scheint alles OK zu sein hier.

 

Mein (Raucher-) Zimmer im "Park Inn Nürnberg"

Mein (Raucher-) Zimmer im "Park Inn Nürnberg"

 

Mein Bad im "Park Inn Nürnberg"

Mein Bad im "Park Inn Nürnberg"

UPDATE: Bitte diesen Artikel nicht lesen ohne darauf den zweiten Teil zu lesen!

Mit einer eher interessanten als gefährlichen Variante eines Einbruchs in Ihre Infrastruktur sah sich gestern, am 4. März 2012, der Code Hoster GitHub konfrontiert, als der russische Programmierer Egor Homakov diese Präsenz benutzte um auf eine Sicherheitslücke in Ruby on Rails (kurz: Rails), einem dem Ruby basierendem Framework für Webapplikationen, aufmerksam zu machen. GitHub ist ein sagenhaft populärer Hoster von Git-Repositorien, der neben dem reinen Hosting des Codes auch ein Wiki, Bugtracker, usw. bietet. Auch ich partizipiere darüber an Projekten wie z.B. “flora“. Zufällig verwendet GitHub selbst das Rails Framework; ebenso nutzen die Rails Entwickler GitHub als Code Hoster der Rails-Quellen. Ein ideales Ziel also für Homakov um, nach anfänglichen Schwierigkeiten sein Anliegen den Rails Entwicklern darzulegen, diese Lücke zu demonstrieren:

Er nutzte sie erfolgreich aus, verschaffte sich administrativen Zugang zum Rails-Projekt, bewies das er volle Admin-Rechte erlangt hatte und beispielsweise Fehlerberichte nach Belieben öffnen, schließen und sogar aus der Zukunft schreiben konnte. Außerdem fügte er dem Repositorium eine Datei hinzu. Auch das vollständige Löschen der gesamten Projekthistorie wäre möglich gewesen.

GitHub sperrte daraufhin den Account von Homakov, behob die Sicherheitslücke und gab eine Sicherheitswarnung heraus. Wenig später folgte eine zweite Ankündigung, in der man (wohl auch nicht zuletzt aufgrund anhaltender Proteste der Community) Homakov weitestgehend rehabilitierte und die Sperrung seines Accounts aufhob.
Einige  Leute, die nach wie vor keine wirklich schwerwiegenden Probleme zu haben scheinen und ansonsten offenbar wenig mit Ihrer Freizeit anzufangen wissen, diskutieren immernoch ob Homakov ein “Held” oder ein “Krimineller” ist … OMG!
Er selbst entschuldigt sich auf seinem Blog für sein Vorgehen:

Yes I behaved like a jerk.

GitHub selbst hat alleine dadurch, das sie dem Urheber eines wie auch immer beabsichtigten, jedoch dadurch juristisch nicht weniger strafbaren, Hackerangriffs bereits am nächsten Tag wieder uneingeschränkten Zugriff auf Ihre Systeme gewährten und dem ganzen scheinbar auch keine Strafanzeige folgen lassen, seinen guten Willen bewiesen.
Damit sollte doch alles gesagt sein, meine Güte! Beide sind sich einig und wieder Freunde :) . Das GitHub erstmal vorsorglich das Einfallstor schließt, bis alles geklärt ist, ist doch nur normal! Alles andere wäre strafbar fahrlässig.

Die Rails-Entwickler sind in meinen Augen die, die viel zu wenig tun. Sie wollen die Funktionen, die soetwas ermöglicht, auf Produktivsystemen künftig standardmäßig abschalten. Mit einem Fix ist “bereits” mit Rails 3 als Plugin zu rechnen … Sicherheit als zukünftige, optionale Alternative … na super. Leute, das ist armseelig und unterstreicht in meinen Augen das Rails ein Framework ist, von dem man tunlichst die Finger lassen sollte!
Man stelle sich folgendes Gespräch in einem Autohaus vor:

“Chef, Chef! Man kann in unserem neuen Auto Modell 2012 ohne den Originalschlüssel die Türen öffnen und losfahren! Ein Sicherheitsexperte vom ADAC hat das bereits im Fernsehen demonstriert! Was machen wir??” 

“Ruhig Blut … wir bieten mit dem 2013er Modell nächstes Jahr ein Bonuspaket an, mit dem man den Wagen dann wirklich abschließen kann … jetzt hauen sie ab und verkaufen erstmal die Hallen leer!”

Da hat jemand offenbar absolut keine Ahnung davon, was sie da anrichten und was sie auch nicht zuletzt dem Ruf von Ruby ansich antun. Ein Projekt solcher Größe sollte nicht von solch blauäugigen Diletanten geführt werden. Dann nimmt man halt viele bestehende Projekte erstmal vm Netz – na und ?? Das Fundament muss doch trotzdem frei von solchen Kloppern sein; wem das nicht passt soll halt auf ein Update verzichten! Und wenn es in der Tat zwei Lager gibt, dann muss man halt forken! Aber sowas,  was die jetzt auf die Roadmap gesetzt haben, ist die denkbar schlechteste “Lösung”.

Jedes Mal, wenn ich mir ein neues Linux-System einrichte, muss ich erst nochmal schnell Googlen oder die Manpage wälzen; daher notiere ich es mir hier jetzt endlich mal:

Es gibt ein Sicherheitsfeature bei openSSH, welches einen warnt wenn man sich zu einem Host/einer IP verbinden möchte und sich die ID des Zieles seit dem letzten Mal verändert hat. Das macht zwar durchaus Sinn und ich finde das generell eine gute Sache. Aber es kann wirklich sehr nerven, besonders wenn man mit DHCP arbeitet und die Zielrechner dauernd Ihre IP durchtauschen, man mit virtuellen Maschinen arbeitet und diese nur kurz benutzt werden oder häufig per SSH auf Live-CD-Systeme konnektiert.

Normalerweise muss man die entsprechende Zeile in der Datei ~/.ssh/known_hosts die angemeckerte Zeile löschen; z.B. bei:

$ ssh user@192.168.1.12
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
39:b3:72:04:53:f7:17:eb:aa:8c:ed:70:db:77:8b:e9.
Please contact your system administrator.
Add correct host key in /home/user/.ssh/known_hosts to get rid of this message.
Offending key in /home/user/.ssh/known_hosts:3
RSA host key for 192.168.1.12 has changed and you have requested strict checking.
Host key verification failed.$

müsste man die Zeile 3 entfernen.

Hierzu muss man etwas wie “sed -i 3d ~/.ssh/known_hosts” losjagen oder die Datei in einem Editor von Hand bereinigen. Wie schon gesagt: Auf Dauer sehr nervig!

Wenn einem das nur vereinzelt passiert, kann man sich mit Kommandozeilenoptionen helfen: “ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no user@192.168.1.12“; ist jedoch schon eine recht sportliche Aufgabe sich das a) zu merken und b) jedes Mal wegzutippen.

Wem das permanent passiert, kann dieses Verhalten dauerhaft einstellen. Und zwar sowohl global wie auch userbasiert. In beiden Fällen müssen die beiden o.g. Optionen in die passende Config-Datei eingetragen werden:

UserKnownHostsFile=/dev/null
StrictHostKeyChecking=no

Um diese Einstellung global zu setzen (nicht empfohlen), trägt man diese Optionen in die Datei “/etc/ssh/ssh_config” ein.

Um diese Einstellung nur für einen bestimmten User zu setzen, trägt man diese Optionen in die Datei “~/.ssh/config” ein.

Das ganze hebelt natürlich den als Sicherheitsmaßnahme gegen “Man-in-the-middle” – Attacken gemeinten Schutz vor diesem Angriffstyp aus. Um das ganze wenigstens etwas sicherer zu machen, kann man auch nur einzelne Hosts und Hostbereiche derart von dieser Regel ausnehmen. Die Beispielhafte Syntax dazu lautet dann:

Host 192.168.1.*
   StrictHostKeyChecking no
   UserKnownHostsFile=/dev/null

bzw.:

Host 192.168.1.12
   StrictHostKeyChecking no
   UserKnownHostsFile=/dev/null

Aber Achtung: Bitte nur anwenden wenn Ihr wisst was Ihr tut! Das ganze hebelt, wie gesagt, einen sinnvollen Schutz des SSH Systems aus.

 

Jaaa – was soll ich groß schreiben? Was lange währt wird endlich gut vielleicht :)

LPIC-1 Logo

LPIC-1 Logo

Nachdem mein Kumpel Alex vor inzwischen fast zwei Jahren mit dem LPIC-1 Zertifikat vorgelegt hat, wollte ich eigentlich innerhalb weniger Wochen nachziehen. Nur kam dann eines zum anderen. Erst zog die Firma um, dann hatte ich alle Hände voll zu tun mit meiner damals neuen Position als Abteilungsleiter mit Personalverantwortung, dann … ach – blah, blah, blah. Das Ende vom Lied ist: Ich bin erst am gestrigen Mittwoch endlich dazu gekommen meine LPIC-1 Prüfung bei “The Campus” in Düsseldorf in der Gladbecker Str 1  zu absolvieren. Ich habe direkt beide Prüfungen hintereinander durchgezogen.

Was soll ich lange drum herum reden: Bestanden! :)

Ich habe hierzu mit dreien abzurechnen. Fangen wir mit “The Campus” an.
Ich habe mich am 9.11.2011 zu beiden Prüfungen am 23.11.2011 um 10.30 und 12:00 Uhr angemeldet. Am 22.11. um 17:45 Uhr (also: Am Abend zuvor) sitze ich mit meinem Chef im Meetingraum in der Firma, da kommt eine Kollegin rein und meint “Es hat eine Frau X von The Campus angerufen und meinte die Prüfung morgen verschiebt sich auf 12 Uhr.”. Wir waren eh gerade fertig also rufe ich um 18:00 Uhr, 15 Minuten später, zurück um die Dame zu fragen ob sie das richtig findet einem am Abend zuvor durch einen dritten ausrichten zu lassen das sich die Prüfung verschiebt. Was ist denn wenn ich dann bereits Termine habe? Zudem habe ich meine Handynummer und E-Mailadresse bei der Registrierung angegeben, da kann man mich doch wenigstens versuchen darüber zu erreichen ehe man “Stille Post” spielt.
Aber scheinbar hat sie unmittelbar nach diesem Anruf das Gebäude verlassen – jedenfalls war sie nicht mehr im Hause (Aussage der Kollegin, die ich stattdessen erreicht habe).
Angekommen musste ich erstmal suchen, ob ich richtig bin: Die untere Etage des scheinbaren Neubaus steht leer. Schilder gibt es nur sehr unzureichend.
Ich bin also um 12 Uhr da. Leider habe ich eine Wartezeit bis etwa 12:30 Uhr, da sich die Dame trotz der Verschiebung auf 12 Uhr um knapp eine halbe Stunde verspätet.
Als wir endlich anfangen können, werde ich in einen Raum geführt, in dem 8 völlig veraltete PCs stehen. Die Dame schaltet mir die Prüfung auf und – verlässt den Raum! Alle Prüflinge sind völlig unbeaufsichtigt. Spicken wäre nun Tür und Tor geöffnet. Ebenso wird man auf den ausgehändigten Regeln darauf hingewiesen, das man sich ausschließlich durch heben einer Hand bemerkbar machen soll, wenn man Fragen hat. Der Prüfer kommt dann angeblich sofort und hilft. …. wie denn, wenn garkeiner im Raum ist??
Naja. Nachdem ich die erste Prüfung bestanden hatte, habe ich eine kurze Pause gemacht und bin dann die zweite angegangen. Während dieser Prüfung wurde in den oberen Etagen pausenlos gehämmert. Wirklich konzentrieren: Fehlanzeige. Ich bin nach absolvierter Prüfung zu den Damen gegangen und habe gesagt das sowas alles andere als geeignete Prüfungsbedingungen sind. Reaktion: “Ja, ich war auch eben schonmal gucken …”. Super!

Also: Nichts gegen die Damen an sich: Die beiden waren sehr nett! Aber es ärgert mich, das man viel Geld dafür bezahlt, das man sich da eine Stunde lang an einen PC setzen darf, dabei weder Beaufsichtigt noch betreut wird und das man einen Tag vor der Prüfung derart mit Orga-Scheiss abgelenkt wird. Zumal die auf der Anmeldung ihrerseits ein richtiges Fass aufmachen: “Wer mehr als 15 Minuten später erscheint darf nicht mehr teilnehmen!”, “Armbanduhr, Portemonaie und Handy müssen abgelegt werden!”, “Während der Prüfung: Absolute Ruhe!” , und dann bietet man einem solche Bedingungen an.

Naja …
Morgen rechne ich mit dem Linux Professional Institute ab! Stay tuned! :D

… ich kann es zwar selbst nicht wirklich glauben, aber ich werde nun tatsächlich einen Artikel über Windows und das kopieren / übertragen von dessen Profilen schreiben! Ich hoffe der Internet Explorer klettert in meinen Zugriffsstatistiken trotzdem nicht auf Platz 1 ;D

Dieser Artikel entstand, weil ich auf der Arbeit gerade einen neuen PDC implementiere und hierfür selber eine Lösung gesucht habe, wie ich die bestehenden Profile (lokal und Domänen-Roaming-Profile) dabei möglichst nahtlos in die neue Domäne übernehmen kann. Besonders tricky hierbei war, das die aktuelle Domäne nicht wirklich fehlerfrei funktioniert und nun ein Wildwuchs aus lokalen Profilen (da nicht jede Anmeldung an der Domäne funktionierte) und Domänenprofilen besteht und wir nun von Roaming Profiles auf lokale Profile wechseln.
… mal ehrlich: Hat _irgendjemand_ schonmal Roaming Profiles benutzt ohne entweder dazu überzugehen den PC nicht mehr abzuschalten oder(/und?) Dateien nur noch ausserhalb der eigentlich zum speichern vorgesehenen Ordner abzulegen? Wenn ja: Ich hoffe er kriegt seine Medizin ;D

Ich habe nun für alle drei aktuellen Windowsversionen (XP, Vista und 7 – Wer noch <=2000 im Unternehmensumfeld einsetzt bekommt hoffentlich psychologische Hilfe und vorallem Prügel ;D … “Das ist das stabilste Betriebssystem überhaupt – seit 5 Jahren habe ich keine Sicherheitsupdates mehr einspielen müssen!” … ihr armen, armen irren Kacknoob-Möchtegern-Admins … ) einen mehr oder weniger einheitlichen Weg gefunden dieses zu realisieren! Vieles basiert auf dieser (englischsprachigen) Anleitung, jedoch bevorzuge ich für meine Zwecke eher eine hybride Variante aus dieser und einer zweiten Methode.
Keine Sorge, das hier wird eine Schritt-für-Schritt – Anleitung und keiner muss sich diese beiden Englischen Artikel durchlesen. Ich erwähne diese hier nur, damit ich mich nicht mit fremden Federn schmücke.

Am Ende dieses Artikels findet Ihr eine chronologische Screenshotreihe, welche diese Anleitung verdeutlichen soll.

Ich gehe im folgenden davon aus, das ein Profil aus einer alten Domäne (MFC2) für einen identischen Account (mr) in einer neuen Domäne (MFC3) bereitgestellt werden soll. Die Screenshots stammen, sofern nicht anders erwähnt, von einem Windows XP. Die Dialoge und die Vorgehensweise ist in den unterschiedlichen Windowsversionen jedoch nahezu identisch. Daher beschreibe ich auch zunächst einmal das grundsätzliche Vorgehen und erwähne hinterher, welcher Punkt unter Vista/7 einer kleine Abweichung bedarf.
Damit man diesem Guide gut folgen kann, sollte man sich die alte und die neue SID des zu migrierenden Accounts notieren, ehe man anfängt. Passiert das ganze von einem Samba-Server auf einen Samba-Server, ist es einfach: Einfach auf beiden DC folgenden Befehl ausführen:

pdbedit -Lv mr | egrep ‘^User SID’

Diese Zeichenketten notiert man sich nun und nicht vergessen zu vermerken, welche die alte und welche die neue ist.

Ich gehe davon aus, das der User, dessen Profil migriert werden soll, sich bereits früher am System angemeldet hat und das gecachedte Profil sich somit bereits auf der lokalen Festplatte befindet. Sollte dem nicht so sein, weil der PC z.B. gleich mit erneuert werden soll, oder weil man diesen Guide erstmal “durchspielen” will, sollte man dieses also zunächst tun, damit das Profil auf das System kopiert wird.

Die folgenden Schritte führt man am besten als ein Domänenadmin aus – Mit dem lokalen Admin geht es nicht, da dann die Domänen-SID-Username Mappings nicht zur Verfügung stehen.

NACHTRAG 02.11.2011: Es ist hierbei sehr wichtig, das der folgende Schritt nicht mit dem User gemacht wird, dessen Profil kopiert werden soll! Benutzt hierfür einen anderen; der User, dessen Profil kopiert werden soll, darf währenddessen nicht eingelogged sein.

Zunächst muss das bisherige Profil des Users kopiert werden.
Unter Windows XP navigiert man dazu nach : Systemsteuerung -> System -> Tab: Erweitert -> Benutzerprofile: Einstellungen.
Unter Windows Vista und 7 navigiert man dazu nach : Systemsteuerung -> Benutzerkonten -> Erweiterte Benutzerprofileinstellungen konfigurieren.

Es öffnet sich jeweils ein Fenster namens “Benutzerprofile” mit einer Liste der bestehenden Userprofile. Man wählt hier nun das zu kopierende Profil aus; im Beispiel: MFC2\mr.
… nun würde man gerne auf “Kopieren nach” klicken, richtig? Aber ratet mal: Dieser Weg war Microsoft zu einfach. Also hat man es einfach kurzerhand deaktiviert und verweist stattdessen auf den KB 973289. Damit nicht genug die Funktion zu deaktivieren: Diese Sadisten grauen den nur aus statt zu entfernen, um allen unter die Nase zu reiben “So leicht könnt’s sein …“. Aber glücklicherweise kommt uns genau diese Tatsache nun zu gute:

Ich weise an dieser Stelle darauf hin, das mir zwar keine Meldung bekannt ist, das das folgende Verfahren irgendwo einmal zu einem Problem geführt hat. Jedoch handelt es sich nicht um das offizielle Microsoft – Vorgehen und jeder handelt dabei auf eigene Gefahr.
Zunächst läd man das kleine Tool “Windows Enabler” herunter. Es handelt sich dabei um ein kleines Programm, welches nicht installiert werden muss. Dieses tut man schließlich auch. Achtung: Unter Windows 7/Vista bitte unbedingt “Ausführen als Administrator” auswählen. In der Systemleiste neben der Uhr erscheint daraufhin ein kleines, blaues Icon. Klickt man 1x darauf, erscheint “On” darin. Klickt man nun auf die ausgegraute “Kopieren nach” Schaltfläche, wird sie verfügbar -> Verarscht! ;)

Wir klicken nun auf die neu verfügbare “Kopieren nach” – Schaltfläche. In dem sich daraufhin öffnendem Dialog wählen wir als Ziel “Dokumente und Einstellungen\<username>.<neue_domäne>” (im Beispiel: “Dokumente und Einstellungen\mr.MFC3″; unter Vista/7: “Users”- o. “Benutzer”\<username>.<neue_domäne>). Dieser Ordner kann nicht im sich hier öffnendem Dialog angelegt werden, daher dieses bitte zuvor selbst im Explorer tun. Bei großen Profilen kann es sein, das das Fenster eine zeitlang den Eindruck macht es sei abgestürzt; einen Fortschrittsbalken gibt es nicht. Aber das ist glaube ich eine Sache, mit der man in einer eigentlich deaktivierten Funktion ganz gut leben kann ;)

Ist dieses abgeschlossen, bringt man den PC in die neue Domäne und startet neu. Anschließend meldet man sich am besten als Domänenadmin an – Mit dem lokalen Admin geht es nicht, da dann die Domänen-SID-Username Mappings nicht zur Verfügung stehen.
Man klickt den neuen Profilordner nun mit rechts an und wählt “Eigenschaften“; im sich öffnendem Fester wechselt man zum Tab “Sicherheit“. Man sieht hier nun mindestens eine SID mit einem weißen Symbol. Diese User entfernt man zunächst, indem man ihn durch einen Klick auswählt und anschließend auf “Entfernen” klickt. Das sind die Useraccounts der alten Domäne, die der neue Domänencontroller natürlich nicht auflösen kann.
Der nächste Schritt besteht nun darin, das man dem neuen User rekursiv Vollzugriff auf diesen Profilordner gewährt. Hierzu klickt man auf “Hinzufügen” und gibt im Feld “Geben Die die zu verwendenden Objektnamen ein” den Usernamen ein (Im Beispiel: mr). Hierbei ist darauf zu achten, das im Feld “Suchpfad” der Name der neuen Domäne angezeigt wird. Nach einem Klick auf “OK” taucht der User in der Rechteliste auf, sofern er in der neuen Domäne gefunden wird.
Man wählt diesen Eintrag nun an und setzt danach im Feld “Berechtigungen für USERNAME” alle Haken auf “Zulassen“. Anschließend klickt man auf “Erweitert” und setzt den Haken bei “Berechtigungen für alle untergeordneten Objekte durch die angezeigten Einträge, sofern anwendbar, ersetzen.“. Nun bestätigt man alle Dialoge mit “OK“. Es kann anschließend zu einer Fehlermeldung kommen, das nicht alles richtig gesetzt werden konnte. Das kann man jedoch in der Regel ignorieren.

Als letzten Schritt muss man eine kleine Anpassung in der Registry vornehmen. Die Datei “NTUSER.dat” im neuen Profil hat nun zwar bereits die passenden Berechtigungen für den neuen User, jedoch hat diese Datei in sich auch nocheinmal eine Berechtigungsstruktur, die wir nun setzen.
Hierzu öffnet man zunächst den Registrierungs-Editor (“regedit” eingeben unter Start->Ausführen) und wählt den Schlüssel “HKEY_LOCAL_MACHINE” durch anklicken aus. Anschließend klickt man auf “Datei” und wählt “Struktur laden …” aus. Man navigiert nun in den neuen Profilordner. Hierin befindet sich eine Datei namens “NTUSER.dat”. Es kann sein, das sie garnicht oder ohne “.dat” angezeigt wird. Das kommt darauf an, ob man in Windows die Anzeige von bekannten Dateiendungen und Systemdateien aktiviert hat, oder nicht. Wie auch immer: Diese Datei muss nun ausgewählt werden. Anschließend wird man aufgefordert, sich einen temporären Namen für diese Struktur auszudenken. Das Originaltutorial empfiehlt hier “chickenfucker” – tatsächlich sind der Phantasie hier jedoch keine Grenzen gesetzt und hat keinerlei Auswirkungen, da es nur temporär benutzt wird ;)
Die geladene Struktur wird nun mit dem soeben vergebenem Namen unter  “HKEY_LOCAL_MACHINE” eingebunden. Man öffnet nun mit einem Rechtsklick auf diesen Namen das Kontextmenü und wählt “Berechtigungen…“. Es öffnet sich nun derselbe Dialog wie wir ihn schon vom setzen der Berechtigungen auf den neuen Profilordner her kennen. Man setzt nun einfach dieselben Rechte erneut und entfernt die Alt-Domain SIDs. Auch hier kann man den Hinweis, das einige Teile nicht gesetzt werden konnten, ignorieren.
Achtung! Der folgende Schritt ist sehr wichtig: Ist das ganze durchgelaufen, klickt man erneut auf “Datei” und wählt “Struktur entfernen …“.

Das war’s! Meldet sich nun der User an, für den wir auf diesem Wege das Profil vorbereitet haben, sollte er genau dieselben Einstellungen vorfinden, wie er sie auch in der alten Domäne hatte; inklusive Hintergrundbild und sogar Anordnung der Desktop-Symbole ;)
Sollte das nicht der Fall sein, könnte es daran liegen, das Windows einen anderen Ordner für das Profil gewählt hat als wir es gedacht haben. In freier Wildbahn ist mir so z.B. schon “user.domäne.000″ begegnet.
In diesem Fall meldet man sich als Admin an (dieses Mal kann es ruhig der lokale Admin sein); es muss aber unbedingt ein anderer User sein als der, dessen Profil man umbiegt! Diesen meldet man vor dem folgendem Schritt ab.
Man startet nun erneut den Registrierungs-Editor (“regedit” eingeben unter Start->Ausführen) und navigiert zur Struktur “HKEY_LOCAL_Machine\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList“. Darin befinden sich eine Menge Unterschlüssel, beginnend mit “S-1-5-21-“. Diese Namen stehen für SIDs, daher brauchen wir nun die Liste der SIDs vom neuen Domänencontroller, die man zu Beginn dieses Artikels auslesen sollte. Sucht nach dem Schlüssel, der 1:1 identisch mit der SID des Users auf dem Domänencontroller ist und klickt darauf. Darin befindet sich unter anderem ein REG_EXPAND_SZ mit dem Pfad zum zu verwendendem Domänenprofilcache als Wert. Dieser Wert kann einfach auf den richtigen Profilordner geändert werden.
Nach einem Neustart sollte schließlich das richtige Profil geladen werden.