10 Jahre Purrucker Blog und ein moderneres Layout

dsc_9873Mein alter Technik-Blog feiert seinen zehnten Geburtstag. Somit hatte er ziemlich genau 10 Jahren das gleiche Layout. Im Internet ist das eine Ewigkeit. Außerdem störte mich zunehmend der für Smartphones und Tabletts nicht ganz optimale Aufbau der Menüs und Widgets. Deshalb habe ich den Blog auf ein neues und moderneres Layout mit einem Responsive Webdesign umgestellt. Damit ist der Blog jetzt auch optimal auf mobilen Geräten zu lesen.

Umleitung auf einen anderen DNS-Namen und erzwingen von HTTPS innerhalb eines VirtualHosts

Wenn man eine Webseite mit mehreren DNS-Namen betreibt, möchte man meistens nur ein SSL-Zertifikat für diese erwerben. Eine solche Webseite wird bei einem Apache Webserver zudem meistens innerhalb eines VirtualHost konfiguriert. Daraus ergibt sich somit die Anforderung, innerhalb eines VirtualHost bei einem Apache Webserver gleich zwei Weiterleitungen zu konfigurieren.

  1. Eine Weiterleitung von http://<hostname1>.<domain>.de auf http://<hostname2>.<domain>.de
  2. Eine Weiterleitung von  http://<hostname2>.<domain>.de auf https://<hostname2>.<domain>.de

Damit der Browser keine Warnmeldung ausgibt, muss dass Zertifikat für den richtigen DNS-Namen ausgestellt sein. Deshalb ist es sehr wichtig, dass die Weiterleitungen nicht gleichzeitig sondern nacheinander ausgeführt werden. Beim ersten Aufruf der Seite muss nur auf den zweiten DNS-Namen umgeleitet werden. Beim zweiten Aufruf der Seite (der dann ja schon über den zweiten DNS-Namen erfolgt) muss dann von HTTP auf HTTPS umgeleitet werden.

Die serverseitige Umleitung von einer URL auf die andere Erfolg bei Apache üblicherweise über das Modul mod_rewrite. Bevor man dieses verwendet, muss es aktiviert werden. Dies geschieht bei Debien oder Ubuntu mit den folgendem Befehl.

a2enmod rewrite

Danach muss der Apache neu gestartet werden, damit das Modul geladen wird. Dies erledigt man bei einem neueren Ubuntu z.B. mit dem folgenden Befehl.

service apache2 restart

Die Regel für eine Weiterleitung besitzt bei Apache sogenannte Flags. Diese legen die genaue Funktionsweise der Weiterleitung fest. Um eine Weiterleitung durch Ersetzen zu erreichen wird das Flag R benötigt. Das Flag R steht für Replace und bedeutet, dass Teile der URL durch etwas anderes ersetzt werden. Wenn die Weiterleitung zudem dauerhaft sein soll, ist bei dem Flag R zudem ein Grund 301 hilfreich. Dieser Grund signalisiert, dass die Weiterleitung dauerhaft sein soll. Das Flag wird dann als „R=301“ geschrieben.

Obwohl die Konfiguration für beide Weiterleitungen in der Konfiguration von demselben VirtualHost steht, darf nur eine zur Zeit ausgeführt werden. Dies wird durch das Flag L erreicht. Dieses Flag steht für Last und bedeutet, dass beim Greifen der Rewrite-Regel keine weitere Rewrite-Regel ausgeführt wird. Es wird also immer nur eine Regel pro Aufruf ausgeführt.

Zudem ist wichtig, dass als erstes die Regel für die Weiterleitung auf den ersten DNS-Namen kommt. Erst danach darf die Regel für die Weiterleitung auf HTTPS kommen.

Wenn man all diese Bedingungen beachtet, sollten Rewrite-Regeln wie folgt aussehen.

RewriteEngine on
RewriteCond %{HTTP_HOST}   ^hostname1\.domain\.de$ [NC]
RewriteRule   ^/(.*)$ http://hostname2.domain.de/$1  [R=301,L]
 
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

Weitere Informationen zum mod_rewrite gibt es auf den entsprechenden Webseiten beim Apache-Projekt unter http://httpd.apache.org/docs/current/mod/mod_rewrite.html oder https://httpd.apache.org/docs/current/rewrite/flags.html zu finden.

Wenn Server nach einem Neustart die Netzwerkkarten vertauscht haben

