On Thu, 2005-09-08 at 09:05, Karanbir Singh wrote:
> >
> > Local to what? The production boxes are distributed but have good
> > internet connectivity. The test box only has so-so internet
>
> local to your organisation. If you do have good connectivity, forking
> out for an extra role machine should not be an issue. I fail to see how
> bandwidth has anything to do with yum. no matter what package manager
> you use, you are going to need to pull down the same packages....
>
> Any system admin who needs such solid control on the package tree's will
> host his/her own repository of packages, sometimes even a bunch ( eg.
> based on intended system role ) and run an automated delivery mechanism.
But you wouldn't need that if the package manager could actually manage
packages.
> Also, are you saying that you admin a large number of machines, and dont
> actually test the packages before they are rolled out ?
I provide the QA people with a machine with the latest updates and when
they say everything works I try to duplicate those updates into the
production boxes. As you imply, this is something nearly everyone
has to do, so I find it surprising that the package management tools
don't give you a simple way to do it. Also note that there are as
many risks in waiting for testing and QA approval as not and you
have to balance them. For example, I'd probably roll out any available
update to openssh to internet exposed boxes as fast as possible since
that is extremely unlikely to affect our services and not doing it
invites a compromise. Besides, as the steady stream of security and
bugfix updates to a supposedly stable OS distribution demonstrates,
there will always be issues that you don't find until you have something
in real-world production. So, I consider the 'real' test to be the
first small set of of production boxes that are updated after QA's
blessing and watch for problems before rolling out to the rest.
> > connectivity. Isn't having to do that an admission that yum
> > doesn't really do a good job of managing the packages you
> > want on a box?
>
> there is yumlib, now available. Feel free to hack away.... A lot of the
> 'home grown' scripts that I have seen out there are screen-scrapers....
> which by default, are locked into the specific version/setup of yum
> anyway. Its stupid to think that those sort of scripts are ever going to
> maintain functionality across versions.
There is a basic concept missing to provide what you get by making
a snapshot of the repository. Consider the repository as a database
and then consider whether making a snapshot of an entire database
at every operation is the best way to get repeatable operations.
What it needs is for the repository index (only) to have the snapshot
operation after changes are complete so that no additions are considered
until the set is complete and you know all dependencies are available
and by keeping prior indexes and being able to specify something to
identify them in the update command you could precisely repeat the
set of changes that happened on a previous date. This presents a
small problem with mirror operations since you have to ensure that
all other files are present before the index is updated.
> > Actually I think some invocation of rpm -q will give a list
> > of installed packages that you can feed to yum to install on
>
> you mean something like
>
> rpm -qp *.rpm --qf "%{name}.%{arch} "
>
> which should give you a list of packages... easy to feed that to a yum
> install process...
I think that might be a reasonable starting point. But it doesn't solve
the problem of attempting updates as a repository is being modified.
You have to work around that even if you do your own snapshot copies.
> > another machine, but it is not at all intuitive. Don't the
> > people writing package management tools actually manage any
> > machines or understand that keeping them identical is
> > desirable?
>
> If a couple of hundred machines counts as 'machines', then yes - the
> people I know - working on these package management tools do indeed
> manage machines.
Do they do it by working around the package management tool's problems
with huge repository snapshots?
> perhaps, this conversation needs to move to the yum-devel list, where
> you can then recommend ways to make yum more user-friendly.
I've mentioned it on the RPM list and a yum developer responded, but I
don't think I got across how desirable it would be to have yum
operations be repeatable and reliable in spite of the inconsistencies
during repository updates. I think I need a better way to explain the
similarity to a CVS repository and the equivalent need to be able to
extract any consistent set of revisions.
--
Les Mikesell
lesmikesell@xxxxxxxxx
