Kategori public

Der vim Mausmodus unter Debian 9

Freitag, November 17th, 2017

Unter Debian 9 Stretch hat vim eine neue default Einstellung bekommen, den Mouse Modus. Möchte man Texte per Maus kopieren bzw in die Zeichenablage legen dies nicht mehr.

Ich habe mir zum editieren der vim Konfiguration Datei folgenden Einzeller geschrieben, den ich einmalig ausführen muss:

Was macht er im Detail:
In der /usr/share/vim/vim80/defaults.vim muss unter folgender Sektion der set mouse Parameter auskommentiert werden.

systemd KillMode und systemd-run

Sonntag, Oktober 8th, 2017

Für eine Video Projekt habe ich ein Script das in einer Schleife ein Einminütiges Video erstellt und dieses danach verarbeitet. Damit man die Erstellung sauber beenden kann, habe ich beim Starten eine Datei angelegt und zum beenden wird diese Datei wieder gelöscht. In der schleife wird immer abgefragt ob diese noch Existiert:

So kann man das Skript sehr gut von „außen“ steuern. Ein weiteres Script zum verarbeiten, das sich ebenfalls in der schleife befindet, habe ich geforkt.

Nun habe ich das Script auf einen systemd Service umgestellt, bei dem ich auf zwei Probleme gestosen bin.
1. Systemd beendet das Script und alle hiervon aufgerufenen Programme ebenfalls mit Signal 15. Das bedeutet das, dass Video erstellen und verarbeiten umgehend unterbrochen werden.
2. Das „verarbeitung.sh“ Script ist eigentlich vollkommen unabhängig und es muss nicht auf dessen Beendigung gewartet werden.

Lösung:
Im SystemD Services habe ich den Kill Mode auf Mixed umgestellt. Das Sendet nur noch an eigentliche Script ein Signal 15. Hier tiggert dann der trap und löscht die Datei zum Beenden der Schleife.

Den fork habe ich mit mit systemd-run in eine eigene Unit verfrachtet. Somit kann die Verarbeitung abgeschlossen werden und SystemD kann den Dienst als beendet erklären.

Einführung in Docker

Freitag, August 25th, 2017

Hier eine Kurzzusammenfassung wie man mit Docker sein erstes Projekt starten kann und worauf man achten sollte.

Installation:
Die Installation ist mittlerweile trivila einfach:

Wenn man docker als System Benutzer ausführen möchte. muss dieser in der Gruppe docker sein.

Das Dockerfile:
Das Dockerfile beschreibt was gemacht werden soll. Fangen wir langsam an und setzen eine Instanz mit einem Webserver mit PHP Unterstützung auf:

Im Detail: Die „FROM“ Zeile beschreibt das zugrunde liegende Image. In unserem fall ist das Ubuntu in der Version 14:04. Die liste der Images findet man hier: hub.docker.com

Die Zeile RUN beschreibt was beim Prozesse des bauen eines Docker Container gemacht werden soll. An dieser stelle habe ich alle apt befehle hintereinander geschrieben, da Docker für jedes einen eigenen Layer erzeugt. Dies hat vor und Nachteile.

Dann starten wird das ganze doch mal:

Mit „docker build“ wird das Image gebaut. Mit der Option -t geben wird dem ganzen noch einen beliebigen Namen und der Punkt besagt das das Dockerfile aus dem aktuellen Verzeichnis verwendet werden soll.

Nach dem Bauen können wir den Container Starten. Zunächst habe ich mit der Option „-v“ das Verzeichnis in dem wir uns gerade befinden im den Container an die Stelle /var/www/html gemountet. Mit der Option -i und -t mit dem bekommen wir im zusammen Spiel mit dem abschließenden Aufruf von /bin/bash einen Interaktiven zugriff auf den Container. Die „–rm“ Option löscht nach beenden der Interaktiven Shell auch den gesamten Container. Dies würde Docker sonst nicht machen und es würde sehr viel Datenmüll entstehen. Da wir dem ganzen einen Namen gegeben haben müssen wir nicht umständlich nach nach der beim Bauen des Container erzeugten ID suchen sondern könne einfach loslegen:

In diesem Container ist nun noch nichts gestartet. Nach dem Starten des Webservers mittels /etc/init.d/apache2 start kann mit einem Webbrowser die Seite angezeigt werden. Hierfür sucht man sich die Aktuelle IP herraus: ip a und gibt diese im Webbrowser an.

spam aus Panama

Samstag, April 1st, 2017

Einige zeit lang hat es mich genervt das es Spam Server gibt, die von Domains verschicken die ausschließlich in Panama Register sind. Die sind mittlerweile so dreist das sie Spam score werte erreichen, die weit negativ sind, da bei ihnen alles stimmt. Aber eine Gemeinsamkeit haben Sie, neben dem whois Eintag das Sie aus Panama stammen, auch noch. Sie haben alle FreeDNS Einträge von Namecheap Inc. Ops die kann man getrost droppen:

In der /etc/postfix/main.cf habe ich den smtpd_recipient_restrictions folgende Eintrag angefügt:

Dann habe ich die Datei /etc/postfix/blacklist_ns.cf angelegt:

Anschließend habe ich die hash table erstellt:

Nach dem neu laden des Postfixes fand ich wenige Sekunden später folgendes im log:
postfix/smtpd[..]: connect from mx4.siegertarifpkv.com[...]
postfix/smtpd[..]: Anonymous TLS connection established from mx4.siegertarifpkv.com[...]: TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)
postfix/smtpd[..]: NOQUEUE: reject: RCPT from mx4.siegertarifpkv.com[...]: 554 5.7.1 : Sender address rejected: Sender-Domain is registered at WhoisGuard Panama / Namecheap Inc; from= to= proto=ESMTP helo=
postfix/smtpd[..]: disconnect from mx4.siegertarifpkv.com[...]

Kernel Bug in CentOS 7

Sonntag, Februar 12th, 2017

Nach dem neu starten unserer VServer Plattform mit dem Kernel 3.10.0-514, traten nach sofort nach dem Booten folgende schwerwiegenden Fehler im Log auf:

kernel: Buffer I/O error on dev dm-15, logical block 8892681, lost async page write
kernel: sd 4:0:0:0: [sdc] FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
kernel: sd 4:0:0:0: [sdc] Sense Key : Not Ready [current]
kernel: sd 4:0:0:0: [sdc] Add. Sense: Logical unit communication failure
kernel: sd 4:0:0:0: [sdc] CDB: Write(16) 8a 00 00 00 00 00 37 7d 48 00 00 00 40 00 00 00
kernel: blk_update_request: I/O error, dev sdc, sector 930957312
kernel: sd 4:0:0:0: [sdc] FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE

Aber auch folgende syslog events traten auf, nachdem mittels:

lvmcreate -L 10G -n lv_snapshot -S vg/lv

ein snapshot erzeugt wurde.

kernel: EXT4-fs (dm-28): INFO: recovery required on readonly filesystem
kernel: EXT4-fs (dm-28): write access will be enabled during recovery
kernel: EXT4-fs warning (device dm-28): ext4_clear_journal_err:4718: Filesystem error recorded from previous mount: IO fail
ure
kernel: EXT4-fs warning (device dm-28): ext4_clear_journal_err:4719: Marking fs in need of filesystem check.
kernel: EXT4-fs (dm-28): recovery complete
kernel: EXT4-fs (dm-28): mounted filesystem with ordered data mode. Opts: (null)
kernel: EXT4-fs (dm-28): INFO: recovery required on readonly filesystem
kernel: EXT4-fs (dm-28): write access will be enabled during recovery
kernel: EXT4-fs (dm-28): orphan cleanup on readonly fs
kernel: EXT4-fs (dm-28): 6 orphan inodes deleted
kernel: EXT4-fs (dm-28): recovery complete

Schlimmer noch, die VMs wechselten nach kurzer Zeit in den read only Modus. Und konnten ohne erweitertes Filesystem Check nicht wieder gestart werden.

Zugglück sind wir schnell auf den Kernel Parameter gekommen, der das Problem verursacht hat.

Dieser Wert war bei älteren Servern noch auf 512 eingestellt. Bei den von dem Bug betroffenen Server durfte er nicht über 4096 eingestellt sein, stand aber immer wieder auf 8192.

Der CentOS Bug Report 12725, in dem das selbe verhalten mittels:

parted -s /dev/sda unit s print

beschrieben wurdet, half uns den Fehler weiter auf den Kernel einzuschränken. Immer wenn eine Partitionsabfrage, oder eine Änderung am LVM Stattgefunden hat, änderte sich der Wert plötzlich wieder auf 8192.

Folgende udev Regel, die wir unter /etc/udev/rules.d/99-san.rules eingefügt haben, verhinderte das umstellen des wertes:

Fazit:
Ein so schwerwiegenden Kernel Bug ist mit schon lange nicht mehr untergekommen. Er hatte für uns zufolge das wir bei einzelnen VMs nur noch teile retten konnten und komplett aus dem Backup wiederhergestellt werden mussten. Auch das Rechercheiren des Bugs ist bei CentOS kaum möglich. Da es zu RedHat binär kompatibel kann man nicht einfach durch ein git repository zu scrolen und sich die Änderungen und Kommentare anschauen. Wo bei mir die Überlegung offen ist, zukünftig auf einen Vanilla-Kernel zu wechseln und/oder CentOS zu vermeiden.

Unser Kernel: 3.10.0-514.6.1.el7.x86_64
Quelle Burgreport: https://bugs.centos.org/view.php?id=12725