Beiträge von sTeaLth

  • Aktualisierung/Modernisierung des Repository-Keys

    Zitat von bravesurfer

    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?

  • Ausblick auf das nächste große Release

    Zitat von antondollmaier

    "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?

  • Ausblick auf das nächste große Release

    Hallo Herr Keppler,


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

    Zitat von kk

    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.

  • Ausblick auf das nächste große Release

    Zitat von kk

    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

  • Überlauf php_errors.log

    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

  • Überlauf php_errors.log

    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

  • Sporadische Probleme mit milter-reject

    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!?!?

  • Sporadische Probleme mit milter-reject

    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.

  • Roundcube Update

    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

  • Roundcube Update

    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?

  • Fehlermeldung beim Update auf Version 2.13.0

    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

  • Lets Encrypt SSL-Zertifikate des Administrators werden ungültig angezeigt

    Zitat von kk

    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.

  • Lets Encrypt SSL-Zertifikate des Administrators werden ungültig angezeigt

    Zitat von kk

    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.

  • Lets Encrypt SSL-Zertifikate des Administrators werden ungültig angezeigt

    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?

  • Postfächer löschen

    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.

  • Spamfilter für alle E-Mailadressen eines Kunden aktivieren.

    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

  • Meldungen Dovecot / Postfix - Ubuntu 18.04.5

    Hallo und vielen Dank.
    Ich konnte das Problem gerade auf den eingesetzten Virenscanner der Kundensysteme (ESET NOD32) eingrenzen. auch nach einem Update von Version 13 auf die aktuelle Version 14 bleibt das Problem bestehen. Windows Updates wurden auf den Systemen gestern nicht durchgeführt.
    Wir haben die IP des Servers erstmal aus der Protokollüberprüfung des Virenscanners entfernt und der Fehler taucht beim abrufen unserer Konten nun nicht auf. Andere Konten (iCloud) haben aber das gleich Problem. Anscheinend hat ESET sein Protokollset zurückgestuft oder kaputt gemacht.


    kk Ich kann Ihnen gerne noch den Namen des Mailservers schicken, denke aber das Thema hat sich erledigt.
    Ich hatte auch schon einen Report über "hardenize.com" erstellt und konnte da alles wie Konfiguriert nachvollziehen.


    Dann ist das einzige Thema in diesem Thread was noch offen bleibt, warum der Dovecot beim starten die SSLv2 Warnung ausgibt obwohl die Konfiguration und der Check von extern was anderes sagt.


    Code
    Oct 27 12:37:02 host01 dovecot: master: Dovecot v2.2.33.2 (d6601f4ec) starting up for imap, pop3 (core dumps disabled)
Oct 27 12:37:02 host01 dovecot: config: Warning: SSLv2 not supported by OpenSSL. Please consider removing it from ssl_protocols.


    Gruß
    Simon