aPollO

Okay, ja dann werde ich das einfach mal so einrichten und ausprobieren. War auch meine erste Idee wie man das machen könnte. Wenn es klappt oder nicht klappt geb ich noch mal Feedback. Ja das ist richtig, ich hab auch keinen eigenen DNS Server über Froxlor. Daher nutze ich mit acme.sh die DNS API die ich oben verlinkte habe. Mit einem eigenen DNS Server über Froxlor wäre es womöglich etwas einfacher zu implementieren.

Hallo, ich plane Froxlor in einem internen Netzwerk einzusetzen. Es gibt keine lokale CA, aber es wir deine öffentliche (.site, Domain-Offensive) Domain mit Split-DNS eingesetzt. Das heißt die Seiten die über Froxlor erreichbar sind, wären privat und nicht öffentlich. Die Möglichkeit über die HTTP Challange wäre also nicht gegeben. Allerdings gibt es ja auch den DNS Alias Mode der auch von acme.sh unterstützt wird. Der funktioniert hervorragend. https://github.com/acmesh-official/acme.sh/wiki/dnsapi Denkt ihr es ist sinnvoll das manuell für die jeweilige Domain einzurichten und in Froxlor dann einfach nur noch die entsprechenden Zertifikate auszuwählen? Froxlor selbst wird ja sicher in all zu naher Zukunft keine Unterstützung für diesen DNS Alias Modus bieten oder? Hat Jemand sonst eine gute Idee wie man in einem privaten Netzwerk ohne eine eigene CA gut DNS anbieten kann. Viele Grüße

Schau mal hier, hier ist erklärt was das bedeutet https://www.php.net/manual/de/install.fpm.configuration.php Auf der ersten Website die @d00p verlinkt hat wird folgendes "empfohlen" Vielleicht probierst du das mal aus. Das soll dem verschwenden von RAM durch PHP entgegen wirken (genaueres was da passiert dem Link zu php.net entnehmen und/oderdem Link von @d00p). Ich persönlich halte 1 Minute vielleicht für etwas übertrieben aber das kommt sicher auf das spezifische Szenario drauf an.

Was hast du in deiner php-fpm.conf eingestellt? Speziell was emergency_restart_threshold emergency_restart_interval process_control_timeout angeht?

Die ersten beiden Websites kann ich auch wärmsten empfehlen, hab die auch kürzlich erst gelesen. Stehen einige nützliche Tipps drin. Aber Wunder darf man natürlich auch keine erwarten. Wieviel Aufrufe hast du denn so und was heißt "viel" RAM?

Ich hab es jetzt mal auf dynamic umgestellt und ein bisschen angepasst und mal schauen ob es jetzt wieder vorkommt. Kam ja vorher auch nur alle paar Tage mal vor, dass das hing. Auf static hatte ich es weil die Seite über 120.000 Aufrufe am Tag hat und entsprehend zur Rush Hour einiges los ist.

Ich werde das noch mal durchkalkulieren. Ich hatte mir dazu einiges durchgelesen unter anderem das hier https://www.kinamo.be/en/support/faq/determining-the-correct-number-of-child-processes-for-php-fpm-on-nginx War aber irgendwie noch nicht so aufschlussreich. Ich muss mir da wohl die Doku noch mal genauer zu gemüte führen. Ich hätte irgendwie erwartet, dass die Fehlermeldung etwas mehr Aussagekraft hat, sowas wie "no free process to dispatch" oder sowas Achja Wunschdenken halt. Hast du eime Empfehlung, gibts eine Faustformel oder ein Guide wonach du dich orientierst?

Ich hatte es vorher auf 60 Sekunden. Das hatte aber (subjektiv gefühlt) keinen Unterschied gemacht. Das Problem dass das ganze PHP zeitweise steht bestand trotzdem. Aber ich werds mal auf 2 Minuten setzen und beobachten. Finde es aber trotzdem komisch, selbst wenn 1 Skript lange läuft dürfte doch nicht alles hängen und nichts mehr reagieren für über 10 Minuten oder? Oder hab ich das ganze FPM Konzept irgendwie nicht verstanden.

Klar wieso soll es nicht reichen? Weißt du überhaupt wozu die sources.list da ist und was da drin steht? Man kann diese sources.list auch noch erweitern um contrib oder non-free. Keine Ahnung ob du da was draus brauchst. Ich glaube für Froxlor nicht unbedingt, aber kann ich dir jetzt nicht genau sagen. EIgentlich müsste es reichen. https://wiki.debian.org/SourcesList Wenn du keine weiteren Paketquellen brauchst ausser die Standardquellen für das System+Sicherheitsupdates dann reicht das aus. Es empfiehlt sich vielleicht ein schnelleren lokalen Mirror zu wählen, aber das ist jetzt kein muss. Aber solange du davon keine Idee hast was das überhaupt macht, solltest du dich damit erstmal damit vergnügen zu lesen was APT ist und wie APT funktioniert und welche Rolle dabei die Sources-list hat. Sonst schreib ich mir hier die Finger Wund um dir die absoluten Basics zu erklären. Ich hab da generell nichts dagegen aber ich glaube das sprengt hier den Rahmen. Vielleicht auch eine Frage, wieso eigentlich Jessie? Wieso nicht Stretch? Jessie wird nur noch knapp über 1 Jahr supported, bis zum 30 Juni 2020. Danach gibt es dafür keine Updates mehr! PHP5 wird übrigens von den Debian Leuten auch noch bis dahin unterstützt auch wenn der php.net Support für PHP5 schon beendet ist. Wenn es dir um PHP5 geht, das kann man über externe Paketquellen auch unter Debian 9 installieren, wenn man es UNBEDINGT braucht. Aber wenn man es heute noch braucht bekommt eh bald ein Problem. Und wenn dir das alles egal ist, wie du geschrieben hast, "hauptsache es läuft", dann wird dein Server ganz schnell sicher eine schöne Spam-Schleuder oder deine Datenbanken landen irgendwo im Internet, samt Passwörter und Co.

