Zertifikatübersicht

Heute bin ich mit einem Problem gestoßen. Ich habe mir für meine zwei Haupt-Email-Adressen Zertifikate bei trustcenter.de bestellt.  Naturgemäß lauten beide auf meinen Namen. Theoretisch sollte es damit auch keine Probleme geben, da beide ja auf unterschiedliche Email-Adressen ausgestellt sind.

Auf dem Mac unter Mail gab es auch keine Probleme. Beide Zertifikate wurden problemlos importiert und konnten zum Signieren und Verschlüsseln benutzt werden.

Problem

Zertifikatzuordnung

Auf dem EeePC bin ich vor Kurzem von Windows Live-Mail auf Thunderbird 3.0 umgestiegen. Der Import verlief auch ohne Probleme und es wurden beide Zertifikate in der Übersicht angezeigt. Das Problem taucht auf, wenn man versucht die Zertifikate den einzelnen Email-Adressen zuzuweisen. In der Drop-Down-Liste erscheint nur ein einziges Zertifikat statt der beiden importierten.

Einzeln importiert funktionieren diese problemlos. Zusammen importiert, wird nur ein Zertifikat angezeigt.

Nach langer Recherche konnte die Ursache in der Bildung der Drop-Down-Liste von Thunderbird festgestellt werden. Zur Bildung der Liste werden bei Thunderbird nur Vor- und Nachnahme benutzt (CN), aber nicht die erweiterten Felder des Zertifikates. Viele andere Zertifikathersteller schreiben in die CN noch weitere Daten, sodass das beschriebene Problem meines Wissens nur bei trustcenter.de auftritt. Die Auszeichnung, wie trustcenter.de dies tut, entsprich der Empfehlung des Zertifikatstandards.

Lösung

Allgeminer Name

Um das Problem bei Thunderbird und trustcenter.de zu umschiffen, habe ich eins von meinen Zertifikaten gesperrt und ein neues beantragt. Dieses Mal aber in dem Feld Vorname nicht nur meinen Vornamen eingegeben, sondern “Herr …”.

Nach dem neuen Import hat Thunderbird nun beide Zertifikate richtig aufgelistet und ich konnte diese den jeweiligen Email-Adressen zuordnen.

Alternativer Name

Feel free to Flattr this post at flattr.com, if you like it.

1. Benutzer-Verzeichnis eines Benutzers verschieben.

Bild 1: Systemeinstellungen: Benutzer

Melden Sie sich am besten als ein anderer Benutzer, als der, den Sie “umziehen” möchten.

Öffne Sie die Systemeinstellungen und gehen Sie auf das Punkt Benutzer (siehe Bild 1). Unter Benutzer schalten Sie zuerst die Änderungsfunktion frei (das geschlossene Schloss unten links anklicken und mit Administratorrechten freigeben). Nun können Sie unter den Benutzer auswählen, dessen Benutzerordner Sie verschieben möchten. Klicken Sie auf diesen mit der rechten Maustaste (Kontextmenü) oder “Ctrl +  linke Maustaste”. Im Kontextmenü den Punkt “Erweiterte Optionen” auswählen. Es gibt ja nur diesen Kontextmenü-Eintrag (siehe Bild 2).

Bild 2: Erweiterte Optionen

Im neuen Unterfenster kann unter anderem auch der Benutzerordner neu festgelegt werden (siehe Bild 3).

Bild 3: Ordner ändern

Der Zielordner muss auf dabei bereits vorhanden sein.

Diese Methode hat einen entscheidenden Nachteil. Für jeden neu angelegten Benutzer muss die Prozedur wiederholt werden. Das ist zwar im häuslichen Bereich bei 2-3 Benutzern vertretbar, bei mehr Benutzern empfehle ich aber die zweite Methode: “Umlenken des gesamten /Users Ordners”.

2. Umlenken des gesamten /Users Ordners

Für diese Methode müssen wir uns des Terminals bemühen, da die Umlenkung des /User-Ordners durch einen so genannten symbolischen Link geschehen wird.

Als Erstes meldet man sich als Administrator an. Nach der Anmeldung sollten keine Programme im Hintergrund laufen (Mail usw.), da sonst das Löschen nicht richtig funktioniert (/Users wird sofort wieder neu angelegt). Das einzige Programm, das laufen soll, ist ein Terminalfenster.

