Archiv ‘Uncategorized’

Freitag, 30. März 2018

Wenn US-Amerikanerinnen (insbesondere Kalifornierinnen) so komisch sprechen …

Meine Frau legt diese Sprechweise zum Glück nicht zu Tage, aber bei einigen ihrer Kolleginnen und bei flüchtigen Bekanntschaften auf unseren Kalifornien-Reisen ist es mir bereits unzählige Male aufgefallen: Dieses ganz-hinten-im-Rachen-sprechen, die Angehörige des weiblichen Geschlechts an den Tag legen. Und einem immer wieder auffällt, sobald man sich einmal darauf geachtet hat.

Bis vor einigen Tagen war ich der Meinung, dass dieses Phänomen bisher nur mir aufgefallen ist und es keinen Namen dafür gibt.

Falsch gedacht! Als Kollege Schaad und seine Catherine kürzlich bei uns auf ein Raclette vorbeikamen, fiel die Konversation irgendwann einmal auf die Kardashians. Und bei diesem Thema erwähnte Raphael den Begriff „Vocal Fry“, der diese froschartige Sprechweise bezeichnet.

Ein Zeitgenosse, der sich wohl wie ich derart ab den Kardashians aufregt, hat dazu auch gleich ein sehr illustratives Video auf YouTube aufgeschaltet, das man kaum in voller Länge schauen sollte, wenn man Wert auf seine geistige Gesundheit legt:

Nachtrag

Naomi Wolf redet ihren Geschlechtergenossinnen in einem Meinungsstück mit dem Titel Young women, give up the vocal fry and reclaim your strong female voice ins Gewissen.

Tags: , , , , , , , ,
Labels: Uncategorized

Keine Kommentare | neuen Kommentar verfassen

Freitag, 23. März 2018

Was verändert sich mit meinem nächsten Subversion Checkin?

Der folgende Befehl zeigt analog zu einem diff zwischen zwei Dateien an, welche Änderungen an den lokalen Dateien gegenüber dem letzten versionierten Stand vorgenommen wurden:

$ svn diff -r head

Tags: , ,
Labels: Uncategorized

Keine Kommentare | neuen Kommentar verfassen

Samstag, 25. November 2017

Normalen Benutzern den SSH-Login auf Synology DiskStations erlauben

Mit dem Synology DiskStation Manager DSM 6.0 kam es zu Sicherheitsanpassungen beim SSH-Login: Selbst wenn ein Administrator auf einem Synology NAS SSH aktiviert, können sich normale Benutzer per SSH nicht auf dem NAS einloggen. Dies ist nur mit Benutzern möglich, die der Administrator-Gruppe zugeteilt sind.

Um diese Anpassung im Namen der Sicherheit rückgängig zu machen, bin ich dem Blog-Artikel Howto: (re-)Enable SCP/SSH Login on Synology DSM 6.0 for non admin users [UPDATE] gefolgt. Der Grund ist trivial: Synology setzt für normale Benutzer in /etc/passwd ein unbrauchbares Login-Shell: /sbin/nologin

Die Lösung: Ein auf dem NAS hinterlegtes bash-Script wird mittels Cron-Job unter root laufend alle fünf Minuten ausgeführt und ersetzt die Login-Shell ausgewählter Benutzer mit /bin/sh.

/volume1/homes/admin/enable-ssh-logins.sh

#!/bin/bash
/usr/bin/awk -i inplace -F: 'BEGIN{OFS=":"}/^dagobert\:/{gsub(/.*/,"/bin/sh",$7)}1' /etc/passwd
/usr/bin/awk -i inplace -F: 'BEGIN{OFS=":"}/^donald\:/{gsub(/.*/,"/bin/sh",$7)}1' /etc/passwd
/usr/bin/awk -i inplace -F: 'BEGIN{OFS=":"}/^daisy\:/{gsub(/.*/,"/bin/sh",$7)}1' /etc/passwd
/usr/bin/awk -i inplace -F: 'BEGIN{OFS=":"}/^huey\:/{gsub(/.*/,"/bin/sh",$7)}1' /etc/passwd
/usr/bin/awk -i inplace -F: 'BEGIN{OFS=":"}/^dewey\:/{gsub(/.*/,"/bin/sh",$7)}1' /etc/passwd
/usr/bin/awk -i inplace -F: 'BEGIN{OFS=":"}/^louie\:/{gsub(/.*/,"/bin/sh",$7)}1' /etc/passwd

