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.

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.