Autor: sscho

vmbr0: received packet on bond0 with own address as source address

Im Proxmox-Cluster bekam ich auf einem einzelnen Node (trotz gleicher Konfiguration an Netzwerkkarten, Ports und am Switch) die Fehlermeldung.

Die finale Lösung gefunden habe ich am Ende im Proxmox-Forum (nach etlichen fehlerhaften Versuchen):
https://forum.proxmox.com/threads/kernel-vmbr0-received-packet-on-bond0-with-own-address-as-source-address.133152/page-2#post-613634 (Archiv)

Aktuell sehen die Netzwerkeinstellungen für meinen vmbr0 Adapter daher so aus:

auto vmbr0
iface vmbr0 inet static
        address 192.168.XXX.107/24
        gateway 192.168.XXX.254
        bridge-ports bond0
        bridge_ageing 0
        bridge-stp off
        bridge-fd 0
        bridge-vlan-aware yes
        bridge-vids XXX-YYYY
        mtu ZZZZ

Hier ein manuelle Möglichkeit zur Bereinigung der Exchange Mailbox Logs, nach der ich schon seit Längerem gesucht habe.

Am einfachsten geht die Bereinigung der Logs ohne Applikationsbackups tatsächlich über den Befehl diskshadow.

Genaue Anleitung bei msp360, (Archiv)

kurzgesagt:
diskshadow
add volume c:
begin backup
create
end backup

Nachdem ich es mehrere Monate vor mir her geschoben habe, sind jetzt die Webseiten umgezogen auf den neuen Hosted Server.

Statt 320 GB HDD habe ich jetzt 640 SSD und zusätzlich sehr viel mehr RAM und CPU Kerne. Hat sich gelohnt.

Während ich die letzten Migrationen automatisch, also per Plugin gemacht habe, habe ich mir dieses Mal die Datenbank exportiert und auf dem neuen Server importiert. Das klappte tatsächlich alles ohne irgendwelche Probleme.

Das einzige was ich noch angehen will ist die Migration von MariaDB auf PostgreSQL, aber das eilt ja nicht.

Wireguard gibt es ja jetzt schon eine Weile, Zeit also bei meinem kommenden hosted Server die noch recht junge VPN Variante auszuprobieren.

Eine passable Anleitung habe ich hier gefunden:
https://www.server-world.info/en/note?os=Debian_12&p=wireguard&f=1 (Archiv)

Tatsächlich ist – sobald einmal verstanden – das erstellen der private keys und public keys das schwierigste bei wireguard. Der Rest ist Bestandteil des Linux Kernels.

Hier meine Server-Config mit 3 externen Peers:

[Interface]
# specify generated private key for server
PrivateKey = <private key server>
# IP address for VPN interface
Address = 10.0.88.1
# UDP port WireGuard server listens
ListenPort = 51820


# possible to set any commands after WireGuard starts/stops
# set routing rules like follows to access to local network via VPN session
# [wg0] ⇒ VPN interface name
# [eth0] ⇒ Ethernet interface name
PostUp = echo 1 > /proc/sys/net/ipv4/ip_forward; iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = echo 0 > /proc/sys/net/ipv4/ip_forward; iptables -D FORWARD -i wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

[Peer]
# specify public key pc1
PublicKey = <public key pc1>
AllowedIPs = 10.0.88.5/32
PersistentKeepalive = 25

[Peer]
# specify public key pc2
PublicKey = <public key pc2>
AllowedIPs = 10.0.88.6/32
PersistentKeepalive = 25

[Peer]
# specify public key pc3
PublicKey = <public key pc3>
AllowedIPs = 10.0.88.7/32
PersistentKeepalive = 25

Auf dem ersten Peer sieht es so aus:

[Interface]
PrivateKey = <private key pc1>
Address = 10.0.88.5/32

[Peer]
PublicKey = <public key server>
AllowedIPs = 10.0.88.0/24
Endpoint = 89.58.xxx.xxx:51820
PersistentKeepalive = 25

Tatsächlich musste ich den PersistentKeepalive mit aufnehmen, damit die Verbindung auch bestehen bleibt, damit sich die Peers untereinander anpingen können.

