everflux

Canonical hat als neue Vision, als hätten „Mir“ und „Unity“ nicht gereicht, Pakete im Snap Format auszuliefern. (Siehe auch https://snapcraft.io/ ) Dabei handelt es sich um containerisierte Anwendungen – seit Docker in aller Munde ist, möchte man da natürlich nicht zurückstehen.

Und so kam es, dass mir bei meinem Notebook bei der Installation von Ubuntu 18.10 direkt auch Snap untergeschoben wurde. So richtig deutlich merkt man das nicht – wenn alles täte, wäre das ja auch ok.

Bis ich für den ODROID-N2 eMMC Karten über einen MicroSD Adapter beschreiben wollte. Als braver „DevOps“ automatisiert man alles. Kleines Shellscript, das per fdisk alles partitioniert, mit mkfs.vat/mkfs.ext4 die Dateisysteme erzeugt, Arch Linux herunterlädt und passend auspackt und dann noch schnell ein paar Settings vornimmt. Hatte sich bei dem ODROID-C2 Kubernetes Cluster, den ich gefühlte 20 Mal neu aufgesetzt hatte sehr bewährt.

Doch nun das Fiasko: Es tat nicht. Ganz merkwürdig nicht. Die Partitionen wurden korrekt angelegt, aber das Dateisystem hatte eine viel zu geringe Größe. Auch ging die Einrichtung gefühlt einen Hauch zu schnell. Das Auspacken von der Arch Linux Distribution tut dann natürlich nicht.

Ok, nimmt man gparted meldet es auch, dass das Filesystem zu klein sei, ob man das nicht reparieren wolle – klaro. Ein paar Animationen später soll alles ok sein, ist es aber nicht.

Durch Zufall fällt mir auf, dass „df“ andere Mountpoints meldet, als „mount“. Bei „mount“ ist es /dev/sda1, bei „df“ ist es /dev/loop29 …. die anderen Loop-Devices werden für Snap Pakete verwendet. Und da machte es nach ca. 7 Stunden intensiver Diagnose und „Ist-das-kaputt-oder-ich-verrückt“ Momenten endlich „klick“. Scheinbar werden elementare Werkzeuge in Snap-Containern ausgeführt – und das führt dann zu Effekten, wenn die Devices nicht korrekt durchgemappt sind. WTF.

Das Snap Zeug ist jetzt deinstalliert. Alle Probleme verschwunden – und der Weg damit frei zum Kubernetes Cluster auf ODROID-N2 Basis!

Nachdem man sich der neuen „Postbank ID“ rumschlagen durfte, die dann natürlich mit OpenSource Software, wie Jameica/Hibiscus auch kein Stück funktioniert, gibt es wenigstens noch einen #fail zur Aufmunterung

Webseiten sind schwer zu managen, gerade wenn diese schon lange in Umlauf sind.
Wie in einem Garten werden neue Pflanzen gesetzt, alte abgeschnitten.
Doch nicht immer werden auch alle Wegweiser aktualisiert, und dann kann auch so was dabei heraus kommen.

Eine gute Lösung ist da schwer zu finden, vor allem, wenn man es mit vielen Satellitenseiten zu tun hat, möglicherweise noch Inhalten, die erst hinter einem Login zu finden sind.

Was aber helfen könnte, wäre eine einfache Möglichkeit, defekte Links zu melden – crowdsourcing ftw.

Das Blog hier wurde ‚gehackt‘.

Bemerkt wurde das erst, als ich im Auswärtseinsatz bei einer Schulung war. So dauerte es leider etwas, bis alles wieder in geordneten Bahnen war. (Man kann ja schlecht sagen „So Leute, jetzt mal ne schwere Übung, ich brauch etwas Zeit mein Blog zu fixen….“).

Doch wie konnte es dazu kommen? Ich aktualisiere regelmässig die Blogsoftware, der Server wird (meist) gut gewartet, um so erschreckender, wenn Einbrecher vandalisierend unterwegs sind.

WordPress verfügt über eine Auto-Update-Funktion. Die ist natürlich auch eingeschaltet. Tut nur nicht. Aktuelle Hypothese: Das Super-Cache ist Schuld, denn dabei werden Requests direkt von einer statischen Datei beantwortet und kommen gar nicht erst bei der Blog-Software an.

Bleiben also nur manuelle Updates, und die installiere ich eben bei Security-Fixes sehr schnell. Minor Fixes werden auch mal hinten angestellt, denn meine Freizeit ist arg knapp bemessen.

Und so hatte ich WordPress 4.7, 4.7.1 installiert, aber nicht das wenige Tage später erschienene 4.7.2, das war für nach der Rückkehr von der Schulung geplant und es gab keine kritischen Fixes. Zumindest hatte es keiner gesagt, denn das WordPress Team hatte sich entschieden zu verschweigen, dass es eine extrem kritische Lücke gab. Eine Lücke, die einem unauthentifizierten Nutzer erlaubt, die Kontrolle zu übernehmen.  Und die Lücke wurde erste mit WordPress 4.7 eingeführt. Man könnte also sagen, dass meine eifrigen Updates zu dem Problem beigetragen haben.

Das offizielle Statement dazu hätte auch von einem PR Berater kommen können:

We believe transparency is in the public’s best interest. It is our stance that security issues should always be disclosed. In this case, we intentionally delayed disclosing this issue by one week to ensure the safety of millions of additional WordPress sites.

Im Nachhinein wurde also erst die volle Tragweite kommuniziert und dann noch schöngeredet, wie damit umgegangen wurde. Man kann sich vorstellen wie gut ich darauf zu sprechen bin.

Das eigentliche Probleme ist aber das nicht funktionierende Auto Update. Um das weiter einzugrenzen habe ich diese Plugins ausprobiert:

• https://de.wordpress.org/plugins/wp-cron-status-checker/
• https://de.wordpress.org/plugins/advanced-cron-manager/

Der Cron Status Checker ist dabei, was ich gesucht habe. Es prüft, ob cron funktioniert, und erlaubt sogar dem Blog Besitzer emails zu senden, wenn bei der cron Ausführung ein Fehler auftritt.

Hat leider nicht so ganz geklappt. Angeblich soll dies Setting helfen:

define( 'ALTERNATE_WP_CRON', true );

Ich bezweifle jedoch, dass das besser funktioniert.

Seit Monaten schon stapelt sich der Müll: Spam der Schwerlastregale, Erste-Hilfe-Koffer und weiteres Zeugs bewirbt, den man total komfortabel und günstig einkaufen kann. Alles weit unter dem Listenpreis!

Die Webseiten haben unterschiedliche Domains, bei einigen habe ich mal geschaut, diese hatten dann ein Frame, dass auf www.handelskauf.com zielt.
Vom Design her sind die Seiten schlicht bis altbacken.

Von gesicherter Verbindung – eigentlich Standard bei der Verarbeitung potentiell personenbezogener Daten – keine Spur. Direkt auf der Startseite springt einem ein dicker Disclaimer entgegen:

Sollten Sie unverlangt E-Mails erhalten haben (Joe-Job), die auf uns als Absender hinweisen, distanzieren wir uns ausdrücklich von diesen Schreiben. Bisher wurde anhand der Absender-IP-Informationen festgestellt, dass Schreiben mit gefälschten Absendern in unserem Namen aus Russland und China versandt wurden. Gleichzeitig bitten wir Sie, uns hier zu informieren, damit wir erforderliche Schritte einleiten können um eine zukünftige Belästigung zu verhindern. Vielen Dank!

Der Link ist kein Formular, sondern die E-Mail Adresse [email protected] – hier würde ich auf keinen Fall etwas hinmailen, denn nichts finden potentielle Spammer besser, als verifizierte Adressen. Ich sage daher potentielle Spammer, da mein Gesamteindruck der E-Mails und der Webseite der ist, dass der Anbieter tatsächlich der Versender der E-Mails ist. Alles andere – Joe-Job – halte ich für eine nicht plausible Schutzbehauptung.

Wenn man genug sucht – ein Impressum ist nicht zu finden – findet man vergraben in den AGB dann „Consulttrayx, Kruppstr. 2, 60388 Frankfurt. mail: [email protected]“ als angeblichen Anbieter.

Auf der Webseite ist eine Faxnummer angegeben: Telefax 069-25577137 Consulttrayx
Schaut man sich die Daten des Domaininhabers an, so sieht man

Updated Date: 2016-09-05T13:37:47.0Z
Creation Date: 2016-09-05T13:37:47.0Z
Registrar Registration Expiration Date: 2017-09-05T13:37:47.0Z
Registrar: Key-Systems GmbH
Registrar IANA ID: 269
Registrar Abuse Contact Email: [email protected]
Registrar Abuse Contact Phone: +49.68949396850
Domain Status: ok https://icann.org/epp#ok
Registry Registrant ID: Not Available From Registry
Registrant Name: Markus Böhme
Registrant Organization: Palex GmbH
Registrant Street: Sternplatz 3
Registrant City: Freudenberg
Registrant State/Province: Hessen
Registrant Postal Code: 97896
Registrant Country: DE
Registrant Phone: +49.6925577137
Registrant Phone Ext:
Registrant Fax:
Registrant Fax Ext:
Registrant Email: [email protected]

Die Palex GmbH, palex.eu hat auf der Webseite stehen

Palex GmbH
Sternplatz 3
97896 Freudenberg

Telefon: 0800-7243267 (Freecall)
Telefax: 06181-5709487

Ustr.-Nr. DE279949400
EORI-Nr. DE58871984157027

AG Mannheim HRB 723633
Geschäftsführer: M. Böhme

Interessant ist hier die gekürzte Angabe des Namens Markus Böhme – dies kann als rechtswidrig bezeichnet werden, denn es gibt die Vorgabe den vollständigen Namen des Geschäftsführers im Impressum anzugeben. Sucht man nach der Umsatzsteuernummer DE279949400 so findet man haufenweise Berichte über Spam von der „Mbi Gmbh“, auch hier ist der Geschäftsführer Markus Böhme.
Da muss jemand aber wirklich wirklich Pech haben immer diese Joe-Jobs abzubekommen… und da macht man schon ständig neue GmbHs… mit der selben Umsatzsteueridentifizkationsnummer?

Auch super ist die Verlinkung der Widerrufsbelehrung, wenn man verrückt genug ist bei einem so unseriösen Laden ohne Impressum zu bestellen: Der Link funktioniert schlicht nicht.

Was könnte der Grund sein für so einen offensichtlichen Spam mit einem Shop, in dem keiner bestellt, der bei Trost ist?
Validierungs von E-Mail Adressen?
Eine Seite mit der man Malware vertreiben kann?
Oder gibt es tatsächlich Leute, die auf so etwas anspringen und kaufen?

Bei Beschwerden würde ich in jedem Fall die kostenlose Rufnummer 0800-7243267 wählen und nicht dort hin mailen. Sonst ist noch mehr Spam von dem Herrn Böhme oder einer der verbundenen Firmen wie der Consulttrayx Spam wahrscheinlich.

Was kann man tun? Ich würde empfehlen sich bei dem jeweiligen Anbieter der genutzten Infrastruktur zu beschweren. OMCnet Internet Service GmbH bietet für handelskauf.com und palex.eu die Infrastruktur.

Hier könnte ein Hinweis an Lutz Rabing, den Geschäftsführer der OMCnet für Sensibilität sorgen.

Wer sich mit dem Thema Cloudcomputing beschäftigt, der stößt unweigerlich auf das Thema Ausfallsicherheit. Bei Host-Systemen wird mit sehr aufwendigem und teurem Engineering Ausfallsicherheit durch „self-healing“, Redundanz und Hot-Plug-Fähigkeiten erzielt. Fällt ein Netzteil aus, wird durch ein oder mehrere redundante Netzteile die zum Betrieb notwendige Stromversorgung weiter aufrecht erhalten. Sobald ein Ersatzteil verfügbar ist, kann das defekte Netzteil dann ohne Betriebsunterbrechung ersetzt werden. Skalierung erfolgt durch sehr leistungsfähige Komponenten, wird mehr Durchsatz benötigt so kann bei Mainframes zusätzliche Kapazität freigeschaltet werden („on demand“).

In der Cloud ist es genau andersherum: Jeder einzelne Rechner bringt eine eher geringe Verfügbarkeit mit sich, mehr Leistung auf den einzelnen Knoten ist ebenfalls nur sehr begrenzt verfügbar. Ausfallsicherheit wird durch extreme Verteilung – bis hin über den ganzen Globus – und Vermeidung von Single Points of Failure erzielt. Skalierung analog. Selbst der Ausfall ganzer Rechenzentren oder gar die Infrastruktur eines Kontinents ist damit theoretisch verschmerzbar.

Klassische Enterprise IT bewegt sich meist zwischen den beiden extremen: Die einzelnen Rechner bestehen aus hochwertigen Komponenten, dank Virtualisierung lassen sich Hardwaremigrationen durchführen um bei Ausfall oder Wartung von Servern den Betrieb weiter zu gewährleisten.

Jedes Szenario hat eigene Vor- und Nachteile, am meisten fällt der finanzielle Aspekt ins Auge. Host/Mainframe ist sehr teuer in der Anschaffung, Betrieb/Wartung und erfordert spezielle Fachkräfte, die sich im Vergleich zu weniger spezialisierten Personen entsprechend fürstlich bezahlen lassen. Auch lässt der eiserne Griff der Anbieter einen Wechsel auf andere Plattformen sich oft nur schwer wirtschaftlich darstellen.

Allen ist jedoch eins gemeinsam: Totalausfälle sind zu vermeiden und durch entsprechende Massnahmen zumindest eingeschränkter Betrieb aufrecht zu erhalten. (Zum Beispiel als Read-Only.)

Was man nie zu sehen bekommen sollte, ist daher so etwas wie hier bei dem Buchungssystem der Lufthansa

Es geht nichts über generische Fehlerbehandlung… und dann noch einen Medienbruch oben drauf. Erstklassig, liebes American Express!

Um welches Land mag es sich da handeln über dass das Handelsblatt hier berichtet?

Tipp: Es ist nicht China. Nein auch nicht Nordkorea.

Deutschland? Wirklich? Nein, aber wäre es eine andere Überschrift geworden?

Das ist schon gar nicht so einfach mit online Bestellungen. Selbst wenn man in der IT arbeitet. Joey’s Pizza – zu denen ich eh ein gespaltenes Verhältnis habe – hat jetzt ein neues Online Bestellsystem für Joey’s Pizza Lieferdienst. Um da zu bestellen müssen Daten angegeben werden, für die es gar keine Felder gibt. Klappte dann aber auch ohne „Name am Klingelschild“, aber hat das Bestellerlebnis deutlich beeinträchtigt. Ich wüsste gerne wie hoch die Abbruchrate bei dem Prozessschritt ist.

Insgesamt dauert die Bestellung fast doppelt so lange wie bei dem alten System, dafür sind ja auch die Preise angehoben worden. Wenn das nicht fair ist.

Ist immer so eine Sache mit den null Jobs… dass jemand wirklich null Job sucht ist aber auch für mich was neues.

Immerhin gibt es null jobs in vielen Städten, man bleibt also flexibel.