Beiträge von Nobbi

  • Ausblick auf das nächste große Release

    Zitat von kk

    Bei der DNSSEC-Migration gab es leider einen Fehler: bei DNS-Zonen, welche einen 4096-Bit RSA-Schlüssel als KSK haben, und bei denen wiederum der ZSK-Key-Tag einen kleineren Wert als der KSK-Key-Tag hat, bei denen wurde eine falsche DNSSEC-Policy in die Zonenliste geschrieben (für 2048-Bit statt 4096-Bit-KSKs). Das führte wiederum dazu, dass BIND die KSKs nicht übernommen sondern Neue erzeugt hat. :-/

    (das ist leider eine seeehr hässliche Nebenwirkung der "wir-kümmern-uns-ab-sofort-um-alles"-Philosophie bei dnssec-policy.


    Der Migrationsfehler wurde eben behoben, wir entwickeln eben noch ein Routine zur Korrektur aller betroffenen Domains (bei bereits migrierten Systemen), wird dann gleich in Form der v2.18.1 bereitstehen.


    Wir hatten im Rahmen eines Umzugs eine niedrige TTL für schnellere Umstellungen gesetzt. Genau das hat den Effekt des Problems potenziert:


    Durch die fehlerhafte dnssec-policy wurden offenbar neue KSKs erzeugt, was dazu führte, dass unsere Domain plötzlich nicht mehr auflösbar war – insbesondere bei deutschen DNS-Providern heute schon wieder, jetzt dauert es wieder mehrere Stunden bis die DNS Änderungen bei den Kunden ankommen, es ist zum Mäusemelken. Es tritt im übrigen nur bei .de domains bei mir auf die .at /.ch waren nicht betroffen das machte die Sache noch schwerer zu verstehen also musste es irgendwas mit der DENIC zu tun haben

  • Let's Encrypt für LiveConfig Basic

    Hab jetzt ein Upgrade bei meinem Provider durchgeführt 6 EUR im Monat mehr, naja was solls, schade nur das erstmal so nicht ersichtlich ist das ein upgrade fällig ist, hab 3 Stunden Zeit investiert da hätte ich die Lizenz 3 Jahre mieten können für :D

  • Lizenz kann nicht aktiviert werden wegen SSL Problem

    Zitat von suppenuser

    Liveconfig hat sein Zertifikat unter /etc/liveconfig/.


    Verstehe ich das richtig? Dein LC läuft seit 2014 im Demo-Modus?


    Nein seit dem letzten Update des SSL Zertifikates, war von 2 Jahren, an und für sich habe ich es mal 2014 eingerichtet und seither mache ich daran nichts nur das Zertifikat verlängern wenn es mal abläuft. Ich muss das Zerti bis Dienstag verlängern also einfach das vorhandene ersetzen was in der Apache config drin ist?

  • Lizenz kann nicht aktiviert werden wegen SSL Problem

    Liveconfig läuft ja nur läuft im Demo Modus ich habe das schon seit 2014, kann ich einfach die SSL Zertifikate manuell setzen? Also ich würde jetzt nachsehen woher liveconfig diese bezieht und einfach dort das neue Zertifikat hinterlegen? Ich muss dringend das Zertifikat erneuern.


    Zitat

    SSLCertificateFile /etc/ssl/certs/2e4c94f7d6f762eb.crt
    SSLCertificateKeyFile /etc/ssl/private/2e4c94f7d6f762eb.key
    SSLCertificateChainFile /etc/ssl/certs/2e4c94f7d6f762eb-ca.crt


    dort einfach die neuen Pfade rein oder aber die neuen Zertifikate gleich benennen?

  • Lizenz kann nicht aktiviert werden wegen SSL Problem

    Moin,


    ich hab ein Problem, mein SSL Zertifikat eines älteren Servers läuft bald ab. Nun musste ich die Lizenz aktualisieren weil aktuell der Demo modus läuft


    Code
    Generating license activation request, please wait... ok.
 - liveconfig: SSL peer certificate validation failed: certificate has expired
 error!
SSL peer verification failed


    Code
    --2022-06-14 12:41:02--  https://www.liveconfig.com/liveconfig.key
Auflösen des Hostnamen »www.liveconfig.com (www.liveconfig.com)«... 88.198.223.28, 2a01:4f8:bb:c00::2:28
Verbindungsaufbau zu www.liveconfig.com (www.liveconfig.com)|88.198.223.28|:443... verbunden.
FEHLER: Kann das Zertifikat von »www.liveconfig.com« nicht prüfen, ausgestellt von »»/C=US/O=Let's Encrypt/CN=R3««:.
  Das ausgestellte Zertifikat ist nicht mehr gültig.
Verwenden Sie »--no-check-certificate«, um zu dem Server »www.liveconfig.com« eine nicht gesicherte Verbindung aufzubauen.
gpg: Keine gültigen OpenPGP-Daten gefunden.



    Der Server hat noch ein altes Ubuntu 14.04 drauf kann ich aktuell auch nicht ändern, Update und Upgrades habe ich gemacht.


    Code
    N: Datei »liveconfig.list.1« in Verzeichnis »/etc/apt/sources.list.d/« wird ignoriert, da sie eine ungültige Dateinamen-Erweiterung hat.
W: Während der Überprüfung der Signatur trat ein Fehler auf. Das Repository wurde nicht aktualisiert und die vorherigen Indexdateien werden verwendet. GPG-Fehler: http://repo.liveconfig.com main InRelease: Die folgenden Signaturen konnten nicht überprüft werden, weil ihr öffentlicher Schlüssel nicht verfügbar ist: NO_PUBKEY D409AC6D65FE6664


W: Fehlschlag beim Holen von http://repo.liveconfig.com/debian/dists/main/InRelease


    Kann ich das Zertifikat auch einfach so erneuern?

  • Verwendung der Funktion TLSA Record in DNS Einstellungen

    Moin,


    ich wollte gerade einen TLSA Record für meinen Mailserver anlegen. Eigentlich dachte ich es wäre ein TXT Eintrag ähnlich wie SPF aber LiveConfig hat wohl einen eigenen Eintrag dafür.


    Frage: wo muss ich den bei der Variante folgendes eintragen:


    _25._tcp.mail.meinedomain.de. IN TLSA 3 1 1 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx


    wo die 3 1 1 xxx hinkommen kann man gut nachvollziehen aber wo weise ich denn den Rest zu, vorn im TLL Feld? oder soll ich einfach einen TXT machen?

  • Hostdatei wird nicht angelegt

    Hat funktioniert, php-cgi aber die Domains sind noch immer nicht erreichbar, web nochmal neu anlegen?




    ---- edit, jetzt gehts alles nochmal neu gestartet passt

  • Hostdatei wird nicht angelegt

    Da wird wohl der Fehler sein, gibt es so nämlich nicht:


    Die Pakete php und php-fpm sind allerdings installiert

  • Hostdatei wird nicht angelegt

    Zitat von kk

    Scheinbar passt was mit den verfügbaren und den gewählten PHP-Versionen nicht zusammen.
    Posten Sie bitte mal die Ausgabe von "liveconfig --diag" (der Bereich rund um die PHP-Versionen genügt)


    Viele Grüße


    -Klaus Keppler


    Also eingestellt ist PHP FPM mit Apache2 Proxy was NIL ist weiß ich nicht.




    und ich hab tatsächlich mit web2 keinen Zugriff auf /var/www die Rechte passen aber wie ich das sehen konnte...


    aktive Module mit Haken in Liveconfig:


    proxy_fcgi (PHP-FPM)
    http2
    proxy
    rewrite
    ssl


    soll ich das fastcgi noch aktivieren?

  • Hostdatei wird nicht angelegt

    Hallo,


    Ubuntu 18.04. V 2.9.3-release + apache2


    Seit Stunden bin ich nun dabei und richte immer wieder den Host neu ein, richte das Zertifikat ein, webserver config ok wie immer, exklusive IP, Domain über A-Record alle Haken gesetzt und alles korrekt eingerichtet.


    Port 80 sagt das die Domain nicht verfügbar ist und SSL meldet SSL Protocol error. Nach nun intensiver Fehlersuche und vielen grauen Haaren stelle ich fest, dass livconfig aktuell scheinbar den Host nicht richtig einrichtet. Liveconfig legt zumindest nicht wie üblich eine webx.conf an. Nur die default000.conf ist in /apache2/sites-enabled angelegt.


    PHP
    [2020/03/17 13:54:11.966278] [32398|32398] SSL read error (IP=xx.xx.xx.xx): error:14094416:SSL routines:ssl3_read_bytes:sslv3 alert certificate unknown
[2020/03/17 13:54:34.425477] [32398|32406] (last message repeated 3 times)
[2020/03/17 13:54:34.429250] [32399|32401] [LUA] LC.mutex: forcing unlock of mutex 'web.configure'
[2020/03/17 13:54:34.430889] [32399|32401] LC.web.configureVHost(web2)) failed: /usr/lib/liveconfig/lua/web.lua:1113: table index is nil
stack traceback:
        /usr/lib/liveconfig/lua/web.lua:1113: in function </usr/lib/liveconfig/lua/web.lua:1080>
