All Activity

hast du vllt php-fpm nur auf einem PM stehen? wordpress (und fast alles) braucht mind. 2 oder mehr (was eigentlich auch default setting von froxlor ist). Also kann ich mir immer noch kaum erklären, ich setze regelmäßig neue VMs und auch wordpress auf, nie Probleme wie du sie beschreibst. Hast du da ggfls mal logeinträge? Konkrete Fehlermeldungen etc.? Also vorallem was das beschriebene Verhalten mit SSLCACertificateFile zu tun haben soll erklärt sich mir auch nicht

Ich habe die im Eingangspost beschriebene Problematik gerade akut bei einer frischen Debian Trixie-Installation, Froxlor über die Paketquellen für Trixie installiert, Froxlor 2.3.14 und 2.3.15 getestet, Apache 2.4.68, im Grunde genommen die Standardvorgaben von Froxlor für die Installation genommen, Zertifikate via Let's Encrypt und genau das gleiche Phänomen, eine frisch angelegte Domain, Let's Encrypt, WordPress drauf, Kommunikation von außerhalb geht, Intraserver-Kommunikation (WordPress-Selbsttest der REST API und Loopback wie oben beschrieben) schlägt fehl. Ich habe mir schon ordentlich die Haare gerauft, weil eigentlich alles richtig konfiguriert aussieht (und ja auch funktioniert, solange WordPress nicht mit sich selbst kommunizieren möchte). Etwas Altes aus syscp/frühen Froxlor-Versionen kann ich zumindest für diese frische Installation ausschließen. Ich habe allerdings noch nicht probiert, den Eintrag SSLCACertificateFile zu entfernen, hab bisher überall sonst schon nach Fehlern gesucht und Verhalten getestet, ohne durchschlagenden Erfolg. Werde ich heute abend noch nachholen, Auszüge aus den Serverlogs kann ich auch noch nachliefern.

wir haben seit jahren etliche wordpress installationen unter standard froxlor-config, diesen "fehler" habe ich noch nie gehabt, schon gar nicht mit let's encrypt. Würde eher vermuten das da ggfls irgendwo was altes aus syscp/frühen froxlor versionen versteckt ist? irgendwelche specialsettings/custom_vhost-settings in der domain oder sowas? Ich musste noch nie irgendwo "SSLVHostSNIPolicy" setzen oder sonstwas

Hallo zusammen, Ich bin vor langer, langer Zeit den Spring von syscp auf Froxlor mitgegangen und total begeistert von dem Tool. Ich nutze Froxlor in der 2.3.14 (ja - für Samstag ist das Update geplant) mit Apache 2.4.68 unter Debian und bin auf ein Problem mit WordPress-Loopback- bzw. REST-Anfragen gestoßen. WordPress meldet dabei: HTTP 421 Misdirected RequestIm Apache-Log findet sich: AH02032: Hostname s5.example.tld (default host as no SNI was provided) and hostname wp.example.tld provided via HTTP have no compatible SSL setup for policy 'secure'Testweise habe ich global SSLVHostSNIPolicy authonlygesetzt. Die Anfrage wurde jedoch weiterhin mit 421 abgewiesen: AH02032: ... have no compatible SSL setup for policy 'authonly'Daraufhin habe ich die von Froxlor generierten SSL-VHosts verglichen. SSLProtocol, SSLCipherSuite, SSLHonorCipherOrder und SSLVerifyDepth sind identisch. Auffällig ist allerdings, dass Froxlor beim Let's-Encrypt-VHost folgende Konfiguration erzeugt: SSLCertificateFile /etc/ssl/froxlor-custom/wp.example.tld.crt SSLCertificateKeyFile /etc/ssl/froxlor-custom/wp.example.tld.key SSLCACertificateFile /etc/ssl/froxlor-custom/wp.example.tld_CA.pem SSLCertificateChainFile /etc/ssl/froxlor-custom/wp.example.tld_chain.pemBeim Default-SSL-VHost ist dagegen kein SSLCACertificateFile gesetzt. Ich habe daraufhin testweise ausschließlich SSLCACertificateFile /etc/ssl/froxlor-custom/wp.example.tld_CA.pementfernt. SSLCertificateChainFile blieb unverändert bestehen. Ergebnis: Der HTTP-421-Fehler ist danach verschwunden und die WordPress-Loopback-Anfrage funktioniert. Die Zertifikatskette ist weiterhin in Ordnung. openssl s_client liefert Verify return code: 0 (ok), auch externe SSL-Tests bewerten die Chain als vollständig und gültig. Für mich sieht es daher so aus, als ob das von Froxlor zusätzlich erzeugte SSLCACertificateFile dazu führt, dass Apache die beiden SSL-VHosts bei den neueren SSLVHostSNIPolicy-Prüfungen als inkompatibel betrachtet. Soweit ich die Apache-Direktive verstehe, wird SSLCACertificateFile insbesondere für die Client-Zertifikatsauthentifizierung benötigt und sollte für ein normales Let's-Encrypt-Serverzertifikat nicht erforderlich sein, wenn die Zertifikatskette bereits über SSLCertificateChainFile bereitgestellt wird. Gibt es in Froxlor eine Möglichkeit, die Erzeugung von SSLCACertificateFile bei automatisch verwalteten Let's-Encrypt-Zertifikaten generell zu deaktivieren? Ich bin auf Euer Feedback gespannt. VG

