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

[Jeroen van Meeuwen]

Bryan Kearney wrote:
>> The name I would choose to give to this spin is "Fedora AOS" (at which 
>> point the name of the kickstart becomes "fedora-livecd-aos.ks" or 
>> possibly just "fedora-live-aos.ks".
> 
> Good comment. I have renamed it fedora-aos.ks. This seems to take the 
> heart of your suggestion as well as reflect the fact that this is an 
> image not an ISO.
> 

Point taken, accepted.

>>
>> == Feature Page ==
>>
>> The feature page is more extensive then other Spin's feature pages 
>> because this particular spin is only part of a feature. To be able to 
>> track the Spin Feature separately, we may need a separate AOS Spin 
>> Feature page. I'm not sure how other involved parties are seeing this 
>> (eg. Feature wrangler / Release Engineering).
> 
> At the FESCo meeting, I was told to submit the feeature to RE. I think 
> it is good enough, but am happy to break out another tracking feature if 
> that is necessary.
> 

OK, if FESCo has addressed this there is no need to change anything ;-)

>> Whereas the appliance-tools has additional features compared to 
>> livecd-tools, this particular spin is a perfect showcase, and a great 
>> way to test whatever it is someone might want to do.
>>
>> It may need a little clarification though on why a user should use 
>> this spin (eg. scope and target audience things).
> 
> I re-worked the benefits section of the feature [1] to make clear what 
> the AOS was providing. Does that address the concern?
> 

WORKSFORME. I hope Release Engineering agrees since they are the ones 
empowered by FESCo to approve Spin Features as real Features.

>>
>> == 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.

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

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

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

> Thanks again. Updated kickstart file is attached.
> 

Thanks for the quick response.