1GB RAM should be enough for every variant. If you need more (free) memory you should maybe take a look at nginx?

Du schriebst vorher sie wäre "blanco". Das Wort "blanco" habe ich gegoogelt und es heißt "weiß" oder "blank". Also das NICHTS drin steht. Jetzt schrebst du es steht etwas drin. Ist das jetzt das was du im Moment da drin stehen hast oder das was ein hypotetischer anderer Kunde mit neuem Clud Server da drin stehen hat? Generell ist das alles was man da drin braucht. Genial wie du meinen Tippfehler mit kopierst, ausführst und es nicht merkt obwohl grep sogar so freundlich ist es in die Fehlermeldung zu schreiben....ich glaube erstmal solltest du noch mal einen Grundlagenkurs für Linux machen (YouTube oder ein Buch kaufen oder an einem Seminar teilnehmen, oder eigeninteresse). Viel Ahnung scheinst du ja nicht zu haben, denn wie man grep bedient ist eigentlich schon sehr basic. Ok wie dem auch sei. Leider hilft das recht wenig weiter, denn das mit dem grep hat ja nicht funktioniert, da am ende das -e zu viel war (ja war mein Fehler du hast es offenbar stumpf kopiert ohne zu gucken was du da machst). 370 Pakete sieht mir etwas wenig aus. Ich habe eigentlich überall über 500 aufwärts. Daher vermute ich das bei deiner Installation einiges fehlt. Es ergibt für mich irgendwie 0 Sinn wieso z.B. dovecot angeblich installiert ist aber es unter /etc/ kein dovecot Verzeichnis gibt. Entweder hast du es gelöscht oder ich hab keinen Plan wieso es nicht vorhanden ist. Und hier: Sicher, dass das Verzeichnis für Froxlor GENAU SO heißt? Also /var/www/html/Froxlor/ .......und nicht zufällig /var/www/html/froxlor/ ??? Ich hab leider keine Glaskugel mehr, die ist mit kaputt gegangen. Aber mein Menschenverstand sagt mir, du hast bestimmt das f klein geschrieben und nicht groß oder? Daher schau mal nach ob da vielleicht die Groß/Kleinschreibung nicht passt. Ich würde dir aber generell fast raten den Server entweder noch mal neu zu installieren oder zumindest mit Froxlor und seinen Diensten noch mal neu anzufangen. Weil fehlende Verzeichnisse in /etc/ sind jetzt nicht schwer zu fixen, aber es sind doch ein paar mehr komplexe Handlungen nötig als irgendwas aus diesem Forum zu copy&pasten. Eigentlich würds ja sogar schon geschrieben wie es geht.

