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