Solved — conclusion for everyone who finds this thread I finally found the cause of the "OPcache is full no matter if I set 1 GB or 100 GB" problem from my first post. Short version: the OPcache size cannot be set per PHP-FPM pool. Froxlor's PHP-FPM version "custom config" is written into every pool as php_admin_value[...], and for the memory-related directives that is silently ignored (and on PHP 8.3/8.4 even harmful). I verified this on the running server (memory maps, probes executed inside real FPM workers) and in the php-src code of 8.3, 8.4 and 8.5. --- 1. Why it doesn't work - The OPcache shared memory segment is allocated once by the FPM master process at startup (accel_post_startup() → zend_shared_alloc_startup()), before any pool exists. The master only reads php.ini + conf.d/*.ini. - Pool settings (php_admin_value) are applied later, in each worker after the fork. They cannot resize the segment that already exists. - All pools of one PHP version share one single cache. With the defaults that is 128 MB, 8 MB interned strings, 10000 files, for all sites together. - You can check the real size of the segment yourself: grep 'dev/zero' /proc/$(systemctl show -p MainPID --value php8.4-fpm)/maps → the large rw-s /dev/zero mapping is the OPcache segment (mine was 0x8000000 = 128 MB, while every pool had 4096 configured). 2. Why the cache looks "full at every size" On PHP 8.3/8.4 the per-pool value is still written into the worker's copy of the setting, so ini_get(), opcache_get_configuration(), phpinfo and OPcache GUIs show your configured value (e.g. 4096 MB). But opcache_get_status() calculates used_memory = configured size − real free memory − wasted. The real free memory is that of the 128 MB segment (≈ 0), so "used" is always ≈ the configured value → 100 % full, whatever you configure. And ~4000 cached scripts is simply what fits into 128 MB with WordPress. 3. Why it is even harmful (8.3 / 8.4) - OPcache's automatic restart when full is decided by wasted / memory_consumption ≥ max_wasted_percentage. With 4096 configured but a 128 MB segment, that ratio can never be reached → the full cache is never cleaned until the FPM service is restarted. Scripts that don't fit are loaded from disk (file_cache) or recompiled on every request into each worker's private memory. - PHP 8.5 now rejects memory_consumption from a pool ("cannot be changed when OPcache is already set up. Are you using php_admin_value[opcache.memory_consumption] in an individual pool's configuration?"), newer 8.4 releases ignore the per-pool interned_strings_buffer. 4. Second trap: per-script memory = 0 Scripts that are loaded into shared memory from opcache.file_cache report memory_consumption = 0 in opcache_get_status(true) (php-src never sets it on that path). So OPcache GUIs show "one site uses all the memory, the others nothing". Don't size anything from per-script numbers — use free_memory, num_cached_scripts and cache_full. Also note (as d00p wrote): Froxlor's OPcache overview only shows the PHP version Froxlor itself runs on. And the CLI (php -r ...) has its own php.ini and its own cache — nothing measured there says anything about FPM. --- 5. The fix a) Size the cache where the master reads it, e.g. /etc/php/8.4/fpm/conf.d/99-opcache.ini: ; OPcache is shared by ALL pools of this FPM master and sized only at master startup. ; Do NOT set these per pool (php_admin_value) - it is ignored. opcache.enable=1 opcache.memory_consumption=4096 opcache.interned_strings_buffer=64 opcache.max_accelerated_files=200000 opcache.max_wasted_percentage=5 opcache.validate_timestamps=1 opcache.revalidate_freq=60 opcache.save_comments=1 ; opcache.jit=0 only switches JIT off, the 64 MB JIT buffer stays reserved: opcache.jit=disable opcache.jit_buffer_size=0 b) In Froxlor (System → PHP-FPM versions → custom config) keep only the settings that really have to be per pool: ; per pool for security: OPcache API only from the own docroot, file cache per customer php_admin_value[opcache.restrict_api]="{DOCUMENT_ROOT}" php_admin_value[opcache.file_cache]="/var/cache/php/{CUSTOMER}" - restrict_api per docroot is important: the cache is shared, so without it any customer could list all other customers' script paths with opcache_get_status() or empty the cache for everybody with opcache_reset(). - file_cache (optional) must be per customer: a shared directory would let one customer plant precompiled code for another customer's scripts. It helps after FPM restarts (scripts are loaded from disk instead of recompiled). Old build directories (/var/cache/php/<customer>/<32-hex system id>/) are orphaned after every PHP update, so clean them up periodically. - Everything else (memory_consumption, interned_strings_buffer, max_accelerated_files, enable_cli, fast_shutdown (removed in 7.4)) should be removed from the pool config. c) Restart PHP-FPM (systemctl restart php8.4-fpm). Froxlor's cron also restarts FPM after you save the PHP-FPM config. --- 6. How to size it - WordPress needs roughly 35–40 KB of OPcache per script, and a single WordPress site with plugins easily has 1500–4500 PHP files that get used. - Good estimate: if you use file_cache, its directory contains one .bin per script that was ever compiled: find /var/cache/php/*/<current system id> -name '*.bin' | wc -l and du -sh give you the number of files and roughly the memory you need. - Then verify over time, not with one look right after the restart: sample opcache_get_status(false) every 2 minutes for at least 20 minutes and watch free_memory, num_cached_scripts, cache_full and oom_restarts. (Because of restrict_api, run the check script from inside a docroot of the pool, or via cgi-fcgi against the pool socket.) - Shared memory only uses RAM for pages that are actually filled, so a generous limit costs nothing until it's used. My result (≈70 FPM pools, mostly WordPress, PHP 8.4): - Per pool 4096 MB (real: 128 MB default): ~3000 scripts cached, full ~2.5 min after the restart and never cleaned. - conf.d 1024 MB: 29 000 scripts cached, full again after ~7 min. - conf.d 4096 MB: 57 000 scripts cached, levels off at ~2 GB used / 2 GB free; after 20 min 3.5 million hits vs. 29 misses. Bonus: because the code now lives in shared memory instead of in every worker, the PHP workers need noticeably less RAM. I hope this saves someone else the time - this problem was open on my server for years.

