Beiträge von m_ueberall

Fürs Protokoll: Neben den vorgenannten Dovecot und Postfix würde ich noch Rspamd empfehlen, welches seinerzeit mehrere zusätzliche Hilfsprogramme ersetzte.

Zitat von Paul

Letztendlich bauen die fertigen Lösungen auch nur auf diesen bzw. ähnlichen Komponenten auf, sind aber nicht direkt auf das oben genannte Setup ausgelegt, weswegen ein manuelles Setup sicher nicht so viel aufwändiger wäre.

Hier würde ich anraten, zumindest einmal einen Blick auf ein "Rundum-Sorglos-Paket" wie mailcow zu werfen, um eine Idee dafür zu bekommen, was möglich/konfigurierbar ist (auch wenn ich besagtes Paket nicht selbst nutze).

Je nach den eigenen Wünschen ist ein Fokus auf das unbedingt Benötigte mittel-/langfristig immer besser, allerdings dauert es seine Zeit, bis man sich in alles eingelesen hat (und wenn man allzu spezialisierte Konfigurationen verwendet, wird die Luft schnell dünner, wenn man bei Problemen Dritte kontaktieren will – Daumenregel: je größer die Nutzerbasis, desto höher die Chance, dass sich schon einmal jemand dem Problem gegenübersah). Ich habe über die Jahrzehnte sicherlich viele PT an der Konfiguration herumgeschraubt, um sie zu perfektionieren; auch wenn die Programme inzwischen auch "Kinderkrankheiten" loswurden und zusätzliche Funktionen lernten, ist das Aufsetzen eines Mailservers (inklusive Backup-Funktionalität!) nicht zu unterschätzen.

Ganz wichtig sind natürlich externe Funktions- und Sicherheitstests (ein Beispiel: MECSA).

Zitat von dirk1405

Seit wann macht man denn bitte ein Screenshot von der Bestellung?

Schon immer.

Zitat von killerbees19

Mit Verlaub, aber bei solchen Fehlern wie im Nachbarthread muss Dein Browser alles großflächig rot unterstreichen.

Ich möchte hier diesbezüglich https://languagetool.org/ empfehlen (die Serverkomponente kann man – mit wenigen Abstrichen, was die Funktionalität betrifft – sogar lokal laufen lassen), welches mehrere Sprachen unterstützt und mit wenigen Gigabyte großen N-Gramm-Statistiken sogar in der Lage ist, falsche Wortkombinationen zu identifizieren!

20201021_langtool_port8082_4.png

Zitat von m_ueberall

Preisfrage: Wie bekomme ich ohne Reboot fehlerhafte Einträge (Dateisystem fuse.xyz) aus /proc/self/mounts entfernt?

[…]

Zitat von H6G

grep -r fuse /proc/*/mounts - fuse durch den richtigen FS Typ ersetzen.

PIDs werden eigentlich aufsteigend vergeben, d.h. der Treffer mit der kleinsten PID dürfte deine Quelle sein.

Das Problem ist weniger die Enumeration aller Elterprozesse und "Kontexte" (=Namensräume) als vielmehr die Tatsache, dass ich offensichtlich nicht den richtigen K./NR. identifizieren kann, um den Einhängepunkt zu löschen:

#!/bin/bash

MPOINT="$1"

PSPIDS=""
PSPID=$$
while [[ ${PSPID} -gt 0 ]]; do
    PSPID="$(ps -p ${PSPID} -o ppid=)"
    [[ ${PSPID} -gt 0 ]] && PSPIDS="${PSPID} ${PSPIDS}"
done

for PSPID in ${PSPIDS}; do
    MNS0="$(ls -l /proc/${PSPID}/ns/mnt)"
    MNS0="${MNS0%\]}"
    MNS0="${MNS0##*\[}"
    grep -q "${MPOINT}" /proc/${PSPID}/mounts
    RCODE=$?
    printf "%10d %10d %d\n" ${PSPID} ${MNS0} ${RCODE}
    #if [[ ${RCODE} -eq 0 ]]; then
    #    nsenter -t "${MNS0}" umount "${MPOINT}"
    #    exit 0
    #fi
done

Wenn ich das Script mit dem Einhängepunkt als Parameter aufrufe, sehe ich, dass alle Elterprozesse des aktuellen Prozesses ($$) denselben Mount-Namensraum verwenden (inklusive Prozess Nummer #1, init). Allerdings liefert der manuell ausgeführte, mit dem entsprechenden ${MNS0} versehene nsenter-Befehl dasselbe Ergebnis, als würde ich umount direkt in der aktuellen Shell ($$) ausführen (was mir auch wieder logisch erscheint). man nsenter hat mich noch nicht auf die richtige Idee gebracht…

Zitat von killerbees19

m_ueberall fusermount -u klappt auch nicht?

Nein, fusermount -u [-z] ... liefert mir in diesem Fall einen "Invalid argument"-Fehler.

Zitat von H6G

Warum explizit /proc/self - bist du in einem Container? (lxc oder Docker)?

Nein, kein Container. /proc/self ist hier nur als "Einstiegspunkt" erwähnt – der Einhängepunkt ist natürlich "ge-/vererbt" und spiegelt sich in /proc/*/mounts wider.