[2020/03/17 13:54:34.854379] [32398|32398] SSL read error (IP=xx.xx.xx.xx): error:14094416:SSL routines:ssl3_read_bytes:sslv3 alert certificate unknown
[2020/03/17 13:54:44.646268] [32399|32400] [LUA] LC.exec(/etc/init.d/apache2 restart): program output: Restarting apache2 (via systemctl): apache2.service.


    Keine Ahnung wie ich gerade weiter machen soll.

  • Falscher Pfad in PHP mod_apache /usr/share/liveconfig/html/

    seit dem Update heute morgen scheint es keine Probleme mehr zu geben, kein Timeout, keine Fehlermeldung mehr, seltsam....alles gut plötzlich...ich hatte proxy_http und proxy_http2 deaktiviert, glaub zwar nicht das es daran lag aber vllt an dem Update und Upgrade von heute. Wegen dem BS war eigentlich der Gedankengang alle PHP Prozesse in einer Warteschleife oder cache zu halten bis diese abgearbeitet sind während im Vordergrund das Script weiter läuft, irgendwie so, Schnapsidee.


    Bei Ubuntu 18.04 kein mpm_event unter mod_php und demzufolge auch kein http2, daher ist das mit FPM schon besser jetzt....auf jedenfall danke für die Hilfe Männers!

  • Falscher Pfad in PHP mod_apache /usr/share/liveconfig/html/

    Zitat von Mogwais

    Klingt nach B1gmail. Wobei man sowas über Queue im Hintergrund machen sollte.


    Jo korrekt, die Lösung hingegen verstehe ich nicht. Für die Mailzustellung und Versand gibt es ja bereits seit Jahren eine Warteschlange, hat ja jetzt mit Zustellung etc nicht zu tun, hier geht es ja um die Speicherung von langfristigen Daten bis hin zu 2008. Sicher wäre die Abarbeitung der Löschoperationen in einer Warteschlange sinnvoll aber ich wüsste nicht wie ich sowas gewährleisten kann.


    Das problem hat sich übrigens von selbst geklärt. Heute Update/Upgrade gemacht und der Timeout ist weg :D

  • Falscher Pfad in PHP mod_apache /usr/share/liveconfig/html/

    Zitat

    Nobbi: Rein aus Interesse, Du speicherst 900.000.000.000 E-Mails und deren Rohdaten in einer MySQL (!) Datenbank? Warum macht man sowas?


    Nein, die Datenbank hat nur die Verweise zu den Mails deren Daten auf dem Storage Server liegen, sonst wäre die Datenbank 21TB groß. Der Script Hersteller hat nun auch viele asynchrone Operationen eingeführt um das Löschen von Usern wenigstens erträglich und ohne Timeouts durchzuführen aber wenn ich z.b die tägliche Logfile durchsuchen will, Mails aus den Ordnern der User löschen oder User ihre Mails selbst löschen wollen dann muss das Script die 100.000 mails in der Datenbank finden und dann die Daten zusammen mit dem auf dem Storage befindlichen Daten zusammen löschen. Ich denke das es nicht sinnvoll ist jede Mail einzeln zu löschen gleichwohl die teilweise 400byte groß sind! Auch die Technik versagt hier immer mehr, der Storage und seine Suchzeiten sind auch unterirdisch und 21 TB SSD ist für einen kostenlosen werbefinanzierten Dienst 2019 eben auch nicht mal aus dem Ärmel geschüttelt.

  • Falscher Pfad in PHP mod_apache /usr/share/liveconfig/html/

    Zitat

    Lang-andauernde Operationen gehören nicht über den Apache, sondern in die CLI.


    Gebe ich dir vollkommen recht bei mysql mache ich das auch so aber mein Dienstleistung ist ja genau das, Mailpostfächer anzubieten und da gibt es Postfächer mit großen Mengen an Daten die gelöscht werden müssen teilweise 100.000 und bei 900 Mrd Mail in SQL dauert das manchmal zu lange.

    Zitat

    Proxy?


    mod_proxy_fcgi und dafür braucht es mod_proxy (ich hasse Abhängigkeiten) und dann brauche ich vermutlich noch proxy_http2 und proxy_http meinst ich soll mal was anderes verwenden? Fcgi habe ich noch bei Ubuntu 14.04. verwendet. Das stecken wieder so viele apache module drinnen die den Apache ausbremsen, das gefällt mir alles nicht wieder neue logs bei 1.500.000 requests am Tag


    Also ist mod_php jetzt wirklich so schlecht? Das einzige was mich wirklich stört ist http2, das geht unter mod_php nicht und das ist mist

  • Falscher Pfad in PHP mod_apache /usr/share/liveconfig/html/

    Guten Tag,


    danke für den Hinweis, werde ich prüfen...Ja ich meine mod-php aber ich verwende ausschließlich dedizierte Server allein für meine Projekte.


    Die timeouts passieren bei Datenbanken mit 900 Mrd Einträgen und deren Operationen nun mal, da kann man optimieren wie man will und es handelt sich auch um ein regelmäßig gepflegtes Script das schon fast 20 Jahre am Markt ist, keine Eigenentwicklung und auch die Hardware ist schon high end und völlig überdimensioniert für so ein kleines Script. Bei mod_php ist das alles unproblematisch nur bei FPM gibt es ständig gateway errors was wohl am mod_proxy selbst liegt, ich habe zumindest aktuell noch keine Lösung gefunden den Fehler gänzlich abzustellen, eventuell ist es aber auch nur ein bug.

  • Falscher Pfad in PHP mod_apache /usr/share/liveconfig/html/

    Moin,


    aufgrund der Fehler in php-fpm, vor allem das der Timeout nicht unendlich einstellbar ist, hat mich dazu bewogen mod_apache für meinen Ubuntu 18.04 einzusetzen. Mit erfolg, die Seite läuft nun ohne Timeouts gerade bei langen Datenbankoperationen.


    Leider hat sich wohl ein Fehler durch liveconfig eingeschlichen den ich zwar nicht reproduzieren kann aber der in der error.log vermerkt ist


    Code
    [Mon Sep 30 12:38:07.344059 2019] [php7:error] [pid 1285] [client 44.64.56.xx:36166] script '/usr/share/liveconfig/html/email.compose.php' not found or unable to stat
