hardwarefetish.com

Outlook Express von totem System migrieren

Es ist ja hinlänglich bekannt, wie man Outlook Express-Daten migriert: Einfach aus dem “Dokumente und Einstellungen\[User]\Lokale Einstellungen\Anwendungsdaten\Identities” Ordner die .dbx Fiels kopieren.

Dadurch werden jedoch die Einstellungen nicht übertragen. Um diese ebenfalls zu übertragen kann man sich das Feature zum Laden von Strukturen des Windows Registry Editors zunutze machen.

Folgende Vorgehensweise bietet sich daher an:

1) Kopieren des Ordners Dokumente und Einstellungen\[User]\Lokale Einstellungen\Anwendungsdaten\Identities in denselben Ordner der neuen Installation

2) Kopieren des Adressbuchs aus Dokumente und Einstellungen\[User]\Lokale Einstellungen\Anwendungsdaten\Microsoft\Address Book in das neue Verzeichnis.

3) Laden der alten Registry-Struktur im Registry-Editor. Hierzu geht man auf den Schlüssel HKEY_USERS, dann im Menü Datei auf Struktur laden… und gibt als Strukturname z.B. “alt” ein.

4) Exportieren folgender Schlüssel unterhalb des “Alt”-Zweigs in eine .reg Datei:

HKEY_CURRENT_USER\Identities
HKEY_CURRENT_USER\Software\Microsoft\Internet Account Manager

5) Schlüssel “Alt” mittels Datei/Struktur entfernen… wieder entladen.

6) Die exportierten .reg files editieren und den Pfad von HKEY_USERS\alt auf HKEY_CURRENT_USER ändern.

7) .reg Dateien importieren

8 ) Outlook Express starten und die Passwörter für die Accounts neu eingeben.

Könnte man eventuell acuh mit einem Programm automatisieren, aber händisch ist es auch nicht soviel Arbeit.

site update

hardwarefetish.com wurde mit heute auf wordpress umgestellt.

daher: rss feed läuft nun über feedburner und befindet sich hier: hardwarefetish.com/feed.

neues design und evtl. ein paar komfortable features folgen demnächst, die alten inhalte werden nach möglichkeit in den nächsten tagen wieder hergestellt.

danke für die aufmerksamkeit.

Debian Server ueber NEtzwerk auf neuen RAID1-Server migrieren

Am Wochenende hatte ich die Aufgabe, einen bestehenden Server auf einen neuen Rechner migrieren. Der neue Rechner
hat 2 Festplatten drin, die man als Software-RAID1 gespiegelt im Verbund betreiben kann.
Im Internet habe ich einige Anleitungen gefunden, wie man ein laufendes System zu einem RAID-1 Verbund konvertiert, aber der Aufwand ist in diesem Fall ja nicht nötig, da man ja übers Netzwerk auf ein komplett neues System migrieren kann.
Ich habe micht daher etwas herumgespielt und diese Anleitung entwickelt.
Vielleicht kann ja mal jemand was damit anfangen.

Erzeugung von core dump erzwingen trotz eigenem SIGSEGV handler

Ein Problem mit Programmen ist, dass diese immer mal wieder abstürzen. Der Kunde mault, der Entwickler ist ratlos wie es dazu gekommen ist. Um post-mortem noch etwas über den Crash der Applikation feststellen zu können, gibt es unter *nix coredump-files.
Nun kann man mit ulimit -c unlimited die Erstellung dieser coredump zwar einschalten, aber das nützt nix, wenn man einen eigenen Signal handler für SIGSEGV hat, in dem man z.B. einen Stacktrace generieren und in ein Logfile zur Schnellanalyse schreiben kann.
Zufällig bin ich auf einen Mailinglisteneintrag gestoßen, wo erklärt wird, wie man den Signalhandler so setzt, dass trotzdem noch ein Stacktrace generiert wird. Prinzipiell muss man mit sigaction mithilfe des Flags SA_RESETHAND einstellen, dass der Signal-handler selbst auch wieder ein signal absetzen darf und im Signal-handler dann mit raise das Signal nochmals senden, sodass der Kernel den Coredump produziert.

Ich habe den Code noch etwas erweitert, um z.B. die Erstellung eines Coredumps trotz ulimit -c 0 zu ermöglichen
und in meinem Signal handler gibt’s einen Stracktrace auf stderr.
Den Beispielcode findet man hier

Das weitere Debuggen des coredumps sollte dann ohnehin bekannt sein:
gdb [executable] [coredump]
thread apply all bt


