Using k5start with replacement init daemons

[Jaap Winius]

On Mon, 05 Jul 2010 14:05:31 -0700, Russ Allbery wrote:

> How are you invoking k5start under initctl (what flags, in other words)?

Hi Russ!

This is my /etc/init/kstart.conf that I used on Kubuntu lucid:

   start on filesystem
   stop on runlevel S

   expect fork
   respawn
   respawn limit 20 2
   oom never

   pre-start script
	/bin/sleep 3
   end script

   exec /usr/bin/k5start -U -f /etc/krb5.keytab -K 10 -l 24h -L

This sometimes worked, but usually not. I also tried versions with "start 
on kdm" and "start on starting-dm", but neither made a difference. 
Perhaps I should have tried adding "auto eth0 / iface eth0 inet dhcp" to 
my /etc/network/interfaces file, but I was also put off my the fact that 
upstart was failing to start up the getty processes for the consoles most 
of the time.

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

The logs did report that k5start had been started, but that it was unable 
to resolve any KDC addresses. I figure this was because it was being 
started up before there was a network connection, because it had no 
problem finding a KDC if I later did "initctl start k5start" from a 
console (or a remote session in lieu of a console).
 
> 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.

Indeed: Natxo Asenjo mentioned two such solutions earlier. It's an 
interesting approach, but really meant for laptop users who can usually 
log in. For desktops with local home directories, it might be useful as a 
temporary workaround, but not as a serious solution in a production 
environment. In addition, I suspect that my use of OpenAFS can only make 
this approach less likely to succeed. With an OpenAFS laptop, that's why 
it's so important to have a network connection in the first place: 
without one, there is no home directory to log into.

In the mean time, I've re-installed my desktop using Debian squeeze 
instead: it may not be as polished, but at least I could get Kerberos, 
OpenLDAP and OpenAFS to work on it without any problems. 

Cheers,

Jaap