"Einbruch" bei GitHub.com

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".

Teilen per: TwitterEmail


Windows XP, Vista und 7 Profile kopieren

... 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.

[gallery link="file"]

Teilen per: TwitterEmail


Erster Eindruck zu Windows 8

Seit gestern können Interessierte die kommende Windowsversion "Windows 8" völlig legal im Rahmen einer "Developer Preview" als ISO Image überraschend schnell von den Microsoft Servern herunterladen und testen. Eine Registrierung ist hierbei nicht erforderlich.

Ich habe mir gestern mal den Spass gemacht und musste nach erfolgter Installation erstmal einen Blick auf den Wandkalender werfen. Nein, es ist in der Tat September und nicht April. Ich konnte, was ich da sehe, nicht glauben! Wer sich den Download des bis zu 4.8 GB großen ISO Images sparen möchte, der kann einfach in den nächsten Saturn oder Media Markt gehen und sich ein x-beliebiges Windows Phone ansehen. Man bekommt den Eindruck, das Microsoft zukünftig nur noch ein Betriebssystem für Computer, Tablets, Handys, usw. entwickeln will, da sie das komplette Startmenü in dieser ... ich weiss garnicht wie man das nennen soll: "Swype - Oberfläche" gehalten haben. Klickt man auf "Start" (der Button sieht übrigens so aus als hat ein Kind den gemalt), öffnet sich zunächst mal ein Menü, welches zig kleine Icons auf dem Bildschirm anzeigt - völlig unsortiert und bei vielem ohne Text. Man muss anhand des Bildes raten, was passiert, wenn man darauf klickt.

Das ist sowas von völlig schrecklich geworden ... ich habe das komplette Teil nach 10 Minuten wieder gelöscht!

Naja, OK. Wenn das jetzt Microsoft's neuer Releasezyklus wird, im Wechsel ein unbenutzbares und ein gutes OS herauszubringen (wie ja seit XP begonnen: XP = gut, Vista = Schrott, 7 = gut, 8 = Schrott, ...), wieso nicht? Müssen die selber wissen ob sie sich so einen Mist bei zunehmender Konkurenz durch Apple und Linux leisten können.

Ebenfalls erschreckend: Während der Installation bietet Windows einem an das Live - Konto als Login zu verwenden!!!! HALLO??? Sicherheit und so??? Die haben doch wohl den Schuss nicht gehört: Man soll nun allen ernstes seinen PC mit weiss-der-geier wie privaten und vertraulichen Daten über's Internet mit denselben Daten anmelden, wie man sie ggf. seit Jahren mit seinem MSN Messenger verwendet anmelden? Ich komme auf anhieb auf locker 20 Möglichkeiten wie ich als Security Laie diese Daten bereits heute ausspähen kann. Der Weg zu "Ja - aber ... ich will mich mit meinen Facebook - Daten anmelden können!" ist da echt nicht mehr weit. Und das bietet man dann auch noch dem IT-Technisch hinrtotem Volk an, welches trotz jahrelangen Berichten darüber, wie unsicher Online-Banking ist und wie leicht sich Handydaten ausspähen lassen, beide Unsicherheitsfaktoren durch Smartphone-Internetbanking kombinieren?
Au Backe ... man sollte echt mal drüber nachdenken umzusatteln und unter die Onlinekriminellen gehen - das mausert sich ja immer mehr zum Selbstbedienungsladen ...

Positiv fiel hingegen der neue Windows Explorer auf. Das Menü ist nun ähnlich wie bei Office 2011 viel umfangreicher und weniger zusammengefaltet, so das man sich für viele (sinnvolle) Funktionen den Umweg über "Datei > Neu > Ordner > ..." oder das Kontextmenü sparen kann.

Mehr kann ich zu diesem Betriebssystem ehrlich gesagt garnicht sagen, da ich es, wie gesagt, umgehend wieder gelöscht habe. Es mag sein, das man diesen Schrott-Modus auch irgendwie abstellen kann, aber ich bin ehrlich gesagt nicht bereit dazu mich mit einer Vorabversion von Windows zu beschäftigen; zumal die Systemsteuerung auch so beschissen angeordnet ist, das man um eine Einarbeitung garnicht herum kommt.
Macht Euch einfach den Spaß, ladet das herunter und stellt die Kotztüten bereit.

Teilen per: TwitterEmail


VirtualBox mit WLAN im Host nutzen

Seit Monaten kotze ich jetzt einen armdicken Strahl, wenn ich zuhause mit meinen VirtualBox Virtual Machines etwas entwickeln oder evaluieren möchte, weil ich jedes Mal ein Kabel quer durch mein Wohnzimmer legen muss, da die Netzwerkbrückenverbindung (Bridged Networking) über verschiedenste WLAN USB Sticks nicht funktionierte.
Vielleicht kurz zur Erläuterung: Das "Bridged Networking" ist eine der zur Verfügung stehenden Netzwerkemulationstechniken in VirtualBox, welche es einem, anders als "Host-Only" oder "NAT", erlaubt die virtuellen Maschinen so an das Netzwerk anzuschließen, das diese direkt mit den sich darin befindenden Komponenten kommunizieren können, ohne irgendwie vom Host geProxyt oder geNATed werden zu müssen. So können sich die VMs beispielsweise per DHCP von den realen Verteilern im Netz eine IP holen, von diesen ohne Port Forwarding angesprochen werden (z.B. per HTTP oder SSH), usw.

Die Lösung war, nach mehreren Monaten der Unkenntnis und erfolglosen Google- und IRC Recherche, ganz simpel, jedoch so seltsam, das ich die Lösung gerne hier kundtun möchte in der Hoffnung, das es anderen diesen Ärger ersparen möge:

Standardmäßig nutzt eine VM als virtuellen Netzwerkadapter einen "Intel PRO / 1000 MT Desktop (82540EM)" Adapter. Der funktioniert mit kabelgebundenem LAN auch hervorragend, versagt jedoch scheinbar wenn der Host per WLAN ins Netzwerk integriert ist.
Stellt man diesen auf "Intel PRO / 1000 MT Server (82545EM)" um funktioniert auf einmal alles reibungslos! Man benötigt im Gastbetriebssystem (zumindest unter Linux) nicht einmal einen neuen Treiber!

Verstehen tue ich es nicht wirklich, aber Hauptsache ist doch, das es nun funktioniert :)

Auf dem folgenden Bild seht Ihr, wie man diesen Adaptertyp umstellt:

[caption id="attachment_904" align="aligncenter" width="300" caption="1. = "Erweitert" muss zunächst aufgeklappt werden, damit der Dialog erscheint. --- 2. = Hier muss der Adaptertyp "Intel PRO / 1000 MT Server" ausgewählt werden."]![VirtualBox 4 - Auswahl des virtuellen Adaptertypes für WLAN-Hosts --- 1. = "Erweitert" muss zunächst aufgeklappt werden, damit der Dialog erscheint. --- 2. = Hier muss der Adaptertyp "Intel PRO / 1000 MT Server" ausgewählt werden.]({filename}images/virtual_box_virtueller_adaptertyp-300x214.png "VirtualBox 4 - Auswahl des virtuellen Adaptertypes für WLAN-Hosts --- 1. = "Erweitert" muss zunächst aufgeklappt werden, damit der Dialog erscheint. --- 2. = Hier muss der Adaptertyp "Intel PRO / 1000 MT Server" ausgewählt werden."){.size-medium .wp-image-904 width="300" height="214"}[/caption]

Teilen per: TwitterEmail


CeBit 2010

Ich war auf der CeBit! Das ganze wurde inklusive Fahrt und Verpflegung von meiner Firma bezahlt. Um es kurz zu machen: Wenn die irgendwann einmal irgendwo ... sagen wir: In Duisburg oder Bochum, also: in der Nähe, stattfinden sollte und ich gerade rein GARNICHTS anderes vorhaben sollte, würde ich in Erwägung ziehen diese Messe noch einmal zu besuchen. Aber Hannover? No Way - Die Messe ist Mega langweilig. Neben zig No-Name China-Ständen stehen da nur noch langweilige 0815 - Stände. Keinerlei Innovationen, ja: Nichtmal echter Herstellerkontakt ist dort möglich.

Ich interessiere mich zum Beispiel für vertikal montierbare PDUs für unsere Server-Racks. Klingt komisch, ist aber so! :D Die Leute von APC, die da vor Ort waren konnten mir die simpelsten Fragen nicht beantworten. Aber OK: Sie haben mir angeboten diese Fragen gezielt weiterzuleiten (an der Hotline waren sie ebenfalls überfragt) und sich bei mir zu melden. Ähnliches habe ich auch mit anderen Herstellern gemacht - das wird hier keinesfalls ein APC - Exklusives negativ-Ranking. Und ein paar Tage nach Messeende bekommt man nur eine Standard-Spammail "Sie haben uns auf der CeBit besucht - schön! Besuchen Sie doch mal unsere Homepage. ...." :P

Ich brauch da nie wieder hin. Weder privat noch geschäftlich. Außer Spesen nichts gewesen ...

Teilen per: TwitterEmail


Zugriff auf Samba Freigaben mit Windows Vista

Hallo zusammen!

Wir hatten hier in meiner Firma das Problem, das man sich an Windows XP Workstations anmelden konnte und problemlos auf eine von einem Linux Samba Server bereitgestellte Ressource zugreifen konnte, jedoch als derselbe User, der an einer Windows Vista Workstation angemeldet ist, auf dieselbe Ressource keinen Zugriff bekam.

Ich habe zunächst vermutet, das ich einen Fehler in meiner PDC Konfiguration hatte oder ähnliches, da der Domänencontroller und die Bindung der Samba Dateiserver an diesen erst recht neu implementiert wurde. Jedoch liegt es an einem neuen "Feature" von Windows Vista das diese Zugriffe überhaupt nicht klappen können.

Nach kurzer Suche bin ich auf dieses Blog gestossen, in dem genau dieses Problem beschrieben wurde.

Ich denke ohne diesen Beitrag wäre ich da nie drauf gekommen.

Da ich immer Angst habe, das Beiträge die ich verlinke in naher Zukunft wieder verschwinden, kopiere ich den Inhalt des erwähnten Beitrages in mein eigenes Blog. Ich hoffe Jörn hat nichts dagegen. Ansonsten bitte einfach einen Kommentar schreiben :)

Vista und Samba Shares

Ich habe mir Vista zum Testen installiert. Da ich ein WL700gE habe nutze ich auch die eingebaute Platte als Netzlaufwerke. In den ersten Wochen ging noch alles gut mit den Netzlaufwerken unter Vista.
Nachdem ich aber eines Tages auf meine Laufwerke zugreifen wollte bekam ich die Abfrage nach einem anderen “richtigen” Passwort, da der alte Nutzer nicht authentifiziert werden konnte. Ich habe nicht lange nachgedacht und schnell mein Username und Passwort eingetippt, und.. nichts. Es funktioniert nicht.

Nach etwas Suchen habe ich dann eine Lösung gefunden.

Vista nutzt eine neuen Version des SMB Protokolls. Soll sicherer sein, einziges Problem war nur, dass Samba dieses nicht unterstützt. Und da mein WL700g auf einem Linux läuft und Samba für die Shares nutzt kann es nicht funktionieren.

Um das Problem zu beheben muss man die Lokalen Sicherheitsrichtlinien bearbeiten. Erstmal den Richtlinieneditor über

Start -> Eingabeleiste -> secpol.msc

starten und dann folgenden Pfad hinunter hangeln.

Lokale Richtlinien -> Sicherheitsoptionen

Dort findet ihr dann auf der rechten Seite einen Punkt der
Netzwerksicherheit: LAN-Manager-Authentifizierungsebene
heißt. Dort ein Doppelklick und die Option

LM-und NTLM-Antworten senden (NTLMv2-Sitzungssicherheit verwenden)

auswählen. Dann nur noch auf Ok klicken und den Editor wieder schließen.
Nun sollte es wieder möglich sein Samba Shares zu öffnen und zu verbinden. Falls nicht sollte noch ein Neustart gemacht werden. Bei mir hat es zwar ohne funktioniert, aber bei Windows kann man ja nie wissen. ;)

Ob das jetzt ein Versuch von Microsoft sein soll Linux als Fileserver Betriebssystem auszustechen ist fraglich, da es zu einfach zu umgehen ist. ;)
Grüße Jörn

Kleine Ergänzung noch von mir selbst:

Bei  Vista Home Basic und Vista Home Premium soll es anders sein. Da sind stattdessen folgende Schritte notwendig:

  • In der Registry den Schlüssel "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Contr ol\Lsa" suchen
  • Den Wert für LmCompatibilityLevel von "3" auf "1" ändern

Dieses kann ich nur leider nicht nachstellen, da wir diese Versionen in der Firma nicht haben.

Teilen per: TwitterEmail



Zeichensatz von Dateinamen unter Linux umwandeln

Ich musste heute wieder einmal mit mkisofs ein ISO File eines Verzeichnisses unter Linux erstellen. Dabei stand ich mal wieder vor dem Problem, das es Dateien aus einem ehemaligen Samba - Share eines Samba Servers waren, dessen Zeichensatz nicht explizit gesetzt war, wodurch der Windows Zeichensatz cp850 verwendet wird. Dieses sieht unter linux nicht nur "ganz toll" aus, nein: Programme wie mkisofs können daher auch solche Dateien nicht wirklich gut verarbeiten.

Ich hatte wie der Autor des Blogeintrages, durch welchen ich letztendlich mal wieder fündig wurde, das Problem das ich das Programm convmv kannte, damit auch schonmal gearbeitet hatte, ich mir den Namen jedoch nicht wirklich gut einprägen konnte.

Unter openSuSe 10.3 heisst das RPM auch einfach convmv.

Um nun Dateien eines Samba - Shares gescheit umzubenennen, gibt man convmv folgende Parameter mit:

convmv -f cp850 -t utf-8 --notest -r ordner

Mit -f wird der aktuelle Zeichensatz angegeben.

-t definiert den Ziel-Zeichensatz.

-r führt das ganze Programm rekursiv auf das ganze Verzeichniss aus und

--notest sorgt dafür, das die Dateien effektiv umbenannt werden.

Achtung:

Wer sich über das Ergebniss nicht ganz sicher ist, der sollte die Option --notest zunächst mal weglassen. Dann Zeigt das Programm nur an was es tun würde.

Teilen per: TwitterEmail


Mit Postfix Mails an bestimmte Adressen an ein Script übergeben

Heute war es auf der Arbeit nötig einem Postfix MTA folgendes Konfigurationsszenario beizubringen:

Es sollte ein Verteiler eingerichtet werden, dessen Mails an ein PHP Script auf einem anderen Server übergibt.
Zum Glück sollte es nicht eine bestimmte Mailadresse auf demselben Server sein - das wäre deutlich umfangreicher geworden ..

Der Zielserver hat eine UMTS Karte und kann daher direkt SMS verschicken. Wird nun eine Mail an die Adresse fantasie@traumland.de geschrieben, soll diese Mail an den Server smsgateway weitergeleitet werden und dort von einem PHP Script an gammu weitergegeben werden.

Es ließ sich auf dem Primary MX sehr leicht konfigurieren. Dazu muss in die Datei /etc/postfix/virtual folgendes eingetragen werden:

smsuser@traumland.de smsuser@smsgateway.traumland.de

Auf dem Server smsgateway musste in die Datei /etc/aliases folgendes eingetragen werden:

smsuser: "|/pfad/zum/phpscript.php"

Damit war diese Aufgabe erledigt.
Die Datei /etc/postfix/virtual unterstützt dieses Format user: "|script" wohl nicht so ohne weiteres. Hätte das Script auf dem Primary MX direkt laufen sollen, wäre das Anlegen des aliases Eintrages fatal: Jede Mail an smsuser@ , ganz gleich an welche Domain, würde eine SMS auslösen und ggf. sehr teuer werden.

Teilen per: TwitterEmail