Hi Guys,
Some micro-conversations have taken place around this issue on various venues and its worth bringing all that together into one place.
With EL6, the rpmlist has grown quite a bit, also there are components that Red Hat ship out in their 'optional' repo. Which are not available on the main isos. Or so I've been told - if you can verify that, please do.
The other thing to keep in mind is that we have always merged in all packages from various variants that upstream ship - making all packages available to everyone was always the aim.
So traditionally, CentOS has maintained the distro repositories in 2 url's:
[os] [updates]
with [os] reflecting whats on the isos/; as close to exactly as possible.
With CentOS-6, we might need to reconsider that - there is way too much content to fit onto a single DVD. And having the main distro on multiple DVD's might be an option, but is that the best option ?
to expand on that option, we could merge in all packages, built a DVD iso set ( 2 or 3 disks, whatever is needed ), stick with the [os] and [updates] repo's on mirror.c.o - and then potentially consider doing some 'slimmer' options. eg: CentOS-6-Minimal, or CentOS-6-SMB-Server etc.
The other option is to split the repos into [os] [updates] [optional] {1} [optional-updates] {2}
{1} or use a better / different name {2} do we even need the second -updates, we could go with what the present policy w.r.t centosplus/extras is - and drop updates into the same repo
Then stick with what we have done in the past, use the isos to reflect whats in [os], create the ability for people to use the [optional] repo at install time and go with that. The iso content would be dictated by the merged iso contents from upstream, so we retain the CentOS <= 5 process in that regard.
Continuing on the same idea, one thing that came up was reporpose the Extras/ repo and use that to host these 'additional/optional' packages. Given that it changes a massive user expectation - unless there is very good reasoning to do this, lets try and avoid this.
- KB
On Fri, 2010-11-26 at 11:52 +0000, Karanbir Singh wrote:
Boot disk on mirrors is needed. Maybe a server install disc. What about CD Install discs
The other option is to split the repos into [os] [updates] [optional] {1} [optional-updates] {2}
[OS] [Updates] <-- To contain all Updates [Optional]
It really does not make sense to have two Update directories for the repo.
John
On 11/26/2010 12:18 PM, JohnS wrote:
Boot disk on mirrors is needed. Maybe a server install disc. What about CD Install discs
the usual network-install iso will get built anyway. We could then do a 'something like a server disk', but we would need to get our heads in and come up with a name. we cant call it 'server' since there is an upstream product by that name. Also, we would need some sort of a process to decide on pkg list.
Wolfy setup a quiz interface the other day, maybe if people want to get in their ideas of 'name of this cd iso' we can get a poll going to a wider audience. </just thinking out loud at this stage>
[OS] [Updates]<-- To contain all Updates [Optional]
It really does not make sense to have two Update directories for the repo.
the problem with that would be : yum would see pkgs from the optional-updates, by default. While people might have the optional repo disabled.
- KB
On Fri, 2010-11-26 at 12:21 +0000, Karanbir Singh wrote:
On 11/26/2010 12:18 PM, JohnS wrote:
Boot disk on mirrors is needed. Maybe a server install disc. What about CD Install discs
the usual network-install iso will get built anyway. We could then do a 'something like a server disk', but we would need to get our heads in and come up with a name. we cant call it 'server' since there is an upstream product by that name. Also, we would need some sort of a process to decide on pkg list.
There is no reason why it can not be called server. It is not Trade Marked. Server reflects the very idea it is "a server install". As in "CentOS-6-Server"
Wolfy setup a quiz interface the other day, maybe if people want to get in their ideas of 'name of this cd iso' we can get a poll going to a wider audience. </just thinking out loud at this stage>
Where is this at?
[OS] [Updates]<-- To contain all Updates [Optional]
It really does not make sense to have two Update directories for the repo.
the problem with that would be : yum would see pkgs from the optional-updates, by default. While people might have the optional repo disabled.
While that may be true the more directories in the repo leaves more room for failure on the repo cache updates.
John
On 11/27/2010 04:28 PM, JohnS wrote:
There is no reason why it can not be called server. It is not Trade Marked. Server reflects the very idea it is "a server install". As in "CentOS-6-Server"
As I already said previously, it cant be called server unless it contains the exact same components as the upstream server product - way too much confusion to be had otherwise.
Wolfy setup a quiz interface the other day, maybe if people want to get
Where is this at?
on a machine with a web server ? Not sure what the best answer to that question of your's is :) there is no quiz / poll on there at the moment. If we get around to using it, will publish a url along with the poll details.
While that may be true the more directories in the repo leaves more room for failure on the repo cache updates.
can you elaborate on that a bit ?
- KB
2010/11/26 Karanbir Singh mail-lists@karan.org:
to expand on that option, we could merge in all packages, built a DVD iso set ( 2 or 3 disks, whatever is needed ), stick with the [os] and [updates] repo's on mirror.c.o - and then potentially consider doing some 'slimmer' options. eg: CentOS-6-Minimal, or CentOS-6-SMB-Server etc.
Hi Karanbir,
My suggestion: Let's do it just like Red Hat.
2 DVDs:
CentOS 6 Server (about 3,2 GB) CentOS 6 Workstation (about 4 GB)
Repos:
[os] [updates] [optional] [extras]
Best regards,
Morten
On 11/26/2010 12:35 PM, Morten P.D. Stevens wrote:
My suggestion: Let's do it just like Red Hat.
Why ?
CentOS 6 Server (about 3,2 GB) CentOS 6 Workstation (about 4 GB)
What about the other variants ?
[os] [updates] [optional] [extras]
So, are you saying use 'optional' and put updates for pkgs into the same place ?
Can we come up with a better name than 'optional' ? Since essentially pretty much anything and everything in the CentOS distro is just about as optional as anything else.
On the other hand, retaining the name 'optional' might make it easier for people comparing upstream and centos - and perhaps share configs.
discuss!
- KB
2010/11/26 Karanbir Singh mail-lists@karan.org:
On 11/26/2010 12:35 PM, Morten P.D. Stevens wrote:
My suggestion: Let's do it just like Red Hat.
Why ?
Because it is much clearer.
A desktop / workstation version and a server version. (With the same repos)
If someone is missing something he can still install it with yum.
CentOS 6 Server (about 3,2 GB) CentOS 6 Workstation (about 4 GB)
What about the other variants ?
The client variant?
[os] [updates] [optional] [extras]
So, are you saying use 'optional' and put updates for pkgs into the same place ?
To prevent these problems, I propose to use an extra update repo for optional packages.
For example:
[optional-updates]
On the other hand, retaining the name 'optional' might make it easier for people comparing upstream and centos - and perhaps share configs.
I am sure to continue to use [optional].
Best regards,
Morten
On 11/26/2010 01:11 PM, Morten P.D. Stevens wrote:
My suggestion: Let's do it just like Red Hat.
Because it is much clearer.
What about the fact that we've always had a single merged distro layout for 2.1/3/4/5 ? There is a fairly consistent user experience and user expectation built around that as well, right ?
Also, consider that having so many more isos and so many more repo's will also drastically increase the disk space requirements on mirrors. We could get around that to some extent using hardlinks between the repo's but the ISOS will need their own space.
A desktop / workstation version and a server version. (With the same repos)
Maybe this can happen - have multiple install media with the same repo on mirror.centos.org; what are the implications arising from this ?
CentOS 6 Server (about 3,2 GB) CentOS 6 Workstation (about 4 GB)
What about the other variants ?
The client variant?
There are also the storage products, the computenode etc. Given that we have no support model, and it makes little sense to replicate pkgs for isos and base repo's I dont really see why we would want all that overhead.
I am sure to continue to use [optional].
why :)
- KB
2010/11/26 Karanbir Singh mail-lists@karan.org:
What about the fact that we've always had a single merged distro layout for 2.1/3/4/5 ? There is a fairly consistent user experience and user expectation built around that as well, right ?
That's a good question. In recent years the size of all linux distibutions is greatly increased.
The other possibility: We make 2 DVDs for CentOS6 containing all packages. In any case, I would appreciate if we offer a network install CD like Red Hat.
Also, consider that having so many more isos and so many more repo's will also drastically increase the disk space requirements on mirrors. We could get around that to some extent using hardlinks between the repo's but the ISOS will need their own space.
Yes, this is the drawback.
On the other hand, CentOS 6 will be identical to RHEL6. This would make it easier for newcomers.
There are also the storage products, the computenode etc. Given that we have no support model, and it makes little sense to replicate pkgs for isos and base repo's I dont really see why we would want all that overhead.
The workstation and server version of CentOS 6 can indeed contain these packages.
We need only 2 versions: CentOS Server and Workstation containing all the upstream packages.
I am sure to continue to use [optional].
why :)
For clarity :)
Best regards,
Morten
Morten P.D. Stevens wrote:
2010/11/26 Karanbir Singh mail-lists@karan.org:
What about the fact that we've always had a single merged distro layout for 2.1/3/4/5 ? There is a fairly consistent user experience and user expectation built around that as well, right ?
That's a good question. In recent years the size of all linux distibutions is greatly increased.
The other possibility: We make 2 DVDs for CentOS6 containing all packages. In any case, I would appreciate if we offer a network install CD like Red Hat.
Just out of curiosity, what is the total size of server + workstation? (I only have access to RHEL 6 Server DVD, so I don't know how much Workstation adds to it). I'm guessing most CentOS 6 users would use the Server variant over the Workstation variant, so would it be possible to mostly combine them, but move some of the really heavy stuff (i.e. OpenOffice, eclipse, etc.) to the 2nd DVD?
-Greg
On 26/11/10 17:56, Greg Bailey wrote:
Morten P.D. Stevens wrote:
2010/11/26 Karanbir Singhmail-lists@karan.org:
What about the fact that we've always had a single merged distro layout for 2.1/3/4/5 ? There is a fairly consistent user experience and user expectation built around that as well, right ?
That's a good question. In recent years the size of all linux distibutions is greatly increased.
The other possibility: We make 2 DVDs for CentOS6 containing all packages. In any case, I would appreciate if we offer a network install CD like Red Hat.
Just out of curiosity, what is the total size of server + workstation? (I only have access to RHEL 6 Server DVD, so I don't know how much Workstation adds to it).
Don't know as I don't have a Workstation subscription either, but the 64-bit multilib Server DVD is 3273MB containing 3432 packages, and the optional channel contains a further 2672 packages (there might be a few errata in there by now so it might actually be a few less than that).
Personally I would suggest a 2 DVD set for everything, and a somewhat lighter "Server" DVD as per upstream that has room to grow during subsequent update releases. That combined with the minimal network install ISO image should cover most people's requirements?
2010/11/26 Ned Slider ned@unixmail.co.uk:
Personally I would suggest a 2 DVD set for everything, and a somewhat lighter "Server" DVD as per upstream that has room to grow during subsequent update releases. That combined with the minimal network install ISO image should cover most people's requirements?
This is the best option.
Best regards,
Morten
On 11/26/2010 06:52 PM, Ned Slider wrote:
Personally I would suggest a 2 DVD set for everything, and a somewhat lighter "Server" DVD as per upstream that has room to grow during subsequent update releases. That combined with the minimal network install ISO image should cover most people's requirements?
I am also quite keen on the idea of retaining our single-merged distro, atleast as the main option. And then perhaps a slightly light(er) weight alternative.
Who now wants to take up the task of working out the package set which should be on this alternative media ?
- KB
PS: still looking for 'options' to the 'optional' repo name
Karanbir Singh wrote:
On 11/26/2010 06:52 PM, Ned Slider wrote:
Personally I would suggest a 2 DVD set for everything, and a somewhat lighter "Server" DVD as per upstream that has room to grow during subsequent update releases. That combined with the minimal network install ISO image should cover most people's requirements?
I am also quite keen on the idea of retaining our single-merged distro, atleast as the main option.
+1 here
+1 for me
2010/11/26 David Hrbáč hrbac.conf@seznam.cz
Dne 26.11.2010 20:17, Fabian Arrotin napsal(a):
Karanbir Singh wrote:
On 11/26/2010 06:52 PM, Ned Slider wrote: I am also quite keen on the idea of retaining our single-merged distro, atleast as the main option.
+1 here
+1 for me. DH _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
On 26/11/10 19:13, Karanbir Singh wrote:
On 11/26/2010 06:52 PM, Ned Slider wrote:
Personally I would suggest a 2 DVD set for everything, and a somewhat lighter "Server" DVD as per upstream that has room to grow during subsequent update releases. That combined with the minimal network install ISO image should cover most people's requirements?
I am also quite keen on the idea of retaining our single-merged distro, atleast as the main option. And then perhaps a slightly light(er) weight alternative.
Who now wants to take up the task of working out the package set which should be on this alternative media ?
Well, I'd suggest starting with the package set on the upstream Server disk as that looks fairly complete to me. There are some common "Desktop" packages missing that might want to be added - evolution, pidgin, thunderbird, xchat, and maybe even OpenOffice if there's room, but most stuff is already there.
On 11/26/2010 08:31 PM, Ned Slider wrote:
I am also quite keen on the idea of retaining our single-merged distro, atleast as the main option. And then perhaps a slightly light(er) weight alternative.
Well, I'd suggest starting with the package set on the upstream Server disk as that looks fairly complete to me. There are some common "Desktop" packages missing that might want to be added - evolution, pidgin, thunderbird, xchat, and maybe even OpenOffice if there's room, but most stuff is already there.
the upstream server product is almost a full DVD in itself. Is it worth having the main distro on 2 DVD, and another option which is still a complete'ish DVD ? If we are going to work out a lightweight CD size'd install media, is it worth then also having the full DVD'ish option over and above the 2 DVD disk full distro ?
-KB
On 11/29/2010 03:10 PM, Karanbir Singh wrote:
On 11/26/2010 08:31 PM, Ned Slider wrote:
I am also quite keen on the idea of retaining our single-merged distro, atleast as the main option. And then perhaps a slightly light(er) weight alternative.
Well, I'd suggest starting with the package set on the upstream Server disk as that looks fairly complete to me. There are some common "Desktop" packages missing that might want to be added - evolution, pidgin, thunderbird, xchat, and maybe even OpenOffice if there's room, but most stuff is already there.
the upstream server product is almost a full DVD in itself. Is it worth having the main distro on 2 DVD, and another option which is still a complete'ish DVD ? If we are going to work out a lightweight CD size'd install media, is it worth then also having the full DVD'ish option over and above the 2 DVD disk full distro ?
unless the CD offers all that's needed for a lightweight SMB (as in small business) server, it's not worth the effort ( at least not for European users; I cannot speak for other parts of the world ). A server edition on 1 DVD and a full-edition on 2 ( or more) DVDs satisfies me completely.
/* my N82 has a SD card large enough to store a full DVD and I did use it as install media */
On 11/29/2010 7:24 AM, Manuel Wolfshant wrote:
On 11/29/2010 03:10 PM, Karanbir Singh wrote:
On 11/26/2010 08:31 PM, Ned Slider wrote:
I am also quite keen on the idea of retaining our single-merged distro, atleast as the main option. And then perhaps a slightly light(er) weight alternative.
Well, I'd suggest starting with the package set on the upstream Server disk as that looks fairly complete to me. There are some common "Desktop" packages missing that might want to be added - evolution, pidgin, thunderbird, xchat, and maybe even OpenOffice if there's room, but most stuff is already there.
the upstream server product is almost a full DVD in itself. Is it worth having the main distro on 2 DVD, and another option which is still a complete'ish DVD ? If we are going to work out a lightweight CD size'd install media, is it worth then also having the full DVD'ish option over and above the 2 DVD disk full distro ?
unless the CD offers all that's needed for a lightweight SMB (as in small business) server, it's not worth the effort ( at least not for European users; I cannot speak for other parts of the world ). A server edition on 1 DVD and a full-edition on 2 ( or more) DVDs satisfies me completely.
The point of a minimal install isn't to give you a turnkey server at its first boot. It is to make it easy for anyone (even remote-hands that don't know much about linux) to get a box to the point where you can ssh in and say 'yum groupinstall ...' for the package set you want. All the packages are available over the internet anyway but network installs don't always work and don't give you much of a chance to diagnose problems remotely. And you may want to add some local or 3rd party repos before installing your final package set. Also, you may need to install on machines with no DVD drive.
On 29/11/10 13:10, Karanbir Singh wrote:
On 11/26/2010 08:31 PM, Ned Slider wrote:
I am also quite keen on the idea of retaining our single-merged distro, atleast as the main option. And then perhaps a slightly light(er) weight alternative.
Well, I'd suggest starting with the package set on the upstream Server disk as that looks fairly complete to me. There are some common "Desktop" packages missing that might want to be added - evolution, pidgin, thunderbird, xchat, and maybe even OpenOffice if there's room, but most stuff is already there.
the upstream server product is almost a full DVD in itself. Is it worth having the main distro on 2 DVD, and another option which is still a complete'ish DVD ? If we are going to work out a lightweight CD size'd install media, is it worth then also having the full DVD'ish option over and above the 2 DVD disk full distro ?
No, giving this some more thought I would just put out a 2 DVD full distro set. Disk1 based on the upstream "Server" DVD and Disk2 containing everything else (i.e, the upstream "Optional" channel). Disk1 would also be your "minimal" disk giving everything that's required to do an install meaning people don't need to download Disk2 to install. The upstream Server DVDs are 2.7 and 3.2GB for x86 and x86-64, respectively.
On 11/29/2010 10:57 PM, Ned Slider wrote:
On 29/11/10 13:10, Karanbir Singh wrote:
On 11/26/2010 08:31 PM, Ned Slider wrote:
I am also quite keen on the idea of retaining our single-merged distro, atleast as the main option. And then perhaps a slightly light(er) weight alternative.
Well, I'd suggest starting with the package set on the upstream Server disk as that looks fairly complete to me. There are some common "Desktop" packages missing that might want to be added - evolution, pidgin, thunderbird, xchat, and maybe even OpenOffice if there's room, but most stuff is already there.
the upstream server product is almost a full DVD in itself. Is it worth having the main distro on 2 DVD, and another option which is still a complete'ish DVD ? If we are going to work out a lightweight CD size'd install media, is it worth then also having the full DVD'ish option over and above the 2 DVD disk full distro ?
No, giving this some more thought I would just put out a 2 DVD full distro set. Disk1 based on the upstream "Server" DVD and Disk2 containing everything else (i.e, the upstream "Optional" channel).
I agree so far ...
Disk1 would also be your "minimal" disk giving everything that's required to do an install meaning people don't need to download Disk2 to install.
.. but not here. When people want "minimal" they expect to do that with a _small_ download. [*] A full DVD does not fit this bill, even if it can be used for a minimal install, too.
The upstream Server DVDs are 2.7 and 3.2GB for x86 and x86-64, respectively.
I sincerely doubt that anyone would consider those as "minimal". I am tempted to say that minimal should fit a definition similar to "grab a small image -- the smaller the better -- and use it to do an install which can give you a local root account which can further be used to install what ever else is needed. And which allows basic network tests as it is".
[*] And I rely this affirmation on the questions received on #centos.
On 29/11/10 21:08, Manuel Wolfshant wrote:
On 11/29/2010 10:57 PM, Ned Slider wrote:
No, giving this some more thought I would just put out a 2 DVD full distro set. Disk1 based on the upstream "Server" DVD and Disk2 containing everything else (i.e, the upstream "Optional" channel).
I agree so far ...
Disk1 would also be your "minimal" disk giving everything that's required to do an install meaning people don't need to download Disk2 to install.
.. but not here. When people want "minimal" they expect to do that with a _small_ download. [*] A full DVD does not fit this bill, even if it can be used for a minimal install, too.
The upstream Server DVDs are 2.7 and 3.2GB for x86 and x86-64, respectively.
I sincerely doubt that anyone would consider those as "minimal". I am tempted to say that minimal should fit a definition similar to "grab a small image -- the smaller the better -- and use it to do an install which can give you a local root account which can further be used to install what ever else is needed. And which allows basic network tests as it is".
Which can be addressed by a minimal CD being discussed in a separate thread. I tried to avoid mentioning that here so as not to cloud the DVD media discussion :-)
My use of the quoted term "minimal" was perhaps misleading - I meant it to refer to the fact that Disk1 could be used as a stand alone disk and would not require the "optional" Disk2.
On 11/30/2010 12:48 AM, Ned Slider wrote:
On 29/11/10 21:08, Manuel Wolfshant wrote:
On 11/29/2010 10:57 PM, Ned Slider wrote:
No, giving this some more thought I would just put out a 2 DVD full distro set. Disk1 based on the upstream "Server" DVD and Disk2 containing everything else (i.e, the upstream "Optional" channel).
I agree so far ...
Disk1 would also be your "minimal" disk giving everything that's required to do an install meaning people don't need to download Disk2 to install.
.. but not here. When people want "minimal" they expect to do that with a _small_ download. [*] A full DVD does not fit this bill, even if it can be used for a minimal install, too.
The upstream Server DVDs are 2.7 and 3.2GB for x86 and x86-64, respectively.
I sincerely doubt that anyone would consider those as "minimal". I am tempted to say that minimal should fit a definition similar to "grab a small image -- the smaller the better -- and use it to do an install which can give you a local root account which can further be used to install what ever else is needed. And which allows basic network tests as it is".
Which can be addressed by a minimal CD being discussed in a separate thread. I tried to avoid mentioning that here so as not to cloud the DVD media discussion :-)
My use of the quoted term "minimal" was perhaps misleading - I meant it to refer to the fact that Disk1 could be used as a stand alone disk and would not require the "optional" Disk2.
Argh.. Indeed, it was misleading. In this case I agree with you , having a fully contained first DVD ( even smaller than the maximum size allowed by the standard !) labeled and able to be used as "server DVD" would fit my needs.
Le 30/11/10 09:32, Manuel Wolfshant a écrit :
On 11/30/2010 12:48 AM, Ned Slider wrote:
On 29/11/10 21:08, Manuel Wolfshant wrote: ... My use of the quoted term "minimal" was perhaps misleading - I meant it to refer to the fact that Disk1 could be used as a stand alone disk and would not require the "optional" Disk2.
Argh.. Indeed, it was misleading. In this case I agree with you , having a fully contained first DVD ( even smaller than the maximum size allowed by the standard !) labeled and able to be used as "server DVD" would fit my needs.
+1
JML
On 11/29/2010 08:57 PM, Ned Slider wrote:
No, giving this some more thought I would just put out a 2 DVD full distro set. Disk1 based on the upstream "Server" DVD and Disk2 containing everything else (i.e, the upstream "Optional" channel). Disk1 would also be your "minimal" disk giving everything that's required to do an install meaning people don't need to download Disk2 to install.
This is quite a good idea. I am also tempted to consider moving all multilib stuff from x86_64 into the second disk.
- KB
Le 26/11/10 12:52, Karanbir Singh a écrit :
Hi Guys,
Some micro-conversations have taken place around this issue on various venues and its worth bringing all that together into one place.
With EL6, the rpmlist has grown quite a bit, also there are components that Red Hat ship out in their 'optional' repo. Which are not available on the main isos. Or so I've been told - if you can verify that, please do.
The other thing to keep in mind is that we have always merged in all packages from various variants that upstream ship - making all packages available to everyone was always the aim.
So traditionally, CentOS has maintained the distro repositories in 2 url's:
[os] [updates]
with [os] reflecting whats on the isos/; as close to exactly as possible.
With CentOS-6, we might need to reconsider that - there is way too much content to fit onto a single DVD. And having the main distro on multiple DVD's might be an option, but is that the best option ?
to expand on that option, we could merge in all packages, built a DVD iso set ( 2 or 3 disks, whatever is needed ), stick with the [os] and [updates] repo's on mirror.c.o - and then potentially consider doing some 'slimmer' options. eg: CentOS-6-Minimal, or CentOS-6-SMB-Server etc.
The CentOS 5's merging of server, worstation and others declinations stick better with our usages : for example we use the server distro but we also need thunderbird package from the workstation distro and we perhaps need some other package from another specific delination. In this usage, doing some slimmer "dedicated-DVD" install, that shoud be complete after with yum, seems an excellent option.
The other option is to split the repos into [os] [updates] [optional] {1} [optional-updates] {2}
{1} or use a better / different name {2} do we even need the second -updates, we could go with what the present policy w.r.t centosplus/extras is - and drop updates into the same repo
If you choose this option, optionnal (or better/different name) should work as the others extras/plus centos repos, so optional-updates should be avoid.
Then stick with what we have done in the past, use the isos to reflect whats in [os], create the ability for people to use the [optional] repo at install time and go with that. The iso content would be dictated by the merged iso contents from upstream, so we retain the CentOS<= 5 process in that regard.
Continuing on the same idea, one thing that came up was reporpose the Extras/ repo and use that to host these 'additional/optional' packages. Given that it changes a massive user expectation - unless there is very good reasoning to do this, lets try and avoid this.
does CentOS-6 extras repo will contain some stuff which will be extra from Upstream ? same question for addons and contrib ?
JML
On 11/26/2010 02:19 PM, Jean-Marc Liger wrote:
Then stick with what we have done in the past, use the isos to reflect whats in [os], create the ability for people to use the [optional] repo at install time and go with that. The iso content would be dictated by the merged iso contents from upstream, so we retain the CentOS<= 5 process in that regard.
Continuing on the same idea, one thing that came up was reporpose the Extras/ repo and use that to host these 'additional/optional' packages. Given that it changes a massive user expectation - unless there is very good reasoning to do this, lets try and avoid this.
does CentOS-6 extras repo will contain some stuff which will be extra from Upstream ? same question for addons and contrib ?
IMHO, keeping close to upstream schema is better for people are mixing RHEL/CentOS so their config / script (yum specific) can be shared easily ;
BTW, make a remix/livecd/livedvd should be easy using fedora's livecd-tools because RHEL6/CentOS6 are based on Fedora 12/13
Regards.
On 11/26/2010 01:19 PM, Jean-Marc Liger wrote:
perhaps need some other package from another specific delination. In this usage, doing some slimmer "dedicated-DVD" install, that shoud be complete after with yum, seems an excellent option.
Would you be able to come up with a list of packages, you think are essential to have on this slim-dvd ?
Thanks
- KB
Le 26/11/10 17:14, Karanbir Singh a écrit :
On 11/26/2010 01:19 PM, Jean-Marc Liger wrote:
perhaps need some other package from another specific delination. In this usage, doing some slimmer "dedicated-DVD" install, that shoud be complete after with yum, seems an excellent option.
Would you be able to come up with a list of packages, you think are essential to have on this slim-dvd ?
Thanks
- KB
Something which focus on what was the CentOS 4 Server CD is a good target.
We could base it on some current Group Install Options like "CentOS// Server (GUI)".
JML
On 11/26/2010 05:06 PM, Jean-Marc Liger wrote:
Something which focus on what was the CentOS 4 Server CD is a good target. We could base it on some current Group Install Options like "CentOS// Server (GUI)".
Thats possible, but we should try and consider what the install package sets are on the upstream product and see if its possible to match that in some way.
w.r.t ServerCD-4, i just went with the most common server packages ( as measured by download numbers on mirror.c.o ); that worked as an additional install media, over and above the main distro CD/DVD set, but if we are going to have something like this for our main install media I feel trying to get close to the upstream product might be a good idea.
what do you think ?
- KB
Dne 26.11.2010 19:30, Karanbir Singh napsal(a):
Thats possible, but we should try and consider what the install package sets are on the upstream product and see if its possible to match that in some way.
w.r.t ServerCD-4, i just went with the most common server packages ( as measured by download numbers on mirror.c.o ); that worked as an additional install media, over and above the main distro CD/DVD set, but if we are going to have something like this for our main install media I feel trying to get close to the upstream product might be a good idea.
what do you think ?
- KB
For me, the size is not so important, I don't find is as an issue. I guess 2 DVDs with the first one as primary is the way to go. C5 goes the same way and even if I can use CD isos I use only DVD iso now. I don't think it's worth investing time to create server iso. It will only increase storage requirements. DH
On 11/26/10 12:30 PM, Karanbir Singh wrote:
On 11/26/2010 05:06 PM, Jean-Marc Liger wrote:
Something which focus on what was the CentOS 4 Server CD is a good target. We could base it on some current Group Install Options like "CentOS// Server (GUI)".
Thats possible, but we should try and consider what the install package sets are on the upstream product and see if its possible to match that in some way.
w.r.t ServerCD-4, i just went with the most common server packages ( as measured by download numbers on mirror.c.o ); that worked as an additional install media, over and above the main distro CD/DVD set, but if we are going to have something like this for our main install media I feel trying to get close to the upstream product might be a good idea.
what do you think ?
I think it would be great to have a minimal CD/USB install image that would get you to a point where you can run yum after the reboot. Whether enough server packages fit to be useful without having yum install more packages is somewhat irrelevant if we assume that you need enough internet connectivity to do updates anyway. The idea would be to have a super-fast install that doesn't need a DVD drive and gets you to a point where you can debug hardware/network problems, add some drivers, etc. in difficult cases and (unlike a network install) lets you continue after failures. And it would make it quick and easy for off-site people to get a machine to the point where you could ssh in to run the rest of the 'yum install', etc. commands to customize it.
On 11/27/2010 11:45 AM, Les Mikesell wrote:
On 11/26/10 12:30 PM, Karanbir Singh wrote:
On 11/26/2010 05:06 PM, Jean-Marc Liger wrote:
Something which focus on what was the CentOS 4 Server CD is a good target. We could base it on some current Group Install Options like "CentOS// Server (GUI)".
Thats possible, but we should try and consider what the install package sets are on the upstream product and see if its possible to match that in some way.
w.r.t ServerCD-4, i just went with the most common server packages ( as measured by download numbers on mirror.c.o ); that worked as an additional install media, over and above the main distro CD/DVD set, but if we are going to have something like this for our main install media I feel trying to get close to the upstream product might be a good idea.
what do you think ?
I think it would be great to have a minimal CD/USB install image that would get you to a point where you can run yum after the reboot. Whether enough server packages fit to be useful without having yum install more packages is somewhat irrelevant if we assume that you need enough internet connectivity to do updates anyway. The idea would be to have a super-fast install that doesn't need a DVD
If you want fast, nothing beats a LiveCD/USB, particularly the way fedora's livecd-tools does it (dd fs copy, with my convoluted dm optimization). If you want super-fast, throw a rebootless installer (zyx-liveinstaller) on top of that. Oops, I just willfully spammed the list. It just seemed relevent to the thread however. And also a good place to add the forgotten caveat to my last post about procedure, i.e. I do have an obvious ulterior motive in wanting to see round1 packages ASAP, so that I can start playing around with centos6 based livecd/usbs.
-dmc
drive and gets you to a point where you can debug hardware/network problems, add some drivers, etc. in difficult cases and (unlike a network install) lets you continue after failures. And it would make it quick and easy for off-site people to get a machine to the point where you could ssh in to run the rest of the 'yum install', etc. commands to customize it.
On 11/27/2010 09:10 PM, Douglas McClendon wrote:
If you want fast, nothing beats a LiveCD/USB, particularly the way fedora's livecd-tools does it (dd fs copy, with my convoluted dm
thats not true. A bare metal install will finish before your livecd has finished booting. I have c5/node's build in just under 270 seconds from machine powerup - usb/optical media just cant shift data fast enough to first boot an environment then kickup an installed.
ok, things might have changed in fedora13+; but I'd still like to see it being done.
optimization). If you want super-fast, throw a rebootless installer (zyx-liveinstaller) on top of that. Oops, I just willfully spammed the
.. and you lose any/all management ability from the standard distro-aware tools. Ofcourse, that does not matter if you don't need those tools anyway.
- KB
On 11/29/2010 06:16 AM, Karanbir Singh wrote:
On 11/27/2010 09:10 PM, Douglas McClendon wrote:
If you want fast, nothing beats a LiveCD/USB, particularly the way fedora's livecd-tools does it (dd fs copy, with my convoluted dm
thats not true. A bare metal install will finish before your livecd has finished booting. I have c5/node's build in just under 270 seconds from machine powerup - usb/optical media just cant shift data fast enough to first boot an environment then kickup an installed.
Sure, pedantically you are no doubt correct even though I have no idea what a 'bare metal install' means in this context.
ok, things might have changed in fedora13+; but I'd still like to see it being done.
no, I'm not talking anything that new, just standard f8 and onward.
optimization). If you want super-fast, throw a rebootless installer (zyx-liveinstaller) on top of that. Oops, I just willfully spammed the
.. and you lose any/all management ability from the standard distro-aware tools. Ofcourse, that does not matter if you don't need those tools anyway.
Also here I don't really know what you mean. Though yes, LiveCD installations are presently still less flexible in several ways than the traditional installer. I was just pointing out that they are also more flexible in several ways, and my rebootless installer takes both sides of that even further.
I didn't mean to suggest abandoning the traditional installer. I mean I am crazy, but not _that_ crazy :) I do believe however that when most people compare a traditional DVD install, or even the fanangled traditional DVD image on usb boot media, to the LiveCD/DVD/USB method, with or without my novelty rebootless alternative, they will find the experience to be drastically speedier (at least in many cases). Simply because writing 10K files to a filesystem takes a lot longer than dd'ing a filesystem image. (and invoking rpm to install all of them, and other steps, etc...)
But I'm sure there are many use cases outside my knowledge which you are presumably referring to which are speedier still, and the right choice for some situations but not others.
What I see however, is a LiveUSB that boots purty darn fast, and allows installation purty darn fast. In fact, I envision a LiveUSB image that acts pretty much like most LiveUSB's you are familiar with, but which may also have a bootloader option to take you straight into the afore-described minimal ssh/yumable state in just a couple minutes, without even requiring any subsequent reboot before attaining fully operational production state.
But what I'm describing are things I'd like to experiment with building, and present as experimental options and ideas to this list in the future. Absolutely off-topic as far as the obvious priority #1 of this list at the moment. So... never mind for now.
-dmc
On 11/30/2010 01:42 AM, Douglas McClendon wrote:
thats not true. A bare metal install will finish before your livecd has finished booting.
Sure, pedantically you are no doubt correct even though I have no idea what a 'bare metal install' means in this context.
to me, 'a bare metal' install is where its just the bios, pxe into a pre-established install set ( via a ks.cfg ) - Also, rebooting before a machine gets deployed in a 'role' is actually very highly recommended. Install images and run-time images are never guaranteed to be identical.
.. and you lose any/all management ability from the standard distro-aware tools. Ofcourse, that does not matter if you don't need those tools anyway.
Also here I don't really know what you mean. Though yes, LiveCD installations are presently still less flexible in several ways than the
management tooling like cobbler/spacewalk/theforeman/existing and established install -> deployment tools etc.
But what I'm describing are things I'd like to experiment with building, and present as experimental options and ideas to this list in the future. Absolutely off-topic as far as the obvious priority #1 of this list at the moment. So... never mind for now.
Sounds good, and I look forward to trying out some of these things. Over the next few months, lets try and see if we can create hooks in the centos build process that allows such 'alternatives' to be built in sync with the main distro. Were going to trial something very basic for the LiveCD stuff this time.
- KB
010/12/2 Karanbir Singh mail-lists@karan.org:
On 11/29/2010 08:57 PM, Ned Slider wrote:
No, giving this some more thought I would just put out a 2 DVD full distro set. Disk1 based on the upstream "Server" DVD and Disk2 containing everything else (i.e, the upstream "Optional" channel). Disk1 would also be your "minimal" disk giving everything that's required to do an install meaning people don't need to download Disk2 to install.
This is quite a good idea. I am also tempted to consider moving all multilib stuff from x86_64 into the second disk.
Yes, that's really a good idea.
Best regards,
Morten
On 12/01/2010 07:33 PM, Karanbir Singh wrote:
On 11/30/2010 01:42 AM, Douglas McClendon wrote:
thats not true. A bare metal install will finish before your livecd has finished booting.
Sure, pedantically you are no doubt correct even though I have no idea what a 'bare metal install' means in this context.
to me, 'a bare metal' install is where its just the bios, pxe into a pre-established install set ( via a ks.cfg ) - Also, rebooting before a machine gets deployed in a 'role' is actually very highly recommended. Install images and run-time images are never guaranteed to be identical.
Yeah, later I realized you brought up 'bare metal' as opposed to virt, in relation to your comment about installation-running-os fighting for io traffic from the cd/usb with the installation data itself. But no, I was talking bare metal installs as well. And I think I can beat your 270s time. Also, while I'll grant that there are some valid points for rebooting (though I have ways to mitigate/counter those), your point about install-images and run-time(installation-os?) images not being guaranteed to be identical is actually I think exactly wrong for the case of how fedora's livecd installation works. Fedora's livecd installation works by literally copying the same rootfs image that was used to boot the livecd, to the destination partition. Thus they are in that case, always guaranteed to be identical. Also note, that your point about livecd/usb boots being slow, had I believe a lot to do with your perspective of watching particular livecd/usb boots, and how much work they actually do compared to the installation-os that boots from the traditional install media. I.e. if you build a custom livecd that isn't trying to boot up to a full gnome desktop, and instead just boots up to what we think of as runlevel1, or to runlevel3 of a minimal style install (just ssh server and yum groupinstallable), you'll find that a livecd/liveusb can boot up nearly as fast as the traditional install media. Then, the time savings you get from performing an fs-image copy style install versus a fs-create+rpm-i*.rpm+otherstuff, more than make up for the few extra seconds upon boot. In other words, I definitely think I can make a liveusb minimal sshable-yumable installer that finishes faster than the same usb booting the traditional installer doing a traditional equivalent minimal install. And then also a version that makes the reboot after install completes entirely optional (in other words, if you want to do it to test the bootloader, you can, but you don't have to).
.. and you lose any/all management ability from the standard distro-aware tools. Ofcourse, that does not matter if you don't need those tools anyway.
Also here I don't really know what you mean. Though yes, LiveCD installations are presently still less flexible in several ways than the
management tooling like cobbler/spacewalk/theforeman/existing and established install -> deployment tools etc.
Yes, you just got the wrong impression that I was talking about a replacement installer, not an additional optional/experimental method.
-dmc
On 27 November 2010 17:45, Les Mikesell lesmikesell@gmail.com wrote:
I think it would be great to have a minimal CD/USB install image that would get you to a point where you can run yum after the reboot. Whether enough server packages fit to be useful without having yum install more packages is somewhat irrelevant if we assume that you need enough internet connectivity to do updates anyway. The idea would be to have a super-fast install that doesn't need a DVD drive and gets you to a point where you can debug hardware/network problems, add some drivers, etc. in difficult cases and (unlike a network install) lets you continue after failures. And it would make it quick and easy for off-site people to get a machine to the point where you could ssh in to run the rest of the 'yum install', etc. commands to customize it.
That would be an eminently useful install medium, Les. As someone who routinely uses just CD-1 out of an install set, I would certainly make use of such a medium.
Alan.
On 11/27/2010 05:45 PM, Les Mikesell wrote:
I think it would be great to have a minimal CD/USB install image that would get you to a point where you can run yum after the reboot. Whether enough server
Moving conversation to a new thread. I think there is enough interest to consider a minimal install option.
- KB
Hi all.
[os] [updates] [optional] {1} [optional-updates] {2}
+1 for an optional repository.
{1} or use a better / different name
I like the name :)
{2} do we even need the second -updates, we could go with what the present policy w.r.t centosplus/extras is - and drop updates into the same repo
I would suggest to drop updates directly to optional. no need for having a separate repo here imho.
Besides that I am not a fan of different installation medias for workstation and server. One of the advantages of CentOS always was to allow installation of both with one media kit.
On 11/26/2010 05:54 PM, Marcus Moeller wrote:
+1 for an optional repository. I like the name :)
I am not sold on the idea of calling it 'optional' - as mentioned before, we dont really have a supported and optional model in CentOS. Does everyone really want to go with the 'optional' name ?
Besides that I am not a fan of different installation medias for workstation and server. One of the advantages of CentOS always was to allow installation of both with one media kit.
cool!
- KB
Am 26.11.10 19:32, schrieb Karanbir Singh:
I am not sold on the idea of calling it 'optional' - as mentioned before, we dont really have a supported and optional model in CentOS. Does everyone really want to go with the 'optional' name ?
I'm (even with RHEL) wondering what makes them optional. Optional compared to what? Sounds like some alternative in there, but then again the question: An alternative to what?
I gather just having one repo with the "optional" packages in there isn't that great, as people might want to stay close to the "non-optional" RHEL when using CentOS.
I'd put those packages into Extras - even though we already had an extra repository. But if those packages which RH deems to be optional - so are ours.
What I don't want to have is base, updates, plus, extras and optional. Either we drop base and put our packages into "optional" too, or we just put "optional" into our extras.
We can clearly flag our packages via a repo tag, for example.
Ralph
Ralph Angenendt wrote:
Am 26.11.10 19:32, schrieb Karanbir Singh:
I am not sold on the idea of calling it 'optional' - as mentioned before, we dont really have a supported and optional model in CentOS. Does everyone really want to go with the 'optional' name ?
I'm (even with RHEL) wondering what makes them optional. Optional compared to what? Sounds like some alternative in there, but then again the question: An alternative to what?
on a support point of view ( from a RHEL perspective) : most (if not all) of the packages in the optional repo for rhel6-server are in fact packages supported in the Workstation/Client subscription. So they are made available through an 'optional' channel for people with a Server subscription, but those customer won't get any support for such packages coming from Optional
I gather just having one repo with the "optional" packages in there isn't that great, as people might want to stay close to the "non-optional" RHEL when using CentOS.
As said above, because there is no support in CentOS and that such packages are in the Workstation/Client channels (that CentOS doesn't have), it's just one big repo for CentOS in the end
I'd put those packages into Extras - even though we already had an extra repository. But if those packages which RH deems to be optional - so are ours.
My vision of the Extras repository was a repository of packages non provided by Upstream, which is specifically the case for the optional ones
What I don't want to have is base, updates, plus, extras and optional. Either we drop base and put our packages into "optional" too, or we just put "optional" into our extras.
We can clearly flag our packages via a repo tag, for example.
Ralph _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
On 11/26/10 2:28 PM, Fabian Arrotin wrote:
on a support point of view ( from a RHEL perspective) : most (if not all) of the packages in the optional repo for rhel6-server are in fact packages supported in the Workstation/Client subscription. So they are made available through an 'optional' channel for people with a Server subscription, but those customer won't get any support for such packages coming from Optional
Is there any chance that the packages in the optional repo will be the same as packages in some other repo but at different revs (presumably so that by enabling the optional repo you would get a new version)? If so, merging it with any other repo contents will cause problems later. Also, the more you put in one repo the more likely it is to cause dependency issues when you have 3rd party repos enabled, so mixing it with extras is likely to cause trouble too.
Hi,
On 11/27/2010 05:32 PM, Les Mikesell wrote:
on a support point of view ( from a RHEL perspective) : most (if not all) of the packages in the optional repo for rhel6-server are in fact packages supported in the Workstation/Client subscription. So they are
Is there any chance that the packages in the optional repo will be the same as packages in some other repo but at different revs (presumably so that by
I believe that is indeed the case. server-optional is not identical to <something else variant>-optional.
For dep loops and build ordering / mock config buildout / chroot population, I know for a fact that the optional pkgs have been considered upstream as well.
Although, they have had some really weird build linking, making me think that they have decided to adopt our model of non-standard build roots :D
- KB
Hi all.
I am not sold on the idea of calling it 'optional' - as mentioned before, we dont really have a supported and optional model in CentOS. Does everyone really want to go with the 'optional' name ?
I'm (even with RHEL) wondering what makes them optional. Optional compared to what? Sounds like some alternative in there, but then again the question: An alternative to what?
I gather just having one repo with the "optional" packages in there isn't that great, as people might want to stay close to the "non-optional" RHEL when using CentOS.
I'd put those packages into Extras - even though we already had an extra repository. But if those packages which RH deems to be optional - so are ours.
What I don't want to have is base, updates, plus, extras and optional. Either we drop base and put our packages into "optional" too, or we just put "optional" into our extras.
optional in extras would also be fine imho.
On 11/27/2010 09:07 AM, Marcus Moeller wrote:
What I don't want to have is base, updates, plus, extras and optional. Either we drop base and put our packages into "optional" too, or we just put "optional" into our extras.
optional in extras would also be fine imho.
In light of the fact that upstream's optional repo's are specific to the variant, I dont think we have any options ourselves. If we were to make a list of things that are in all <varient>-options repo's we'd be left with a very small list, and we'd need to put the rest into the base distro.
Which then really closes the door on having components in a seperate repo, with the base being light. We're going to need to drop everything into base and consider doing parallel builds. at the moment, thats the base+livecd+minimal
or am I missing something ?
- KB
On 11/26/2010 05:54 PM, Marcus Moeller wrote:
Besides that I am not a fan of different installation medias for workstation and server. One of the advantages of CentOS always was to allow installation of both with one media kit.
As a second point of interest : we now have a 2 disk C5/x86_64 install dvd set. How did other projects react to this, specially ones associated with the media format : spacewalk & cobbler etc ?
- KB
2010/11/26 Karanbir Singh mail-lists@karan.org:
On 11/26/2010 05:54 PM, Marcus Moeller wrote:
Besides that I am not a fan of different installation medias for workstation and server. One of the advantages of CentOS always was to allow installation of both with one media kit.
As a second point of interest : we now have a 2 disk C5/x86_64 install dvd set. How did other projects react to this, specially ones associated with the media format : spacewalk & cobbler etc ?
For Spacewalk you only need to import the boot images and mirror the repositories to channels. No need to work with media here.
I have never used cobbler import so I cannot say much about it.
Hi,
On 11/26/2010 06:43 PM, Marcus Moeller wrote:
For Spacewalk you only need to import the boot images and mirror the repositories to channels. No need to work with media here.
So just to confirm : mirror the repo's is something one would do over-the-net ? You cant use local isos or media for this ?
- KB
Hi,
On 11/26/2010 06:43 PM, Marcus Moeller wrote:
For Spacewalk you only need to import the boot images and mirror the repositories to channels. No need to work with media here.
So just to confirm : mirror the repo's is something one would do over-the-net ? You cant use local isos or media for this ?
I would do so. Spacewalk now got a very good integrated repository management and mirroring component.
As mentioned 'cobbler import' could also import from media but I am not sure if that would work with two disks. For Spacewalk this is also not a common way to go, but maybe for a standalone cobbler setup.
----- Original Message ----- | Hi, | | On 11/26/2010 06:43 PM, Marcus Moeller wrote: | > For Spacewalk you only need to import the boot images and mirror the | > repositories to channels. No need to work with media here. | | So just to confirm : mirror the repo's is something one would do | over-the-net ? You cant use local isos or media for this ? | | - KB | _______________________________________________ | CentOS-devel mailing list | CentOS-devel@centos.org | http://lists.centos.org/mailman/listinfo/centos-devel
With cobbler you can import with DVD or net media, spacewalk I think is the same
-- James A. Peltier Systems Analyst (FASNet), VIVARIUM Technical Director Simon Fraser University - Burnaby Campus Phone : 778-782-6573 Fax : 778-782-3045 E-Mail : jpeltier@sfu.ca Website : http://www.fas.sfu.ca | http://vivarium.cs.sfu.ca http://blogs.sfu.ca/people/jpeltier MSN : subatomic_spam@hotmail.com
On 11/26/2010 08:26 PM, James A. Peltier wrote:
| So just to confirm : mirror the repo's is something one would do | over-the-net ? You cant use local isos or media for this ? | With cobbler you can import with DVD or net media, spacewalk I think is the same
So how does cobbler handle multiple dvd images ? is it aware of the media:// style repo metadata ?
- KB
On 26/11/10 11:52, Karanbir Singh wrote:
Hi Guys,
Some micro-conversations have taken place around this issue on various venues and its worth bringing all that together into one place.
With EL6, the rpmlist has grown quite a bit, also there are components that Red Hat ship out in their 'optional' repo. Which are not available on the main isos. Or so I've been told - if you can verify that, please do.
Yes, that's correct.
On Fri, Nov 26, 2010 at 04:52, Karanbir Singh mail-lists@karan.org wrote:
The other option is to split the repos into [os] [updates] [optional] {1} [optional-updates] {2}
{1} or use a better / different name {2} do we even need the second -updates, we could go with what the present policy w.r.t centosplus/extras is - and drop updates into the same repo
[core] # your basic OS [core-updates] [extras] # the items not in basic [extras-updates] [bonus] # items not supplied by the upstream release? [bonus-updates]
Keeping things consolidated as possible is good for developers dealing with 'oh wait I need this from the sever-optional and this from workstation-optional' problems. [Seeing this in compiling stuff for EPEL]
On Nov 26, 2010, at 6:21 PM, Stephen John Smoogen wrote:
Keeping things consolidated as possible is good for developers dealing with 'oh wait I need this from the sever-optional and this from workstation-optional' problems. [Seeing this in compiling stuff for EPEL]
Hi Smooge!
How long did it take you to design the mirror hierarchy for @redhat way back when? 1 year?
I still *miss* the SRPMS/SRPMS brain fart ;-)
73 de Jeff
-
Alan Bartlett -
Athmane Madjoudj -
David Hrbáč -
Douglas McClendon -
Fabian Arrotin -
Greg Bailey -
James A. Peltier -
Jean-Marc Liger -
Jeff Johnson -
JohnS -
Karanbir Singh -
Les Mikesell -
Lucas Timm LH -
Manuel Wolfshant -
Marcus Moeller -
Morten P.D. Stevens -
Ned Slider -
Ralph Angenendt -
Stephen John Smoogen