Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #227277 > unrolled thread

notify via virtual terminal available packages

Back to article view | Back to linux.debian.user

Contents

  notify via virtual terminal available packages Pòl Hallen <deben@fuckaround.org> - 2020-09-23 22:50 +0200
    Re: notify via virtual terminal available packages john doe <johndoe65534@mail.com> - 2020-09-24 10:40 +0200
    Re: notify via virtual terminal available packages Charles Curley <charlescurley@charlescurley.com> - 2020-09-24 15:50 +0200
      Re: notify via virtual terminal available packages Greg Wooledge <wooledg@eeg.ccf.org> - 2020-09-24 16:00 +0200
        Re: notify via virtual terminal available packages Greg Wooledge <wooledg@eeg.ccf.org> - 2020-09-24 16:40 +0200
          Re: notify via virtual terminal available packages Charles Curley <charlescurley@charlescurley.com> - 2020-09-24 16:50 +0200
            Re: notify via virtual terminal available packages Greg Wooledge <wooledg@eeg.ccf.org> - 2020-09-24 17:00 +0200
            Deterministic delays in POSIX shell scripts (Was: Re: notify via  virtual terminal available packages) Andy Smith <andy@strugglers.net> - 2020-09-25 09:50 +0200
              Re: Deterministic delays in POSIX shell scripts (Was: Re: notify via  virtual terminal available packages) Greg Wooledge <wooledg@eeg.ccf.org> - 2020-09-25 13:50 +0200
                Re: Deterministic delays in POSIX shell scripts (Was: Re: notify via  virtual terminal available packages) Andy Smith <andy@strugglers.net> - 2020-09-25 14:30 +0200
                  Re: Deterministic delays in POSIX shell scripts (Was: Re: notify via  virtual terminal available packages) David Wright <deblis@lionunicorn.co.uk> - 2020-09-26 04:50 +0200
        Re: notify via virtual terminal available packages Charles Curley <charlescurley@charlescurley.com> - 2020-09-24 16:40 +0200

#227277 — notify via virtual terminal available packages

Hi :-)
like ubuntu, what's the best way to show a notify alert (via terminal) 
about available packages?

thanks! :)

-- 
Pol

[toc] | [next] | [standalone]

#227284

On 9/23/2020 10:36 PM, Pòl Hallen wrote:
> Hi :-)
> like ubuntu, what's the best way to show a notify alert (via terminal)
> about available packages?
>

I can't talk about Ubuntu but you could use a cronjob that checks
periodicly for new updates and use 'wall' to notify the users.

--
John Doe

[toc] | [prev] | [next] | [standalone]

#227291

On Wed, 23 Sep 2020 22:36:36 +0200
Pòl Hallen <deben@fuckaround.org> wrote:

> like ubuntu, what's the best way to show a notify alert (via
> terminal) about available packages?

I take it you mean, *new* available packages. I don't know how Ubuntu
does it, so I'll tell you what I do. And the answer depends on what you
want to do.

You could install unattended-upgrades, and let that notify you (via
email) of packages it has already upgraded for you and the occasional
reboot required.

If that's a bit too trusting, set a cron job to pull in new packages,
but not install them. I use:

   5      3      *                *	*	root	sleep $( echo $((1 + RANDOM \% 1200)) ) ; /usr/bin/apt-get update > /dev/null && /usr/bin/apt-get -dy dist-upgrade > /dev/null

The sleep command waits for up to 1200 seconds. That is there because I
have a small herd of computers here and way back when I was on dial-up
I did not want to swamp my connection.

The apt-get update does an update, and throws away the output.

Same with the dist-upgrade. The -d does a download only.

You could follow that with "apt list --upgradable -a" so cron will
email you a list of available upgrades. Or you could run that manually
when you are ready. I just run "apt upgrade" when I am ready. As I
mentioned, I have a small herd of computers. I run a shell script based
on mssh to check all of them for updates.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

[toc] | [prev] | [next] | [standalone]

#227292

On Thu, Sep 24, 2020 at 07:23:28AM -0600, Charles Curley wrote:
>    5      3      *                *	*	root	sleep $( echo $((1 + RANDOM \% 1200)) ) ; /usr/bin/apt-get update > /dev/null && /usr/bin/apt-get -dy dist-upgrade > /dev/null

RANDOM is a bashism, not available in sh, so that won't work in a
crontab unless you've altered which shell cron is using to parse the
crontab.

If you *do* use bash to parse the line, then the $( echo ... ) bit is
unnecessary.

sleep $((1 + RANDOM \% 1200))

