All Activity

It works! danke

https://github.com/froxlor/Froxlor/issues/1316#issuecomment-2732518385 Oder auf update warten

Danke. Ich habe auch die MySQL… was ist konkret zu machen? kleinen Tipp bitte:)

https://github.com/froxlor/Froxlor/issues/1316

Hallo, nach dem Update auf 2.2.6 kann kein User mehr Datenbanken anlegen. Fehler A database error occurred SQLSTATE[HY000]: General error: 1396 Operation CREATE USER failed Was kann ich machen? VG

So I checked permissiins on customrs web, they are right. I do a nscd -i group and nscd -i passwd and restart service php8.4-fpm restart and now it works. I purged nscd and reboot the system and it seems to work! Thank you sooo much for fast response 😉

a) with libnss-extrausers you do not need nscd, remove it b) check the customer's homedir permissions, see error message: "ensure it is readable and that '/var/customers/webs/Test/' is executable"

Hello, we have 3 froxlor (version 2.2.6, debian trixie, PHP-FPM, PHP8.4.x) systems, 2 works fine, if we create a new customer with domain. On one system it is faulted, an error occurs for domian (also if I open webalyzer): [Mon Apr 21 10:34:28.730401 2025] [core:crit] [pid 1032037:tid 1032037] (13)Permission denied: [client xx.xxx.xxx.xxx:51055] AH00529: /var/customers/webs/Test/.htaccess pcfg_openfile: unable to check htaccess file, ensure it is readable and that '/var/customers/webs/Test/' is executable So i checked the libnss-extrausers configurations and versions on all three systems and they are identically version libnss-extrausers 0.6-6 nssswitch.conf: # Make sure that `passwd`, `group` and `shadow` have extrausers in their lines # You should place extrausers at the end, so that it is queried after the other mechanisams # passwd: compat extrausers group: compat extrausers shadow: compat extrausers hosts: files dns networks: files dns services: db files protocols: db files rpc: db files ethers: db files netmasks: files netgroup: files bootparams: files automount: files aliases: files nscd.conf: # # /etc/nscd.conf # # An example Name Service Cache config file. This file is needed by nscd. # # WARNING: Running nscd with a secondary caching service like sssd may lead to # unexpected behaviour, especially with how long entries are cached. # # Legal entries are: # # logfile <file> # debug-level <level> # threads <initial #threads to use> # max-threads <maximum #threads to use> # server-user <user to run server as instead of root> # server-user is ignored if nscd is started with -S parameters # stat-user <user who is allowed to request statistics> # reload-count unlimited|<number> # paranoia <yes|no> # restart-interval <time in seconds> # # enable-cache <service> <yes|no> # positive-time-to-live <service> <time in seconds> # negative-time-to-live <service> <time in seconds> # suggested-size <service> <prime number> # check-files <service> <yes|no> # persistent <service> <yes|no> # shared <service> <yes|no> # NOTE: Setting 'shared' to a value of 'yes' will accelerate the lookup, # but those lookups will not be counted as cache hits # i.e. 'nscd -g' may show '0%'. # max-db-size <service> <number bytes> # auto-propagate <service> <yes|no> # # Currently supported cache names (services): passwd, group, hosts, services # # logfile /var/log/nscd.log # threads 4 # max-threads 32 # server-user nobody # stat-user somebody debug-level 0 # reload-count 5 paranoia no # restart-interval 3600 enable-cache passwd yes positive-time-to-live passwd 600 negative-time-to-live passwd 20 suggested-size passwd 211 check-files passwd yes persistent passwd yes shared passwd yes max-db-size passwd 33554432 auto-propagate passwd yes enable-cache group yes positive-time-to-live group 3600 negative-time-to-live group 60 suggested-size group 211 check-files group yes persistent group yes shared group yes max-db-size group 33554432 auto-propagate group yes enable-cache hosts yes positive-time-to-live hosts 3600 negative-time-to-live hosts 20 suggested-size hosts 211 check-files hosts yes persistent hosts yes shared hosts yes max-db-size hosts 33554432 enable-cache services yes positive-time-to-live services 28800 negative-time-to-live services 20 suggested-size services 211 check-files services yes persistent services yes shared services yes max-db-size services 33554432 enable-cache netgroup yes positive-time-to-live netgroup 28800 negative-time-to-live netgroup 20 suggested-size netgroup 211 check-files netgroup yes persistent netgroup yes shared netgroup yes max-db-size netgroup 33554432 #/var/lib/extrausers seems to be correct. www-data is in all groups Any idea?

You should not put user data outside of the customers homedir...

I had the same confusion. Adding :/var/services/ to OpenBasedir only allows access, but doesn’t change where the subdomain path actually points. When you set the subdomain path to /var/services/nextcloud, the panel still prepends the user path like /var/customers/webs/$USER/, unless you manually adjust it in the backend or use root-level config. Using /../ won’t help—it’s sanitized for security. I ended up creating a symlink inside /var/customers/webs/$USER/ pointing to /var/services/nextcloud, and allowed both paths in OpenBasedir. It works fine. If you want a true shared path across subdomains, you'd need to configure this outside the web panel using Apache/Nginx manually.

Unfortunately, I haven't had the time to get to the bottom of this yet but it's on my list

Hello everyone, I'm having the same problem on some of my servers (running MySQL 8.0). However, other servers running MariaDB are working fine. Is there a solution to this problem in sight? Thanks Thorsten

Problem ist gelöst. Dummer Fehler von mir. Es betraf eine andere Maschine, nicht diese. Hab nur beim Absender nicht aufgepasst. Ich schließe den Thread. Oder bitte schließen, ich kann das wohl nicht. Hab zumindest auf die Schnelle nix gefunden.

Perfekt. Man dankt!

Ja die process-manager settings sind PRO domain, sagst du "spawn 10 child-processes" dann gibts für jede domains 10 prozesse genau, die settings die du da festlegst sind immer für jede domain die dieser config zugeordnet sind

Moin, ich hab ein paar Domains mit unterschiedlichen PHP-Anforderungen und deshalb verschiedene PHP-Konfigurationen. Konfiguration A - 2 Domains, Konfiguration B - 2 Domains. Ich hab dann im Pool.d-Verzeichnis nachgeschaut und da ist dann für jede Domain eine Konfiguration geschrieben. Sieht gut aus. Jetzt zum Verständnis: Wenn ich in der Konfiguration A angebe 10 Server zu starten dann startet der für jede der Domains 10 Server - also 20 gesamt. Das ist nicht ein Pool von 10 Servern für die jeweiligen Konfiguration. Korrekt? Beim Opcache Verhält sich das dann ähnlich. Der Opcache gilt nicht für den Pool an Domains der selben PHP-Konfiguration sondern für jede Domain einzeln. Korrekt?

ich vermute jetzt mal, dass ich unter bookworm php8.2 verwenden sollte, es scheint unter 8.1 nicht richtig zu funktionieren, wegen des raphf. Dazu müsste ich wohl im Froxlor die FPM config ändern auf php8.2. php8.2 ist ja bereits im Dateisystem installiert, muss es also nur switchen.

k.A. hab vor dem post hier noch nie von raphf gehört - ist weder bestandteil von standard debian php noch von froxlor

also unter /etc/php/8.1/fpm/conf.d, finde ich: 20-raphf.ini -> /etc/php/8.1/mods-available/raphf.ini Ich brauch dieses raphf nicht, außer irgendein Tool benötigt das. Ich habe das installiert, wegen der Meldung PHP Warning: Cannot load module "http" because required module "raphf" is not loaded Er sollte ja das Modul http laden können, deswegen die ganze Aufregung.

nein tut es nicht, die haben da nix verloren. Worüber beziehst du denn die verschiedenen PHP Versionen? Irgendwie scheint mir da was komisch auszusehen. Hast du denn diese raphf extension explizit installiert und brauchst das? Ansonsten schmeiss doch raus den müll

Hab noch was gefunden. server:/usr/lib/php# find . -name raphf.so ./20170718/raphf.so ./20151012/raphf.so ./20190902/raphf.so ./20240924/raphf.so ./20230831/raphf.so ./20160303/raphf.so ./20200930/raphf.so ./20210902/raphf.so ./20220829/raphf.so ./20180731/raphf.so In den Ordnern drwxr-xr-x 3 root root 4.0K Mar 11 10:35 7.0 drwxr-xr-x 3 root root 4.0K Mar 11 10:35 7.1 drwxr-xr-x 3 root root 4.0K Mar 11 10:36 7.2 drwxr-xr-x 3 root root 4.0K Mar 11 10:36 7.3 drwxr-xr-x 3 root root 4.0K Mar 11 10:36 7.4 drwxr-xr-x 3 root root 4.0K Mar 11 10:33 8.0 drwxr-xr-x 3 root root 4.0K Mar 11 10:34 8.1 drwxr-xr-x 3 root root 4.0K Mar 11 10:34 8.2 drwxr-xr-x 3 root root 4.0K Mar 11 10:33 8.3 drwxr-xr-x 3 root root 4.0K Mar 11 10:37 8.4 gibt es nur diese Files: -rw-r--r-- 1 root root 73K Mar 10 16:24 php.ini-development -rw-r--r-- 1 root root 73K Mar 10 16:24 php.ini-production -rw-r--r-- 1 root root 73K Mar 10 16:24 php.ini-production.cli drwxr-xr-x 2 root root 4.0K Mar 11 10:34 sapi Ich könnte ja mal die raphf.so da reinkopieren, aber ob das Sinn macht weiß ich nicht.

