Updating as a regular user

[oops]

... The ability of updating for a regular user is interesting, but mostly for the web browsers, openoffice, the security patches, etc ... but not recommended for a grub update, or a kernel update for example.

[b3ta]

EDIT: Some wit said "In theory there is no difference between practice and theory; in practise there is."
This doesn't work! (Guess I should have tested first). I'll look at it again soonish. Right now the Long Island Iced Tea my wife gave me precludes any further investigation.

---

Thank you for all the help.

Four points, and I'm OK to mark this a SOLVED (it is for me). [See the EDIT, above]

ONE

... but not recommended for a grub update, or a kernel update for example.

Indeed. That's where I think Mint's idea of update levels is probably a Good Thing.
That said, I don't really want to end up here (because I've been there): https://forums.linuxmint.com/viewtopic.php?t=233882.

TWO

Reading https://wiki.archlinux.org/index.php/Polkit and https://doc.opensuse.org/documentation/ ... cykit.html brought me to the following insights:

• Local authorisation rules should be placed in /etc/polkit-1/rules.d/ to preclude updates from clobbering them.
• The sed script should be amended not to change the authorisation requirements for <allow_any> or <allow_inactive>.

I have written the following script I'm saving as ~/bin/local-polkit_admin2self. It adds a few more authorisations I think are useful in the context of a single-user laptop. The reason I'm scripting it as opposed to running it once is to have a record of what I've done, as a diff a few upgrades hence might induce a headache, depending on which new policies there are. Yes, I'm not defining a trap to delete the directory, this could all be one line, etc., but I'd also rather read it easily.

Code: Select all

#!/bin/bash

SDIR=/usr/share/polkit-1/actions
DDIR=/etc/polkit-1/rules.d
TDIR=`mktemp -d`

if [ ! -d $DDIR ]; then
  sudo mkdir -p $DDIR
fi

for sf in\
 $SDIR/org.mxlinux.pkexec*\
 $SDIR/com.ubuntu.pkexec.synaptic.policy\
 $SDIR/org.freedesktop.timedate1.policy
do
  df=`basename $sf`
  sudo sed "s/<allow_active>auth_admin/<allow_active>auth_self/g" $sf >$TDIR/$df
done

sudo /bin/mv $TDIR/* $DDIR/.
rmdir $TDIR

THREE

The ArchWiki source above speaks of their package called polkit-explorer, a GUI to the whole thing. That seems like a better idea than this kind of mucking around. Given how structured those files are and that this need exists, it should not be too great a hurdle to port / do the same.

FOUR

It would also be useful to look at how /usr/share/polkit-1/rules.d/ is used.

---

8-)
John

[Head_on_a_Stick]

... The ability of updating for a regular user is interesting, but mostly for the web browsers, openoffice, the security patches, etc ... but not recommended for a grub update, or a kernel update for example.

Debian buster has unattended-upgrades enabled by default so I'm not sure if that's true.

FWIW our family laptop runs Debian stable with unattended-upgrades enabled for all the repositories and it's been fine for several years now, including many kernel & GRUB updates.

But perhaps things would be different under MX.

[asqwerth]

Debian buster has unattended-upgrades enabled by default so I'm not sure if that's true.

FWIW our family laptop runs Debian stable with unattended-upgrades enabled for all the repositories and it's been fine for several years now, including many kernel & GRUB updates.

But perhaps things would be different under MX.

Isn't Unattended Upgrades the setting in MX-Updater that manyroads and I mentioned? You can enable it in MX-Updater for your family's MX-installed computers.

[Head_on_a_Stick]

Isn't Unattended Upgrades the setting in MX-Updater that manyroads and I mentioned?

I'm not sure, does that setting install and configure the unattended-upgrades package?

You can enable it in MX-Updater for your family's MX-installed computers.

Erm, full disclosure: I don't use MX

I hope the community doesn't mind, I'm just here to help out where I can.

[oops]

... The ability of updating for a regular user is interesting, but mostly for the web browsers, openoffice, the security patches, etc ... but not recommended for a grub update, or a kernel update for example.

Debian buster has unattended-upgrades enabled by default so I'm not sure if that's true.

FWIW our family laptop runs Debian stable with unattended-upgrades enabled for all the repositories and it's been fine for several years now, including many kernel & GRUB updates.

But perhaps things would be different under MX.

Sometime, the systeme ask some questions (to keep or not the existing config, to install grub into MBR ou PBR etc) ... so cross the fingers, until now, the answers given by your family was always the good one. ;-)

In an other hand, for an update for some basic tools as regular user, the alternative is to use the appimages, flatpak ,etc ...

[manyroads]

[...]

Sometime, the systeme ask some questions (to keep or not the existing config, to install grub into MBR ou PBR etc) ... so cross the fingers, until now, the answers given by your family was always the good one. ;-)

[...]

Which is why I check things every 5+/- weeks. My recommendation to my father & sister is to just say 'yes'. I know Nancy Reagan is turning in her grave... but this has worked 100% so far for me.

[Head_on_a_Stick]

Sometime, the systeme ask some questions (to keep or not the existing config, to install grub into MBR ou PBR etc)

That doesn't happen in Debian stable, those questions would only be asked for an upgrade between releases.

@OP: sorry for the diversion.

[kmathern]

Isn't Unattended Upgrades the setting in MX-Updater that manyroads and I mentioned?

I'm not sure, does that setting install and configure the unattended-upgrades package?

Unattended-Upgrades is enabled/disabled by the 'Auto-update' setting in the MX Updater preferences dialog. (btw I'm not crazy about the 'Auto-update' name for that setting, I would have preferred to stick with the 'Unattended Upgrades' wording.).

Unattended-upgrades (the .deb package) is installed by default (the apt-notifier package has it as a dependency), but unattended-upgrades aren't enabled by default. The MX Updater preference enables (or disables) them. i.e. APT::Periodic::Unattended-Upgrade "1"; (enabled) / APT::Periodic::Unattended-Upgrade "0"; (disabled)

Sometime, the systeme ask some questions (to keep or not the existing config, to install grub into MBR ou PBR etc)

That doesn't happen in Debian stable, those questions would only be asked for an upgrade between releases.

@OP: sorry for the diversion.

As far as I know Unattended Upgrades will hold back upgrades if they would require answering config questions during the upgrade.

[Richard]

@HOAS,
Personally, I find your posts enlightening, in the main. You bring a point of view that helps keep us aligned with MX's focus on adapting and/or changing Debians defaults to this very useful result which I've been using since April 2014.

Stable, with backports, lots of time-saving utilities in the MXTools and the antiX/Refracta Snapshot plus all the antiX & MX improvements. All good stuff for lazy users who haven't the time or inclination to build their own.

It's been a few years since I used Debian, mainly testing in the past, as a daily ride, although I do take a look at new releases in Vbox. It is the base of the most useful distros I have used.

Thanks for your opinions.