exit 0

Cron-Job über DiskStation Manager Web-Oberfläche einrichten

  • Control Panel
  • Task Scheduler
  • Create
  • User-defined script
  • General
    • Task: „Enable Login Shell“
    • User: root
  • Schedule
    • [x] Run on the following days: Daily
    • Frequency: Every 5 minute(s)
  • Task Settings
    • Run command: User-defined script: /volume1/homes/admin/enable-ssh-logins.sh

Tags: , , , ,
Labels: Uncategorized

1 Kommentar | neuen Kommentar verfassen

Freitag, 13. Oktober 2017

Hyperloop: Was für ein Käse

Elon Musk und seine Spinnereien mag ich nicht. Er verkörpert für mich vieles, was in Silicon Valley falsch läuft, wobei Uber niemandem den Platz streitig machen kann.

Ein Physik-interessierter Zeitgenosse hat in einem halbstündigen YouTube-Video Musks „Achterbahn“ demontiert:

Top, die Wette gilt!

Tags: , , , ,
Labels: Uncategorized

Keine Kommentare | neuen Kommentar verfassen

Montag, 2. Oktober 2017

Landeanflug auf SFO

Seit 2011 erlebe ich diesen Landeanflug in der Regel ein, zwei Mal pro Jahr:

Hier scheint es sich um den Jungfernflug (?) der A380 von FRA nach SFO zu handeln.

Verwirrt hat mich der Begriff „DUMBA“, bis mir meine Frau gesagt hat, dass damit wohl die Dumbarton-Brücke gemeint ist.

Tags: , , , , , , , , , , ,
Labels: Uncategorized

1 Kommentar | neuen Kommentar verfassen

Montag, 2. Oktober 2017

DJ Antoines „Ma Chérie“ gejodelt

Kollege Hebo hat mich in der Toscana auf diese bodenständige, sympathische Werbung für das Wallis und Schweizer Tradition aufmerksam gemacht:

Tags: , , , , , , , ,
Labels: Uncategorized

Keine Kommentare | neuen Kommentar verfassen

Samstag, 29. Juli 2017

Backup der Raspberry Pi SD-Karte anfertigen

Kürzlich hatte ich während eines Anfalls aus geistiger Umnachtung versucht, meinen Raspberry Pi 3 von Raspbian Jessy auf Raspbian Stretch zu „lüpfen“. Scheiss-Idee. Im Gegensatz zu Debian ist Raspbian Stretch leider noch nicht stabil genug, um auf einem produktiven Raspberry Pi zu laufen.

Nicht nur das, es war tatsächlich so, dass ich zwar seit wohl fünf Jahren hier in der Wohnung einen Raspberry Pi betreibe — und nicht wusste, dass man auf einfachste Weise eine Kopie einer sauber aufgesetzten Raspbian-Installation anfertigen kann.

Das Vorgehen ist im Internet mehrfach beschrieben; ich habe mich an den Artikel Back-up a Raspberry Pi SD card using a Mac gehalten.

Das Vorgehen:

  1. Raspberry Pi herunterfahren
  2. Die SD-Karte mit einer Pinzette aus dem Gerät holen
  3. Die SD-Karte mit einem Adapter an einen Mac (oder Linux-Rechner) anschliessen
  4. Mit diskutil list oder df die Device-Adresse der SD-Karte herausfinden; in meinem Fall /dev/rdisk4
  5. Die gesamte SD-Karte in eine Datei auf dem lokalen Mac klonen:
    # dd if=/dev/rdisk4 of=~/Desktop/emeidi-dashboard.img bs=1m

Fertig! Verbockt man sich in Zukunft den Raspberry Pi, schliesst man einfach wieder die SD-Karte an den Mac an und schreibt das Image zurück.

Dies funktioniert auch wieder auf der Kommandozeile mit dd (mit umgekehrten if– und of-Parametern), doch hier war ich zu Faul und habe stattdessen das quelloffene Etcher mit graphischer Oberfläche und Fortschrittsanzeige verwendet.

