Beiträge von sTeaLth

    Hallo Klaus,

    in kenne das Problem nicht, habe aber selbst mal recherchiert und zwei mögliche Ursachen gefunden:
    Ein User schreibt, dass es bei Ihm nicht funktioniert sobald der Apache im Event Mode läuft.

    In welchem Mode läuft denn dein Apache? apachectl -M | grep 'mpm'
    Ein anderer User schreibt

    Zitat

    Also it might be possible that the environment variables were removed by suexec.

    Evtl hilft dir einer der Infos bei deinem Problem.


    Besten Gruß

    Simon

    Unter Ubuntu erhalten ich nach Installation des neuen liveconfig-keyring und Update folgende Fehlermeldung


    Code
    N: Das Laden der konfigurierten Datei »php/binary-i386/Packages« wird übersprungen, da das Depot »http://repo.liveconfig.com/debian bionic InRelease« die Architektur »i386« nicht unterstützt.

    Oder wenn die neuen Sources im deb822 Format angegeben sind, einfach um die Zeile Architectures: amd64 erweitern.


    Dies war bei mit mit Ubuntu 22.04.4 LTS auch nötig. kk kann das nicht direkt bei der Paket Installation abgefangen werden?

    "31.12.2039" würde uns doch auch nicht helfen...

    Grundsätzlich nicht direkt, aber man kann doch mal hinterfragen warum man überhaupt auf die v3 aufmerksam macht, wenn man es nicht annähernd in der geplanten Zeit (ggf. mit Toleranz von einem Jahr) veröffentlichen kann.
    Viele hier warten mit Spannung auf die v3, aber der Spannungsbogen droht doch dann zu reißen.

    Die API der v3 wurde am 06/07.11. aktualisiert, also wird wohl auch weiter und mit Hochdruck an der neuen Version gearbeitet.
    Aber wie weit man in Summe ist kann ich nicht einschätzen und ein kleines Feedback (evtl. einmal im Monat) wäre doch ganz Nett.

    Auch dazu kann ich nur sagen, warum dann so früh auf die v3 aufmerksam machen?
    Nicht falsch verstehen, grundsätzlich find ich es gut wenn man seine Kunden/Community mit in sowas einbezieht. Aber dann doch bitte mit annähernd realistischer Planung. Die LiveConfig GmbH und Keppler IT GmbH ist ja auch nicht erst seit 2 Jahren in dem Business.
    Auch ich möchte keine Version die voller Fehler steckt, aber manchmal muss man halt Abstriche machen und von Betatestern oder der Beta-Version die es seit dem 31.01.2022 geben soll hab ich hier auch noch nichts gelesen. Es gab aber schon öfter den Hinweis, dass bald eine Version zum Testen bereit steht.
    Wenn es die nicht gibt, brauchen wir Zeitnah wohl nicht mit einem Release der v3 rechnen oder?

    Hallo Herr Keppler,


    ich verstehe ihren Post und die damit verbundenen Schwierigkeiten, aber die meisten Themen gab es doch auch schon vor Liveconfig 3.

    Ich gebe mal einen ganz kleinen Einblick in die Komplexität scheinbar trivialer Funktionen.

    ...

    Sie sind ja nicht neu in Bereich der Entwicklung und müssten doch langsam mal sagen können, wann Sie das Produkt nun wirklich launchen können.

    Erst hieß es "3. Quartal 2022" und mittlerweile wird auch der voraussichtliche Release (aktuell steht "2. Quartal 2023") nicht mehr aktualisiert.

    Es wäre schön wenn es zumindest mal ein Datum gäbe, an dem es nun wirklich einen Release gibt.

    Wir arbeiten jeden Tag und ausschließlich daran weiter.
    Updates halten wir nicht zurück um die Spannung zu erhöhen ;) sondern weil es technische Gründe gibt.


    In der 2.14 gibt es sehr weitreichende Änderungen im Hintergrund, weshalb wir diese schrittweise mit den ersten Kunden produktiv ausgerollt haben und so die mit der Zeit aufgetretenen Probleme beheben konnten. Das "Stable-Release" erfolgt nun aber in Kürze.


    Gibt es denn ein Update? Sind Sie im "neuen" Zeitplan?
    Kurzes Feedback wäre super

    Das Logfile war einen Tag alt.
    Pro Aufruf immer 17MB ins Log:


    Code
    Got a packet bigger than 'max_allowed_packet' bytes für Abfrage UPDATE `wp_options` SET `option_value`


    Hatte den Apache natürlich neu gestartet und anschließend auch mal den ganzen Server, aber immer wurden wieder 17MB ins Log geschrieben, weil mysql "max_allowed_packet" 16MB hatte. Hab das nun als Workaround erstmal auf 20MB gestellt. Andere Fehler kommen auch nicht ins Log


    Code
    /var/www/XXX/conf/php74/php.ini:log_errors = Off
    /var/www/XXX/conf/php74/php.ini:log_errors_max_len = 1024
    /var/www/XXX/conf/php7/php.ini:log_errors = Off
    /var/www/XXX/conf/php7/php.ini:log_errors_max_len = 1024
    /var/www/XXX/conf/php80/php.ini:log_errors = Off
    /var/www/XXX/conf/php80/php.ini:log_errors_max_len = 1024

    Ich habe das Problem aktuell auch 32GB php_errors.log Datei.
    Erst war "log_errors" bei dem Kudnen noch an, aber obwohl er nun explizit "log_errors = Off" hat wird weiter geloggt.


    Ubuntu 18.04.6 LTS
    PHP 7.4.33 von Liveconfig

    Ohje, sehe gerade das hier 2018 schonmal jemand das Problem geschildert hat.


    und auch eine Antwort von kk bekommen hat.



    https://www.liveconfig.com/de/…-7-1-Service-unavailable)


    kk Den "kritischen Bug" aus 2018 der den ClamAV zum Absturz bringt können wir wohl ausschließen, außer es gab aktuell wieder einen.
    Evtl. kann mein Post aber dann weg und ich Antworte / Frage unter dem alten Thread nochmal!?!?

    Hallo Community,
    ich habe heute nun zum zweiten mal in einer Woche das Problem, dass mein Postfix keine Mail mehr annimmt und folgende Meldung ausgibt:

    Code
    postfix/cleanup[23307]: 4JSgh638dhzFjRJ: milter-reject: END-OF-MESSAGE from host.domain.tld[A.B.C.D]: 4.7.1 Service unavailable - try again later; from=<abc@sender.tld> to=<xyz@recipient.tld> proto=ESMTP helo=<host.domain.tld>


    Beim ersten mal habe ich zuerst das System neu gestartet, hat aber nichts geändert.
    Dann habe ich festgestellt, dass der clamav-milter nicht gestartet war (trotz reboot). Also gestartet -> alles wieder ok.


    Als das Problem aber heute nochmals aufgetreten ist, lief der clamav-milter. Auch ein Neustart des Servers/Dienstes hat an der Situation nichts geändert.
    Da es beim ersten mal am ClamAV lag, habe ich diesen temporär deaktiviert, damit ich meine wichtige Mail erhalten hab und diesen dann wieder aktiviert. Und schwups war das Problem weg.


    Die eigentlichen Frage ist aber: Wie kann ich das Problem fassen / debuggen?
    So ein willkürliches Problem kann man ja nicht gebrauchen.


    Systeminfos:

    Code
    Ubuntu 18.04
    Postfix 3.3.0 (3.3.0-1ubuntu0.4)
    ClamAV (0.103.2+dfsg-0ubuntu0.18.04.2)
    SpamAssassin (3.4.2-0ubuntu0.18.04.5)
    OpenDKIM (2.11.0~alpha-11b)


    Danke für alle Ratschläge.

    Das hab ich mir ja auch gedacht und das "installto.sh" Script mit entsprechender php Version ausgeführt.

    Code
    sudo -u admin /opt/php-7.4/bin/php /var/www/admin/priv/roundcubemail-1.5.1/bin/installto.sh /var/www/admin/apps/webmail/


    Liegt aber wahrscheinlich daran, dass im Script dann wieder fest das "php" binary des Systems für den Aufruf der "update.sh" genutzt wird.

    Code
    system("cd $target_dir && php bin/update.sh --version=$oldversion" . ($accept ? ' -y' : ''));


    Genauso ist es auch, nach Anpassung der Zeile funktioniert es. Muss ich mir jetzt mal überlegen was ich daraus mache. Ist dann wohl am einfachsten wie kk schon schreibt einfach die "php-mbstring" der Distri zu installieren.


    Danke an alle und schöne Tage

    Ich habe gerade nach der Anleitung aus der KB versucht mein Roundcube zu aktualisieren. Habe ich auch vorher schon einige male so ähnlich gemacht.


    Die folgende Fehlermeldung kam auch schon beim ersten mal. Die Version ist aktuell nun schon 1.5.1 trotz Fehlermeldung.


    Diese ist auch gleich ob ich es mit php 7.2/7.4 oder 8.0 versuche.


    Ein "php -i | grep mbstring" bringt:

    Code
    Zend Multibyte Support => provided by mbstring
    Multibyte decoding support using mbstring => enabled
    usw.


    Jemand eine Idee?

    Beim aktualisieren habe ich folgenden Fehler erhalten:


    Code
    aptitude full-upgrade
    ...
    Fehler traten auf beim Bearbeiten von:
     liveconfig
    E: Sub-process /usr/bin/dpkg returned an error code (1)


    Für mich sieht aber alles normal aus. Auch im liveconfig.log, apt,dpkg, syslog etc. sehe ich keine gravierenden Fehler mit zeitlichem Zusammenhang.


    Bekannt? Betrifft das nur mich oder haben alle das einfach nur ignoriert?


    Ach ja:
    Ubuntu 18.04.6 LTS

    Das halte ich für ausgeschlossen: die von LiveConfig über Let's Encrypt abgerufenen Zertifikate enthalten derzeit immer beide Zwischenzertifikate (das ist derzeit der Standard bei Let's Encrypt). Da muss also irgendwo der Certbot im Spiel gewesen sein (möglicherweise wurde das betroffene Zertifikat mal über den Certbot oder eine andere Drittsoftware mit einer anderen Zertifikatskette angefordert, und LiveConfig hat bei einer späteren Zertifikatsbestellung für die selbe Domain dann auch die "kürzere" Chain zugewiesen bekommen).


    Da haben wir wohl aneinander vorbei gesprochen. Mit anderem System meinte ich tatsächlich nicht Liveconfig, sondern zig Hosts mit "win-acme" auf dem auch aktuelle Zertifikate drauf waren. Windows, Android und Co hatten damit keine Probleme, aber diverse IOS Geräte etc. Nach einem "force renewal" war denn der Spuk vorbei. Wenn uns das hier nicht hilft... aber ein neu erzeugtes Zertifikat in Liveconfig sieht erstmal so aus, als ob es was bringt.

    Alle von Let's Encrypt ausgestellten Zertifikate enthalten seit vielen Monaten bereits die "neue" Kette an Zwischenzertifikaten (also "R3" und "ISRG Root X1"). Eine Neuausstellung würde daran nichts ändern.


    Details werden gerade per Ticket geklärt.


    Das können wir so nicht bestätigen. Wir hatten in den letzten Tagen auf anderen Systemen ein ähnliches Problem mit den LE Zertifikaten, die beide Zwischenzertifikate enthielten und nach einem "force renew" nur noch das aktuell gültige. Alle Probleme waren dann gelöst.

    Aktuell scheinen wir auf einem System auch vom Let's Encrypt Zertifikatsketten Problem betroffen, auf welchem leider noch Ubuntu 16.04 läuft.


    Die Lösungen im Forum und Ihrem Blogpost haben leider keinen Erfolg gebracht.


    Mir ist aber aufgefallen das sehr viele Zertifikate noch eine alte kette mit verweisen auf die alte RootCA enthalten. (welche ja auch in der /etc/ssl/certs/8d33f237.* das Problem zu sein scheint)


    Gibt es eine Möglichkeit alle LE Zertifikate Zwangs zu erneuern, damit diese keine Verweise mehr auf die abgelaufene Kette enthalten?

    pitgrap ich glaube Sie haben den kk hier falsch verstanden.
    Er hat ja nur darauf hingewiesen, dass beim löschen der Domain zwei Möglichkeiten zum Handling der Postfächer angeboten werden (löschen oder parken).
    Sie wollten doch löschen. Warum nutzen Sie dann das parken? Oder habe ich jetzt was falsch verstanden?
    Hilft Ihnen jetzt nicht weiter, aber evtl. für das nächste mal.

    Mein Anliegen ist schnell beschrieben.
    Weiß hier jemand ob man den Spamfilter für alle E-Mail Adressen eines Kunden aktiveren kann, ohne dabei die Einstellung in jeder E-
    Mail Adresse manuell durchführen zu müssen?
    Und kann man irgendwo den Default so setzen dass bei jeder neuen E-Mail der Spamfilter aktiviert wird?


    Vielen Dank und schöne Feiertage