On Mon, 23.08.10 16:17, Dennis Gilmore (dennis(a)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.