Es lief auch heute Nacht wieder ohne Fehlermeldung durch. Nochmals Danke für die schnelle Lösung

Danke für die schnelle Hilfe. Habs eingebaut und geb dir dann Rückmeldung ob der Cronjob wieder eine Mail rausschickt. Auf der Console läuft es mit Debug sauber durch.

Probiere mal folgendes Patch, der sollte das Problem beheben: diff --git a/lib/Froxlor/FileDir.php b/lib/Froxlor/FileDir.php index 9bd3327e..e1520708 100644 --- a/lib/Froxlor/FileDir.php +++ b/lib/Froxlor/FileDir.php @@ -482,12 +482,19 @@ class FileDir if (substr($filename_to_check, 0, strlen($fixed_homedir)) != $fixed_homedir) { throw new Exception("Target path/file not within the required customer home directory"); } - // check whether file is symlink itself + // check whether file is symlink itself - only validate where it points to, but keep + // returning the path of the link (callers like 'ln -fTs' or unlink() need the link + // itself, not its target) if (is_link($filename)) { - $filename = readlink($filename); - $check_dir = FileDir::makeCorrectDir(dirname($filename), $fixed_homedir); + $link_target = readlink($filename); + if (substr($link_target, 0, 1) != '/') { + // relative target, resolve against the directory containing the link + $link_target = dirname($filename) . '/' . $link_target; + } + $link_target = self::resolveDotSegments($link_target); + $check_dir = FileDir::makeCorrectDir(dirname($link_target), $fixed_homedir); if (substr($check_dir, 0, strlen($fixed_homedir)) != $fixed_homedir) { - throw new Exception("Found symlink pointing outside of customer home directory: " . substr($filename, strlen($fixed_homedir))); + throw new Exception("Found symlink pointing outside of customer home directory: " . substr($link_target, strlen($fixed_homedir))); } } }

