Provider ohne IPv6 prefix delegation: NAT66

Posted on by roman

Solange A1 am VDSL Modem keine IPv6 Prefix Delegation zulässt (es werden nur /64 Adressen geliefert) muss man für halbnativen IPv6 Zugriff (und vorhersagbare/die Möglichkeit von statischen lokalen Adressen) in die Trickkiste greifen und NAT66 von den lokalen ULAs (fd::/8) auf die öffentliche GUA am Modem konfigurieren. Hier am Beispiel OpenWrt (alles LuCI, Stand 23.05.2):

Network/Interfaces/Global network options: Check ob “IPv6 ULA-Prefix” vorhanden ist (der ausgewürfelte /48 prefix für die lokalen fd:: Adressen)

Network/Interfaces/Interfaces/Interface der Wahl/DHCP Server/IPv6 Settings: RA-Service auf “server mode” (DHCP Server und NDP Proxy bleibt disabled)

Darauf erscheint Zusatztab “IPv6 RA Settings”: “Default Router” auf “on available prefix”

Ist das angewendet gibts unter Network/Interfaces/Interfaces/Interfache der Wahl/General Settings neue Felder für die IPv6 Adresse (nur das Default Interface “lan” erhält eine Adresse mit dem ULA Prefix und fdxx:xxxx:xxxx::1/60, dort ist dann naturgemäß nichts zu tun) – dort dann passende IPv6 Adresse eintragen (z.B. VLAN hinter dem /48 Teil der vorgegeben ist für /60 Netz – im Beispiel VLAN 20):

Network/Interfaces/Interfaces/wan6/Advanced Settings/IPv6 source routing disablen

Network/Firewall/Zones/der Zeile mit wan => REJECT (die mit Masquerading=enabled)/Advanced Settings/IPv6 Masquerading enablen

Damit hat man all das mühsam nachgebaut was mit IPv6 eigentlich der Vergangenheit angehören hätte sollen…. 🙁

Das alles ist im OpenWrt Wiki beschrieben:

# Enable IPv6 masquerading aka NAT66 on the WAN zone.
# ---------------------------------------------------
uci set firewall.@zone[1].masq6="1"
uci commit firewall
service firewall restart

# Announce IPv6 default route for the ULA prefix.
# (replace ".lan." with your interface to change)
# -----------------------------------------------
uci set dhcp.lan.ra_default="1"
uci commit dhcp
service odhcpd restart

# Disable IPv6 source filter on the upstream interface.
# -----------------------------------------------------
uci set network.wan6.sourcefilter="0"
uci commit network
service network restart

Debian Dependency ignorieren

Posted on by roman

Problem: Custom .DEB mit einer Dependency die in Debian nicht enthalten ist oder die Dependency ist falsch weil eine höhere Version der Dependency benötigt wird aber nicht in Debian enthalten ist
[TP-Link Omada Controller DEB mit JRE 17 verlangt JSVC >=1.0.8 aber 1.1.x ist tatsächlich notwendig, siehe hier]

Lösung (grauslich aber es wirkt): /var/lib/dpkg/status editieren und beim entsprechenden Paket (welches z.B. bei apt upgrade dann die fehlende Dependency einfordert und –fix-broken vorschlägt was zwar apt glücklich machen würde aber Omada bricht) bei “Depends:” die irrgeleitete Dependency entfernen.

tp-link Omada Controller auf Raspberry Pi installieren

Posted on by roman

In Anlehnung an die Anleitung hier die Kommandos (Raspberry 4 mit 4 GB RAM, unter 2 eher schmerzhaft, Debian 11):

sudo apt update && sudo apt upgrade
#--------------- MONGODB -------------------
wget https://repo.mongodb.org/apt/ubuntu/dists/focal/mongodb-org/4.4/multiverse/binary-arm64/mongodb-org-server_4.4.18_arm64.deb

sudo dpkg -i mongodb-org-server_4.4.18_arm64.deb

sudo systemctl daemon-reload
sudo systemctl enable mongod
sudo systemctl start mongod

#--------------- JAVA (JDK) ----------------
sudo apt install openjdk-17-jdk-headless

#--------------- JSVC BUILD ----------------
sudo apt install autoconf make gcc
wget https://dlcdn.apache.org/commons/daemon/source/commons-daemon-1.3.4-src.tar.gz
tar xvfz commons-daemon-1.3.4-src.tar.gz
cd src/native/unix
sh support/buildconf.sh
./configure --with-java=/usr/lib/jvm/java-17-openjdk-arm64
make
sudo cp jsvc /usr/bin/

#---------------- OMADA -------------------
#Liste: https://www.tp-link.com/de/support/download/omada-software-controller/
wget https://static.tp-link.com/upload/software/2024/202401/20240112/Omada_SDN_Controller_v5.13.23_linux_x64.deb

