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

Nach der enttäuschenden Feststellung, dass selbst ein Raspberry Pi3 lediglich 100mbit als Netzwerkport und mit USB Gigabit Ethernetadaptern auch nur maximal 450mbit aufgrund der USB 2 Bandbreite zu erzielen ist, musste ein anderes Gerät her.

Ausgewählt habe ich einen Odroid-XU4, der auch Gigabit direkt onboard mitbringt und dank USB 3 auch in der Lage ist Gigabit zu bedienen. Aufgrund der Big-Little Architektur gibt es hier zwar acht CPU Kerne, diese sind jedoch unterschiedlich leistungsfähig. Um die optimale Netzwerkgeschwindigkeit zu erzielen, müssen einige Einstellungen am Odroid vorgenommen werden. Andernfalls ist auch bei rund 170-200 mbit Durchsatz Ende.

Zum einen muss der Interrupt für die Netzwerkkarte auf eine andere CPU als die Default-CPU 0 gelegt werdenm denn die ist mit Interrupts sowieso gut beschäftigt.

Zum anderen kann man noch dem Netzwerkstack mitteilen, mit welchen IRQs anstehende Daten behandelt werden sollen.

echo f > /sys/class/net/eth0/queues/rx-0/rps_cpus

Um stets die bestmögliche Performance zu erzielen kann noch der CPU Governor angepasst werden.

Ich wurde heute gefragt, wie ich das nur schaffe, mir ständig neue Dinge anzusehen und mich mit so vielen Themen und Technologien zu befassen. Ob das nicht anstrengend sei, wie lange ich das durchhalte würde.

Ich glaube umgekehrt wird ein Schuh draus: Ich möchte keinen Job haben, der eintönig ist. 9-17 Uhr, dann die Schuhe in die Ecke donnern und ein Bier im Fernsehsessel? Bagger steuern und um halb zehn die Bild „lesen“? Wäre halt nicht mein Leben, auch wenn andere damit total happy sind.

Darum braucht man auch verschiedene Typen Menschen. Die einen, die konsumieren und dafür bereit sind, anderes zu tauschen. Und dann gibt es die Menschen, die neues gerne angehen und sich über Chancen freuen, konstruktive Dinge zu tun. Das fühlt sich dann nicht unbedingt wie Arbeit an. Das „durchgearbeitete“ Wochenende? Entspannung, sieht nur nicht unbedingt auf den ersten Blick so aus!

(Davon abgesehen bilde ich mir ja ein, dass das Gehirn davon jung bleibt – also etwas Egoismus sei gestattet 😉 )

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.

Google hat mit der Wahl der Jetbrains Platform für ihr Android Studio eine gute Wahl gemacht. (Auch wenn ich mir persönlich gewünscht hätte, dass es NetBeans wird, aber das war bei dem Verhalten von Oracle ja kaum zu erwarten.) Dennoch gibt es ab und zu Gründe, ohne Android Studio eine Installation der Android Entwicklungswerkzeuge vorzunehmen. (Zum Beispiel, wenn man NativeScript nutzt und dabei in WebStorm unterwegs ist…)

Nach der Umstellung des SDK ist es schwierig, aktuelle Anleitungen für Ubuntu zu finden, die nicht mit „Download Android Studio…“ beginnen.

Darum hier jetzt meine Kurzanleitung:

1. Auf 64bit Systemen wird noch immer eine 32bit Umgebung benötigt, diese installiert man mittels
   sudo apt-get install lib32ncurses5 lib32stdc++6 libstdc++6
2. Ordner anlegen, wo das Android SDK und die Werkzeuge landen sollen, ich wähle mal
   mkdir ~/tools/android-sdk<c/ode>
3. Download der Kommandozeilen Werkzeuge des SDK
   wget https://dl.google.com/android/repository/sdk-tools-linux-3859397.zip
