Die Einrichtung und der Zugriff der verschlüsselten Derby Datenbank ist vergleichsweise simpel: Zum JDBC-Connect String werden die zwei Parameter dataEncryption=true und bootPassword=2NGWGv.... hinzugefügt, z.B.

jdbc:derby:MyDB;create=true;dataEncryption=true;bootPassword=2NGWGv

Hier ein Screenshot, wie ich die Verschlüsselung im Eclipse Data Source Explorer eingebunden habe:

Über den zusätzlichen Parameter encryptionAlgorithm lässt sich noch der Verschlüsselungs-Algorithmus angeben. Weitere Informationen zu diesem Parameter gibt es in den Derby-Docs.

Da ich den Datei-Namen der zu erzeugenden XML-Sitemap-Datei für jedes Blog bestimmen kann, bennen ich die Datei nach einem einheitlichen Schema: sitemap-<http-host>.xml.

Da ich meine Sitemaps bereits bei Google & Co. unter dem Namen sitemap.xml registriert habe, wäre ein Umstieg auf den neuen Dateinamen etwas lästig. Daher habe ich die Apache RewriteRules herangezogen:

# Sitemap Korrektur

RewriteCond %{REQUEST_FILENAME} !-f

RewriteCond %{REQUEST_FILENAME} !-d

RewriteCond %{REQUEST_URI} sitemap.xml.gz$

RewriteRule sitemap.xml.gz$ /sitemap-%{HTTP_HOST}.xml.gz [L]

# Ende Sitemap Korrektur

Die vier Zeilen bewirken, dass Anfragen an die Datei sitemap.xml.gz — sofern nicht vorhanden — an die Datei sitemap-<Hostname>.xml.gz (intern) weitergeleitet werden.

Das Problem ist, dass Firefox Portable den echten Firefox startet und dieser echte Browser sich zum Standard-Internet-Browser des Windows-Systems macht. Gewünscht ist aber, dass FirefoxPortable gestartet wird.

Ich habe hierfür in der Windows-Registry den folgenden Wert anpassen müssen:

HKEY_CURRENT_USERSoftwareClasseshttpshellopencommand

(Die Registrierdatenbank kann so geändert werden: “Start”-Taste drücken -> “Ausführen” -> regedit eingeben und “OK” klicken).

Hier steht beim Standard-Wert firefox.exe unterhalb des FirefoxPortable Verzeichnisses drin. Dieser Wert muss so geändert werden, dass FirefoxPortable.exe gestartet wird. Allerdings war bei mir noch der Parameter “-osinst” angegeben, der den FirefoxPortable am Starten gehindert hat. Erst nachdem ich den Parameter entfernt hatte, startete mein gewünschter Firefox mit den richtigen Einstellungen.

Zuerst versuchte ich mein Glück in der Experten-Konfiguration des Browser, in dem ich als URL in die Adresse-Leiste meines Firefoxes eingab: about:config. Hier aber gelang es mir nicht eine passende Einstellung zu finden.

Die Lösung hierfür verbarg sich im Unterverzeichnis “OtherSource” der Firefox-”Installation”. Die dort enthaltene Konfigurations-Datei “FirefoxPortable.ini” musst nur in den Hauptordner von Firefox kopiert und bearbeitet werden. Sprich, die Datei musste im selben Verzeichnis abgelegt sein, wie das Programm FirefoxPortable.exe.

Nun noch die Konfiguration bearbeiten und in der Zeile “DisableSplashScreen=false” verändern auf “DisableSplashScreen=true”. Damit ist der SplashScreen beim Starten deaktivert.

Hier meine geänderte Konfiguration:

[FirefoxPortable]
FirefoxDirectory=Appfirefox
ProfileDirectory=Dataprofile
SettingsDirectory=Datasettings
PluginsDirectory=Dataplugins
FirefoxExecutable=firefox.exe
AdditionalParameters=
ocalHomepage=
DisableSplashScreen=true
AllowMultipleInstances=false
DisableIntelligentStart=false
SkipChromeFix=false
SkipCompregFix=false
RunLocally=false

