Kategorie: Uncategorized

SNMP-Odysee mit Zabbix und Mikrotik

Aus mehreren Gründen (und aus Rache gegen vermeintlichen Vendor-Lock-In) bin ich auch privat auf Zabbix umgestiegen. Mikrotik mit SNMP einbinden und abfragen? Easy Peasy!

Bis zum Tag X, an dem zwei weitere Mikrotik Geräte mit RouterOS dazu kamen. Nix zu wollen! Ich dachte erst es ist ein Template-Problem bei Zabbix, weil ich Switche (aus guten Gründen, Danke Sandro 😉 mit RouterOS betreiben wollte.

cannot read from session: Bad parse of ASN.1 type (plaintext scopedPDU header type

snmpwalk mit v3, sah alles Top aus, keine Passwort oder IP oder Firewall Probleme. Alles ausgeschlossen. Nur sobald ich das in Zabbix haben wollte -> Nada!

Stunden später bin ich auf einen Beitrag aufmerksam geworden, dass die EngineID unterschiedlich sein muss, das auch sollte, aber aus irgendwelchen Gründen bei Mikrotik gleich ist.

Einfach einen eindeutigen String bei Engine ID suffix (ich hab mich dann für die Primäre MAC-Adresse ohne Doppelpunkte/Striche entschieden) eintragen, und das Thema ist durch.

Proxmox LXC Container überschreibt /etc/resolv.conf

Wenn man auf Proxmox LXC Container betreibt, wird die /etc/resolv.conf immer wieder beim Neustart überschrieben. Das ist von Vorteil, damit die Einstellungen aus der GUI konsequent gesetzt werden. Allerdings fehlt dadurch die Möglichkeit auch mal keine search(domain) zu setzen. Bei einem leeren Feld werden die Einstellungen des Proxmox Hosts gezogen, und diese dürfen nicht leer sein.

Bei meinen unbound DNS Resolvern müssen diese aber leer sein, u.a. aus mehreren Gründen (dazu später mehr).

Die Lösung ist eine wenig dokumentiertes Proxmox Feature, bei welchem man in der VM bzw. im Container selbst eine „Ignore“-Datei anlegt.

sudo touch /etc/.pve-ignore.resolv.conf

sorgt dafür, dass die resolv.conf nicht mehr verändert wird. Das geht auch mit anderen Dateien, die normalerweise beim Reboot geschrieben werden.

P.S: Fast die Gründe vergessen, warum ein DNS Resolver (der wohlgemerkt das hier in der /etc/resolv.conf stehen hat)

nameserver 127.0.0.1

sich beim selbst befragen nicht auch noch auf eine search(domain) stürzen sollte:

  • fehlerhafte oder verlängerte DNS-Auflösungen
  • Query-Erweiterungen, die nicht gewollt sind
  • potenzielle NXDOMAIN-Fehler
  • Debugging-Aufwand bei internen Zonen

By the way, eigene Resolver helfen übrigens hervorragend, wenn man SPAM-Listen mit eigenen Mailservern befragen möchte. Happy Resolving 😉

Hinweis: Bei einigen Distributionen (z. B. Ubuntu-LXCs) oder bei aktiviertem DHCP/systemd-resolved kann Proxmox Standard-Konfiguration trotzdem erneut die resolv.conf überschreiben — selbst wenn die Datei /etc/.pve-ignore.resolv.conf existiert. In diesem Fall kann es notwendig sein, zusätzlich systemd-resolved zu deaktivieren oder einen dhclient-Hook zu nutzen, der das automatische Neuschreiben von /etc/resolv.conf verhindert.

Quellen: https://pve.proxmox.com/wiki/Linux_Container#_guest_operating_system_configuration

Nextcloud – Fehler beim Mailserver einrichten

Beim einrichten eines SMTP Mailservers im Nextcloud Backend kommt es, trotz korrekter Daten zum Fehler: AxiosError: Request failed with status code 400

In den Logs wird nichts ausgegeben, der Fehler tritt nur in der Weboberfläche auf und zeigt sich genau so in den Developer Tools

Grund ist eine fehlende E-Mail Adresse des Nextcloud-Benutzers mit dem man angemeldet ist. Nextcloud versucht direkt einen Test-Mail Versand vorzubereiten, bricht aber mit diesem Fehler ohne E-Mail Adresse im User-Profile ab. Also falls ihr normale User und Admin User nutzt, auch beim Admin eine E-Mail hinterlegen 😉

Danke an Janaka_Wickramasingh aus dem Nextcloud Forum: https://help.nextcloud.com/t/axioserror-request-failed-with-status-code-400/217651/11

I ran into the same error message. When I debug the request, it showed me that I haven’t set the email address for admin user that I’m trying test i.e. adding email to Personal Settings → email , fixed my issue. Hope this helps.

It’s a fresh installation of Nextcloud Hub 9 (30.0.6)

Cheers,
Janaka

SCP Funktioniert nicht auf aktuellem Debian 12

Auf einem aktuellen Debian funktioniert zwar der Zugriff per SSH und SSH-Keys, aber scp funktioniert nicht. Vor allem bei der Provisionierung mit Ansible tritt dieser Fehler auf.

Problem war eine Fehlerhafte Zuweisung des SFTP Subsystems in der Datei /etc/ssh/sshd_config

Dort musste die Direktive „Subsystem sftp internal-sftp-server“ abgeändert werden, und der letzte Part „-server“ entfernt werden.

Anbei das Kommando für die Änderung mit sed

sed -i 's/internal-sftp-server/internal-sftp/' /etc/ssh/sshd_config
systemctl restart ssh

rsync + SSH + Kompression

Wer regelmäßig Daten zwischen Servern schieben muss, sollte rsync mit SSH und Kompression nutzen

rsync -az --info=progress2 -e 'ssh -T -c aes128-gcm@openssh.com' ./local/ user@host:/remote/
AttributBemerkung
-aArchivmodus (Rechte, Zeiten, rekursiv)
-zKomprimierung aktivieren
–info=progress2Fortschritt anzeigen
-e ’ssh -c aes128-gcm@openssh.com‘schneller Cipher für besseren Durchsatz

Courier IMAP: Fehler nach Debian-Update

Nach der Installation mehrerer Debian Major-Updates (Version 10 -> 11 -> 12) war IMAP von manchen Clients nicht mehr nutzbar.

Es kam zu folgender Fehlermeldung im Mail-Log:

Mar 24 23:42:23 $host courier-imaps: ip=[$ip], couriertls: /etc/courier-imap/courier.pem: error:1E08010C:DECODER routines::unsupported

Auf iOS äußerte sich der Fehler mittels folgender Meldung:

E-Mails können nicht empfangen werden
Der Mail-Server „$server“ reagiert nicht. Überprüfe, ob du in den Mail-Einstellungen die richtigen Accountinfos eingegeben hast.
Unable to create a secure connection to the server („Ungültige
Protokollversion“ -9.836).

In einer älteren Microsoft Outlook Version schlug der Abruf der IMAP-Ordner fehl. Zudem blieb Outlook mehrfach beim Start hängen und reagierte nicht mehr.

Ursache war eine veraltete /usr/share/dhparams.pem

Lösung: /usr/share/dhparams.pem löschen und mittels folgendem Befehl neu generieren:

/usr/sbin/mkdhparams

Details & Quellen:

Systemd auf Debian installieren

Um Sytemd auf (älteren) Debian-Systemen zu installieren, folgende Befehle ausführen:

aptitude install systemd systemd-sysv

Nach einem Reboot soll PID 1 auf systemd zeigen. Check via:

ps -f -p 1

Falls hier noch /sbin/init ausgegeben wird, ist das in der Regel ein Symlink zu /lib/systemd/systemd.

Quellen: