OpenSCEP
OpenSCEP is an open source implementation of the SCEP protocol used by Cisco routers for certificate enrollment to build VPNs. It implements most of the draft specification, include as reference in the distribution.
aus Delicious/steinhobelgruen
Diese Anleitung muß ich für ein paar Kollegen im Moment sowieso schreiben, und vielleicht interessiert das ja noch irgendjemanden. Bevor ich also wieder so ein unkommunikatives Word-Dokument rumschicke:
1. Subclipse
Im Gegensatz zu CVS wird der Nachfolger Subversion von Eclipse (noch?) nicht direkt unterstützt — dabei hat Subversion viele Vorteile (z.B. atomare Transaktionen und Versionierung über Verschiebungen und Umbenennungen hinweg). Zuerst müssen wir das deshalb in Form eines Plugins nachrüsten: Subclipse gibt es bei tigris.org, und eine Installationsanleitung ist auch dort.
So, jetzt kann man in Eclipse die „SVN Repository Exploring perspective“ öffnen und dort die Adresse seines Repositories eintragen.
Auf UNIXoiden Betriebssystemen wie Linux, Solaris und MacOS X kann man den folgenden Schritt überspringen. Dort ist ssh in der Regel installiert, im Pfad und kann als Tunnel gestartet werden ohne Fensterchen aufzumachen.
2. ssh-Tunnel aufbauen
Subversion unterstützt einen Haufen unterschiedlicher Protokolle. Neben dem direkten Dateizugriff auf das Repository und einem eigenen Protokoll für lokale Aufrufe unterstützt es WebDAV über http(s) durch ein Apache-Modul und kann über verschiedene Remote-Shell-Protokoll tunneln. Wenn man die Repositories (so wie wir) auf einem UNIX-Server lagert und keine Lust hat, sich mit dem svnDAV-Apache-Modul und seiner zweiten Benutzerverwaltung herumzuschlagen, dann ist das svn+ssh-Protokoll eine günstige Wahl. Leider kommt Windows ohne ssh-Client (im Repository Explorer sieht man unklare Fehlermeldungen wie „Das Verzeichnis ist nicht da.“), deshalb muß Abhilfe geschaffen werden. Weiterlesen
Einer der Haupthinderungsgründe für den Weiterbetrieb der Alertbird-Software war ja immer der Ressourcenbedarf (sowohl Rechner- als auch Geld-) der Oracle-Datenbank. Meine Umbautätigkeiten bestehen deshalb bisher zum größten Teil aus Änderungen, um die Daten in Zukunft in einer PostgreSQL-Datenbank halten zu können. Leider habe ich die alten Daten nur in Form eines exp/imp-Dumpfiles für Oracle 8i, drum mußte ich tricksen:
Aus der Arbyte habe ich mir eine virtuelle VMWare-Maschine mit Oracle 9i drauf ausgeliehen, dort den Dump eingespielt und mit einem JAVA-Programm die Daten in die Postgres rüberkopiert (solche Programme sind schnell geschrieben, das habe ich schließlich im FleetBoard-Projekt lange genug geübt). Leider waren nachher alle Umlaute weg (bzw. es war ein Bit abgeschnitten — die Leute heißen dann z.B. „Jvrg“). Kurz nachgesehen: die Umlaute waren aber auch in der Quelldatenbank schon weg, am Kopierprogramm liegt’s also nicht. imp nochmal ausgeführt: da steht doch tatsächlich, die Daten seien US7ASCII-Kodiert. Ohje, sollten die Umlaute etwa beim Export schon verschwunden sein? Dann wären sie seit 2004 weg und wohl nicht wieder aufzutreiben…
Zum Glück waren die Umlaute in der Datei selbst vorhanden, da stimmte wohl nur die Deklaration nicht (das bedeutet übrigens gleichzeitig, daß Umlaute in Alertbird in der Vergangenheit nur deshalb funktioniert haben, weil Oracle sich vor Version 9 nicht um den Inhalt des achten Bits geschert hat, wenn ein 7-Bit-Zeichensatz eingestellt war). Hier fand ich eine Erklärung, wie die Zeichensatzangabe in die Exportdatei kommt. Ich brauchte also nur einen Hexeditor…
… und mußte den Anfang der Datei von „03 00 01 …“ auf „03 00 1F…“ ändern, nochmal in Oracle importieren und die Kopie noch einmal starten.
Das sieht doch schon ganz gut aus (an den Datumsfeldern muß ich aber noch feilen, die verlieren noch alle ihre Uhrzeit):