Im zweiten Schritt wird das /Users-Verzeichnis auf die Zielpartition kopiert. Entweder über das Terminal oder auch mit dem Finder.

# sudo cp -Rp /Users /Volumes/NeuePartition/Users

Als Nächstes muss das “alte” /Users-Verzeichnis gelöscht werden. Das erledigt man auch am besten im Terminal-Fenster.

# sudo rm -R /Users

Im letzten Schritt legt man das Symbolische Link an, damit das Verzeichnis /Users auf den Ordner auf der anderen Partition zeigt.

# sudo ln -s /Volumes/NeuePartition/Users/ /Users

Jetzt nur noch abmelden und neu anmelden. Alle Benutzer liegen nun auch der anderen Partition, auch neu angelegte.

Wer auf Nummer sicher gehen will, sollte diese Operationen entweder von einer Installation auf einer externen HDD starten oder von der Boot-DVD (Terminalfenster aufrufen, bevor die Installation anfängt). Dann sägt man sprichwörtlich nicht an dem Ast, auf dem man gerade sitzt.

In diesem Fall muss /Users durch /Volumes/SystempartitionName/Users ersetzt werden.

Auf demselben Weg kann auf Wunsch auch das Programm-Verzeichnis auf eine andere Partition “verschoben” werden.

Nach der Neuinstallation des Systems muss man nur den symbolischen Link neu setzten und alle Benutzer (incl. aller deren Einstellungen) sind wieder da.

Ich hoffe dieser Beitrag hat einigen geholfen, das Mac OS X noch ein wenig komfortabler zu machen.

WARNUNG: Das Arbeiten im Terminal mit administrativen Rechten erfolgt auf eigene Gefahr. Jeder, der sich auch das Terminal begibt, sollte wissen, was er mit dem System mach, da es hier keinen doppelten Boden und keine Sicherheitsabfragen gibt. Ein SuperUser darf eben ALLES machen, ohne Nachfragen.

Feel free to Flattr this post at flattr.com, if you like it.

Die Lösung liegt darin, das Feature, die Mac-Partitionen zu sehen, temporär auszuschalten. Dazu muss im Ordner:

c:\Windows\System32\Drivers

In diesem Ordner muss die Datei AppleMNT.sys umbenannt werden. Nach dem Neustrat von Windows, werden die Mac-Partitionen nicht mehr erkannt und man kann den SP3 wie gewohnt installieren. Nach der Installation kann die Datei AppleMNT wieder zurück umbenannt werden.

Die Problematik ist auch bei Apple Support gut erklärt.

Feel free to Flattr this post at flattr.com, if you like it.

Originalmeldung: www.typolight.de

Feel free to Flattr this post at flattr.com, if you like it.

Um diesen Mangel zu beseitigen, benutzte ich schon seit Jahren unter Windows den Duden Korrektor (seit Version 3.5) für OpenOffice. Unter Windows klappt so weit alles gut, da der XP bis dahin praktisch nur in 32-Bit-Version lief.

Seit über 3 Jahren nutze ich vermehrt Linux, als primäres Betriebssystem, und seit einem Jahr noch Mac OS X 10.5 (Leopard) für meine Frau. Also wurde kurzerhand der Duden Korrektor (Version 5.0 mittlerweile) auch auf diese Systeme installiert, theoretisch. Bei Mac gibt es keine Probleme. Die Erweiterung läuft auf 64-Bit.

Unter Linux ist ein 64-Bit-System dagegen eine absolute Bremse. Es funktioniert einfach nicht. Auch konnte ich bis jetzt keine Workarounds finden, die eine funktionierende Umgebung erzeugen. Unter 32-Bit läuft es dagegen ohne Probleme (EeePC 1000H).

Die Anfragen an Duden Verlag direkt ergaben nichts. Es kommt nur die Antwort, das 64-Bit-Systeme nicht unterstützt werden, auch nicht in der Zukunft. Mittlerweile steht sogar in den Systemanforderungen (Version 6.0), dass Windows XP und Vista nur in den 32-Bit-Versionen unterstützt werden. Bei Linux wird merkwürdigerweise keine solche Ausnahme angegeben.

P.S.: Ein schneller Test der Version 5.0 mit OpenOffice 3.1 unter Windows 7 x64 RC1 zeigte, dass auch hier keine Inkompatibilitäten auftreten.

Feel free to Flattr this post at flattr.com, if you like it.

