Posts by Athar

    Well, from what I could find :

    Quote

    Process Control support in PHP is not enabled by default. You have to compile the CGI or CLI version of PHP with --enable-pcntl configuration option when compiling PHP to enable Process Control support.


    So, your only option would be to compile your own version of PHP8.1 with this option enabled.


    ==> https://www.php.net/manual/en/book.pcntl.php


    If you see it enabled, it should work, as no settings are available in the php.ini (from those pages), but I don't know this extension so...

    Yeah, R3 should be the default, but might be replaced in the future by E5/E6 (RSA to ECDSA).


    And checking some info, I can confirm this : https://community.letsencrypt.…uction-environment/150679 , I quote from the last answer 11 days ago:

    Quote

    In one week, on June 6th, we will be switching to new issuance chains 38, which will include issuing ECDSA by default.

    As a result, the ECDSA opt-in form is no longer needed and has been closed.

    Just did a check on my system and yeah, I confirm this is still working for newly added domain on my end.


    On an "old" one, I got one cert from R3+Root X1.

    On the new test domain created yesterday night (and certificate just a few minutes ago), got it from E6+Root X1.


    But you seems to have fixed it, it's fine for now 😁

    I know that on recent Ubuntu releases (20+ at least), there is this package installed : unattended-upgrades


    This install "harmless" update without letting you know by default.

    Well, harmless, it depend, as this update Docker even with containers running (so they crash and reboot once updated :D )


    I had to remove this package to ensure I didn't run into that anymore, maybe something to look on your side ? :)

    Yeah, didn't find a lot of informations so far.


    Only thing I saw, someone who tried to update from 18.04 to 18.10 and break everything (no real solution) and some other who might have got failed normal updates (but this was, mostly, on RedHat/CentOS :D ).


    All in all, the only advise I could read there was to check no updates were pending or in a fail state.

    Comme prévu : Suppression du package PHP-FPM utilisé par i-MSCP, ce qui fait que le "binaire imscp_panel" a été supprimé par le panel (incohérence de versions).


    J'ai vu dans l'historique l'installation des versions PHP-FPM 7.2, 7.3 et 7.4 (et la suppression, aussi, de la 7.1 qui a donc conduit au problème principal).


    Utilisation de la version 7.4 et recréation du binaire pour démarrer le panel et ça passe (sans garanties que des trucs ne fonctionneront peut-être pas avec la version 7.4).


    Quoi qu'il en soit, les versions installés ne fonctionneront pas, comme ça, pour PHPSwitcher.



    Tu peux marquer le post comme "résolu" du coup :D

    Alors il est fort probable que le dev ait installé (et remplacé) la version de PHP 7.0 ou 7.1 nécessaire au panel ce qui pourrait faire du dégât :D


    Sachant que la procédure pour ajouter une version de PHP avec PHPSwitcher est différente d'une installation normale, cela me parait donc envisageable.


    Également, j'ai regardé sur mon système, le fichier "/usr/local/sbin/imscp_panel" est bien présent (logique puisqu'il est appelé par le service en question), cependant la date et l'heure semblerait indiquer qu'il est régénéré par un process autre (ou au moins modifié).

    Code
    1. ls -alh /usr/local/sbin/imscp_panel
    2. -rwxr-xr-x 1 root root 4.5M Apr 12 18:20 /usr/local/sbin/imscp_panel
    3. systemctl status imscp_panel.service
    4. ● imscp_panel.service - PHP FastCGI process Manager Daemon for i-MSCP FrontEnd
    5. Loaded: loaded (/etc/systemd/system/imscp_panel.service; enabled; vendor preset: enabled)
    6. Active: active (running) since Fri 2024-04-12 18:20:35 CEST; 1 day 20h ago


    A mon niveau, et par discussion interposé ici, je n'aurais pas plus de conseils que ce que j'ai déjà dis (et de fait, on sait désormais que l'installation sur tes serveurs est donc dans un état "instable" au vu des fichiers manquants).

    On est pas tant sur un problème d'iMSCP que de gestion du serveur de manière générale aussi :')


    En dehors de me connecter au(x) serveur(s) pour voir ce qu'il en est, je ne sais pas quoi dire de mieux, et je ne suis pas un expert non plus en la matière, aucune garantie de pouvoir en trouver une solution (avec le setup qui n'est plus fonctionnel, et qu'il faudrait pourtant relancer pour replacer les éventuels fichiers manquants).



    Edit : Je viens de faire une petite recherche rapide, et ce fichier semble être supprimé dans le cas ou la version attendue de PHP FPM ne serait plus présente (si j'en comprend bien le code) :

    Code
    1. if ( -f '/usr/local/sbin/imscp_panel' ) {
    2. unless ( -f $self->{'config'}->{'PHP_FPM_BIN_PATH'} ) {
    3. # Cover case where administrator removed the package
    4. # That should never occurs but...
    5. my $rs = $self->stopPhpFpm();
    6. $rs ||= iMSCP::File->new(
    7. filename => '/usr/local/sbin/imscp_panel'
    8. )->delFile();
    9. return $rs;
    10. }


    Bref, c'est théoriquement réparable, mais jamais fait (car jamais eu le cas de mon côté :D )