4. Das wird dann unter ~/tools/android-sdk ausgepackt, entstehen wird danach der Ordner „tools“
5. Die entstehenden Android Verzeichnisse werden in den PATH aufgenommen, damit von der Kommandozeile die Programme gefunden werden. Ob das jetzt in die ~/.bashrc oder ~/.zshrc oder ~/.sonstwasrc muss, wird jeder selbst wissen.
   

   export ANDROID_HOME=~/tools/android-sdk
   export PATH=$PATH:$ANDROID_HOME/emulator:$ANDROID_HOME/tools:$ANDROID_HOME/tools/bin:$ANDROID_HOME/platform-tools

6. Nun folgt ein umfangreicherer Download….
   

   sdkmanager --update
   sdkmanager "extras;android;m2repository" "extras;google;m2repository" "system-images;android-25;google_apis;x86" "system-images;android-25;google_apis;x86_64" "platforms;android-25" "build-tools;25.0.3"

7. Und „schon“ kann ein Android Emulator Image instantiiert werden
   avdmanager create avd -d 9 --abi google_apis/x86 --name nexus5x  -k "system-images;android-25;google_apis;x86"

8. Gestartet wird das ganze dann z.B. so:
   emulator @nexus5x -skin 768x1280

Schon ist das Android SDK Setup unter Ubuntu fertig.

Leider stehen einige Optionen, wie „–skin“ bei dem avdmanager (noch) nicht zur Verfügung, so dass beim Emulator Start der Parameter mit angegeben werden muss. Sonst gibt es ein Guckloch im Format einer Briefmarke für den Emulator…

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

Mobile growth is a driver for many technologies: Responsive design, HTTP/2, HTML5 replacing Flash. Facebook started with an own format for optimized mobile delivery. This is not only beneficial to users: If a page is displayed fast, ads are visible before the user clicks away, as well.

Google followed the approach of a custom format, called Accelerated Mobile Pages (Google AMP). Instead of choosing a completely different container, like XML, proven technologies were used: HTML, JavaScript and schema.org JSON notation. By using a JavaScript based runtime to implement functions like delayed loading of non-essential assets and inlining CSS, the initial transmission size of the page can be reduced.

While WordPress got support for generating AMP content by a plugin, other CMS applications seem to be lacking. Especially when using static site generators it can be challenging to generate multiple variants from the same content. I like static site generators for several reasons:

• Can be served from a low-grade webserver without special requirements
• Really, really fast page serving
• Easy to cache / integrate CDN
• Low attack surface, easy to secure

I used middleman in several projects, so far I am quite happy with it. Thanks to integrated asciidoctor support it was even possible to use a common source for web pages as well as print documents, distributed by other channels.

When facing the desire to provide Google Accelerated Mobile Pages (AMP) using the existing middleman setup along with the existing content I noticed the shortcomings of HTML or asciidoc based page templates. Nevertheless I went ahead and use some customizations (some would call it hacks) to achieve my goal. I prototyped it for trion.de and you can see the AMP result on https://www.trion.de/amp/

The implementation uses the latest middleman 4 and the targets plugin to have multiple variants as build targets. To ensure that the AMP links to not point to the non-AMP version by accident a link_prefix and deployment of AMP to a subdirectory is used. Another option would have been to use a subdomain. Of course the AMP version uses a different layout which includes the AMP engine JavaScript and required markup and meta data for the AMP pages.

# Build Targets
# https://github.com/middlemac/middleman-targets
config[:targets] = {
  default: {
    build_dir: "build",
    layout: "layout",
    link_prefix: nil,
    features:
    {
    }
  },
  amp: {
    build_dir: "build/amp",
    layout: "amp",
    link_prefix: "/amp",
    features:
    {
    }
  }
}

In order to be able to reuse the existing content, some global search-and-replace is applied as part of the template.

<% content = yield %>
<%
content.gsub!("<img", "<amp-img")
content.gsub!("<iframe", "<amp-iframe")
content.gsub!("</img", "</amp-img")
content.gsub!("</iframe", "</amp-iframe")
%>
<%= content %>

It is now obvious why this can be called a hack instead of an engineered solution. A better approach would be possible if the source data for the pages is provided in a more strcutured format like JSON or YAML. Both are supported by middleman and are a good choice for content that follows a well defined structure. (A good example is the trainings catalogue on trion.de/schulung/schulungen-coaching-training.html)