This is a list of issues for discussion for CentOS-4. Most of it is based on my experience from building/maintaining CentOS-2 and observing CentOS-3. I have not seen the CentOS-4 beta yet so I don't know if any of this is already done. If these have been discussed on IRC then perhaps someone could produce a shot summary of the outcomes....?
* Just call it CentOS-4 not 4.1 etc. Too confusing and serves no real purpose
* All modified rpm should use mezzanine or equiv. This makes it easier to track changes, build updates and generate a report on what has changed.
* Modified rpm should have .c4.n added to the release - c4 = centos 4. (works well once the 4.1 is dropped) - .n = a number starting at 1. The spec only 0 does not scale if you need to make another spec only change. The changelog will tell you what has changed.
* Mission: To stay as close to RedHat as possible Issues: some things need to be modified to support this. For example the cpu/memory restrictions will be removed(like in CentOS-3). Given that we are doing this, should we also lift other artificial constraints like installing on i386?
If we start making changes, where do we draw the line? In CentOS-2 I have fixed some small 1 line bugs (mostly packaging issues) but this might be a contentious issue. What about a CentOS+ repo. for enhanced versions?
* Issue: should the distro be self hosting? I think as long as the requirements are available from the addon/extras repos. then I don't think this is needed out of the box. Obviously the build environment needs to be well documented and reproducible.
* Mission: Remove RedHat trademarks. Issues: should we replace all rh logos/icons or just the ones required by RedHat? I think if the file/words can be replaced then yes, but package names etc. should be left alone.
* Issue: yum Don't ever auto-modify yum.conf. Too confusing. Invent a system for selecting/allocating a mirror. Users should always use a 3rd party mirror and not the main caosity mirrors. Issue: every mirror has different paths. We need to clean up all the symlinks and multi versions on the mirrors. (We need someone in change of the mirrors)
* Issue: gpg key. This should be installed by default so the user does not have to find & import it. At a minimum it should be in /usr/share/doc/centos-release and work like a RedHat box.
* Issue: release QA Before public release, a QA procedure should make sure that there are no obvious problems (like the comps issue of 3.3).
* Idea: automatic patch building. It should be possible to build most patches without intervention. I don't know what the current systems in place are but if there were autobuilt unsigned patches available it would allow - testing of patches before they are 'officially' released - checking the progress if a patch
Using an automatic system to apply CentOS specific modifications means that in some cases, the CentOS specific changes can also be autoapplied and the package build.
Obviously before a package is officially released, someone needs to check that it is correct and works etc.
John.
John Newbigin wrote:
perhaps someone could produce a shot summary of the outcomes....?
or even a short one.
From: John Newbigin jn@it.swin.edu.au To: CentOS Users centos@caosity.org Subject: [Centos] Issues/thoughts re CentOS-4 Date: Tue, 14 Dec 2004 17:22:21 +1100
- Mission: To stay as close to RedHat as possible
Issues: some things need to be modified to support this. For example the cpu/memory restrictions will be removed(like in CentOS-3).
Could you please share more information about this? What cpu/memory restrictions are in Centos 3 which are not present in RHEL3 ? This is what I am trying to discover which RHEL version like AS, ES or WS is Centos based on. I was under impression after reading Centros website documents that Centos is designed to be an almost 100% RHEL clone minus the copyrighted Redhat logos.
If we start making changes, where do we draw the line? In CentOS-2 I have fixed some small 1 line bugs (mostly packaging issues) but this might be a contentious issue. What about a CentOS+ repo. for enhanced versions?
Yes please! Please keep Centos changes to RHEL SRPMS separate from RHEL clone packages.
- Issue: should the distro be self hosting? I think as long as the
requirements are available from the addon/extras repos. then I don't think this is needed out of the box. Obviously the build environment needs to be well documented and reproducible.
Do you get best RHEL clone packages from building on RHEL AS computer itself? If so then I believe that is what should be used to build Centos RPMS. Opinions?
- Mission: Remove RedHat trademarks.
Issues: should we replace all rh logos/icons or just the ones required by RedHat? I think if the file/words can be replaced then yes, but package names etc. should be left alone.
A nice mission would be to remain 100% RHEL compatible with just no Redhat copyright logos + references.
- Issue: gpg key.
This should be installed by default so the user does not have to find & import it. At a minimum it should be in /usr/share/doc/centos-release and work like a RedHat box.
This will be convenient!
- Issue: release QA
Before public release, a QA procedure should make sure that there are no obvious problems (like the comps issue of 3.3).
Ah also an good idea. Less bugs = more fun =)
- Idea: automatic patch building.
It should be possible to build most patches without intervention. I don't know what the current systems in place are but if there were autobuilt unsigned patches available it would allow
- testing of patches before they are 'officially' released
- checking the progress if a patch
What patches are added to RHEL SRPMS besides logo removals? This is the main reason why I am browsing Centos documents. I would like to use RHEL clone on which to install RHEL compatible certified software and hardware. If HP server is certified for RHEL AS then can I use with CEntos without headaches? Same with software also like from Veritas or Oracle. I am just giving examples ........ I dont use Oracle but just in case someone else does.
Many thanks to all. Max.
_________________________________________________________________ Take charge with a pop-up guard built on patented Microsoft® SmartScreen Technology http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI... Start enjoying all the benefits of MSN® Premium right now and get the first two months FREE*.
- Mission: To stay as close to RedHat as possible
Issues: some things need to be modified to support this. For example the cpu/memory restrictions will be removed(like in CentOS-3).
Could you please share more information about this? What cpu/memory restrictions are in Centos 3 which are not present in RHEL3 ? This is what I am trying to discover which RHEL version like AS, ES or WS is Centos based on. I was under impression after reading Centros website documents that Centos is designed to be an almost 100% RHEL clone minus the copyrighted Redhat logos.
It's the other way around. RHEL has restrictions on amount of memory and number of cpu's. Check http://www.redhat.com/software/rhel/comparison/
Andy
From: Andy Masiar amasiar@gmail.com Reply-To: Andy Masiar amasiar@gmail.com To: Max Beerli maxbeerli@hotmail.com CC: centos@caosity.org Subject: Re: [Centos] Issues/thoughts re CentOS-4 Date: Tue, 14 Dec 2004 09:45:17 -0500
- Mission: To stay as close to RedHat as possible
Issues: some things need to be modified to support this. For example
the
cpu/memory restrictions will be removed(like in CentOS-3).
Could you please share more information about this? What cpu/memory restrictions are in Centos 3 which are not present in RHEL3 ? This is
what I
am trying to discover which RHEL version like AS, ES or WS is Centos
based
on. I was under impression after reading Centros website documents that Centos is designed to be an almost 100% RHEL clone minus the copyrighted Redhat logos.
It's the other way around. RHEL has restrictions on amount of memory and number of cpu's. Check http://www.redhat.com/software/rhel/comparison/
But this is why I am asking which RHEL branch CEntos follows mainly because I had gone through Redhat comparison documentation. Is Centos 3.3 based on RHEL AS which has higher limits or RHEL ES which has lower ones. Is it possible to base it to RHEL AS? Is the SRPMS for RHEL built on a RHEL AS build computer to generate CEntos RPMS?
_________________________________________________________________ Take charge with a pop-up guard built on patented Microsoft® SmartScreen Technology http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI... Start enjoying all the benefits of MSN® Premium right now and get the first two months FREE*.
But this is why I am asking which RHEL branch CEntos follows mainly because I had gone through Redhat comparison documentation. Is Centos 3.3 based on RHEL AS which has higher limits or RHEL ES which has lower ones. Is it possible to base it to RHEL AS?
I don't think that the srpms packages make a distinction whether they belong to AS or ES. AFAIK theres only two or thee packages in AS that are not present in ES (clustering, HA)
I think that AS and ES distinction applies mostly to RedHat's support level and hardware limitations.
Is the SRPMS for RHEL built on a RHEL AS build computer to generate CEntos RPMS?
No idea. Would that make a difference?
Andy
On Tue, 2004-12-14 at 14:16 -0500, Andy Masiar wrote:
But this is why I am asking which RHEL branch CEntos follows mainly because I had gone through Redhat comparison documentation. Is Centos 3.3 based on RHEL AS which has higher limits or RHEL ES which has lower ones. Is it possible to base it to RHEL AS?
I don't think that the srpms packages make a distinction whether they belong to AS or ES. AFAIK theres only two or thee packages in AS that are not present in ES (clustering, HA)
Redhat adds artificial restraints to ES ... CentOS has all the RPMS (including those from the Extras disc). It is based on RHEL AS.
I think that AS and ES distinction applies mostly to RedHat's support level and hardware limitations.
Is the SRPMS for RHEL built on a RHEL AS build computer to generate CEntos RPMS?
No idea. Would that make a difference?
It makes no difference where you compile the files.
- Issue: yum
Don't ever auto-modify yum.conf. Too confusing. Invent a system for selecting/allocating a mirror. Users should always use a 3rd party mirror and not the main caosity mirrors. Issue: every mirror has different paths. We need to clean up all the symlinks and multi versions on the mirrors. (We need someone in change of the mirrors)
Why not to point "default" yum.conf to 3rd partymirrors
Something like below.
I let mirror.centos.org there because of statistics ... :-), but this setup makes it 1/10th of all downloads .... If you add more mirrors it will be less ...
(I forced failovermethod=roundrobin, but it is not necessary http://slovnik.seznam.cz/sl.fcgi?src_trg=en_cz&len=30&word=necessary%20steps
it is default) ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ [main] cachedir=/var/cache/yum debuglevel=2 logfile=/var/log/yum.log pkgpolicy=newest distroverpkg=redhat-release installonlypkgs=kernel kernel-smp kernel-hugemem kernel-enterprise kernel-debug kernel-unsupported kernel-smp-unsupported kernel-hugemem-unsupported tolerant=1 exactarch=1
[base] name=CentOS-$releasever - Base baseurl=http://mirror.centos.org/centos-3/$releasever/os/$basearch/ http://ftp.upce.cz/caos/centos-3/$releasever/os/$basearch/ http://caos.oregonstate.edu/centos-3/$releasever/os/$basearch/ ftp://sunsite.utk.edu/pub/linux/caos/centos-3/$releasever/os/$basearch/
http://mirror.cs.wisc.edu/pub/mirrors/linux/caosity.org/centos-3/$releasever...
ftp://ftp.sunsite.org.uk/sites/mirror.caosity.org/cAos/centos-3/$releasever/os/$basearch/ http://download.centos.ru/centos-3/$releasever/os/$basearch/
ftp://mirror.pacific.net.au/linux/cAos/centos-3/$releasever/os/$basearch/
http://public.planetmirror.com/pub/caosity/centos-3/$releasever/os/$basearch... ftp://ftp2.tnc.edu.tw/pub1/centos/centos-3/$releasever/os/$basearch/ gpgcheck=1 failovermethod=roundrobin
#released updates [update] name=CentOS-$releasever - Updates baseurl=http://mirror.centos.org/centos-3/$releasever/updates/$basearch/ http://ftp.upce.cz/caos/centos-3/$releasever/updates/$basearch/ http://caos.oregonstate.edu/centos-3/$releasever/updates/$basearch/
ftp://sunsite.utk.edu/pub/linux/caos/centos-3/$releasever/updates/$basearch/
http://mirror.cs.wisc.edu/pub/mirrors/linux/caosity.org/centos-3/$releasever...
ftp://ftp.sunsite.org.uk/sites/mirror.caosity.org/cAos/centos-3/$releasever/updates/$basearch/ http://download.centos.ru/centos-3/$releasever/updates/$basearch/
ftp://mirror.pacific.net.au/linux/cAos/centos-3/$releasever/updates/$basearch/
http://public.planetmirror.com/pub/caosity/centos-3/$releasever/updates/$bas...
ftp://ftp2.tnc.edu.tw/pub1/centos/centos-3/$releasever/updates/$basearch/ gpgcheck=1 failovermethod=roundrobin
#packages used/produced in the build but not released [addons] name=CentOS-$releasever - Addons baseurl=http://mirror.centos.org/centos-3/$releasever/addons/$basearch/ http://ftp.upce.cz/caos/centos-3/$releasever/addons/$basearch/ http://caos.oregonstate.edu/centos-3/$releasever/addons/$basearch/
ftp://sunsite.utk.edu/pub/linux/caos/centos-3/$releasever/addons/$basearch/
http://mirror.cs.wisc.edu/pub/mirrors/linux/caosity.org/centos-3/$releasever...
ftp://ftp.sunsite.org.uk/sites/mirror.caosity.org/cAos/centos-3/$releasever/addons/$basearch/ http://download.centos.ru/centos-3/$releasever/addons/$basearch/
ftp://mirror.pacific.net.au/linux/cAos/centos-3/$releasever/addons/$basearch/
http://public.planetmirror.com/pub/caosity/centos-3/$releasever/addons/$base... ftp://ftp2.tnc.edu.tw/pub1/centos/centos-3/$releasever/addons/$basearch/ gpgcheck=1 failovermethod=roundrobin
#additional packages that may be useful [extras] name=CentOS-$releasever - Extras baseurl=http://mirror.centos.org/centos-3/$releasever/extras/$basearch/ http://ftp.upce.cz/caos/centos-3/$releasever/extras/$basearch/ http://caos.oregonstate.edu/centos-3/$releasever/extras/$basearch/
ftp://sunsite.utk.edu/pub/linux/caos/centos-3/$releasever/extras/$basearch/
http://mirror.cs.wisc.edu/pub/mirrors/linux/caosity.org/centos-3/$releasever...
ftp://ftp.sunsite.org.uk/sites/mirror.caosity.org/cAos/centos-3/$releasever/extras/$basearch/ http://download.centos.ru/centos-3/$releasever/extras/$basearch/
ftp://mirror.pacific.net.au/linux/cAos/centos-3/$releasever/extras/$basearch/
http://public.planetmirror.com/pub/caosity/centos-3/$releasever/extras/$base... ftp://ftp2.tnc.edu.tw/pub1/centos/centos-3/$releasever/extras/$basearch/ gpgcheck=1 failovermethod=roundrobin
#packages in testing #[testing] #name=CentOS-$releasever - Testing #baseurl=http://mirror.centos.org/centos-3/$releasever/testing/$basearch/ # http://ftp.upce.cz/caos/centos-3/$releasever/testing/$basearch/ # http://caos.oregonstate.edu/centos-3/$releasever/testing/$basearch/ # ftp://sunsite.utk.edu/pub/linux/caos/centos-3/$releasever/testing/$basearch/ # http://mirror.cs.wisc.edu/pub/mirrors/linux/caosity.org/centos-3/$releasever... # ftp://ftp.sunsite.org.uk/sites/mirror.caosity.org/cAos/centos-3/$releasever/testing/$basearch/ # http://download.centos.ru/centos-3/$releasever/testing/$basearch/ # ftp://mirror.pacific.net.au/linux/cAos/centos-3/$releasever/testing/$basearch/ # http://public.planetmirror.com/pub/caosity/centos-3/$releasever/testing/$bas... # ftp://ftp2.tnc.edu.tw/pub1/centos/centos-3/$releasever/testing/$basearch/ #gpgcheck=1 #failovermethod=roundrobin
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
While a default yum.conf sounds good, for those admins that don't update their yum.conf file after installing a new system, they might get stuck downloading from a mirror that is not close to them.
There is talk about a system like the ClamAV project which redirects you to the closest mirror to you automatically, there is 1 common domain and DNS handles the redirection. In which case everyone would have the same yum.conf file.
Matt Shields wrote:
While a default yum.conf sounds good, for those admins that don't update their yum.conf file after installing a new system, they might get stuck downloading from a mirror that is not close to them.
There is talk about a system like the ClamAV project which redirects you to the closest mirror to you automatically, there is 1 common domain and DNS handles the redirection. In which case everyone would have the same yum.conf file.
Hmmmm sounds good.
But IMHO, it will work just for HTTP ...
On the other hand, which of Tier1 mirrors is far of you? for me (in Czech Republic) are some CZ servers much far then some in AU, DE or US
Does it really metter
Petr Klima
There is talk about a system like the ClamAV project which redirects you to the closest mirror to you automatically, there is 1 common domain and DNS handles the redirection. In which case everyone would have the same yum.conf file.
That sounds really complicated. How about a "mirror-select" script that's run when you run yum update for the first time?
From: Andy Masiar amasiar@gmail.com Reply-To: Andy Masiar amasiar@gmail.com To: centos@caosity.org Subject: Re: [Centos] Issues/thoughts re CentOS-4 Date: Tue, 14 Dec 2004 09:38:36 -0500
There is talk about a system like the ClamAV project which redirects you to the closest mirror to you automatically, there is 1 common domain and DNS handles the redirection. In which case everyone would have the same yum.conf file.
That sounds really complicated. How about a "mirror-select" script that's run when you run yum update for the first time?
This is really good idea!
_________________________________________________________________ MSN® Calendar keeps you organized and takes the effort out of scheduling get-togethers. http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI... Start enjoying all the benefits of MSN® Premium right now and get the first two months FREE*.
Max Beerli wrote:
There is talk about a system like the ClamAV project which redirects you to the closest mirror to you automatically, there is 1 common domain and DNS handles the redirection. In which case everyone would have the same yum.conf file.
That sounds really complicated. How about a "mirror-select" script that's run when you run yum update for the first time?
This is really good idea!
This is a really BAD idea. Mirrors come and go, mirrors stop rsyncing, but have outdated data.
I'd rather have a centralized authority hand out a "best guess" mirror than have someone pick a mirror at setup and thing they are covered.
.dn
On Tue, 14 Dec 2004, donavan nelson wrote:
This is a really BAD idea. Mirrors come and go, mirrors stop rsyncing, but have outdated data. I'd rather have a centralized authority hand out a "best guess" mirror than have someone pick a mirror at setup and thing they are covered.
... but with a central authority, scaling problems then appear
- R
R P Herrold wrote:
On Tue, 14 Dec 2004, donavan nelson wrote:
This is a really BAD idea. Mirrors come and go, mirrors stop rsyncing, but have outdated data. I'd rather have a centralized authority hand out a "best guess" mirror than have someone pick a mirror at setup and thing they are covered.
... but with a central authority, scaling problems then appear
only providing the suggested mirror to use....this is nothing more then and a websever.... Shoot even the WBEL guy is having yum hit his tiny T1 to get the mirror list.
.dn
only providing the suggested mirror to use....this is nothing more then and a websever.... Shoot even the WBEL guy is having yum hit his tiny T1 to get the mirror list.
In the event that the central site or network is inaccessible then the entire system stops. Even if there is new data on all/any mirror.
That's a good reason to have multiple mirrors populated in the config file.
or you can use a mirrorlist file but put it ON the machine.
-sv
Or have the best of both worlds.
Main config only servers either a. DNS round robin or b. static config on the client (in case of main DNS failure).
These config servers use a geography/topography to mirror database and return the URL of a mirror or mirrors to use for this update only.
The client can cache/remember the last working mirror or mirrors in case of config server failure.
Although I don't think we have to build a failsafe system, it is good to be able to dynamically change the mirrors without having to modify the client config, but at the same time, give the client enough power to pick a mirror if they want.
Much of this could all be hidden behind an http server as long as yum supports following redirects.
(apologies for not posing this thread to centos-devel, I was sending out errata messages at the time and was not thinking).
seth vidal wrote:
only providing the suggested mirror to use....this is nothing more then and a websever.... Shoot even the WBEL guy is having yum hit his tiny T1 to get the mirror list.
In the event that the central site or network is inaccessible then the entire system stops. Even if there is new data on all/any mirror.
That's a good reason to have multiple mirrors populated in the config file.
or you can use a mirrorlist file but put it ON the machine.
-sv
CentOS mailing list CentOS@caosity.org http://lists.caosity.org/mailman/listinfo/centos
Main config only servers either a. DNS round robin or b. static config on the client (in case of main DNS failure).
These config servers use a geography/topography to mirror database and return the URL of a mirror or mirrors to use for this update only.
The client can cache/remember the last working mirror or mirrors in case of config server failure.
cache where?
Although I don't think we have to build a failsafe system, it is good to be able to dynamically change the mirrors without having to modify the client config, but at the same time, give the client enough power to pick a mirror if they want.
Much of this could all be hidden behind an http server as long as yum supports following redirects.
It does.
(apologies for not posing this thread to centos-devel, I was sending out errata messages at the time and was not thinking).
So am I to assume you'll be writing this code. :)
-sv
From: donavan nelson donavan@4wx.net CC: centos@caosity.org Subject: Re: [Centos] Issues/thoughts re CentOS-4 Date: Tue, 14 Dec 2004 15:27:28 -0600
Max Beerli wrote:
There is talk about a system like the ClamAV project which redirects you to the closest mirror to you automatically, there is 1 common domain and DNS handles the redirection. In which case everyone would have the same yum.conf file.
That sounds really complicated. How about a "mirror-select" script that's run when you run yum update for the first time?
This is really good idea!
This is a really BAD idea. Mirrors come and go, mirrors stop rsyncing, but have outdated data.
I'd rather have a centralized authority hand out a "best guess" mirror than have someone pick a mirror at setup and thing they are covered.
Then how about centralized server or system keeps statistics on all mirrors. Make sure mirrors is updated, available and amount of bandwidth available. How does sourceforge do this? When you go to download a file it changes links to most available or closest server. Then a mirror script on new Centos installation gets run on first yum update so it contacts statisitics server which tells it based on location and all other variables which mirror should be used. It outputs the mirror address to screen where user can add it to yum.conf
_________________________________________________________________ Take charge with a pop-up guard built on patented Microsoft® SmartScreen Technology. http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI... Start enjoying all the benefits of MSN® Premium right now and get the first two months FREE*.
On Tue, 14 Dec 2004, donavan nelson wrote:
Max Beerli wrote:
There is talk about a system like the ClamAV project which redirects you to the closest mirror to you automatically, there is 1 common domain and DNS handles the redirection. In which case everyone would have the same yum.conf file.
That sounds really complicated. How about a "mirror-select" script that's run when you run yum update for the first time?
This is really good idea!
This is a really BAD idea. Mirrors come and go, mirrors stop rsyncing, but have outdated data. I'd rather have a centralized authority hand out a "best guess" mirror than have someone pick a mirror at setup and thing they are covered.
The ClamAV project maintains DNS and is responsible for making sure all mirrors are current and running. Each record is using a round-robin scheme.
# database.clamav.net is a round-robin record which points to our most # reliable mirrors. It's used as a fall back in case db.XY.clamav.net is # not working. DO NOT TOUCH the following line unless you know what you # are doing. DatabaseMirror db.be.clamav.net DatabaseMirror db.local.clamav.net
The package rewrites the freshclam.conf to include a mirror based on the country you live in (this information is taken from /etc/sysconfig/clock and matched with the zoneinfo information).
Of course, users have the freedom to change the config file and tweak what they like, the default will just result in a more balanced setup that gives control into the hands who owns the DNS and proper usage will boil down to proper management of mirrors and DNS.
They even have a split-brain setup for db.local.clamav.net that takes into account in what netblock you're in. In my case db.local.clamav.net (or database.clamav.net and even db.be.clamav.net) points to the reliable europian mirrors.
There's no burden on the users (unless they want to manage it themselves), it gives flexibility and control to the foundation and the only requirement is the responsibility of managing the mirrors correctly, which you would want to do otherwise anyway.
-- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power]
On Wed, 2004-12-15 at 14:42 +0100, Dag Wieers wrote:
On Tue, 14 Dec 2004, donavan nelson wrote:
Max Beerli wrote:
There is talk about a system like the ClamAV project which redirects you to the closest mirror to you automatically, there is 1 common domain and DNS handles the redirection. In which case everyone would have the same yum.conf file.
That sounds really complicated. How about a "mirror-select" script that's run when you run yum update for the first time?
This is really good idea!
This is a really BAD idea. Mirrors come and go, mirrors stop rsyncing, but have outdated data. I'd rather have a centralized authority hand out a "best guess" mirror than have someone pick a mirror at setup and thing they are covered.
The ClamAV project maintains DNS and is responsible for making sure all mirrors are current and running. Each record is using a round-robin scheme.
# database.clamav.net is a round-robin record which points to our most # reliable mirrors. It's used as a fall back in case db.XY.clamav.net is # not working. DO NOT TOUCH the following line unless you know what you # are doing. DatabaseMirror db.be.clamav.net DatabaseMirror db.local.clamav.net
The package rewrites the freshclam.conf to include a mirror based on the country you live in (this information is taken from /etc/sysconfig/clock and matched with the zoneinfo information).
Of course, users have the freedom to change the config file and tweak what they like, the default will just result in a more balanced setup that gives control into the hands who owns the DNS and proper usage will boil down to proper management of mirrors and DNS.
They even have a split-brain setup for db.local.clamav.net that takes into account in what netblock you're in. In my case db.local.clamav.net (or database.clamav.net and even db.be.clamav.net) points to the reliable europian mirrors.
There's no burden on the users (unless they want to manage it themselves), it gives flexibility and control to the foundation and the only requirement is the responsibility of managing the mirrors correctly, which you would want to do otherwise anyway.
-- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power]
I don't know how they do it, but the MySQL download area also has automated mirror selection that seems to work pretty well for me. Are we interested enough for me to ask how they do it?
Johnny Hughes http://www.HughesJR.com
On Sat, 18 Dec 2004 07:08:38 -0600, Johnny Hughes mailing-lists@hughesjr.com wrote:
I don't know how they do it, but the MySQL download area also has automated mirror selection that seems to work pretty well for me. Are we interested enough for me to ask how they do it?
I'm just speaking for myself here but if any sort of effective automated mirror selection scheme will help reduce bandwidth costs for the core developers then I'm all for it.
Hey!
Johnny Hughes wrote:
I don't know how they do it, but the MySQL download area also has automated mirror selection that seems to work pretty well for me. Are we interested enough for me to ask how they do it?
Would be quite academic to drop in something like GeoIP and use that as a refrence tool. For anyone interested : http://www.maxmind.com/app/geoip_country
Running / checking the mirror list for update status every 6 hours could be built into the central server, mirror handout should be done on the fly from there. And a setup like mirror.centos.org is redundant enough to not have issues with 1 or even 2 of the machines being down at a given time.
On Tuesday, 14 December 2004, at 17:22:21 (+1100), John Newbigin wrote:
This is a list of issues for discussion for CentOS-4. Most of it is based on my experience from building/maintaining CentOS-2 and observing CentOS-3. I have not seen the CentOS-4 beta yet so I don't know if any of this is already done. If these have been discussed on IRC then perhaps someone could produce a shot summary of the outcomes....?
- Just call it CentOS-4 not 4.1 etc. Too confusing and serves no real
purpose
IMHO, 4.0 should represent the final release, and each .? version afterward should correspond to a RHEL numbered update set.
- All modified rpm should use mezzanine or equiv. This makes it easier
to track changes, build updates and generate a report on what has changed.
There are two basic philosophies behind rebuilds, and Mezz can do either one. You can rebuild all packages from SRPM and point Mezzanine at the SRPM's (or SCM checkins thereof), or you can supply source and binary packages for anything you'll not rebuild and only rebuild what you need to. For cAos, every single package is an SPM in the CVS repository (first approach); for Vermillion, I used the second approach instead.
- Modified rpm should have .c4.n added to the release
- c4 = centos 4. (works well once the 4.1 is dropped)
- .n = a number starting at 1. The spec only 0 does not scale if you
need to make another spec only change. The changelog will tell you what has changed.
For clarity, I recommend ".centos4.NUM" instead. And there's really no reason to have more than one NUM suffix; just increase it each time.
- Mission: To stay as close to RedHat as possible
Issues: some things need to be modified to support this. For example the cpu/memory restrictions will be removed(like in CentOS-3). Given that we are doing this, should we also lift other artificial constraints like installing on i386?
If we start making changes, where do we draw the line? In CentOS-2 I have fixed some small 1 line bugs (mostly packaging issues) but this might be a contentious issue. What about a CentOS+ repo. for enhanced versions?
The line should be drawn at anything which would break binary compatibility. In other words, anything that changes library sonames, or moves perl/python modules around, etc.
- Issue: should the distro be self hosting? I think as long as the
requirements are available from the addon/extras repos. then I don't think this is needed out of the box. Obviously the build environment needs to be well documented and reproducible.
Maintaining binary compatibility is more important than being self-hosting. During the beta cycle, any non-self-hosting packages should be filed as bugs in RH bugzilla. After that, it's too late; we have to work around it.
- Idea: automatic patch building.
It should be possible to build most patches without intervention. I don't know what the current systems in place are but if there were autobuilt unsigned patches available it would allow
- testing of patches before they are 'officially' released
- checking the progress if a patch
Using an automatic system to apply CentOS specific modifications means that in some cases, the CentOS specific changes can also be autoapplied and the package build.
I had a tool that looked at the RH update trees and fetched any new updates automatically. If mezzanine were driving the CentOS builds, it would be fairly trivial to do this.
Michael
-
"Petr \"Qaxi\" Klíma" -
Andy Masiar -
Avtar Gill -
Dag Wieers -
donavan nelson -
John Newbigin -
Johnny Hughes -
Karanbir Singh -
Matt Shields -
Max Beerli -
Michael Jennings -
R P Herrold -
seth vidal