Meiner Meinung nach ist der originäre Kontext zu identifizieren, in welchem das Dateisystem ursprünglich eingebunden wurde und dort eine Bereinigung durchzuführen, aber ich habe noch keine rechte Idee, wie ich das anstelle.

Im Ergebnis sollte der Einhängepunkt aus allen ("Kind-")Kontexten verschwunden sein (und somit auch aus /proc/self/mounts).

Zitat von m_ueberall

Preisfrage: Wie bekomme ich ohne Reboot fehlerhafte Einträge (Dateisystem fuse.xyz) aus /proc/self/mounts entfernt?

Zitat von voja

Geht ein umount -f ?

Nein, umount -f (oder umount -l) meldet, dass hier nichts eingebunden sei (was insofern korrekt ist, als die vorherigen Inhalte verschwunden sind; ich kann keine Hilfsprozesse mehr identifizieren, welche mit der vorherigen Einbindung in Zusammenhang stehen).

Preisfrage: Wie bekomme ich ohne Reboot fehlerhafte Einträge (Dateisystem fuse.xyz) aus /proc/self/mounts entfernt?

Zitat von chroscher

Du meinst vielleicht 'nen Raspberry Pi in der Schublade?

Als Alternative zum Raspberry Pi möchte ich an dieser Stelle – insbesondere, wenn es um rechenintensivere Vorhaben geht – explizit den ODROID N2+ nennen (maximal 4GB RAM anstatt 8GB RAM beim Raspberry, aber 4x2.4+2x2.0GHz-CPU-Kerne bei problemloser Übertaktung). Ein Exemplar davon steht mit dem oben abgebildeten Zusatzlüfter hier neben einem NUC und ist selbst bei aktivem Lüfter (der selten anläuft, obwohl das Gerät als reine Build-Maschine für die ARM64-Architektur verwendet wird und regelmäßig beschäftigt ist) schon bei weniger als 1m Abstand lautlos. IMHO ein fantastisches Preis-/Leistungsverhältnis.

Zitat von andreas.

m_ueberall: Die Ergebnisse der Seite whatsmydns.net sind mit Vorsicht zu genießen.

Sofern infolge einer Änderung im CCP nach kurzer Zeit aber an zahlreichen, unterschiedlichsten Orten mehr grüne Häkchen/zurückgelieferte IP-Adressen sichtbar sind als davor, tendiere ich dazu, von einer Besserung auszugehen, die ihren Ursprung bei den Netcup-Servern/-Einträgen hat (wobei wie geschildert insbesondere das "verlorene DNSSEC-Häkchen" ein Indiz eines lokalen Ereignisses ist).

Gestern ab 17:30h waren bei einer über Netcup-DNS-Server verwalteten .org-Domäne nach Rückmeldungen aus dem Ausland (verschiedene Länder) für einige Stunden keine DNS-A-Einträge mehr sichtbar; im CCP war das DNSSEC-Häkchen verschwunden. Ein "Refresh" – durch Setzen des genannten Häkchens, natürlich mit entsprechender Verspätung, weil entsprechende E-Mails erst 16h später gelesen wurden – hat laut https://www.whatsmydns.net/ inzwischen wohl den gewünschten Heilungseffekt angestoßen.

Nachdem die Domäne jedoch niemals einen SMIMEA-Eintrag besessen hat, an dessen Existenz vorherige/selbst beobachtete Probleme in diesem Diskussionsfaden festgemacht wurden, und von Netcup selbst keine (proaktive) Störungsmeldung vorliegt, beunruhigt mich dieser Vorfall.

Zitat von Kaishiyoku

Wenn ich keine Netzwerk-spezifischen Einstellungen schreibe, was würde dann passieren? Bzw. wozu ist die 50-cloud-init.yaml überhaupt da?

Ohne jegliche netzwerkspezifische Einstellungen dürfte in der Regel nur die lo-Schnittstelle zur Verfügung stehen.

Die vorgenannte Deaktivierung würde sich nur auf das Cloud-Init-Rahmenwerk auswirken, wenn dieses auch installiert ist; unter Debian/Ubuntu muss in diesem Fall folgendes Paket vorhanden sein:

# dpkg --list cloud-init | grep "^ii" | sed -e 's|   *|  |g'
ii  cloud-init  20.3-2-g371b392c-0ubuntu1~20.04.1 all  initialization and customization tool for cloud instances

Wenn also 50-cloud-init.yaml die einzige Datei im Verzeichnis /etc/netplan/ ist, und es sich um eine durch Netcup gestellte Installation handelt, dann hat man im Wesentlichen ein Artefakt bzw. das Ergebnis der nicht näher dokumentierten Netcup-eigenen Provisionierung vor sich. Wenn man das vorgenannte Cloud-Init nicht verwendet, kann die genannte Datei eigentlich auch nie überschrieben werden, obwohl man sinnvollerweise die Datei /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg mit obengenanntem Inhalt anlegt, um sich vor "Überraschungen"/Seiteneffekten zu schützen. Eine Umbenennung der YAML-Datei dient dann einem Administrator normalerweise auch als Anhaltspunkt dafür, dass Cloud-Init nicht in die aktive Verwaltung des Inhalts involviert ist.

Sofern man sich entschließt, (später) Cloud-Init zu verwenden, macht es umgekehrt natürlich Sinn, keine (anderen) Dateien in /etc/netplan/ zu behalten, um ggf. Seiteneffekte zu vermeiden. (Insofern kann man nicht sagen, dass es ungeschickt von Netcup sei, Vorgabe-Einstellungen in 50-cloud-init.yaml abzulegen.) Leider unterstützt Netcup das Rahmenwerk bislang providerseitig noch nicht.

Zitat von Kaishiyoku

Mein Quellcode stammte aus der 50-cloud-init.yaml.

Zwei Anmerkungen dazu zur Sicherheit:

1. Wenn der Quellcode die ersten drei von mir genannten Zeilen nicht enthält (also oben nicht nur ausschnittsweise zitiert wurde), wäre das sehr seltsam.
2. Die Datei 50-cloud-init.yaml selbst sollte man niemals editieren. Im Zweifelsfall sollte sie gelöscht und Cloud-Init angewiesen werden, keine netzwerk­spezifischen Einstellungen zu schreiben. Bei Ubuntu findet sich diesbezüglich normalerweise folgender Header in der vorgenannten Datei, sofern sie existiert:

# This file is generated from information provided by the datasource.  Changes
# to it will not persist across an instance reboot.  To disable cloud-init's
# network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}

3. sudo netplan --debug try spuckt einige hilfreiche Informationen aus.

1. Sicher, dass die Netzwerkschnittstellen auch so heißen (ein ifconfig | grep ": " bzw. ip link show bringt hier ggf. Klarheit)?

2. Die Syntax der Datei sieht normalerweise leicht anders aus (siehe Zeilen 1–3 bzw. diese Beispiele) :

network:
  version: 2
  ethernets:
    ens1:
      dhcp4: yes
      dhcp6: yes

Zitat von DerRené

Doch doch, das klappt auch mit myfritz - in meinen Augen aber nicht sehr zufriedenstellend.

Legt man eine neue myfritz-Freigabe an (nicht die klassische Portfreigabe), erhält man eine Subdomain zur eigentlichen myfritz-Adresse, beispielsweise:

