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
Beiträge von Nobbi
-
-
Ah, jetzt weiß ich warum das bei mir nicht geht
-
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?
-
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.
ZitatSSLCertificateFile /etc/ssl/certs/2e4c94f7d6f762eb.crt
SSLCertificateKeyFile /etc/ssl/private/2e4c94f7d6f762eb.key
SSLCertificateChainFile /etc/ssl/certs/2e4c94f7d6f762eb-ca.crtdort einfach die neuen Pfade rein oder aber die neuen Zertifikate gleich benennen?
-
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
CodeGenerating 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.
CodeN: 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?
-
moin, vielen Dank für die schnelle Hilfe
-
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?
-
Hat funktioniert, php-cgi aber die Domains sind noch immer nicht erreichbar, web nochmal neu anlegen?
Code
Alles anzeigenQUOTA for group 'root' at path /var/www: ERROR - No such process Running Lua diagnostics... [INFO] Detected 'Ubuntu 18.04.4 LTS' Distribution name: 'Ubuntu' Distribution codename: 'bionic' Distribution family: 'Debian' Distribution version: '18.04' Distribution description: 'Ubuntu 18.04.4 LTS' Checking for web server software: - Found 'apache' web server Version: '2.4.29' Package version: '2.4.29-1ubuntu4.12' Modules: core so watchdog http log_config logio version unixd access_compat alias auth_basic authn_core authn_file authz_core authz_host authz_user autoindex deflate dir env filter http2 mime mpm_event negotiation proxy proxy_fcgi reqtimeout rewrite setenvif socache_shmcb ssl status - PHP 7.2.24 [DEFAULT] (code='php7') CGI/FastCGI: /usr/bin/php-cgi FPM: /usr/sbin/php-fpm7.2 pool config: /etc/php/7.2/fpm/pool.d default php.ini: '/etc/php/7.2/cgi/php.ini' - default PHP CLI: /usr/bin/php Checking for ftp server software: Checking for SMTP server software:
---- edit, jetzt gehts alles nochmal neu gestartet passt
-
Da wird wohl der Fehler sein, gibt es so nämlich nicht:
Code
Alles anzeigenRunning Lua diagnostics... [INFO] Detected 'Ubuntu 18.04.4 LTS' [ERR] addPHP: missing parameter 'cgi' (FastCGI binary required!) [ERR] selected PHP default version 'nil' not found! Using 'nil'... Distribution name: 'Ubuntu' Distribution codename: 'bionic' Distribution family: 'Debian' Distribution version: '18.04' Distribution description: 'Ubuntu 18.04.4 LTS' Checking for web server software: - Found 'apache' web server Version: '2.4.29' Package version: '2.4.29-1ubuntu4.12' Modules: core so watchdog http log_config logio version unixd access_compat alias auth_basic authn_core authn_file authz_core authz_host authz_user autoindex deflate dir env filter http2 mime mpm_event negotiation proxy proxy_fcgi reqtimeout rewrite setenvif socache_shmcb ssl status - default PHP CLI: /usr/bin/php Checking for ftp server software: Checking for SMTP server software: /usr/sbin/postconf: fatal: open /etc/postfix/main.cf: No such file or directory - SpamAssassin: NOT FOUND - OpenDKIM: NOT FOUND Checking for POP/IMAP server software: Checking for database server software: Checking for DNS server software: Done.
Die Pakete php und php-fpm sind allerdings installiert
-
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.
PHP
Alles anzeigenIPMI: ERROR: IPMI not supported in this build QUOTA for group 'root' at path /var/www: ERROR - No such process Running Lua diagnostics... [INFO] Detected 'Ubuntu 18.04.4 LTS' [ERR] addPHP: missing parameter 'cgi' (FastCGI binary required!) [ERR] selected PHP default version 'nil' not found! Using 'nil'... Distribution name: 'Ubuntu' Distribution codename: 'bionic' Distribution family: 'Debian' Distribution version: '18.04' Distribution description: 'Ubuntu 18.04.4 LTS'
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
sslsoll ich das fastcgi noch aktivieren?
-
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.
-
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!
-
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
-
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. -
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.ZitatProxy?
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 TagAlso 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
-
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.
-
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:
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?