Beiträge von m_ueberall

    m_ueberall interessant; dass des auch bei einer anderen Distri existiert(e); CentOS vs. Debian

    Die distributions-spezifischen Anpassungen am "Kernfunktionsumfang" halten sich deutlich in Grenzen bei Postfix–Debian dürfte hier noch an den meisten Rädchen drehen:

    kann mich mal jemand über diesen Log eintrag im Postfix aufklären

    Dec 9 16:28:58 vhost01 postfix/smtpd[2437]: NOQUEUE: reject: CONNECT from unknown[unknown]: 550 5.7.1 Client host rejected: cannot find your hostname, [unknown]; proto=SMTP

    [...]

    wie kommt dieses 'unknown' an Stelle einer IP-Adresse zustande?

    Da hilft wohl nur Quellenstudium (für die verwendete Postfix-Version; allerdings sehe ich diese Einträge auch für v3.5.8): https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=461227#10

    Mir ist gerade auch mal aufgefallen das mein MX Eintrag nun auch weg ist, also kann keine E-Mail vom Support kommen ?

    Solange ein oder mehrere @ A-/AAAA-Eintrag/-Einträge vorhanden ist/sind, darf der MX-Eintrag "notfalls" fehlen (vgl. RFC 5321). Blöd ist nur (wie in meinem Fall), wenn ein MX-Eintrag vorhanden ist, aber seinerseits auf ungültige A-/AAAA-Einträge verweist. Dann kann man nur noch hoffen, dass ersterer zumindest noch gelöscht werden kann.

    Es ist keine gute Idee, eine E-Mailadresse eines im CCP verwalteten Produkts als Kontaktadresse für das CCP anzugeben.

    Ob man allerdings ein "x-beliebiges" E-Mail-Konto dafür verwenden will? Im CCP steht ja explizit "im Kleingedruckten":

    Zitat

    […] Die hier angegebene E-Mailadresse wird auch für den Inhaber und Admin-C Ihrer Domainregistrierungen hinterlegt. […]

    Das Problem ließe sich aber auch schon dadurch relaxieren, wenn man denn mehrere Adressen angeben könnte… ich glaube, das wurde irgendwann auch einmal hier andiskutiert.

    Vorhin zwei DNS-Einträge geändert; nun sind ca. 50% aller Einträge für die Domäne ungültig (zufälligerweise betrifft das fast alle TLSA-Einträge); DNSSEC-Flagge ist nach wie vor gesetzt. Nachdem offensichtlich entsprechende Probleme mit dem DNS in den letzten Tagen häufiger aufgetreten sind (hat sonst noch jemand ein oder mehrere Tickets hierzu offen?), frage ich mich, ob und ab wann mit einem Eintrag auf https://www.netcup-status.de/ dazu gerechnet werden kann…

    […] I don't think ETH2 validators can be consider as mining […]

    I would like to know if Netcup is against this usage of his servers, or if this can be consider as tolerated or allowed (maybe on root-servers?)

    Given that this is a customer forum, I'd suggest asking the support (regardless of previous discussions found here–if any) in writing. They will be able to give you a reliable answer (and once they're fed up with answering the same question about a certain topic over and over again, that answer will find its way into a FAQ/the wiki/their terms and conditions).

    Danke für deine Antwort. (Hoffe du ist okay...)

    Es ist ja bald Weihnachten, da will ich mal nicht so sein… :P

    Gibt es eine sinnvolle Möglichkeit einen Vergleich über die komplette Instanz zu machen?

    Sofern es auf beiden Rechnern ein Nutzerkonto mit (temporärer) Erlaubnis gibt, rsync als Superuser auszuführen (vgl. sudo), sollte der nachfolgende Befehl eine Liste aller abweichenden Dateien "ausspucken", welche man danach mittels diff vergleichen kann (man rsync usw. liefert Hilfestellungen bzgl. der Parameter – wichtig ist hierbei, unbedingt -n/--dry-run zu verwenden, sonst werden die Änderungen wirklich übertragen):

    Code
    sudo rsync -n -l -v -r -e "ssh" --rsync-path "sudo rsync" /<oberverzeichnis> [<nutzer@>]<anderer_rechner>:/<oberverzeichnis>

    Ansatzpunkt für die Fehlersuche wäre die Auflistung aller Unterschiede. Kommen bei beiden Rechnern dieselben (Unter-)Domänen zum Einsatz? Dasselbe Betriebssystem?

    • Wenn ja würde ich alle Dateien zwischen beiden Rechnern vergleichen (und ggf. danach Datenbank-/DNS-Einträge)
    • Wenn nein würde ich zunächst versuchen, eine identische Konfiguration herzustellen (und gewünschte Änderungen nachträglich anzuwenden, wenn ein "Clone" des ersten VPS funktioniert)

    In VNC kann ich ja nichts reinkopieren, drum ein Nutzer PW mit nicht zu vielen Stellen aber genügend.

    Wenn ich SSH nutze um den VPS zu administrieren würde ich einfach ein sehr langes PW aus dem PW-Tresor für den Nutzer Login nehmen, das ich dann aber nicht mehr von Hand in der VNC Konsole eingeben möchte...

    Am besten möchtest du garkein SSH Passwort sondern einen SSH Key verwenden.

    Den kannst du dann natürlich noch mit einem Passwort versehen.

    Nur, damit nicht aneinander vorbeigeredet wird: Die "Passphrase" für einen SSH-Schlüssel kann (und sollte) von einem Nutzerkontopasswort abweichen. Letzteres kann bei (Not-)Login via SCP durchaus relativ kurz sein, wenn man es nur dort nutzen kann. Denn wer Zugang auf den VPS via SCP hat, den interessieren Nutzerkonto­pass­wör­ter sowieso nicht mehr, weil er (sofern das Dateisystem nicht verschlüsselt und nach einem Reboot somit nicht mehr ohne weiteres lesbar ist) einfach über eine alternative Bootmöglichkeit (Rettungssystem/Bootdisk) an alle Inhalte herankommt…

    Ohne jetzt den Diskussionsfaden E-Mail-Server-Lösung für VPS halb "kapern" zu wollen: Obwohl ich selbst Mailcow nicht verwende, hat mich etwas gewundert, dass eine Suche nach Mailcow dsync dovecot keine (prominenten?) Ergebnisse lieferte. Nutzt wirklich Keiner eine solche Konfiguration? In den "Mailcow-Issues" auf GitHub wird im Kontext einer gemeinsamen Datei-/Mailablage immer nur auf "NFS" verwiesen, aber wenn es um Redundanz/hohe Verfügbarkeit für (dedizierte) Mailserver geht, erscheint das auf den ersten Blick (mit Kenntnis von dsync) suboptimal für kleine/kleinste redundante Installationen.