Using k5start with replacement init daemons

[Russ Allbery]

Jaap Winius <jwinius at umrk.nl> writes:

> However, a lot of this depends on how init behaves: if it runs k5start
> before the network comes up, the process will fail and the user will not
> be able to log in. I had this experience recently with Ubuntu 10, which
> uses a replacement init, called upstart. Once I had managed to write a
> reasonable /etc/init/k5start.conf, it only seemed to work some of the
> time. Other times I would have to switch to a console screen and run
> "initctl start k5start" manually before I could log in. Even worse,
> sometimes upstart even failed to start up the getty processes for the
> consoles, forcing me to first use another machine to ssh to the
> workstation to start up kstart (and maybe a getty). Has anyone managed
> to configure k5start to work on Ubuntu 10 (lucid) with upstart?

How are you invoking k5start under initctl (what flags, in other words)?
Also, does it report that k5start has started and then exits and won't
stay running, or does it never try to run it at all?

> And if that's not bad enough, what can be done for all those laptop
> users out there who are used to managing their network connections from
> their desktops? In such cases, there may not be a network connection
> until after they log in.  Personally, I'd first login as root, establish
> the appropriate network connection from the command line and then run
> k5start before switching back to xdm, gmd, or kdm, but that's not
> something we can expect normal users to feel comfortable with. All I can
> think of is that something be built into xdm, gdm and kdm to allow the
> network connections (including wireless) to be managed before users log
> in.

If you can bring up the network connection before the user logs in,
there's no reason to wait to xdm, gdm, or kdm to do it; just do it on
boot.  The problem is that the information required to bring up the
network may require the user to enter passwords or some other tokens known
only to the user (think of VPNs, for instance).  In this case, there's no
way around needing to let the user authenticate and log in without either
Kerberos or LDAP being available.

There are PAM modules that can cache your last login credentials and let
you use them to log in again if there's no network.  Something like that
might work.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>