Sicherstellen dass CUPS läuft: sudo systemctl start cups
Drucker verbinden
sudo system-config-printer
Add / Network Printer / Find Network Printer / IP bei Host angeben und Find
Warten bis er Amok läuft und 2000 Einträge mit der IP-Adresse in der Liste baut – aber auch eben einen Eintrag „Epson WF-7610 (IP-Adresse)„
Diesen Eintrag auswählen (Host wird mit Port 515 vorbefüllt und Queue „PASSTHRU“) und „Probe“ klicken, „Searching for drivers“ sollte aufgehen und verschwinden.
Der Odyssey G9 (ein S49FG910EU bei mir) hat 5120×1440 und kann 144 Hz.
Mein Mini PC (Ninkear K7 mit einer Ryzen 7430U) hat nur HDMI.
Damit 5120×1440 in höheren Refreshraten läuft braucht man HDMI 2.1.
AMD darf unter Linux aus irgendeinem dummen Grund nicht HDMI 2.1 machen.
Ergo: Linux sieht als höchstes der Gefühle 3840×1080@120 oder so was natürlich nicht Sinn der Sache ist und auch noch Kacke aussieht.
Lösung für 144 Hz: Display Port.
Da ich aber keinen neuen Mini PC kaufen will funktioniert folgender 5120×1440@60 Workaround (da ich jetzt auf KDE/Arch fahre und demnächst auf QubesOS – beide mit X11- umsteige):
Update: Ein Adapter von USB-C auf Display Port hat das Problem ohne neuen Mini PC gelöst 😀 (Qubes OS/X11 springt instant auf die native Auflösung in 120 Hz, 144 ist aber auch in der Liste)
Scheinbar hat Apple ab iOS 16.2 beschlossen nur mehr vCard 3.0 oder höher zu unterstützen. Outlook, selbst in der neuesten M365 Version exportiert aber 2.1 – Mobile Safari spuckt dann lapidar „Safari cannot download this file“ aus.
Falle 2:
Also, man will ja auch was lernen, hab ich mit pythonvCard4 eine 4.0 vCard erzeugt. Mit Bild natürlich. Konnte iOS auch auf Anhieb öffnen, Android auch aber dort wurde ein Kontakt erzeugt der den Base64 Wert vom Bild im Namen hatte.
Aus irgendeinem Grund macht Android das wenn die Namensfelder („FN“ und „N“) vorm PHOTO Feld stehen. Also zuerst PHOTO dann FN/N im vCard File.
Falle 3:
Weiß nimmer genau wer mit was umgehen kann aber auf alle Fälle hab ich jetzt das PHOTO zweimal drin, einmal mit
Falls ich oder irgendwer es jemals wieder wo braucht 😀 Single host. Kein TLS. Ohne Schusswaffe. Nur um es mal gesehen zu haben.
Minio AGPL3 runterladen und installieren (erzeugt systemd Service „minio„, User und Gruppe „minio-user“ und Config auf /etc/default/minio) – ist seltsam weil offenbar je nach Download URL andere Lizenz im Executable eingebacken ist:
## Volume to be used for MinIO server.
MINIO_VOLUMES="/data/minio"
## Use if you want to run MinIO on a custom port.
MINIO_OPTS="--address :9198 --console-address :9199"
## Root user for the server.
MINIO_ROOT_USER=whatever1
## Root secret for the server.
MINIO_ROOT_PASSWORD=whatever2
## set this for MinIO to reload entries with 'mc admin service restart'
MINIO_CONFIG_ENV_FILE=/etc/default/minio
Der Datenpfad muss dem minio User gehören:
sudo chmod -R minio-user:minio-user /data/minio
Minio starten und systemd journal checken was abgeht:
Im Webinterface (Port 9199 gemäß obiger Config) kann man nicht viel machen außer Buckets verwalten (anlegen/löschen), daher brauchen wir MC, das CLI:
wget https://dl.min.io/client/mc/release/linux-amd64/mc
chmod +x mc
sudo cp mc /usr/local/bin/
mc braucht auch ein config file welches beim ersten Aufruf mit Defaultwerten befüllt wird (die nicht funktionieren oder wir erzeugen selbst eines – die Keys sind User/PW von /etc/default/minio) – die ist unter ~/.mc/config.json zu speichern:
Wir erzeugen ein Bucket und setzen die Region des Servers (+Restart desselben):
mc mb local/longhornbackup
mc admin config set local region name=myregion
mc admin service restart local
Dann brauchen wir noch eine Zugriffspolicy (Einschränkung auf unseren Bucket den wir soeben erzeugt haben) die wir dann unserem Backupuser zuordnen (minio-longhornbackup-policy.json):
Zuletzt legen wir einen User samt Access Key für Longhorn Config an und attachen die Policy (das local ist der Alias der Konfiguration aus der ~/.mc/config.json, das Kennwort ist irrelevant weil wir eh mit accesskey zugreifen):
mc admin user add local longhorn irgendeinkennwort
mc admin accesskey create local longhorn
mc admin policy create local longhornbackup ./minio-longhornbackup-policy.json
mc admin policy attach local longhornbackup --user longhorn
Mit den Werten die die accesskey Erzeugung unter „Access Key“ und „Secret Key“ ausgespuckt hat erzeugen wir ein Kubernetes Secret im longhorn-system Namespace (minio-secret hier, beim AWS_ENDPOINTS Wert den Servernamen auf dem Minio läuft plus den Port für API aus /etc/default/minio dort verwenden):
Zuletzt tragen wir das Backup Target im Longhorn Web UI noch unter Setting/Backup Target ein wobei der Teil vor dem @ der Name des Bucket ist und das hinterm @ die Region die wir gesetzt haben:
Problem: VPS mit rootless Podman Container die (völlig überraschend) Daten erzeugen die man (auch völlig überraschend) sichern will – aber nicht beim Hoster wegen Kosten und 3-2-1 Regel (wenn wir uns mal das 3 und 2 wegdenken).
Subproblem: Wegen UID Mapping haben die Daten die Container erzeugt einen Owner mit einer gemappten UID und somit kann der (unberechtigte) User der die Podman Container betreibt nicht auf die Daten zugreifen.
Lösung: Daten mit root und rclone als TAR (wegen Erhalt UIDs) nach OneDrive sichern und mit rclone alte Files löschen lassen.
rclone installieren
rclone config
als Name „onedrive“ angeben
type of storage „Microsoft OneDrive“ auswählen (bei mir 31)
client_id, client_secret überspringen
Region „Microsoft Cloud Global“
Advanced config: no
Auto Config: no
Auf Rechner mit Browser rclone authorize "onedrive" --onedrive-auth-url https://login.microsoftonline.com/<tenant-guid>/oauth2/v2.0/authorize --onedrive-token-url https://login.microsoftonline.com/<tenant-guid>/oauth2/v2.0/token
Output in config_token reinpasten
config_type=OneDrive Personal or Business (1 bei mir)
drive_id=das mit „Documents“ oder „Dokumente“ (1 bei mir)
Drive OK bestätigen
~/.config/rclone/rclone.conf auf /root/.config/rclone/rclone.conf kopieren
Backupscript erstellen (s.u.) ggf. --min-age anpassen wenn man Backups länger als 3 Monate aufheben will. Script geht davon aus dass User mit dem Container laufen podman heißt (-M podman@ im systemctl Call) und der Container mycontainer als Service podman-mycontainer im Ordner /path/to/mycontainerparent läuft und auf /targetfolder/on/onedrive gesichert werden soll.
Aufruf in System crontab einfügen (muss als root laufen weil die Dateien die im Container erzeugt werden ja UID-mapped sind und für normale User nicht zugreifbar sind).
Wollte Storage einer VM von einem LVM Store auf einen anderen verschieben und bin nach Start draufgekommen dass ich nicht das Hakerl bei „delete on source“ gemacht habe – abgebrochen in der Annahme dass er die unfertige Kopie am Ziel dann entfernt.
Natürlich hat er die Zieldisk nicht gelöscht und man konnte sie auch nicht manuell löschen weil er meinte es gibt eine VM dazu.
Lösung: qm disk rescan, das erkennt die in der Luft hängende Disk und fügt sie als „unused0“ der VM hinzu wo man sie dann kontrolliert löschen kann.
Obwohl TP-Link seit mehreren Jahren in diversen Supportforen angefleht wird das zu ändern sind neuere Omadataugliche TP-Link Switches ausschließlich über VLAN 1 adoptierbar.
Mein Lösungsansatz (für mich weil ichs bis zum nächsten Mal garantiert erfolgreich vergessen hab):
Port auf der Kiste wo Omada läuft freihalten
Bei Bedarf diesen Port auf 192.168.0.irgendwas (<> 1) konfigurieren, kein VLAN
Switch anstecken (am besten auf einem Port der auch in der Zielkonfiguration Default VLAN (1) hat) und mit Strom versorgen
Warten bis der Switch in Omada auftaucht
Adopten
[falls noch nicht erledigt VLANs in Omada unter Settings/LAN erzeugen]
Bei den Ports die Zielkonfiguration der Ports herstellen (VLANs/Trunks) herstellen.
In der Config unter VLAN Interface das gewünschten Management VLAN hinzufügen enablen und editieren
„Management VLAN“ enablen und Adresse vergeben (oder für die mutigen halt mit DHCP am Managementinterface arbeiten)
Wenn man den Switch jetzt an dem Port in Richtung eine Switches dessen Zielport mit dem Management VLAN tagged ist anbindet sollte man normal weiter administrieren können.
Falls der Konfigurationsport nicht VLAN 1 behalten soll entsprechend konfigurieren.
Problem: Linux, HP EliteBook 850 G5 mit HP LTE Modem. Nach 1-12x zuklappen und Sleep erwacht das Modem nicht mehr aus dem Schlaf und man muss alles mögliche und unmögliche restarten (am besten aber rebooten) um Dornröschen wachzuküssen.
Ursache: Würde mal annehmen HP?
Lösung/Workaround: Es gibt ein Tool mit dem man bestimmte USB Geräte zurücksetzen kann: usb_modeswitch, man braucht „nur“ Vendor- und Product-ID von dem Gerät welche man mit lsusb rausfinden kann:
Danach einfach das Gerät resetieren und es sollte zurück ins Leben kommen:
Problem: Single Host Proxmox Installation. 3 Linux Bridges – vmbr0 für den Host selbst, vmbr1 für die CorpNet Simulation, vmbr2 für die Internetsimulation. Keine bessere Möglichkeit als Host Firewall gefunden um vmbr1 und vmbr2 voneinander abzuschotten (also das Internetsimulation nicht die VMs in der CorpNetsimulation sieht) und folgende Regel eingetragen (123 ist Internet, 122 ist CorpNet):
Hat super funktioniert, auch über Reboots hinweg bis ich angefangen habe pve8to9 für Upgrade auf PVE 9.0 auszuführen und paar Warnings weggemacht habe (nix was eigentlich Firewall ändern sollte) – auf einmal ging nix mehr rein aber alles raus (VM und Host selber kamen überall hin).
Ursache: Unbekannt, irgendwas hat die Regel die vorher einwandfrei auch ohne Zusatzregeln funktioniert hat geändert.
Lösung (vermutlich grauslicher Hack aber für mich reichts): Da man ja remote nicht mehr drauf kommt lokal oder über KVM oder IPMI in /etc/pve/nodes/<hostname>/host.fw IN und OUT Regeln eintragen:
[OPTIONS]
nftables: 1
[RULES]
FORWARD DROP -source 192.168.123.0/24 -dest 192.168.122.0/24 -log nolog
OUT ACCEPT -log nolog
IN ACCEPT -log nolog