Mit dieser einfachen Änderung ist dieses Fenster beim Starten von Firefox nicht mehr zu sehen:

wdcollect[..]: Statistics stack owerflow. Stack contains now 1000 unsaved entries, some of them will be removed.

Beide Probleme hängen zusammen. Der wdcollect-Dienst konnte (aus irgend einem Grund) die Datenbank mysql nicht erreichen und konnte so die gesammelte Statistik-Einträge nicht mehr speichern. Folglich konnte auch kein Auslastungsgraph berechnet werden. Nach einem Neustart des wdcollect-Dienstes sammelt mein Plesk wieder fleißig Statistik-Informationen.

Den Neustart des Dienstes habe ich über den Admin-Bereich von Plesk durchgeführt, indem ich bei “Module” -> “Watchdog” den Dienst zuerst deaktiviert habe und anschließend wieder aktiviert habe.

IMAP_EMPTYTRASH=Trash:7

Diese Anweisung veranlasst Courier dazu, alle Mails aus dem Trash/Papierkorb-Ordner nach 7 Tagen zu entfernen. Wer die Kurz-Doku zu dieser Konfig-Anweisung studiert, findet schnell noch grausamere Möglichkeiten dieser Option. So kann grundsätzlich jeder Ordner nach einer bestimmten Zeit “bereinigt” werden, etwa der Ordner für gesendete Nachrichten.

Wer die Zeile auskommentiert oder ohne Werte einträgt und den Imap-Server zum Neustart bewegt, hat dem Datenverlust einen Riegel vorgeschoben. Die gewünschte Konfiguration schaut dann so aus:

IMAP_EMPTYTRASH=

Nun noch den (richtigen) Courier-Server neu laden — am besten über den Plesk-Manager bei “Server-Verwaltung” -> “Dienste”.

Wie kommen nun die verlorenen Mails wieder zurück in den Papierkorb? Wer sich hier noch Hoffnung macht, dem kann geholfen werden … mit den regelmäßigen, aktuellen Backups vom Server. Wer die nicht hat, kann sich nur noch tränenreich von seinen geliebten Daten verabschieden.

IMAP_CAPABILITY=”IMAP4rev1 UIDPLUS CHILDREN NAMESPACE THREAD=ORDEREDSUBJECT THREAD=REFERENCES SORT QUOTA IDLE AUTH=CRAM-MD5″

Die Konfigurationseinstellung IMAP_ENHANCEDIDLE ist mithilfe des Wertes 1 zu aktivieren:

IMAP_ENHANCEDIDLE=1

Nun noch den Courier-Imap-Server über den Plesk-Desktop neu laden und schon spricht der Server IMAP.

Für ergänzende Konfigurations-Anweisungen des Apaches sind die folgenden beiden Schritte notwendig:

1. Anlegen der vhost.conf für die gewünschte Domain.
   Im Konfigurations-Verzeichnis der Domain liegt von Haus aus die Datei httpd.conf, welche von Plesk gelesen und geschrieben wird. Das Konfigurationsverzeichnis für die Domain www.domain.de liegt beispielsweise bei SuSE Linux hier: /srv/www/vhosts/domain.de/conf/. In dieses Verzeichnis gehört nun die vhost.conf – Datei, in die die Apache-Einstellungen eingetragen werden können. Alle Einträge sind dabei automatisch innerhalb der <Virtual> Konfiguration enthalten. Anschließend noch daran denken, die vhost.conf für den Web-Server lesbar zu machen: $> chmod go+r /srv/www/vhosts/domain.de/conf/vhost.conf
2. Plesk dazu bringen, die vhost.conf Datei einzubinden.
   Auch wenn die eigenen Einstellungen in der Datei bereits korrekt eingetragen sind, so weiß der Apache noch nichts von der erweiterten Konfiguration. Plesk muss zuvor noch die Datei in die bestehende httpd.conf per Include einbinden. Dies kann hervorgerufen werden, indem die Einstellungen zu der Domain in Plesk aufgerufen und (unverändert) gespeichert werden.
   Jetzt ist die vhost.conf in der httpd.conf inkludiert und dem Apache bekannt gegeben.

