Hi Jaroslaw, > Hi > > > Just to add my 2 cents here. I don't need repo preference. I resolved this > > issue by disabling all but base repo's, then scripting the packages I want to > > be notified on (and upgrade to) per repo, then croning updates based on the > > "--enablerepo=" option in yum. > > Yes , that is an option: but you mostly use it on the > systems you manage yourself, right ? Yes. > At CERN we have about 1500 systems managed by individual > owners/users .. so we really need a solution which will > not require all of them writing / editing scripts .. Are these systems all pretty much identical to the packages that need to be checked on them? or do the owners/users have root privilege to install/modify whatever they want on the systems? I use another product (csync2) to help me manage large nodes of clusters, where I group "like" systems. My yum scripts can be easily extended to work on hundreds of nodes using csync2 to synchonise yum check scripts ie. using csync2, you could easily have multiple "yum.check.atrpms.server1.sh, yum.check.atrpms.server2.sh" scripts distributed to hundreds of nodes, managed from one main server and distributed automatically to groups of nodes, while those scripts are cron'ed on each of the nodes to check a central repo/mirror. As an admin, I like the control this gives me, as I can manage everything from a central server. > So far we were working with apt using repository > preference and ability to 'pin' (=lock) package versions. > (plus ability of LUA scripting for kernel modules upgrades) > > For me, it looks like combination of yum protectbase, > versionlock and kernel-module plugins > (plus few more yum-utils like build-dep and sourcedownload) > would allow us to achieve similar result with yum. The thing I don't like about automatic things is that implementations on servers become too messy over time. It becomes very hard to keep track of what packages are installed and especially keeping track of the dependencies those packages installed. The administrative overhead may be a little more, but in the long run I believe it reduces problems which occur on systems after they've been in the wild for some years. > [FYI: As apt for rpm is not being developped > anymore for future versions of Scientific Linux CERN > we are looking at replacing our default update mechanism > by a yum based one.] > > Regards > > Jarek > > PS: Maybe you could contribute your scripts to SL ? Yeah, I'm happy to do this. About a month and a half ago I was speaking with Troy about it, as I have implementations for Fedora Core releases and SL4 releases. The Fedora Core scripts are all in-house and specific to those releases (so not much help to the SL community), while the SL scripts extend Troy's scripts to allow an admin to manage "repo.package" files which are called from the main check script. So the end result is an email to the admin of all the packages updated per checked repo, in one nicely formatted email. The admin then has the choice whether to update them or not. The last we spoke about this I told Troy I'd clean up the scripts a little more then send them all to him (I need to make them more generic for the public - like a template file - and not specific to my setup for example). But I've been tied up with cluster work since then, which should be finished by next week. After that, I'll relook at the scripts, clean them up (for public release) and send them to Troy. From there, it's up to him what he does with them :) Michael.