Beiträge von netzlodern

    Ich habe in meinem internen Wiki folgendes Snippet gefunden:

    Bash
    # Die Variablen muss man natürlich noch ersetzen!
    ip route change default via $GATEWAY src $ADDRESS

    Wie man das jetzt bei Netplan korrekt hinterlegt, müsste ich aber auch erst recherchieren.

    DAS hat die Lösung gebracht. Super, vielen Dank!


    Via netplan selbst hab ich es auch nicht eingestellt bekommen. Für alle die es interessiert - zumindest unter Ubuntu 20.04 mit networkd-dispatcher:


    1.) Neue Datei erstellen (Besitzer muss root sein): sudo /etc/networkd-dispatcher/routable.d/50-ifup-hooks


    Bash
    #!/bin/bash
    
    # Variablen $IFACE, $GATEWAY und $ADDRESS muss man noch ersetzen!
    ip route change default dev $IFACE via $GATEWAY src $ADDRESS

    2.) Rechte setzen: sudo chmod u+x /etc/networkd-dispatcher/routable.d/50-ifup-hooks

    3.) sudo netplan apply


    Fertig! :)



    Vielen Dank nochmal an alle die versucht haben zu helfen! :)

    Am liebsten wäre mir, wenn die generelle Ausgangs-IP die Failover ist.


    Speziell geht es hier jedoch um Apache, nginx und PHP (FPM und CLI).

    Bei diesen Diensten hört auch alles eingehend ausschließlich auf die Failover.. aber für ausgehend hat das leider keine Wirkung.

    google einmal nach deprecated address und lft_preferred


    Danke, der Tipp war schon gut, funktioniert nur leider nicht wie erwartet. :(


    Die netplan-Config sieht nun wie folgt aus:


    Ein "ip a" gibt dann auch folgendes aus für o.g. IPs:

    Code
    inet 6.7.8.9/32 scope global ens3
           valid_lft forever preferred_lft forever
    inet 1.2.3.4/22 brd 1.2.3.255 scope global deprecated ens3
           valid_lft forever preferred_lft forever


    Die Lifetime für die "1.2.3.4" bleibt also auf "forever", obwohl sie als deprecated gekennzeichnet ist.

    Auch ein "ip route" bestätigt, dass die falsche IP weiterhin verwendet wird:

    Code
    ip route get 8.8.8.8 | head -1 | gawk '{ print $5,$7 }'
    ens3 1.2.3.4


    Das Verhalten bleibt sowohl nach einem "netplan apply" als auch nach einem Neustart das Selbe.

    Die netplan Version ist bereits die 0.100, welches o.g. Konfiguration ermöglicht (mit 0.99 gings noch nicht). Ich habe es dennoch ebenso mit den Hooks des networkd-dispatcher versucht - vergebens.


    Weitere Ideen? :)

    Hallo zusammen,


    ich steh irgendwie auf dem Schlauch. Entweder es geht nicht oder mir fehlt der Ansatz.


    Wir haben einen Server mit gebuchter IPv4 Failover-Adresse. Installiert ist Ubuntu 20.4 LTS - Netzwerk-Konfiguration mit netplan.

    Soweit so gut. Funktioniert auch alles soweit.


    Aber wie bekomme ich es nun hin, dass statt der Standard-IP-Adresse (im Beispiel: 1.2.3.4) die Failover-Adresse (im Beispiel: 6.7.8.9) als ausgehende IP verwendet wird?

    Also das bei Fremdservern angezeigt wird, dass die Verbindung von der Failover-IP kommt.


    Hier meine netplan-Config - weitere Netzwerk-Einstellungen sind sonst abweichend vom default nicht gesetzt:

    Code
    network:
      version: 2
      renderer: networkd
      ethernets:
        ens3:
          addresses: ["1.2.3.4/22", "4.5.8.9/32"]
          gateway4: "1.2.3.1"
          nameservers:
            addresses: [46.38.225.230, 46.38.252.230]


    Besten Dank für eure Hilfe,

    Patrick

    Hallo liebes netcup-Team,


    im SCP gibt es m.E. einen Bug mit der IPv6-Failover Darstellung im Bereich der Auswahl.


    Während im Dropdown im Bereich IPv4 an bereits zugeordneten Adressen erscheint zu welchem Server diese bereits zugewiesen ist, wird im IPv6 Dropdown nur ein Sterchen angezeigt.

    Somit verliert man leider den Überblick welches Netz noch frei wäre und ordnet ggf. versehentlich ein bereits vergebenes Netz woanders zu.


    In dem Zusammenhang würde ich gerne auch nochmal auf meine damalige Feature-Request hinweisen :)



    Beste Grüße

    netzlodern

    [netcup] Felix P. bei dem aktuellen Angebot "Root-Server 4000 SSDx4 G8" steht in der Übersicht 480GB SSD (wahrscheinlich richtig) und auf der Produktseite wird mit 560GB SSD geworben.


    Welche Angabe stimmt?

    Rein rechnerisch müssten eigentlich aber die 560GB stimmen. Der normale 4000er hat 140GB SSD drin.

    Macht nach Adam Riese: 4x 140GB = 560GB


    Nehme also mal an, dass das auf der Produktseite stimmt und in der Übersicht ein Fehler ist.

    Hallo,


    der ionCube Encoder für PHP 5.6 ist lauffähig bis PHP 7.1.

    Ab PHP 7.2 muss der Encoder für PHP 7.2 genommen werden, welcher aber ebenso für PHP mit Version 7.3 funktioniert.


    Also entweder auf PHP 7.1 umstellen oder das Script mit der neueren Version encoden lassen.



    Beste Grüße

    Müssen die 1-3 im Code einfach ausgetauscht werden ?

    Die Zeile

    Code
    Options +FollowSymlinks

    in der .htaccess-Datei sollte durch

    Code
     Options +SymLinksIfOwnerMatch

    ersetzt werden.

    Ersatzweise ganz entfernt.


    Persönlich würde ich zum ersetzen raten um die Funktionalität von Joomla - oder auch anderen Systemen wo dies so vorkommt - nicht zu gefährden.



    Beste Grüße

    Patrick

    KB19 & Mordor vielen Dank für eure Antworten.


    Tja, das ist/war es ja gerade, wir haben zwar nen vorgeschalteten Filter, dieser lehnt aber E-Mails halt nur ab und benachrichtigt entsprechend.

    Eigentlich hatten wir nichts via default eingestellt, dass der Spam- oder Virenfilter standardmäßig aktiviert ist. Im Gegenteil: Ja, die Services stehen zur Verfügung, aber es muss je Account/Mailbox aktiv aktiviert werden - was es bei den betreffenden Accounts nicht war.

    Mir/uns ist durchaus bewusst, dass das verschieben von Haus aus rechtlich schwierig wäre.


    Aber eure Antworten bzgl. "wie werden die Mails denn verschoben" hat mich erneut darüber nachdenken lassen, wie das überhaupt sein kann.

    Und siehe da: Ich stoße auf den bekannten Plesk-Fehler #PPPM-7745 im Zusammenhang mit der Plesk-gesteuerten DMARC-Prüfung. Nicht nur, dass diese Prüfung einen Fehler hat, nein, ihr ist es auch noch total egal ob der Filter ein- oder ausgeschaltet ist und das Verschieben eben eigentlich nicht stattfinden sollte.


    Ich habe die DMARC-Prüfung somit soeben komplett ausgeschaltet und sehe das Problem nun als erledigt an.

    Vielen Dank nochmal für diesen Denkanstoß!

    Hallo zusammen,


    ich wundere mich zwar, aber ich hab tatsächlich über die Suche nicht gefunden, dass das Thema schon mal aufkam.

    Vielleicht passt es auch eher ins "Plesk"-Unterforum hier, aber so ganz sicher war ich mir da nicht.


    Es geht um folgendes:

    Wir betreiben mehrere Server, u.a. auf Plesk-Basis. Der Kunden-Mail-Server läuft mit Plesk und daran ist leider auch nicht zu rütteln. -.-

    Nun ist es so, dass der Abruf der E-Mails via IMAP problemlos funktioniert und die Mails alle dargestellt werden - fein säuberlich in den einzelnen Ordnern, etc.


    Jetzt haben wir allerdings auch einige Kunden die auf POP3 setzen, setzen wollen und wohl teilweise auch müssen.

    Hier gehen die Probleme jedoch los:

    E-Mails die vom System aus direkt in den Ordner "Spam / Junk" verschoben werden bekommen diese User niemals zu gesicht. Diese werden via POP3 schlicht und einfach nicht abgeholt.

    Irgendwie logisch, es ist halt nicht der passende INBOX-Folder.


    Aber wie bewerkstellige ich das? Ich probiert hier schon eine ganze Weile rum, aber ich scheitere leider an der Stelle irgenwie zu bewerkstelligen, dass via POP3 halt woanders geschaut wird.


    Folgende Ansätze habe ich im Web gefunden - beide im Prinzip "gleich":

    Virtual Mailboxes (ganz unten)

    Dovecot SIEVE-Filter für POP3-Nutzer


    An den Anleitungen kann man sich auch recht gut langhangeln und es ist soweit alles logisch... und dann kommt die Stelle wo es darum geht dem Dovecot beizubringen, dass sich bei POP3 anderes verhalten werden soll (userdb extra fields / user_query).


    Hat jemand eine Idee, Lösung oder/und es gar schon selbst umgesetzt auf Plesk-Basis?!

    Ich werd noch verrückt.. Aber wie gesagt, an Plesk ist hier leider nicht zu rütteln... :wacko:



    Beste Grüße

    Patrick

    Die PHP-Version mal überprüft? Ist es die Selbe oder eine andere - oder zumindest die selbe Versionsreihe?

    Wenn nicht: Einfach im WCP umstellen.


    Ggf. verträgt sich die Software auch nicht mit'm nginx oder die htaccess ist falsch konfiguriert/fehlerhaft/kann nicht vom Apache verarbeitet werden.


    Was sagen die Log-Files?

    Moin,


    wir haben selbige Erfahrung mit SORBS gemacht. Einige Konfigurationen und Listen-Kombinationen ausprobiert.


    SORBS liefert mit Abstand die meisten False-Positives bei all den getesteten Listen.

    Die einzigen Listen die von SORBS in unseren Augen nutzbar sind, sind diese: Sorbs BadConf, Sorbs NoMail, Sorbs PreEmpt, Sorbs Relays



    LG

    Wie schaut denn die Einstellung unter "Einstellungen Webserver" bzw. "Einstellungen für Apache & nginx" der Domain wo das Problem auftritt inzwischen aus?

    Ist der Haken bei "Fähigkeit, symbolischen Verknüpfungen zu folgen, einschränken" gesetzt oder nicht?


    Beide Einstellungen, also "+FollowSymlinks" und "+SymLinksIfOwnerMatch", zu setzen macht keinen Sinn. Ich würde nur "+SymLinksIfOwnerMatch" wählen und "+FollowSymlinks" rausschmeißen - dann ist es egal ob der eben abgefragte Haken gesetzt ist oder nicht. Der Besitzer der Dateien solltest du immer sein bei PHP mit FPM.


    Müsste es nicht über SoGo möglich sein anhand der Nutzerkennung den richtigen Mailserver auszuwählen [netcup] Felix P.

    Ich habe auch mal gelesen, dass nginx auch IMAP Server loadbalancen kann und anhand des Logins den passenden Server auswählen kann.


    https://www.nginx.com/resources/admin-guide/mail-proxy/

    Bzgl. nginx haben wir vor etwa einem halben Jahr viel und lange ausprobiert.


    Das funktioniert alles soweit gut, außer das man es nginx offenbar nicht beigringen kann das Passwort verschlüsselt an den Zielserver zu übertragen. Die verschlüsselte Anmeldung des Users, etc. mittels eigener Login-Logik (prüfung des Passworts gegen die Datenbank) funktioniert alles soweit, aber die verschlüsselte Übertragung des Kennworts - je nach gewähltem Algorithmus - an den Zielserver funktioniert dann nicht mehr. Da muss man das PLAIN-Kenwort für bemühen.


    Entweder hab ich hier gewaltig was überlesen in der Dokumentation oder das ist einfach eine Eigenheit die nginx da leider hat.