Nice feature !

Is there some specific action to do in order to enable this panel to work ?

Because I tried to add it in my board and here is the error I get on Debian (with apt):

Note: I also have this warning in logs: PHP Warning: count(): Parameter must be an array or an object that implements Countable in /XXXX/libs/apt.php on line 42

Additional info:
It seems to use update-notifier with hardcoded path for your verification on Ubuntu. I don't find this apt-check in debian folders even after installing it:

# sudo apt install update-notifier
Reading package lists... Done
Building dependency tree
Reading state information... Done
Note, selecting 'gnome-packagekit' instead of 'update-notifier'

https://packages.debian.org/search?keywords=update-notifier

Thanks! Unfortunately, it looks like you confirmed my suspicions that the utility apt-check is provided by Ubuntu as an addon.

For the PHP Warning - I'll have to check on this as I wasn't paying attention to the php logs when poking at this problem. Looking at the php count() api - https://www.php.net/manual/en/function.count.php - this might be a bigger issue or I'm using it wrong.

I think what you're seeing is expected if the module is enabled but can't find the executable. I would also expect a console warning to be emitted of Not Available. If you're not, can you let me know as that probably means I screwed up the configuration check in the index.php file.

Doing a bit of further digging, I found https://askubuntu.com/a/441934 - which leads me to think that parsing the result of apt-get wouldn't be as difficult as I thought. And I just found out that if you put -s into the apt-get command, you no longer need to execute apt-get as sudo/root. Which is good. (silly assumption that apt-get had to be run as a superuser) Only downside is that I'll need to let a system get out of date for a bit for testing! It would also allow for a more detailed look at what categories are needing updating/removed/etc. instead of just the total values.

As for the hardcoded paths - that was a definite shortcut to get this working. I'm fairly confident that Ubuntu has had the script in that location for a few major versions and thought that would be Good Enough For Now. However, now that the sudo blocker for running apt-get directly appears to be a non-issue, it might be worth it to just get rid of leveraging apt-check.

For testing:

• What's your apt-get and php versions? e.g. the output of apt-get -version and php -v from the command line.
• Are you seeing a javascript console message being emitted?

Thanks for writing up the detailed question

Nice findings for the 'multi-linux' script !

My config:

Php: 7.3.29-1
Apt-get:  1.8.2.3
Debian 10 (buster)

Here is the result of the request on my debian for the apt-get command with -s: provided by your link before and after an update:

