Mercury/32 v4.90 released

David Harris hat am 23.10.2021 eine neue Version des Mercury/32 Mailserver veröffentlicht.

Version 4.9 is an important major release containing numerous significant changes and fixes.

https://community.pmail.com/index.php?u=/topic/11469/mercury-32-v4-90-released

Nützliche Links

http://www.pmail.com/

Ubuntu 18.04: Apache2 php Version aktualisieren auf php7.4

Da es sich um einen Ubuntu Server Version 18.04 LTS (End of Life: April 2023) handelt, muss zuerst das PPA von “ondrej/php” hinzugefügt werden. Darin sind sämtliche benötigten PHP Packages / Extensions der Version 7.4 enthalten. Zusätzlich braucht es für den Apache2 noch “ondrej/apache2”.

sudo apt install software-properties-common
sudo add-apt-repository ppa:ondrej/php
sudo add-apt-repository ppa:ondrej/apache2
sudo apt update

Als Nächstes kann nun php7.4 installiert werden:

sudo apt install php7.4

Nachdem wir nun PHP installiert haben, installieren wir noch die benötigten Extensions:

sudo apt install php7.4-common php7.4-mysql php7.4-xml php7.4-xmlrpc php7.4-curl php7.4-gd php7.4-imagick php7.4-cli php7.4-dev php7.4-imap php7.4-mbstring php7.4-opcache php7.4-soap php7.4-zip php7.4-intl -y

Jetzt können wir Apache2 konfigurieren und deaktivieren zuerst einmal die alte PHP-Version:

sudo a2dismod php7.2

Als Nächstes aktivieren wir die neue PHP-Version:

sudo a2enmod php7.4

Zum Schluss müssen wir noch einen Neustart des Webserver Apache2 durchführen, damit die neue PHP-Version auch verwendet wird:

sudo systemctl restart apache2

Nützliche Links

Upgrade PHP version to PHP 7.4 on Ubuntu

ppa:ondrej/php – the main PHP repository

Ondřej Surý – bietet Debian Packages (PHP, nginx, apache, DNS, …)

The Ubuntu lifecycle

Windows: Remotecomputer herunterfahren oder neustarten

Dazu muss die “Command Console” / Eingabeaufforderung mit einem auf dem Remotecomputer berechtigten Benutzer ausgeführt werden.

Mit dem “Shutdown-Befehl” kann dann der Remotecomputer neu gestartet oder heruntergefahren werden:

>shutdown /r /m \\<remotecomputer> /t 0
/rneustarten
/mIP oder Name des Remotecomputer
/tZeit bis zum Neustart (0 = sofort ohne Verzögerung)

Nützliche Links

Windows: shutdown command

How to Restart or Shutdown a Remote Computer (activedirectorypro.com)

nginx: Strong SSL Security on nginx

Beim Prüfen der nginx SSL-Konfiguration bin ich auf folgende Seite gestossen: Raymii.org: Strong SSL Security on nginx. Hier wird ausführlich beschrieben wie man die SSL-Konfiguration seines nginx Webserver stärkt. Eine weitere aktuellere Seite ist: sherbers.de: Sichere TLS Konfiguration mit NGINX.

Prüfen kann man die Konfiguration auf: ssllabs.com

Hat man die wichtigsten Einstellungen vorgenommen, sollte der SSL-Report mindestens eine A Bewertung anzeigen.

SSL-Report Bewertung
SSL-Report “monsterli.ch” Bewertung

 

Nützliche Links:

Raymii.org: Strong SSL Security on nginx

sherbers.de: Sichere TLS Konfiguration mit NGINX

ssllabs.com: SSL Server Test

 

 

Ubuntu: Apache2 Kommandos

Starten:

> sudo service apache2 start

Stoppen:

> sudo service apache2 stop

Neustarten:

> sudo service apache2 restart

Konfiguration aktualsieren:

> sudo service apache2 reload

Syntax der Konfiguration prüfen:

> apache2ctl configtest

Status anzeigen:

> sudo service apache2 status

Geladene Module anzeigen:

> apache2ctl -M

Modul aktivieren:

> sudo a2enmod

Modul deaktivieren:

> sudo a2dismod

Aktivieren eines virtuellen Hosts:

> sudo a2ensite <name>.conf