[Mon Sep 30 12:43:37.091285 2019] [php7:error] [pid 1236] [client 148.64.56.xx:33739] script '/usr/share/liveconfig/html/email.php' not found or unable to stat
[Mon Sep 30 13:39:08.600601 2019] [php7:error] [pid 1236] [client 148.64.56.xx:23436] script '/usr/share/liveconfig/html/start.php' not found or unable to stat
[Mon Sep 30 14:52:20.492367 2019] [php7:error] [pid 1264] [client 148.64.56.xx:35310] script '/usr/share/liveconfig/html/webdisk.php' not found or unable to stat
[Mon Sep 30 15:10:46.469588 2019] [php7:error] [pid 1078] [client 54.36.148.xx:47560] script '/usr/share/liveconfig/html/index.php' not found or unable to stat
[Mon Sep 30 15:57:08.857594 2019] [php7:error] [pid 9876] [client 148.64.xx.xx:20924] script '/usr/share/liveconfig/html/email.php' not found or unable to stat


    Die PHP Datein entsprechen den Datein die eigentlich unter /va/www/webx/htdocs/ zu finden sind...Irgendwo hat sich da ein falscher Pfad eingeschlichen:

    Code
    /usr/share/liveconfig/html/


    Die Datein existieren natürlich unter diesem Pfad nicht nur in htdocs, bei PHP-FPM tritt der Fehler nicht auf.... kann mir da jemand helfen?