$ apt-get -s dist-upgrade | grep "^[[:digit:]]\+ upgraded"
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
$sudo apt update
(... update list of available packages from internet but doesn't download-install them)
$ apt-get -s dist-upgrade | grep "^[[:digit:]]\+ upgraded"
21 upgraded, 19 newly installed, 0 to remove and 0 not upgraded.

=> It seems you need to do an apt update before your script in order to be accurate :(
(note also that apt & apt-get are available under /bin/ folder in debian)

For the warning:

First, it was only for your information, it is a really minor problem.
It seems you try to do a count on something which is a simple variable, not a table (maybe a comparison with "null" would be more appropriate ?).

Example of lib that uses a count but will have a real table on json config file (ie [ ]):

ping.php:
if (count($Config->get('ping:hosts')) > 0)
{
   ...
}

esm.config.json:
"ping": {
        "hosts": [
            "facebook.com",
            "google.com",
            "yahoo.com"
        ]
    },

For the display behavior:

I think what you're seeing is expected if the module is enabled but can't find the executable. I would also expect a console warning to be emitted of Not Available. If you're not, can you let me know as that probably means I screwed up the configuration check in the index.php file.

Your script is working as intended:

Note: I have no js console log under Chrome but one under Firefox (it seems to be a strange behavior of the global script, not yours...)

Well, as the saying goes "Got some good news and bad news..."

Thanks for the details on your setup & output results. It does make troubleshooting so much easier.

Bad News: Leveraging apt-get is much slower than apt-check. Looks like there's some caching going on w/ the Ubuntu quality of life script. As you discovered, you also need a cron job or something to execute apt-get update on a schedule. If I was running Debian on a daily basis, I'd be tempted to pre-parse the result, save it to disk, and use that cached value.

Good News: I updated the script to check for apt-check and then apt-get in two locations. It should work for you now.

Interesting News: Turns out my initial assumptions about the Config utility was misplaced - if you attempt to get a missing key, it'll return the entire configuration tree. I dropped a TODO for myself to revisit as my PHP days were more of the 3.x variety....

Oh! Other interesting news: The various linux distros are slowly combining the various /bin and /usr/bin (etc) directory structures. Take a look: https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/ The next version of Debian does the same thing but I can't find the announcement again.

As for the warnings, I'm firmly in the camp that they should be addressed otherwise alert fatigue occurs. Weirdly, php logging isn't enabled on my server & I can't quite figure out where it's configured. (Another item for the list of 'random things to investigate when bored'.) Also, I wasn't able to get this to throw the error but if you're running PHP 8.0, that warning should be an error... which wouldn't be nice to throw. So.... best to fix it!

Wow ! That is just perfect ! Thanks a lot for this feature !
I checked on my debian server and it works fine ! (didn't have any package thought so it shows '0' and '0' but that is expected behavior).

Just for information, for my personal needs, I added an option to enable the apt-get update (by default disabled) on my fork if you want to integrate it (it means you have to allow sudo apt-get for www-data user with visudo).

• Working code (I checked, it works fine) and explanation (+security warning):
  QuentinCG@0007d70
  QuentinCG@7a70f1e
  QuentinCG@49e14e0

Weirdly, php logging isn't enabled on my server & I can't quite figure out where it's configured

It should be in log file like those if not configured and if you use apache: /var/log/apache2/error.log

You're welcome!

Updated the logic per your code snippets. Thanks for the patch code.

I did adjust it so the apt-get update is only triggered if you're using the apt-get path. (as the apt-check does execute it automatically if it's been too long since the last cache update, from what I'm seeing) I also added in the --non-interactive flag to sudo so it'll fail if the command prompts for anything (including the password). Can you confirm it works without issue on your end?

To be honest, having this script execute a sudo command feels a bit .... ugly. At least your documentation limits www-data to apt-get only, which is good & I appreciate calling out that approach.

Turns out my PHP install had it's logging disabled. Probably did that a while ago and forgot about it :) Hmm, I should probably merge my branch with my main branch. Time to experiment with the Config utility to figure out that count() problem...

Nice, so now your pull-request (may) work the same way between all linux !
Hope the owner will merge it for anyone to be able to use it (I'm using it anyway =P)

To be honest, having this script execute a sudo command feels a bit .... ugly. At least your documentation limits www-data to apt-get only, which is good & I appreciate calling out that approach.

I understand your concern.
With visudo method, it mitigates the risks as it allows only specific binaries to execute with superuser rights. It is all a balance between what your server is used for vs risks depending on binaries you allow.
I would not allow www-data to execute apt-get on critical server but it makes sense on less critical one.

I did adjust it so the apt-get update is only triggered if you're using the apt-get path. (as the apt-check does execute it automatically if it's been too long since the last cache update, from what I'm seeing) I also added in the --non-interactive flag to sudo so it'll fail if the command prompts for anything (including the password). Can you confirm it works without issue on your end?

If there is a password prompt, this new feature will just never work anyway, but you are right specifying '--non-interactive' will prevent side effects if your server is not correctly configured to allow www-data to use the command in s.u. mode ;)

Turns out my PHP install had it's logging disabled. Probably did that a while ago and forgot about it :) Hmm, I should probably merge my branch with my main branch. Time to experiment with the Config utility to figure out that count() problem...

By default, web servers have logs enabled.
That's not a good thing to disable web server logs on 99.9% of the cases as you never know when you need the logs (analyze an intrusion on your server, check errors that slow down your server, check which ips tried to access each of your websites, ...) and it doesn't cost so much space on your server.
Maybe you just need to revert this kind of thing ? https://superuser.com/questions/916726/disable-apache-logging-completely