die Meldung kommt nicht vom froxlor cronjob, sondern von PHP selbst, mach doch auf der console einfach mal ein "php -v" oder "php -m" - da wirst du den selben Fehler sehen. Ich hab mit diesem "raphf" noch nie gearbeitet, möglicherweise musst du die extension vllt erst aktivieren, wenn du sagst du findest den Eintrag /etc/php/8.1/mods-available/raphf.ini:extension=raphf.so dann ist die extension ja erstmal nur "verfügbar", wirf mal einen blick in den /etc/php8.1/fpm/conf.d/ (sofern du fpm nutzt) und/oder /etc/php8.1/cli/conf.d/ (für shell nutzung) - da sollte die raphf.ini ja gelinked sein

Hallo d00p, diesen Artikel hatte ich auch gelesen. Und raphf ist installiert. vserver1:~# dpkg -la|grep raphf ii php-raphf 2.0.1++-4+0~20241125.27+debian12~1.gbp2ec090 all raphf module for PHP ii php7.0-raphf 2.0.1++-4+0~20241125.27+debian12~1.gbp2ec090 amd64 raphf module for PHP ii php7.1-raphf 2.0.1++-4+0~20241125.27+debian12~1.gbp2ec090 amd64 raphf module for PHP ii php7.2-raphf 2.0.1++-4+0~20241125.27+debian12~1.gbp2ec090 amd64 raphf module for PHP ii php7.3-raphf 2.0.1++-4+0~20241125.27+debian12~1.gbp2ec090 amd64 raphf module for PHP ii php7.4-raphf 2.0.1++-4+0~20241125.27+debian12~1.gbp2ec090 amd64 raphf module for PHP ii php8.0-raphf 2.0.1++-4+0~20241125.27+debian12~1.gbp2ec090 amd64 raphf module for PHP ii php8.1-raphf 2.0.1++-4+0~20241125.27+debian12~1.gbp2ec090 amd64 raphf module for PHP ii php8.1-raphf-dbgsym 2.0.1++-4+0~20241125.27+debian12~1.gbp2ec090 amd64 debug symbols for php8.1-raphf ii php8.2-raphf 2.0.1++-4+0~20241125.27+debian12~1.gbp2ec090 amd64 raphf module for PHP ii php8.2-raphf-dbgsym 2.0.1++-4+0~20241125.27+debian12~1.gbp2ec090 amd64 debug symbols for php8.2-raphf ii php8.3-raphf 2.0.1++-4+0~20241125.27+debian12~1.gbp2ec090 amd64 raphf module for PHP ii php8.3-raphf-dbgsym 2.0.1++-4+0~20241125.27+debian12~1.gbp2ec090 amd64 debug symbols for php8.3-raphf ii php8.4-raphf 2.0.1++-4+0~20241125.27+debian12~1.gbp2ec090 amd64 raphf module for PHP Die Meldung kommt trotzdem, aber ich weiß nicht, von welchem vhost die Meldung kommen soll. find /var/www/fcgi -name php.ini -type f -exec grep "raphf" {} \; bringt kein Ergebnis. Könnte das Problem also außerhalb von froxlor zu finden sein? Obwohl die Meldung den froxlor cronjob betrifft? Gruß feiaweng

Hi again, today, I removed my Froxlor installation along with MySQL. I then installed MariaDB and set up a fresh Froxlor installation. Everything is working fine with MariaDB—just wanted to keep you informed. Best Bastian

2 sek google: https://askubuntu.com/questions/1386960/php-warning-cannot-load-module-http-because-required-module-raphf-is-not-lo Btw. hat nix mit froxlor zu tun und gehört nicht zum "standard-setup", froxlor hat nichts mit "php-raphf" zu tun