hk@

Hi, froxlor v2.0.13-1 (on Unbut 20.04 LTS) - basically all is well, yet if acme.sh updates the LE certs via its own root-owned cronjob in the middle of the night, the froxlor cronjob somhow doesn't find those certs to be new - until - we look into each domain that suffers from this problem and see LE is deactived for this domain. We're quite sure neither us nor the user did this, I guess it's probably some domain test by froxlor gone bad, but if there was a problem we didn't get notified nor anyone else gets notified except for the LE certs silently expiring. Could there be another way to handle such cases, ie to recover from a temporarly failure?

after migrating from 0.10 to 2.0.9 the first odd thing was that the letsencrypt cronjob wasn't there anymore, although the cron-rebuild (-r 99) was done per the webupdate-instructions. tried disabling LE for the froxlor-vhost and re-enabling it, then tried disabling letsencrypt via settings and then disabling ssl all together, re-enabling it and doing froxlor:cron 'tasks' as well as froxlor:cron 'letsencrypt' manually. it simply does not generate a LE/acme config not does it import any already stored certs from acme for the froxlor-vhost. other domains work just fine on the same host with LE. this is now the second froxlor-setup this is happening, so I'm out of ideas where to look as evidence of things not seen in the debug-log is hard to report...

well, how about connecting to the socket or if this is not feasible maybe a cron-job could do the trick reporting the status and froxlor could read it.

In Froxlor one gets the phpinfo, opcache and APCu information via the panel for the php-version currently run by the panel (obviously). I wonder if it might be possible to select each configured php-fpm-version and get those information-sets for the selected version by the admin/user. I'm guessing it should be possible piping the respective info/status call via the fpm-socket of each version and show the result in the panel. Also I belive this might help users and admins to see possible issues on their currently running environment in full. thx hk

which is perfectly understood (yet dovecot and proftpd would seem easier, while postfix exposes its settings also); anyway, injecting a path to key+cert+fullchain might seem more probable.

usually web-admins don't get root, but ymmv.

this cronjob is already in place I'm not talking about regularly, but for situations (like we experienced) when the current config isn't working anymore and we have to rebuild configs - ideally as fast as possible and using as little different steps. Also I was writing about major system-upgrades (like moving from Debian v10 to v11 or Unbuntu 18 to 20 or 22), it would simply ease these updates if some custom ssl/tls settings could be kept or injected. In the end I'm just looking for easier effortless upgrade-paths because systems get quite old quite fast otherwise

while having a phpmyadmin user has its advantages, the major set-back is that any admin-user could simply delete it and while it can be argued this must not happen and it's ones own fault - we'd very much like to avoid even the possibility to have this accidentially deleted and noone saying anything until it is needed and then all hell breaks loose to fix this asap. if we look eg at debian v10 which would offer phpmyadmin v4.6.6 from its repository, this needs php7.1 and simply can not co-exist via an alias-path working in the at-least-php7.4-fpm-space of the froxlor v2 host itself. What would be seriously nice would be to have an option to set a domain+customer to be locked and hidden from the panel until some un-hide-procedure is done via cli. But in fact I don't see a good way except for a manual setup like adding a system-user and a manual site-config to have this running in its own context without being interferred by any other domain, which in turn creates a lot of other maintenance issues

Hi, currently we use the froxlor-server-hostname generated lets-encrypt certificate also for services like proftpd, postfix and dovecot. Additionally we check for refreshed certs and if new certs arrive we reload those services so they take up the new cert before the old one expires. Now the froxlor:config-services option using froxlor-cli is a great tool to get thing fixed up - especially after major updates on the system-level. Yet it creates a default-set for its certificates like ssl-cert-snakeoil.pem for postfix+dovecot and its very own proftp-cert. For postfix+dovecot we migth workaround by using symlinks from snakeoil to the /etc/ssl/froxlor-custom/<server-hostname.crt> but proftp doesn't give us this easy way out. So basically my question would be: How about a switch for the config-services script to keep current tls/ssl settings but replace the other config parts? Or a way to specify one's own certificate-files for some/all services? I believe this would make life a lot easier when going for new ubuntu/debian releases that basically require to re-create (or re-check) a lot of configs for froxlor. thx hk

Hi, we're running debian/ubuntu setups and depending on the version the usually packaged phpmyadmin does not always like the froxlor required php-version, also requirements might change in the future and therefore we are considering to move away from the current https://froxlor/phpmyadmin setup as we can't (easy) use different php-versions in folders/locations. Now my question would be: is there a best practice on how to setup phpmyadmin side by side with froxlor, ideally we'd have both being updated using apt and not creating manual update-needs. Additionally we have an additional authentication setup in front of phpmyadmin that requires users to login using their ftp credentials in order to reduce brute-force or other security issues with phpmyadmin itself. Any input would be very welcome. thx, hk

well, it is a major update - obviously - new installs, new requirements, several changes in paths, scripts etc. announcements in the forum are usually not checked on a daily basis, we found out (and still find out) the hard way getting updates via apt which break a lot of things. holding packages would have been an option if we only had known beforehand... (or major updates might choose to take an explicit path for packaging not going into autoupdates)

really loving froxlor until now, but this quite unannounced and unstoppable update breaks my neck on several systems, would have preferred a clear update-path without auto-breaking systems.

yep, of course

I'm aware of the strange occurence and if I hadn't had a non-working customer-site I'd have investigated it in more detail. My conclusion is simply based on the happening: 0750 works, then doesn't work, 0751 works, then after restarting apache and checking the extrausers for oddities it works again with 0750. apache logs clearly it couldn't access the .htaccess (yes in the userdir where no such file exists nor should exist), but it only happened to the one website that had a .htaccess in their docroot while all other sites were working with no issue whatsoever and those do not have a .htaccess in their docroot. Why it tries to look into the userdir? I don't know. If we get this error again, we'll hopefully be able to show a simple "groups www-data" that doesn't include the user-group of this or another usere, which it should be a member of which then would in turn point to extrausers for the possible issue. thx!

Hi quite similar to https://forum.froxlor.org/index.php?/topic/16806-server-unable-to-read-htaccess-file/#comment-37628 merely out of thin air the error log of a domain reports this: [Sun Jul 31 15:41:40.701383 2022] [core:crit] [pid 20833:tid 140391919634176] (13)Permission denied: [client x.x.x.x:y] AH00529: /var/customers/webs/user/.htaccess pcfg_openfile: unable to check htaccess file, ensure it is readable and that '/var/customers/webs/user/' is executable userdirs usually get created "drwxr-x---" by froxlor. had to change this userdir using "chmod +x" to get "drwxr-x--x" and things worked fine then. this is a problem that seems to appear if the docroot is another subdirectory and the user places a .htaccess file there, otherwise this seems to be no issue... a bit strange, but it seems this way. and yes, the user-group does containt www-data as a member, the system is running ubuntu 20. finally rebooted the system and changed permissions of the userdir back to 0750. it seems this issue is somehow related to libnss-extrausers not delivering correctly, yet replication of the problem seems hard.

Hi basically tried this on a live-system and the "funny" thing was: the froxlor vhost worked fine after switching (served via fpm). but any other domain hosted gave this in their error-logs: [proxy_fcgi:error] [..] AH01079: failed to make connection to backend: httpd-UDS [proxy:error] [..] (13)Permission denied: AH02454: FCGI: attempt to connect to Unix domain socket /var/lib/apache2/fastcgi/3...-php-fpm.socket (*:80) failed first changed the settings then did the fpm-config-scripting - but obviously missed something somewhere. any advise would be greatly appreciated.

jap - schaut gut aus Danke!

Froxor -> Ressourcen -> SSL-Zertifikate -> dort das LE-Cert für den VHost gelöscht.

Danke - noch eine Kleinigkeit: hätte jetzt auch das LE-Cert für den froxlor-VHost gelöscht - aber das wird anscheinend nicht wieder generiert?

merci - kann das hier bestätigen, nach einem --force sind die LE-Certs wieder gut. Krieg ich eventuell einen Tipp, wie dsa LOG_WARN wegzubekommen wäre? Danke!

Hallo, wir haben das gleiche Phänomen auf einer Froxlor-Installation. Gibt's da zufällig einen geordneten Fix? Danke, hk

and sorry for taking the wrong forum, obviously should have posted in german here, maybe you can move this thread to the international one. thank you again.

uhm, that's exactly what is (and was) running on this box, yet we got lots of mails reporting about socat.

well, the acme.sh is reporting this on a 5-minute-basis because of the --tasks job and to get rid of this had to install it but any other "get rid of this" solutions would be welcome.

today we suddenly got this: /usr/bin/php /var/www/html/scripts/froxlor_master_cronjob.php --tasks --debug [information] TasksCron: Searching for tasks to do [information] Running Let's Encrypt cronjob prior to regenerating webserver config files [information] Requesting/renewing Let's Encrypt certificates [information] Updating certificate for xxx.server.local [Tue Dec 31 15:47:09 CET 2019] It is recommended to install socat first. [Tue Dec 31 15:47:09 CET 2019] We use socat for standalone server if you use standalone mode. [Tue Dec 31 15:47:09 CET 2019] If you don't use standalone mode, just ignore this warning. [information] Checking for LetsEncrypt client upgrades before renewing certificates: [Tue Dec 31 15:47:08 CET 2019] Installing from online archive. [Tue Dec 31 15:47:08 CET 2019] Downloading https://github.com/Neilpang/acme.sh/archive/master.tar.gz [Tue Dec 31 15:47:09 CET 2019] Extracting master.tar.gz [Tue Dec 31 15:47:09 CET 2019] Installing to /root/.acme.sh [Tue Dec 31 15:47:09 CET 2019] Installed to /root/.acme.sh/acme.sh [Tue Dec 31 15:47:09 CET 2019] Good, bash is found, so change the shebang to use bash as preferred. [Tue Dec 31 15:47:10 CET 2019] OK [Tue Dec 31 15:47:10 CET 2019] Install success! [Tue Dec 31 15:47:10 CET 2019] Upgrade success! [Tue Dec 31 15:47:10 CET 2019] Removing cron job the box is ubuntu buster/sid after a bit of digging into the issue "apt install socat" did the trick. please add it to the required packages.