Ship unattended-upgrades with BunsenLabs?

tknomanzr · 2017-08-23 19:27:55

brontosaurusrex wrote:

How is this for a short one, in tint2rc add

#-------------------------------------
# E = EXECP
execp = new
execp_centered = 0
execp_has_icon = 0
execp_command = aptitude search "~U" | wc -l
execp_interval = 3600
execp_font = cuprum 13
execp_font_color = #111111 100
execp_padding = 0 0 0
execp_tooltip = updates
execp_lclick_command = urxvt -e bash -c "sudo apt update && sudo apt dist-upgrade && sleep 5"

This looks like it would run silently, which would be ok. In this case, I would probably precede the command with system-cat so that the output is redirected to the journal and there is some kind of feedback somewhere on the execution of the script.

brontosaurusrex · 2017-08-23 19:43:03

It would need some polishing like
- apt version of that aptitude call (arh, i see apt list in your scripts now)
- show '-' when there is no data (hard one for one-liner)

Last edited by brontosaurusrex (2017-08-23 20:46:08)

tknomanzr · 2017-08-23 20:51:32

Yeah. One of the reasons I wrote this script up is a tad selfish. I intend to wrap all upgrades into a backup routine of some sort. If I do it with btrfs pools, and set it up correctly this time around, I can get some system restore type of functionality in my backups. So I would probably run the backups once a day or so and snapshot any upgrade or dist-upgrade. This other idea in the back of my mind really drove the creation of the script. For a stock BL install, though, perhaps simpler would be better.

brontosaurusrex · 2017-08-24 13:01:17

execp_command = apt list --upgradable | expr $(wc -l) - 1

worth testing or not, if not: something else?

So far it appears:
- It seems to work (mostly tested on various servers out of tint2 context)
- When no internet it will return 0 (same as no-upgrades-available = good enough for me)
- doesn't need sudo, which is a win
- it won't whine in tint2 context, so no stderr > dev/null redirection is neccesary (Also if 'apt list' decides to stop whining on some future upgrade, that will not affect functionality) < not sure if this is correct, test.
- p.s. Actually it will complain if execp_tooltip is not defined.
- undefined rclick is a good thing, it will reload the execp_command (there is no visible feedback in tint2 thought).

other

execp_tooltip = updates

Is not language independent.

Last edited by brontosaurusrex (2017-08-24 15:30:02)

damo · 2017-08-24 14:08:35

brontosaurusrex wrote:

execp_command = apt list --upgradable | expr $(wc -l) - 1
worth testing or not, if not: something else?
So far it appears:
- It seems to work (mostly tested on various servers out of tint2 context)
- When no internet it will return 0 (same as no-upgrades-available = good enough for me)
- doesn't need sudo, which is a win
- it won't whine in tint2 context, so no stderr > dev/null redirection is neccesary (Also if 'apt list' decides to stop whining on some future upgrade, that will not affect functionality)
other
execp_tooltip = updates
Is not language independent.

This ^ works for me in Tint2, and with the addition of enabling mouse-click update/upgrade...

# Exec
execp = new
execp_command = apt list --upgradable | expr $(wc -l) - 1
execp_has_icon = 0
execp_interval = 0
execp_centered = 1
execp_font = sans 9
execp_markup = 1
execp_font_color = #aaffaa 100
execp_padding = 2 0
execp_tooltip = Updates available
execp_lclick_command = x-terminal-emulator -e '/bin/bash -c "sudo apt-get update && sudo apt-get upgrade"'
execp_background_id = 0
execp_cache_icon = 1

This only runs once, when Tint2 starts, with "execp_interval = 0". Set it to whatever time interval (seconds) you want, eg once an hour with "execp_interval = 3600".

Last edited by damo (2017-08-24 14:26:51)

brontosaurusrex · 2017-08-24 14:57:42

@damo: That ' ' stuff doesn't work for me, this does

execp_lclick_command = x-terminal-emulator -e /bin/bash -c "sudo apt update && sudo apt dist-upgrade && sleep 5"

tint2 version 0.14-git20170602.b50f5ec (freshly compiled).

Last edited by brontosaurusrex (2017-08-24 15:25:26)

damo · 2017-08-24 16:02:35

^ Probably because I was using termite, with its idiosyncracies

brontosaurusrex · 2017-08-24 16:05:59

Ah right, so that fact basically disables the sneaky layer of abstraction brought by x-terminal-emulator?

Another thing, can anything be used to just delete/flush/print-nothing? (clear and reset = fail) Idea would be to display absolutely nothing until some updates are available.

This

apt list --upgradable | expr $(wc -l) - 1 || (echo " ")

