Mail-server-upgrade to Opensuse Leap 15 – and some hours with authentication trouble …

Some of my readers know that the mail server in my private LAN resides in an encrypted KVM/qemu guest. It provides IMAP- and SMTP-services to mail-clients - and receives emails from several hosted servers on the Internet via a fetchmail system in a DMZ. It was/is my policy that any access to a mail service account on my private mail server requires authentication against user entries on a separate LDAP-server. The accounts the IMAP/SMTP-service-daemons deal with are not to be confused with Linux user accounts: On the mail server NO Linux user accounts are required for mail handling. I regard the absence of standard Linux user accounts on the mail-server as a small, but effective contribution to security. No mail user can login into the mail server as a Linux user. Nevertheless authentication for the use of mail services is required.

Upgrade top Leap 15 resulted in unusable mail services

The manual upgrade of the mail server system from OS Leap 42.3 to Leap 15 seemed to work perfectly. I got no serious warnings. As root I could login to the virtual KVM guest via ssh - and systemd had started all required services: Fetchmail operated on external servers in the DMZ and transferred new mails to the upgraded mail server. There my postfix queues and secondary services for virus and spam checks seemed to work perfectly. Regarding IMAP I could also see that new entries for new mails appeared in various email accounts (more precisely: in related spool directories). Everything looked great ...

However, the big surprise came pretty soon: No mail user could login to the IMAP-service - neither with Kmail, nor Mutt, nor Thunderbird. Access to the SMTP service for sending email was not possible either. System messages appeared on the GUIs saying that there was an authentication error. A very unpleasant situation which required analysis ....

In the meantime I had to start a backup copy of the old mailserver guest installation. On this front
virtualization proved its strengths and simplicity - I had made a copy of the whole KVM guest before the upgrade and just had to include the copy as a virtualization domain into the KVM setup of the virtualization host. But, as the upgraded server had already processed some new mails, I needed to transfer these mails between the servers and reconstruct and reindex some IMAP accounts ... A simple, but a task which can be done by some scripts ....

Error analysis

It took me quite a while to figure out where the origin of the upgrade problem was located. I first checked my local firewall protocols both on the mail server and on the LDAP server. Nothing special there ... Then I checked the LDAP access protocols - there were successful data requests from various systems - but astonishingly not from the mail server. So it seemed that the mail services did not even try to authenticate their users ... strange ....
I then created a new IMAP test user based on a new local Linux user account, i.e. with an entry in "/etc/passwd" and "/etc/shadow". Guess what? This user could work without any problems. So, obviously the communication of the mail services with the LDAP service for authentication was not triggered or failed in a strange way. I, therefore, tried a manual data request to the LDAP server from the mail server - and got a perfect answer. So, there seemed to be no fundamental problem with the required sssd-daemon and client-configurations. What else was wrong? A bit of despair was in the air ...

The role of PAM in the game

Then I tried to remember what I had done in the past to separate the email accounts from the Linux user accounts. Over the last years I had actually forgotten how I had treated this problem. After some reading in old diaries my attention eventually turned to PAM ...

The PAM-layer offers Linux admins the possibility of fine-tuning access/authentication conditions for the usage of a service; among other things you can request certain PAM-modules to authenticate a user via given credentials against defined resources. A sequential series of required, sufficient or optional criteria can be set up. ( When a service needs additional Linux user account information during a session NSS can in addition request information from name resolution backends as "/etc/passwd". However, this is NOT required for mail services. )

Linux mail services often use the SASL-framework and the saslauthd daemon to perform authentication. SASL can communicate with a variety of authentication backends directly - but it can also use PAM as an intermediate layer. And, in fact, I had used PAM to access my independent LDAP-server with mail account credentials via the PAM-module for SSSD.

I have described my simple approach in a previous article
Unfortunately, only in German. I, therefore, summarize the basic ideas shortly (see also the graphics in the referenced article).

