DSGVO – Löschung von Konten in diesem Blog

Posted on by

Liebe Leser dieses Blogs, dear readers of this blog,

Es gibt einige registrierte Leser dieses Blogs. Wir haben heute im Vorfeld der DSGVO die zugehörigen Konten bereinigt und einige gelöscht. Die entsprechenden User wurden per E-Mail benachrichtigt. Dahinter steckt keine Böswilligkeit unsererseits. Wir möchten allerdings dafür sorgen, dass registrierte Leser eine Kontoanmeldung auf Basis unserer Datenschutzerklärung vornehmen – und in dem Bewusstsein, dass Ihre Daten (E-Mail-Adresse, Namen, ..) gespeichert werden. Ferner sollten Nutzer, die Kontos als Kommentatoren nutzen wollen, klar sein, dass Ihre Texte auch im Entwurfsstadium für unsere Administratoren einsehbar sind und dass die Texte in Hinblick auf Spam-Versuche analysiert werden. Wir halten dieses Vorgehen für fair.

Wir möchten auch feststellen, dass dieser Blog primär Linux und Open Source Technologie/Tools unterstützt. Es ist auch mein persönlicher Weg, der Linux und OpenSource Community etwas zurück zu geben. Wir wollen auch in Zukunft und trotz zunehmender Anfragen nicht der kommerziellen Bewerbung von Closed Source oder technik-fremden Produkten dienen. Wir werden uns allerdings auch weiterhin mit solchen Produkten kritisch und konstruktiv auseinandersetzen – im Besonderen wenn sie unter Linux eingesetzt werden können.

There are some registered readers of this blog. In advance of the DSGVO / EU GDPR we have consolidated these accounts – and also deleted some accounts. We want to ensure that any further registration takes place by accepting
our data protection information. All account users should also be aware of the fact that their texts are visible to our administrators even before submit time and that all texts will be analyzed regarding Spam contents. We feel this procedure to be clean and fair. We shall provide an English version of the data protection information the next days.

We would also like to mention that this blog primarily supports Linux and Open Source technology. It is also our way of delivering soemthing back to the Linux and Open Source Community. We have no intention to support advertisement for closed source products or related companies. However, we will sometimes critically comment such products – especially when they can be used on Linux systems.

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

Posted on by

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.

Gegentests

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!

Fazit

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.

Links

Leaving Facebook … – I
Bruce Schneier über Facebook, Cambridge Analytica und die Daten-Sammel-Industrie
https://www.kuketz-blog.de/das-kranke-www-stop-using-google-web-services/
https://traffic3.net/wissen/webanalyse/google-analytics-datenschutz
https://www.blogmojo.de/google-dsgvo/#5_google_analytics

PHP, MariaDB, Load Data Infile – manchmal ist der Umweg über Dateien performanter ….

Posted on by

Im Moment bin ich wider mit LAMP-Entwicklung beschäftigt. Mit Simulationen zu technischen Netzwerken in mehreren Dimensionen mit vielen Knoten, die kreuz und quer verbunden sein können. In solchen Netzen gibt es u.U. eine mit der Knotenmenge exponentiell wachsende Anzahl von Pfaden. Die Simulation des Informationstransports durch solche Netze ist ähnlich zum Transport von Signalen in “künstlichen neuronalen Netzwerken” – in unserem Fall ist aber die Komplexität aufgrund der Netzstruktur und der Qualität der transportierten Information erheblich größer.

Das Ziel meiner Auftraggeber sind datenbankgestützte Simulationen solcher technischen Netze mit PHP. Bei einer hinreichenden Anzahl von Knoten, Ebenen und Verbindungen erhält man dabei u.U. erhebliche Datenmengen, die man während der laufenden Rechnung systematisch auslagern muss. Das ist in Forschungslabors mit einer Armada von Prozessoren und SSDs nun heute selten ein grundsätzliches Problem. Im einem kleinen Büro oder auf billigen LAMP-Servern aber sehr wohl – insbesondere dann, wenn man nicht mit Multithreading in Web-Server-Umgebungen beginnen will oder aus Sicherheitsgründen gar nicht kann (pthread etc,. lassen das in Webumgebungen gar nicht zu). Oft hilft dann ein kleiner Umweg – und der führt u.U. über Ajax, Web-Clients und Dateien.

