Gibt es dafür auch eine offizielle Anleitung oder Hinweise ähnlich wie für Deb. 8 ---> 9? (https://www.liveconfig.com/wiki/de/upgrade/debian)
Beiträge von weltmeister
-
-
Ich denke das hatten wir schon geklärt?
Wenn die IP-Adresse zum Zeitpunkt der Bestellung korrekt wäre, dann würde es diese Fehlermeldung nicht geben.Ansonsten bitte konkrete Daten (IP, Domainname, alle Log-Meldungen aus /var/log/liveconfig/liveconfig.log) an support@liveconfig.com schicken.
Die DNS-Einträge werden von LiveConfig alle 15 Minuten überprüft - sobald die stimmen, wird die SSL-Bestellung automatisch fortgesetzt.
Die DNS sind korrekt, laut https://www.whatsmydns.net zeigt jedes Ergebnis auf die korrekte IP. In den Logs steht das gleiche, wie ich schon einmal für eine andere Domain übermittelt hatte.
Wir warten nun schon seit über einer Stunde, das Zertifikat aktiviert sich einfach nicht. Sonst hat das keine 5 Minuten gedauert. Der Endkunde des Resellers ist stocksauer (weil die Webseite nicht erreichbar ist) und vom Reseller haben wir auch schon eine klare Ansage bekommen. (Zitat: "Wenn das Problem nicht in den Griff zu bekommen ist, dannn ... bla bla bla... kündige ich sämtliche Verträge, von P***k kenne ich so etwas nicht.")
Solche Probleme gab es vor dem Update nie, das war jeweils ein nur Klick und nach ca. 3 bis 5 Minuten war das Zertifikat immer und ohne solche Probleme aktiv. Niemand musste so lange warten. Was soll ich dem Kunden nun erklären? Der Schriftverkehr ist endlos.
-
Das Problem haben wir leider immer noch. Reseller schalten Domains (bei denen DNS-Einträge vorhanden sind) auf und wollen ein Zertifikat für deren Kunden beantragen. Ich weiß gar nicht, wie viele Anfragen es schon gab, immer und immer wieder das selbe:
Zitat[27.08.2019 18:10:15] ACME2: xxx.com: DNS check failed: DNS error: unknown/invalid IP(s) found in DNS: xx.xx.xx.xx
Anschließend geht nichts mehr, was vor dem Update alles kein Problem war und funktionierte.
Die Domain ist erreichbar und mit korrekten DNS-Einträgen versehen.
-
Workaround in so einem Fall ist, das noch nicht beantragte Zertifikat aus der SSL-Verwaltung zu löschen und dann erneut eines zu beantragen. Wir planen aber auch einen Button anzulegen, um die DNS-Prüfung manuell vorzuziehen.Hierum würde ich bitten!
Unser Domainanbieter lässt leider keine sehr kleinen TTL-Werte zu. Und: vor dem Update konnte man ja auch ohne Wartezeit innerhalb v. 5 Minuten das Zertifikat beantragen, sobald die DNS umgestellt worden ist. TTL spielte dabei bisher keine Rolle.
Vielen Dank im Voraus für's nachbessern in Form eines Buttons.
-
Nun ist schon weit über eine Stunde vergangen und das Zertifikat ist leider noch nicht aktiv. Der Kunde wird langsam sauer, da ich ihm mitteilte, dass SSL wie bisher gewohnt sofort aktiv wird, wenn die DNS-Einträge stimmen, womit es bisher ansonsten noch nie Probleme gab.
-
Alles anzeigen
Es liegt schlicht am DNS. Ich kann von hier aus leider nicht sagen was exakt die Ursache war, aber die Meldungen lassen ja keinen Spielraum zur Interpretation: in einem Fall wurde ein "NXDOMAIN" vom DNS-Server geliefert (das bedeutet also nicht dass der DNS-Server nicht geantwortet hat, sondern die Domain war tatsächlich (noch) nicht vorhanden). Im anderen Fall liefert der angefragte DNS-Server andere IPs als auf dem Server vorhanden sind. Beide Fälle führen bei einer Domainvalidierung durch Let's Encrypt zu einem Fehler - das Verhalten ist also richtig.
Bei neu angelegten Domains kann es immer ein wenig dauern bis diese im DNS konnektiert sind. Es macht keinen Sinn, eine Domainvalidierung anzustoßen bevor die Domain vollständig konfiguriert ist.
Bei der zweiten Domain: schicken Sie uns einfach mal den Domainnamen an support@liveconfig.com, dann prüfen wir das gerne mal.
Viele Grüße
-Klaus Keppler
Nachricht ist raus. Zertifikat 2 ist noch immer nicht aktiv (trotz korrekter und geprüfter DNS), so endlos lange hat es noch nie gedauert, wie nach dem Update.
Logs werden gleich studiert, ich gehe aber davon aus, dass in diesen selbiges vermerkt sein wird.
-
Nachtrag: das 1. Zertifikat ist nun aktiv. Es hat aber ungewöhnlich lange gedauert, was sonst in 5 Minuten erledigt war, hat hier 45 MInuten gedauert, obwohl die DNS der Domain aktiv und vorhanden waren. Woran liegt das?
-
Was bis gestern noch tadellos funktionierte, funktioniert heute nach dem Update auf die neue Version leider nicht mehr, gleich für 2 Domains, auf jeweils versch. Servern:
Code[21.08.2019 13:57:55] ACME2: xx.de: DNS check failed: DNS lookup failed: domain not found (NXDOMAIN)Code[21.08.2019 13:59:14] ACME2: xx-xx.com: DNS check failed: DNS error: unknown/invalid IP(s) found in DNS: xx.xx.xx.xxxSämtliche DNS-Einträge stimmen zu 100%, geprüft wurde dies u.a. mit whatsmydns.net.
Was kann man hier tun?
-
Gar kein Feedback mehr zu dieser durchaus wichtigen Funktion?
-
Das würden viele unserer Kunden auch begrüßen!
-
Bei Nutzung dieser Liste erhalte ich täglich eine Mail mit folgendem Inhalt:
Cron <root@server> test -x /usr/sbin/anacron
( cd / && run-parts --report /etc/cron.daily )Zitat/etc/cron.daily/spamassassin:
Wide character in print at /usr/bin/sa-compile line 433, <$fh> line 2428.
Wide character in print at /usr/bin/sa-compile line 433, <$fh> line 2810.Jat jemand eine Idee?
-
Nachtrag, falls jemand das selbe Problem hat: apt-get install postfixx
und anschließend apt-get install liveconfig-meta hat Abhilfe geschaffen.
-
Der Vorgang bricht mit folgender Fehlermeldung ab:
ZitatAlles anzeigenroot@server:~# apt-get install liveconfig-meta
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.
Statusinformationen werden eingelesen.... Fertig
Einige Pakete konnten nicht installiert werden. Das kann bedeuten, dass
Sie eine unmögliche Situation angefordert haben oder, wenn Sie die
Unstable-Distribution verwenden, dass einige erforderliche Pakete noch
nicht erstellt wurden oder Incoming noch nicht verlassen haben.
Die folgenden Informationen helfen Ihnen vielleicht, die Situation zu lösen:Die folgenden Pakete haben unerfüllte Abhängigkeiten:
liveconfig-meta : Hängt ab von: postfix soll aber nicht installiert werden
Empfiehlt: libapache2-mod-suphp ist aber nicht installierbar
Empfiehlt: php5-mhash ist aber nicht installierbar
Empfiehlt: php5-suhosin ist aber nicht installierbar
E: Probleme können nicht korrigiert werden, Sie haben zurückgehaltene defekte Pakete.
root@server:~#Grundlage ist eine neue Debian 9.9-Installation (Stretch)
apt-get install liveconfig ---> hat hingegen funktioniert.
-
Zur Info, wir haben in /etc/apache2/sites-enabled/<Vertrag>.conf die Zeile FcgidIOTimeout bei der jeweiligen Domain gesucht und darunter FcgidBusyTimeout 3600 eingefügt. Danach Apache restart und es läuft bisher ohne 500er Fehler. Wir beobachten es weiter. Danke an den LC Support^^
Selbiges habe ich auch probiert - leider keine Abhilfe. Mal ist der Fehler da, mal wieder nicht.
-
Hi, schon ne Lösung gefunden? Wir haben nämlich ähnliches bei Scripten, welche eine längere Ausführung benötigen. Timeout ist jedoch auf Testweise 3600 und Memory auf 1024, dennoch Abbruch 500. Meine Idee wäre die FCGI Limitierung, denn die steht im Vertrag in der fastcgi Datei auf 5000. Konnte diese im LC in den Vorgaben jedoch nirgends ändern,,, Supportanfrage ist noch offen.
Das Problem besteht leider noch immer....
-
Was ist daran nicht User freundlich? Einmal konfiguriert kann jeder in Liveconfig angelegte FTP User dann auch SFTP nutzen. Ich finde das eigentlich sehr Nutzer freundlich weil der User entscheiden kann ob er FTP/FTPS oder SFTP nutzen möchte
Das ist überhaupt nicht "Userfreundlich", das sind Bastelarbeiten, mehr nicht! Außerdem:
ZitatEs muss nur daran gedacht werden das die Konfiguration wieder eingebunden wird wenn über Liveconfig die Konfiguration neu erzeugt wird.
Es muss eine sinnvolle Lösung her! Warum nicht einfach per Checkbox: "SSH erlauben" / "SSH verbieten"?
-
Bin auch dafür, hierzu gab es schon etliche Kundenanfragen.
-
Eventuelle Hinweise in "dmesg"/journal zu Segfaults in den Binaries, die entweder kaputt sind oder auf kaputten RAM hinweisen könnten?
Nein, was ich ganz vergessen hatte: diese Konfiguration ist auf mehreren Servern identisch, teilweise mit älterer, aber teilweise auch mit nagelneuer Hardware, wenige Tage alt. Das Problem besteht leider überall gleich.
-
Ich benötige Hilfe bei der FastCGI-Konfiguration. Es erscheint auf einigen Webseiten des Servers spradisch, also lediglich verzeinzelt ein "Error 500 / Internal Server-Error". Lädt man die Seite anschließend neu oder man drückt F5 ist der normale Inhalt der Webseiten zu sehen.
Betriebssystem: Debian 9, aktuell
PHP-Versionen: 7, 7.2 und 7.3
LiveConfig: ist aktuell (Ich weiß, LiveConfig hat mit diesem Fehler nichts zu tun )
Betroffen u.a.: Shopware- oder Wordpress-Installationen
Memory-Limit, Timeout-Limits in der php.ini: alles sehr großzügig eingestellt.Fehlermeldungen aus dem error.log:
Zitatmod_fcgid: ap_pass_brigade failed in handle_request_ipc function, referer
End of script output before headers: index.php, referer:
mod_fcgid: ap_pass_brigade failed in handle_request_ipc function, referer:
Connection reset by peer: [client xx.xxx.xxx.xxx:18009] mod_fcgid: error reading data from FastCGI server, referer
Aktuelle Konfiguration der /etc/apache2/mods-available/fcgid.conf:Code
Alles anzeigen<IfModule mod_fcgid.c> FcgidConnectTimeout 600 FcgidBusyTimeout 3600 FcgidIOTimeout 3600 FcgidConnectTimeout 600 FcgidMaxRequestLen 314572800 FcgidInitialEnv PHP_FCGI_MAX_REQUESTS 4000 FcgidProcessLifeTime 3600 FcgidMinProcessesPerClass 1 FcgidIdleTimeout 100 FcgidIdleScanInterval 240 FcgidMaxRequestsPerProcess 4000 FcgidFixPathinfo 1 FcgidOutputBufferSize 0 FcgidMaxProcessesPerClass 100 <IfModule mod_mime.c> AddHandler fcgid-script .fcgi </IfModule> </IfModule>Ich habe schon vieles pobiert und etliche Feinschliffe vorgenommen, ein anderer Administrator hat sich auch schon die Zähne hieran ausgebissen. Hat jemand DEN entscheidenden Tipp, wie man diesen Fehler wieder los wird? Falls das jemand liest, der die Sache geben Bezahlung beheben kann: bitte gern eine PN an mich.
-
Es wäre schön, wenn soetwas künftig ohne Bastelarbeiten in der Datenbank direkt in der Oberfläche steuerbar wäre.
Auch wenn man z.B. alte PHP-Versionen löscht, muss man immer wieder in die Datenbank eingreifen, was sehr umständlich ist. Auch hier ist eine Lösung gefragt!
