FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > CentOS > CentOS

 
 
LinkBack Thread Tools
 
Old 04-28-2011, 03:03 PM
"Mattias Geniar"
 
Default LDAPs causing System Message Bus to hang when there's no network

> Yes, the bug is actually older than that---Don't know if it's only RH
> based systems (as so many things seem to work everywhere but RH and
> their offshoots) or ldap.
> You should be able to fix it by changing /etc/ldap.conf. There is a
> default commented line in there
>
> #bind_policy hard
>
> Uncomment it, change it to soft. (On the client.) Note this is
> /etc/ldap.conf--in Fedora, if that's the client, I believe it's now
> /etc/pam_ldap.conf or possibly /etc/nss_ldap.conf.
>
> I can't find the earlier bug at first glance, but it's FAR older than
> 2010, and they never bothered to fix it.
>
>
> > Has anyone else ever solved this to still be able to keep the group
ldap
> > entry in nsswitch.conf without having a server hang on boot if
there's
> > no network?
>
> See above. Darn, I wish I could find that older bug, so that I could
go
> to the newer one you mention and point out that they've been unable to
> fix it for far longer than a year. (I might do it anyway)
>
> Grouchily yours, (Not at you, at RH for being unable to get such a
> basic thing to work--actually, at one point, Fedora changed
bind_policy
> to soft so that it would work, but now they're back to the broken
way.)
>
>
> --
> Scott Robbins

Hi Scott,

In case you're wondering, this is about the oldest entry (2006):
https://bugzilla.redhat.com/show_bug.cgi?id=186527

The bind_policy didn't seem to have the wanted effect with me, it kept
trying to connect to LDAP server even after 10+ failed attempts, taking
1m50s on each and every attempt.

I read quite a few topics on that solving the issue, but it didn't seem
to be that case in my environment.
Are there other workarounds/tips if the bind_policy doesn't work? The
rc.local hack seems ... ugly ... and embarrassing if a client would
ever find it out. :-)

Regards,
Mattias
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 04-29-2011, 08:16 AM
"Mattias Geniar"
 
Default LDAPs causing System Message Bus to hang when there's no network

> ----
> I use the following to prevent hanging at startup with LDAP.
>
> nss_initgroups_ignoreusers root,ldap,bacula,named
> timelimit 30
> bind_timelimit 30
> bind_policy soft
>
> This is because some daemons start prior to the start of OpenLDAP
> service.
>
> Obviously adding haldaemon, dbus, radvd, tomcat, etc. or other 'users'
> for daemons that launch prior to your LDAP server application is
useful
> but those users would have to be listed in /etc/passwd|group to
> significantly benefit.
>
> Craig

Hi Craig,

The problem I have with listing those ignoreusers, is you need to know
in advance which services are on the system, and that's not always the
case. Or if a user installs a new daemon, he'll break his start-up of
the server should he ever be unable to connect to the LDAP systems.

Perhaps I'm asking too much, but could anyone try the following config
(in a VM or so, with networking disabled)? This is the one that is
causing boots to hang indefinitely, even though there are "bind_policy
soft" parameters involved.

/etc/ldap.conf
=======================================
ldap_version 3
base ou=people,o=company
uri ldaps://srv.domain.be/ ldaps://srv2.domain.be/
scope sub
timelimit 5
bind_timelimit 5
bind_policy soft
idle_timelimit 15
timeout 5

# If the LDAP server is unavailable during boot, don't retry too often
# or the system will hang on the System Message Bus service
bind_timeout 2
#nss_reconnect_tries 2
#nss_reconnect_sleeptime 1
#nss_reconnect_maxsleeptime 3
#nss_reconnect_maxconntries 2

referrals no

ssl start_tls
ssl on
tls_checkpeer yes
tls_cacertdir /etc/openldap/cacerts

pam_filter objectclass=posixAccount
pam_login_attribute uid
pam_min_uid 5000
pam_max_uid 6000
#pam_groupdn cn= company -shared,ou=groups,o=company
pam_groupdn cn= company -managed,ou=groups,o=company
pam_member_attribute memberUid
pam_password md5

nss_base_passwd ou=people,o= company
nss_base_shadow ou=people,o= company
nss_base_group ou=groups,o= company

#debug 255
#logdir /tmp/
=======================================

Or if anyone else can spot an obvious "Dude, why the f#!? did you put in
those lines"-error, please inform me. :-)

Thanks everyone for your interest and comments!

Kind regards,
Mattias
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 05-03-2011, 10:43 AM
"Mattias Geniar"
 
Default LDAPs causing System Message Bus to hang when there's no network

> I'd probably argue that nss_ldap is fundamentally unfixable. Why
*not* get
> behind sssd? Have you given a recent version a try?
>
> jh

Understandable, but since a lot of people are still going to stick with
CentOS 4/5 for legacy reasons, I would argue that nss_ldap is still
worth "fixing".

It's not as fancy as sssd of course, but it's what people are using
right now. :-)

Regards,
Mattias
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 
Old 05-03-2011, 05:43 PM
 
Default LDAPs causing System Message Bus to hang when there's no network

On May 3, 2011, at 4:52 AM, John Hodrien wrote:

> On Tue, 3 May 2011, Mattias Geniar wrote:
>
>> Understandable, but since a lot of people are still going to stick
>> with
>> CentOS 4/5 for legacy reasons, I would argue that nss_ldap is still
>> worth "fixing".
>
> I'm not saying it's not worth fixing, I suspect it's fundamentally
> unfixable
> without a complete redesign.
>
>> It's not as fancy as sssd of course, but it's what people are using
>> right now. :-)
>
> sssd answers a lot of these questions. It's definitely not a perfect
> replacement yet, but it's going in the right direction if you ask me.

So whats the answer today for ~10K users?

The bug fixes suggested here work around the problems I have been
encountering.

Can any one comment on what ppl are using for larger deployments? I
hope its not a resounding M$ AD?!

- aurf
_______________________________________________
CentOS mailing list
CentOS@centos.org
http://lists.centos.org/mailman/listinfo/centos
 

Thread Tools




All times are GMT. The time now is 11:55 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org