Vor Kurzem habe ich, mein komplettes Heimnetzwerk mit Komponenten von Ubiquiti UniFi neu aufgebaut.

Dafür habe ich mir folgende Geräte angeschafft:

• Ubiquiti UniFi Security Gateway (USG)
• Ubiquiti UniFi Switch US-8-60W
• Ubiquiti UniFi Switch US-8
• Ubiquiti UniFi AP AC Lite

So als Informatiker stellt man sich die Welt ja immer einfach vor. Man kauft ein neues Spiel - und spielt das dann. Utopisches Wunschdenken von mir, ist ja klar.

In diesem Fall geht es um das Spiel Anno 1404, dies hatte ich mir mit einem Kollegen aufgrund des Coop-Modus über die Plattform Steam gekauft.

Das Spiel ist aus 2009, man sollte also erwarten können, dass dort alles funktioniert. Naja...

Kaufgrund war wie gesagt der Coop-Modus. Blöd nur, dass beim Versuch den Internet-Multiplayer zu starten, immer die Meldung "Es konnte keine Verbindung zum Internetserver hergestellt werden" kam. Eine kurze Recherche im Internet ergab, dass wir mit diesem Problem nicht alleine sind. Viele Einträge waren aus dem Jahr 2010 und endeten immer mit: "Spiel zurückgeschickt".

Neulich ist ja mit KRACK eine Schwachstelle in WPA2 gefunden worden. Jetzt sind rund zwei Wochen vergangen und ich wollte einmal meine Geräte patchen.

Tja, was soll ich sagen, von meinen drei W-LAN APs kann ich genau einen updaten, den Ubiquiti UniFi UAP AC LITE.

Ubiquiti hatte hier wirklich sehr schnell reagiert, und ein Update für seine Geräte bereitgestellt.

Das Problem wurde mit der Firmware 3.9.3.7537 behoben.

Neulich ist mir aufgefallen, dass wenn ich auf meinem Ubuntu 15.10 Desktop ein Video mit dem VLC Player abspiele, ich fast an Screen Tearing sterbe.

Also wenn sich das Bild langsam bewegt, das Bild komplett zerrissen ist. Ihr kennt das von Computerspielen. Stichwort: Vertikale Synchronisation.

Der PC nutzt einen Intel Grafikchip. Um das Ganze zu beheben, muss man in die Datei /usr/share/X11/xorg.conf.d/20-intel.conf den folgenden Inhalt einfügen.

Section "Device"
   Identifier  "Intel Graphics"
   Driver      "intel"
   Option      "TearFree"     "true"
EndSection

Nach einem Reboot sollte das Problem behoben sein.

Es reicht natürlich auch, wenn ihr nur den X-Server neustartet. X-Server mit STRG + ALT + BACKSPACE neustarten

Für die letzten drei Tage, war ich im Carrier NAT von meinem ISP "gefangen". Über diese Zeit möchte ich etwas berichten.

Alles fing mit einer ganz harmlosen Benachrichtigung meines Monitorings an, dass sich meine IP-Adresse geändert hat. Mein ISP ist ein Kabelanbieter, deshalb passiert das nicht sonderlich oft.

Danach konnte ich meine Dienste, welche Zuhause laufen, nicht mehr erreichen. Weder über die neue externe IP-Adresse noch über den DNS Namen.

Nach zwei Tagen keine Besserung

Nach zwei Tagen, hat mich mein Monitoring wieder daran erinnert, dass ich der Sache doch mal bitte auf den Grund gehen solle.

Heute möchte ich gerne über die Installation und Konfiguration von Apt-Cacher-ng schreiben. Dabei handelt es sich um einen Caching-Server für Debian und Ubuntu Repositories.

Der Clou and der Sache ist, auch Repositories für openSUSE (oder andere Distributionen) können von Apt-Cacher-ng im Cache gehalten werden.

Warum?

Nun, in Zeiten von schnellem Internet könnte sich der ein oder andere fragen, für was man noch einen Cache für Repositories benötigt.

In Unternehmen sieht dies allerdings schon wieder etwas anders aus. Dort teilen sich viele Menschen oder Computer die Bandbreite. Des Weiteren macht einem eventuell der Proxy-Server oder die Firewall Probleme.

Gerade wenn man viele Systeme updaten möchte, ist es sehr bequem, wenn die Anfragen einfach aus dem Cache beantwortet werden.

Gerade wenn man mit verteilten Computersystemen (z. B. Cluster) arbeitet, spielt die Latenz des Netzwerkes eine große Rolle, wenn es um sachen Performance geht.

Eventuell dauert die Replikation der Datenbank nicht lange, weil die Platten dicht sind, sondern einfach weil die Latenz zu Groß ist, oder die Verbindung einen hohen Package Loss aufweist.

Grund genug also zu testen, ab welcher Latenz oder Bandbreite es kritsch wird und ob etwas am Setup optimiert werden kann/sollte.

Zum Glück kann man in Linux, mit dem Tool tc, sehr einfach Manipulationen am Netzwerk durchführen.

Um den Versuch durchzuführen, benötigt man zwei oder mehr Systeme. Zusätzlich sollte man sich überlegen, welche Metriken man im Auge behalten möchte. Stauen sich irgendwo Dateien an, welche kopiert werden sollten? Bricht die Performance der Datenbank Replikation ein? Und so weiter...

Seit etwas über einem halben Jahr überwache ich jetzt mein Raumklime mit Naemon und Grafana. Die ganze Zeit habe ich die Daten über einen Raspberry Pi gesammelt, an dem ein DHT22 Sensor angeschlossen war.

Nun habe ich das umgebaut, auf einen NodeMCU mit ESP8266 Chip.

Hier nochmal der Link, zum alten Beitrag.

Für ein neues Projekt, habe ich mir ein 1.8" TFT Display ST7735R für das Arduino bestellt.

Was ich damit genau bauen möchte, werde ich in einem weiteren Beitrag zeigen. Zuerst einmal hat es mich ganz schön lange beschäftigt, das Display überhaupt ans Laufen zu bekommen.

Ich persönlich bin kein Freund von Universalfernbedienung, da oft wichtige Tasten fehlen oder nicht richtig funktionieren wollen.

Allerdings ist es auch lästig, dass "Fernbedienungschaos" Gästen zu erklären. Was also tun?

Nun, ich wollte gerne etwas, das man über das Handy bedienen kann, aber nicht meinen Geldbeutel unnötigt belastet.

Außerdem möchte ich die Sender direkt einspeichern können, also das ich für jeden Sender eine Taste habe, und mir die Nummern nicht merken muss.

Das klingt doch irgendwie perfekt, um es mit einem Arduino einfach selber zu bauen.

Bei mir ist das Projekt aufgrund von Platz- und Kommunikationsproblemen drei mal umgezogen.

Angefangen hatte ich auf einem Arduino UNO, wo allerdings der Speicherplatz nicht gereicht hatte. Also habe ich auf ein Arduino MEGA gewechselt. Aktuell nutze ich ein NodeMCU mit einem ESP8266, da die Kommunikation über WLAN viel praktischer ist.

Hier schonmal eine Vorschau, auf das Ergebnis.

Weiter lesen