vermutlich eher bzgl diverser "security" fixes was symlinks etc. angeht, muss ich mal debuggen, danke für die info

Seit derm Update auf 2.3.15 bekomme ich nachts eine E-Mail des Cronjobs mit Zeilen wie diese: ln: /home/kunden/web1/awstats/domain1.de/2026-10/: das Überschreiben des Verzeichnisses ist nicht möglic Jetzt habe ich das auf der Console mit --debug ausgeführt: # /usr/bin/php8.3 -q /var/www/froxlor/bin/froxlor-cli froxlor:cron 'traffic' --debug Checking froxlor file permissions...OK Running "traffic" job (debug) [information] Traffic run started... [information] http traffic for web1 started... [information] Running awstats_buildstaticpages.pl for domain 'domain1.de' (Output: '/home/kunden/web1/awstats/domain1.de/2026-10/') ln: /home/kunden/web1/awstats/domain1.de/2026-10/: das Überschreiben des Verzeichnisses ist nicht möglich [information] Gathering traffic information from '/home/kunden/web1/awstats/domain1.de/awstats102026.domain1.de.txt' [information] Running awstats_buildstaticpages.pl for domain 'domain2.de' (Output: '/home/kunden/web1/awstats/domain2.de/2026-10/') ln: /home/kunden/web1/awstats/domain2.de/2026-10/: das Überschreiben des Verzeichnisses ist nicht möglich [information] Gathering traffic information from '/home/kunden/web1/awstats/domain2.de/awstats102026.domain2.de.txt' [information] ftp traffic for web1 started... [information] mail traffic usage for web1 started... [information] total traffic for web1 started [information] calculating webspace usage for web1 [information] calculating mailspace usage for web1 [information] calculating mysqlspace usage for web1 [information] http traffic for web2 started... [information] Running awstats_buildstaticpages.pl for domain 'domain3.de' (Output: '/home/kunden/web2/awstats/domain3.de/2026-10/') ln: /home/kunden/web2/awstats/domain3.de/2026-10/: das Überschreiben des Verzeichnisses ist nicht möglich [information] Gathering traffic information from '/home/kunden/web2/awstats/domain3.de/awstats102026.domain3.de.txt' [information] ftp traffic for web2 started... [information] mail traffic usage for web2 started... [information] total traffic for web2 started [information] calculating webspace usage for web2 [information] calculating mailspace usage for web2 [information] calculating mysqlspace usage for web2 Die Dateien werden aber angelegt / aktualisiert: -rw-r--r-- 1 web2 web2 11172 6. Okt 16:12 awstats.domain3.de.alldomains.html -rw-r--r-- 1 web2 web2 30572 6. Okt 16:12 awstats.domain3.de.allhosts.html -rw-r--r-- 1 web2 web2 7870 6. Okt 16:12 awstats.domain3.de.allrobots.html -rw-r--r-- 1 web2 web2 28704 6. Okt 16:12 awstats.domain3.de.browserdetail.html -rw-r--r-- 1 web2 web2 5469 6. Okt 16:12 awstats.domain3.de.downloads.html Hat sich im Bereich des Cronjobs bzw der Erstellung der Statistiken etwas verändert oder wie bekomme ich die Fehlermeldung wieder los?

Release 2.3.15 set a reasonable client_max_body_size for nginx according to php post_max_size [Fix] check existing mysql user hosts by key in DbManager::correctMysqlUsers() to avoid CREATE USER errors when changing mysql_access_host (#1425) [Fix] don't fail with TypeError in Database::showerror() if sql-error log cannot be written, notify user and syslog instead (#1424) [Fix] don't lose ssh keys when ftp-users share the same homedir [Security] block Certificates.add/update on Let's Encrypt managed domains More information: https://github.com/froxlor/froxlor/security/advisories/GHSA-ch7m-649m-x7xg [Security] enforce customer_hide_options 'mysql' in Mysqls.add More information: https://github.com/froxlor/froxlor/security/advisories/GHSA-6vjr-55fw-r5x2 hide dependent antispam fields when bypass_spam is forced or toggled; fixes #1419 [Security] reject mismatched id/loginname in Admins.get for resellers More information: https://github.com/froxlor/froxlor/security/advisories/GHSA-m7gc-8c8g-4f89 [Security] block customer deletion of main domains via SubDomains.delete More information: https://github.com/froxlor/froxlor/security/advisories/GHSA-pp2f-frcg-w8rv [Security] close remaining symlink-containment gaps in traffic/fcgid crons More information: https://github.com/froxlor/froxlor/security/advisories/GHSA-vwjv-x8ff-4cvv [Security] scope api_keys.php listing and delete to owned/managed keys More information: https://github.com/froxlor/froxlor/security/advisories/GHSA-5fm2-8wxf-xc5v The security-advisories will be published on 18th of October in order to give people enough time to update.

Ich hatte selber nachgedacht und mich entschieden, dass ich mich NICHT mit den internen Datenstrukturen von goaccess beschäftigen will. Somit habe ich die Statistiken verworfen und in einer iterierenden for-Schleife einfach die Statistiken aus den je vorliegenden 12 Monaten access.log's mit dem neuen goaccess neu bauen lassen. Die hier vorgestellte Lösung ist aber insofern schöner, als dass sie keine Daten verlieren kann.

Habe das Problem auch bemerkt und verschiedene Suchen auf Google führen immer wieder (und in auffälliger Anzahl 😜) hierher. Hier die Lösung, welche mir Claude in 2 Minuten geliefert hat: GitHubGitHub - GuentherMair/goaccess-fix-grouping: Silences GoA...Silences GoAccess ≥ 1.12's "This database predates request-grouping metadata" warnings. - GuentherMair/goaccess-fix-grouping

Vielen Dank! Ich werde das beobachten.

wenn der cronjob durchgelaufen ist sollten da natürlich keine "ausstehenden jobs" mehr angezeigt werden, du kannst den cronjob auch einfach öfter ausführen froxlor-cli froxlor:cron -fd

Hihi, nein :) interessant wie mir das durchgerutscht ist. Sorry! Der Manuelle Aufruf hat funktioniert In der Übersicht werden jetzt noch ausstehende Cronjobs aus August angezeigt. Kann ich das ignorieren? Ich habe die Konfiguration für cronjobs auch noch einmal ausgeführt (als root) :D

du rufst den cron aber schon als root auf ja?