sudo dpkg -i --ignore-depends=jsvc Omada_SDN_Controller_v5.13.23_linux_x64.deb

Das letzte dpkg -i sollte den Controller auch gleich starten (Zugriff über Port 8088). Sonst mit sudo tpeap start/stop/status/version steuerbar.

Software, Logs und Configs unter /opt/tplink/EAPController.

Der User der im First Time Setup erzeugt wird ist der “Main Administrator” und als Einziger befugt globale Parameter wie z.B. Listening Port zu ändern, habe noch keine Möglichkeit gefunden zusätzlichen Benutzern auch diese Rolle geben zu können.

Update/Workaround: Einfach mit Main Administrator eine neue Rolle erzeugen die alle Rechte hat und dem gewünschten User geben.

Update 2: Versionsupdate ausschließlich das letzte dpkg -i Kommando (inklusive dependency-ignore); macht Stopp, erkennt vorhandene Daten und wirft anschließend wieder an.

ffmpeg Fenster oder single Desktop aufzeichnen

Posted on by roman

Weil mir die Sucherei jedes mal auf die Nerven geht:

ffmpeg -f gdigrab -framerate 30 -i title="Fenstertitel" -b:v 3M -pix_fmt yuv420p video.mp4

Der einfachste Weg die verfügbaren Fenstertitel kann man über das EXE mit folgender Commandline rausfinden (hier am Beispiel Chrome):

tasklist /v /fi "imagename eq chrome.exe" /fo list|findstr "Window"
(oder "Fenster" auf deutschem System)

Problematisch wirds bei Firmen die meinen irgendwelche in CMD nicht vernünftig übertragbare Zeichen im Fenstertitel haben zu müssen, oder Microsoft? ODER???

Bei Multimonitor kann man das Video um die nicht gewünschten Teile erleichtern, Syntax ist

videobreite:videohöhe:xstart:ystart

bei einem Setup mit 3 1920×1200 Monitoren wäre der volle mittlere Monitor also:

ffmpeg -f gdigrab -framerate 30 -i desktop -vf crop=1920:1200:1920:0 -b:v 3M -pix_fmt yuv420p video.mp4

Cross podman-compose Namensauflösung

Posted on by roman

Annahme: Zwei Verzeichnisse mit docker-compose.yaml die mit podman-compose ins Leben gerufen werden.

Defaultverhalten: Selbst bei Angabe von “networks:” im docker-compose.yaml sehen sich die zwei Deployments nicht weil sie in zwei Podman Netzwerken erzeugt werden. Die Netzwerke werden immer mit dem Verzeichnisnamen prefixiert (podman network ls).

Ziel: Container aus Deployment A sollen Container aus Deployment B namensmäßig auflösen und auch netzwerkmäßig erreichen können.

Lösung: Identen Projektnamen beim Aufruf von podman-compose für beide Deployments angeben

podman-compose -p meinprojekt up -d

❗ Sollten networks: im yaml verwendet werden müssen die Container die miteinander kommunizieren sollen natürlich auch im gleichen Network sein – der Projektname ist nur der Prefix des Netzwerks.

Debian + fail2ban = Have not found any log file for sshd jail

Posted on by roman

Gemäß Issue ist das ein Problem von allen systemd-basierten Distros die nur mehr in journald loggen – in /etc/fail2ban/jail.local in Sektion [DEFAULT] das Setting backend auf systemd setzen:

# /etc/fail2ban/jail.local 
# (gemäß Doku von /etc/fail2ban/jail.conf kopiert)

[DEFAULT]
backend = systemd

[sshd]
enabled = true

Damit das funktioniert muss man noch folgendes Paket installieren:

sudo apt install python3-systemd

Wie man im Issue auch nachlesen kann bringt das natürlich alle Jails um die in Logfiles suchen wollen 😐

Inter-Container Kommunikation mit rootless podman auf Debian

Posted on by roman

Notwendige Pakete für podman

podman
slirp4netns
uidmap
podman-compose

Danach am besten Reboot weil sonst a) die subuids/subguids von uidmap und b) die netns Geschichten von slirp4netns nicht greifen und podman-compose auf die Nase fliegt mit “podman failed to mount runtime directory for rootless netns” failed.

Aber – damit können zwei Container noch nicht miteinander kommunizieren. Podman benutzt dann per default CNI als Netzwerkmethode und das überall beschriebene Paket “podman-plugins” gibts auf Debian offenbar nicht (erlebt auf bookworm), das notwendige Paket mit dem plugin “dnsname” (landet dann auf /usr/lib/cni/) heißt

golang-github-containernetworking-plugin-dnsname

Das installiert eben das dnsname CNI plugin und auch dnsmasq-base damit Inter-Container DNS Lookups darüber geführt werden können.

