Re: Auto-upgrade with Debian

Replies:

Parents:

Hey.

I had a look at the auto-upgrade script for debian, described in [1]
and [2] and have a few questions for the author(s), along with (humble)
proposals to improve it.

[1] http://impressive.net/archives/fogo/20001121225017.A31960@larve.net
[2] http://impressive.net/archives/fogo/20010312040537.E24079@impressive.net

The script is:

#######################################################################

#!/bin/sh

PATH=/usr/sbin:/sbin:/usr/bin:/bin

if [ ! "`apt-get -q update | grep ^Get`" ]
then
 exit 0
fi

# Packages updated: do an upgrade
apt-get upgrade -q -y | tac | sed '/^0 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded.$/,/^Reading Package Lists/d' | tac

#######################################################################



Question 1 is about the -y. I always wondered what happens when a
configuration file is about to be overriden. When running interactively,
I usually say "D" (diff) and have a look at what changes are made. The
problem is that no "default" behaviour is good, sometimes you need to
keep your version (when you've made a custom config), but sometimes you
need to accept the newer version (lack of backward-compatibility, not
frequent, but I saw that a couple of time, or just that you don't care,
in which case having the latest-default-version is good).

Hugo, you expressed this concern in you mail [1], too, and said "time
will tell". What did time tell, after all?

I just did a quick test, run apt-get -y dist-upgrade, knowing that it
would want to change /etc/ssh/sshd_config, and... it went interactive,
so I don't have the answer for a non-interactive  cron script.



Question 2 is about the choice of apt-get upgrade instead of
dist-upgrade. "If you are not familiar with debian", upgrade only
upgrades packages with new versions and no conflict, while dist-upgrade
tries to be smart and installs new packages if it can solve a conflict.

The main drawback, IMHO, of an auto-upgrade system, is that it makes you
confident and comfortable that "everything is fine, stuff are up to date
and worky", though some conflicts may prevent a package to be upgraded
for months. If you also do some upgrade by hand from time to time,
that's OK, but...

Therefore, I think it would be good to use dist-upgrade instead of
upgrade.



Question 3 : what about monitoring important packages? Inserting
something like:

apt-get -u -s dist-upgrade | grep -v ^Conf

or, if you prefer short cron messages:

apt-get -s dist-upgrade | grep ^Inst

and filter with a list of "crucial" stuff (ssh, libc6, a.s.o). Could be
cool, woundn't it?

Does the "tac/sed" stuff work? I tried, and it seems it doesn't.
An alternative to this would be to use the filter described above, and
trash every output but this and errors.



Question 4 : Why not add a apt-get clean at the end of the script?
Would save disk space...



Thoughts?


Oh, BTW, Gerald, could you subscribe me to the list? Thanks :)

--
Olivier

Re: Auto-upgrade with Debian

Replies:

  • None.

Parents:

[ Sorry for the delay. ]

* Olivier Thereaux <ot@zoy.org> [2001-07-05 14:07+0900]
> Question 1 is about the -y. I always wondered what happens when a
> configuration file is about to be overriden. When running interactively,
> I usually say "D" (diff) and have a look at what changes are made. The
> problem is that no "default" behaviour is good, sometimes you need to
> keep your version (when you've made a custom config), but sometimes you
> need to accept the newer version (lack of backward-compatibility, not
> frequent, but I saw that a couple of time, or just that you don't care,
> in which case having the latest-default-version is good).
>
> Hugo, you expressed this concern in you mail [1], too, and said "time
> will tell". What did time tell, after all?

I am not quite sure I must say. I had once my sshd down because it was
stuck with a question it could not answer. That was... annoying. ;-)

> Question 2 is about the choice of apt-get upgrade instead of
> dist-upgrade. "If you are not familiar with debian", upgrade only
> upgrades packages with new versions and no conflict, while dist-upgrade
> tries to be smart and installs new packages if it can solve a conflict.

The problem is that dist-upgrade installs automatically important
packages IIRC, that I might have deselected on purpose. For example,
on my wireless station, I don't have syslogd nor crond. ;-)

> The main drawback, IMHO, of an auto-upgrade system, is that it makes you
> confident and comfortable that "everything is fine, stuff are up to date
> and worky", though some conflicts may prevent a package to be upgraded
> for months. If you also do some upgrade by hand from time to time,
> that's OK, but...
>
> Therefore, I think it would be good to use dist-upgrade instead of
> upgrade.

On a normal server, without any weird configuration, probably.

> Question 3 : what about monitoring important packages? Inserting
> something like:
>
> apt-get -u -s dist-upgrade | grep -v ^Conf
>
> or, if you prefer short cron messages:
>
> apt-get -s dist-upgrade | grep ^Inst
>
> and filter with a list of "crucial" stuff (ssh, libc6, a.s.o). Could be
> cool, woundn't it?

That could work too. I am lazy though, and I must say that expect my
sshd problem once (that I solved with my SSL telnetd), I never had a
problem.

But yes, for critical machines with administrators doing their job
daily, using -s makes a lot of sense.

> Does the "tac/sed" stuff work? I tried, and it seems it doesn't.
> An alternative to this would be to use the filter described above, and
> trash every output but this and errors.

I think that refers to an improvement by Gerald. I will let him answer
that. ;-)

> Question 4 : Why not add a apt-get clean at the end of the script?
> Would save disk space...

I didn't know apt-get clean. ;-)

> Oh, BTW, Gerald, could you subscribe me to the list? Thanks :)

I am copying you on this in case it hasn't been done yet.

--
Hugo Haas <hugo@larve.net> - http://larve.net/people/hugo/
Me fail English? That's unpossible. -- Ralph Wiggum

HURL: fogo mailing list archives, maintained by Gerald Oskoboiny