fails as well.

Last edited by brontosaurusrex (2017-08-24 17:18:07)

tknomanzr · 2017-08-24 17:32:00

johnraff used tput clear to clear the screen in bl-welcome.

I like the simplicity of this. This looks to me like great defaults. Also, remember, prepending any command with systemd-cat will write the output to the systemd journal. I know we try to remain init agnostic, so that might not be the best for defaults but command output should be redirected somewhere, possibly .xsession-errors.

So perhaps a command like:

systemd-cat apt list --upgradable | expr $(wc -l) -1 || tput clear

might work?

I will reserve the script I built for integrating a backup strategy wrapped around upgrades and dist-upgrades, however, because I want to take snapshots prior to possible system damaging operations. This is probably not such a big deal for Stable but I track Sid a lot also and would like to have that framework built before my next Sid install.

p9000 · 2017-08-24 22:37:50

Don't know about systemd but normally you can use logger to write to the system log, and tee (or logger -s) if you want to also print to stdout (stderr). See http://man7.org/linux/man-pages/man1/logger.1.html

logger has been the standard way to write to the system log from scripts since 1992.

Last edited by p9000 (2017-08-24 22:45:24)

brontosaurusrex · 2017-08-25 09:53:03

Show absosmurfly nothing if there is no updates (to test), possibly ugly

execp_command = num=$(apt list --upgradable | expr $(wc -l) - 1); if [ $num != 0 ]; then echo "$num"; fi # < not working

The above didn't work for some reason, back to aptitude tests

execp_command = num=$(aptitude search "~U" | wc -l); if [ $num != 0 ]; then echo "$num"; fi

Last edited by brontosaurusrex (2017-08-26 09:18:39)

brontosaurusrex · 2017-08-26 10:48:07

In tint2 executor Is there a way to say: re-execute execp_command right after execp_anyclick_command were finished?

How is this with 'killall -SIGUSR1 tint2' event

#-------------------------------------
execp = new
execp_centered = 0
execp_has_icon = 0
execp_command = num=$(aptitude search "~U" | wc -l); if [ $num != 0 ]; then echo "$num"; fi
execp_interval = 3600
execp_font = cuprum 13
execp_font_color = #111111 100
execp_padding = 0 0 0
execp_tooltip = updates
execp_lclick_command = urxvt -e bash -c "sudo apt update && sudo apt dist-upgrade && killall -SIGUSR1 tint2 && sleep 5"

^behavior should be
- never show nothing if there is no aptitude in system
- show nothing if there are no updates
- show number of updates if there are some
- on lclick run update && reload tint2 (reloading the execp_command as well)

Last edited by brontosaurusrex (2017-08-26 11:59:28)

o9000 · 2017-08-26 14:54:52

brontosaurusrex wrote:

In tint2 executor Is there a way to say: re-execute execp_command right after execp_anyclick_command were finished?

No. But I could add that.

Restarting the panel is a bit brutal, and has side effects (order of task buttons or tray icons may end up different).

And I don't think it's the right way to solve this. What if the user updates manually. Then for up to an hour the info shown will be incorrect.

Alternatives:

1. Lower the interval to a small enough value. Say 1 minute or less.

2. Figure out how to react to package database changes, and use a continuous executor instead of an interval one. That means that your script will not exit, it will keep running. You must have an event loop and sleep from there; and also react to dpkg events from there.

Option 2 is the "right" way to do it.

I don't know how to react to apt/dpkg events. I'm sure that there are global post-installation hooks, a quick web search confirms this: https://unix.stackexchange.com/question … ke-success

brontosaurusrex · 2017-08-26 18:20:58

o9000 wrote:

2. Figure out how to react to package database changes, and use a continuous executor instead of an interval one. That means that your script will not exit, it will keep running. You must have an event loop and sleep from there; and also react to dpkg events from there.
I don't know how to react to apt/dpkg events. I'm sure that there are global post-installation hooks, a quick web search confirms this: https://unix.stackexchange.com/question … ke-success

Ok.

brontosaurusrex · 2017-08-26 20:14:54

How about an indirect spy (spying on /var/log/apt/history.log changes)

https://raw.githubusercontent.com/bront … bin/aptSpy

and in tint2

execp = new
execp_centered = 0
execp_has_icon = 0
execp_command = aptSpy
execp_continuous = 1
execp_font = cuprum 13
execp_font_color = #111111 100
execp_padding = 0 0 0
execp_tooltip = updates
execp_lclick_command = urxvt -e bash -c "sudo apt update && sudo apt dist-upgrade && sleep 5"

