Re: Comparing update systems
- From: Günther Schwarz <strap@xxxxxx>
- Date: Tue, 01 Jul 2008 21:31:44 +0200
houghi wrote:
Günther Schwarz wrote:
The reason this is done is it might leave your system unworkable,
because you will need to reboot. Not an option for a server when
that happens on a saturday evening and everybody is out.
But it should be left to my decision and responsibility. That said up
to now I never had a system in an inoperative state after a kernel
update, so knock on wood. But then I do not do automatic updates on
the machine that offers the vital services like LDAP and mail.
OK, so you do it manualy. Then for those machines you won't be using
cron-apt.
It can be configured no to do kernel updates automatically. But the
system is question is not a Debian one, so this does not apply anyways.
The thing I run with is:
zypper --quiet up -y -t patch --skip-interactive
That way it won't install anything that asks for a license or a
reboot.
And I will never get new kernel versions or Acrobat Reader without
having a close look at the updates and what was skipped.
Not sure about acrobate reader with the update. The kernel indeed not.
I am confused as to what you want exactly. You run cron-tab at certain
times (say at night) and then what happens?
It checks for updates at the repositories, downloads and installs them.
There is no magic involved. It just works nicer than the tools I have
at hand with SuSE.
Yes, it uses the apt-get command which then calls the dpkg package
handler.
I looked a bit at the source and it is basicaly just a script that
runs apt-get if I am not mistaken. Just like you can make a script
that does about the same for zypper with very little effort.
Well, the difference is that cron-apt is available in the first place.
So I do not have any work to do myself other than a little
configuration.
Make one script that does that for you. Indeed it is expected that
you just use that you need. With what you are running, I am sure you
know how to put together a bash script that is able to do this for
you.
Yes, of course. I did this for smart and it works just fine. But a
script that parses the zypper output correctly will be lengthy and
cumbersome to write up for the reason I mentioned previously.
No, it won't. I might not be as easy as one would like, but it is very
doable. Depending on what you want, you can easily do it in a few
lines. The sample output of the latest I recieved:
From: root@xxxxxxxxxxxx
To: root@xxxxxxxxxxxx
Subject: Cron <root@penne> zypper --quiet up -y -t patch
--skip-interactive
From root@xxxxxxxxxxxx Mon Jun 30 04:43:45 2008
The following packages are going to be upgraded:
php5-iconv php5-pdo php5-dom php5-hash apache2-mod_php5
php5-xmlwriter php5-mysql php5-json php5-ctype
php5-xmlreader php5 php5-tokenizer php5-sqlite
The following NEW patch is going to be installed:
apache2-mod_php5
^[[2K^MContinue? [YES/no]: yes
Yes, the last line is ugly and all the filenames are in one line.
Filter out the Coninue line and you are about done if that is so
upsetting for you. All in all I am pretty happy with the information.
It would be nice this way. But your example is with 11.0 obviously. The
10.3 systems here won't be retired until 2009, and I have to find a
solution for this. Otherwise they do run nicely, so I have no intention
to go to kernel 2.6.25 anytime soon. It is either parsing the nasty
output to a readable form or switching to smart like I already did with
10.2 where zypper has proven to be plain horror. I would like to stay
with the default updater, so I'm working now on the parsing problem.
This is what I am complaining about. Zypper obviously is not intended
for use other than a simple and isolated desktop system. Otherwise
the developers would have thought about how to make it managable and
usable in a networked environment. No one has time to write scripts
for simple desktop systems these days.
In what way is cron-apt intended for anything else, because from what
I have seen, all it does is run apt-get on the machine it is
installed. http://packages.debian.org/sid/cron-apt
Contains a tool that is run by a cron job at regular intervals. By
default it just updates the package list and download new packages
without installing. You can instruct it to run anything that you can
do with apt-get (or aptitude).
I have seen nothing that makes it any better in what is already
possible.
As I said there is nothing special about it: it simply works without
annoying bugs and is easy to configure. That makes it superior to a
tool that is still buggy and harder to work with. But I'm repeating
myself here.
Leaving the bugs aside the main difference here is that the person
who wrote the cron-apt package had networked environments in mind and
thought about a way to do things in a convenient way on these.
I am sorry, I fail to see where is does anything that would relate to
a networked enviroment.
Think of a small system with several servers and PCs which share big
parts of their configuration. Maintenance work has to be restricted to
the absolute minimum possible without compromising security and
availability. Automatic updates are vital for such a system as is a
configuration tool like cfengine.
At SuSE
people were thinking of isolated desktop systems (zypper) or
heterogenous environments (rug) obviously. One results in a focus on
tray bar icons and a colorful interface while the other becomes
interesting only in big networks running Novell's server software.
That part about the GUI is bull and you know it.
No, it is not ;-) The default installation results in a GUI updater that
pops up a window if updates are available while the CLI tool for
automatic updates is buggy (which might have been fixed in the most
recent release).
We were talking about
zypper and CLI all the time. Yes, the GUI is an importand part for
openSUSE, because that is what many people now want. It however has
nothing to do with what we are talking about.
It has, as time spent on making a system user-friendly for the isolated
desktop easily results in time missing for development and testing of
tools and procedures to do remote administration. This is basically
what I'm complaining about.
Another point is that cron-apt and apt-get are set up in the
traditional UNIX way were everything is configured via ASCII text
files. The SuSE tools are more 'modern' and abstract from the OS with
configuration in databases. This can result in better performance and
give the possibility to write platform-independent tools.
So this is good, right?
This is interesting if a company wants to write software for mixed
environments. But it is also challenging and might result in more
complex software with questionable benefits.
Rug is even a .NET application that runs in a mono environment and is
obviously intended as a replacement for the Microsoft updater on
Windows clients.
No idea. I do not know anything about Microsoft. The automatic updater
has been a part of the distro since forever. What they have done is
put YOU and Redcarpet together and out came rug/zypper/libzypp
So no, it was not intended as a replacement for the windows updater.
This applies to rug only. See
<http://www.novell.com/documentation/zenworks7/index_ptm.html>
<http://www.novell.com/documentation/zenworks7/pdfdoc/ptm7install/ptm7ainstall.pdf>
(Well, this is not about rug exactly, but about the full Zenworks Patch
Management which is supposed to work with about any OS known to mankind
and where rug is one part of.)
As a result both are much less flexible and harder to handle for a
sysadmin who is used to work the old UNIX way.
That is the fault of the sysadmin, not of the tool.
Editing files is much simpler and safer than using scripts which call
complex commands like zypper or rug.
Why would it be safer? Simpler? No.
Oh yes, it is. Show me a complete list of possible outputs of these two
commands. This does not exist. It is a try and error procedure to get a
working script that does automatic updates with these commands and
informs the sysadmin what has been done in a comprehensive an reliable
way.
Günther
.
- Follow-Ups:
- Re: Comparing update systems
- From: houghi
- Re: Comparing update systems
- References:
- Re: Comparing update systems
- From: houghi
- Re: Comparing update systems
- Prev by Date: Re: Xen kernel work with KDE?
- Next by Date: S3 Unichrome Pro 11.0 gets it wrong everytime!
- Previous by thread: Re: Comparing update systems
- Next by thread: Re: Comparing update systems
- Index(es):
Relevant Pages
|