Noch ein Tipp für Änderungen an der Konfiguration: Die geänderte Konfiguration sollte immer überprüft werden, bevor der Apache neu gestartet wird — egal ob per rcapache restart oder apache2ctl graceful. Bei Fehlern droht sonst, dass der Apache seinen Dienst verweigert.

Daher immer ein apache2ctl configtest vor dem “reload” durchführen

Nachdem es nicht zu empfehlen ist, die Einstellungen des Plesk-Apache-Servers auf den produktiven zu übertragen, muss eine Proxy-Verbindung aufgebaut werden. Dank der Apache2-Module “mod_proxy” und “mod_proxy_http” kann ein Apache Anfragen zu einem anderen Web-Server durchschleusen — in diesem Fall zum Pleks-Server auf dem lokalen Port 8443.

Zuerst muss sicher gestellt sein, dass die beiden genannten Module “mod_proxy” und mod_proxy_http” vom Apache geladen werden. Dazu sind beide Module in der Konfiguration unter

/etc/sysconfig/apache2

einzutragen. Die Zeile beginnend mit APACHE_MODULES sollte die Einträge mod_proxy und mod_proxy_http enthalten, z.B.:

APACHE_MODULES="actions alias auth_basic dir env expires include
                log_config mime negotiation setenvif ssl php5
                rewrite mod_proxy mod_proxy_http"

Anschließend ist der Apache per “rcapache restart” zum Neustart zu bringen. Hinweis: Ein “apache2ctl graceful” genügt nicht. Spätestens nach dem Neustart kann der Apache als Proxy arbeiten.

Nun muss die Weiterleitung in der Apache-Konfiguration angelegt werden. Es empfiehlt sich dringend, eine eigene Subdomain für den Zugriff auf Plesk zu verwenden und nicht etwa ein Unterverzeichnis zu verwenden, da Plesk mit absoluten Pfaden arbeitet.

Vorgehen:

1. Über die Plesk-Console eine neue Sub-Domäne anlegen, z.B. “plesk.meine-domain.de”
2. Im config-Verzeichnis der Subdomain die vhost.conf – Datei anlegen (sollte noch nicht existieren):

   /srv/www/vhosts/meine-domain.de/subdomains/plesk/conf/vhost.conf

3. Die Datei vhost.conf sollte mindestens diese Zeilen enthalten:

   ProxyPass / https://localhost:8443/
   <Location />
     ProxyPassReverse /
   </Location>
   
   SSLProxyEngine On
   
   <Proxy *>
     Order deny,allow
     Deny from all
     Allow from all
   </Proxy>

4. Nun muss die neue Configdatei (vhost.conf) noch in die Apache-Konfiguration aufgenommen werden. Dazu am besten auf dem Plesk-Desktop die Einstellungen für die neue Sub-Domäne (plesk.meine-domain.de) laden und (unverändert) speichern.

Ein Hinweis zur Sinnhaftigkeit: Es gibt Kunden oder gar Administratoren, die nur per (Zwangs-)Proxy im Internet surfen können — etwa vom Firmen-PC. Da nun viele dieser Firmen-Proxy-Server so eingestellt sind, dass CONNECT-Anfragen (sprich SSL-Verbindungen) nur auf Port 443 möglich sind, können solche User nur die unsichere http-Verbindung nutzen. Neben dem Zwangsproxy kann auch eine restriktive Firewall-Regelung den Zugriff auf diesen Nicht-Standardport (was auch immer Standard bedeuten mag) verbieten — hier muss dann in jedem Falle umgestellt werden.

Die Lösung für das Problem war bei mir sehr simpel: Die Admin-Oberfläche startet über ein Popup-Fenster, was mein Firefox standardmäßig unterbindet. Wer genau hinschaut sieht in der Status-Leiste seines Browsers das Symbol für ein blockiertes Popup-Fenster. Über das Symbol (ein Fenster mit einem roten Kreuz) kann die aktuelle Seite für Popups freigegeben werden: Linke Maustaste und “Popups erlaube für …” anklicken.