Possible points of failure:
- aptitude search "~U" # would behave
- that var/log file location may be fragile
- known unknowns, unknown unknowns ...

Good stuff:
- Not really tied to debian/apt, should be easy enough to change for some other system.

Last edited by brontosaurusrex (2017-08-27 06:06:21)

p9000 · 2017-08-26 22:54:04

I looked at how Ubuntu does it. It adds hooks: http://bazaar.launchpad.net/~ubuntu-cor … e-notifier

The scripts that are called are a bit convoluted, so I didn't dig deeper. Might be worth a look, since they might have hit unexpected problems that apply here too.

p9000 · 2017-08-26 23:33:33

Why not watch /var/log/dpkg.log?

brontosaurusrex · 2017-08-27 00:59:41

It fires 10 times on 'apt install pcmanfm' ( /var/log/dpkg.log that is), but I must assume there is more to it? Or should the script have some additional frequency limiter build in?

On a more pressing matters: Just noticed this will actually only update on first run (or if apt was run), i guess combo off

execp_interval = 3600
execp_continuous = 1

is not working as one would expect?

edit: Maybe fixed, inotifywait is now running in bg and some hardcoded interval in eternal loop.

Last edited by brontosaurusrex (2017-08-27 07:38:39)

tknomanzr · 2017-08-27 02:37:27

I don't have a lot of time at the moment to sit and code. I might tomorrow or Monday but this blog post looks like it might provide some useful information. First, we can setup apt where it will run apt update daily without the need for systemd files, like this:
In /etc/apt/apt.conf.d/10periodic, we make sure that the package index is updated daily by running apt-get update daily:

APT::Periodic::Update-Package-Lists "1";

Next, a package called apt-check will return output like this:

$ /usr/lib/update-notifier/apt-check --human-readable
7 packages can be updated.
0 updates are security updates.
$

Full Blog Post Here

The question then becomes one of...how do we display in tint2, given that we don't want it to display at all if no updates are available.? I used execp because I knew that I could get it working but we really need a notification in the system tray. This takes us back to the notification system johnraff mentioned. A systray icon that is only visible when updates are available and is clickable to perform the update/upgrade cycle would be perfect. I intend to look into setting up a notification system now.

I like my system but it does have some minor flaws such as I end up with an update notifier on all 3 of my monitors and it is always there regardless whether updates are available or not. Plus it has a sort of oddball dependency chain although I was happy to be able to reuse some BL scripting to set it up.

In an ideal world, I get an update notifier but am also able to integrate backup scripts into that process.

Last edited by tknomanzr (2017-08-27 02:39:06)

Sector11 · 2017-08-27 02:52:19

apt-check?

#41 2017-08-23 19:27:55

Re: Ship unattended-upgrades with BunsenLabs?

#42 2017-08-23 19:43:03

Re: Ship unattended-upgrades with BunsenLabs?

#43 2017-08-23 20:51:32

Re: Ship unattended-upgrades with BunsenLabs?

#44 2017-08-24 13:01:17

Re: Ship unattended-upgrades with BunsenLabs?

#45 2017-08-24 14:08:35

Re: Ship unattended-upgrades with BunsenLabs?

#46 2017-08-24 14:57:42

Re: Ship unattended-upgrades with BunsenLabs?

#47 2017-08-24 16:02:35

Re: Ship unattended-upgrades with BunsenLabs?

#48 2017-08-24 16:05:59

Re: Ship unattended-upgrades with BunsenLabs?

#49 2017-08-24 17:32:00

Re: Ship unattended-upgrades with BunsenLabs?

#50 2017-08-24 22:37:50

Re: Ship unattended-upgrades with BunsenLabs?

#51 2017-08-25 09:53:03

Re: Ship unattended-upgrades with BunsenLabs?

#52 2017-08-26 10:48:07

Re: Ship unattended-upgrades with BunsenLabs?

#53 2017-08-26 14:54:52

Re: Ship unattended-upgrades with BunsenLabs?

#54 2017-08-26 18:20:58

Re: Ship unattended-upgrades with BunsenLabs?

#55 2017-08-26 20:14:54

Re: Ship unattended-upgrades with BunsenLabs?

#56 2017-08-26 22:54:04

Re: Ship unattended-upgrades with BunsenLabs?

#57 2017-08-26 23:33:33

Re: Ship unattended-upgrades with BunsenLabs?

#58 2017-08-27 00:59:41

Re: Ship unattended-upgrades with BunsenLabs?

#59 2017-08-27 02:37:27

Re: Ship unattended-upgrades with BunsenLabs?

#60 2017-08-27 02:52:19

Re: Ship unattended-upgrades with BunsenLabs?

Board footer