Start in runlevel 5, add user accounts?

[Mark Komarinski]

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				mark_komarinski(a)hms.harvard.edu
Sr. Research Systems Architect		http://ritg.med.harvard.edu
Research IT Group
Harvard Medical School

[J. Hartline]

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

[Mark Komarinski]

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

-- 
Mark Komarinski				mark_komarinski(a)hms.harvard.edu
Sr. Research Systems Architect		http://ritg.med.harvard.edu
Research IT Group
Harvard Medical School

[Toshio Kuratomi]

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

[J. Hartline]

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

[Toshio Kuratomi]

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

[J. Hartline]

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

[Toshio Kuratomi]

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

user added optional features, was Re: Start in runlevel 5, add user accounts?

[Jane Dogalt]

--- Toshio Kuratomi <toshio(a)tiki-lounge.com&gt; 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

user added optional features, was Re: Start in runlevel 5, add user accounts?

[Chitlesh GOORAH]

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


--
http://clunixchit.blogspot.com

[Chitlesh GOORAH]

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

[Chitlesh GOORAH]

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


--
http://clunixchit.blogspot.com