The things one has to do to force IMAP and/or a SMTP services to use LDAP, but other services to use local authentication resources is:

  • We direct local login-services, ssh-services, etc. on the server via PAM to local resources, only.
  • We eliminate any UIDs corresponding to email account names from local resources as "/etc/passwd" and "/etc/shadow" (and NIS if used).
  • We do not create any local home-directories for email account names.
  • We eliminate LDAP as a usable NSS resource from nsswitch.conf; i.e. we eliminate all LDAP references there.
  • We setup special PAM files in "/etc/pam.d" for the IMAP-service and the SMTP-service. These files will necessarily include pam-modules for the "sss"-service (
  • We select entries on the LDAP server for users which for any reasons shall NOT or NO LONGER get access to the mail service accounts, set the "host"-attribute for these entries and configure sssd to use the host-attribute. Or deny certain user names access to the IMAP-service by the help of IMAP -configuration files; cyrus e.g offers the maintenance of a list "userdeny_db".

This strategy worked very conveniently already on an Opensuse 12.3 platform. Examples for the required special files "/etc/pam.d/imap" and "/etc/pam.d/smtp" are given in the article named above. The mix and sequence of the statements there is due to the fact that locally defined system users as "cyrus" must get access to the IMAP-service, too.

What had happened during the Leap 15 upgrade?

My configuration had survived multiple upgrades of the virtualized server in the past. But not the one to Leap 15! What had happened?

After having remembered the importance of the PAM configuration, I eventually had a look into the directory "/etc/pam.d" on the upgraded system and compared it to the respective directory on the original system. Whereas during previous upgrades "personal" PAM configuration files for services had been respected, the upgrade to Leap 15 simply had removed my PAM configuration files for SMTP and IMAP - without a backup! Incredible, but true! Actually and astonishingly, the contents of some other standard PAM files had been transferred to a backup ....

A restoration of my PAM files for the mail services lead to an immediate success - authentication for the access of mail accounts on the upgraded server was possible again. Some hours in the hell for Linux admins came to an end.


Never (!) trust a standard upgrade of a whole Linux system procedure to keep configuration files in "/etc/pam.d" untouched. Keep an admin or system diary for unusual approaches. And - of course: Full backups of critical systems before backups are a MUST ....

Full encryption with LUKS (SHA512, aes-xts-plain64) – grub2 really slow ….

My German readers know that I work on an article series regarding a reasonable full encryption of customer related Linux laptops and virtual machines with dm-crypt/LUKS. Whilst experimenting with different configurations I found that all my naive assumptions regarding the boot time of fully encrypted systems on standard laptops were wrong.

The boot manager for Linux - Grub2 - can lead to unacceptable long boot times (> n * 10 secs) - despite much smaller and reasonable values for the time required by the kernel to open encrypted devices. Delay factors during boot of more than 7 to 8 are possible and have to be taken into account during the encryption setup.

In my case Grub2 appears to be dead slow regarding a distinct factor which determines the time required during a first boot phase until the graphical Grub menu with choices for bootable installations gets displayed. The time for later boot phases (loaded kernel with initrd-support, access to encrypted volumes by the kernel) is much, much shorter.

A quick test showed that Grub2 is inefficient with respect to the SHA512 and not to the core and aes-based symmetric decryption algorithm.


DSGVO – wir stoppen Google-Analytics nach einem Test des Verhaltens unserer Leser zu Cookie- und GA-Hinweisen …

Liebe Leser des Blogs,
wie viele andere schlagen wir uns gerade mit dem Thema DSGVO (bzw. EU GDPR) herum. Ein Thema ist dabei Google Analytics, kurz [GA]. Auch wir haben bislang in diesem Blog ein Plugin verwendet, um mittels GA feststellen zu können, wie oft unser Blog besucht wird und welche Artikel unsere Besucher am meisten interessieren. Wir haben dies bislang für legitim und auch sinnvoll gehalten. Nun hat sich unsere Meinung aber geändert.

Wie reagiert der Besucher von Websites auf Cookies und Google Analytics, wenn er die Wahl hat?

Das Gute an der DSGVO (EU GDPR) ist, dass man sich auch als Webseiten-Betreiber ein paar unangenehmen Fragen stellen muss. Eine Frage, die ich selber immer wieder verdrängt habe, ist:

Wie reagiert eigentlich der/die Besucher/in einer Web-Site, wenn er/sie entscheiden kann, ob Cookies verwendet werden und ob sein Verhalten mittels GA auf der Site getrackt wird oder nicht?

Wir machen uns dabei folgenden Aspekt zu wenig klar: Web-Site-Betreiber leisten ja eigentlich dem geschäftsbedingten Daten-Sammeltrieb von Google Vorschub, indem sie/wir vermeintlich zum eigenen Vorteil einen attraktiven und gut funktionierenden Service von Google nutzen. Gerade in im Falle von Google Analytics geht es aber nicht nur um unsere eigenen Daten. Die nachfolgende Frage drängt sich auf:

Kann man testen, wie der User oder Leser auf Google Analytics reagiert, wenn er rechtzeitig informiert wird - und eine Option hat? Antwort: Ja, das kann man - und sollte es im Vorfeld der DSGVO auch tun. Wir haben eine Woche lang - eher unfreiwillig - einen solchen Test gemacht. Hier ist unsere Geschichte, die uns selbst gestern ein wenig ungläubig auf GA-Daten zum Blog blicken ließ ...

Erfahrung mit unseren Lesern, einem Cookie/Google-Analytics-Banner und GA-Opt-Out im Verlauf einer Woche

Am 01. Mai habe ich mich aufgrund der DSGVO mit verschiedenen Plugins und Cookie-Bannern auseinandergesetzt. Zudem mit Plugins, die ein Google-Analytics-Opt-Out durch den Leser ermöglichen. In den Blog integriert wurde dann einerseits ein Cookie-Banner-Plugins der italienischen Regierung, das wir als gut erachtet hatten (s.u.). Auf diesem Banner wiesen wir auf Google Analytics hin. Zusätzlich kam auch ein Opt-Out-Plugin bzgl. Google Analytics zum Zuge.

Eine Woche später mussten wir folgenden, für uns doch ziemlich überraschenden Effekt konstatieren:

Laut Auswertung der "Google Analytics"-Statistik ging die Anzahl der Besucher dieses Blogs am 02.05. angeblich von durchschnittlich 150 Besuchern pro Tag schlagartig auf 3 oder 4 pro Tag herunter. Tendenz im Laufe der Woche fallend. Gestern war es nur noch 1 Besucher am ganzen Tag.

Irgendwie nicht lustig ... Ein wenig Studium des Programmablaufs machte aber deutlich, dass das ein Scheineffekt war/ist - allerdings ein interessanter. Denn ein Gegentest zeigte, dass die veränderte Google-Analytics-Statistik etwas über die Haltung und Meinung unserer Besucher aussagt.

Die Auswirkung restriktiver und besucher-freundlicher Cookie-Banner

Wir gehen nach einer zwischenzeitlichen Analyse davon aus, dass der beobachtete GA-Effekt auf eine gewollte Wechselwirkung des Cookie-Banner-Plugins mit dem üblich "Google Analytics"-Skript in den Webseiten zurückzuführen ist. Das sog. "EU-Cookie-Law"-Plugin bietet nämlich als eines von wenigen eine Option an, die ich für absolut fair und richtig halte und deshalb aktiviert hatte:

Das Cookie-Banner-Plugin unterbindet in Webseiten integrierte Skripte, die ja potentiell weitere Cookies setzen und lesen könnten, so lange, bis eine explizite User-Zustimmung zur Cookie-Nutzung erfolgt ist.

Das verhindert technisch nun auch nicht jede Art von Benutzer-Analyse: Bereits der PHP-Code der Seite könnte ja Session-Cookies und auch (verschlüsselte) Cookies mit weiteren tiefergehenden Informationen zum Besucher aufgrund von Browser-Informationen setzen und zumindest im Zuge von Seitenwechseln bestimmte Dinge auswerten. Viele WordPress-Plugins und Themes etwa setzen eigene (relativ harmlose) Cookies zur dynamischen Ablaufsteuerung, z.B. im Zusammenhang mit Bildgalerien. Detailliertere Auswertungen des Nutzerverhaltens setzen aber Javascript oder andere Skripts am Client (Browser/App) und bestimmte Cookie-Typen mit unterschiedlichen Informationen voraus.

Deshalb bietet das Plugin der italienischen Regierung die Option, cookie-fähige Skripte zu unterbinden, die auf der Client-Seite - also im Browser - ausgeführt werden. Das betrifft u.a. JS, Flash. Und natürlich Google Analytics; kaum überraschend setzt das GA-Skript ja gleich mehrere (3) Cookies.

Fairness gegenüber dem Besucher von Webseiten

Aus unserer Sicht spiegelt die Option des italienischen Cookie-Banners den Geist der DSGVO wieder... Der User soll nicht nur informiert werden, sondern auch ein wenig Einfluss auf das Geschehen haben, wenn seine Daten betroffen sind.

Stimmt der Besucher des Blogs durch Klicken auf den angebotenen Button zu, so ist das alles kein Problem. Das Script für Google Analytics läuft dann regulär ab; das Verhalten des Users auf der besuchten Seite wird direkt registriert und kann vom Inhaber der Seite auch live mitverfolgt werden. Was aber, wenn der Besucher den Button bzw. das gesamt Cookie-Banner aus guten Gründen ignoriert? Eine Folge ist, dass das Mini-Skript von Google Analytics dann nie zum Zuge kommt ....

Der vorsichtige User ignoriert Cookie-Banner systematisch ...

Nun ist das bewusste Ignorieren des Cookie-Banners eine völlig verständliche Reaktion. Ich selbst wähle dieses Handlungsmuster laufend - u.a. und im Besonderen auch auf Seiten von Suchmaschinen-Herstellern. Ein Motiv ist dabei:
Warum sollte ich etwas zustimmen, das nicht explizit einer Wahl sondern eher einer reinen Kenntnisnahme entspricht? Und warum sollte ich etwas zustimmen, bei dem ich die Folgen nicht abschätzen kann?

Implizit müsste ein derart vorsichtiger Benutzer dabei davon ausgehen können, dass dann eben auch nichts außer einfachen Session-Cookies zum Tragen kommt. In Wirklichkeit ist dies leider nur bei einem kleinen Teil von Web-Sites der Fall. Das Cookie-Informations-Banner wird meist nur aus Alibi-Gründen angezeigt; das Nicht-Anklicken des OK-Buttons hat vielfach keine Wirkung im Sinne einer Cookie-Blockade. Im Fall unseres Cookie-Banners war das jedoch anders.


Ich habe am gestrigen und heutigen Nachmittag dann mal getestet, was passiert, wenn ich die Sperre von Scripts über das Cookie-Banner wieder deaktiviere. Na, ihr erratet es schon:

An beiden Tagen wurden sofort wieder etwa 15 Besucher des Blogs innerhalb von jeweils ca. 30 Minuten Testzeitraum registriert. Das konnte ich live in unserem GA-Account verfolgen. Am Nachmittag ist das auf unserem Blog Durchschnitt. Damit ist die Theorie wohl richtig, dass unsere (intelligenten!) Besucher das Cookie-Banner entweder schlicht ignorieren oder systematisch eine ebenfalls angebotene Opt-Out-Alternative gewählt haben.

Konsequenz 1

Eigentlich sind Banner,

  • die ein Zustimmung zu Cookies anfordern und
  • die zulassen, dass clientseitig ablaufende Skripts im Hintergrund mehr als einfache Session-Cookies zur Steuerung des Seitenablaufs setzen, wenn der User das Banner ignoriert,

eine Farce. Wie gesagt: Ich selbst erwarte wider besseren Wissens, dass keine Zustimmung durch Button-Klick bedeutet, dass auch nichts passiert.

Aus meiner Sicht dienen die von GA dynamisch gesetzten Cookies jenseits meiner persönlichen statistischen Interessen aber auch weiterreichenden Anliegen von Google (s.u.)! Es wäre also gegenüber unseren Lesern nicht fair, das GA-Skript nicht zu unterbinden, wenn der User das Cookie-Banner und seinen Button absichtlich ignoriert.

Konsequenz 2

Ignorieren die meisten unserer Besucher aber das Cookie-Banner tatsächlich absichtlich, so wird bei fairer Einstellung des Cookie-Banners Google Analytics für uns, vermutlich aber auch für andere völlig nutzlos. Das hat uns die Erfahrung der letzten Woche eindeutig gezeigt.

Die "neuen" Google-Bedingungen für die Nutzung von Google Analytics

Hinzu kam, dass man aufgrund der DSGVO als Nutzer von Google Analytics nun ja auch den neuen Google-Bedingungen für die Nutzung von Analytics zustimmen muss. Hmmmm - ausgedruckt sind das 13 Seiten, die Google da unverschämterweise nur in Form eines kleinen Popups anbietet, bei dem man sich dann den Mittelfinger wund-scrollt. Allein das sollte einen schon misstrauisch machen.... Zudem erhielt ich die neuen Nutzungsbedingungen in unserem Google-Account nur auf Englisch angeboten - obwohl Google natürlich sehr wohl erkannte, dass ich mich aus Deutschland auf der GA-Verwaltungsseite angemeldet hatte.

Ich muss nach einer längeren Lektüre leider sagen,

  • dass ich die neuen (englisch verfassten) Bedingungen mindestens genauso skeptisch sehe wie die von mir in diesem Blog zuletzt so kritisierten Nutzungsbedingungen von Facebook
  • und dass ich die Google-Bedingungen z.T. - wegen der ausgesprochen verklausulierten Anwaltssprache - als noch unverständlicher einstufe.

Es wird Leser meines früheren Artikels zu Facebook nicht wundern, dass auch bei Google eine Art "third-party-partners" (s. den Link unten) auftaucht - selbige heißen bei Google aber "Third-Party-Subprocessors" und "Affiliates". Die spielen natürlich auch im Kontext der GA-Daten-Erfassung eine interessante Rolle. Letztere wiederum lässt sich allerdings nur über weitere sekundäre (und lange) Dokumente erschließen. Ehrlich: Das nervt!... schon auf Englisch, es würde das aber sicher auch auf Deutsch tun.

Mir scheint, die EU GDPR hat offenbar durchaus das Potential, das Geschäftsmodell bestimmter Informationskraken durch eine bessere Information von Nutzern in Frage zu stellen - und die Anwälte von Facebook, Google und Co. leisten nun ganze Arbeit, um Otto-Normal-Verbraucher mit wirklich schwer verdaulichen Text-Kaskaden von bestimmten Schlussfolgerungen abzuhalten. Gewollt oder nicht ...

Im Fall von Google Analytics stößt man dann noch auf eine spezielle Anforderung: Man muss zustimmen, dass Google das Recht hat, Daten aus dem EWR/EU-Raum heraus zu befördern - speziell in die USA. Ich habe das mit meinen begrenzten Englisch-Kenntnissen zumindest so verstanden und meine, Punkt 10.1 ff. der neuen Google-"Terms" lässt hier keine andere Interpretation zu. Dieser Datentransfer dient dann u.a. der Versorgung von "Googles "Affiliates and Subprocessors" in solchen Staaten außerhalb der des EWR/EU-Raums. Dem soll ich als Google-"Customer" zwingend zustimmen.

Tja Leute, warum sollte ich das angesichts einer sich abschottenden amerikanischen Wirtschaft eigentlich tun?

Und ehrlich gesagt, die Termini "Affiliates" und "Subprocessors" gefallen mir gar nicht ... speziell, wenn ich für ein besseres Verständnis noch weitere Papiere und Bedingungen studieren soll. Durch einen späteren Abschnitt und durch Appendix 1 wird übrigens klar, dass die exportierten Daten dann natürlich auch die erfassten Daten der Besucher einer Website umfassen. Zumindest nach meinem Verständnis. Vielleicht sollte google dazu mal Stellung beziehen.

Klar auch, dass in dem Augenblick, wo die Daten Server auf amerikanischem, chinesischem, russischem oder sonstigem Nicht-EU-Boden erreichen, dort womöglich der lokalen Rechtsprechung bzgl. des Umgangs mit unseren/euren Daten unterliegen.

Konsequenz 3

Die neuen Nutzungsbedingungen von Google kann ich nicht guten Gewissens und schon gar nicht ohne vorherige Anwaltskonsultationen mittragen. Der ganze Text ist eine einzige Zumutung. Entscheidend ist dabei aber, dass es hier nicht nur um meine, sondern auch um eure Daten geht.

Liebes Google: Verlangt vom Nutzer eures GA-Services in Zukunft lieber eine angemessener Gebühr und haltet dafür die Daten dann ausschließlich auf EU-Servern vor. Und gebt sie (dann) explizit und grundsätzlich nicht an "Affiliates und Third Party Sub-Processors" weiter! Bitte sucht euch gefälligst auch Übersetzer, die das zugehörige Anwalts-Englisch in klare, für jeden Kunden nachvollziehbare Landessprache übersetzen.

Es ist für mich - wie bei Facebook auch - leider überhaupt nicht nachvollziehbar, was mit meinen und den erfassten Daten meiner Leser passiert, sobald diese Daten - offenbar absehbar und gewollt - die EU verlassen. Sorry, aber dabei gehe ich angesichts der Entwicklung in einigen Staaten weg von demokratisch verfasster Rechtsstaatlichkeit zunächst mal vom Schlimmsten aus. Gegenüber Eingriffen staatlicher Eingriffen nützt nämlich auch eine ISO 27000 nichts, auf die Google hinweist.

Da mein Cookie-Banner aus rechtlichen Gründen natürlich auch auf Google Analytics hinweisen müsste, sehe ich als Voraussetzung einer nachfolgenden aktiven Zustimmung des Lesers auch das Verständnis der Folgen einer Akzeptanz von GA-Cookies als zwingend notwendig an. Nun verstehe ich aber nicht mal selbst Googles Bedingungen ... Das kann ich meinen Lesern nicht zumuten.

Der einwöchige Testlauf hat zudem deutlich gezeigt, dass zumindest die Leser dieses Blog die angeforderte explizite Zustimmung wohl aus guten Gründen nicht geben wollen und werden - was ich sehr gut verstehe!


GA wird nach der DSGVO faktisch völlig sinnlos, wenn man mit seinen Lesern und potentiellen Kunden fair umgehen will - und eine explizite Zustimmung zu Cookies zur Bedingung für das Ablaufen wenn GA-Scripts macht. Ist vielleicht gut so, denn die Folgen der neuen Bedingungen für die Nutzung von GA kann ein Webseitenbetreiber eigentlich nicht ohne aktives Involvieren seiner Leser mittragen. Und meine Leser haben mir im Laufe der letzten Woche hierzu eine eindeutige Antwort gegeben.

Deshalb stellen wir Google Analytics auf diesem Blog im Interesse unserer Leser ab. Das entsprechende Konto bei GA wurde gekündigt. Leider behält sich Google das Recht vor, im Sinne von staatlich verordneter Datenvorratshaltung die bislang erfassten Daten noch eine Weile vorrätig zu behalten. Auch ein interessanter Punkt - aber ich mag meinen Blutdruck nicht weiter strapazieren ...

Gerne könnt ihr mich per E-Mail zu diesem Thema kontaktieren.

Hinweis: Dieser Beitrag wurde am 08.05.2018 und 15.05.2018 textlich und inhaltlich bearbeitet. Am 15.05. wurden zudem etliche Rechtschreibfehler beseitigt.
Eränzung 15.05.2018: Möglicherweise fand der Beitrag ja auch bei Google-Mitarbeitern Interesse. So hatte ich am 07.05.2018 und am 08.05.2018 mehrfach Zugriffe auf mein Xing-Profil von Google-Mitarbeitern zu verzeichnen. Anonym natürlich ... Liebe Leute von Google, wenn es etwas zu sagen oder zu besprechen gibt oder ich mich gar bzgl. der neuen Nutzungsbedingungen getäuscht haben sollte, dann schreibt mich bitte unter Nennung von Namen an. Ich bin auch gerne bereit, eure Meinung hier zu präsentieren.


Leaving Facebook … – I
Bruce Schneier über Facebook, Cambridge Analytica und die Daten-Sammel-Industrie