Die Standard-Farbauswahl in vi(m) ist für Hervohebungen von Syntax speziell auf dunklen Hintergründen schwer lesbar. Hat man schwarzen Hintergrund im Terminal und nutzt Syntax-Highlighting, so wird einiges in (dunkel)lila dargestellt.
Schwer lesbar.
Besser lesbar ist es, wenn man eine ~/.vimrc mit folgendem Inhalt anlegt:
Login auf einen Server mit ssh -X user@host.
Dort wird ein grafisches Programm gestartet. Beispielsweise gedit. Der Start wird mit der Fehlermeldung „X11 Forwarding: X11 connection rejected because of wrong authentication“ negativ quittiert. Gedit öffnet sich nicht.
1. Ist auf dem Server xauth installiert?
2. Ist in der ssh_config X11Forwarding erlaubt (default: no)?
X11Forwarding yes
X11DisplayOffset 10
X11UseLocalhost noNach dem Einfügen den SSH Service neu starten: sudo systemctl restart ssh.service . Logout aus dem Server und neu einloggen.
Weiterlesen
VM wird mit Ubuntu 25.10 „from scratch“ unter Proxmox 9.0.11 neu installiert.
Nach dem Booten funktioniert das Netzwerk, es sind alle aktuellen Updates für Ubuntu 25.10 installiert.
Diese VM wird geklont.
Der Klon hat nach dem Booten keine IP, ip a zeigt an, dass der Link down genommen ist.
Weiterlesen
Um sich ein self-signed (selbst-signiertes) SSL Zertifikat für eine Nginx Anwendung zu erstellen und diese zu nutzen:
sudo openssl req -x509 -nodes -days 3650 -newkey rsa:4096 -keyout /etc/ssl/private/hostnamezertifikatsname.key -out /etc/ssl/certs/hostnamezertifikatsnam.crt
(Hinweis: Die Gültigkeitsdauer von 10 Jahren sollte nur für Testumgebungen derart lang gesetzt werden.)
In der Konfiguration des Hosts die Umstellung von Port 80 („listen 80“) auf 443 vornehmen und die korrekten Pfade für das Zertifikat und den Key angeben:
server {
listen 443 ssl;
server_name meinhostname.tld; # alternativ die IP Adresse
ssl_certificate /etc/ssl/certs/hostnamezertifikatsnam.crt;
ssl_certificate_key /etc/ssl/private/hostnamezertifikatsname.key;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers HIGH:!aNULL:!MD5;
...
}
Nun den Webserver Nginx einmal neu starten:
sudo systemctl restart nginx
Man sollte nun beim Aufruf von https://IP_NGINX den Warnhinweis erhalten, dass die Verbindung zwar SSL gesichert, das Zertifikat aber nicht geprüft werden konnte, erhalten.
https://nginx.org/en/docs/http/configuring_https_servers.html
Nach einem Upgrade auf aktuelle MySQL 8.4er Version gibt es eine Änderung im Handling von Passwörtern.
Diese werden nun als gehashtes SHA2 Passwort in der Datenbank gespeichert.
In Logs, beispielsweise einigen PHP Anwendungen, die Zugriff auf eine Datebank herstellen wollen, erscheinen Fehlermeldungen wie diese
Um die alte (aber nicht mehr empfohlene) Funktion mysql_native_password wieder zu nutzen, legt man eine Konfigurationsdatei in /etc/mysql/conf.d/ an (sofern dieser Pfad per Include in der Konfiguration my.cnf steht), die man nach eigenem Namensschema benennen kann.
Wir nennen diese beispielsweise mysql_native_password.cnf.
Inhalt dieser Konfigurationsdatei:
# Alte Funktion mysql_native_password aktivieren
[mysqld]
mysql_native_password=ON
Danach muss der mysql-server Dienst einmal neu gestartet werden. Der Zugriff sollte nun wieder funktionieren.
https://php.watch/articles/fix-php-mysql-84-mysql_native_password-not-loaded
Mit dem Update auf PiHole 6 wurde von lighthttpd auf einen eigenen Webserver gewechselt.
Nach dem Update ist die WebGUI nicht mehr über den bekannten Link erreichbar.
Ursache: Es wurde vom Standard-Port 80 auf Port 8080 gewechselt.
Hierdrüber ist der Zugriff wieder ganz normal möglich.
Nan kann sich nun überlegen, ob man die Konfiguration anpasst, wieder auf 80 wechselt, einen ReverseProxy
einrichtet oder aber einfach den Port 8080 zukünftig nutzt (und ggfs. Links usw. auf die Gui anpasst).
Problem
ubuntu% ping heise.de
ping: socktype: SOCK_RAW
ping: socket: Operation not permitted
ping: => missing cap_net_raw+p capability or setuid?
Lösung
ubuntu% sudo setcap cap_net_raw+p /usr/bin/ping
ubuntu% ping heise.de
PING heise.de (193.99.144.80) 56(84) bytes of data.
64 bytes from 193.99.144.80: icmp_seq=1 ttl=247 time=11.4 ms
64 bytes from 193.99.144.80: icmp_seq=2 ttl=247 time=13.6 ms
Über Proxmox lässt sich ohne bekanntes root-Passwort auf Container/ VMs zugreifen. Auch bei gesetztem root-Passwort.
Ist für administrative (Erst-)Einrichtung sicher erstmal nett, aber langdfristig nicht unbedingt gewünscht.
Deaktivierung (root Passwort vorher setzen):
Den Bereich --autologin root aus der
/etc/systemd/system/container-getty@1.service.d/override.conf
entfernen. Speichern. Rebooten.
Nach einem Upgrade eines Ubuntu 24.04 auf 24.10 lässt sich der Container nicht mehr starten. Die Proxmox Infos hierzu sind erstmal nicht wirklich hilfreich:
run_buffer: 571 Script exited with status 255
lxc_init: 845 Failed to run lxc.hook.pre-start for container "CONTAINERID"
__lxc_start: 2034 Failed to initialize container "CONTAINERID"
TASK ERROR: startup for container '100' failed
Über die Konsole kommen mehr Infos:
pct start CONTAINERID –debug
Hier kommt raus, dass Ubuntu 24.10 scheinbar noch nicht unterstützt wird: „unsupported os type“
Lösung:
In der Konfigurationsdatei des Containers den Eintrag ostype auf unmanaged setzen.
Der Hinweis „Datenbank fehlen einige Indizes“ erscheint in der Nextcloud-Administrationsansicht.
Per OCC Kommando die fehlenden Indizes hinzufügen
sudo -u www-data php /var/www/pfad/zu/occ db:add-missing-indices