Ausgangslage

Aus bestimmten Gründen sollen die Berechnungen meiner Kunden auf LAMP-Servern angeboten werden. Hochgradige Programm-Effizienz ist also ein Muss. Günstige virtualisierte Mittelklasse-Server haben oft eine Ausstattung mit 4-6 Prozessoren, mehreren GB RAM und SSD-Speicherplatz. Zwei Prozessoren sollen ggf. einen Apache-Server mit PHP-Modul stützen, zwei andere eine Hauptdatenbank, die während der Simulation benutzt wird, und ein fünfter ggf. eine Bank für Ergebnisdaten.

Nun macht jeder mal die Erfahrung, dass Datenbank-INSERTs in der Regel grundsätzlich zu den langsamen Transaktionen zählen. Zudem behindern sie in einem PHP-Programm die Ausführung weiterer datengenerierender Funktionen, die möglicherweise gar nicht – oder zumindest nicht zeitnah – von den erzeugten Outputdaten abhängig sind. So kann es je nach Breite von Records schon mal im Bereich von Sekunden dauern, wenn man mehrere hunderttausend Datensätze “on the fly” in Datenbank-Tabellen schreiben will – und dabei auch noch mehrere Indices aufgebaut werden sollen. Wertvolle Zeit, in der andere Dinge – nämlich weitere numerische Berechnungen – passieren könnten. Wie kann man da CPU-Zeit sparen bzw. sinnvoll nutzen?

Ajax und der Web-Client zur Multitasking-Steuerung für Arme

Man vergisst oft, dass bei gut separierbaren Aufgaben auch der (Web-) Client ins Spiel gebracht werden kann. So kann ein Client über Ajax zwei (oder mehr) PHP-Threads auf einem Apache-Server starten – jeder in einer eigenen Umgebung (memory-, session- und prozess-bezogen). Per Ajax kann man den zweiten Prozess auch periodisch – und in Abhängigkeit von zwischenzeitlich dokumentierten Ergebnissen des kontinuierlich laufenden ersten Prozesses starten.

Der Hauptprozess – in unserem Fall unsere Simulation – kann dabei mit den weiteren periodisch gestarteten Prozessen signalartig über ein gemeinsames Medium kommunizieren – nämlich über spezielle Tabelleneinträge in der Datenbank. Die periodischen Jobs lesen diese Information aus und verhalten sich entsprechend. Ergebnisse werden per Ajax an den Client übermittelt, der dann weitere Nachfolgeaktionen einleitet.

Diese Art von getriggertem “Multitasking” über einen zentralen Web-Client und einen vermittelnde Ajax-Schicht hat einige Vorteile bei langwierigen Prozessen – wie etwa Simulationsläufen. Eine typische Anwendung ist etwa das Status-Polling zum Simulationsprozess. Ich hatte darüber bereits früher in diesem Blog berichtet.

Umgang mit großen zwischen-zeitlich aufkommenden Ergebnisdaten

Wie können wir das nun nutzen, um
zwischenzeitlich produzierte große Datenmengen halbwegs schnell in eine Datenbank aufzuräumen? Man vergisst im LAMP-Geschäft zu oft Dateien als Austauschmedium und als Puffer. MariaDB/MySQL-Systeme bieten zudem einen hochgradig effizienten Weg an, große Datenmengen in flache Tabellen einzulesen, nämlich “LOAD DATA INFILE”:

Vergleicht man die Zeit, die man in einem ausreichend mit RAM gepufferten System mit Write-Caching auf Linux-Ebene benötigt, um strukturierte Daten in ein File zuschreiben, so wird man feststellen, dass das u.U. erheblich (!) weniger Zeit kostet, als zwischenzeitlich eine Datenbanktabelle zu befüttern. Das gilt auch dann noch, wenn man die Zeit hinzurechnet, die ein LOAD DATA INFILE der MariaDB für das Füllen einer Tabelle aus den insgesamt generierten CSV-Filedaten (mit ggf. Millionen Datensätzen) benötigt. Das Schreiben in ein File, das anschließende Laden in eine Tabelle einer ansonsten wenig ausgelasteten Bank (ohne gleichzeitige Index-Generierung!) und die nachträgliche Erzeugung von Indices ist i.d.R. immer noch um Faktoren schneller als der direkte Transfer über (prepared) INSERTs – selbst wenn man hunderte Rows in ein INSERT-Statement packt. Zeit, die – wie gesagt – vom eigentlichen Simulationsprogramm genutzt werden kann!

Hinweis:
Ganz entscheidend für den effizienten Einsatz von “LOAD DATA INFILE” ist hierbei, alle Indices von der zu befüllenden Tabelle gelöscht zu haben, die Daten zu laden und erst danach die notwendigen Indices zu generieren. In all unseren Tests haben sich hierbei übrigens MyISAM-Tabellen performanter als InnoDB-Tabellen verhalten.

Schrittfolge

Wir werfen kurz einen Blick auf die Schrittfolge (habe leider gerade keine Zeit, schöne Grafiken zu zeichnen):

  • Schritt 1: Der Web-Client startet das Simulationsprogramm “S”, das durchgehend auf der Hauptdatenbank-Instanz arbeitet.
  • Schritt 2: Der Web-Client startet unmittelbar darauf auch noch zum ersten Mal und danach periodisch ein weiteres Programm “O”, das für die Behandlung von Output-Daten zuständig ist (sobald halt welche angefallen sind) und das dazu eine spezielle Tabelle der Hauptdatenbank auf Einträge zu fertiggestellten Output-Dateien abfragt. Der Client startet “periodisch” aber nur dann weitere Jobs vom Typ “O”, wenn er zuvor Statusmeldungen des aktuellen “O”-Prozesses erhalten hat, und sich der aktuelle “O”-Prozess beendet hat.
  • Schritt 3: Der zweite PHP-Prozess “O” widmet sich dann jeweils der zuletzt fertiggestellten Datei, prüft ggf. deren Struktur und übergibt dann die weitere Behandlung an einen LOAD DATA INFILE-Prozess der MariaDB – ggf. einer zweiten separaten Datenbank-Instanz, der eigene Prozessoren und memory-Anteile zugewiesen wurden.
  • Schritt 4: Nach einem erfolgreichen Laden der Daten durch den Prozess “O” beendet sich dieser, nachdem er dem Client noch eine Meldung per Ajax zugeschickt hat.
  • Schritt 5: Der Client startet ein weiteres Mal das für Outputs zuständige Programm vom Typ “O”.
    etc.

Das Ganze dauert so lange, bis vom Hauptprogramm ein “Signal” (per DB-Eintrag) gesetzt wurde, dass kein weiterer Output mehr zu erwarten ist.

Das Vorgehen entspricht einer Art selbstgesteuertem, dynamischen Batch-Processing von Daten auf einem LAMP-Server. Es erfordert ein wenig mehr Programmieraufwand (insbesondere zur Fehlerbehandlung) als ein Standard-Vorgehen im Rahmen eines einzigen Threads – es bringt u.U. aber Faktoren an Performance – solange die Simulation nicht auf Zwischenergebnisse in der Bank warten muss. Letzteres ist bei uns oft genug der Fall.

Wir haben so Programm-Läufe, die in Tests 25 Sekunden dauerten, auf unter 5 Sekunden gebracht. Es
war der Mühe wert – und wir können anderen, die langwierige PHP-Programme für Simulations-Berechnungen auf LAMP-Servern nur empfehlen, eine solche Vorgehensweise an kritischen Engpässen mal als Alternative zu untersuchen.

Zusammenfassung

Fallen bei langwierigen PHP/LAMP-Programmen zwischenzeitlich große Datenmengen an, können diese u.U. ohne Beeinträchtigung des Hauptprogramms parallel durch weitere PHP-Programme einer Behandlung durch eine Datenbank zugeführt werden. Teil der Steuerung kann dabei ein gemeinsamer Ajax-Client sein, der die Ergebnislieferung der verschiedenen PHP-Programme überwacht. Der Datenaustausch zwischen den parallel laufenden PHP-Prozessen erfolgt dabei über die Datenbank, Ajax-Meldungen und Datenfiles. Zur Behandlung großer Datenmengen kann dabei LOAD DATA INFILE seine Performance-Vorteile ausspielen. Insgesamt sind dadurch im Einzelfall erhebliche Programm-Beschleunigungen möglich.

phpmyadmin, charts, MariaDB – a strange bug with x-axis value order and ORDER clauses in sub-SELECTS

Posted on by

A customer of mine wants to use phpMyAdmin to create some charts whilst working with a complex database. I recommended a trial with phpMyAdmin and its chart functionality. Unfortunately, this did not always work out as expected:

You may e.g. create an ordered resultset first – with a suitable SELECT and ORDER clause – e.g. to get two columns – an index “i” and associatd values “val”. Rows of the resultset ordered e.g. ASC with the “i”-values. But after using the columns “i” a simple line graph the order on the x-axis may appear different than requested by your ORDER clause.

I have posted this as an issue to the (nice) developers of phpmyadmin – who are working on it :-).

There is a workaround. But what I found more interesting is the cause of the problem, which appears on MariaDB and NOT on MySQL. It has apparently to do with a different handling and interpretation of SQL standards for ORDER clauses in sub-SELECTs! See:
https://mariadb.com/kb/en/library/why-is-order-by-in-a-from-subquery-ignored/

This is of general interest for developers using MySQL or MariaDB-databases. I, myself, was not aware of it. Besides an already different handling of database replication, I regard this point as one more indication for a growing “distance” between both RDBM-systems…

If you stumble across the phpmyadmin-chart problem, see a discussion and a workaround on the following site:
https://github.com/phpmyadmin/phpmyadmin/issues/14239

I also want to explicitly thank M. Jayaratne who supplied me with the valuable information referenced above.

Sparc Flow – what a read …

Posted on by

As some of my readers may know I have a certificate on ISO/IEC 27001 internal auditing. (Not that there are many customers interested in this … security in Germany still is a waste land.) The ISO/IEC 27001 standard defines a systematic process oriented approach to security. At its core it demands (besides other things) defined processes for a thorough periodical risk analysis to derive appropriate security measures. Control, audit and continuous improvement processes must be included in the process landscape – up to highest company level. So far so good. Of course, technical measures have to be taken into account – but the whole “control” catalog of Appendix A is written in a very general way and has to be broken down to specific requirements of a company.

Despite working on process consulting, I carry around a technical mindset from my time in physics and numerical math. So, in a way, I like looking at the technical basics in a security context – though I would not call me a real technical expert on “hacking”. Still I have a profound interest in pen-testing tools. In my opinion every type of security auditor should have a reasonable amount of knowledge about technical risks, pen-testing and possible attack vectors. However, after working a while with common scanning and attack tools in isolated pen-test environments – with the legal consent of the owners – one gets a strange feeling:

When you judge the effectiveness of security measures and test them by standard analysis tools: Don’t you miss the creativity of real hackers? Are the “real” threats covered by pen-testing tools like vulnerability scanners and Metasploit stuff, at all?

Another critical point is the threat level assigned by tools like Nessus or OpenVAS to detected system vulnerabilities – if you concentrate on the most “severe”, high point alerts, you may almost always miss some “low” risks and underlying threats, which alone or in combination can be used for a systematic privilege escalation. That there is some truth in this statement you may already find out on metasploitable training machines.

So, one of the questions nagging in a corner of my mind from time to time was: Is there some literature which gives you a broader insight in the way a hacker may think? In action? Yesterday, I started reading a series of books of an author calling himself “Spark FLOW”.

My preliminary “verdict” as a non-hacker, but as a defense and security oriented person after 2 out of 7 books is:

Very interesting reading – though based on somewhat “constructed” scenarios (so far). Creative, varying use/combination of attack methods on different types of machines … I learned quite a bit about some Windows weaknesses and privilege escalation. But also Linux gets its amount of hacks and related comments. It is almost provocative that the first book rather early describes compromising a Linux machine in a DMZ ….(because – as the author explains in a footnote – “otherwise it would be too simple if we directly landed on Windows from the start”).

However, more important: Although written very attack-oriented – it gave me a hell to think about counter-measures. Which I, probably, have a better grasp on regarding Linux machines. But there a some Windows systems in our nets, too.

I would like very much to see a kind of summary table of this guy at the end of each of his books with a systematic collection of weaknesses and vulnerabilities exploited – and his ideas on reasonable countermeasures on the admins’ side.

Anyway – the reading was “enjoyable” and a bit frightening at the same time. It triggers some serious thinking. I recommend the book series of Sparc Flow to all “admins” and to all “sec staff” members who want to learn more about a hacker’s mindset and its flexibility.