Ganzes Verzeichniss zippen:
zip -r <ArchiveNama>
<Folder1> <Folder2> ….
Ganzes Verzeichniss zippen:
zip -r <ArchiveNama>
<Folder1> <Folder2> ….
Graylog bietet einen einfach zu konfigurierenden Syslog-Input an. Leider kommt es jeh nach verwendeten „Loglayout“ dann zu parsing Fehlern. Bei mir hat es z. B. hauptsächlich die Genauigkeit des Zeitstempels betroffen.
Am leichtesten löst man das Problem indem man RSyslog dazu bringt, im GELF Format zu loggen. Dies ist ein einfaches JSON Format und ohne Probleme vie RSyslog-Template umzusetzten:
template(name="gelf" type="list") { constant(value="{\"version\":\"1.1\",") constant(value="\"host\":\"") property(name="hostname") constant(value="\",\"facility\":\"") property(name="syslogfacility-text") constant(value="\",\"facility-num\":\"") property(name="syslogfacility") constant(value="\",\"syslogtag\":\"") property(name="syslogtag") constant(value="\",\"priority\":\"") property(name="syslogpriority-text") constant(value="\",\"message\":\"") property(name="msg" format="json") constant(value="\",\"timestamp\":") property(name="timegenerated" dateformat="unixtimestamp") constant(value=".") property(name="timegenerated" dateformat="subseconds") constant(value=",\"level\":\"") property(name="syslogseverity") constant(value="\",\"severity\":\"") property(name="syslogseverity-text") constant(value="\"}") } action(type="omfwd" target="deepdraft.aqua" port="12201" protocol="udp" template="gelf")
Ein einfachen GELF Beispiel
{ "version": "1.1", "source":"", "short_message":"", "some_variable":"" }
Der Unifi Controller unterstützt mittlerweile nicht nur das StartTLS sonder prüft auch das Zertifikat des Mail Servers. Was erstmal in die Kategorie „Captain Obvious“ fallen sollte, wird interessant, weil frühere Versionen das nicht gemacht haben und die Zertifikatsprüfung auch gemacht wird, wenn man 127.0.0.1 als Mailserver verwendet.
Konkret: auch wenn man in der Controller-Config angibt, dass der Mailserver ohne SSL/TLS anzusprechen ist, wird beim Verbindungsaufbau ein StartTLS gesendet und das Zertifikat geprüft. Das Zertifikat muss zur verwendeten MailServer-Addresse passen. Wer den MailServer lokal betreibt oder direkt mit IP anspricht, muss das Zertifikat entsprechend anpassen oder die korrekte DNS-Adresse verwenden.
Zu Tuningzwecken muss ab und zu auf /sys/block/dm-X zugreifen. Dazu muss man allerdings (bei mehreren DM- Block Devices) wissen, was hinter den einzelnen DM-Devices steckt.
Das kann man mittels folgenden Befehl rausbekommen.
dmsetup info /dev/dm-*
Zuerst das Logische Volumen vergrößern
lvextend -l +100%FREE /dev/mapper/<logical-device>
Wenn cryptsetup/LUKS zum Einsatz kommt, muss man einmal das Device Unmounten und den Container schließen und wieder aufmachen.
Anschließend das Volume vergrößern. Bei XFS geht das nur online.
xfs_growfs <mountpunkt>
Ich war schon eine geraume Zeit auf der Suche nach einem „Plaste-Router“ für einen sehr spezjellen UseCase: einen ReiseRouter.
Da ich mit Familie reise und die Anzahl an WiFi Devices mittlerweile, die der mitreisenden Personen übersteigt, stellt sich am Zielort immer wieder die gleiche Prozedur ein: alle Devices ins Urlaubs-WLan bringen. Wenn es ganz Übel wird, gibt es dort nicht mal solches. Mit einem gesteigerten Privacy/Security Anspruch, will man zudem ungern direkt in einem fremden Netzwerk hängen. Ein VPN muss her. Nun unterstützt nicht jedes Consumer Endgerät VPNs (Switch, EBook Reader usw)…
Lange Rede – Kurzer Sinn: Es werden folgende Features benötigt:
All das kann man mit diversen OpenWRT/LEDE geflashten Routern irgendwie hinbekommen. Aber meistens war da Gefrickel notwendig. Besonders, wenn man sich in ein WLAN einwählen wollte und gleichzeitig selber ein anderes WLAN als AP zur Verfügung stellen wollte. (Auf dem gleichen Band wohlgemerkt)
Mein kurzer Abstecher in die „alte ConsumerWelt“ via einer Netgear AirCard war echt abschreckend. Für mehr als ein LTE Modem taugt der Kram nicht (dafür aber, dank externer großer Antenne, gut). OS Updates – wozu? „Shippen and Forget“ ist hier die Devise.
Vor meinem letzten Urlaub habe ich mir „zum Testen“ den AR750 Slate von GL.iNet zugelegt. Das Gerät gibt es im Handel aktuell für um die 100€. Das ist erstmal eine Ansage. Damit spielt das Gerät preislich in der „Oberliga“ der Plasterouter Marke „eierlegende Wollmichsau“.
Die erste Überraschung gibt es beim Auspacken des Gerätes. Das Ding ist kleiner als ein RasperryPy und dennoch bietet es zwei schwenkbare Antennen, 3 RJ45 Ports (Gigabit Ethernet) und einen USB2 Port. Ein RJ45 Port dient fest als WAN Port, über die anderen Beiden kann man kabel-gebundene Geräte anschließen. Der USB Port kann wahlweise für eine Modem oder Tethering-Verbindung genutzt werden oder es kann ein USB Massenspeicher angeschlossen werden. Der interne Speicher (128MB) kann via MicroSD Karte erweitert werden. Die Stromversorgung läuft über ein USB Mini und kann von einem beliebigen USB Netzteil oder PC erfolgen.
Die zweite Überraschung erfolgt bei der Inbetriebnahme des Gerätes. Man wird von der vorgeschaltet UI gezwungen (!!!!!) eine „sicheres“ Passwort zu vergeben. Das ist man bei PlasteRoutern nicht unbedingt gewohnt. Man landet sofort in einer Übersicht wo man aus 4 Optionen wählen kann, wie man die Verbindung zum Internet herstellen möchte. Einen Klick (wirklich nur einen Klick) später hat man Internet (Wenn die Konfiguration am Zielort mitspielt, dazu gleich mehr).
Beim VPN hat man die Wahl zwischen OpenVPN und WireGuard. Unsichere und „sollte man nicht verwenden“ Protokolle und werden gar nicht erst angeboten. Beim VPN Setup hat man immer die Wahl zwischen Client und Server Mode. Die notwendige Config lädt man einfach hoch. Die meisten VPN Provider bieten die passenden personalisierten Configs an, bei privaten VPNs muss man sich Selbige schnell zusammenbasteln. Liegt die Config vor braucht es 5 Klicks bis das VPN steht. Zwei weitere Klicks und der Router blockiert jedweden Traffic, wenn kein VPN verbunden ist. Kurz: wenn alles gut läuft ist man in unter zwei Minuten mit dem Setup durch und muss sich den Rest des Urlaubs nicht mehr um den kleinen Kasten kümmern.
Ich hatte natürlich gleich beim ersten Einsatz den „SuperGau“. Mein HotelWLan nutzte die gleiche IP Range wie mein Heimnetz. Solche Fälle kann weder über die GL.iNet noch die LuCI-GUI abfangen. Hier war direkter SSH Zugang und „Policy Based Routing“ Gefrickel notwendig. 20 Minuten und einige Flüche später war aber auch das Problem umschifft. Das Gerät hat über die Dauer des Urlaubs keine Auffälligkeit gezeigt und einfach lautlos (und störungsfrei) seinen Dienst verrichtet.
Wenn man Meckern will, dann nur auf sehr hohen Niveau. Hier sind ein paar Punkte:
So viel „Euphorie“ hatte ich bei Netzwerkgeräten schon lange nicht mehr. Eigentlich löst das nur Ubiquity bei mir aus. Anschließen, einrichten und „geht“. Man sucht noch Gründe rum zu basteln aber eigentlich tut alles. Der Router ist perfekt auf seinen Einsatzzweck ausgerichtet. Urlaubs-Resort betreten, WLAN Zugang einrichten, VPN verbinden und dann das Gerät vergessen und Urlaub machen. Wenn es mal doch einen Grund gibt zu basteln, hat man aber auch die komplette Bandbreite der Tools zur Verfügung.
Vorweg: mit IPv6 wäre das nicht notwendig. IPv6 ist aber immer noch nicht flächendeckend ausgerollt (und wird es wohl zu meiner Lebenzeit auch nicht)
Wenn man sich via VPN aus einem beliebigen Netz in sein eigenes Netzwerk verbindet funktioniert das nur, wenn das Lokale Netz (aus dem man sich verbinden will) eine andere Netzmaske hat, als das Zielnetz, in das man sich verbinden will.
In meinem Fall Hotel-WLan-Gateway die gleiche Adresse wie eine meiner Server (auf dessen Service ich gerade zugreifen wollte).
Ich halte ja mittlerweile zwei unterschiedliche VPN Netzwerk Konfigurationen bereit, für den Fall, dass mein Gastnetzwerk den gleichen Addressraum nutzt, denn auch mein VPN hat. Für die Zieladressen konnte ich diesen Weg aber nicht gehen.
Das Problem kann man mit einem Router und „Policy Based Routing“ lösen.
Der Router wird mit dem zur Verfügung gestellten Gast Netz verbunden (IP Range A) und stellt selber ein Netzwerk (IP Range B) zur Verfügung. Der Router wählt sich nun in das VPN-Netzwerk ein (IP Range C). Das interne Netzwerk, dass durch das VPN erreicht werden soll, hat auch IP Range A.
Das Problem: wenn ein Client aus IP Range B versucht auf interne Ressourcen mit der IP Range A zuzugreifen, geht der Router nicht über das VPN, sondern auf den direkten Link, also ins GastNetz.
Die Lösung: man legt sich eine neue Routing Table an, die zwei Einträge hat:
Den Lokalen Link für das eigene Netzwerk (IP Range B)
eine Default Route über das VPN (IP Range C)
Das kann dann so aussehen
ip route add IP-RANGE-B dev LOCAL-DEV proto kernel scope link src LOCAL-IP table 200 ip route add default via VPN-GW-IP dev VPN-DEV table 200
Anschließend muss man dem Router nur noch dazu Bringen, alles aus dem eigenen Netzwerk (IP Range B) über diese Tabelle zu routen. Das geht wie folgt:
ip rule add from IP-RANGE-B lookup 200
Wenn nun etwas aus dem eigenen Netzwerk (IP Range B) bearbeitet wird, kennt der Router das GastNetz (IP Range A) nicht.
Das ganze kann man auch ohne Router erreichen, also mit einem Client direkt im GastNetz (IP Range A) und einer OpenVPN Instanz am laufen. Dann werden die „ip rule“ Statements nur viel komplizierter.
Die Ansatz hier ist: Sämtlichen Traffic, der nicht von dem VPN erzeugt wird, über eine gesonderte RoutingTable zu bearbeiten und nur den VPN Traffic an das Default GW zu bekommen. Der Kniff ist „Sämtlichen Traffic, der nicht von dem VPN erzeugt wird“ korrekt zu erkennen. Möglichkeiten hier sind:
Alles in allem hat man einfach ein bisschen mehr Aufwand.
Oder man sorgt mittels IPv6 einfach dafür, dass man keine zwei Netze mit gleicher IP Range hat…
ich weiß ich bin ein bisschen „Late to the Party“ – aber egal.
Wer unter Ubuntu ZWave-Geräte via HomeAssistant steuern möchte, muss erst mal selber hand anlegen.
Folgende pakete müssen via apt-get nachinstalliert werden:
Anschließend muss man noch via pip das Paket python-openzwave installieren. Den Rest sollte HomeAssistant selber nachinstallieren, sobald man zwave in der Config aktiviert hat.
zwave: usb_path: /dev/ttyACM0 network_key: "SecretKey"
Die Installation der meisten Z Wave sticks läuft problemlos. Anstecken und ein device wird angelegt, meist irgendwas mit ttyACM. Gegenbefalls muss man noch an den Berechtigungen schrauben aber das ist trivial. Im HomeAssistant COnfigMenu sollte unter ZWave jetzt der Controller gelistet sein.
Zuerst muss man das Thermostat montieren. Danach versetzt man via HomeAssistant den Z Wave Adapter in den Suchmodus. Auf dem Thermostat die mittlere Bedientaste zur Bestätigung drücken (ca 1sek) und nach kurzer Zeit sollte im HomeAssistant eine neue ZWave Node auftauchen.
„Aus Gründen“ wird das Thermostat als Cooling Unit erkannt. Die Temperatur wird zwar korrekt ausgelesen, aber man kann keine Ziel Temperatur setzten. Um das zu beheben muss muss man warten bis die Node im ZWave Dialog als „Complete“ gelistet wird. Anschließend den HomeAssistant geregelt runter fahren, damit die ZWave Config raus geschrieben wird. Nun diese Config bearbeiten und den Eintrag „Heating 1“ hinzufügen.
<CommandClass id="67" name="COMMAND_CLASS_THERMOSTAT_SETPOINT" version="1" request_flags="4" innif="true" base="1" typeInterpretation="B"> <Instance index="1" /> <Value type="decimal" genre="user" instance="1" index="1" label="Heating 1" units="C" read_only="false" write_only="false" verify_changes="false" poll_intensity="0" min="0" max="0" value="21.00" /> <Value type="decimal" genre="user" instance="1" index="2" label="Cooling 1" units="C" read_only="false" write_only="false" verify_changes="false" poll_intensity="0" min="0" max="0" value="0.0" /> </CommandClass>
Jetzt noch unter Climate ZWave aktivieren:
climate: - platform: zwave
Nach dem start des HomeAssistant sollen 4 neue „devices“ verfügbar sein:
Um einen Sensor für die Batterie zu haben muss man folgendes machen:
sensor: - platform: template sensors: zwave_devolo_batt: value_template: '{% if states.zwave.danfoss_unknown_type_0005_id_0175 %} {{ states.zwave.danfoss_unknown_type_0005_id_0175.attributes.battery_level }} {% else %} Unknown {% endif %}' unit_of_measurement: '%'
Hat man mehrere Thermostate wird allen litereals ein Nummerierung via Unterstrich angehängt. (zwave.danfoss_unknown_type_0005_id_0175_2, climate.danfoss_unknown_type_0005_id_0175_heating_1_2 …)
Jetzt kann man das Thermostat im HomeAssistant nutzen und steuern.
Was funktioniert nicht:
COMMAND_CLASS_CLOCK – Der HomeAssistant scheint die Uhrzeit noch nicht auf das Device zu schreiben. Die wird gebraucht, dass das Thermostat einmal eine „Justierungsmessung“ Des Ventiels macht
COMMAND_CLASS_CLIMATE_CONTROL_SCHEDULE – Laut Beschreibung sollte man dem Thermostat hier eigenen „Schedule“ verpassen können. Das kann man über den HomeAssistant lösen, was heir auch gehen sollte, ist den Temperatursensor mit einem Offset zu versehen.
Kleine Anmerkung für die Leute die die Bedienungsanleitung suchen. Devolo hält es nicht für Notwendig die vollen Funktionen des Thermostates zu beschreiben. Da es sich aber um ein Gebrandetes Danfoss handelt, kann man sich da die nötigen Daten ziehen. Als Spezjalservice, das wichtigste hier:
Unter Linux gibt es den openrazer Treiber um Razer Geräte anzusteuern. Leider hat Razer bei neueren Geräten das „Protokoll“ gewechselt und betreibt jetzt wohl mehr „Software Based Lightning“. Lange Rede – kurzer Sinn: der openrazor Treiber aus den aktuellen quellen funktioniert noch nicht.
Wenn man nicht alles selber bauen will sollte man sich erst mal das Frontend installieren. Unter KDE bietet sich Polychromatic an. Dazu muss man auch den Treiber „schon mal“ installieren.
Anschließen hohlt man sich die Openrazer-Quellen von hier: https://github.com/sumpster/razer-drivers.git
Danach der üblich Weg:
make sudo make driver_install sudo make setup_dkms sudo make udev_install sudo make daemon_install
danach noch den openrazor_daemon aus /usr/lib/python3.x nach /usr/lib/python3/dist-packages kopieren, durchstarten und schon kann man die Huntsman unter Linux steuern.
Wichtig: nutzt !!nicht!! die abkürzung über ubuntu_install. Die ist fürs pakaging gedacht und zerschießt euch das System.