On Mon, 23.08.10 16:17, Dennis Gilmore (dennis@xxxxxxxx) 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. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
