I would like to submit for approval an Appliance Operating System (AOS) Spin. This spin is part of the appliance-tools feature [1] and also part of the thincrust project [2]. The Kickstart file can be found in the repo [3] but I have flattened it and attached it to this email.
The goal of this spin is to provide a minimal base upon which software appliances can be built. The main deployment for appliances is expected to be virtual machine, but since there are no kernel changes this could work bare metal as well. This would be the fedora implementation of a JeOS [4].
We would like to target this for Fedora 10. Please let me know what next steps would be.
Thank you.
-- bk
[1] https://fedoraproject.org/wiki/Features/appliance-tools [2] http://www.thincrust.net [3] http://git.et.redhat.com/?p=act.git;a=tree;f=config [4] http://en.wikipedia.org/wiki/Just_enough_operating_system_(JeOS)
Bryan Kearney wrote:
I would like to submit for approval an Appliance Operating System (AOS) Spin. This spin is part of the appliance-tools feature [1] and also part of the thincrust project [2]. The Kickstart file can be found in the repo [3] but I have flattened it and attached it to this email.
The goal of this spin is to provide a minimal base upon which software appliances can be built. The main deployment for appliances is expected to be virtual machine, but since there are no kernel changes this could work bare metal as well. This would be the fedora implementation of a JeOS [4].
First of all, it's great to see this "special" spin being submitted for review and possibly being released alongside Fedora 10 as a perfect showcase of how both spins as well as the JeOS or AOS work.
== Name ==
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".
== 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).
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).
== 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.
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.
3) the partitioning configuration has --ondisk sda as well as --fstype ext3 which is not taken into account with creating a live spin.
4) the package manifest includes @core, which is included already
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.
6) the network isn't started on boot. Note that the network service does not start on boot by default anymore, in favor of the NetworkManager service, which is not available on this spin, and which I think would also not be favorable to the spin's specific use case.
== Image Size ==
The image size composed against today's rawhide is 117M, which should definitely fit on a CD (~690-700M), or some of the even smaller media for that matter.
Noted the aforementioned issues this overall looks as a great spin to include in the release. Please change or motivate the issues set forth and we'll gladly take another stab at this spin ;-)
Kind regards,
Jeroen van Meeuwen -kanarip
Thank you for reviewing. I am going to respond to the items below, and also introduce the issue that we would like to see this spin delivered not as an ISO, but as a disk image. That will help scope some of the answers below. This will change the release engineering a bit as the image will need to be built with the appliance-tools, istead of livecd-tools. The appliance-tools are based on the livecd-tools base clases, so the process should not be much different.
Comments below. David Huff, please see the question on SELinux.
Jeroen van Meeuwen wrote:
Bryan Kearney wrote:
I would like to submit for approval an Appliance Operating System (AOS) Spin. This spin is part of the appliance-tools feature [1] and also part of the thincrust project [2]. The Kickstart file can be found in the repo [3] but I have flattened it and attached it to this email.
The goal of this spin is to provide a minimal base upon which software appliances can be built. The main deployment for appliances is expected to be virtual machine, but since there are no kernel changes this could work bare metal as well. This would be the fedora implementation of a JeOS [4].
First of all, it's great to see this "special" spin being submitted for review and possibly being released alongside Fedora 10 as a perfect showcase of how both spins as well as the JeOS or AOS work.
== Name ==
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.
== 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.
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?
== 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.
- 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.
- 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.
- the package manifest includes @core, which is included already
Removed it.
- 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.
- the network isn't started on boot. Note that the network service does
not start on boot by default anymore, in favor of the NetworkManager service, which is not available on this spin, and which I think would also not be favorable to the spin's specific use case.
I added a services line to enable this at startup.
== Image Size ==
The image size composed against today's rawhide is 117M, which should definitely fit on a CD (~690-700M), or some of the even smaller media for that matter.
Noted the aforementioned issues this overall looks as a great spin to include in the release. Please change or motivate the issues set forth and we'll gladly take another stab at this spin ;-)
Kind regards,
Jeroen van Meeuwen -kanarip
Thanks again. Updated kickstart file is attached.
--bk
[1] https://fedoraproject.org/wiki/Features/ApplianceTools#Benefit_to_Fedora
Bryan Kearney wrote:
Thank you for reviewing. I am going to respond to the items below, and also introduce the issue that we would like to see this spin delivered not as an ISO, but as a disk image. That will help scope some of the answers below. This will change the release engineering a bit as the image will need to be built with the appliance-tools, istead of livecd-tools. The appliance-tools are based on the livecd-tools base clases, so the process should not be much different.
This is a point we need to pass through release engineering (in CC:).
Could release engineering please review/address this particular request?
Kind regards,
Jeroen van Meeuwen -kanarip
Jeroen van Meeuwen wrote:
Bryan Kearney wrote:
Thank you for reviewing. I am going to respond to the items below, and also introduce the issue that we would like to see this spin delivered not as an ISO, but as a disk image. That will help scope some of the answers below. This will change the release engineering a bit as the image will need to be built with the appliance-tools, istead of livecd-tools. The appliance-tools are based on the livecd-tools base clases, so the process should not be much different.
This is a point we need to pass through release engineering (in CC:).
Could release engineering please review/address this particular request?
Note that appliance-tools is not yet in rawhide, but has a completed review request / cvs done in RH BZ https://bugzilla.redhat.com/show_bug.cgi?id=457152 (no builds in koji yet and no CVS import yet that I can see).
Hence the appliance-tools util has not been used by the Spin SIG to technically review the spin concept (yet), but we've been using livecd-tools.
Kind regards,
Jeroen van Meeuwen -kanarip
Jeroen van Meeuwen wrote:
Jeroen van Meeuwen wrote:
Bryan Kearney wrote:
Thank you for reviewing. I am going to respond to the items below, and also introduce the issue that we would like to see this spin delivered not as an ISO, but as a disk image. That will help scope some of the answers below. This will change the release engineering a bit as the image will need to be built with the appliance-tools, istead of livecd-tools. The appliance-tools are based on the livecd-tools base clases, so the process should not be much different.
This is a point we need to pass through release engineering (in CC:).
Could release engineering please review/address this particular request?
Note that appliance-tools is not yet in rawhide, but has a completed review request / cvs done in RH BZ https://bugzilla.redhat.com/show_bug.cgi?id=457152 (no builds in koji yet and no CVS import yet that I can see).
Hence the appliance-tools util has not been used by the Spin SIG to technically review the spin concept (yet), but we've been using livecd-tools.
Kind regards,
Jeroen van Meeuwen -kanarip
Just wanted to check in with both groups. What are the next steps which Huff and I should be taking to ensure the spin is in F10?
Thanks in advance!
-- bk
Jeroen van Meeuwen wrote:
Note that appliance-tools is not yet in rawhide, but has a completed review request / cvs done in RH BZ https://bugzilla.redhat.com/show_bug.cgi?id=457152 (no builds in koji yet and no CVS import yet that I can see).
Hence the appliance-tools util has not been used by the Spin SIG to technically review the spin concept (yet), but we've been using livecd-tools.
Jeroen:
With the effects of last week, do you have new dates for spin requests and reviews? I want to make sure we are on track for the aos spin.
-- bk
Bryan Kearney wrote:
Jeroen van Meeuwen wrote:
Note that appliance-tools is not yet in rawhide, but has a completed review request / cvs done in RH BZ https://bugzilla.redhat.com/show_bug.cgi?id=457152 (no builds in koji yet and no CVS import yet that I can see).
This has been taken care of, the first build of appliance-tools is in koji. The only issue is that it requires a newer version of livecd-tools with the latest patches applied. I have created a temporary version of livecd-tools to use for testing until an official build is out(looks to be this week,) every thing is available here for testing:
thincrust.org/download
Hence the appliance-tools util has not been used by the Spin SIG to technically review the spin concept (yet), but we've been using livecd-tools.
Jeroen:
With the effects of last week, do you have new dates for spin requests and reviews? I want to make sure we are on track for the aos spin.
-- bk
Is there anything we can do to help out here? Do we need to submit an aos kisckstart file to the spin repo?
Ps. for some reason I am having issues being added to the fedora-spins@lists.fedoraproject.org if anyone can help me I would appreciate it.
-D
David Huff wrote:
Ps. for some reason I am having issues being added to the fedora-spins@lists.fedoraproject.org if anyone can help me I would appreciate it.
Added you to the list, you should have received a notification.
Kind regards,
Jeroen van Meeuwen -kanarip
Bryan Kearney wrote:
Jeroen van Meeuwen wrote:
Note that appliance-tools is not yet in rawhide, but has a completed review request / cvs done in RH BZ https://bugzilla.redhat.com/show_bug.cgi?id=457152 (no builds in koji yet and no CVS import yet that I can see).
Hence the appliance-tools util has not been used by the Spin SIG to technically review the spin concept (yet), but we've been using livecd-tools.
Jeroen:
With the effects of last week, do you have new dates for spin requests and reviews? I want to make sure we are on track for the aos spin.
With the suggested changes and the continuing effort to put appliance-tools as well as a patched version of livecd-tools into rawhide, I can approve this spin.
Next steps are to request Board Trademark approval, followed by getting FESCo's approval for the feature (which I think as a general feature has been approved already), for which (as far as the spins is concerned) FESCo has enforced release engineering. I think a very, very hard requirement on their end is that both appliance-tools and the patched version of livecd-tools land in rawhide, but I'll leave that to them ;-)
Would the spin maintainers (bkearney and dhuff) please request commit access to the spin-kickstarts repository by means of joining the gitspin-kickstarts group at https://admin.fedoraproject.org/accounts/group/view/gitspin-kickstarts ?
I'll be pushing the latest version of fedora-aos.ks into the repo shortly.
Kind regards,
Jeroen van Meeuwen -kanarip
Jeroen van Meeuwen wrote:
Bryan Kearney wrote:
Jeroen van Meeuwen wrote:
With the suggested changes and the continuing effort to put appliance-tools as well as a patched version of livecd-tools into rawhide, I can approve this spin.
Next steps are to request Board Trademark approval,
Is this done at a board IRC meeting?
followed by getting
FESCo's approval for the feature (which I think as a general feature has been approved already), for which (as far as the spins is concerned) FESCo has enforced release engineering. I think a very, very hard requirement on their end is that both appliance-tools and the patched version of livecd-tools land in rawhide, but I'll leave that to them ;-)
Do we put in tickets for this for RELENG?
-- bk
Bryan Kearney wrote:
Jeroen van Meeuwen wrote:
Bryan Kearney wrote:
Jeroen van Meeuwen wrote:
With the suggested changes and the continuing effort to put appliance-tools as well as a patched version of livecd-tools into rawhide, I can approve this spin.
Next steps are to request Board Trademark approval,
Is this done at a board IRC meeting?
I guess it happens at a Board meeting in general, by submitting the abstract / wiki page to fedora-advisory-board@redhat.com, with a topic similar to:
Request for Trademark Approval (Fedora AOS Spin)
Do we put in tickets for this for RELENG?
I do not see tickets for creating spins currently, that is in the release engineering trac instance on fedorahosted.org, and I guess that once the board approves the trademark usage, FESCo's Feature Wrangler will put the Feature page into the correct Category which is also a tracker location for Release Engineering, but correct me if I'm wrong.
Kind regards,
Jeroen van Meeuwen -kanarip
On Thu, 2008-08-28 at 15:03 +0200, Jeroen van Meeuwen wrote:
Bryan Kearney wrote:
Jeroen van Meeuwen wrote:
Bryan Kearney wrote:
Jeroen van Meeuwen wrote:
With the suggested changes and the continuing effort to put appliance-tools as well as a patched version of livecd-tools into rawhide, I can approve this spin.
Next steps are to request Board Trademark approval,
Is this done at a board IRC meeting?
I guess it happens at a Board meeting in general, by submitting the abstract / wiki page to fedora-advisory-board@redhat.com, with a topic similar to:
Request for Trademark Approval (Fedora AOS Spin)
That method has worked fine thus far. We look at these every week.
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...
- 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.
- 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.
- 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).
- 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.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
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.
Jeroen van Meeuwen wrote:
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...
- 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.
David
- 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 will comment this out, defaulting it to a blank password.
- 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).
Added a comment.
- 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.
Updated kickstart file is attached.
-- bk