[ralphy]

We have a winner there :)

Consider... /etc/suoders.d/lun  chmod 0440 which is the correct recommended permission.

Everything seems to work beautifully in my tests.

[valtam]

We have a winner there :)

Consider... /etc/suoders.d/lun  chmod 0440 which is the correct recommended permission.

Everything seems to work beautifully in my tests.

Thanks Ralphy, will set those perms.

[valtam]

Git pushed. Will leave the 2min test in there until we're close to final.

[ralphy]

Thank you Jerry, great work!

Here is a time saving script to help you with the postinst

Code:

#! /bin/sh
# Postinst script for Lite Update Notify
set -e
file=lun
if [ ! -f /etc/sudoers.d/$file ]; then
    (umask 337;touch /etc/sudoers.d/$file)
    echo '%sudo ALL=NOPASSWD: /usr/local/sbin/updatenotify' >> /etc/sudoers.d/$file
else
    :
fi

[valtam]

Cheers Ralphy, I've placed your code into postinst.

[ralphy]

Cheers Ralphy, I've placed your code into postinst.

It aint mine but OUR  ;D

[valtam]

:)

Sent from my Phone using Tapatalk

[ralphy]

I noticed that we didn't have a check to kill package managers in lite-tweaks-super. I have committed the check to master: https://github.com/linuxlite/litetweaks/...dfa48818e2

But in the same process, while double checking code, I noticed that we have package managers kill switch in liteupdatesnotify:

https://github.com/linuxlite/liteupdates...datenotify

Code:

...
# Kill off any package managers that may be running
if [ "$(pidof synaptic)" ]
then
   killall -9 synaptic
fi

if [ ! -z "$(pgrep gdebi-gtk)" ]
then
   killall -9 gdebi-gtk
fi
...

There is no interference between what we are executing in liteupdatesnotify and a lock from package managers that may cause the script to error out. Do we really need the kill switch there?

[valtam]

I was concerned that the updatenotify script wouldn't complete, (line 5: sudo apt-get update > /dev/null 2>&1 ) The script does complete after some testing, but I'd like to test some more.

[ralphy]

Well, we have more work to do with liteupdatesnotify... it doesn't work as expected (yet)... debugging here on my end this is what I see:

We are allowing to execute /usr/local/sbin/updatenotify as sudo with no password but the file itself doesn't get launched with sudoers privileges hence its asks for password to run 'sudo apt update'

[sudo] password for ralphy:
0 packages can be updated.
0 updates are security updates.

A work around would be to add %sudo ALL=NOPASSWD: /usr/bin/apt-get  to /etc/sudoers but I don't like that idea.

Another way would be to put the cron job under root crontab but this will make it a global configuration; meaning that changes on that cron job cannot be saved on a per user level ( they all go to root ).

yup, we have to go back to the drawing board and think of better ways.