[ Sorry for the delay. ]
* Olivier Thereaux <
[email protected]> [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 <
[email protected]> -
http://larve.net/people/hugo/
Me fail English? That's unpossible. -- Ralph Wiggum