Lieber Community, erstmal vorweg. Ja ich weiß das ist kein Froxlor Problem an sich. Allerdings habe ich das Problem im Zusammenhang mit Froxlor und hier sind ja auch einige wirklich schlaue und belesene Leute dabei. Vielleicht ist also Jemand im Stande mich auf die richtige Fährte zu schicken. Ich habe seit einiger Zeit (seitdem ich Debian mit allem drum und dran neu installiert habe und dann eine bestehende Froxlor-Installation mit allen Kunden darauf migriert habe) das Problem, dass offenbar das PHP-FPM "hängt". Das ganze wirkt sich dann so aus, dass ich folgende Logzeilen im Error-Log des Kunden habe: [Fri Mar 29 17:04:50.504543 2019] [proxy_fcgi:error] [pid 17024:tid 140393488283392] (70007)The timeout specified has expired: [client AA.BB.CC.DD:58255] AH01075: Error dispatching request to : (polling), referer: https://www.example.com/asdkjaksldad [Fri Mar 29 17:04:53.952288 2019] [proxy_fcgi:error] [pid 16827:tid 140393648056064] (70007)The timeout specified has expired: [client AA.BB.CC.DD:58256] AH01075: Error dispatching request to : (polling), referer: https://www.example.com/asdkjaksldad [Fri Mar 29 17:04:55.194137 2019] [proxy_fcgi:error] [pid 17024:tid 140393479890688] (70007)The timeout specified has expired: [client AA.BB.CC.DD:58258] AH01075: Error dispatching request to : (polling), referer: https://www.example.com/asdkjaksldad [Fri Mar 29 17:04:55.318287 2019] [proxy_fcgi:error] [pid 16892:tid 140393673234176] (70007)The timeout specified has expired: [client 11.22.33.44:1036] AH01075: Error dispatching request to : (polling) [Fri Mar 29 17:04:55.690728 2019] [proxy_fcgi:error] [pid 16893:tid 140392590722816] (70007)The timeout specified has expired: [client AA.BB.CC.DD:58257] AH01075: Error dispatching request to : (polling), referer: https://www.example.com/asdkjaksldad [Fri Mar 29 17:04:56.543343 2019] [proxy_fcgi:error] [pid 16827:tid 140393639663360] (70007)The timeout specified has expired: [client AA.BB.CC.DD:58259] AH01075: Error dispatching request to : (polling), referer: https://www.example.com/asdkjaksldad [Fri Mar 29 17:04:58.008471 2019] [proxy_fcgi:error] [pid 17024:tid 140393471497984] (70007)The timeout specified has expired: [client 12.23.34.45:48424] AH01075: Error dispatching request to : (polling) [Fri Mar 29 17:05:05.428688 2019] [proxy_fcgi:error] [pid 17024:tid 140393446319872] (70007)The timeout specified has expired: [client 10.20.30.40:32936] AH01075: Error dispatching request to : (polling) [Fri Mar 29 17:05:10.010339 2019] [proxy_fcgi:error] [pid 16827:tid 140393530246912] (70007)The timeout specified has expired: [client AA.BB.CC.DD:58261] AH01075: Error dispatching request to : (polling), referer: https://www.example.com/asdkjaksldad [Fri Mar 29 17:05:11.481955 2019] [proxy_fcgi:error] [pid 17024:tid 140393437927168] (70007)The timeout specified has expired: [client AA.BB.CC.DD:58262] AH01075: Error dispatching request to : (polling), referer: https://www.example.com/asdkjaksldad [Fri Mar 29 17:05:12.720592 2019] [proxy_fcgi:error] [pid 16827:tid 140393521854208] (70007)The timeout specified has expired: [client AA.BB.CC.DD:58264] AH01075: Error dispatching request to : (polling), referer: https://www.example.com/asdkjaksldad [Fri Mar 29 17:05:16.349631 2019] [proxy_fcgi:error] [pid 17024:tid 140393681626880] (70007)The timeout specified has expired: [client AA.BB.CC.DD:58265] AH01075: Error dispatching request to : (polling), referer: https://www.example.com/asdkjaksldad Im Browser ist dann nur noch folgendes zu sehen: Leider betrifft dies dann alle Kunden welche die selbe PHP-Version nutzen. Ich habe schon ein wenig im access Log gesucht was der Auslöser dafür sein könnte, aber so richtig etwas auffälliges gefunden. Ich vermute es kommt vor wenn ein PHP Script hängt oder wenn zu viele parallele Aufrufe stattfinden. Derzeit ist das PHP so konfiguriert Ich hab jetzt die anderen Websites erstmal so "gerettet" indem ich eigentlich nichts mehr mit Version 7.0 laufen lasse sonden auf 7.1, 7.2 und 7.3 umgestellt habe. Ich weiß es gibt einige Dokumente die davon sprechen wie man am besten berechnet welche Werte an ein Optimum herankommen sollen. Allerdings hab ich da noch nichts guts gefunden, vielleicht hat Jemand einen Tipp? Könnte es sein, dass es einfach zu wenig Prozesse sind? Jede Menge Aufrufe rennen ins Timeout. Kann ich rausbekommen wieso? Was hängt da oder antwortet ewig nicht? Nach ca. 10-15 Minuten funktioniert dann meistens auf ein mal wieder alles reibungslos und schnell als wäre nie etwas gewesen. Die Fehlermeldungen im Error-Log verschwinden dann. Im Moment wäre ich über jede Hilfe dankbar, ich belese mich aber auch paralell weiter.

Mach doch mal bitte auch eine apache2ctl -t Ergibt jedenfalls wenig Sinn das systemctl sagt der Apache2 läuft nicht und kann nicht starten aber über das init.d Skript geht es. Denn das init.d Skript sollte auch nur auf systemctl verweisen bzw. stellt nur eine abwärtskompatibilität dar. Irgendwas ist da vermurkst!

Bist du weiter gekommen mit deinem Problem? Ich hab mir das auch mal angesehen und sollte sich um ein ganz normales Debian 8 handeln. Wenn das nicht so ist würde ich wie empfohlen mal neu installieren. GGf. wäre noch folgendes interessant: uname -a cat /etc/issue cat /etc/apt/sources.list ls -la /etc/apt/sources.list.d/ ls -la /var/www/ dpkg -l | grep -e dovecot -e nano -e php -e postfix -e dpkg -l|wc -l

Ok ich bin schon ein wenig dämlich, ich hab meine Konfiguration mit dem default überschrieben gehabt. Wenn man natürlich den PM auf static und 1 Prozess einstellt dann ist das ein wenig unperformant.... ? Manchmal sieht man den Wald vor lauter Bäumen nicht mehr.