systemd and changes

Lennart Poettering mzerqung at 0pointer.de
Mon Aug 23 21:33:18 UTC 2010


On Mon, 23.08.10 16:17, Dennis Gilmore (dennis at ausil.us) wrote:

> > > It's just risk management.  I think we'd be better off acknowledging
> > > there are unknown unknowns and try to mitigate them.  One way we could
> > > have done that this time around was making it an optional feature (as
> > > Matt was mentioning in a previous email) for F14 and then decide in F15
> > > if it was ready.  Unfortunately that's not the path we seem to be on. 
> > > We unwisely seemed to declare it ready before anyone even saw it then we
> > > ignored what we didn't know as if we knew there were going to be no
> > > problems.  The sad thing is that's such an easy fix by making brand new
> > > features for core components like this opt in, even if it's just for a
> > > single release.
> > 
> > I am sorry, but your are discussing all this from the perspective as if
> > something went really horribly wrong with how things worked out. But
> > frankly, I don't even see what even remotely went wrong. So far, I am
> > myself surprised how smooth this all went. I was prepared for much
> > worse, I have expected much worse.
> >
> > I know I am repeating myself: everything's wonderful.
> 
> Umm we discussed for many hours on friday the issue im having that is 
> resulting im my desktop being unable to boot  since now the network service 
> will not start which also causes dbus to not start  and my sysetm to never 
> fully come up.
> 
> With no outcome other than to stick with upstart for now  its not all 
> wonderful and peachy.   it has been the case forever that if your using ldap 
> for auth you need to have network start before dbus  that has always been the 
> answer  but you broke that from happening. 

Well, that's not entirely fair I think. Most people taking part in the
discussion I think agreed that it's pam_ldap's fault here or at least
dbus', some even suggested to remove pam_ldap from the distribution
entirely, and adviced you to use sssd instead.

This is mostly a bug that becomes visible through systemd, but has been
existing since about forever, and you can easily trigger problems with
it even in other contexts.

While I personally believe that this problem is not particularly crucial
and as I understood you you even agreed on trying sssd instead, I'd be
willing to sit down and unfuck pam_ldap to the level that makes this
work, should FESCO come to the conclusion that it matters. The problem
is probably easy to fix actually as pam_ldap should just cleanly refuse
service if the network isn't around.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.


More information about the devel mailing list