[Gllug] CentOS and RHES

[Karanbir Singh]

Hi Jason,

Firstly, before I get into the email I want to make one thing clear - I 
am not doubting you had a problem ( as Martin's email seems to indicate )

Jason Clifford wrote:
> Indeed and he had been warned - in fact he'd be told to use Debian as even 
> if you do have cron run apt-get update every day the same problem would 
> not have arisen.

I still have no idea as to what broke on the machine  ? do you have some 
bugzilla numbers ? Would really appreciate some info on the problem on 
the machine itself, that way atleast someon can try to get to the bottom 
of this.

>>the mirror.centos.org network was all updated at the time - but was 
>>running slow ( we were pretty much maxing out on the networks that we 
>>have access to ), most of the major external mirrors were also updated, 
>>while there were indeed some third party mirrors that were out of sync - 
>>it should not effect yum's running.
> 
> 
> That is simply not true.

Can you give me the server names you were looking at ? I'd be happy to 
look through the rsync logs to check what time they picked up the 
/centos/4*/ tree's.

> I checked the mirrors yum was trying using a web client and, where 
> possible FTP. In the case of two of those which mirror.centos.org pointed 
> to 4.2 was simply not on the server at all. These were the servers yum was 
> trying on. It was not a matter of yum suffering a time out it was a matter 
> of the necessary files not being on the servers yum was connecting to.

If you look at how yum works, and how the $releasever is calculated, you 
will find its not centos/4.2/os/ its looking at but centos/4/os/ !!!! at 
release time all machines had a valid /4/ repository structure. So what 
exactly were you looking for on the 4.2 symlink ?

If that client has mod'ed up the yum config's himself/herself then would 
I be wrong in saying they should know what they are doing ?

Also, mirror.centos.org has NO ftp access, so once again , where were 
you looking ?

>>If you notice, the pkg update process is only run after the pkgs have 
>>been downloaded. If there is a checksum error, there is a pkg missing or 
>>the repository metadata does not match the pkg tree on the mirror - yum 
>>will error out and not run the update.
> 
> 
> Yum errors out with errors that do not reflect what actually went wrong. 

Can we be a bit more specific ? Errors due to 404's or metadata / pkg 
tree mismatch or unsigned pkgs etc should be quite clear. If things are 
really not user friendly, we should RFE's the issues and ask upstream to 
make ammends.

> I understand that yum is something added in by CentOS and isn't present 
> with RHEL so I'd hope you'd have checked this.

we did..

you can always use up2date if thats what you prefer, works fine in 
CentOS. And based on server logs, I can tell you that almost 80% of 
users on Desktop / Workstations running CentOS use the Gnome-rhn-applet 
and up2date to do their pkg management. I base my estimate on Desktop / 
Workstation users by the number of people who pull the FireFox.Arch pkg, 
which might not really be completely accurate, but should give us a fair 
idea.

Then there is always aptrpm :) But that only works with singlearch tree's.

>>btw, you said - something broke... what was it that broke ?
> As above - the necessary files for version 4.2 were simply not present on 
> some of the machines pointed to by mirror.centos.org.

I was actually wanting to know what broke on your machine due to this 
issue ....

> Even better you could seek to amend yum so that version upgrades don't 
> happen as the result of a simple "yum update" without gaining specific 
> consent from the operator of the system. Version upgrades are significant 
> events - particularly on an Enterprise system - and should always require 
> the operator of the system to give prior consideration to major changes.

errr.. 4.2 is not a Version update. its just EL4 with Update2 rolled in. 
Exactly how RHEL works ( they call it 4U2 ). Redhat document the 
Quarterly(ish) update policy on their website, maybe you could scan 
through that for more info on exactly how this works.

A move from CentOS3 to CentOS4 might be considered a version upgrade.

> What was not acceptable was that the new version was released without 
> having care that the official mirrors (ie those that you publish as 
> mirror.centos.org) actually had it on them. For the sake of a couple of 

the 7 machines that picked up the load for mirror.centos.org at time of 
release ( for http traffic ) had the 4.2 tree on there, the first 
rsync's started off

> hours waiting to rsync the servers you could have avoided the problem but 
> as the CentOS team decided to move ahead before things were ready users 
> ended up suffering up to 2 days of problems.

The 4.2 pkg tree is 24.2GB, and was on the 7 machines that picked up 
mirror.centos.org traffic at release time, it was also on some of the 
major mirrors ( eg. kernel.org and centos.crazyfrogs.org ).

I wonder if there was a caching proxy sitting between that machine and 
the internet causing issues ? (just a guess.. )

>><plug>CentOS is a community oriented setup, we all put in our time, 
>>efforts and resources into building it and on occasion we even put in 
>>money from our own pockets to meet the costs associated. We need 
>>mirrors, why dont you help us spread the load and setup a mirror on a 
>>fast pipe to help everyone out a bit ? Specially if you are an ISP or 
>>sell services based on / around CentOS.</plug>
> 
> 
> UKFSN dosn't operate mirrors as out position as a small ISP is to provide 
> good quality services to our customers.

Fair enough, I personally appreciate your supporting customers who in 
turn run CentOS. The reason for me to put that in there was for everyone 
on the list - I am sure there are a few people here, sitting on fat 
pipes that could help on the mirror front.

> I hope that my concerns will be addressed and that this wont happen again 
> - I'd rather like to see CentOS succeed in the long term and Red Hat needs 
> there to be a good community base for the RHEL products and Fedora isn't 
> it.

I hope we are able to better meet your expectations when 4.3 comes 
around! But when things break, please file bugzilla's just so that we 
have something to work with.

- K

PS: are we straying OT here ?
-- 
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug