1:37 p.m.
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(a)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
1:40 p.m.
New subject: Server SIG - work areas
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
8:44 a.m.
New subject: Server SIG - work areas
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(a)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 :-)
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.
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
See: http://thincrust.net/ace-console.html
Complex system management in Linux environment generally is not optimal.
Dan
8:57 a.m.
New subject: Server SIG - work areas
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
9:32 a.m.
New subject: Server SIG - work areas
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
9:47 a.m.
New subject: Server SIG - work areas
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
9:56 a.m.
New subject: Server SIG - work areas
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
10:18 a.m.
New subject: Server SIG - work areas
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
10:22 a.m.
New subject: Server SIG - work areas
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
2. limiting the hw you
can run on.
the set of virtual hardware is very limited
Dan
7:28 a.m.
New subject: Server SIG - work areas
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
7:46 a.m.
New subject: Server SIG - work areas
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
7:57 a.m.
New subject: Server SIG - work areas
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
5589
days inactive
5591
days old
server@lists.fedoraproject.org
11 comments
4 participants
participants (4)
-
Bryan Kearney -
Dan Horák -
David Huff -
Seth Vidal