Deaktivieren eines virtuellen Hosts:

> sudo a2dissite <name>.conf

Layout der Konfiguration unter Ubuntu:

/etc/apache2/
|-- apache2.conf
|        -- ports.conf
|-- mods-enabled
|        -- *.load
|        -- *.conf
|-- conf-enabled
|        -- *.conf
|-- sites-enabled
|        -- *.conf

Standard Dokumentverzeichnis (Docoument root):

/var/www/html

Nützliche Links

Ubuntu documentation: HTTPD – Apache2 Webservice

Cheat-sheet: Apache2 Commands

NGINX: Command-line parameter -s

Mit dem Command-line paramter “-s” (signal) (ab version >= 0.7.53), kann der laufende Hauptprozess von nginx beeinflusst werden.

Lade die Konfigurationsdateien neu
Dieser Befehl lädt die Konfiguration neu, ohne den Betrieb von nginx
zu beinträchtigen.

nginx -s relaod

Danach werden neue Anfragen mit der neuen Konfiguration bedient.

Beendet nginx sofort

nginx -s stop

Beendet nginx “vorsichtig”

nginx -s quit

Keine neuen Anfragen werden mehr beantwortet, bestehende aber noch bedient.

Nützliche Links
nginx: command-line parameters
Starting, Stopping, and Restarting NGINX

Nginx: Alle http-Anfragen auf https umleiten

Soll eine Webseite nur noch über HTTPS zugänglich sein, müssen alle HTTP-Anfragen auf HTTPS umgeleitet werden. Dies kann bei Nginx mit rewrite oder return gemacht werden. Die Empfehlung der Nginx Community ist aber die Verwendung des return, wie hier in diesem Beispiel:


server {
listen 80;
server_name signup.mysite.com;
return 301 https://signup.mysite.com$request_uri;
}


Nützliche Links
Nginx Community: Pitfalls
Nginx Community: Converting rewrite rules
Server Fault: How to force or redirect to SSL

IIS: App_Offline.htm – .NET Webapplikation offline nehmen

Will man eine .NET Webapplikation mit einer neueren Version ersetzen, sollte man diese offline nehmen. Ansonsten werden die HTTP-Anfragen munter weiter bedient und dies führt dann oft zu unschönen Fehlermeldungen.

Eine elegante Methode ist die Datei “App_Offline.htm”. Wird ins Root-Verzeichnis der .NET Webapplikation eine Datei mit dem Namen “App_Offline.htm” kopiert, werden sämtliche neuen HTTP-Anfragen mit dem Inhalt dieser Datei beantwortet und zugleich wird die Webapplikation sowie deren “Application Domain” beendet.

Nach den Wartungsarbeiten oder dem Updaten wird die Datei “App_Offline.htm” einfach wieder gelöscht. Ist die Datei nicht mehr vorhanden, werden sämtliche Anfragen wieder wie gewohnt beantwortet.

Schritte um eine .NET Webapplikation zu aktualisieren:

  1. App_Offline.htm ins Root-Verzeichnis kopieren
  2. ein Backup der Dateien erstellen
  3. Webapplikation updaten
  4. App_Offline.htm aus dem Root-Verzeichnis löschen

Nützliche Links

Vipin Agarwal: App_Offline.htm, taking site down for maintenance
ScottGu’s Blog: App_Offline.htm
stackoverflow.com: explain the differences, in IIS, between application pools, worker processes and app domains

pfSense: Konfigurieren eines transparenten Squid Web Proxy mit Multi-WAN Links

Wichtiger Hinweis zur pfSense Version 2.1:

04.02.2014: Es scheint das Load Balancing mit aktiviertem Squid bei vielen gar nicht mehr funktioniert. Die Failover-Konfiguration funktioniert jedoch ohne Probleme mit dem Squid Proxy. Siehe pfSense Forum

Um einen Standort mit redundanter Internetanbindung auszurüsten, eignet sich die Firewall-Distribution pfSense 2.x perfekt. Die Distribution unterstützt standardmässig Load Balancing und Failover mit mehreren WAN-Anschlüssen. Mehr dazu findet man im pfSense Wiki unter Multi-WAN.

