On Thu, 5 May 2011, Gordon Messmer wrote:
> On 05/03/2011 10:43 AM, aurfal...@gmail.com wrote:
>> Can any one comment on what ppl are using for larger deployments? I
>> hope its not a resounding M$ AD?!
>
> Use sssd. It's now included in CentOS 5.
Included doesn't necessarily mean usable though
On 05/03/2011 10:43 AM, aurfal...@gmail.com wrote:
> Can any one comment on what ppl are using for larger deployments? I
> hope its not a resounding M$ AD?!
Use sssd. It's now included in CentOS 5.
___
CentOS mailing list
CentOS@centos.org
http://lists
On Tue, 3 May 2011, aurfal...@gmail.com wrote:
> So whats the answer today for ~10K users?
>
> The bug fixes suggested here work around the problems I have been
> encountering.
Well that's good then.
> Can any one comment on what ppl are using for larger deployments? I
> hope its not a resoundi
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
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 comple
> 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".
On Fri, 29 Apr 2011, Devin Reade wrote:
> Probably moot now anyway as nobody is interested in fixing it since sssd
> will cure all ills and bring world peace. (Insert sarcasm/skepticism as
> appropriate.)
I'd probably argue that nss_ldap is fundamentally unfixable. Why *not* get
behind sssd? H
--On Thursday, April 28, 2011 10:53:52 AM -0400 Scott Robbins
wrote:
> On Thu, Apr 28, 2011 at 04:21:58PM +0200, Mattias Geniar wrote:
>> I've tracked this down to the following known bug in Redhat, but
>> it dates back to early 2010.
>> https://bugzilla.redhat.com/show_bug.cgi?id=182464#c46
>
>
> 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,
On Thu, 2011-04-28 at 09:28 -0700, Paul Heinlein wrote:
> On Thu, 28 Apr 2011, Steve Thompson wrote:
>
> > This works:
> >
> > nss_initgroups_ignoreusers root,ldap,named,avahi,haldaemon,dbus
>
> We use a slightly longer version:
>
> nss_initgroups_ignoreusers
> root,ldap,named,avahi,haldaemon
On Thu, 28 Apr 2011, Steve Thompson wrote:
> This works:
>
> nss_initgroups_ignoreusers root,ldap,named,avahi,haldaemon,dbus
We use a slightly longer version:
nss_initgroups_ignoreusers
root,ldap,named,avahi,haldaemon,dbus,radvd,tomcat,radiusd,news,mailman
I suspect, however, that the extra
On Thu, 28 Apr 2011, Benjamin Hackl wrote:
> On Thu, 28 Apr 2011 16:21:58 +0200
> "Mattias Geniar" wrote:
>
>> Here's my /etc/ldap.conf file:
>
> Did you include nss_initgroups_ignoreuser in your /etc/ldap.conf?
>
> nss_initgroups_ignoreusers root,ldap
This works:
nss_initgroups_ignoreusers
On Thu, 28 Apr 2011, Mattias Geniar wrote:
> 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
>
On Thu, Apr 28, 2011 at 05:03:55PM +0200, Mattias Geniar wrote:
>
> 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
On Thu, 28 Apr 2011, Scott Robbins wrote:
> On Thu, Apr 28, 2011 at 03:52:44PM +0100, John Hodrien wrote:
>> On Thu, 28 Apr 2011, Mattias Geniar wrote:
>>
>>> could be a work-around I can live with, but it doesn't appear there is.
>>
>> I'd hope you'd see these problems almost entirely go away in
> 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
>
On Thu, Apr 28, 2011 at 03:52:44PM +0100, John Hodrien wrote:
> On Thu, 28 Apr 2011, Mattias Geniar wrote:
>
> > could be a work-around I can live with, but it doesn't appear there is.
>
> I'd hope you'd see these problems almost entirely go away in future with a
> switch to sssd rather than nss_
On Thu, Apr 28, 2011 at 04:21:58PM +0200, Mattias Geniar wrote:
> Hi Everyone,
>
>
> So that's pretty straight forward. My LDAP systems are running fine, and
> I can authenticate to them.
>
> However, the problem: when the client boots *without network
> connectivity*, the server gets stuck/hang
On Thu, 28 Apr 2011, Mattias Geniar wrote:
>> Did you include nss_initgroups_ignoreuser in your /etc/ldap.conf?
>>
>> nss_initgroups_ignoreusers root,ldap
>>
>> Brgds
>
> Hi Benjamin,
>
> I tried that, but that just makes it hang upon the next service trying
> to start (in our case: a zabbix monit
> Did you include nss_initgroups_ignoreuser in your /etc/ldap.conf?
>
> nss_initgroups_ignoreusers root,ldap
>
> Brgds
Hi Benjamin,
I tried that, but that just makes it hang upon the next service trying
to start (in our case: a zabbix monitoring daemon running as
zabbix/zabbix).
It works, if
On Thu, 28 Apr 2011 16:21:58 +0200
"Mattias Geniar" wrote:
> Here's my /etc/ldap.conf file:
Did you include nss_initgroups_ignoreuser in your /etc/ldap.conf?
nss_initgroups_ignoreusers root,ldap
Brgds
___
CentOS mailing list
CentOS@centos.org
http:/
Hi Everyone,
I'm experiencing the following problem, for which I've not yet found a
resolution. It's been discussed elsewhere, but unfortunately nothing
actually solves it.
Here's my /etc/ldap.conf file:
#
ldap_version 3
base ou=people,o=xxx
uri ldaps://server1.domain.be/ ldaps://
22 matches
Mail list logo