Two problems I'm having with kadischi.
First, the system never starts in runlevel 5, always 3. Somewhere during the ISO creation process I get "cannot determine current runlevel" which may be related.
Second, is there any way to create a non-root user? I don't want people using the root account to log into the system.
I'm using the live CDs for teaching a Linux desktop class. So far, I've been able to hack around, create the user after boot time and kick the init level to 5, but that takes a few minutes times 10 machines or so I have to do this on.
-Mark
Mark Komarinski wrote:
Two problems I'm having with kadischi.
First, the system never starts in runlevel 5, always 3. Somewhere during the ISO creation process I get "cannot determine current runlevel" which may be related.
Second, is there any way to create a non-root user? I don't want people using the root account to log into the system.
Anaconda should be setting the correct runlevel according to packages installed. Do you have a list of packages you are using?
As for the user you could probably run a few chroot/utilities. This is something I think would be good for Kadischi, the only downside is the password would be known.
J. Hartline
Jasper O'neal Hartline wrote:
Mark Komarinski wrote:
Two problems I'm having with kadischi.
First, the system never starts in runlevel 5, always 3. Somewhere during the ISO creation process I get "cannot determine current runlevel" which may be related.
Second, is there any way to create a non-root user? I don't want people using the root account to log into the system.
Anaconda should be setting the correct runlevel according to packages installed. Do you have a list of packages you are using?
I'm rerunning this now and the cannot determine current run level happens in 04userconfig.py. There's no anaconda-ks.cfg that gets created that I can see, or is it elsewhere? I selected X and GNOME, so that should mean that anaconda knows X is installed.
As for the user you could probably run a few chroot/utilities. This is something I think would be good for Kadischi, the only downside is the password would be known.
I think I have a fix, but I'm testing it out now. I created a 07sleep.sh that just sleeps for 5 minutes. That's the last thing I have running, so while that goes on, I chroot into the image, create the user I want, fix the runlevel, and change my xorg.conf.
I think longer term the solution would be to have instead of a sleep for 5 minutes something like "hit enter now to chroot into the image, make whatever changes you want, and things will continue when you leave the shell". Also a great way to add extra packages or run updates. It's a bit more manual, but a lot more flexible.
-Mark
On Fri, 2006-04-14 at 11:38 -0400, Mark Komarinski wrote:
Jasper O'neal Hartline wrote:
Mark Komarinski wrote:
Two problems I'm having with kadischi.
First, the system never starts in runlevel 5, always 3. Somewhere during the ISO creation process I get "cannot determine current runlevel" which may be related.
Second, is there any way to create a non-root user? I don't want people using the root account to log into the system.
Anaconda should be setting the correct runlevel according to packages installed. Do you have a list of packages you are using?
I'm rerunning this now and the cannot determine current run level happens in 04userconfig.py. There's no anaconda-ks.cfg that gets created that I can see, or is it elsewhere? I selected X and GNOME, so that should mean that anaconda knows X is installed.
It should be created in the /root/ directory in the build image. It's destroyed before compressing currently (AutOPSY -- is keeping /root instead of destroying it still in the works? I think it's a two line change or so and I didn't see any objections when you mentioned it.)
If you're chrooting into that directory before the post_install scripts are run, you should see it there.
I think longer term the solution would be to have instead of a sleep for 5 minutes something like "hit enter now to chroot into the image, make whatever changes you want, and things will continue when you leave the shell". Also a great way to add extra packages or run updates. It's a bit more manual, but a lot more flexible.
Perhaps a --chroot option on kadischi's commandline? Long term, this is best done by writing a post_install script for your local settings but the option to chroot can be good for quick 'n dirty experimentation until you get it right.
-Toshio
Toshio Kuratomi wrote:
It should be created in the /root/ directory in the build image. It's destroyed before compressing currently (AutOPSY -- is keeping /root instead of destroying it still in the works? I think it's a two line change or so and I didn't see any objections when you mentioned it.)
I've changed this in CVS. Now rootfiles along with Anaconda kickstart file is kept, and the install.log too.
I think the original purpose was to conserve space, but in this respect removing root's files isn't the best way to do it I don't think.
J. Hartline
On Fri, 2006-04-14 at 09:09 -0500, Jasper O'neal Hartline wrote:
Mark Komarinski wrote:
Second, is there any way to create a non-root user? I don't want people using the root account to log into the system.
As for the user you could probably run a few chroot/utilities. This is something I think would be good for Kadischi, the only downside is the password would be known.
We should prompt for a user/password rather than providing a default one. Kadischi could take a cmdline switch like --user=fedora --md5-password='$1$MEUsTNg2$89lWdr/Hd1YFAIKBXPkD43'
or popup a dialog requesting a username and password.
The user could either be created at CD creationtime or boottime. The only difference that I can see is if a creator wanted to stick special files into the home directory (and didn't want to put them in /etc/skel.)
And sometimes you don't want any users or passwords or you want a user with a disabled password so we should be able to make that happen as well.
-Toshio
Toshio Kuratomi wrote:
We should prompt for a user/password rather than providing a default one. Kadischi could take a cmdline switch like --user=fedora --md5-password='$1$MEUsTNg2$89lWdr/Hd1YFAIKBXPkD43'
or popup a dialog requesting a username and password.
Right. I think the shell or dialog would be sufficient.
A switch is well, a switch. For a user I don't think it is neccessary maybe we can look into the %livecd item for this instead. (Anaconda, ks.cfg)
J. Hartline
On Fri, 2006-04-14 at 11:43 -0500, Jasper O'neal Hartline wrote:
Toshio Kuratomi wrote:
We should prompt for a user/password rather than providing a default one. Kadischi could take a cmdline switch like --user=fedora --md5-password='$1$MEUsTNg2$89lWdr/Hd1YFAIKBXPkD43'
or popup a dialog requesting a username and password.
Right. I think the shell or dialog would be sufficient.
A switch is well, a switch. For a user I don't think it is neccessary maybe we can look into the %livecd item for this instead. (Anaconda, ks.cfg)
Currently, I can completely script the running of kadischi. I'd hate to see this feature go away. So a commandline switch has advantages over a dialog.
OTOH, this should currently be possible through anaconda's %post or a post_install. So the question becomes, what do we want kadischi to be able to do? Is it just the CD creator and all the configuration is done through (possibly distributed and enabled by default) post_install scripts? It makes sense at a certain conceptual level to do this, but it is more confusing to the user as scripts will have to be tweaked for their specifics. So at the least, kadischi needs to pass commandline args/parse any config files and pass those values through to the post_install scripts so the end-user is unaware of the split.
-Toshio
--- Toshio Kuratomi toshio@tiki-lounge.com wrote:
On Fri, 2006-04-14 at 11:43 -0500, Jasper O'neal Hartline wrote:
Toshio Kuratomi wrote:
We should prompt for a user/password rather than providing a default one. Kadischi could take a cmdline switch like --user=fedora --md5-password='$1$MEUsTNg2$89lWdr/Hd1YFAIKBXPkD43'
or popup a dialog requesting a username and password.
Right. I think the shell or dialog would be sufficient.
A switch is well, a switch. For a user I don't think it is neccessary maybe we can look into the %livecd item for this instead. (Anaconda, ks.cfg)
Currently, I can completely script the running of kadischi. I'd hate to see this feature go away. So a commandline switch has advantages over a dialog.
ditto on that. Losing headless cron-ability would be IMO undesirable. GUI's are nice, but command lines are useful.
OTOH, this should currently be possible through anaconda's %post or a post_install. So the question becomes, what do we want kadischi to be able to do? Is it just the CD creator and all the configuration is done through (possibly distributed and enabled by default) post_install scripts? It makes sense at a certain conceptual level to do this, but it is more confusing to the user as scripts will have to be tweaked for their specifics. So at the least, kadischi needs to pass commandline args/parse any config files and pass those values through to the post_install scripts so the end-user is unaware of the split.
I think this strategy makes sense. You allow the gui or command line args to create or tweak pre-cooked post_install scripts. But in general, there should be 1 set of post_install scripts that are just plain fundamentally required to get the liveiso to work. Another set that just make a tremendous amount of sense (X11 auto config, removing unneeded files from directories which live in tmpfs, etc...). And then more sets that are optional and can perhaps be shortcut added by the user via a commandline option, or gui radio button. Likewise that second primary set could be disabled via a similar comline option or gui button.
More complicated semi-pre-cooked post_install scripts which require user configuration (i.e. system user username and password, security settings) could be used as above, but with the comline option, or gui radio button, requiring further user input. I.e.
--add-feature=useraccount:username=sysuser:password="xxx" (or gui radio button invokes further dialog prompting for those options)
Just a theory... , i.e.
--add-feature=xautoconfig:defaultresolution=1024x768 --add-feature=gdmautologin:username=sysuser --add-feature=installextrapackages:extrayumrepo=http://...:packages=xmms,lirc,... --add-feature=custompayload:data=/home/me/livecdbuildenv/mydata:script=/home/me/livecdbuildenv/mypostinstall
-jdog
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
--add-feature=useraccount:username=sysuser:password="xxx" (or gui radio button invokes further dialog prompting for those options)
Just a theory... , i.e.
--add-feature=xautoconfig:defaultresolution=1024x768 --add-feature=gdmautologin:username=sysuser --add-feature=installextrapackages:extrayumrepo=http://...:packages=xmms,lirc,... --add-feature=custompayload:data=/home/me/livecdbuildenv/mydata:script=/home/me/livecdbuildenv/mypostinstall
I like this idea.
We have to document ourselves on how will Anaconda deal with extras packages in the future.
I have a post install script which enables autologin for a user 'fedora'. See attachment.
Maybe this might be useful to you.
I've disabled the service "firstboot" for my livecd as well, but not sure whether its worth or not.
Cheers, Chitlesh GOORAH -- http://clunixchit.blogspot.com
And sometimes you don't want any users or passwords or you want a user with a disabled password so we should be able to make that happen as well.
Actually on my post install script, the user "fedora" doesn't have a password.
Security should be discussed as well.
livecd@lists.fedoraproject.org
-
Chitlesh GOORAH -
J. Hartline -
Jane Dogalt -
Mark Komarinski -
Toshio Kuratomi