YIO Remote Two, eine Alternative zur Logitech Harmony?
Ich benutzte ja schon seit Jahren eine Logitech Harmony und steuere damit alles was, zum Entertainment nötig ist. Nun gibt es aber einen Lichtblick am Horizont, der hoffentlich die Konfigurierbarkeit erheblich verbessern sollte und es endlich auch ermöglicht eignen Abläufe zu programmieren die nicht von einem festgelegten Konfigurations-Tool abhängig sind.
Ich hab die Tage auf kickstarter.com die YIO Remote Two unterstützt und hoffe das, dass Project, zügig vorankommt und alles zeitgerecht ausgeliefert werden kann.
Es handelt sich dabei um eine zum Teil in Open Source entwickelte Fernbedienung mit einem Dock die Geräte über WiFi, Bluetooth oder klassisch mit IR Steuern kann. Das ist jetzt die 2. Version die auch schon eine recht große Community um sich scharrt und wo man stark von einem Erfolgreichen Project ausgehen kann.
Eventuell Sucht ja noch jemand von euch eine Multifunktionsfernbedienung mit Bastler Feeling, allerdings muss man auch noch ein wenig Geduld mitbringen, weil die Auslieferung erst in einem Jahr (Juli 2022) ist!
Sie wurde Übrigens in Dänemark entwikelt.
Als nachtrag hier noch ein Livestream Record zu dem Thema, sehr interesant!
Neue tag Übersicht mit einem Blog-Universum
Ab jetzt gibt es auf der tags Seite auch noch eine kleine tags→Artikel Verbindungs-Übersicht, bei der die Verbindungen zwischen den tags und den Artikeln, mithilfe der alchemy.js Library, visualisiert wird.
Ich bin sehr gespannt wie das Universum in einem Jahr aussehen wird!
Bleibt Neugierig.
Umgang mit Docker und Kubernetes Pods
Das wird mein erster FAQ-Artikel, der sich um Docker drehen wird. Ich werde hier mit der Zeit immer mal wieder kleine hints hinzufügen, damit ich nicht lange suchen muss.
Eine laufende Docker Instanz betreten
Docker
docker ps
docker exec -it containerid bash
Kubernetes
kubectl get pods -n namespace
kubectl -i -t -n namespace containerid bash
Eine shell in einem pod über proxy (jumphost) und eigner Config öffnen
KUBECONFIG=~/.kube/config_xxl https_proxy=http://127.0.0.1:8888 kubectl exec -it -n namespace poduniname -- bash
Container logs lesen
-f, --follow hat den gleichen effect wie tail -f
Docker
docker ps
docker logs containerid -f
Kubernetes
kubectl get pods -n namespace
kubectl logs -n namespace containerid -f
Ereignisübersicht
Einen namesspace
kubectl get events --sort-by=.metadata.creationTimestamp -n namesspace
Alle namespaces mit mehr output
kubectl get events --all-namespaces -o wide
Links
Git kniffe und Tricks
Einen alten branch Name nach merge neu nutzten
git checkout master
git pull
git branch -d brachname
git checkout -b brachname
git push orgin brachname
Das geht aber nur wenn der Brach schon gemerged und gelöscht wurde!
chmod auf ein file im git repro
git update-index --chmod=+x path/to/file
Um das exec bit zu löschen
git update-index --chmod=-x path/to/file
Anzeigen von chmod im git index
git ls-files --stage path/to/file
Erzeugen von Symlinks in git
cd destdir
ln -s ../../../existing_file symlinkfile
git add symlinkfile
git ls-files -s symlinkfile # show link
git cat-file -p linkhash # show source
Wenn das Zielfile, Git schon bekannt war, muss man es erst aus Git löschen bevor man es mit add hinzufügen kann!
check git config
Zu auflisten der aktuellen config gibt es die --list Option
git config --list
und zum ändern einer Option kann man sie z.b. mit --global ändern
git config --global user.name "dein name"
Git das Password speichern erlauben
Git bringt einen einfache Methode zum Password Speichen mit, die allerdings nicht unbedingt sicher ist. Zum aktiveren muss man nur diese Zeile ausführen und Git speichert das pw zum den repros.
git config --global credential.helper store
nun muss man nur noch einam z.z. ein
git pull
und er speichert die Zugangsdaten für das nächste mal in dem file ~/.git-credentials in Klartext es ist also ein sehr unsichere Sache.
Alternativ kann man auch nur einen mem cache mit timeout nutzten.
git config --global credential.helper cache
git config --global credential.helper 'cache --timeout=3600'
dann hält er das pw nur um Ram und schmeißt es nach dem Timeout weg.
Es existieren auch noch ein Paar andere Metoden, hier eine interesante Zusammenfassung auf stackoverflow.com
git mtime restore
Manchmal braucht man die mtime für Files und wenn man ein file nicht modifiziert hat wird die neue mtime eventuell nicht richtig geseztzt. Für dieses Problem gibt es aber eine einfach Lösung.
sudo apt install git-restore-mtime
cd [repo]
git restore-mtime
Commit log in der shell
git log --graph --all --decorate --oneline --simplify-by-decoration
Wie Testet man die MTU Größe
Wie oft hat man das Problem, das man in einem Netzwerk, unerklärliche Netzwerk Abbrüche hat. Oft ist der Grund einfach eine falsche MTU Größe, die dazu führt, dass zwar Kommunikation möglich ist aber man bei größeren datenabhängigen auf einmal nichts mehr geht.
Grundlagen
Die MTU (Maximum Transmission Unit) Größe, definiert die Effektiv nutzbare Daten und ist mit jeder zusätzlichen Netzwerkschicht bzw. unterschiedlichen Protokollen anders. Dazu gehören z.b. IPv4 vs. IPv6, UDP vs. TCP oder Ethernet vs. Internet oder VPN. Mit jedem zusätzlichen Feature kommen ein paar Bytes zu Header dazu der die nutzbare Daten-gösse verringert. In einem Lokalen Netz hat man meist eine MTU von 1500 und Richtung Internet so um die 1472.
Eine zu kleine Größe führt dazu, das die Daten in zu viele Pakete aufgesplittet werden, man so mehr Header Daten senden muss und so einen schlechteren Durchsatz hat. Wohingegen zu große Blöcke zu Netzwerkproblemen führen.
Testen
Mit Ping kann man die MTU werte testen. Ping benutzt ICMP als Protokoll was eine Header Größe von 28 Bytes hat mit IPv4 (IPv4=20 bytes + ICMP=8 bytes = 28).
ping -D -c 2 -s 1472 8.8.8.8
sollte sowas wie das ergeben
PING 8.8.8.8 (8.8.8.8): 1472 data bytes
36 bytes from x.1x.1xx.1xx: frag needed and DF set (MTU 1492)
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst
4 5 00 05dc 0000 0 0000 3e 01 646f 192.1xx.1x.2xx 8.8.8.8
Jetzt Sagte uns Ping, das Packet müste Fragmentiert werden.
Wenn man die Blockgröße viel zu groß hat sieht es dann so aus.
ping -D -c 2 -s 1473 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 1473 data bytes
ping: sendto: Message too long
ping: sendto: Message too long
Also Testen wir es nochmal mit den vorgeschlagenen 1492. 1492-28 = 1464
ping -D -c 2 -s 1464 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 1464 data bytes
76 bytes from 8.8.8.8: icmp_seq=0 ttl=115 time=19.860 ms
Das heißt also, wir können eine MTU von 1492 verwenden in dieser Verbindung.
Windows
Unter Windows sind die Argumente ein wenig anders aber es geht dort genau so.
# windows powershell
ping -f -n 2 -l 1464 8.8.8.8
Ping wird ausgeführt für 8.8.8.8 mit 1464 Bytes Daten:
Antwort von 8.8.8.8: Bytes=68 (gesendet 1464) Zeit=19ms TTL=115