Beiträge von sTeaLth

    Vielen dank Ralf, aber ist die von dir benannte Lösung nicht nur temporär?
    Die Postfixkonfigurationen main.cf und master.cf werden doch von Liveconfig überschrieben (sofern nicht deaktiviert, was ich nicht will).


    Jetzt habe ich aber im Zusammenhang noch ei aktuelles Anliegen, wo mir evtl. jemand helfen kann.
    Seit gestern morgen bekomme ich noch weitere Meldungen und jetzt auch Probleme bei den Mailclients der User, die Ihre Mails nicht abrufen können.


    Weil die User sich erst heute gemeldet haben, dachte ich zuerst es liegt an den Updates die ich gestern eingespielt habe.
    Aber die Updates habe ich erst um 15:09Uhr gemacht und nicht schon um 11:15Uhr.
    Meiner Meinung nach ist SSLv2/SSLv3 schon lange im dovecot deaktiviert.
    Ich habe jetzt gerade auch nochmal unter "/etc/dovecot" alles mit dem Backup von Sonntag verglichen.
    Da steht schon länger in der von liveconfig generierten "dovecot.conf" -> "ssl_protocols = !SSLv2 !SSLv3" drin.


    Gestern Nachmittag habe ich folgende Pakete aktuallisiert:

    Code
    Start-Date: 2020-10-26  15:09:02
    Requested-By: stealth (1000)
    Install: linux-modules-extra-4.15.0-122-generic:amd64 (4.15.0-122.124, automatic), linux-headers-4.15.0-122:amd64 (4.15.0-122.124, automatic), linux-headers-4.15.0-122-generic:amd64 (4.15.0-122.124, automatic), linux-modules-4.15.0-122-generic:amd64 (4.15.0-122.124, automatic), linux-image-4.15.0-122-generic:amd64 (4.15.0-122.124, automatic)
    Upgrade: perl-base:amd64 (5.26.1-6ubuntu0.3, 5.26.1-6ubuntu0.5), python2.7-dev:amd64 (2.7.17-1~18.04ubuntu1.1, 2.7.17-1~18.04ubuntu1.2), libpython3.6-minimal:amd64 (3.6.9-1~18.04ubuntu1.1, 3.6.9-1~18.04ubuntu1.3), php7.2-common:amd64 (7.2.24-0ubuntu0.18.04.6, 7.2.24-0ubuntu0.18.04.7), php7.2-cgi:amd64 (7.2.24-0ubuntu0.18.04.6, 7.2.24-0ubuntu0.18.04.7), php7.2-cli:amd64 (7.2.24-0ubuntu0.18.04.6, 7.2.24-0ubuntu0.18.04.7), linux-headers-generic:amd64 (4.15.0.118.105, 4.15.0.122.109), linux-libc-dev:amd64 (4.15.0-118.119, 4.15.0-122.124), vim-common:amd64 (2:8.0.1453-1ubuntu1.3, 2:8.0.1453-1ubuntu1.4), linux-image-generic:amd64 (4.15.0.118.105, 4.15.0.122.109), php7.2-mysql:amd64 (7.2.24-0ubuntu0.18.04.6, 7.2.24-0ubuntu0.18.04.7), python2.7-minimal:amd64 (2.7.17-1~18.04ubuntu1.1, 2.7.17-1~18.04ubuntu1.2), libpython3.6-stdlib:amd64 (3.6.9-1~18.04ubuntu1.1, 3.6.9-1~18.04ubuntu1.3), php7.2-sqlite3:amd64 (7.2.24-0ubuntu0.18.04.6, 7.2.24-0ubuntu0.18.04.7), perl-modules-5.26:amd64 (5.26.1-6ubuntu0.3, 5.26.1-6ubuntu0.5), sudo:amd64 (1.8.21p2-3ubuntu1.2, 1.8.21p2-3ubuntu1.3), libpython2.7:amd64 (2.7.17-1~18.04ubuntu1.1, 2.7.17-1~18.04ubuntu1.2), python2.7:amd64 (2.7.17-1~18.04ubuntu1.1, 2.7.17-1~18.04ubuntu1.2), libpython3.6:amd64 (3.6.9-1~18.04ubuntu1.1, 3.6.9-1~18.04ubuntu1.3), python3.6:amd64 (3.6.9-1~18.04ubuntu1.1, 3.6.9-1~18.04ubuntu1.3), libpython2.7-dev:amd64 (2.7.17-1~18.04ubuntu1.1, 2.7.17-1~18.04ubuntu1.2), php7.2-json:amd64 (7.2.24-0ubuntu0.18.04.6, 7.2.24-0ubuntu0.18.04.7), php7.2-opcache:amd64 (7.2.24-0ubuntu0.18.04.6, 7.2.24-0ubuntu0.18.04.7), php7.2-curl:amd64 (7.2.24-0ubuntu0.18.04.6, 7.2.24-0ubuntu0.18.04.7), perl-doc:amd64 (5.26.1-6ubuntu0.3, 5.26.1-6ubuntu0.5), libperl5.26:amd64 (5.26.1-6ubuntu0.3, 5.26.1-6ubuntu0.5), python3.6-minimal:amd64 (3.6.9-1~18.04ubuntu1.1, 3.6.9-1~18.04ubuntu1.3), php7.2-imap:amd64 (7.2.24-0ubuntu0.18.04.6, 7.2.24-0ubuntu0.18.04.7), python3-distupgrade:amd64 (1:18.04.38, 1:18.04.40), ubuntu-release-upgrader-core:amd64 (1:18.04.38, 1:18.04.40), php7.2-readline:amd64 (7.2.24-0ubuntu0.18.04.6, 7.2.24-0ubuntu0.18.04.7), php7.2-gd:amd64 (7.2.24-0ubuntu0.18.04.6, 7.2.24-0ubuntu0.18.04.7), vim-runtime:amd64 (2:8.0.1453-1ubuntu1.3, 2:8.0.1453-1ubuntu1.4), vim:amd64 (2:8.0.1453-1ubuntu1.3, 2:8.0.1453-1ubuntu1.4), xxd:amd64 (2:8.0.1453-1ubuntu1.3, 2:8.0.1453-1ubuntu1.4), libpython2.7-minimal:amd64 (2.7.17-1~18.04ubuntu1.1, 2.7.17-1~18.04ubuntu1.2), libfreetype6:amd64 (2.8.1-2ubuntu2, 2.8.1-2ubuntu2.1), perl:amd64 (5.26.1-6ubuntu0.3, 5.26.1-6ubuntu0.5), vim-tiny:amd64 (2:8.0.1453-1ubuntu1.3, 2:8.0.1453-1ubuntu1.4), libcryptsetup12:amd64 (2:2.0.2-1ubuntu1.1, 2:2.0.2-1ubuntu1.2), libpython2.7-stdlib:amd64 (2.7.17-1~18.04ubuntu1.1, 2.7.17-1~18.04ubuntu1.2), linux-generic:amd64 (4.15.0.118.105, 4.15.0.122.109)
    End-Date: 2020-10-26  15:10:09


    Vorher am Tag wurde Serverseitig nichts verändert.


    Kann da wohl ein Zertifikat abgelaufen sein oder hat MS gestern irgendwelche tollen Patches gemacht?
    User mit Problemen sind z.Z. Outlook User (z.B. Outlook 2013 per POP3)


    Gruß
    Simon

    Hat jemand von euch Ubuntu 18.04 am laufen und auch die folgenden Meldungen?


    Code
    Sep  9 17:52:39 host01 postfix[12605]: Postfix is running with backwards-compatible default settings
    Sep  9 17:52:39 host01 postfix[12605]: See http://www.postfix.org/COMPATIBILITY_README.html for details
    Sep  9 17:52:39 host01 postfix[12605]: To disable backwards compatibility use "postconf compatibility_level=2" and "postfix reload"
    Sep  9 17:52:39 host01 postfix/postfix-script[12710]: starting the Postfix mail system
    Sep  9 17:52:39 host01 postfix/master[12712]: daemon started -- version 3.3.0, configuration /etc/postfix
    
    
    Sep  9 17:52:42 host01 dovecot: master: Dovecot v2.2.33.2 (d6601f4ec) starting up for imap, pop3 (core dumps disabled)
    Sep  9 17:52:42 host01 dovecot: config: Warning: SSLv2 not supported by OpenSSL. Please consider removing it from ssl_protocols.


    Ich habe die Postfix und Dovecot Config auch schon neu schreiben lassen.
    Muss die Dovecot Konfig von LC nicht anders erstellt werden, damit die Meldung verschwindet?
    Die Meldung taucht bei jedem neustart von Dovecot und bei jedem delivery in eine Mailbox auf.
    Bei Postfix bin ich mir nicht sicher, ob es ggf. an meiner custom.lua liegt, aber bei Dovecot benutze ich den LC Standard.

    Ich zahle Geld für eine Software die mir Ermöglicht meine Projekte effizient zu verwalten und zu erstellen, das aber nicht macht und ich dann noch tricksen muss? Danke nein. Lizenz ist bereits gekündigt.


    Sie haben ein Problem mit den Produkt Liveconfig und wenden sich nicht an den offiziellen Support, sondern das Forum. Kollegen stellen Ihnen Fragen, welche Sie nicht beantworten und Sie fragen aber nach einem Workaround. Anschließend bemängeln Sie den Workaround und danken ab. Wahrscheinlich kann Ihnen gerade niemand helfen, aber eine Lösung für Ihr Problem mit dem Produkt gibt es bestimmt.


    Vielleicht holen Sie nochmal tief Luft und überdenken Ihren Unmut, denn Liveconfig ist in der Tat ein sehr tolles Produkt und auch das Team um Herrn Keppler ist sehr angegiert für alles eine Lösung zu finden.

    Wie ist der aktuelle Stand? Der Termin für die versprochene nächste Preview ist ja nun doch schon ein paar Tage her (Das nächste Preview-Release ist für kommenden Dienstag, 02.07.2019 geplant.).
    Welche "Showstopper" sind noch offen?

    Ich habe die Optionalen Liveconfig php Packete (56/70/72) für Ubuntu 16.04 installiert.
    Ich bekomme beim nutzen der "date" Funktion mit php56 die folgende Meldung:

    Code
    date(): It is not safe to rely on the system's timezone settings…


    Wenn ich nun nach der Option "date.timezone" in der php.ini suche, finde ich die Option nur in den php70 / php76 conf Ordnern.

    Code
    grep date.timezone /var/www/webXY/conf/php*/php.ini 
    /var/www/webXY/conf/php70/php.ini:date.timezone = Europe/Berlin
    /var/www/webXY/conf/php72/php.ini:date.timezone = Europe/Berlin


    Ich habe mit geholfen, in dem ich unter "/opt/php-5.6/etc/conf.d/" eine "custom.ini" angelegt habe.

    Code
    cat /opt/php-5.6/etc/conf.d/custom.ini 
    [Date]
    date.timezone = Europe/Berlin


    Ist die Option "date.timezone" in php56 noch kein Standard oder warum wird diese nicht gesetzt

    Hab ich auch schon vermutet, laut maldet und chkrootkit ist aber alles sauber. Ich konnte bisher auch nichts anderes auffälliges finden. Ich suche mal weiter.

    Evtl. kann mir hier jemand weiterhelfen oder mir verraten, wo ich noch gucken/fragen kann.
    Eine meiner Websites läd seit kurzem Total langsam bzw. Antwortet erst sehr spät. Manchmal kommt es dann auch zu einem "Internal Server Error".
    Nun habe ich schon herausgefunden, was da passiert.
    Erstmal habe ich gesehen, dass da eine Connections auf eine IP geöffnet werden.
    Also tcpdump gestartet und den Dump analysiert.
    Sobald ich die Seite aufrufe, macht der Server im Hintergrund eine DNS Abfrage auf "htmlvalue.com" und dann auch mehrere HTML Gets. (sooo what, ich weiß nicht wo das herkomt)
    Nun habe ich in der Firewall alles auf diese IP blockiert und zack ... alles wieder schnell.


    Da "html" und "value" ja häufiger im html / php Code vorkommen, dachte ich da ist wohl irgend was kaputt im Script.
    Hat einer von euch eine Idee, wie ich das Debugen kann?
    Gibts es die Möglichkeit dem DNS lookup zu entlocken, welches script bzw. welcher aufruf es gestartet hat?


    Es handelt sich um ein älteres CMS System, was demnächst auch abgelöst wird.
    Das alles läuft auf Ubuntu 16.04 LTS.

    Ich habe die "alten" Debian Packete unter "Ubuntu 14.04.5 LTS" genutzt. Kann mir jemand sagen, ob die neuen da weiterhin funktionieren? Beim Update sieht es so aus, als würde er die Packete nur entfernen wollen.

    Wir werden in den nächsten zwei Monaten aber noch eine Herstellererklärung vorbereiten, die genau darlegt, welche Daten wo gespeichert und welche Daten an uns übermittelt werden.


    Gibt es dazu schon was neues?


    Vielen Dank

    Hallo liebe Community,


    wie der Titel schon sagt, möchte ich weg von "Weg von postfix.NOUPDATE = true".
    Gibt es einen Weg ohne das Clonen in ein Testsystem, mir die Postfix Konfiguration die Liveconfig erzeugen würde ausgeben zu lassen?
    Bedingt durch eine Migration des Systems habe ich noch ziehmlich viele anpassungen in Postfix, welche ich nun eleminieren / durch "postfix.LOCALCONFIG" ersetzen will um wieder zu einem Standardsystem zu gelangen.


    Vielen Dank

    Release-Intervalle werden in den kommenden Updates wieder kürzer ausfallen.
    Wir planen das offizielle Release von v2.6.0 für kommende Woche ein (also noch vor Pfingsten).


    Jetzt wartet doch mal ab, Pfingsten ist doch erst am 09.06.2019 ;)

    aber beachten, dass der Server außerhalb der Vertragsordner in /var/log auch Logs hat!




    Wenn die IP anonymisiert wird, ist das denke ich flexibel. Ohne Anonymisierung maximal 7 Tage, aber auch das ist eher heikel.


    Das Thema ist jetzt aber generell ein bisschen problematisch oder nicht?


    Nach BGH-Urteil vom 3. Juli 2014, Az. III ZR 391/13 darf ich doch maximal sieben Tage die Log Dateien mit vollständiger IP-Adressen aufbewahren um, "im Einklang mit dem Telekommunikationsgesetz (TKG) Netzstörungen und Fehler an TK-Anlagen abzuwehren.".


    Oder trifft dies bei reinem Hosting nicht zu?


    Sofern eure Kunden personenbezogene Daten speichern, müssten diese als Veranwortliche doch auch AV-Verträge mit euch machen.


    Wie geht Ihr mit der Thematik um?

    Im Apache könnte man es ggf. noch abschalten. Aber nicht für E-Mail.


    Versteh ich, aber geht es mit Liveconfig Boardmitteln? Es geht mir auch nur um das Webserver Log.
    Wenn es nicht mit Boardmitteln geht, hat jemand eine Idee wie man es sonst ggf. löst?

    Ist es auch möglich das Logging für einen Kunden zu deaktivieren/sperren? Der Kunde benötigt kein Logging bzw. keinen Zugriff darauf. Wie setze ich dies am besten um, damit dies seine Datenschutzerklärung schlanker macht?

    Hallo Klaus,


    geht das nicht einfach über "Hosting" -> "PHP-Einstellungen"? Da kannst du "open_base" anpassen und es gilt, sofern nicht schon im "Vertrag" angepasst, dann sofort diese Einstellung.


    Gruß
    Simon