Wird der Web Proxy Squid nicht auf dem gleichen Host betrieben, sondern hinter der Firewall, bietet auch diese Konfiguration keine grossen Probleme. Den das LoadBalancing und Failover funktioniert gut.

In diesem Beitrag werde ich auf die Konfiguration eingehen, bei der Squid auf dem selben Host läuft. Im Web findet man sehr viele Beiträge zu diesem Thema. Es scheint für diese Lösung keine Standardkonfiguration zu geben. Je nachdem ob man zusätzliche Pakete installiert hat, kann die Konfiguration abweichen. Was bei einer Installation läuft, muss nicht zwangsläufig bei einer anderen funktionieren. Ich werde hier einfach meine Erfahrungen und Ergänzungen vorstellen, die ich beim Sichten der verschiedenen Anleitungen gemacht habe, bis ich eine funktionierende Konfiguration hatte. Dieser Beitrag soll kein vollständiges “Howto” sein, sondern nur die wichtigen Punkte hervorheben, die mir geholfen haben.

Schritt 1: Multi-WAN

Als erster Schritt muss die Multi-WAN Konfiguration, wie in der Anleitung beschrieben, erstellt und ohne Proxy getestet werden. Dabei sollten zusätzlich folgende wichtige Punkte beachtet werden:

Gateways Einstellungen

Anmerkung zur pfSense Version 2.0.3:

Unter “System->Routing->Gateways” sollte kein Gateway als “Default-Gateway” markiert sein. Es scheint als verwendet pfSense standardmässig den Gateway des WAN-Interfaces als “Default-Gateway”. (Beim Versuch das WAN2-Interface als “Default-Gateway” zu definieren funktionierte die Abfrage über Squid nicht mehr.)

Gateways Einstellungen
Gateways Einstellungen

Anmerkung zur pfSense Version 2.1:

Mit der Version 2.1 scheint das Definieren eines “Default-Gateway” auch bei mir wieder zu Funktionieren. Daher sollte unter “System->Routing->Gateways” ein Gateway als “Default-Gateway” markiert werden.

Unter “Diagnostics->Routes” kann die Routingtabelle eingesehen werden und dort findet man auch den Eintrag des “Default-Gateway”.

Routingtabelle
Routingtabelle

Ein weiterer wichtiger Punkt ist die Einstellung “Allow default gateway switching” welche aktiviert werden sollte. So wird beim Ausfall des WAN-Interfaces automatisch ein anderes Interface als “Default-Gateway” eingesetzt. Dies kann unter “System->Advanced->Miscellaneous” geändert werden.

Load Balancing Einstellungen
Load Balancing Einstellungen

DNS-Server Einstellungen

Bei den DNS-Server Einstellungen sollten pro Gateway mindestens ein DNS-Server eingetragen werden. Was auch nicht schaden kann, ist ein öffentlicher DNS-Server der über alle Interfaces erreichbar ist. Hier in diesem Beispiel wurde zusätzlich ein DNS-Server von Google angegeben. Eintragen kann man diese unter “System->General Setup”.

DNS-Server Einstellungen
DNS-Server Einstellungen

Firewall Rules

Zusätzlich zu den Firewall-Regeln die den Datenverkehr über den gewünschten Gateway oder die Gatewaygruppe leiten, muss noch eine eigene Regel für den DNS-Traffic des Squid Proxy erstellt werden.

DNS-Floating Rule
DNS-Floating Rule

Details der Floating-Rule:

  • Interfaces: Wan & Wan2
  • Direction: out
  • Protocol: TCP/UDP
  • Source: any
  • Destination: any
  • Destination Port: 53 (DNS)
  • Gateway: Wan1BalanceWan2 (Definierte Gatewaygruppe)

Schritt 2: Squid Konfiguration

Wurde die Multi-WAN Konfiguration erfolgreich getestet (Unterbruch simulieren der verschiedenen WAN’s, surfen funktioniert noch), kann mit der Konfiguration des Proxy-Server’s angefangen werden.

Dazu werden unter “Services->Proxy Server” die Interfaces ausgewählt bei denen die HTTP-Abfrage über den Proxy Server laufen sollen. Anmerkung: In manchen Anleitungen steht, man soll das “Loopback” Interface auch auswählen. Dies wird jedoch in dieser Konfiguration nicht verwendet, sondern führt nur zu Fehler bei den Proxy abfragen.

