One of the biggest areas of overlap between the server sig and thincrust is in a minimum package set definition that can be extended for different needs/applications.
Thincrust already includes an official Fedora spin, the AOS, which is hosted in the "spin kickstart pool"[1]. The AOS is basically a kickstart file describing a minimal appliance OS that includes: the kernel, yum, dns, grub, and se-linux, all working on start-up.
The first cut of the AOS was built by removing everything, ie. not including core or base, and adding the packages we needed. We also tired to exclude extra packages that got brought in as deps. This produces an disk image of 140 packages and is ~360M.
While I am not saying this is the prettiest and/or the best approach, it was a quick way of producing a working appliance definition with a relatively small foot print using the current tools.
Ideally any "Server spin" would be extensions of this minimum OS definition. I would love to see the the AOS definition evolve to become a better and smaller minimum OS definition.
I am in the process of defining the AOS requirements[2] for the F-11 Spin and would love to get some feedback from the server sig.
I am looking for ideas/suggestion/opinions on what would be the best way of redefine the AOS into a smaller, more fine gained, minimum server definition. Something that can be easily be extended by others?
-D
[1] http://git.fedorahosted.org/git/?p=spin-kickstarts.git;a=blob_plain;f=fedora...
David Huff wrote:
One of the biggest areas of overlap between the server sig and thincrust is in a minimum package set definition that can be extended for different needs/applications.
Thincrust already includes an official Fedora spin, the AOS, which is hosted in the "spin kickstart pool"[1]. The AOS is basically a kickstart file describing a minimal appliance OS that includes: the kernel, yum, dns, grub, and se-linux, all working on start-up.
The first cut of the AOS was built by removing everything, ie. not including core or base, and adding the packages we needed. We also tired to exclude extra packages that got brought in as deps. This produces an disk image of 140 packages and is ~360M.
While I am not saying this is the prettiest and/or the best approach, it was a quick way of producing a working appliance definition with a relatively small foot print using the current tools.
Ideally any "Server spin" would be extensions of this minimum OS definition. I would love to see the the AOS definition evolve to become a better and smaller minimum OS definition.
While I'm not disagreeing, why not create "single CD install media" with an option (in the isolinux.cfg menu) to have the minimum (working) set of packages be installed, and the rest of the installation menu interactive (partitioning, root password)?
Bearing in mind that the Fedora Project already releases CDs, and that I've fixed package ordering, the simplest win would be to add the menu entry to the isolinux.cfg, and include one kickstart file on the disk with just a %packages section.
A user would still be able to run the normal installation procedure, or supply a different kickstart on the cmdline (including the %packages kickstart on the cdrom?) for full automation.
Just a thought Fedora Unity has been pondering on, at popular demand. I'm as far as getting Revisor into shape to do the job.
Kind regards,
Jeroen van Meeuwen -kanarip
On Tue, 2009-01-20 at 10:10 +0100, Jeroen van Meeuwen wrote:
While I'm not disagreeing, why not create "single CD install media" with an option (in the isolinux.cfg menu) to have the minimum (working) set of packages be installed, and the rest of the installation menu interactive (partitioning, root password)?
Bearing in mind that the Fedora Project already releases CDs, and that I've fixed package ordering, the simplest win would be to add the menu entry to the isolinux.cfg, and include one kickstart file on the disk with just a %packages section.
A user would still be able to run the normal installation procedure, or supply a different kickstart on the cmdline (including the %packages kickstart on the cdrom?) for full automation.
Just a thought Fedora Unity has been pondering on, at popular demand. I'm as far as getting Revisor into shape to do the job.
Kind regards,
Jeroen van Meeuwen -kanarip
Jeroen,
Correct me if I'm wrong, but do you mean by this that, effectively, there'd be a kind of menu that would allow, more or less, different "spins" or flavors of Fedora to be installed from the same installation media by default?
If so, I find that idea really fascinating, given that enough packages are able to fit on one CD to support more than one installation.
________________________________________________________________________
Basil Mohamed Gohar abu_hurayrah@hidayahonline.org www.basilgohar.com
Basil Mohamed Gohar wrote:
On Tue, 2009-01-20 at 10:10 +0100, Jeroen van Meeuwen wrote:
While I'm not disagreeing, why not create "single CD install media" with an option (in the isolinux.cfg menu) to have the minimum (working) set of packages be installed, and the rest of the installation menu interactive (partitioning, root password)?
Bearing in mind that the Fedora Project already releases CDs, and that I've fixed package ordering, the simplest win would be to add the menu entry to the isolinux.cfg, and include one kickstart file on the disk with just a %packages section.
A user would still be able to run the normal installation procedure, or supply a different kickstart on the cmdline (including the %packages kickstart on the cdrom?) for full automation.
Just a thought Fedora Unity has been pondering on, at popular demand. I'm as far as getting Revisor into shape to do the job.
Kind regards,
Jeroen van Meeuwen -kanarip
Jeroen,
Correct me if I'm wrong, but do you mean by this that, effectively, there'd be a kind of menu that would allow, more or less, different "spins" or flavors of Fedora to be installed from the same installation media by default?
Basically, yes. One option in the menu would only need the first CD (server install, 'minimum', or 'best minimum' packages), other options may need more then one CD. One other thing Fedora Unity has been pondering about is OEM installation discs, with what the Fedora Project thinks is the best installation default for a OEM vendor to install. This could very well go on the same (set of) media, of course, although the "best default" may need more then 1 CD, in which case we'd point vendors to the DVD.
Kind regards,
Jeroen van Meeuwen -kanarip
Jeroen van Meeuwen wrote:
Basil Mohamed Gohar wrote:
On Tue, 2009-01-20 at 10:10 +0100, Jeroen van Meeuwen wrote:
While I'm not disagreeing, why not create "single CD install media" with an option (in the isolinux.cfg menu) to have the minimum (working) set of packages be installed, and the rest of the installation menu interactive (partitioning, root password)?
Bearing in mind that the Fedora Project already releases CDs, and that I've fixed package ordering, the simplest win would be to add the menu entry to the isolinux.cfg, and include one kickstart file on the disk with just a %packages section.
A user would still be able to run the normal installation procedure, or supply a different kickstart on the cmdline (including the %packages kickstart on the cdrom?) for full automation.
I agree that this would be a good scenario, however what I am looking for is ideas on what should be included in that %package section and how can we deliver this. If we can get a good minimal package set defined and accepted by the community this could be used for many different applications, ie appliances, bare metal servers, or as you suggested at install time.
My experience has been that @core will not cut it because for our application we also need selinux, dns, and yum, and @core also pulls in a lot of stuff that is not needed. Using core and adding kernel, dnsclient, yum, and lokkit pulls in 156 packages and used 439M. There has go to be a better way to get a minimal package set....
Also how do we deliver it? Should this just be a kisckstart snippet with only a %package section? If so this could possible be included in the kickstart pool. or should this be a new comps group?
I have also included a package list of all the packages that are installed using @core and including adding kernel, dnsclient, yum, and lokkit
Comments....
-D
ConsoleKit-libs-0.2.10-3.fc9.x86_64 MAKEDEV-3.23-4.x86_64 audit-libs-1.7.2-6.fc9.x86_64 audit-libs-python-1.7.2-6.fc9.x86_64 authconfig-5.4.2-1.fc9.x86_64 basesystem-8.1-1.noarch bash-3.2-22.fc9.x86_64 bzip2-libs-1.0.5-1.fc9.x86_64 checkpolicy-2.0.14-1.fc9.x86_64 chkconfig-1.3.37-2.x86_64 coreutils-6.10-18.fc9.x86_64 cpio-2.9-7.fc9.x86_64 cracklib-2.8.12-2.x86_64 cracklib-dicts-2.8.12-2.x86_64 crontabs-1.10-19.fc9.noarch cyrus-sasl-lib-2.1.22-13.fc9.x86_64 db4-4.6.21-5.fc9.x86_64 dbus-1.2.1-1.fc9.x86_64 dbus-glib-0.74-6.fc9.x86_64 dbus-libs-1.2.1-1.fc9.x86_64 dbus-python-0.82.4-2.fc9.x86_64 device-mapper-1.02.24-11.fc9.x86_64 device-mapper-libs-1.02.24-11.fc9.x86_64 dhclient-4.0.0-14.fc9.x86_64 diffutils-2.8.1-21.fc9.x86_64 dirmngr-1.0.1-2.fc9.x86_64 dmraid-1.0.0.rc14-6.fc9.x86_64 e2fsprogs-1.40.8-2.fc9.x86_64 e2fsprogs-libs-1.40.8-2.fc9.x86_64 ed-0.8-2.fc9.x86_64 efibootmgr-0.5.4-4.fc9.x86_64 elfutils-libelf-0.133-3.fc9.x86_64 ethtool-6-1.fc9.x86_64 expat-2.0.1-5.x86_64 fedora-logos-9.0.0-2.fc9.noarch fedora-release-9-5.transition.noarch fedora-release-notes-9.0.0-1.noarch file-4.23-5.fc9.x86_64 file-libs-4.23-5.fc9.x86_64 filesystem-2.4.13-1.fc9.x86_64 findutils-4.2.33-3.fc9.x86_64 gamin-0.1.9-5.fc9.x86_64 gawk-3.1.5-17.fc9.x86_64 gdbm-1.8.0-28.fc9.x86_64 glib2-2.16.3-5.fc9.x86_64 glibc-2.8-3.x86_64 glibc-common-2.8-3.x86_64 gnupg2-2.0.9-1.fc9.x86_64 gpgme-1.1.6-3.fc9.x86_64 grep-2.5.1-59.fc9.x86_64 grub-0.97-33.fc9.x86_64 gzip-1.3.12-6.fc9.x86_64 hdparm-8.6-1.fc9.x86_64 hwdata-0.217-1.fc9.noarch info-4.11-5.fc9.x86_64 initscripts-8.76-1.x86_64 iproute-2.6.23-4.fc9.x86_64 iptables-1.4.0-4.fc9.x86_64 iptables-ipv6-1.4.0-4.fc9.x86_64 iputils-20071127-2.fc9.x86_64 isomd5sum-1.0.4-1.x86_64 kbd-1.12-31.fc9.x86_64 kernel-2.6.25-14.fc9.x86_64 keyutils-libs-1.2-3.fc9.x86_64 kpartx-0.4.7-11.fc7.x86_64 krb5-libs-1.6.3-10.fc9.x86_64 kudzu-1.2.85-1.x86_64 less-418-3.fc9.x86_64 libacl-2.2.47-1.fc9.x86_64 libattr-2.4.41-1.fc9.x86_64 libcap-2.06-4.fc9.x86_64 libcurl-7.18.1-1.fc9.x86_64 libdhcp-1.99.8-1.fc9.x86_64 libdhcp4client-4.0.0-14.fc9.x86_64 libdhcp6client-1.0.14-1.fc9.x86_64 libgcc-4.3.0-8.x86_64 libgcrypt-1.4.0-3.x86_64 libgpg-error-1.6-2.x86_64 libidn-0.6.14-7.x86_64 libksba-1.0.3-2.fc9.x86_64 libnl-1.1-3.fc9.x86_64 libselinux-2.0.61-1.fc9.x86_64 libselinux-python-2.0.61-1.fc9.x86_64 libsemanage-2.0.25-1.fc9.x86_64 libsepol-2.0.26-1.fc9.x86_64 libstdc++-4.3.0-8.x86_64 libsysfs-2.1.0-3.fc9.x86_64 libusb-0.1.12-15.fc9.x86_64 libuser-0.56.9-1.x86_64 libvolume_id-120-5.20080421git.fc9.x86_64 libxml2-2.6.32-1.fc9.x86_64 linux-atm-libs-2.5.0-5.x86_64 logrotate-3.7.6-3.fc9.x86_64 lvm2-2.02.33-11.fc9.x86_64 mdadm-2.6.4-4.fc9.x86_64 mingetty-1.08-2.fc9.x86_64 mkinitrd-6.0.52-2.fc9.x86_64 module-init-tools-3.4-13.fc9.x86_64 nash-6.0.52-2.fc9.x86_64 ncurses-5.6-16.20080301.fc9.x86_64 ncurses-base-5.6-16.20080301.fc9.x86_64 ncurses-libs-5.6-16.20080301.fc9.x86_64 net-tools-1.60-87.fc9.x86_64 newt-0.52.9-1.fc9.x86_64 newt-python-0.52.9-1.fc9.x86_64 nspr-4.7.0.99.2-2.fc9.x86_64 nss-3.11.99.5-2.fc9.x86_64 openldap-2.4.8-3.fc9.x86_64 openssl-0.9.8g-6.fc9.x86_64 pam-1.0.1-2.fc9.x86_64 parted-1.8.8-5.fc9.x86_64 passwd-0.75-2.fc9.x86_64 pciutils-2.2.10-1.fc9.x86_64 pcre-7.3-3.fc9.x86_64 pinentry-0.7.4-5.fc9.x86_64 policycoreutils-2.0.46-5.fc9.x86_64 popt-1.13-3.fc9.x86_64 prelink-0.4.0-3.x86_64 procps-3.2.7-20.fc9.x86_64 psmisc-22.6-5.fc9.x86_64 pth-2.0.7-6.x86_64 pygpgme-0.1-8.fc9.x86_64 python-2.5.1-25.fc9.x86_64 python-iniparse-0.2.3-3.fc9.noarch python-libs-2.5.1-25.fc9.x86_64 python-urlgrabber-3.0.0-6.fc9.noarch readline-5.2-13.fc9.x86_64 rhpl-0.215-3.x86_64 rootfiles-8.1-1.1.1.noarch rpm-4.4.2.3-2.fc9.x86_64 rpm-libs-4.4.2.3-2.fc9.x86_64 rpm-python-4.4.2.3-2.fc9.x86_64 rsyslog-3.14.1-2.fc9.x86_64 sed-4.1.5-10.fc9.x86_64 selinux-policy-3.3.1-42.fc9.noarch selinux-policy-targeted-3.3.1-42.fc9.noarch setserial-2.17-22.fc9.x86_64 setup-2.6.14-1.fc9.noarch shadow-utils-4.1.1-1.fc9.x86_64 slang-2.1.3-3.fc9.x86_64 sqlite-3.5.6-2.fc9.x86_64 system-config-firewall-tui-1.2.7-1.fc9.noarch system-config-network-tui-1.5.7-1.fc9.noarch sysvinit-tools-2.86-24.x86_64 tar-1.19-3.fc9.x86_64 tzdata-2008b-1.fc9.noarch udev-120-5.20080421git.fc9.x86_64 upstart-0.3.9-19.fc9.x86_64 usermode-1.96.1-1.x86_64 ustr-1.0.4-6.fc9.x86_64 util-linux-ng-2.13.1-6.fc9.x86_64 vim-minimal-7.1.291-1.fc9.x86_64 wireless-tools-29-2.fc9.x86_64 yum-3.2.14-10.fc9.noarch yum-metadata-parser-1.1.2-8.fc9.x86_64 zlib-1.2.3-18.fc9.x86_64
David Huff wrote:
Jeroen van Meeuwen wrote:
Basil Mohamed Gohar wrote:
On Tue, 2009-01-20 at 10:10 +0100, Jeroen van Meeuwen wrote:
While I'm not disagreeing, why not create "single CD install media" with an option (in the isolinux.cfg menu) to have the minimum (working) set of packages be installed, and the rest of the installation menu interactive (partitioning, root password)?
Bearing in mind that the Fedora Project already releases CDs, and that I've fixed package ordering, the simplest win would be to add the menu entry to the isolinux.cfg, and include one kickstart file on the disk with just a %packages section.
A user would still be able to run the normal installation procedure, or supply a different kickstart on the cmdline (including the %packages kickstart on the cdrom?) for full automation.
I agree that this would be a good scenario, however what I am looking for is ideas on what should be included in that %package section and how can we deliver this. If we can get a good minimal package set defined and accepted by the community this could be used for many different applications, ie appliances, bare metal servers, or as you suggested at install time.
My experience has been that @core will not cut it because for our application we also need selinux, dns, and yum, and @core also pulls in a lot of stuff that is not needed. Using core and adding kernel, dnsclient, yum, and lokkit pulls in 156 packages and used 439M. There has go to be a better way to get a minimal package set....
I think we're talking about two different things here; an Appliance OS, and a Server Spin.
An Appliance OS first of all should not even be built using a yum install; A real appliance would rebuild packages removing dependencies not needed by said appliance, and tweaking options building it for the hardware it's going to run on. Also, the AOS is a running system or live spin based on the idea it has to be minimal, which of course has it's benefits but differs fundamentally nonetheless.
Second is the Server Spin, which should just give you a server you can then turn into a full-blown Fedora 10 Desktop Server if you want; starting out with the absolute minimum packages doesn't make sense here, but what you'd want is 1) the installation to complete as fast as possible, 2) the overhead of installing then updating to be as small as possible, 3) simple media for the cheap CD-ROM drive you're only going to use once or twice, while not having to exchange discs, and 4) the system to be in a running state ready to be used after installation (including sshd running and a root password set which cannot be done with a live spin released by the Fedora Project). The fundamental difference is the Server Spin (on installation media) would just help you take the first stab at installing a system without going through the package selection dialog, maybe strip down the packages yet still have a fully functioning system (instead of a system designed to do one specific thing like an appliance).
Also how do we deliver it? Should this just be a kisckstart snippet with only a %package section? If so this could possible be included in the kickstart pool. or should this be a new comps group?
Kickstart is for package selection, comps for grouping packages. You can see how one complements the other, but not vice-versa.
I have also included a package list of all the packages that are installed using @core and including adding kernel, dnsclient, yum, and lokkit
I'm not sure which of these packages you would want to strip off. If yum, then again that brings out a fundamental difference between an Appliance OS and a Server Spin (on installation media).
Kind regards,
Jeroen van Meeuwen -kanarip
David Huff píše v Po 19. 01. 2009 v 17:36 -0500:
One of the biggest areas of overlap between the server sig and thincrust is in a minimum package set definition that can be extended for different needs/applications.
Thincrust already includes an official Fedora spin, the AOS, which is hosted in the "spin kickstart pool"[1]. The AOS is basically a kickstart file describing a minimal appliance OS that includes: the kernel, yum, dns, grub, and se-linux, all working on start-up.
The first cut of the AOS was built by removing everything, ie. not including core or base, and adding the packages we needed. We also tired to exclude extra packages that got brought in as deps. This produces an disk image of 140 packages and is ~360M.
While I am not saying this is the prettiest and/or the best approach, it was a quick way of producing a working appliance definition with a relatively small foot print using the current tools.
Ideally any "Server spin" would be extensions of this minimum OS definition. I would love to see the the AOS definition evolve to become a better and smaller minimum OS definition.
I am in the process of defining the AOS requirements[2] for the F-11 Spin and would love to get some feedback from the server sig.
I am looking for ideas/suggestion/opinions on what would be the best way of redefine the AOS into a smaller, more fine gained, minimum server definition. Something that can be easily be extended by others?
There is work done by Daniel Mach on more precise inter-package dependencies and on package vs. comps groups assignment. That should remove the need for manual package excludes. Or at least some of them.
Dan
Dan Horák wrote:
There is work done by Daniel Mach on more precise inter-package dependencies and on package vs. comps groups assignment. That should remove the need for manual package excludes. Or at least some of them.
This looks promising is there any additional information on this?
-D
David Huff wrote:
Dan Horák wrote:
There is work done by Daniel Mach on more precise inter-package dependencies and on package vs. comps groups assignment. That should remove the need for manual package excludes. Or at least some of them.
This looks promising is there any additional information on this?
-D
Currently there is no information at all. When I find a dependency which can be removed or changed, I just file a ticket and set Blocks: FedoraServerTracker. If you or someone else is interested to join this effort, I can create a wiki and write up some goals.
- daniel
server@lists.fedoraproject.org
-
Basil Mohamed Gohar -
Dan Horák -
Daniel Mach -
David Huff -
Jeroen van Meeuwen