Docker meldet Chain DOCKER does not exist

Wenn docker beim Starten neuer Container die Meldung

Chain 'DOCKER' does not exist

ausgibt, dann bedeutet dies, dass für Docker keine IP-Talbes rules hinterlegt sind. Vermutlich kann das passieren, wenn man mit docker system prune aufräumt, so richtig sicher bin ich da aber auch nicht.

Falls der Fehler bei dir auch auftritt, kannst du ihn mit folgenden 3 Commands mittles root Permission auf dem entsprechenden Server lösen:


iptables -t nat -N DOCKER
iptables -t nat -A PREROUTING -m addrtype --dst-type LOCAL -j DOCKER
iptables -t nat -A PREROUTING -m addrtype --dst-type LOCAL ! --dst 127.0.0.0/8 -j DOCKER

Linux Server zeigt unterschiedliche Werte bei df und du

Wenn das Monitoring meldet, dass die Platte eines Servers voll läuft, ein

du -hs /*

aber deutlich weniger verwendeten Speicher anzeigt als man es per df sieht – dann gibts erstmal Verwunderung.

Eine google Recherche hat mich dann auf den Trichter gebracht, dass dies ein Zeichen von zwar gelöschten Dateien, aber noch offenen Dateihandles auf diesen liegen kann. Sprich, man hat zwar eine Datei gelöscht, aber ein Programm hat die Datei aktuell noch geöffnet. Dann ist zwar der Dateiname nicht mehr sichtbar, aber die Inhalte der Datei liegen noch immer auf der Festplatte und verbrauchen natürlich auch ensprechend Platz. In meinem Fall ist filebeat nicht mit einem Logrotate klar gekommen und hatte somit eine relativ große Log Dateien weiterhin geöffnet. Mit jedem Logrotate kam eine dazu…

Wie kann man das sichtbar machen? So:

lsof | grep "/var" | grep deleted

oder gleich mit

lsof | grep deleted

wobei man bei letzterem vielleicht ein paar Ergebnisse sieht, die berechtigt noch Handles offen halten.

Hier mal eine Beispielhafte Ausgabe:

Ganz links sieht man den Dienst bzw. Command, und in der ganz rechten Spalte die jeweilige Datei.

Normalerweise sollte es reichen, den entsprechenden Dienst einfach neu zu starten und das Problem ist erstmal behoben. Sollte der Fehler wieder auftreten, müsste dann evtl ein Update/Patch oder als letzte Möglichkeit ein kontrollierter regelmäßiger Neustart das Problem beheben.

raspberry pi 3 b+ will nicht booten

Die Geschwindigkeit meines Octopi Druckservers für meinen 3D Drucker hat mich in letzter Zeit etwas genervt, daher habe ich mir direkt einen ganz neuen Raspberry Pi 3 b+ bestellt. So wie immer dachte ich mir: Karte wechseln, booten, fertig. Aber nix da. Der neue Raspi bootet einfach nicht.

Ok, dann neues Image probiert, andere Karten, andere Kabel usw. Nichts half. Die rote LED blinkte immer nur in unregelmäßigen Abständen und auf meinem Monitor war nur das Bunte Viereck sowie das Blitzsymbol zu sehen, was eigentlich auf Stromprobleme hinweist. Was aber wiederum bei einem 2 oder auch 2.5 A Netzteil mit dicken Kabeln nicht sein kann.

Der Grund für das Problem war dann doch sehr einfach: man muss die SD Karte “richtig” formatieren ?…

Am besten lädt man sich dazu das offizielle Tool zum Formatieren von SD Karten runter (ja, das gibt es tatsächlich 🙂 ) und wählt dort bei der Formatierung “overwrite format” aus. Damit wird die komplette SD Karte einmal überschrieben. Anschließend spielt man mit einem Tool seiner Wahl ein AKTUELLES Raspbian oder Noobs Image auf, welches die Treiber für den neuen Raspberry enthält.

Im Falle von Octopi wie bei mir war es nötig, den aktuellen Nightly Build zu verwenden. Das letzte stable Release verwendet sogar noch die letzte Raspbian Version…

Beim Ausführungen von Java jnlp Anwendungen erscheint ein Access Denied Fehler

Beim Ausführen einer Java Anwendung mit einer jnlp Datei bekam ich komischerweise immer wieder Fehlermeldungen „java.io.FilePermission“ für die Datei „/usr/bin/xprop“. Die Datei war im System vorhanden und durfte auch von jedem ausgeführt werden, selbst mit Sudo kam der Fehler.

Die Lösung des Problems ist zwar relativ leicht, aber mal wieder sehr ärgerlich: es ist ein Fehler in der OpenJDK und in meinem Fall der icedtea-netx Implementierung. Und um diesen zu umgehen muss man leider die original Oracle JAVA JRE runterladen und installieren.

Wichtig hierbei: man muss wohl zwingend die tar.gz Variante und nicht die RPM Variante nehmen, da nur diese „javasw“ enthält.

Das Vorgehen für die Installation ist:

  • openjdk und co vom System schmeissen (es geht auch anders, aber man muss die Sache ja nicht unnötig verkomplizieren)
  • unter http://www.oracle.com/technetwork/java/javase/downloads/index.html den Download Button unter „JRE“ anklicken und auf der folgenden Seite die AGB akzeptieren und dann die entsprechende tar.gz für 64bit oder 32bit herunterladen
  • tar.gz entpacken und den Ordner nach /usr/java/[ORDNER_NAME] verschieben
  • anschließend (keine Ahnung ob das der richtige Weg ist, aber er funktioniert) unter /usr/bin per Link die java und javasw Binaries verlinken:
cd /usr/bin
ln -s /usr/java/[ORDNER_NAME]/bin/java
ln -s /usr/java/[ORDNER_NAME]/bin/javasw

Nun könnt ihr die jnlp Datei einfach per
javasw [DATEI].jnlp aufrufen.

WPA2 kann geknackt werden ?

Und zwar nicht eine Implementierung eines Herstellers, sondern der Standard selbst. Aber die gute Nachricht ist: es ist möglich, die Lücke zu schließen und dabei trotzdem kompatibel mit gepatchten als auch ungepatchten Systemen zu bleiben.

WPA2 führt beim Beitritt eines neuen Gerätes einen 4-Wege Handshake durch, bei dem der gemeinsame Encryption Key ausgehandelt wird. Bei der 3. Nachricht des 4-Wege Handshakes teilt der Access Point dem Client den Encryption Key mit und wartet auf die Bestätigung durch den Client. Da diese 3. Nachricht ja auch mal durch Paketverlust oder ähnliches verloren gehen kann, ist es möglich, diese erneut zu senden. Und genau das ist die Schwachstelle: der Angreifer kann dieses Paket mitlauschen und es dann immer und immer wieder an den Client schicken. Jedes mal, wenn dieser das Paket erhält, setzt er seine inkrementellen transmit/receive Packet Counter zurück und verhält sich so, als ob er gerade dem Netzwerk neu beigetreten ist. Durch diese ständigen Widerholungen kann der Angreifer das “Opfer” gezielt immer die gleichen Pakete verschicken lassen und diese dann relativ einfach knacken.

Besonders betroffen sind Linux und Android Systeme (besser gesagt wpa_supplicant in der Version 2.4), da ihnen durch einen Trick zusätzlich noch ein Schlüssel, der nur aus Nullen besteht, untergeschoben werden kann. Ab diesem Moment kann der komplette Netzwerkverkehr des entsprechenden Gerätes mitgelesen werden.

Die kompletten Details findet ihr hier: krackattacks.com

[Quicktip] Wie man go get und Atlasssian Stash bzw. Gitlab zusammen bringt

In meiner Tätigkeit als Jenkins Admin hat mir das Thema „go get“ und Stash viel Kopfzerbrechen bereitet. Letztendlich ist „go get“ eine Art Alias für git pull, jedoch wird da einige Magic angewendet. Im Normalfall – also mit github und auch plain git Repos funktioniert das ganze wunderbar, sobald man aber Software wie Gitlab oder Stash verwendet, wird es etwas problematisch. Zum einen ist das „.git“, welches sowohl Gitlab als auch Stash an jedes Repo hängen ein Problem, zum anderen aber auch SSH über alternative Ports.

Zum Problem der „.git“ Endung: hängt einfach ein weiteres „.git“ an euren „go get“ Command. Also:

go get git.mydomain.com/foo/bar.git.git

Etwas kniffliger ist die Verwendung eines alternativen Ports und ssh. Stash macht nämlich genau das – der ssh Port ist 7999 in der Default Config. Aber auch hierfür gibt es eine Lösung. Dazu müsst ihr die Datei „.gitconfig“ in eurem Home Folder editieren bzw. anlegen. Die Datei muss dann so aussehen:

[url "ssh://git@stash.yourdomain.com:7999/"]
insteadOf = https://stash.yourdomain.de/

Sobald ihr nun einen Checkout auf

https://stash.yourdomain.de/foo/bar.git 

macht, biegt Git diesen Request auf

ssh://git@stash.yourdomain.com:7999/foo/bar.git

um. Somit könnt ihr auf andere Ports gehen, komplett auf andere Domains umschreiben usw.

[Quicktip] Wie installiere ich ein CA Zertifikat unter Debian Linux

Wenn ihr ein CA Zertifikat bzw. das zugehörige pem File auf eurem Debian Linux installieren möchtet, dann sind folgende Schritte nötig:

  • pem File unter /usr/share/ca-certificates ablegen
  • Datei /etc/ca-certificates.conf editieren und um den gerade hinzugefügten Dateinamen ergänzen. Falls ihr die Datei direkt in /usr/share/ca-certificates hinterlegt habt, dann reicht [Dateiname].pem, wenn ihr einen Unterordner erzeugt habt, dann ist der Eintrag [Unterordner]/[Dateiname].pem
  • als root bzw. per sudo “update-ca-certificates“ ausführen. Dort sollte euch gemeldet werden, dass mindestens ein Eintrag hinzugefügt wurde
  • fertig 😉

[Quicktip] Vagrant up kann die Netzwerkinterfaces nicht starten

Wenn ihr mit

vagrant up

eine virtuelle Maschine starten wollt und während des Hochfahrens die Fehlermeldung kommt, dass das Interface eth1 (oder eth2 usw.) nicht hochgefahren werden konnte, dann probiert folgendes:

  • Virtualbox öffnen
  • die laufende Vagrant Maschine im Virtualbox beenden und anschließend dort auch wieder starten, damit ihr diese direkt steuern könnt
  • anschließend mittels User „vagrant“ und Passwort „vagrant“ einloggen
  • mittels “sudo su“ zu root wechseln
  • “/etc/network/interfaces“ mit vi aufrufen und alle Zeilen löschen, die nichts mit eth0 zu tun haben. In der Regel sollte über diesen Zeilen „# VAGRANT START“ stehen
  • Anschließend noch den Ordner “/etc/udev/rules.d/70-persistent-net.rules“ mittels “rm -rf“ löschen
  • die Maschine herunterfahren und Virtualbox beenden
  • nun mittels „vagrant up“ die Maschine wieder starten, sie sollte nun erfolgreich booten
  • sollte die Provisionierung nicht starten, dann führt anschließend noch ein „vagrant provision“ durch

[Quicktip] Aptitude meldet fehlerhafte Signaturen für Jenkins

Wenn ihr ein 

aptitude update

durchführt und die Meldung

W: GPG-Fehler: http://pkg.jenkins-ci.org binary/ Release: Die folgenden Signaturen konnten nicht überprüft werden, weil ihr öffentlicher Schlüssel nicht verfügbar ist: NO_PUBKEY 9B7D32F2D50582E6

erscheint, dann müsst ihr folgendes machen:

sudo apt-key adv --recv-keys --keyserver keys.gnupg.net 9B7D32F2D50582E6

Damit wird der angezeigte öffentliche Schlüssel auf den neuesten Stand gebracht und der Fehler hat sich erledigt. (9B7D32F2D50582E6 ist die Schlüssel-ID in meinem Fall, kann natürlich auch eine andere sein)