Ich hatte letztlich das Problem, dass sich Netzwerkkarten bei Linux und Windows nach einem Neustart immer wieder vertauschten. Da die Server dadurch über Netzwerk nicht mehr erreichbar sind und ausfallen, ist das natürlich sehr ärgerlich. Da ich jetzt gerade eine neuen Firewall auf Basis von Ubuntu Linux mit 9 Netzwerkkarten und 100 VPN-Tunneln eingerichtet habe, wollte ich das Problem auf jeden Fall verhindern. Deshalb habe ich das Problem noch mal genauer untersuch und viel Doku dazu gelesen. Jetzt ist mir klar warum das Problem auftritt und ich kann es zukünftig verhindern.

Ursache: Da die Betriebssysteme zum schnellen Booten alles parallel starten, kommt es beim Booten regelmäßig dazu, dass die Hardwaretreiber in anderer Reihenfolge geladen werden. Wenn man im Server zwei Netzwerkkarten mit unterschiedlichen Treibern hat, kann dabei die Reihenfolge vertauscht werden, in der die Treiber geladen werden. Da bei älteren Windows- und Linuxservern die Netzwerkkarten einfach nur anhand der Startreihenfolge durchnummeriert werden, kann es somit vorkommen, dass die IP-Konfiguratiuonen der Karten durcheinander gewürfelt werden.

Lösung bei neueren Betriebssystemen: Bei neueren Betriebssystemen wird das Vertauschen der Karten verhindert. Windows merkt sich inzwischen für welche Karte eine Konfiguration war und zählt bei neuen Karten einfach immer weiter hoch. Es bindet (vermutlich anhand der Mac-Adresse oder Seriennummer) die Konfiguration fest an eine Netzwerkkarte und vergibt eine bereits vergebene Nummer kein zweites mal. Deshalb hat man bei Windows auch machmal einen Netzwerkadapter 5 oder 6, obwohl aktuell nur eine Karte im Betriebssystem steckt. Bei Linux wird der Steckplatz der Karte mit in den Namen der Netzwerkkarte aufgenommen. Eine Netzwerkkarte auf PCI-Slot 2 heißt dann z.B. p2p1, wobei das p2 dann für den PCI-Slot 2 und das p1 für den ersten Port der Karte steht. Theoretisch kann man bei Linux also eine neue Karte in den gleichen Slot stecken und die Konfiguration sollte noch funktionieren.

Probleme bei der Virtualisierung mit Ubuntu 14.04 LTS und KVM

Nachdem Ubuntu 14.04 LTS jetzt schon über zwei Monate alt ist, habe ich die ersten Server migriert. Ich hatte gehofft, dass die meisten schlimmen Fehler inzwischen behoben sind und man das System ohne größere Probleme betreiben kann.

Als ich den ersten Server für Virtualisierung migrierte, erwies sich meine Annahme aber leider als falsch. Zunächst liefen die Gast-Betriebsysteme ohne Probleme und dank der Technik Hyper V von Microsoft auch viel schneller als vorher. Je nach Auslastung wurden sie aber zunehmend langsamer und stürzten nach 3 bis 12 Stunden ganz ab. Die Windows-Gäste standen dann im Bluescreen und die Linux-Gäste hatten eine Kernelpanik.

Wie sich zeigte gibt es im Linux-Kernel 3.13 von Ubuntu 14.04 wohl noch einige Bugs, die früher oder später für einen Absturz der Gast-Betriebssysteme sorgen:

Nach diversen erfolglosen Versuchen das Problem in den Griff zu bekommen, stieß ich auf einen Blog-Post von Peter Kieser. Dieser machte den Vorschlag, den erprobten Linux-Kenel 3.10 mit Langzeitsupport für Ubuntu 14.04 zu kompilieren. Dieser Kernel wird auch bei RedHat Enterprise Linux verwendet, ist für Virtualisierung erprobt und er löste alle meine Probleme! Und dies geht wie folgt (ggf. kann man natürlich auch einen neueren Patchlevel des 3.10er Kerbels verwenden):

