hk@

wegen dem goaccess das in der 22 LTS release bisher nur in 1.5.5 kommt und entweder backport braucht oder doch einen Versionssprung. vgl. Bug #2047753 “goaccess displays 'cleaning up resources' message ...”

yep, alias ist gesetzt. sidenote: ubuntu bugreport filed.

tschuldigung, das is ja das deutschsprachige Forum. Die beiden Einträge (2+7) gibt es - sind automatisch erzeugte "Standardsubdomains" von froxlor.

Hi, tried this fix on froxlor v2.1.3-1 on Ubuntu v22 - output is reduced but we still see "Cleaning up resources..." and somehow additional warnings like this: /usr/bin/php8.2 -q /var/www/html/froxlor/bin/froxlor-cli froxlor:cron 'traffic' -q 1> /dev/null Cleaning up resources... Cleaning up resources... Cleaning up resources... PHP Warning: Undefined array key 2 in /var/www/html/froxlor/lib/Froxlor/Cron/Traffic/TrafficCron.php on line 168 Cleaning up resources... Cleaning up resources... PHP Warning: Undefined array key 7 in /var/www/html/froxlor/lib/Froxlor/Cron/Traffic/TrafficCron.php on line 168 Cleaning up resources... Cleaning up resources...

While I get your regular sarcasm, I'd bring again forward the idea to have different release-paths, if there is only one froxlor repo, the only option to not manually do updates on all servers (and most of the times this works fine) is to use the repo available. I might refer to other repos (like powerdns, sury.org) that offer specific release paths as well as distribution paths. I see great value in getting security fixes as soon as possible without manual intervention, there is basically no manual alternative besides being on standby 24x7 for all servers in case a security-update hits. This is why we do not read changelogs and do things manually - in case of security - better update first and ask questions later. Yet - the option to have eg. a 2.0 release repo, 2.1, 2.2 etc - especially if different distributions the panel supports are retired by changing a minor release - would be a good thing to keep things not breaking automagically. Yes, this is additional administration overhead for the repository and it seems we're the only ones having this issue, so maybe it's not worth it. Currently we do check changelogs as soon as we see updates being delivered, but we would not risk being late for security updates and do things manually later. Seasons Greetings, hk

thank you again, this worked. Regarding removal - yeah, but the update came automated and then it is a bit too late to upgrade the distribution beforehand. #funfact after fixing the above setting, the panel still offers Debian v9 and Ubuntu v16, only v10 (debian) and v18 (ubuntu) have been removed in the dropdown-box.

thx for the update - that still happened to Debian v10 also one issue we see: webinterface via admin_configfiles.php?page=configfiles reports Unknown distribution I do suspect this has something to do with Debian v10 running? to be on the safe side - upgraded v10 to v11, then did a cli-reconfiguration for froxlor, but even then it reports "unknown distribution" there. please advise on how to get out of this....

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.

Hi good news! Is there a sane way for current debian-package-users to upgrade without breaking anything (ie. upgrading using the latest tar.gz)? thx, hk

Hi actually this fix is missing the removal of the compromised logfiles, otherwise it fixes future logging of passwords, but not the access to the logfile that has been compromised. I ask you to add a proper .htaccess-block for the logs-directory _and_ remove the logfiles from there as they - if kept - are still a security-risk in the current release. thx hk