1) Thinking about the newui Anaconda used as system-config-kickstart or disk image installer, one simple question (probably with no simple answer) came to my mind -- Do we need to run Anaconda as root in these cases? Or could we, at least, lower the privileges when we don't need them? I believe this could help us debug the unintentional modifications of the system and maybe, in some cases, actually fix it.
2) What if the user wants to use the newui Anaconda as a system-config-kickstart running for example Fedora 16 to make a kickstart for Fedora 18? We want such user to choose from the list of available layouts, but the lists of layouts for Fedora 16 and Fedora 18 differ. And I believe there are many such problems, not only with this one with the layouts configuration. So, should we create a separate package with a simple shell script (running Anaconda) and a bunch of various data that would allow Anaconda provide options depending on the target system rather than on the system Anaconda is running on?
On Mon, Jun 25, 2012 at 01:39:36PM +0200, Vratislav Podzimek wrote:
Thinking about the newui Anaconda used as system-config-kickstart or disk image installer, one simple question (probably with no simple answer) came to my mind -- Do we need to run Anaconda as root in these cases? Or could we, at least, lower the privileges when we don't need them? I believe this could help us debug the unintentional modifications of the system and maybe, in some cases, actually fix it.
It would be nice, but anything that deals with mounting (eg. mounting the disk.img file) has to be run as root. We could try to split off the parts that need root, but I think that the extra complexit ywould end up making the code harder to maintain.
What if the user wants to use the newui Anaconda as a system-config-kickstart running for example Fedora 16 to make a kickstart for Fedora 18? We want such user to choose from the list of available layouts, but the lists of layouts for Fedora 16 and Fedora 18 differ. And I believe there are many such problems, not only with this one with the layouts configuration. So, should we create a separate package with a simple shell script (running Anaconda) and a bunch of various data that would allow Anaconda provide options depending on the target system rather than on the system Anaconda is running on?
We have never supported cross-release creation of things. There are too many details to keep track of which would make maintenance a nightmare. With the image creation tools (livecd-creator, livemedia-creator, etc.) I recommend that they be run on the same release as what is being targeted in order to minimize problems. The one exception to this is Lorax which can make install media for the next release.
Thinking about the newui Anaconda used as system-config-kickstart or disk image installer, one simple question (probably with no simple answer) came to my mind -- Do we need to run Anaconda as root in these cases? Or could we, at least, lower the privileges when we don't need them? I believe this could help us debug the unintentional modifications of the system and maybe, in some cases, actually fix it.
Yes, we're going to want to run a newui-based s-c-ks as not root. This is probably going to be difficult, but we are likely to have to make newui run as non-root anyway for using it as a management front end.
I'm not going to worry with this until after F18.
What if the user wants to use the newui Anaconda as a system-config-kickstart running for example Fedora 16 to make a kickstart for Fedora 18? We want such user to choose from the list of available layouts, but the lists of layouts for Fedora 16 and Fedora 18 differ. And I believe there are many such problems, not only with this one with the layouts configuration. So, should we create a separate package with a simple shell script (running Anaconda) and a bunch of various data that would allow Anaconda provide options depending on the target system rather than on the system Anaconda is running on?
s-c-ks hasn't supported writing out kickstarts for other versions since at least as far back as I made it use yum, perhaps even farther back than that. So I'm not concerned about this for a newui-based s-c-ks.
- Chris
anaconda-devel@lists.stg.fedoraproject.org