Sobald ich im Client die Allowed IPs auf 10.0.88.1/32 und 0.0.0.0/0 setze, wird der gesamte Internettraffic durch den Wireguard Tunnel geroutet und ich erhalte die externe IP meines gehosteten Servers.

Die Keys sind schnell erstellt mit:
wg genkey | tee /etc/wireguard/pc4.key und
cat /etc/wireguard/nb-anke.key | wg pubkey | tee /etc/wireguard/pc4.pub

Bisher kannte ich beim Thema Serverbackups am ehesten den Mechanismus der Vollbackups und darauf aufsetzend inkrementelle oder differenzielle Backups. Beim Proxmox Backup läuft das alles etwas anderes, wie ich jetzt im Forum erfragen konnte.

How does the Proxmox Backup Server _actually_ work? | compared to other backups (archiv)

The backup client splits the disk image or file archive (pxar) into chunks. Every chunk is compressed (and encrypted, if an encryption key is set) and stored on the backup server's data store. Storage happens based on the chunk's hash, meaning that if there are multiple identical chunks, only one copy is saved (deduplication). Aside from the stored chunks, every backup snapshot also produces index files (.didx/.fidx). These index files are essentially are list of all chunks (identified by their hash) that are needed for this backup.

Im Grundsatz wird also die VM nicht en Block gesichert, sondern in ewig viele Chunks aufgeteilt, gehasht und indexiert. Beim nächsten Backup wird halt geschaut ob sich die Hash-Werte der Chunks geändert haben.
Wenn ja, wird zusätzlich gesichert, wenn nein bleibt die vorhandene Chunk-Sicherung bestehen.

Das sieht man dann auch auf Dateiebene, jeder Chunk landet in einem entsprechenden Ordner. Nachteil ist, dass man keinen wirklichen Blick auf die eine große Datei hat die das Vollbackup darstellt. Kann ich aber gut mit leben.

Essentially, with this system, every backup snapshot is a 'full backup' – however the data is automatically shared with other backups, reducing the amount of needed storage drastically.

Und dabei kommt es darauf an, dass man keine korrupten Chunks gesichert hat. Verifikation spielt also eine wichtige Rolle. Denn die gesicherten Maschinen teilen sich ihre Chunks mit anderen Sicherungen derselben Maschine, sofern die Daten gleich sind.

In terms of data corruption: If chunk is corrupted, all backup snapshots that reference this particular chunk will be affected. If an index file is corrupted, only that particular snapshot is affected.

Verification jobs can be used to check if all chunks are clean, essentially it checks if the chunk's hash is equal to the expected one.

Das muss man natürlich beachten.

Bei der aktuellen Clusterkonfiguration ist es ohne Zutun zu folgendem Fehler im Ceph gekommen, aktuell in der Version 17.2.1, aber ich habe den Fehler auch bei anderen Versionen gefunden.

Klingt erst einmal hochdramatisch, bekommt man aber schnell in den Griff.

Die Lösung findet sich auch im Proxmox Forum (archiv)

Just did the same thing , I discovered than device_healths_metrics appear to be created by manager so

1 – Create a new manager , if you already have a second manager go to step two
2 – delete the first manager ( there is no data loss here ) , wait for the standby one to become active
3 – Recreate the initial manager , the pool is back

I re-deleted the device_health_metrics pool just to confirm and the problem Re-appeared , solved the same way

Tatsächlich eine Sache von zwei Minuten, dann ist der Fehler erst einmal weg. Bei den anderen produktiven Clustern ist das bisher nicht aufgetreten.

Bei der Einrichtung einer Debian 11 Maschine stand ich plötzlich vor dem Problem, dass permanente Routen nicht eingetragen wurden in der config. Manuell die route hinzuzufügen war kein Problem, aber es mit bestehenden Befehlen zu machen hat fehlgeschlagen

Lösung des Problems haben wir am Ende bei reddit gefunden:
Debian 11, Persistent routes not added (Archiv)

If you really need to make sure routes don't exist before adding extra routes, include "|| true" at the end of the command to avoid errors in trying to delete non-existing routes.