Squid Einstellungen Interfaces
Squid Einstellungen Interfaces

Als letzte Einstellung muss unter “Custom Options” die Zeile “tcp_outgoing_address 127.0.0.1;” eingetragen werden. Mit diesem Befehl schickt Squid sämtliche TCP-Anfragen wieder zurück an pfSense, wo dann die Pakete an den richtigen Gateway verschickt werden.

Squid Einstellung Custom Options
Squid Einstellung Custom Options

Zum Schluss

Nach diesen Einstellungen sollten nun alle HTTP-Anfragen die über den Squid Web Proxy gehen, auch vom Load Balancing und Failover Mechanismus von pfSense profitieren. Diese Konfiguration habe ich nun seit einiger Zeit im Einsatz und es scheint gut zu funktionieren.

Bei Webapplikationen welche die Anmeldeinformationen an eine IP knüpfen, kann das Load Balancing zu Probleme führen. Nach dem Anmelden wird man kurze Zeit später wieder abgemeldet. Das ist immer dann der Fall, wenn die Verbindung neu über einen anderen Gateway geht. Um diese Problematik zu minimieren, kann man eigene Floating-Rules definieren oder man verwendet die Option “Use sticky connections”. Diese Option sorgt dafür, dass eine bestehende Verbindung immer über denselben Gateway geleitet wird. Aktivieren kann man sie unter “System->Advanced->Miscellaneous”. (Siehe Screenshot “Load Balancing Einstellungen”)

Nützliche Links

pfSense: Erweitern mit Zusatzpaketen (Erweiterungen)
pfSense doc: Multi-WAN
Google Public DNS
pfSense 2.0.2 Multiwan will filter ssl (squid+squidGuard+Lightsquid)
PDF: Set-up transparent Squid Web Proxy with failover on multi-WAN links
default gateway switching concern
New HOWTO: pfSense Squid Web Proxy with multi-WAN links
pfSense Multi-WAN – How to really make it work
Öffentliche Nameserver in der Schweiz

pfSense: NTP-Server aktivieren / konfigurieren

Um bei allen Rechnern in einem Netzwerk die Zeit synchron zu halten, benötigt man einen Zeitserver. Bei der Firewall-Distribution pfSense ist standardmässig OpenNTPD installiert. OpenNTPD ist eine einfache Implementierung des “Network Time Protocol”, welche den einfachen Betrieb eines NTP-Client und NTP-Server ermöglicht.
In diesem Beitrag wird der OpenNTPD von pfSense als Netzwerkzeitserver verwendet. Die Firewall bezieht die Zeit bei einem offiziellen Zeitserver und beantwortet NTP-Anfragen von den verschiedenen lokalen Netzwerken. Diese Konfiguration vereinfacht die Verwaltung und minimiert die NTP-Abfragen gegen Aussen.

Netzwerk konfiguration
Netzwerk konfiguration

1. Konfigurieren des pfSense NTP-Client

Damit auf der Firewall die aktuelle Zeit eines offiziellen Zeitservers verwendet wird, muss dieser im Menü “System -> General Setup” konfiguriert werden. Hier in diesem Beispiel wird der offizielle Zeitserver für die Schweiz “ntp.metas.ch” verwendet.
Wichtig: Die richtige Zeitzone muss eingestellt sein!

Eintragen der NTP-Server
Eintragen der NTP-Server

2. Konfigurieren des pfSense NTP-Server

Damit NTP-Anfragen auch beantwortet werden, muss der OpenNTP-Deamon unter “Services -> OpenNTPD” aktiviert werden. Als Nächstes wird noch angegeben an welchen Interfaces (Netzwerke) eine NTP-Abfrage erlaubt wird.

OpenNTP Einstellungen
OpenNTP Einstellungen

Im oberen Beispiel sind NTP-Anfragen aus den Netzwerken LAN, DMZ und Gray1 erlaubt. NTP-Anfragen aus dem WAN-Interface werden ignoriert.

3. Konfigurieren der Server und Clients

Zum Schluss müssen die verschiedenen Server und Clients so konfiguriert werden, damit die Firewall als Zeitserver verwendet wird.

Nützliche Links:

pfSense
OpenNTPD
ntp.metas.ch
Informationen zum NTP – ntp.org