Jump to content
Froxlor Forum

hk@

Members
  • Posts

    43
  • Joined

  • Last visited

Posts posted by hk@

  1. 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...

     

  2. On 12/10/2023 at 8:39 PM, d00p said:

    maybe then dont blindly/automatically update - or possibly just dont use the froxlor apt-package and update manually after checking the changelog. I'm open for ideas if you have any...

    These were gone since 2.0 already, looks like we've missed these files in the updater to remove them...

    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

  3. 1 hour ago, d00p said:

    Fix:

    UPDATE `panel_settings` SET `value` = 'bullseye' WHERE `settinggroup` = 'system' AND `varname` = 'distribution';

     

    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.

  4. 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....

  5. 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?

  6. 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...

  7. 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

  8. 7 minutes ago, d00p said:

    that's because this is its purpose - its meant to configure the services for you (instead of the former copy'n'paste way...) - it's not meant to be run regulary or anything like that. It doesnt use "current certificates" froxlor generated ....that's not what this tool is there for.

    Why would you RECONFIGURE your services to the default configs regularly? doesnt make sense tbh.

    What you basically want is a cronjob that checks whether a certificate you are using in other services (postfix, dovecot, proftpd) got renewed and these services need to be restarted...

     

    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 ;)

  9. 4 minutes ago, d00p said:

    if you like to use the phpmyadmin debian/ubuntu package and you are using fcgid/php-fpm you will definetly need to adjust the virtual-host config for phpmyadmin to use fcgid/php-fpm as you like. 

    If you want to be able to control these things via froxlor, another approach could be adding a 'phpmyadmin' customer and assign e.g. a subdomain to it for phpmyadmin usage

    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 :)

  10. 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

  11. 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

  12. On 1/11/2023 at 8:33 AM, d00p said:

    "unnanounced update" - literally in the announcement thread...hilarious.

    Sorry you are having so much trouble - we've tried to test as much as possible but due to the support for various settings-combination we can never be sure to hit everything - hence we try to provide fixes as soon as possible.

    Maybe in your case it would be a better idea to mark the froxlor debian package as hold and wait a few weeks

    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)

  13. 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!

  14. 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.

  15. 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.

×
×
  • Create New...