From dan at danny.cz Mon Dec 1 14:05:39 2008 From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=) Date: Mon, 01 Dec 2008 15:05:39 +0100 Subject: Server SIG - work areas Message-ID: 1228140339.3664.75.camel@eagle.danny.cz
Hello,
Sorry for replying to an old thread however I am just now catching up on the discussions from this list. My first impression is that there looks to be a lot in common with the server sig and the "thincrust" project, www.thincrust.org. We are still in the early stages of the thincrust project, however some of the things we have been working on are:
1. Light weight base OS = AOS, currently a fedora spin 2. Tool to build reproducible appliance images form kickstart files, appliance-creator, see the tooling section or the appliance-tools rpm. 3. Best practices and tools for post install setup for "appliances", we are currently using puppet, see the "ACE" section of the web site.
Please check out the site and let us know if there any questions or feedback.
One of the next steps for thincurst is to redefine the AOS package set to make it smaller, more fine gained, and more reusable/extendible, which seems to similar to some of the goals of the server list.
more comments below....
it has been some time when the Server SIG was announced. And one goal has been already almost accomplished - to start discussion about the needs of the server community. For "Server" specific issues I have opened our own mailing list - subscribe at https://admin.fedoraproject.org/mailman/listinfo/fedora-server-list
One question raised during the discussions was "what is a server" and the answer can be simple. The server is a combination of bootloader, kernel and "the server", where "the server" can be a file server, web server, database server, application server, etc. It is quite common to have just one service running per hardware (both physical and virtual). But a mix of running servers is also possible :-)
We have a similar definition for an appliance.
There are miscellaneous goals written on the wiki page, so it is time to get them a little bit organized and to divide the work into more specific areas. And they are here:
Installer
- work with the anaconda team to keep anaconda suitable for server
installs (text mode, kickstarts, ...)
- create a lightweight installer/bootstraper
see the appliance-creator, http://thincrust.net/tooling.html
Server services
- bring more server packages into Fedora
- encourage creation of EPEL branches for existing packages
Kernel
- everything about the kernel side of servers
We have not done anything here, however we have discussed pulling out some kernel modules that are not needed for virtual appliances. There is not an easy way of doing this without "breaking" rpm, current thinking is to use white/black listing of actual files.
Admins corner
- place for administration and monitoring technologies available in
Fedora
- collects pointers to how-tos and other docs useful for administrators
- work on the TUI counterparts of GUI system-config-* tools, should go
in hand with the backend/frontend separation
See: http://thincrust.net/ace-console.html
Security
- improve/monitor the security standards for current server software
- help the desktop developers with the security aspects of their work
QA
- testing
Comments and suggestions welcome.....
-D
On Mon, 2009-01-05 at 14:37 -0500, David Huff wrote:
Server services
- bring more server packages into Fedora
- encourage creation of EPEL branches for existing packages
Kernel
- everything about the kernel side of servers
We have not done anything here, however we have discussed pulling out some kernel modules that are not needed for virtual appliances. There is not an easy way of doing this without "breaking" rpm, current thinking is to use white/black listing of actual files.
Do not work outside of rpm for these things. Work within the system you have available and/or modify it upstream. Working outside of it means that all the tools we already have to work on things w/i the rpm framework have to be modified to work nicely with what you're trying to do.
that's just extra pain.
-sv
seth vidal píše v Po 05. 01. 2009 v 14:40 -0500:
On Mon, 2009-01-05 at 14:37 -0500, David Huff wrote:
Server services
- bring more server packages into Fedora
- encourage creation of EPEL branches for existing packages
Kernel
- everything about the kernel side of servers
We have not done anything here, however we have discussed pulling out some kernel modules that are not needed for virtual appliances. There is not an easy way of doing this without "breaking" rpm, current thinking is to use white/black listing of actual files.
Do not work outside of rpm for these things. Work within the system you have available and/or modify it upstream. Working outside of it means that all the tools we already have to work on things w/i the rpm framework have to be modified to work nicely with what you're trying to do.
Is this about the size of the kernel rpm package or the size of running kernel and ramdisk?
Dan
Dan Horák wrote:
seth vidal píše v Po 05. 01. 2009 v 14:40 -0500:
On Mon, 2009-01-05 at 14:37 -0500, David Huff wrote:
Server services
- bring more server packages into Fedora
- encourage creation of EPEL branches for existing packages
Kernel
- everything about the kernel side of servers
We have not done anything here, however we have discussed pulling out some kernel modules that are not needed for virtual appliances. There is not an easy way of doing this without "breaking" rpm, current thinking is to use white/black listing of actual files.
Do not work outside of rpm for these things. Work within the system you have available and/or modify it upstream. Working outside of it means that all the tools we already have to work on things w/i the rpm framework have to be modified to work nicely with what you're trying to do.
Is this about the size of the kernel rpm package or the size of running kernel and ramdisk?
We were more thinking of rpm package size, and the "foot-print" of a virtual server appliance. Not all of the kernel modules are needed to run in a VC.
As I said we haven't don much here, it was just something that had come up in some discussions.
-D
On Tue, 2009-01-06 at 10:32 -0500, David Huff wrote:
Dan Horák wrote:
seth vidal píše v Po 05. 01. 2009 v 14:40 -0500:
On Mon, 2009-01-05 at 14:37 -0500, David Huff wrote:
Server services
- bring more server packages into Fedora
- encourage creation of EPEL branches for existing packages
Kernel
- everything about the kernel side of servers
We have not done anything here, however we have discussed pulling out some kernel modules that are not needed for virtual appliances. There is not an easy way of doing this without "breaking" rpm, current thinking is to use white/black listing of actual files.
Do not work outside of rpm for these things. Work within the system you have available and/or modify it upstream. Working outside of it means that all the tools we already have to work on things w/i the rpm framework have to be modified to work nicely with what you're trying to do.
Is this about the size of the kernel rpm package or the size of running kernel and ramdisk?
We were more thinking of rpm package size, and the "foot-print" of a virtual server appliance. Not all of the kernel modules are needed to run in a VC.
What kind of footprint are you looking for? Pulling out kernel modules are 1. not going to save you that much space and 2. limiting the hw you can run on.
-sv
seth vidal píše v Út 06. 01. 2009 v 10:56 -0500:
On Tue, 2009-01-06 at 10:32 -0500, David Huff wrote:
Dan Horák wrote:
seth vidal píše v Po 05. 01. 2009 v 14:40 -0500:
On Mon, 2009-01-05 at 14:37 -0500, David Huff wrote:
Server services
- bring more server packages into Fedora
- encourage creation of EPEL branches for existing packages
Kernel
- everything about the kernel side of servers
We have not done anything here, however we have discussed pulling out some kernel modules that are not needed for virtual appliances. There is not an easy way of doing this without "breaking" rpm, current thinking is to use white/black listing of actual files.
Do not work outside of rpm for these things. Work within the system you have available and/or modify it upstream. Working outside of it means that all the tools we already have to work on things w/i the rpm framework have to be modified to work nicely with what you're trying to do.
Is this about the size of the kernel rpm package or the size of running kernel and ramdisk?
We were more thinking of rpm package size, and the "foot-print" of a virtual server appliance. Not all of the kernel modules are needed to run in a VC.
What kind of footprint are you looking for? Pulling out kernel modules are 1. not going to save you that much space and
IMHO it can
- limiting the hw you
can run on.
the set of virtual hardware is very limited
Dan
seth vidal wrote:
On Tue, 2009-01-06 at 10:32 -0500, David Huff wrote:
Dan Horák wrote:
seth vidal píše v Po 05. 01. 2009 v 14:40 -0500:
On Mon, 2009-01-05 at 14:37 -0500, David Huff wrote:
Server services
- bring more server packages into Fedora
- encourage creation of EPEL branches for existing packages
Kernel
- everything about the kernel side of servers
We have not done anything here, however we have discussed pulling out some kernel modules that are not needed for virtual appliances. There is not an easy way of doing this without "breaking" rpm, current thinking is to use white/black listing of actual files.
Do not work outside of rpm for these things. Work within the system you have available and/or modify it upstream. Working outside of it means that all the tools we already have to work on things w/i the rpm framework have to be modified to work nicely with what you're trying to do.
Is this about the size of the kernel rpm package or the size of running kernel and ramdisk?
We were more thinking of rpm package size, and the "foot-print" of a virtual server appliance. Not all of the kernel modules are needed to run in a VC.
What kind of footprint are you looking for? Pulling out kernel modules are 1. not going to save you that much space and 2. limiting the hw you can run on.
We have heard some folks say "I dont care", since they are running higher level applictions which include Java or Ruby. We have heard other folks really concered with size (32/64 meg). The latter set is more on the embedded side of appliancees.
-- bk
On Wed, 2009-01-07 at 08:28 -0500, Bryan Kearney wrote:
We have heard some folks say "I dont care", since they are running higher level applictions which include Java or Ruby. We have heard other folks really concered with size (32/64 meg). The latter set is more on the embedded side of appliancees.
So doesn't it make more sense to have the people with the special size needs build their own kernel pkg than rm files from the existing kernel pkg in %post?
-sv
seth vidal wrote:
On Wed, 2009-01-07 at 08:28 -0500, Bryan Kearney wrote:
We have heard some folks say "I dont care", since they are running higher level applictions which include Java or Ruby. We have heard other folks really concered with size (32/64 meg). The latter set is more on the embedded side of appliancees.
So doesn't it make more sense to have the people with the special size needs build their own kernel pkg than rm files from the existing kernel pkg in %post?
It may.. .if they are really interested in size, whitelisting (or blacklisting) is a common approach. Those users tend to focus on image based updates as opposed to rpm based updates.
We have tried to limit the use of whitelising in the appliance tools (acutally livecd tools) by adding code to set the rpm macros which hits the common issues of docs and locales.
-- bk
David Huff píše v Út 06. 01. 2009 v 10:32 -0500:
Dan Horák wrote:
seth vidal píše v Po 05. 01. 2009 v 14:40 -0500:
On Mon, 2009-01-05 at 14:37 -0500, David Huff wrote:
Server services
- bring more server packages into Fedora
- encourage creation of EPEL branches for existing packages
Kernel
- everything about the kernel side of servers
We have not done anything here, however we have discussed pulling out some kernel modules that are not needed for virtual appliances. There is not an easy way of doing this without "breaking" rpm, current thinking is to use white/black listing of actual files.
Do not work outside of rpm for these things. Work within the system you have available and/or modify it upstream. Working outside of it means that all the tools we already have to work on things w/i the rpm framework have to be modified to work nicely with what you're trying to do.
Is this about the size of the kernel rpm package or the size of running kernel and ramdisk?
We were more thinking of rpm package size, and the "foot-print" of a virtual server appliance. Not all of the kernel modules are needed to run in a VC.
And the foot-print is quite massive - the installed size of the kernel rpm is more then 70 MB in F-10 on x86_64. And IMHO that could be lowered to 10 MB of base kernel and all the required modules.
As I said we haven't don much here, it was just something that had come up in some discussions.
But it illustrates an existing issue.
Maybe some rpm repackager can be developed to split the standard binary kernel rpm into a set of subpackages.
Dan
David Huff píše v Po 05. 01. 2009 v 14:37 -0500:
From dan at danny.cz Mon Dec 1 14:05:39 2008 From: dan at danny.cz (Dan =?ISO-8859-1?Q?Hor=E1k?=) Date: Mon, 01 Dec 2008 15:05:39 +0100 Subject: Server SIG - work areas Message-ID: 1228140339.3664.75.camel@eagle.danny.cz
Hello,
Sorry for replying to an old thread however I am just now catching up on the discussions from this list. My first impression is that there looks to be a lot in common with the server sig and the "thincrust" project, www.thincrust.org. We are still in the early stages of the thincrust project, however some of the things we have been working on are:
Oh, it's never too late for a good discussion about the effective use our limited resources :-)
- Light weight base OS = AOS, currently a fedora spin
- Tool to build reproducible appliance images form kickstart files,
appliance-creator, see the tooling section or the appliance-tools rpm. 3. Best practices and tools for post install setup for "appliances", we are currently using puppet, see the "ACE" section of the web site.
Please check out the site and let us know if there any questions or feedback.
There is a nice overlap with the Server SIG goals in my opinion.
One of the next steps for thincurst is to redefine the AOS package set to make it smaller, more fine gained, and more reusable/extendible, which seems to similar to some of the goals of the server list.
more comments below....
it has been some time when the Server SIG was announced. And one goal has been already almost accomplished - to start discussion about the needs of the server community. For "Server" specific issues I have opened our own mailing list - subscribe at https://admin.fedoraproject.org/mailman/listinfo/fedora-server-list
One question raised during the discussions was "what is a server" and the answer can be simple. The server is a combination of bootloader, kernel and "the server", where "the server" can be a file server, web server, database server, application server, etc. It is quite common to have just one service running per hardware (both physical and virtual). But a mix of running servers is also possible :-)
We have a similar definition for an appliance.
And there were rumours that it is hard to define a server. Only your focus is on the virtual hardware.
There are miscellaneous goals written on the wiki page, so it is time to get them a little bit organized and to divide the work into more specific areas. And they are here:
Installer
- work with the anaconda team to keep anaconda suitable for server
installs (text mode, kickstarts, ...)
- create a lightweight installer/bootstraper
see the appliance-creator, http://thincrust.net/tooling.html
Yes, perhaps with only the support for real hardware missing after a very brief view.
Kernel
- everything about the kernel side of servers
We have not done anything here, however we have discussed pulling out some kernel modules that are not needed for virtual appliances. There is not an easy way of doing this without "breaking" rpm, current thinking is to use white/black listing of actual files.
Admins corner
- place for administration and monitoring technologies available in
Fedora
- collects pointers to how-tos and other docs useful for administrators
- work on the TUI counterparts of GUI system-config-* tools, should go
in hand with the backend/frontend separation
Complex system management in Linux environment generally is not optimal.
Dan
Dan Horák wrote:
Oh, it's never too late for a good discussion about the effective use our limited resources :-)
I agree
And there were rumours that it is hard to define a server. Only your focus is on the virtual hardware.
Although most of the focus is on Virtual Servers, running in an virtual container, we still acknowledge that an appliance can be a traditional "bare metal" appliance, and there are some benefits to running on real hardware. Most everything we have done will also work on bare metal.
- create a lightweight installer/bootstraper
see the appliance-creator, http://thincrust.net/tooling.html
Yes, perhaps with only the support for real hardware missing after a very brief view.
although the appliance creator tool is designed to spit out a "virtual disk image" since all its doing is a chrooted yum install from a ks file there are already tools out there that can do the same for a bare metal, livecd-creator and anaconda.
Although I will admit there are some differences in a box built with anaconda and livecd-creator using the same kickstart file.
-D
server@lists.fedoraproject.org
-
Bryan Kearney -
Dan Horák -
David Huff -
Seth Vidal