Das alleine hilft aber noch nicht weil das Default Netzwerk “podman” (podman network ls) hat DNS lookups nicht enabled (podman network inspect podman – Property “dns_enabled” steht auf false).

Erzeugt man aber nach der Installation vom DNSNAME plugin ein Netzwerk hat dieses dns_enabled=true, entweder auf der commandline

podman create network whatevernet
podman run whatever:latest --net whatevernet

oder im compose file als network:

networks:
   whatevernet:


services:
   whatever:
      image: whatever:latest
      networks:
         - whatevernet

UPDATE

Keine Ahnung warum mein podman mit CNI als Netzwerkbackend installiert wurde aber seit 4.0 sollte eigentlich netavark Default sein – welches das alles out of the box kann. Umstellung:

  • podman system reset
    (Reboot um Reste zu entfernen)
  • sudo cp /usr/share/containers.conf /etc/containers/
  • unter [network] Eintrag network_backend entkommentieren und auf “netavark” setzen
  • sudo apt install netavark
  • sudo apt install aavark
  • podman info | grep networkBackend
    (sollte netavark sein)

Custom Moniker (URL Protocol) erzeugen

Posted on by roman

Um ein beliebiges Programm über eine URL zu starten braucht es nicht viel, am Beispiel outlook:// für überraschenderweise Outlook:

Für den User:

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\SOFTWARE\Classes\outlook]
@="URL:outlook"
"URL Protocol"=""
"EditFlags"=dword:00000002
"Source Filter"="{E436EBB6-524F-11CE-9F53-0020AF0BA770}"

[HKEY_CURRENT_USER\SOFTWARE\Classes\outlook\shell]

[HKEY_CURRENT_USER\SOFTWARE\Classes\outlook\shell\open]

[HKEY_CURRENT_USER\SOFTWARE\Classes\outlook\shell\open\command]
@="outlook.exe"

Oder rechnerweit:

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\outlook]
@="URL:outlook"
"URL Protocol"=""
"EditFlags"=dword:00000002
"Source Filter"="{E436EBB6-524F-11CE-9F53-0020AF0BA770}"

[HKEY_CLASSES_ROOT\outlook\shell]

[HKEY_CLASSES_ROOT\outlook\shell\open]

[HKEY_CLASSES_ROOT\outlook\shell\open\command]
@="outlook.exe"

Kubernetes: Autoimageupdate mit keel.sh mit private Registry mit custom Root CA

Posted on by roman

ConfigMap für keel.sh für die custom Root CA erzeugen

apiVersion: v1
kind: ConfigMap
metadata:
  name: ca-gallauner
  namespace: "keel"
data:
   ca-gallauner.pem: |
     -----BEGIN CERTIFICATE-----
     ....
     -----END CERTIFICATE-----

keel.sh via YAML installieren

  • Basic Auth für Dashboard (PortForward 9300 von Pod)
  • ConfigMap für CA mounten
      containers:
        - name: keel
          image: "keelhq/keel:latest"
          imagePullPolicy: Always
          command: ["/bin/keel"]
          env:
            - name: NAMESPACE
              valueFrom:
                fieldRef:
                  fieldPath: metadata.namespace
            # Basic auth (to enable UI/API)
            - name: BASIC_AUTH_USER
              value: "admin"
            - name: BASIC_AUTH_PASSWORD
              value: "admin"
            # Enable insecure registries
            - name: INSECURE_REGISTRY
              value: "false"
          ports:
            - containerPort: 9300
          livenessProbe:
            httpGet:
              path: /healthz
              port: 9300
            initialDelaySeconds: 30
            timeoutSeconds: 10
          resources:
            limits:
              cpu: 100m
              memory: 128Mi
            requests:
              cpu: 50m
              memory: 64Mi
          volumeMounts:
          - name: ca-gallauner
            mountPath: /etc/ssl/certs/ca-gallauner.pem
            subPath: ca-gallauner.pem
            readOnly: false
      volumes:
      - name: ca-gallauner
        configMap:
          name: ca-gallauner

keel.sh Annotations im Zieldeployment einfügen

    metadata:
      labels:
        app: homer
      annotations:
        keel.sh/policy: all
        keel.sh/trigger: poll
        keel.sh/pollSchedule: "@every 1m"
        keel.sh/approvals: "0"

Private Registry mit Custom Root CA in Kubernetes benutzen

Posted on by roman

In Kubernetes ImagePullSecret erzeugen:

kubectl create secret docker-registry myregistry --docker-server=<your-registry-server> --docker-username=<your-name> --docker-password=<your-pword> --docker-email=<your-email>

Im Pod/Deployment imagePullSecret hinzufügen

    spec:
      containers:
      - name: nginx
        image: myregistry/gallauner/homer:latest
      ports:
        - containerPort: 443
      imagePullSecrets:
      - name: myregistry