UniFi: Access Point schaltet Radio ab ohne Controller

Beim Updaten des Betriebssystems auf dem mein Unifi Controller läuft hatte ich vor kurzem ein sehr ärgerliches Problem: Als der Controller abgeschaltet war hat der Access Point nach ca. drei Minuten aufgehört das WLAN auszustrahlen. Das ist Blöd, wenn der Laptop in dem weggebrochenen WLAN hängt.

Nur weil der Controller nicht erreichbar ist sollte der Access Point aber nicht aufhören das WLAN auszustrahlen. Dieses Verhalten kann man auch einstellen. Die Entsprechende Einstellung befindet sich in den Site-Setting und heißt „Enable connectivity monitoring and wireless uplink“:

 

Source: https://community.ubnt.com/t5/UniFi-Wireless/What-does-Uplink-Connectivity-monitor-do/td-p/1561335

UniFi Controller: TLS Zertifikat tauschen

Ich habe sehr lange die D-Link DAP-1665 für mein WLAN an meinen Wohnorten benutzt. Leider bin ich vom Handling und von der Performance her nicht wirklich überzeugt gewesen und habe deswegen auf Access Points von Ubiquity Networks geupgraded. Genauer gesagt auf die UniFi AP AC Lite.
Hersteller: https://www.ubnt.com/unifi/unifi-ap-ac-lite/
Amazon: http://amzn.to/2hMw3Fi

Die Besonderheit bei diesen Geräten ist, dass die Access Points von einem Controller gesteuert werden. Die WLAN Einstellungen und viele weitere Optionen werden zentral über dieses Managment Tool gesteuert. Im professionellem Umfeld  ist ein arbeiten ohne Controller überhaupt nicht denkbar. Im privatem Umfeld sind solche Systeme nicht üblich, da sie normalerweise sehr teuer und umständlich sind. Ubiquity hat mit seinen 100 € Access Points und kostenloser Controller Software aber ein tolles Produkt für dein Heimanwender geschaffen. Ein ganzes Haus zum Beispiel mit 4-8 Access Points effizient abzudecken sind somit kein Problem mehr.

Die Controller Software ist in Java implementiert und hat als Benutzerschnittstelle eine Weboberfläche. Diese ist standardmäßig mit TLS abgesichert, jedoch muss dazu ein valides Zertifikat erstellt werden, damit der Browser nicht permanent vor einer unsicheren Verbindung warnt.
Um die Weboberfläche mit einem eigenen SSL/TLS Zertifikat auszustatten, muss man ein bisschen basteln, da diese keine Möglichkeit zum Austausch bietet. Read More „UniFi Controller: TLS Zertifikat tauschen“

postfix „cannot find your hostname“ und „transport smtp failure“

Ich habe meinen Root-Server umgezogen von Debian 8 auf Arch Linux. Bei postfix (aktuell in der Version 3.1.3 hatte ich zwei Phänomene.

Reverse Lookup schlägt fehl mit „cannot find your hostname“

Unschöne Logmeldungen tauchten auf:

Dez 20 22:35:04 mineralwasser postfix/smtpd[31080]: Anonymous TLS connection established from unknown[2607:f8b0:4001:c06::245]: TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)
Dez 20 22:35:04 mineralwasser postfix/smtpd[31080]: NOQUEUE: reject: RCPT from unknown[2607:f8b0:4001:c06::245]: 450 4.7.25 Client host rejected: cannot find your hostname, [2607:f8b0:4001:c06::245]; from=<3HENWWAcLBcMwx0nyu77x323kn.lxvqnuux4nuxlA27.mn@youtube-subscriptio
Dez 20 22:35:05 mineralwasser postfix/smtpd[31080]: disconnect from unknown[2607:f8b0:4001:c06::245] ehlo=2 starttls=1 mail=1 rcpt=0/1 data=0/1 quit=1 commands=5/7

Mein Postfix ist so konfiguriert, dass der Reverse DNS Eintrag zum angegebenen HELO Hostname passen muss. Ist das nicht der Fall, dann wir die E-Mail nicht angenommen. Diese Maßnahme filtert viele spamversendende E-Mail Server weg. Diese Regel wollte ich also nur ungern deaktivieren.
Eine manuelle Rückwärtsauflösung funktioniert jedoch einwandfrei. Es handelt sich also nicht um ein DNS Problem. Als nächstes hatte ich systemd-resolved in Verdacht. Da dieser Service aber nicht aktiviert ist musste es doch an postfix liegen.
Den entscheidenden Hinweis gab folgende Logmeldung:

/etc/postfix/master.cf: line 47: using backwards-compatible default setting chroot=y

Read More „postfix „cannot find your hostname“ und „transport smtp failure““

Install Icinga 2 on pfSense 2.3

pfSense 2.3 is using FreeBSD 10.3 as base. Needless to say that my firewall has to be in my monitoring. The install procedure isn’t as easy as expected.
pfSense 2.3 is since this version fully using the pkg infrastucture which should be well known by the BSD users. But it doesn’t provide a „pkg –install-dependencies“ command :-( You have to resolve them by hand. The needed links are:

http://pkg.freebsd.org/freebsd:10:x86:64/latest/All/bash-4.3.46_1.txz
http://pkg.freebsd.org/freebsd:10:x86:64/latest/All/mysql56-client-5.6.30.txz
http://pkg.freebsd.org/freebsd:10:x86:64/latest/All/icu-55.1,1.txz
http://pkg.freebsd.org/freebsd:10:x86:64/latest/All/boost-libs-1.55.0_12.txz
http://pkg.freebsd.org/freebsd:10:x86:64/latest/All/yajl-2.1.0.txz
http://pkg.freebsd.org/freebsd:10:x86:64/latest/All/postgresql93-client-9.3.13_2.txz
http://pkg.freebsd.org/freebsd:10:x86:64/latest/All/monitoring-plugins-2.1.2.txz
http://pkg.freebsd.org/freebsd:10:x86:64/latest/All/icinga2-2.4.10.txz

Each link have to be used with „pkg install <url>“. For example:

:-$ pkg install http://pkg.freebsd.org/freebsd:10:x86:64/latest/All/bash-4.3.46_1.txz

After all these steps you can normally work with Icinga 2. The config files are not stored the Linux way unter /etc/icinga2 but under /usr/local/etc/icinga2.

Icinga 2 auf pfSense 2.3 installieren

pfSense 2.3 benutzt als Basis FreeBSD 10.3. Und auch meine Firewall muss ins Monitoring. Leider war das etwas schwieriger als gedacht.
pfSense 2.3 benutz seit dieser Version vollständig die pkg Infrastruktur, die BSDler gewohnt sind. Leider gibt es kein „pkg –install-dependencies“ Kommando. Abhängigkeiten müssen selbst installiert werden :-(

Damit pfSense trotzdem aus den Repos (auf BSD nennt man die Ports) installiert werden, muss man selber Hand anlegen.

http://pkg.freebsd.org/freebsd:10:x86:64/latest/All/bash-4.3.46_1.txz
http://pkg.freebsd.org/freebsd:10:x86:64/latest/All/mysql56-client-5.6.30.txz
http://pkg.freebsd.org/freebsd:10:x86:64/latest/All/icu-55.1,1.txz
http://pkg.freebsd.org/freebsd:10:x86:64/latest/All/boost-libs-1.55.0_12.txz
http://pkg.freebsd.org/freebsd:10:x86:64/latest/All/yajl-2.1.0.txz
http://pkg.freebsd.org/freebsd:10:x86:64/latest/All/postgresql93-client-9.3.13_2.txz
http://pkg.freebsd.org/freebsd:10:x86:64/latest/All/monitoring-plugins-2.1.2.txz
http://pkg.freebsd.org/freebsd:10:x86:64/latest/All/icinga2-2.4.10.txz

Diese Links führt man nun nacheinander auf der Konsole un dem Prefix „pkg install <url>“ aus. Also zum Beispiel:

:-$ pkg install http://pkg.freebsd.org/freebsd:10:x86:64/latest/All/bash-4.3.46_1.txz

Danach kann man ganz normal mit Icinga 2 arbeiten. Die Konfig Dateien liegen aber nicht (wie auf Linux gewohnt) unter /etc/icinga2 , sondern unter /usr/local/etc/icinga2.

Tor: Shutdown meines Exit Relays

Vor zwei bis drei Wochen habe ich mein Tor Exit Relay heruntergefahren. Der Grund hierfür ist der Umgang der Tor „Community“ über die Vorwürfe gegen ioerror. Viele Threads gingen auf den Mailing Lists auf und alle spekulierten wild rum. Niemand lieferte Beweise und viele Opfer versteckten sich in der Anonymität.
Das Verhalten der sogenannten Community hat mich zutiefst bestürzt. Danach habe ich beschlossen mein Relay abzuschalten und das Projekt nicht weiter zu unterstützen.

Der Daemon ist deinstalliert und die Keys wurde sicher gelöscht. Ich habe mich von allen Mailinglisten abgemeldet. Die negativen Seiten von Tor überwiegen damit für mich.

Icinga2 Notifications sent over Pushover.net

I recently switched to Pushover.net for sending my Icinga 2 notifications on my smartphone.

Edit the script

Pushover published many sample implementation scripts on their website. I use the perl and adapted it a bit. It’s stored on my master server under /etc/icinga2/scripts/pushover.pl and contains

#!/usr/bin/perl

use LWP::UserAgent;
use Mozilla::CA;

LWP::UserAgent->new()->post(
 "https://api.pushover.net/1/messages.json", [
 "token" => "myapitoken",
 "user" => "myusertoken",
 "message" => $ENV{'message'},
 "title" => $ENV{'title'},
]);

Read More „Icinga2 Notifications sent over Pushover.net“

Icinga 2: High inode usage in /var/spool/icinga2/perfdata

Just a short post because the topic is not very hard. My Icinga 2 notified me of high inode usage on my master server. Thanks to Stackexchange I’ve got an one line command to display the directories with high inode usage:

:~$ find / -xdev -printf '%h\n' | sort | uniq -c | sort -k 1 -n

The output was:

   1122 /usr/share/man/man1
   2360 /usr/share/man/man3
   3150 /var/lib/dpkg/info
  30497 /var/lib/grafana/png
 896245 /var/spool/icinga2/perfdata

The directory /var/spool/icinga2/perfdata held nearly 900.000 files. These contained performance data from previously done checks. The Icinga 2 feature to „blame“ for this behaviour is perfdata. I activated that feature because I believed I wouldn’t get any performance data at all without it. Thats false. You can safely deactivate it:

:~$ icinga2 feature disable perfdata
:~$ systemctl reload icinga2.service

Afterwards you can remove the already stored files either each file on its own:

:~$ find /var/spool/icinga2/perfdata -type f -delete

or the whole directory at once:

:~$ rm -rf /var/spool/icinga2/perfdata

Icinga 2: Hoher inode Verbrauch unter /var/spool/icinga2/perfdata

Nur ein kurzer Blogeintrag, weil man da Thema nicht wirklich unnötig lange ausformulieren muss. Mein Icinga 2 hat mich darauf hingewiesen, dass mein Master Server einen hohen inode Verbrauch hat. Dank Stackexchange habe ich einen Einzeiler erhalten, der mir den inode Verbrauch in Ordnern aufsummiert und sortiert:

:~$ find / -xdev -printf '%h\n' | sort | uniq -c | sort -k 1 -n

Die Ausgabe in meinem Fall war:

   1122 /usr/share/man/man1
   2360 /usr/share/man/man3
   3150 /var/lib/dpkg/info
  30497 /var/lib/grafana/png
 896245 /var/spool/icinga2/perfdata

Im Ordner unter /var/spool/icinga2/perfdata waren knapp 900.000 Dateien. In diesen stehen die Performance Werte von ausgeführten Checks drinnen. Verursacht werden diese Anhäufung durch das Icinga 2 Feature perfdata.
Ich hatte das damals aktiviert, weil ich dachte, dass ich nur so Performance Daten weitergeben kann. Dies ist aber nicht der Fall. Deaktivieren kann man es einfach via:

:~$ icinga2 feature disable perfdata
:~$ systemctl reload icinga2.service

Die bereits gespeicherten Daten kann man gefahrlos entfernen. Entweder man löscht alle Dateien einzeln mit

:~$ find /var/spool/icinga2/perfdata -type f -delete

oder gleich den gesamten Ordner:

:~$ rm -rf /var/spool/icinga2/perfdata