Forwarding from David huff, who is having posting permissions fun.
-- bk
-------- Original Message -------- Subject: [Fwd: Re: [Fedora-spins] Appliance Operating System (AOS) REVIEW - NEEDINFO] Date: Thu, 14 Aug 2008 10:52:46 -0400 From: David Huff dhuff@redhat.com To: Bryan Kearney bkearney@redhat.com
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
- -------- Original Message -------- Subject: Re: [Fedora-spins] Appliance Operating System (AOS) REVIEW - NEEDINFO Date: Thu, 14 Aug 2008 10:20:27 -0400 From: David Huff dhuff@redhat.com To: Jeroen van Meeuwen kanarip@kanarip.com CC: The Spin Special Interest Group mailing list fedora-spins@lists.fedoraproject.org References: 48A172BD.9060109@redhat.com 48A369CB.7060002@kanarip.com 48A4200E.9010907@redhat.com 48A4319A.4070003@kanarip.com
Jeroen van Meeuwen wrote:
== Kickstart ==
First of all, since this is a unique spin concept in that it has a specific goal, these notes and corresponding feedback needs to be taken into account by the Spin SIG as well as the spin maintainers...
- SELinux on this spin is disabled. Although understandable, we
would like to see if SELinux could be enabled, or hear about why it is disabled entirely (rather then set permissive). SELinux is a major major feature in Fedora as well as RHEL, so we would like to preserve SELinux as a feature on all spins.
There is an issue with the appliance-tools and selinux. I will need to defer to David Huff on this and have him respond in a separate message.
The existing issue is that if livecd-tools and so also probably appliance-tools is run on a box with SELinux in enforcing mode, inside the chroot the right context cannot be set. Spins are therefor composed on hosts with SELinux set to permissive mode.
This is exactly the case. Also in order to cut down on size we have removed a lot of the selinux packages in the kickstart file, which im not really sure how much size that saves. I agree that it would be nice to have selinux enable by default which would require building the image on a box that has selinux enabled. However the sad reality is that most isvs and/or 3rd party software run with selinux disabled. However I do not have a problem with enabling selinux by default.
- A root password is set, which is understandable for real live
systems but is not conform the other spin concepts where an additional, normal user is created and the root password is removed. If there is a motivation for setting a root password and not creating a (regular) user in this spin concept, please let us know.
This spin is really seen as a base upon which someone would "build" an appliance. As appliances tend to be locked down in most cases, the root user is probably the only user who would log into the machine. Anyone building upon this would probably want to remove the user.
True as far as the custom user is concerned, however a default password for the root user is worse then no password, given that remote access is prevented when not having a password, while allowed when knowing the default password. Although this spin does not contain nor start sshd, I can only assume that is the first thing some people will want to add. Additionally, it has been proven a pain in the *ss to communicate a default password alongside a spin.
I am fine with take off the rootpw. I think the only reason we set it is b.c we had issues with building an image without one. However form your above statements it looks like the appropriate work around is to remove the root pw in the post section as well as creating a normal user.
- the partitioning configuration has --ondisk sda as well as
--fstype ext3 which is not taken into account with creating a live spin.
The appliance-tools do take these into acocunt, and utilize them to set up the partitioning on disk.
Noted, and maybe worth a little comment entry in the kickstart - it doesn't really apply to this particular spin that we would be releasing via the Fedora Project, but it does apply for people wanting to continue and build upon this spin (and use this kickstart).
sounds good
- the kickstart removes fedora-logos, but does not add another logos
package, resulting in that fedora-logos still ends up on the image. A minor problem for when the spin is approved by the Board for trademark usage, but you may want to add "generic-logos" to the manifest for now.
I have added in generic logos. Once the new tradmark policy is put into place, I would like to add the secondary marks to this kickstart file.
Yes, after trademark approval by the board, you are allowed to kick back in the fedora-logos package as well.
agreed
Thanks again. Updated kickstart file is attached.
Thanks for the quick response.
-
Bryan Kearney