Defekte Windows XP Registry wiederherstellen

Nachdem ich heute mal wieder einen Fall hatte, bei dem die Windows XP Registry-Datei (konkret der SYSTEM hive) im Eimer war, bin ich auf diesen Link gestoßen, wo erklärt wird, wie man mithilfe von Systemweiderherstellungspunkten die Registry-Datei wiederherstellen kann.
Konkret geht’s relativ einfach: Mit Bart PE booten, im “System Volume Information” Ordner den neuesten Systemwiederherstellungspunkt (RP* Verzeichnis mit der höchsten Nummer) suchen und die jeweilige Registry-Datei in %systemroot%\system32\repair\ zurückkopieren.
Das Mapping der Files steht ebenfalls beschrieben:


copy c:\windows\tmp\_registry_machine_software c:\windows\system32\config\software
copy c:\windows\tmp\_registry_machine_system c:\windows\system32\config\system
copy c:\windows\tmp\_registry_machine_sam c:\windows\system32\config\sam
copy c:\windows\tmp\_registry_machine_security c:\windows\system32\config\security
copy c:\windows\tmp\_registry_user_.default c:\windows\system32\config\default


c:\windows\tmp natürlich durch den jeweiligen RP-Ordner ersetzen.

SIL3112 SATA-Controller des P4G8X Mainboards für Platten >750GB (z.B. 1TB) einrichten

Habe gestern ein P4G8X Mainboard geschenkt bekommen und wollte den neuen Rechner auch gleich entsprechend “würdigen”, indem ich ihm eine 1TB SATA-Platte verpasse.
Also schnell mal eine 1TB Platte gekauft, reingesteckt und…. …ernüchterung. Der SATA Controller bleibt beim Erkennen der Platte hängen. Na Prima! Also mal auf der Mainboard-Herstellerseite nach einem BIOS-Update suchen.. Fehlanzeige, das neueste BIOS ist von 2003. Was also tun?
Glücklicherweise bin ich dann auf folgenden Thread gestoßen: http://forums.seagate.com/stx/board/message?board.id=ata_drives&thread.id=970&view=by_date_ascending&page=1.
Dort wird erklärt, dass man mit MMTOOL das neue Controllerbios in das BIOS-Image hineinpatchen kann.
Mit dem dort vorgeschlagenen MMTOOL geht’s aber nur für AMI-BIOS wies scheint, also nichts für mein Board mit AWARD-BIOS. Jedoch habe ich bei meiner Recherche dann folgendes nützliche Tool entdeckt: AWDBEDIT.
Folgende Schritte habe ich durchgeführt, um mir ein BIOS mit aktuellem SATA-Controllerbios zu erzeugen:

1) Aktuelle BIOS-Version vom Hersteller laden.
2) Wie im Thread oben angegeben Aktuelles SATA-ControllerBIOS laden.
3) AWDBEDIT laden
4) Alles In ein Verzeichnis auf der Platte laden.
5) AWDBEDIT hatte bei mir einen Bug und hat die Plugins nicht im Unterordner gefunden, habe daher die Files aus dem Plugins-Ordner ins Programmverzeichnis (also eine Verzeichnisebene höher) kopiert.
6) In AWDBEDIT die 1006G.awd geöffnet
7) Die Fehlermeldung, dass das kein gültiges BIOS-Image ist ignoriert und mit “JA” trotzdem das Laden bestätigt.
In der Kategorie Font ROMs den FONT0 ROM ausgewählt. Dort müsste die rom\storage\4224.bin drin sein.
9) Actions / Replace File..
10) 4284.bin aus dem zuvor entpackten Controllerbios eingefügt und dann unter Filename rom\storage\4284.bin genannt.
11) File / Save
12) Neues gepatches File geflasht.

Viell. kann den Tip ja auch mal wer brauchen.

Prompt in Midnight commander unter SuSe

Was mir unter SuSe hier in der Firma immer schon am Nerv ging:
Das Prompt in der Kommandozeile veränderte sich nie je nach Verzeichnis, in welchem man gerade war.
Folglich muss man dann immer pwd eingeben, um sicherzugehen, in welchem Pfad man ist.
Die Ursache ist das PROMPT_COMMAND in /etc/profile, welches nicht sehr mc-Kompatibel ist.
Lösung: einfach durch folgendes austauschen:

PROMPT_COMMAND='echo -ne "\033]0;${USER}@${HOSTNAME}: ${PWD/$HOME/~}\007"'