Hallo zusammen, Mir ist aufgefallen, dass eine meiner Zertifikate bald ausläuft weswegen ich mir die Cronjob in froxlor angesehen habe. Beim aufrufen von /usr/bin/nice -n 5 /usr/bin/php -q /var/www/html/froxlor/bin/froxlor-cli froxlor:cron -f -d kam folgender Fehler: PHP Warning: require(/var/www/html/froxlor/lib/userdata.inc.php): Failed to open stream: Permission denied in /var/www/html/froxlor/lib/Froxlor/Database/Database.php on line 431 PHP Fatal error: Uncaught Error: Failed opening required '/var/www/html/froxlor//lib/userdata.inc.php' (include_path='.:/usr/share/php') in /var/www/html/froxlor/lib/Froxlor/Database/Database.php:431Die /var/www/html/froxlor/lib/userdata.inc.php gehört www-data und steht auf read-only für den Benutzer. FCGI und PHP-FPM sind in froxlor deaktiviert. php_mod ist installiert und aktiviert. Ich habe den Befehl als www-data ausgeführt, das hat dann zu weiteren Permission Fehlern beim Speichern der Zertifikate geführt... Sollte ja aber auch nicht sein das ich den CLI Befehl mit dem www-data user ausführen muss. Kann mir da Jemand weiterhelfen? Vielen Dank und viele Grüße!

IIS (Windows): Built-in FTP Logon Attempt Restrictions (IIS 8+). Configure maximum failed attempts within a time window; the service automatically drops the connection and temporarily blocks the client. IBM Sterling / B2B Integrator: Use Lockout Policy (Deployment → Adapter Utilities → Policy Configuration). Set max sign-on attempts, permanent vs. time-based lockout, and apply at protocol or instance level for FTP/SFTP. Network devices (e.g. Ruijie switches/routers): Commands such as: კორპორატიული შეკვეთები Brute-force protection Fail2Ban / IIS Logon Restrictions / native lockout policy Temporary or permanent lock of IP/user Concurrent connections Server’s MaxClients / MaxPerIP Refuse new connections Data volume / rate Quota modules or traffic shaping Throttle or disconnect Enterprise (IBM etc.) Built-in Lockout / Limitation Policies Configurable lockout

Das klingt nach einer sinnvollen Verbesserung. Gerade die Kombination aus Cache und schnellerer Prüfung bei einem Fehler oder ausstehenden Update dürfte unnötige CLI-Aufrufe reduzieren und trotzdem dafür sorgen, dass der Check nach einem Update schnell wieder auf OK geht. Danke fürs Nachschärfen des Skripts!

To cover a quate question with fail2ban - new to me and I can't find references in fail2bans config. What about the link? Is this an "bot" answer?

Konnte das gerade reproduzieren mit der 1.12. Das sagt lediglich das er für alte Daten nicht wissen kann welchen wert --http-method und --http-protocol hatte, froxlor setzt diese zwei optionen nicht und verlässt sich also auf die defaults/values aus der /etc/goaccess/goaccess.conf - es ist wohl nur ein hinweis und ggfls wird irgendwas als "UNKNOWN" angezeigt, aber einen migrationspfad o.Ä. gibt es nicht. Man wird aktuell wohl mit der warnung leben müssen wenn man die bisherigen Daten behalten will

Hat noch wer folgende Meldungen durch den traffic-cron je einmal täglich seit diese Woche ein aktualisiertes goaccess 1.12 für debian kam? Warning: This database predates request-grouping metadata. --http-method and --http-protocol cannot be validated. Rebuild it if request rows are grouped unexpectedly. ... und das vermutlich für jede Domain/VHost einmal, also je nach Nutzung ne lange Mail Wie lässt sich das beheben ohne die bisher gesammelten Daten zu löschen?

Hello dear friend Install Fail2ban via your system's package manager. Bash sudo apt update && sudo apt install fail2ban -y # Debian/Ubuntu sudo dnf install fail2ban -y # RHEL/Rocky/Fedora Verify Fail2ban is running using sudo systemctl status fail2ban. 2.Configure the FTP Jail: Create a local configuration file to avoid overwriting default settings during updates. Bash sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local sudo nano /etc/fail2ban/jail.local Scroll to the [vsftpd] or [proftpd] section (depending on your FTP daemon) and configure the limits:Ini, TOML Bitlife mod apk

dann halt so