[Fedora-spins] [Fwd: [Fwd: Re: Appliance Operating System (AOS) REVIEW - NEEDINFO]]

[Bryan Kearney]

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 at redhat.com>
To: Bryan Kearney <bkearney at 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 at redhat.com>
To: Jeroen van Meeuwen <kanarip at kanarip.com>
CC: The Spin Special Interest Group mailing list
<fedora-spins at lists.fedoraproject.org>
References: <48A172BD.9060109 at redhat.com> <48A369CB.7060002 at kanarip.com>
<48A4200E.9010907 at redhat.com> <48A4319A.4070003 at 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...
>>>
>>> 1) 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.
>
>>> 2) 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.
>
>>>
>>> 3) 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

>
>>> 5) 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.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkikRrwACgkQccHK32ogu/fdOwCfe+hIp+Hk3c/j366ObxVALPhC
ZvkAnRSYm2wD/W2H+nBkOP3Jnks8aS/p
=/2Fw
-----END PGP SIGNATURE-----