strace für DOS

Auf der Suche nach einer Art strace für DOS, also einem Tool, welches die DOS-Funktionsaufrufe trackt und in einer Protokolldatei mitschreibt, bin ich auf folgendes sehr Nützliches Tool gestoßen, welches ich meinen Blog-Lesern nicht vorenthalten möchte:
Trace: A tool for logging operating system call transactions

Messagebox mit Timeout

Nachdem Zeit Geld ist und jemand nicht unbedingt immer die Nerven hat eine Messagebox wegzuklicken habe ich heute mal schnell eine MessageBox mit Timeout programmiert.
Das Prinzip ist denkbar simpel: Messagebox Hooken, Windowhandle bei Initialisierung holen, Timer Setzen und bei Timeout default-Button drücken.

Dabei bin ich jedoch durch einen Programmierfehler (vergessen die Timerprozedur in SetTimer anzugeben) auf ein interessantes Verhalten gestoßen:
Scheinbar reicht es, einen Timer mit der ID 1 mit SetTimer in der MessageBox anzulegen, der dann nach Ablauf der Zeit ein WM_TIMER an die Messagebox sendet. Vermutlich hat die Dialogprozedur des Systems schon von sich aus eine Logik dahinter, die die Box dann schließt.

Code siehe hier: MessageBox mit Timeout

Eine noch interessantere Lösung habe ich dann schließlich in der MSDN gefunden:
KB181934

Update (15.05.2009): Eine noch interessantere Lösung dafür ist die Verwendung der internen API, welche scheinbar auch von MessageBox verwendet wird. Siehe hierzu diesen CodeProject Artikel.

Empfangendes Interface bei UDP-Kommunikation finden

Ich schreibe zur Zeit privat an einer kleinen RIS (Remote-Installation)-Lösung, mit der man übe rPXE ein Betriebssystem bequem und einfach übers Netzwerk installieren kann.
Dafür wollte ich auch ein kleines Feature einbauen, mit welchem man Tokens (derzeit nur einen Token) im Textfile, welches die Menüstruktur des PXE-Menüs beschreibt, hinterlegen kann, welche dann entsprechend ersetzt werden.
Konkret handelte es sich um einen Token, welcher die IP-Adresse des TFTP-Servers angeben soll.
Um Knoppix über PXE zu booten, habe ich das gepatchte Koppix verwendet, welches statt über NFS auch über SMB booten kann. Hier der entsprechend gepatchte Knoppix-Kern.
Leider benötigt dieser bei der Pfadangabe des zu bootenden Servers unbedingt die IP und kann den Namen scheinbar nicht auflösen. Da ich den Server aber möglichst flexibel halten will, dachte ich mir, ich lasse meinen TFTPD einfach die IP des Interfaces einsetzen, über den der TFTP-Server den Client bedient.
Doch das herauszufinden gestaltet sich leider alles Andere als einfach.
Ich binde den TFTPD auf alle Interfaces (INADDR_ANY). Danach verwende ich recvfrom und sendto, um Requests zu erhalten bzw. zu beantworten. Damit funktioniert das Ganze ja recht einfach, beim recvfrom erhalte ich die CLIENT-Adresse, die ich bei sendto wieder angeben muss. Doch wie bekomme ich die IP des Interfaces?
Die erste Idee war, getsockname nach dem ersten recvfrom zu verwenden. Unter BSD-Artigen Systemen ist in der resultierenden Strutur dann die jeweils verwendete Adresse zu finden (sockaddr_in). Groß war die Ernüchterung, als unter Windows jedoch 0.0.0.0 drinnen stand. Warum das so ist erklärt der Artikel Q129065 der Microsoft Knowledge Base.
Na prima, dort steht eindeutig: Applications should not assume that they can get the IP address of the interface. . Damit wollte ich mich aber nicht zufrieden geben. Irgendwie muss es doch möglich sein, trotzdem das zuständige interface herauszufinden.
Schließlich kam ich auf folgende Idee, die als Workaround ganz gut funktioniert:
Von recvfrom ist ja die IP des Clients bekannt. Also müssen wir Winsock einfach fragen, welches Interface die beste Route dorthin hat.
Mein Workaround:
DWORD br;
WSAIoctl (sock, SIO_ROUTING_INTERFACE_QUERY, &client, sizeof(client),
&server, sizeof(server), &br, 0, 0);

Gewinnt zwar keinen Schönheitspreis, aber mir ist auch keine bessere Lösung dafür bekannt.