Übrigens: Nachdem ich das Image testhalber auf eine zweite SD-Karte zurückgeschrieben und verifiziert hatte, dass der Raspberry Pi 3 vom Backup bootet, habe ich das Image mit ZIP komprimiert und so eine Platzreduktion von 50 Prozent hingekriegt.

Tags: , , , , , , , ,
Labels: Uncategorized

Keine Kommentare | neuen Kommentar verfassen

Montag, 8. Mai 2017

tftp funktioniert über NAT nicht

Am Samstag habe ich an einer Aussenstelle einen Ubiquiti EdgeRouter-X installiert und so konfiguriert, dass alle Konfigurationsanpassungen mittels TFTP auf einen Server geschrieben werden. So möchte ich alle Anpassungen rückverfolgen und im Notfall auch eine „last known good“-Konfiguration einspielen können.

Auf dem Router bin ich der Anleitung EdgeRouter – Manage the configuration file gefolgt und habe folgenden Befehl eingegeben:

# configure
# set system config-management commit-archive location tftp://0.0.0.0/
# commit
# save

Nun musste ich auf einem Debian-Server noch TFTP installieren und ein Verzeichnis freigeben, in welches die Textdateien mit der Konfiguration abgelegt werden (Versioniert nach Name des Gerätes und dem Datum und der Uhrzeit der Anpassung).

Das ging der Anleitung Ubuntu / Debian Linux: Install and Setup TFTPD Server folgend spielend leicht:

# apt-get install tftpd-hpa

Meine individualisierte Konfigurationsdatei unter /etc/default/tftpd-hpa liest sich folgendermassen:

TFTP_USERNAME="tftp"
TFTP_DIRECTORY="/var/edgerouter"
TFTP_ADDRESS="0.0.0.0:69"
TFTP_OPTIONS="--verbose --secure --create"

Notabene: Die in tftpd allows connections, but times out transferring a file angegebenen Anpassungen an der Konfigurationsdatei waren nicht nötig.

Mit der Option --verbose loggt der TFTP-Server schön brav — und vor allem ausführlich(er) — nach /var/log/syslog:

...
May  8 19:37:46 SERVER systemd[1]: Starting LSB: HPA's tftp server...
May  8 19:37:46 SERVER tftpd-hpa[10636]: Starting HPA's tftpd: in.tftpd.
May  8 19:37:46 SERVER systemd[1]: Started LSB: HPA's tftp server.
May  8 19:38:15 SERVER in.tftpd[10999]: WRQ from 0.0.0.111 filename test.txt
May  8 19:38:25 SERVER in.tftpd[11009]: RRQ from 0.0.0.111 filename test.txt
...

Quelle: [syslinux] logging location of tftpd-hpa

Ein Fallstrick gibt es aber: Schreitet man zum Test, sollte man beachten, dass der Client und der Server direkt miteinander kommunizieren können, sprich dass kein NAT-Router zwischen den beiden Geräten steht. Grund: TFTP verwendet UDP, was über NAT nicht auf anhieb funktioniert.

Ich bis mir deswegen sicherlich eine halbe Stunde lang die Zähne aus, weil ich von meinem Mac mini aus Dateien hin- und herkopieren wollte, es aber nicht klappte. Die Verbindung konnte ich zwar herstellen, doch Dateioperationen waren nicht möglich:

$ tftp 0.0.0.0
tftp> get test.txt
Transfer timed out.

Der Grund: Der Mac mini kommuniziert per OpenVPN mit dem entfernten Netzwerk, und der OpenVPN-Router verwendet NAT.

Erst nachdem ich von Servern im selben Subnetz aus versuchte, Verbindungen herzustellen, realisierte ich, dass der Server seit langem funktionierte.

Labels: Uncategorized

Keine Kommentare | neuen Kommentar verfassen

Donnerstag, 2. März 2017

RainLoop Webmail: .vcf-Kontakte importieren

Mein neues OSS-Webmail RainLoop (eindeutig besser als RoundCube) versteht auch .vcf!

Die Option, einen Export aus Apples Contacts im .vcf-Format einzulesen, ist auf den ersten Blick etwas in der Oberfläche versteckt. Sie findet sich nicht etwa unter Einstellungen, sondern im Kontakt-Tool selber:

image-7192

Dort wählt man aus dem „Hamburger“-Menu die Option „Import (csv, vcf, vCard)“ aus:

image-7193