Vor kurzen wurde mir aber eine Aufgabe gestellt, die nicht mehr so einfach zu lösen war. TYPOlight sollte auf einem Windows 2003 Server laufen, und möglichst mit Windows Bordmitteln. Das hieß nichts anderes, als dass CMS unter IIS 6.0 und MS SQL 2005 laufen sollte.

Die Verwendung der MS SQL Datenbank scheiterte nach mehreren Versuchen komplett. Da fehlt einfach noch die Erfahrung in der Community. Es ist zwar ein Abstraktionslayer für die MS Datenbank vorhanden, aber bis jetzt gibt es keine positiven Rückmeldungen, dass TYPOlight wirklich damit läuft, und vor allem, wie man dieses einrichtet. Vielleich finde ich noch in meiner Freizeit ein wenig Zeit und probiere es zum Laufen zu bekommen.

Als erstes Testsystem benutzte ich Windows XP mit IIS 5.0.  Grundsätzlich läuft TYPOlight auch unter IIS 5.0, allerdings mit mehr Einschränkungen, als unter IIS 6.0. Auf beiden Windowsumgebungen wurde PHP 5.3 und MySQL 5.0 verwendet (Version 5.1 hat einen defekten Windows Installer, der unter Server 2003 die Installation versagt).

Der einzige Unterschied zwischen IIS 5.0 und IIS 6.0, den ich feststellen konnte, war, dass es unter IIS 5.0 keine Suchmaschinenfreundliche URLs möglich sind. Man muss immer “Keine Seitenaliase verwenden” aktivieren, damit die Seiten überhaupt aufgerufen werden können. Somit ergeben sich aber folgende URLs:
www.domain.de/index.php?id=123

Unter IIS 6.0 können suchmaschinenfreundliche URLs verwendet werden, so wie diese standardmäßig von TYPOlight generiert werden (ohne Zuhilfenahme von HTACCESS).
www.domain.de/index.php/alias.html

Weiterhin müssen für den TYPOlight Ordner (oder nur tl_files und tmp Ordner) die Rechte für den IIS-Benutzer (Vollzugriff) gesetzt werden, damit TYPOlight in diese Ordner auch schreiben kann. Wer die Dateien über die integrierte Verwaltung hoch laden will, wird hier auf mein anderes Eintrag verwiesen, damit die PHP-Temp-Einstellung richtig funktioniert.

Solange man MySQL als Datenbank einsetzt, spricht eigentlich nichts dagegen den IIS als Webserver zu nutzen. Microsoft ist ja immer mehr bemüht auch PHP direkt in Visual Studio und andere Produkte einzubinden, sodass eine bessere Zusammenarbeit zu erwarten ist. Für eine leichte Installation ist sowohl FastCGI als auch PHP 5.2 über den Microsoft Web-Installer verfügbar (www.microsoft.com/web). Die einzige Schwierigkeit, die noch bleibt, ist die Unterstützung von .htaccess Dateien, die man von Apache her kennt und die von vielen PHP-Projekten für die Generierung freundlicher URLs verwendet werden. Es gibt zwar schon ISAPI Erweiterungen die htaccess nachbilden, aber zumindest bei TYPOlight ist es noch nicht ausreichend, um 100% Funktionalität und Stabilität zu gewährleisten.

Feel free to Flattr this post at flattr.com, if you like it.

Zugriffsberechtigungen überprüft, stimmt alles, also blieb nichts anderes übrig, als zu googln. Der erste Hinweis kam, dass in der PHP.ini ein Temp-Ordner für Uploads definiert ist, auf den der IIS-Benutzer aber keine Schreibrechte hat (c:\Windows\Temp). Also in der PHP.ini den Ordner auf c:\Upload-Temp geändert und dem IIS-Benutzer auf diesen Ordner volle Rechte vergeben. Zwecklos. Es landen weiterhin 0kB Dateien im Zierordner. Auch ein Neustart brachte keine Besserung.

Nach mehreren Stunden Recherche im Internet kam der entscheidende Hinweis, dass der Temp Ordner unbedingt innerhalb des Root-Verzeichnisses der aufrufenden Homepage liegen muss, sonst kann IIS in Verbindung mit PHP keine temporären Daten in diesen schreiben.

Die Änderung der PHP.ini-Datei führte nun zum gewünschten Ergebnis. Der Upload funktioniert nun einwandfrei.

Feel free to Flattr this post at flattr.com, if you like it.