auto ens224
iface ens224 inet static
    address 172.16.150.99
    netmask 255.255.255.248
    gateway 172.16.150.97
    pre-up ip route del 172.16.120.1/32 via 172.16.150.97 dev $IFACE || true
    pre-up ip route del 172.16.31.54/32 via 172.16.150.97 dev $IFACE || true
    up ip route add 172.16.120.1/32 via 172.16.150.97 dev $IFACE
    up ip route add 172.16.31.54/32 via 172.16.150.97 dev $IFACE
    down ip route del 172.16.120.1/32 via 172.16.150.97 dev $IFACE || true
    down ip route del 172.16.31.54/32 via 172.16.150.97 dev $IFACE || true

Auf die Art und Weise kommen auch nach einem Reboot die statischen Routen wieder. Denn bisherige Anleitungen die ich gefunden hatte von 2020 mit Debian 10 funktionierten ein bisschen anders und führten nicht mehr dazu dass die statischen routen wiederaufgebaut wurden.

Für den reibungslosen Betrieb einer 3CX VM unter Proxmox empfiehlt sich die Installation eines Qemu guest agent, zum Beispiel für Speicherverwaltung.

Da 3CX ein angepasstes Repository benutzt, kann man Qemu nicht einfach nachinstallieren. Folgende Anleitung habe ich bei thetechbase (Archiv) gefunden:

1 Log into your 3CX server via SSH
2 Open /etc/apt/sources.list with nano
3 Add the following

deb http://deb.debian.org/debian/ buster main

deb-src http://deb.debian.org/debian/ buster mai

1. Save the sourses list
2. run apt-get install qemu-guest-agent
3. Edit your sourses list again to remove the above repo

Vor allem den letzten Punkt, also die Bereinigung der repos sehe ich als wichtig an, sonst könnte es Probleme geben mit dem Betrieb der Anlage bei Updates.

Problem:

Bei einer Kerio Connect Neuinstallation unter CentOS 7 war kein Active Directory Login der zugeordneten Benutzer möglich. Der Server war in die Domäne aufgenommen, die AD-Anbindung von Kerio Connect zur Domäne funktioniert, AD-Benutzer ließen sich importieren.
Bei dem Login gab es aber ungeklärte Probleme (Kerberos Fehler 0x16 Server not yet valid – try again later)

Lösung:

Quelle: https://docs.inuvika.com/active_directory_sso_using_kerberos/
Archiv: http://archive.is/f1SOr

Die Hauptschritte (Install and Configure Kerberos; Joining the Domain) etwas verkürzt dargestellt:

Installation und Konfiguration von Kerberos

Kerberos Workstation installieren:

yum install krb5-workstation

Neuerstellung der /etc/krb5.conf

[libdefaults]
  default_realm=TEST.DEMO
  kdc_timesync = 1
  ccache_type = 4
  forwardable = true
  proxiable = true
  fcc-mit-ticketflags = true
  default_keytab_name = FILE:/etc/krb5.keytab
 [realms]
  test.demo = {
  kdc = dc.test.demo
  master_kdc = dc.test.demo
  admin_server = dc.test.demo
  default_domain = test.demo
  }
 [domain_realm]
  test.demo = TEST.DEMO
 [logging]
  kdc = FILE:/var/log/krb5/krb5kdc.log

Die Platzhalter TEST.DEMO dc.test.demo, etc müssen entsprechend ersetzt werden.

Beitreten der Domäne

Samba Client installieren:

yum install samba-client

Die Konfigurationsdatei erstellen /etc/samba/smb.conf

[global]
 netbios name = osm
 realm = TEST.DEMO
 security = ADS
 encrypt passwords = yes
 password server = dc.test.demo
 workgroup = TEST
 kerberos method = dedicated keytab
 dedicated keytab file = /etc/krb5.keytab

Wieder müssen die Platzhalter ersetzt werden.
Zum Beitreten der Domäne benötigen wir den Befehl net ads join:

net ads join -U administrator@TEST.DEMO

Gerade sitze ich an meiner ersten Debian-Installation, und kämpfe mit Merkwürdigkeiten im Umgang mit vi.

Stellt sich heraus: die volle Version von vim ist ab Werk bei Debian 9 nicht mitinstalliert, man muss nachinstallieren.

>> ubuntu terminal is not working properly in vi editor

Aha, das hätte auch mal einer sagen können.