[Gllug] CentOS and RHES

[Jason Clifford]

On Mon, 24 Oct 2005, Karanbir Singh wrote:

> depending on what you are doing on that machine, its usually a bad idea 
> - since there is no way you can regulate whats going in. Sounds like a 
> bad move by the client, and he got what he was asking for.

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.

> 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.

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 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. 
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.

> 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.

> Also, what were you trying to do to 'verify that the update had run 
> through' ?

Running "yum update". That gave misleading error messages indicating a 
local problem however I ran it with debugging set and then saw the problem 
was remote.

>  > This wasn't a problem with the distro but rather a reflection of the
>  > fact that CentOS doesn't have competent release management and the
>  > team don't understand online distribution issues.
> 
> We are open to suggestions, please feel free to step forwand and 
> recommend ways in which to better manage the release. I think we did an 
> outstanding job, given the circumstances.

I don't. The simplest and most obvious step would be to ensure that all 
machines pointed to by mirrors.centos.org had completed the rsync prior to 
telling yum to make a version upgrade.

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.

> I am not sure what your point is - on one hand you are saying that we 
> should have held the release back while the mirrors were updated, and 
> now you are saying that when you were asked to wait for a day, it is 
> 'not acceptable' ????

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 
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.

For an enterprise OS that is simply not good enough. The fact that you are 
a community distro doesn't excuse this - in fact it makes matters worse as 
it strongly gives the impression that the community isn't capable of doing 
such things properly.

> <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>

I don't sell services on or around CentOS.

UKFSN dosn't operate mirrors as out position as a small ISP is to provide 
good quality services to our customers.

Mirroring distro's requires a commitment from both the mirror operator and 
the distro maintainers that I am not willing to give and, given the 
response I've seen including denials that indicate either that you did not 
even know the state of your official mirror network or that I have 
received two responses from CentOS people which fell short of the truth, I 
don't feel very confident in the CentOS team on this score.

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.

Jason Clifford
-- 
UKFSN.ORG		     Finance Free Software while you surf the 'net
http://www.ukfsn.org/	       2Mb ADSL Broadband from just £14 149month 
http://www.linuxadsl.co.uk/	     ADSL Routers from just £21.98

-- 
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug