TP-Link Omada Controller als Docker installieren und einrichten

Hat man mehrere TP-Link OMADA Geräte, macht es Sinn, diese über einen zentralen Controller zu verwalten. Hat man vor, mehr als einen Accesspoint zu nutzen, kommt man an einem Controller gar nicht vorbei. Der Beitrag beschreibt die Ersteinrichtung und die Provisionierung eines ersten Gerätes.

Inhaltsverzeichnis

Docker Container einrichten

Für die Installation des Docker Containers bin ich der Anleitung von IT-Beratung Koch gefolgt, weshalb ich diesen Vorgang nicht im Detail beschreibe.

Einrichtung starten

Ist der Container eingerichtet und aktiv, kann man sich über https://IP-ADRESSE:8043 mit dem System verbinden.

Grundeinstellungen

Im folgenden werden die Logindaten für den administrativen Benutzer definiert. Diese Angaben erklären sich soweit von selbst.

Was die Verbindung zur TP-Link Cloud angeht, steht (zum Glück) noch jedem frei, ob man dieses Angebot nutzen möchte. Ich kenne die TP-Link Cloud aktuell nicht und kann Nutzen, Einschränkungen und Probleme nicht einschätzen.

Das Kennwort des administrativen Benutzers muss gewissen Vorgaben entsprechen:

Ich habe den Controller im ersten Schritt nur für die lokale Nutzung vorgesehen und den Cloud Access deaktiviert.

Neueinrichtung oder Wiederherstellung

Der folgende Schritt ermöglicht die Installation eines neuen Systems oder die Wiederherstellung aus einem Backup.

Für mich kommt nur die Konfiguration als neues System infrage.

Es startet ein Setup Prozess, der viele Funktionen des Controllers abfragt. Positiv anzumerken ist die vorhandene Suche in den Auswahlfeldern. Das erspart teilweise nerviges Scrollen in langen Auswahllisten.

Grundeinstellungen

Wieder positiv: Die Teilnahme am „Improvement Program“ ist per Standard nicht aktiviert.

Anlegen der ersten Site

Der Device Account ist der Benutzer, der bei neuen Geräten gesetzt wird, sobald Sie an den Controller gekoppelt werden:

Devices konfigurieren

Es folgt das Hinzufügen von vorhandenen Devices. Da bisher noch kein Omada fähiges Gerät aktiv im Netz ist, wird dieser Punkt per „skip“ übersprungen:

Configure WAN Settings Overrides

In diesem Schritt geht es darum, ob ein Gateway vorhanden ist und was mit dessen Konfiguration passieren soll.
Hat man kein Gateway oder ist das Gateway bereits konfiguriert, kann man den Schritt mit SKIP überspringen.
– Ist die Option deaktiviert, werden die Einstellungen eines alleinstehenden Gateways beim Einbinden in den Controller importiert.
– Ist die Option aktiv, werden die Einstellungen vom Controller auf das Gateway geschrieben. Die Warnung, dass dann der Internetzugang ggf. nicht mehr funktioniert, sollte man nicht unterschätzen.

Aktiviert man die Option kann man mehrere Voreinstellungen für ein Gateway vornehmen:

Aus der Liste kann das entsprechende Gateway ausgewählt werden. Welches hier passt, ist der Modellbezeichnung des Geräts zu entnehmen. Das steht sowohl auf der Verpackung, wie auch auf dem Gerät selbst.
Sobald man das Gerät ausgewählt hat, veränderen sich auch die verfügbaren Optionen. Z. B. kommt dann ein „USB Modem“ oder „SFP Ports“ hinzu.

Das „Online Detection Interval“ ist nur relevant, wenn man mit Load Balancing oder Failover arbeitet. Je kürzer das Intervall, um so schneller wird auf Veränderungen reagiert – allerdings erzeugt das natürlich Last und Traffic.

Weiterhin gibt es die Möglichkeit, die MAC Adresse des WAN Interface zu manipulieren.

Der Typ des WAN Interfaces kann vielfältig eingestellt werden und richtet sich ggf. auch nach dem oben ausgewählten Modell.

Configure Wi-Fi

WiFi zu konfigurieren, macht natürlich nur Sinn, wenn man passende Accesspoints zur Verfügung hat. Aus diesem Grund habe ich diesen Schritt übersprungen.

Ist der Einrichtungsassistent durchlaufen, wird noch eine Zusammenfassung angezeigt, die man mit „Finish“ aktivieren kann.

Login und App

Nach Beenden des Setups wird man zum Login an den Controller weitergeleitet und erhält hier noch einen Hinweis auf die Omada App. Ob man diese auch nutzen kann, wenn man keinen Cloud Access aktiviert hat, muss sich noch herausstellen.

Fazit

Die Einrichtung eines Omada Controllers ist keine große Herausforderung. Natürlich ist es wichtig, dass man die Möglichkeit hat, einen Docker Container zu platzieren oder den Controller auf einem anderen System nutzen kann. TP-Link bietet hier Softwarepakete für Windows oder Linux an.

Selbstverständlich kann man auch einen Hardware Controller wie dem OC200, OC300 oder OC400 nutzen.

Festplatte in Technisat ISIO S tauschen

Der Technisat ISOS S ist ein dualer SAT Receiver mit Festplatte zum Aufnehmen. Nachdem die eingebaute Festplatte in der letzten Zeit immer mehr durch ihre Lautstärke nervt, wollte ich mich jetzt mal damit beschäftigen, ob man die Festplatte tauschen kann. Nach den vielen Jahren im Einsatz sollte auch jeglischer Garantieanspruch erloschen sein.

Das Öffnen des Gerätes ist kein Problem. Zwei Torx(!) TX10 Schrauben an der Seite und vier auf der Rückseite lösen, das Garantiesigel beseitigen und man kann den Deckel abnehmen.
Innen sieht es mal wieder unspektakulärer aus als man annehmen würde. Eine Platine, ein Festplattenkäfig mit einem nervigen 50mm Lüfter und viel Luft.

Sehr erfreulich ist die Lösung für die Festplatte. Es handelt sich um eine ganz normale SATA 3,5″ Festplatte (bei mir eine Western Digital Green mit 500GB). Auf der Platine ist sie mit einem Standard SATA Kabel angeschlossen.
Die Disk ist mit Gummischeiben vom Gehäuse entkoppelt, was ich sehr gut gelöst finde.

Der Tausch der Festplatte ist dann kein Problem. Die Stecker am Mainboard abziehen, die Schraube des Festplattenkäfigs unten im Frontbereich lösen (ebenfalls ein Torx TX10) und den Rahmen herausnehmen. Ein paar Schrauben lösen und zuletzt die Platte beherzt herausziehen. Beim letzten bischen hat es bei mir etwas geklemmt.
Die neue Disk kommt dann entsprechend in umgekehrter Reihenfolge wieder hinein.

Platine mit Anschlüssen für die Festplatte

Optimierungen

Besonders nervig ist wie so oft der kleine Lüfter, der am Träger der Festplatte angebracht ist. Kurzerhand habe ich den Lüfter einfach nicht wieder angeklemmt und teste aus, ob das Gerät so überhitzt.

Was natürlich auch geht, um die Geräuschkulisse zu verbessern, ist anstelle einer lauten 3,5″ Platte, eine 2,5″ Disk einzusetzen. Der Festplattenrahmen ist natürlich nicht dafür gedacht, und so passen die Abstände der Schrauben, aber auch die Schrauben selbst nicht an eine 2,5″ Platte. Da müsste man sich dann mit Kabelbinder oder doppelseitigem Klebeband behelfen. Da der Receiver aber meist fest an einem Platz steht, hält auch so eine Lösung die kleine Festplatte sicher an Ort und Stelle. Durch die Standard SATA Anschlüsse ist die Verbindung kein Problem.

Daten der alten Festplatte auf die neue übernehmen

Eigentlich war der Plan, die 500GB Festplatte durch eine größere zu ersetzen und alle Aufzeichnungen zu übernehmen.
Technisat macht einem das aber nicht einfach. Die Platte scheint mit einem nicht sehr geläufigen Dateisystem (TSD – wie ich im Forum bei digitalfernsehen.de gelesen habe) formatiert. Ein Linux, was ja doch sehr viele Dateisysteme kennt, mit gparted kann mit der Disk an sich nichts anfangen. Eine direkte Übernahme der Inhalte der alten Platte auf die neue funktioniert also nicht.

Gparted kann mit dem Dateisystem auf der Platte nichts anfangen

Es geht aber wohl, Aufnahmen von der lokalen Platte auf eine externe USB Festplatte (mit FAT32) zu verschieben und dann am Rechner weiter zu verarbeiten. Das geht wohl deutlich schneller, als mit Mediaport übers Netzwerk etwas vom Receiver runter zu kopieren.
Mit einer externen Disk am Receiver habe ich mich aber noch nicht beschäftigt.

Falls jemand weiß, ob man die Daten von der internen Festplatte doch direkt auf eine neue übernehmen kann, bitte melden.

Lüfter eines DELL Servers zähmen

Im Standard sind die Lüfter bzw. der Gehäuse Lüfter eines Dell Servers (Beispiel: Power Edge T320) sehr laut. Das ist zwar für die Hardware eine sichere Grundeinstellung, da ein Überhitzen auf jeden Fall verhindert wird, aber eine Drehzahl von 2.400U/min. ist für eine passable Temperatur im System gar nicht notwendig. Natürlich hängt das auch von der Belastung des Servers und von der verbauten Hardware (viele Festplatten) ab, aber auch mit einer Drehzahl von 600U/min. schafft man es, das Gehäuse nicht über 25 Grad und die CPU (bei wenig Last) noch unter 50 Grad zu halten.

Der Weg, die Automatik abzustellen und die Lüfterdrehzahl manuell einzustellen birgt aber natürlich auch Gefahren. Sollte das System doch mal mehr belastet werden oder durch mehr oder neue Hardware die Temperatur ansteigen, reichen die händisch eingestellten Werte möglicherweise nicht aus. Dann wäre es vielleicht doch wünschenswert, dass die Automatik selbständig die Lüfter stärker pusten lässt.
Von daher ist es nicht empfehlenswert, die Lüftersteuerung zu manipulieren und ich rate niemandem, das nachzumachen.

Auf dieser Seite von SPXLabs <Link> wird sehr schön erklärt, wie man mit dem Linux Programm „ipmitool“ die Lüftersteuerung in den manuellen Modus bringen und die Drehzahl manipulieren kann.
Die erwähnten 600U/min. erreicht man übrigens, wenn man die Drehzahl auf 1% stellt (0x30 0x30 0x02 0xff 0x01).

Sources für alte Ubuntu Systeme verfügbar machen

Sobald ein Ubuntu System aus der Wartung ist, was letztlich auch bei allen LTS Versionen passieren wird, kann man nicht mehr auf die online verfügbaren Quellen zugreifen. Das erschwert die Installation von neuen Paketen erheblich. Natürlich könnte man auch die CD/DVD als Quelle einbinden, aber die Datenträger oder Images sind meist noch von der Erstinstallation und damit noch stärker veraltet, als das laufende System selbst.

Sicherlich wäre es noch besser, das gesamte System generell auf einen aktuellen Stand zu bringen, aber es gibt halt auch Systeme, wo es entweder nicht so einfach geht oder es sich nicht mehr lohnt, weil die genutzte Anwendung in absehbarer Zeit abgelöst wird.

Im falle eines Ubuntu Lucid 10.04 LTS kann man die Sources.list unter /etc/apt/ einfach editieren und die Adressen folgendermaßen ändern:

deb http://de.archive.ubuntu.com/ubuntu/ lucid main restricted
deb-src http://de.archive.ubuntu.com/ubuntu/ lucid main restricted


deb http://old-releases.ubuntu.com/ubuntu/ lucid main restricted
deb-src http://old-releases.ubuntu.com/ubuntu/ lucid main restricted

Alle Ubuntu Versionen können übrigens hier als alte Versionen verwendet werden: http://old-releases.ubuntu.com/ubuntu/dists/

Lightroom und unterschiedliche Darstellung in Bibliothek und Entwicklungsmodul bei aktivierter Grafikkartenunterstützung

Unter Lightroom (hier mit Version Lightroom CC 2015.7) gibt es die Möglichkeit, die Leistung für Camera Raw in den Voreinstellungen mit einer kompatiblen Grafikkarte zu verbessern. Das ist per Standard in Lightroom meines Wissens auch aktiv. Warum auch nicht? Wenn die Grafikkarte das schon unterstützt (eine Nvidia), nimmt man ja jede Verbesserung gerne an.

Wenn es nur eine Verbesserung wäre. Ich habe schon desöfteren von Problemen mit diesem Feature gehört. Oft lässt sich das wohl mit aktuellen Treibern wieder lösen. Anscheinend aber nicht in allen Fällen. Ich habe eben erhebliche Unterschiede in der Darstellung zwischen Bibliotheksmodul und dem Entwicklungsmodul bemerkt. In der Bibliothek waren alle Bilder mit einem Gelbstich versehen. Sobald ich in den Entwickler gewechselt bin, wurde das Bild plötzlich klarer und sah aus, als wäre es deutlich bearbeitet worden. Komisch daran ist nur, dass die Ansichten sich eigentlich überhaupt nicht unterscheiden sollten. Macht ja auch keinen Sinn, wenn ein bearbeitetes Bild in der Bibliotheksübersicht völlig anders rüberkommt, als im Entwickler.

Was war nun die Lösung?
Ich habe unter „Bearbeiten -> Voreinstellungen -> Leistung -> Grafikprozessor verwenden“ den Haken entfernt. Danach waren die Darstellungen wieder synchron.

Zum Verständnis zwei Bilder.

Das erste zeigt den Unterschied zwischen Biliothek und Entwickler bei aktiver Grafikkartenunterstützung:

Das zweite Bild zeigt den Unterschied, wenn die Grafikkartenunterstützung aus ist (nämlich keinen):

Windows: Fenster verschieben, die außerhalb des Sichtbereichs liegen

Es passiert nicht oft unter Windows, dass ein Fenster so ungünstig liegt, dass man es nicht mehr mit der Maus „greifen“ kann. Was aber wenn doch und wenn man das Fenster nicht einfach schließen kann oder will?
Dann hilft die Tastenkombination ALT+SPACE+v und schon lässt sich das Fenster mit den Cursor Tasten verschieben. Gar nicht schlecht, von dieser Tastenkombination zu wissen.

Quelle: http://www.win-tipps-tweaks.de/cms/windows-7-tipps/tricks/fenster-ausserhalb-des-desktops-verschoben.html

FreeBSD ZFS: Alle Snapshots eines zfs Filesystems löschen

Nutzt man automatisch erzeugte Snapshots mit ZFS kann es schon vorkommen, dass davon sehr viele entstehen. Aus diesem oder auch anderen Gründen kann es notwendig werden, alle Snapshots eines Filesystems zu löschen.
Wie geht man dabei vor? Es geht kompliziert und mit Shell-Zauberei (siehe meine Quelle) oder ganz einfach mit

zfs destroy -r tank/FILESYSTEM@%

Quelle: https://sysadminman.net/blog/2008/remove-all-zfs-snapshots-50

FreeBSD: Dateiduplikate finden

Beschreibung

Wie findet man in einem Filesystem bzw. einem oder mehreren Verzeichnissen Dateien, die nicht unbedingt den gleichen Namen tragen oder im selben Verzeichnis liegen?

Hier kann das Tool fdupes (fdupes in der Wikipedia.org) helfen. Dieses existiert sowohl für FreeBSD, als auch für Linux. Das Tool bietet noch ein paar Besonderheiten:

Es vergleicht Dateien nicht nur anhand der Größe, sondern bildet über die Datei eine Checksumme und vergleicht diese. Anschließend erfolgt ein byte-to-byte Vergleich
Suchergebnisse können aufgelistet oder auch gleich gelöscht werden
Es besteht auch die Möglichkeit, Duplikate per Hardlink (Hardlink in der Wikipedia.de) auf nur eine existierende Datei zu verlinken (Notwendig ist Option „-L“, welche ich nur unter Debian gefunden habe)

Installation

Unter FreeBSD kann es entweder mittels pkg oder über die Ports Collection (/usr/ports/sysutils/fdupes) installiert werden:

PKG: pkg install fdupes

PORTS: cd /usr/ports/sysutils/fdupes && make install clean

Anwendung

Als Beispiel nehme ich das Verzeichnis /usr/ports/lang auf einem FreeBSD System und wende die Parameter -r (rekursiv), -S (zeige Dateigröße) und -n (keine leeren Dateien) auf das aktuelle Verzeichnis (./) an:

root@bsd:/usr/ports/lang/ > fdupes -r -S -n ./
6308 bytes each:
./php5/files/extra-patch-php-fpm-ipv6
./php55/files/extra-patch-php-fpm-ipv6
./php56/files/extra-patch-php-fpm-ipv6

915 bytes each:
./pypy/files/patch-lib-python__2.7__distutils__sysconfig_pypy.py
./pypy-devel/files/patch-lib-python__2.7__distutils__sysconfig_pypy.py

1691 bytes each:
./pypy/files/patch-lib-python__2.7__distutils__command__install.py
./pypy-devel/files/patch-lib-python__2.7__distutils__command__install.py

178 bytes each:
./php52-extensions/pkg-descr
./php53-extensions/pkg-descr
./php5-extensions/pkg-descr

Zu erkennen ist, dass es in unterschiedlichen Verzeichnissen Dateien mit gleicher Größe und in diesem Fall mit gleichem Namen gibt.
Vergleicht man nun den Dateiinhalt (von Textdateien) miteinander, kann man verifizieren, ob es sich tatsächlich um die gleichen Files handelt:

root@bsd:/usr/ports/lang/ > diff -y --suppress-common-lines ./php55/pkg-message.mod ./php56/pkg-message.mod
root@bsd:/usr/ports/lang/ >

Diff wird mit den Parametern -y (zwei Spalten) und –suppress-common-lines (unterdrücke gleiche Inhalte) aufgerufen. Das Ergebnis des Vergleiches mit DIFF ist, dass es keine Unterschiede gibt.

Natürlich gibt es noch mehr Parameter, mit denen man fdupes aufrufen kann.

Was kann man nun damit machen?

Ein schönes Beispiel ist z. B. Backup mit fdupes und rsync (http://krausens-online.de/fdupes-hardlinks-und-backup-mit-rsync/).
Oder man sucht einfach nur nach gleichen Dateien.