nas.kjsdjkfsdjhfsdsdf.myfritz.net - auf diese verweist dann sowohl die IPv4 der Fritzbox, als auch die öffentliche IPv6 des entsprechenden Gerätes.

Oh! Das muss ich überlesen haben, als ich mich mit den Freigaben beschäftigt habe (ich dachte, diese Namen wären nur lokal über die Fritz!Box selbst bekannt). Werde ich mir nochmal ansehen, danke!

Zitat von andreas.

Eventuell kann man es mit Exposed Host mit Hilfe eines nachgeschalteten Routers lösen. Siehe beigefügte Abbildung.

Ein "Exposed Host" bedeutet aber, dass alle Ports eines Clients/Hosts hinter der Fritz!Box freigeschaltet werden (=Portfreigabe) – was man für einfachstmögliche Konfigurationen haben will, wäre in der Regel wirklich eine IPv4-äquivalente Portweiterleitung; unter "0123456789abcdef.myfritz.net" findet sich ja "nur" die IPv4-/IPv6-Adresse der Fritz!Box selbst, und wenn das IPv6-Präfix ebenfalls dynamisch ist, reicht die Nutzung des AVM-DynDNS-Dienstes allein nicht mehr aus.

Nachgeschaltete Router o. ä. "Workarounds" (ich verwende für Tests u. a. einen tunnel broker via 6in4, wodurch ich für IPv6 nicht auf o. g. DynDNS-Dienst angewiesen bin) bedingen leider (noch?) immer zusätzlichen Konfigurationsaufwand.

Zitat von waster

[W]äre es möglich, einen zentralen DDNS Dienst zur Verfügung zu stellen, damit sich nicht jeder Kunde selbst etwas basteln muss? Oder habe ich diesen bisher noch nicht gefunden?

Zitat von geekmonkey

https://github.com/fernwerker/ownDynDNS (wie oben im Link zu finden) funktioniert bei mir seit Jahren ohne Probleme und läuft auf zwei verschiedenen Fritzboxen

Fürs Protokoll: Wenn wirklich Fritz!Boxen zum Einsatz kommen, kann man auch AVMs eigenen DynDNS-Dienst verwenden, indem man entsprechende CNAME-Einträge für eigene Subdomänen einträgt, wie an mehreren anderen Stellen in diesem Forum besprochen; siehe u. a. hier: https://forum.netcup.de/sonstiges/smal…ema/#post151049 (das funktioniert in der Praxis zumindest für IPv4-Ports an Geräten hinter der jeweiligen Fritz!Box – leider ist mir bislang kein "Hausmittel" für die Standard-Firmware bekannt, mit welchem sich IPv6-Portweiterleitungen einrichten ließen)

Zitat von Tojama

Komme nur noch via FileZilla oder WinSCP über FTP drauf.

Gibt es ggf. Snapshots, auf welche man verzichten kann? Diese sollten sich im SCP löschen lassen.

Inwiefern das bei einem "Managed Server" vertraglich gehandhabt wird, kann ich nicht sagen, aber der nächste Schritt bei einem selbstverwalteten Server wäre normalerweise ein Booten des/eines Rettungssystems, um den vollständigen Platteninhalt in Augenschein nehmen zu können. Eine mögliche Ursache für plötzlichen zusätzlichen Speicherbedarf sind vollgelaufene Logdateien (die aber meistens außerhalb des via FTP "einsehbaren" Bereichs liegen).

Zitat von mainziman

nicht wirklich, und wo stehen diese 16 DVDs als ISO zum Download bereit?

doofe Frage, oder?

Wenn selbst ich den Hyperlinks auf den Seiten folgen kann, […]

Siehe https://www.debian.org/CD/jigdo-cd/

#LastLink

Zitat von mainziman

[W]as wird einem da https://www.shoplinuxonline.com/debian10-full.html verkauft?

(ich find nur 3 DVD-ISOs zum Download, wo sind die anderen 13?)

Versuchen wir heute wieder, Andere für uns googeln zu lassen? Siehe ggf. https://cdimage.debian.org/debian-cd/current/amd64/list-dvd/