blog.bartlweb - a technologist's external brain

Thema: Server

Let’s Encrypt in Enterprise-Setups ohne DNS-Validierungsmöglichkeit per HTTP-Validierung einrichten

Let's Encrypt bietet kostenlose SSL-Zertifikate für die Absicherung von Webservices (Webserver, E-Mail, ...) an. Es lassen sich zwar keine Wildcard-Zertifikate erstellen, aber dafür mehrere einzelne Zertifikate beantragen und zusätzlich Mutidomain-Zertifikate erstellen.

Für das Abrufen der Zertifikate gibt es Tools, die direkt auf dem öffentlich erreichbaren Hostsystem ausgeführt werden und jede einzelne Domain (für die ein Zertifikat beantragt wird) per HTTP oder DNS verifizieren. Und da haben wir in komplexen Infrastrukturen auch schon die größte Hürde:

  • Die DNS-Validierung lässt sich nur sinnvoll nutzen, wenn das Tool direkt die DNS-Konfiguration modifizieren kann und fällt damit für alle jene die die eigenen Domains von einem Hoster verwalten lassen flach.

Self-signed Zertifikate für lokale Webservices mit OpenSSL selbst erstellen

Nicht für jeden Webservice ist es notwendig, ein kostenpflichtiges SSL-Zertifikat von einer anerkannten Registrierungsstelle zu erwerben. So kommen Entwicklungssysteme oder Dienste für eine eingeschränkte nicht-öffentliche Zielgruppe, bei denen es nur auf eine zuverlässige Verschlüsselung, aber nicht auf eine Verifizierung ankommt durchaus mit selbst erstellten Zertifikaten aus.

Self-signed Zertifikat erstellen

Eigene Zertifikate lassen sich mit OpenSSL sowohl unter Linux als auch Windows sehr einfach und rasch mit dem folgenden Befehl erstellen. Die für das Zertifikat notwendigen Daten werden dabei durch das Tool über die Kommandozeile abgefragt. Im unteren Beispiel habe ich ein Zertifikat für einen Entwicklungsrechner erstellt und daher eine Gültigkeit von 10 Jahren (3650 Tage) gesetzt, dieser Wert lässt sich aber beliebig an die eigenen Bedürfnisse anpassen.

Pfade oder Dateien von Redirects mit mod_rewrite in Apache ausnehmen

Der Apache Webserver bietet mit mod_rewrite ein mächtiges Werkzeug, um URLs zu modifizieren. Die Klassiker sind dabei der Redirect von HTTP auf HTTPS oder auch von einer ganzen Domain auf eine andere (z.B. von example.com auf www.example.com).

Doch nicht immer sollen alle Pfade oder Dateien umgeleitet werden. Einen konkreten Fall bilden die Validierungsdateien für Domains, wie Sie von Let's Encrypt verwendet werden, die immer von der Originaldomain für welche die Zertifikate ausgestellt werden sollen abgefragt werden müssen.

Die folgenden beiden Beispiele zeigen, wie ein Pfad vom Redirect auf HTTPS bzw. auf eine andere Domain ausgenommen werden kann:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteCond %{REQUEST_URI} !^/\.well-known/acme-challenge/.*$ [NC]
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
RewriteEngine On
RewriteCond %{REQUEST_URI} !^/\.well-known/acme-challenge/.*$ [NC]
RewriteRule ^(.*)$ https://www.example.com/ [R=301,L]

Eigene Ressourcen in Website die mit mod_proxy von Apache ausgeliefert werden einbinden

Oft dient der Apache Webserver nur als Gateway für weitere im internen Netzwerk liegende Webservices, die aber nach außen hin über Standardports bzw. öffentliche Domains erreichbar gemacht werden sollen. Dazu bedient man sich dem Konzept des Reverse Proxy und dem Apache Modul mod_proxy.

Was aber, wenn zusätzliche Ressourcen von diesen Domains ausgeliefert werden sollen (z.B. Verifizierungsdateien für Google Analytics oder Let's Encrypt, robots.txt, ...), die aber nicht über den eigentlichen Webservice bereitgestellt werden können? Hier kann der Apache Webserver bzw. mod_proxy helfen und einzelne Pfade von der Weiterleitung an das Zielsystem ausnehmen und damit dessen Inhalte selbst bereitstellen. So können dann z.B. global verfügbare Alias-Definitionen oder einzelne virtuelle Verzeichnisse in den Proxy-Hosts verfügbar gemacht werden.

HTML-Anmeldeformulare mit Apache Modul mod_auth_form

Apache stellt verschiedene Varianten für die Authentifizierung von Nutzern bereit. Die bekannteste ist wohl AuthType Basic die im Browser eine schnöde Eingabeaufforderung für Benutzername und Passwort erzeugt. Aber der Apache Webserver liefert mit mod_auth_form auch ein Modul mit, mit dem sich ein HTML-Formular für die Anmeldung nutzen und vor allem selbst adaptieren und gestalten lässt.

Module laden

Damit mod_auth_form funktioniert, muss das entsprechende Modul durch Auskommentieren in der httpd.conf geladen werden. Außerdem werden noch weitere Module zum Verarbeiten der Requests und zum Erzeugen und Speichern der Sessions benötigt.

Upgrade von Alfresco 5.0.c auf die neue Alfresco Community Edition 201605 GA

Alfresco hat nicht nur das Namensschema seiner neuen Community Edition Releases verändert, sondern auch etwas am JavaScript der Editoren verändert, bzw. auf die aktuelle Version von TinyMCE umgestellt, weshalb meine Anpassungen und Optimierungen am Editor nicht so einfach vom alten Release übernommen werden können. Daher gibt es eine neue Upgrade-Anleitung inkl. aktualisierten Code-Anpassungen für die Adaptierung des Wiki- und Blog-Editors.

Alfresco neu installieren und konfigurieren

Installieren Sie Alfresco über den Installationsassistenten in ein neues Verzeichnis, um das aktuelle Installation unangetastet zu lassen und die Daten später übernehmen zu können. Damit die parallele Installation einwandfrei klappt, müssen Sie drei Punkte beachten:

Zugriff auf Apache vHosts vom internen Netzwerk erlauben, aber für externe Netzwerkzugriffe absichern

Gerade bei einfachen Netzwerkdiensten, wie z.B. einem Medienserver, soll im internen Netzwerk der Zugriff uneingeschränkt möglich sein, aber sobald jemand aus dem Internet darauf zuzugreifen versucht, dies entweder untersagt oder mittels Passwort geschützt sein. Dazu lässt sich die Konfiguration des virtuellen Hosts entsprechend anpassen, um für einzelne IP-Bereiche bereits gemachte Einschränkungen wieder aufzuheben.

Konfiguration ab Apache 2.4

Ab Apache 2.4 wird die RequireAny-Direktive genutzt, um Ausnahmen für die aktivierte Basic-Authentifizierung zu schaffen. In diesem Fall wird der Zugriff gestattet, wenn der Nutzer entweder eine IP aus dem Netzwerk 192.168.0.* nutzt oder einen gültiger Nutzer (Authentifizierung) ist.

Z-Push 2.3 und Zimbra Backend 65 zur Zusammenarbeit bewegen

Nach dem Update auf Z-Push 2.3 und dem Connector Z-Push Zimbra Backend 65, klappt die Anmeldung nicht mehr und die folgende Fehlermeldung wird in den Logs ausgegeben:

Checking username casings: PHP Fatal error: 
Declaration of BackendZimbra::Setup() must be compatible with IBackend::Setup($store, $checkACLonly = false, $folderid = false, $readonly = false)
in /server/activesync/backend/zimbra/zimbra.php on line 542

Das Problem liegt an einer geänderten Methode im Quellcode von Z-Push die im ZimbraBackend aufgerufen wird und nun einen weiteren Übergabeparameter erwartet. Eine kleine Anpassung in der Datei zimbra.php des Connectors (zu finden im Z-Push Installationsverzeichnis unter /backend/zimbra/zimbra.php) behebt das Problem.

Dateigröße von thin-provisioned VMDK-Dateien einer virtuellen Maschine unter WMware schrumpfen

VMware erlaubt es mit sogenannten thin-provisined Virtual Maschine Disks (VMDK-Dateien) virtuelle Festplatten zu erstellen, die den Speicherplatz der angegebene Festplattengröße nicht sofort am Hostsystem reservieren, sondern nur bei Bedarf bis zur maximal angegebenen Größe anwachsen. Bei vielen Festplattenaktivitäten mit großen Dateien oder auch regelmäßigen Windows-Udpates wachsen diese VMDK-Dateien mit der Zeit an, obwohl in der virtuellen Maschine in Wirklichkeit nur ein Bruchteil des Festplattenspeicherplatzes genutzt wird, als jener der am Hostsystem durch die VMDK belegt ist.

Um nicht belegten aber reservierten Speicherplatz einer VMDK-Datei auf dem Host freizugeben, muss eine Shrink-Aktion aus der laufenden virtuellen Maschine heraus über die installierten VMware Tools gestartet werden. Das Tool wird über die Kommandozeile bedient und ist je nach Gastbetriebssystem etwas anders zu nutzen:

Anzahl und Größe von Log-Dateien der Alfresco Community Edition wachsen unkontrolliert

Auf meinem Server läuft seit einigen Jahren Alfresco in der Community Edition. Letztens waren plötzlich die 200GB Plattenspeicher meiner virtuellen Maschine voll und nach einem kurzen Blick musste ich feststellen, dass Alfresco unkontrolliert Log-Dateien anlegt und speichert, ohne sich um das Entfernen von alten Logs zu kümmern. So wachsen die Log-Dateien um ca. 2GB pro Woche.

Anscheinend kümmert sich die Alfresco Community Edition nicht um die Rotation der Log-Dateien. Eine kurze Recherche förderte zwei interessante Artikel zutage in denen erklärt wird, wie log4j so adaptiert werden kann, dass sowohl Größe als auch Anzahl der Log-Dateien beschränkt wird:

community.alfresco.com/thread/203988-how-to-better-configure-log-rotation-in-alfresco
sysadminhub.blogspot.co.at/2013/04/log-rotation-retention-in-alfresco.html