apt-get -y install build-essential
cd /usr/local/src
wget https://www.kernel.org/pub/linux/kernel/v3.x/linux-3.10.46.tar.xz
tar -Jxf linux-3.10.46.tar.xz
cd linux-3.10.46
cp /boot/config-`uname -r` .config
make olddefconfig
make -j`nproc` INSTALL_MOD_STRIP=1 deb-pkg
dpkg -i ../*.deb
apt-mark hold linux-libc-dev

Außerdem machte Peter Kieser noch einige Tuning Vorschläge, die er auch durch den Vergleich mit RedHat Enterprise Linux gefunden hatte. Ich habe mir davon die Verwendung des e1000 Netzwerkkartentreibers bei den Windows-Gästen, die Einträge für Hyper V in der Konfig der Windows-Gäste, die Anpassung von Grub und die Einträge in der /etc/sysctl.conf abgeschaut.

Einträge für Hyper V in der Konfig der Windows-Gäste

In die Konfig der Windows-Gäste müssen – sofern noch nicht vorhanden – die folgenden Zeilen in den Abschnitt „features“ eingetragen werden:

  <hyperv>
    <relaxed state='on'/>
    <vapic state='on'/>
    <spinlocks state='on' retries='4096'/>
  </hyperv>

In die Konfig der Windows-Gäste gelangt man am einfachsten, wenn man in der virsh

edit <Name der virtuellen Maschine>

eingibt. Man landet dann mit einem vi in der Konfig und wenn man den vi beendet, wird die Konfig auch gleich richtig gespeichert.

Die Datei sollte nach den Änderungen etwa wie folgt aussehen:

<domain type='kvm'>
  <name>WKSNUE01</name>
  <uuid>cce892d2-8fee-3add-f25d-6a46b1f14268</uuid>
  <memory unit='KiB'>4194304</memory>
  <currentMemory unit='KiB'>4194304</currentMemory>
  <vcpu placement='static'>1</vcpu>
  <os>
    <type arch='x86_64' machine='pc-1.0'>hvm</type>
    <boot dev='hd'/>
  </os>
  <features>
    <acpi/>
    <apic/>
    <pae/>
    <hyperv>
      <relaxed state='on'/>
      <vapic state='on'/>
    </hyperv>
  </features>
  <clock offset='localtime'/>
  <on_poweroff>destroy</on_poweroff>
  <on_reboot>restart</on_reboot>
  <on_crash>restart</on_crash>
  <devices>
    <emulator>/usr/bin/kvm</emulator>
    <disk type='file' device='disk'>
      <driver name='qemu' type='qcow2'/>
      <source file='/daten/images/WKSNUE01.img'/>
      <target dev='hda' bus='ide'/>
      <address type='drive' controller='0' bus='0' target='0' unit='0'/>
    </disk>
    <controller type='ide' index='0'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/>
    </controller>
    <controller type='usb' index='0'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x2'/>
    </controller>
    <controller type='pci' index='0' model='pci-root'/>
    <interface type='network'>
      <mac address='52:54:00:14:8c:a5'/>
      <source network='default'/>
      <model type='rtl8139'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
    </interface>
    <serial type='pty'>
      <target port='0'/>
    </serial>
    <console type='pty'>
      <target type='serial' port='0'/>
    </console>
    <input type='tablet' bus='usb'/>
    <input type='mouse' bus='ps2'/>
    <input type='keyboard' bus='ps2'/>
    <graphics type='vnc' port='-1' autoport='yes'/>
    <sound model='ich6'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
    </sound>
    <video>
      <model type='vga' vram='9216' heads='1'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
    </video>
    <memballoon model='virtio'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/>
    </memballoon>
  </devices>
</domain>

Anpassung von Grub

In der Datei „/etc/default/grub“ sollten für den Linux-Kernel „Headline scheduler“, and „transparent hugepages“ eingeschaltet werden. Dies macht macht man in der Variable „GRUB_CMDLINE_LINUX_DEFAULT“. Die Zeile mit der Variable sollte dazu wie folgt aussehen.

GRUB_CMDLINE_LINUX_DEFAULT="elevator=deadline transparent_hugepage=always"

Damit die Anpassung aktiv wird muss man noch den folgenden Befehl eingeben.

update-grub

Einträge für die Datei /etc/sysctl.conf

kernel.sched_min_granularity_ns=10000000
kernel.sched_wakeup_granularity_ns=15000000
vm.dirty_ratio=10
vm.dirty_background_ratio=5
vm.swappiness=10

Das Tunneln von X11 über SSH bei Ubuntu 14.04 geht nicht

Zu meiner Überraschung funktionierte das Tunneln von X11 über ssh auf einem Ubuntu 14.04 Server nicht mehr. Schon beim Login über den Befehl

ssh -X <Hostname>

gibt es den Fehler „X11 forwarding request failed on channel 0“,
obwohl in der /etc/ssh/sshd_config der Eintrag „X11Forwarding yes“ gesetzt ist.

Auch eine Installation der der XServer Utils

apt-get install x11-xserver-utils

brachte keine Lösung und nicht einmal xclock lief.

Nach ein bisschen Suchen stellt ich fest, dass das Paket xauth fehlt. Wenn man dieses nachinstalliert funktioniert auch das Tunneln von X11 über SSH wieder.

apt-get install xauth

VPN-Anbindung eines Internetservers mit strongSwan 4.2

Bei mir kommt es immer häufiger vor, dass ein Webserver Zugriff auf sensible Dienste eines Servers im internen Netzwerk erhalten soll. Um diesen Zugriff so sicher wie möglich zu gestallten, sollte die dazu notwendige Netzwerkverbindung verschlüsselt werden. Also muss eine VPN-Verbindung her.

Bei Linux-Servern kann man diese Verbindung ganz einfach mit der Software strongSwan einrichten. Bei den meisten Linux-Distributionen ist das dazu nötige Paket enthalten und schnell installiert. Bei Ubuntu 12.04 geht dies z.B. ganz einfach mit dem folgenden Befehl:

sudo apt-get install strongswan

Um die software einzurichten ist noch ein geheimes Kennwort für den Verbindungsaufbau und eine Konfiguration für die VPN-Verbindung notwendig. Das Kennwort wird in der Datei /etc/ipsec.secrets festgelegt. Wenn der Internetserver die IP 144.133.122.111 und die Firewall des internen Netzwerkes die IP 143.132.121.110 hat, müsste die Datei die folgende Zeile beinhalten (das Kennwort sollte natürlich anders sein):

144.133.122.111 143.132.121.110 : PSK 'HierKommtEinGeheimesLangesKennwortHin'

Die Konfiguration der VPN-Verbindung erfolgt in der Datei /etc/ipsec.conf. Für eine Verbindung mit dem Namen InternesNetzwerk kommt der folgende Abschnitt in die Datei:

conn InternesNetzwerk
        left=144.133.122.111
        leftsubnet=144.133.122.111/255.255.255.255
        right=143.132.121.110
        rightsubnet=172.30.4.0/255.255.255.0
        leftid="144.133.122.111"
        rightid="143.132.121.110"
        ike=aes128-sha-modp1536,aes128-sha-modp1024,aes128-md5-modp1536,aes128-md5-modp1024,3des-sha-modp1536,3des-sha-modp1024,3des-md5-modp1536,3des-md5-modp1024
        esp=aes128-sha1,aes128-md5,3des-sha1,3des-md5
        ikelifetime=1h
        keylife=8h
        dpddelay=30
        dpdtimeout=120
        dpdaction=restart
        pfs=yes
        authby=secret
        auto=start
	keyexchange="ikev1"

Bei der Verbindung werden die zuvor schon genannten IP-Adressen von Webserver und Firewall verwendet. Ferner ist ein interner IP-Bereich 172.30.4.0/24 für das interne Netzwerk konfiguriert. Für die IPSec Verbindung wurde IKE in der Version 1, Dead Peer Detektion, Perfect Forward Seurity und einige andere übliche Einstellungen gesetzt. All diese Einstellungen müssen natürlich den jeweiligen Gegebenheiten angepasst werden. Außerdem müssen die IPSec Parameter denen der Firewall entsprechen.

Wenn auch die Firewall auf der Gegenseite eingerichtet ist, lässt sich die Konfiguration durch einen Neustart von strongSwan bzw. IPSec aktivieren.

sudo /etc/init.d/ipsec restart

Danach kann man sich mit dem Befehl

sudo ip xfrm state

oder dem Befehl

sudo ip xfrm policy

anzeigen lassen, ob ein Tunnel zustande gekommen ist. Eventuelle Fehlermeldungen sind wie immer in der Datei /var/log/syslog zu finden. Wenn man die letzen 50 Zeilen anzeigen lassen möchte also einfach den folgenden Befehlt eingeben:

tail /var/log/syslog -n 50

SPAM-E-Mails aus der Postfix-Queue löschen

Heute wurden mit einem geklauten Benutzerzugang über einen unserer Server innerhalb weniger Minuten ca. 10.000 SPAM-E-Mails verschickt. Ich habe den betroffenen Zugang natürlich sofort gesperrt, nachdem durch die Hohe Anzahl von E-Mails der Alarm ausgelöst wurde. Aber was macht man jetzt mit den ganzen E-Mails in der Queue von Postfix?

Durch eine Analyse der E-Mail-Adressen der Empfänger in der Ausgabe des Befehls mailq zeigte sich, dass die E-Mail-Adressen eine bestimmte Systematik hatten. Die meisten enthielten das word admin. Durch die Kombination von ein paar Unix-Befehlen konnte ich deshalb die meisten SPAM-E-Mails löschen, bevor sie versendet wurden. Hier der Befehl, welchen ich dazu verwendet habe:

mailq | awk 'BEGIN { RS = "" } / admin@.*$/ { print $1 }' | tr -d '*!' | postsuper -d -

Weitere Kundendatenbank in OTRS einbinden

Bei Help Desk Software ist es oft sinnvoll auf mehrere Kundendatenbanken zuzugreifen. Dies ermöglicht einem z.B. die Kunden aus dem hauseigenen ERP-System zu verwenden, ohne dazu doppelte Datenhaltung zu betreiben oder komplizierte Replikation-Mechanismen zu verwenden. Die flexible Help Desk Software und IT-Service Management-Lösung OTRS bietet einem deshalb in der aktuellen Version 3.2 die Möglichkeit bis zu zehn weitere Kundendatenbanken anzuschließen.

Um eine weitere Kundendatenbank anzubinden braucht man in der Datei Kernel/Config.pm nur ein Objekt $Self->{CustomerUser2} anlegen und in diesem die nötigen Einstellungen für den Zugriff auf die weitere Datenbank vornehmen. Nähere Informationen dazu sind in der Dokumentation auf der Webseite http://doc.otrs.org zu finden. Im folgenden eine Beispielkonfiguration für eine Anbindung einer MySQL-Datenbank mit einem iso-8859-1 Zeichensatz. (Achtung! Bei Verwendung müssen hier natürlich mindestens Host, Datenbank, Tabelle, Benutzer und Passwort angepasst werden.)

# CustomerUser (customer database backend and settings)
$Self->{CustomerUser2} = {
    Name => 'Database Datasource Kunden2',
    Module => 'Kernel::System::CustomerUser::DB',
    Params => {
            DSN => 'DBI:mysql:database=customerdb;host=customerdbhost',
            User => 'dbbenutzer',
            Password => 'dbpasswort',
            Table => 'customer_user',
            SourceCharset => 'iso-8859-1',
            DestCharset => 'utf-8',
            CaseSensitive => 0,
        },
# customer unique id
CustomerKey => 'login',
 
# customer #
CustomerID => 'customer_id',
CustomerValid => 'valid_id',
    CustomerUserListFields => ['first_name', 'last_name', 'email'],
    CustomerUserSearchFields => ['login', 'last_name', 'customer_id'],
    CustomerUserSearchPrefix => '',
    CustomerUserSearchSuffix => '*',
    CustomerUserSearchListLimit => 250,
    CustomerUserPostMasterSearchFields => ['email'],
    CustomerUserNameFields => ['title','first_name','last_name'],
    CustomerUserEmailUniqCheck => 1,
#    # show not own tickets in customer panel, CompanyTickets
#    CustomerUserExcludePrimaryCustomerID => 0,
#    # generate auto logins
#    AutoLoginCreation => 0,
#    AutoLoginCreationPrefix => 'auto',
#    # admin can change customer preferences
#    AdminSetPreferences => 1,
#    # cache time to live in sec. - cache any database queries
#    CacheTTL => 0,
#    # just a read only source
#    ReadOnly => 1,
    Map => [
        # note: Login, Email and CustomerID needed!
        # var, frontend, storage, shown (1=always,2=lite), required, storage-type, http-link, readonly, http-link-target
        [ 'UserTitle',      'Title',      'title',      1, 0, 'var', '', 0 ],
        [ 'UserFirstname',  'Firstname',  'first_name', 1, 1, 'var', '', 0 ],
        [ 'UserLastname',   'Lastname',   'last_name',  1, 1, 'var', '', 0 ],
        [ 'UserLogin',      'Username',   'login',      1, 1, 'var', '', 0 ],
        [ 'UserPassword',   'Password',   'pw',         0, 0, 'var', '', 0 ],
        [ 'UserEmail',      'Email',      'email',      1, 1, 'var', '', 0 ],
 
#        [ 'UserEmail',      'Email', 'email',           1, 1, 'var', '$Env{"CGIHandle"}?Action=AgentTicketCompose&ResponseID=1&TicketID=$Data{"TicketID"}&ArticleID=$Data{"ArticleID"}', 0 ],
        [ 'UserCustomerID', 'CustomerID', 'customer_id', 0, 1, 'var', '', 0 ],
 
#        [ 'UserCustomerIDs', 'CustomerIDs', 'customer_ids', 1, 0, 'var', '', 0 ],
        [ 'UserPhone',        'Phone',       'phone',        1, 0, 'var', '', 0 ],
        [ 'UserFax',          'Fax',         'fax',          1, 0, 'var', '', 0 ],
        [ 'UserMobile',       'Mobile',      'mobile',       1, 0, 'var', '', 0 ],
        [ 'UserStreet',       'Street',      'street',       1, 0, 'var', '', 0 ],
        [ 'UserZip',          'Zip',         'zip',          1, 0, 'var', '', 0 ],
        [ 'UserCity',         'City',        'city',         1, 0, 'var', '', 0 ],
        [ 'UserCountry',      'Country',     'country',      1, 0, 'var', '', 0 ],
        [ 'UserComment',      'Comment',     'comments',     1, 0, 'var', '', 0 ],
        [ 'ValidID',          'Valid',       'valid_id',     0, 1, 'int', '', 0 ],
    ],
    # default selections
    Selections => {
        UserTitle => {
            'Mr.' => 'Mr.',
            'Mrs.' => 'Mrs.',
        },
    },
};

ISPConfig: Upgrade von Ubuntu 10.04 auf 12.04

Ich habe heute mal einige Server die ich mit ISPConfig (aktuell Version 3.0.5.2) verwalte auf Ubuntu 12.04 aktualisiert. Nachdem Ubuntu 12.04 nun ziemlich genau ein Jahr draußen ist, war die Zeit nach meiner Meinung reif für ein Upgrade.

Das Upgrade lief auch ohne größere Probleme durch. Ich habe aber bei MySQL aus Kompatibilitätsgründen wieder MyISAM als Standard-Tabellentyp eingestellt. Dies kann mit der Zeile

default-storage-engine = MyISAM

in der Datei /etc/mysql/my.cnf bewerkstelligt werden.

Des weiteren hat Postfix ein bisschen rumgezickt. Beim starten hat es einige Zeilen in der main.cf und master.cf angemaul, die nicht mehr unterstützt werden. Diese kann man aber einfach auskommentieren. Außerdem lief die SASL-Authentifizierung von Postfix nicht mehr. Deshalb konnte man keine E-Mails per Authentifizierung verschicken. Die Lösung des Problems wird im Launchpad unter der folgenden URL aber schon beschrieben: https://bugs.launchpad.net/ubuntu/+source/cyrus-sasl2/+bug/875440/comments/34. Offensichtlich hat sich hier in der Schreibweise einiger Parameter etwas geändert. Wenn man die Datei /etc/postfix/sasl/smtpd.conf wie folgt abändert, läuft es wieder:

pwcheck_method: saslauthd
mech_list: plain login pam
allow_plaintext: true
auxprop_plugin: sql
sql_engine: mysql
sql_hostnames: 127.0.0.1
sql_user: [entfernt]
sql_passwd: [entfernt]
sql_database: dbispconfig
sql_select: select password from mail_user where login = '%u@%r'

Die wichtigsten URL Escapecodes

Da ich in der Vergangenheit immer wieder im Internet gesucht habe, schreibe ich mir hier mal die wichtigsten URL Escapecodes auf. Ich hoffe das hilft auch anderen weiter.

  • SPACE = %20
  • < = %3C
  • > =%3E
  • # = %23
  • % = %25
  • { = %7B
  • } = %7D
  • | = %7C
  • \ = %5C
  • ^ = %5E
  • ~ = %7E
  • [ = %5B
  • ] = %5D
  • ` = %60
  • ; = %3B
  • / = %2F
  • ? = %3F
  • : = %3A
  • @ANTISPAM@ = %40
  • = = %3D
  • & = %26
  • . = %2E
  • ! = %21