But the safer way is simply to assume that the crontab is being parsed by
sh (because that's what is actually used by default), and move your
bash-specific code to a script.  Then call the script from the crontab.

[toc] | [prev] | [next] | [standalone]

#227296

On Thu, Sep 24, 2020 at 08:10:04AM -0600, Charles Curley wrote:
> On Thu, 24 Sep 2020 09:53:59 -0400
> Greg Wooledge <wooledg@eeg.ccf.org> wrote:
> 
> > RANDOM is a bashism, not available in sh, so that won't work in a
> > crontab unless you've altered which shell cron is using to parse the
> > crontab.
> 
> Well, that's interesting. The file I pulled that from (in /etc/cron.d)
> sets two variables explicitly:
> 
> SHELL=/bin/sh
> PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
> 
> And the machine that it runs on shows:
> 
> root@hawk:~# ll /bin/sh
> lrwxrwxrwx 1 root root 4 Jan 17  2019 /bin/sh -> dash*

In dash, RANDOM does nothing; it's just an empty variable.  And as it
turns out, dash treats that as a zero.

unicorn:~$ dash
$ echo $((1 + RANDOM % 1200))
1
$ echo $((1 + % 1200))
dash: 2: arithmetic expression: expecting primary: "1 + % 1200"
$ echo $((1 + XYZZY % 1200))
1

So you're just doing "sleep 1" every time.

[toc] | [prev] | [next] | [standalone]

#227298

On Thu, 24 Sep 2020 10:38:55 -0400
Greg Wooledge <wooledg@eeg.ccf.org> wrote:

> In dash, RANDOM does nothing; it's just an empty variable.  And as it
> turns out, dash treats that as a zero.
> 
> unicorn:~$ dash
> $ echo $((1 + RANDOM % 1200))
> 1
> $ echo $((1 + % 1200))
> dash: 2: arithmetic expression: expecting primary: "1 + % 1200"
> $ echo $((1 + XYZZY % 1200))
> 1
> 
> So you're just doing "sleep 1" every time.

Ah, thank you. Yup. Which is weird, because it worked when I first
wrote that many years ago. I may or may not remove that part of the
line. But I will move toward more use of unattended-upgrades, which
handles the original problem differently.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

[toc] | [prev] | [next] | [standalone]

#227299

On Thu, Sep 24, 2020 at 08:49:07AM -0600, Charles Curley wrote:
> Ah, thank you. Yup. Which is weird, because it worked when I first
> wrote that many years ago.

"Many years ago", sh was probably a link to bash, rather than dash.

[toc] | [prev] | [next] | [standalone]

#227322 — Deterministic delays in POSIX shell scripts (Was: Re: notify via virtual terminal available packages)

Hello,

On Thu, Sep 24, 2020 at 08:49:07AM -0600, Charles Curley wrote:
> On Thu, 24 Sep 2020 10:38:55 -0400
> Greg Wooledge <wooledg@eeg.ccf.org> wrote:
> > So you're just doing "sleep 1" every time.
> 
> Ah, thank you. Yup. Which is weird, because it worked when I first
> wrote that many years ago.

In cron scripts where I want a "random" delay, I actually tend to
not really want it to be random, but just different for that host as
opposed to other hosts, otherwise deterministic. I like it if the
delay is the same every time on that host as long as it is a
different delay on different hosts.

So what I tend to do is something like:

    sleep $(( $(printf %d "0x$(hostid)") % 60 ))m; /some/command

which will sleep for some amount of time between 0 and 59 minutes,
the same amount every time, but different on different hosts.

(Obviously change the "60" and the "m" to different values for
different things, like you might want "1440" and "m" for minutes in
a day.)

Note that in a file parsed by cron you do need to escape both the
'%' (like '\%').

The printf is needed to turn the hexadecimal value from the "hostid"
command into a decimal number. Is there a way to do that with pure
shell internals that isn't very verbose?

"hostid" tends to return a hexadecimal representation of the first
IPv4 address (but isn't guaranteed to). On a systemd system one
could instead use /etc/machine-id. On Linux there is also
/proc/sys/kernel/random/boot_id (but needs dashes removed).

Systemd timers can do this sort of thing themselves, so no need
there for this sort of scripting.

> But I will move toward more use of unattended-upgrades, which
> handles the original problem differently.

Yup, I use apticron and unattended-upgrades for solving these
problems these days.

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

Please consider the environment before reading this e-mail.
 — John Levine

[toc] | [prev] | [next] | [standalone]

#227332 — Re: Deterministic delays in POSIX shell scripts (Was: Re: notify via virtual terminal available packages)

On Fri, Sep 25, 2020 at 07:44:25AM +0000, Andy Smith wrote:
> "hostid" tends to return a hexadecimal representation of the first
> IPv4 address (but isn't guaranteed to).

unicorn:~$ hostid
007f0101

Doesn't look very useful.  That's just 127.0.1.1 in a 16-bit little
endian format.

> On a systemd system one
> could instead use /etc/machine-id. On Linux there is also
> /proc/sys/kernel/random/boot_id (but needs dashes removed).
> 
> Systemd timers can do this sort of thing themselves, so no need
> there for this sort of scripting.

You know what else works really well?  Just putting a different start
time in each system's crontab.

[toc] | [prev] | [next] | [standalone]

#227336 — Re: Deterministic delays in POSIX shell scripts (Was: Re: notify via virtual terminal available packages)

Hello,

On Fri, Sep 25, 2020 at 07:49:19AM -0400, Greg Wooledge wrote:
> On Fri, Sep 25, 2020 at 07:44:25AM +0000, Andy Smith wrote:
> > "hostid" tends to return a hexadecimal representation of the first
> > IPv4 address (but isn't guaranteed to).
> 
> unicorn:~$ hostid
> 007f0101
> 
> Doesn't look very useful.  That's just 127.0.1.1 in a 16-bit little
> endian format.

Oh, none of mine do that, it seems to pick the other IP address for
me. But if it's a problem there are other sources of "machine" ID as
I mentioned. There's some more here:

    http://0pointer.de/blog/projects/ids.html

> You know what else works really well?  Just putting a different start
> time in each system's crontab.

If that works for you, great, but I have quite a few machines, VMs
and containers provisioned identically and would rather not have to
change the scripts or configuration on a per-host basis.

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

[toc] | [prev] | [next] | [standalone]

#227378 — Re: Deterministic delays in POSIX shell scripts (Was: Re: notify via virtual terminal available packages)

On Fri 25 Sep 2020 at 12:28:31 (+0000), Andy Smith wrote:
> On Fri, Sep 25, 2020 at 07:49:19AM -0400, Greg Wooledge wrote:
> > On Fri, Sep 25, 2020 at 07:44:25AM +0000, Andy Smith wrote:
> > > "hostid" tends to return a hexadecimal representation of the first
> > > IPv4 address (but isn't guaranteed to).
> > 
> > unicorn:~$ hostid
> > 007f0101
> > 
> > Doesn't look very useful.  That's just 127.0.1.1 in a 16-bit little
> > endian format.
> 
> Oh, none of mine do that, it seems to pick the other IP address for
> me. But if it's a problem there are other sources of "machine" ID as
> I mentioned. There's some more here:
> 
>     http://0pointer.de/blog/projects/ids.html

IIRC Debian's recommendation is that a machine's own hosts entry
should be:

127.0.0.1       localhost
[…]
127.0.1.1       axis.corp       axis    # 192.168.1.14

(The comment at the end is there because I generate my hosts file
with a script that puts the 127.0.1.1 into place.)

That might explain the monotonous 007f0101. Perhaps you don't
set you hosts files that way.

> > You know what else works really well?  Just putting a different start
> > time in each system's crontab.
> 
> If that works for you, great, but I have quite a few machines, VMs
> and containers provisioned identically and would rather not have to
> change the scripts or configuration on a per-host basis.

I don't know what scaling you require, nor the time resolution you
can detect, but the last octet of the IPv4 address × 10 seconds
gives you delays of up to ~42 minutes, unique on what was once
called a "Class C" network. (15 seconds will go just over the hour.)

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#227297

On Thu, 24 Sep 2020 09:53:59 -0400
Greg Wooledge <wooledg@eeg.ccf.org> wrote:

> RANDOM is a bashism, not available in sh, so that won't work in a
> crontab unless you've altered which shell cron is using to parse the
> crontab.

Well, that's interesting. The file I pulled that from (in /etc/cron.d)
sets two variables explicitly:

SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

And the machine that it runs on shows:

root@hawk:~# ll /bin/sh
lrwxrwxrwx 1 root root 4 Jan 17  2019 /bin/sh -> dash*
root@hawk:~# ll /bin/dash 
-rwxr-xr-x 1 root root 121464 Jan 17  2019 /bin/dash*
root@hawk:~# file /bin/dash 
/bin/dash: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=486323dd0fe3ec5af388e4ea4217a1f0092961d2, stripped
root@hawk:~# 




-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web