Der Upload und das Parsen meiner 935 KB grossen .vcf-Datei benötigte ungefähr 60 Sekunden, und dann standen alle Kontakte wie vom lokalen Desktop-Client her gewohnt zur Verfügung.

Das Beste: Da ich unter meinem RainLoop-Hauptaccount fünf Mailkonten vereine (sprich: mittels einem Login erhalte ich Zugriff auf gleich fünf meiner Mailkonten), standen die Kontakte unter jedem Mailkonto zur Verfügung. Der von mir befürchtete fünffache Export erübrigte sich.

Wichtig: Wer wie ich die Apple Contacts mit Photos angereichert hat, muss diese zuerst entfernen, sonst gibt es Probleme mit dem Parser von RainLoop (nach dem langwierigen Upload der 19.2 MB grossen .vcf-Datei). Zuerst markiert man in Contacts alle Einträge und legt diese mittels Drag & Drop in einen lokalen Ordner ab. Anschliessend wendet man mein auf GitHub gehostetes Python-Script auf die Datei an und erhält nun eine deutlich kleinere .vcf-Datei, welche auch mit RainLoop kompatibel ist.

Tags: , , , , , , , , , , ,
Labels: Uncategorized

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 19. Februar 2017

ELK: snmpd: Cannot statfs

Seit einer Woche läuft auf einem Laptop bei mir zu Hause der ELK-Stack und sammelt per Syslog die Logs aller meiner Devices an drei Standorten. In unregelmässigen Abständen werde ich hier über Erkenntnisse berichten, die ich dank der zentralisierten Analyse der Logs gemacht habe.

Heute geht es um snmpd und Mounts, deren Attribute der Daemon nicht auslesen kann. Dies äussert sich auf ELK mit folgenden Log-Meldungen:

... snmpd[1234] Cannot statfs /var/lib/docker/containers/: Permission denied ...
... snmpd[1234] Cannot statfs /var/lib/docker/aufs/mnt/: Permission denied ...
... snmpd[1234] Cannot statfs /run/docker/netns/: Permission denied ...
... snmpd[1234] Cannot statfs /run/user/1000/gvfs: Permission denied ...
... snmpd[1234] Cannot statfs /sys/kernel/debug/tracing: Permission denied ...

Ich versuchte mit verschiedenen Einträgen in /etc/snmp/snmpd.conf das auslesen dieser Mounts zu verhindern. Zuerst mittels der Direktive ignoredisk:

...
ignoredisk /run/user/*
ignoredisk /var/lib/docker/containers/*
ignoredisk /var/lib/docker/aufs/mnt/*
ignoredisk /run/docker/netns/*
ignoredisk /sys/kernel/debug/tracing
...

Das Blacklisting hatte leider keine Wirkung.

Auch der umgekehrte Weg, das Whitelisting, funktionierte nicht:

...
#includeAllDisks 10%
disk / 10%
...

Nach längeren Recherchen im Netz musste ich zum Schluss kommen, dass man solche Meldungen nicht mit Anpassungen an der SNMP-Konfiguration unterdrücken kann. Der Grund:

Because as I wrote in comment #2, snmpd reads /proc/mounts and runs statfs on each entry there. If any statfs call fails it logs an error. So, either stafs must not fail (i.e. no „net:[4026532288]“ entries in /proc/mounts) or snmpd must be fixed to log something more useful and only once.

Quelle: Bug 1314610 – snmpd complaining twice „Cannot statfs net:[********]#***: No such file or directory“ every 10 minutes

snmpd iteriert über die Einträge in /proc/mounts und führt ein statfs auf jeden Mountpoint durch. Das ist der Moment, in dem die Fehlermeldung geloggt wird.

Eine potentielle Lösung:

There needs to be an option to just make snmpd not try to look at these sort of mount points. The problem is that ignoreDisk only works for the devices, not mount points and a tmpfs has no „device“ name to match it by.

Quelle: snmpd storage reports all tmpfs and floods logfile

Dem Problem begegne ich nun, indem ich mit rsyslog solche snmpd-Fehlermeldungen ausfiltere und nicht zu Logstash übermittle. Der Filter dazu lautet:

...
if $programname == 'snmpd' and $msg contains 'statfs' then {
    stop
}
...

Tags: , , , , , , ,
Labels: Uncategorized

Keine Kommentare | neuen Kommentar verfassen