Re: unable to perform authenticated binds

2010-11-05 Thread Tim Dunphy 
Hey guys,

 And sorry to Quanah for the type-o. ;)

 At any rate thanks for the ldapsearch. It did return a ton of
information on the attributes defined in my schema:

 [r...@ldap2 ~]# ldapsearch -x -h ldap.acadaca.net -s base -b
cn=subschema + | more
# extended LDIF
#
# LDAPv3
# base cn=subschema with scope baseObject
# filter: (objectclass=*)
# requesting: +
#

# Subschema
dn: cn=Subschema
structuralObjectClass: subentry
createTimestamp: 20101105183240Z
modifyTimestamp: 20101105183240Z
ldapSyntaxes: ( 1.3.6.1.1.16.1 DESC 'UUID' )
ldapSyntaxes: ( 1.3.6.1.1.1.0.1 DESC 'RFC2307 Boot Parameter' )
ldapSyntaxes: ( 1.3.6.1.1.1.0.0 DESC 'RFC2307 NIS Netgroup Triple' )
ldapSyntaxes: ( 1.3.6.1.4.1.1466.115.121.1.52 DESC 'Telex Number' )
ldapSyntaxes: ( 1.3.6.1.4.1.1466.115.121.1.50 DESC 'Telephone Number' )
ldapSyntaxes: ( 1.3.6.1.4.1.1466.115.121.1.49 DESC 'Supported Algorithm' X-BIN
 ARY-TRANSFER-REQUIRED 'TRUE' X-NOT-HUMAN-READABLE 'TRUE' )
ldapSyntaxes: ( 1.3.6.1.4.1.1466.115.121.1.45 DESC 'SubtreeSpecification' )
ldapSyntaxes: ( 1.3.6.1.4.1.1466.115.121.1.44 DESC 'Printable String' )


However, nothing shows up under the search regarding sudoRole.

[r...@ldap ldif]# ldapsearch -x -h ldap.acadaca.net -s base -b
cn=subschema | grep sudoRole
[r...@ldap ldif]#

This is curious to me as the sudoers.schema file (which has sudoRole
defined) is most definitely entered correctly into my slapd.conf file.


# See slapd.conf(5) for details on configuration options.
# This file should NOT be world readable.
#
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/nis.schema
include /etc/openldap/schema/misc.schema
inlcude /etc/openldap/schema/sudoers.schema
include /etc/openldap/schema/openldap.schema


I checked the modes and permissions on sudoers.schema:

[r...@ldap ~]# ls -l /etc/openldap/schema/sudoers.schema
-r--r--r-- 1 ldap ldap 1655 Nov  4 18:38 /etc/openldap/schema/sudoers.schema


But when I try to add this LDIF entry to my directory:

 # defaults, sudoers, Services, acadaca.net
dn: cn=defaults,ou=sudoers,ou=Services,dc=acadaca,dc=net
objectClass: top
objectClass: sudoRole
cn: defaults
description: Default sudoOption's go here



I am still getting this error:

[r...@ldap ldif]# ldapadd -h ldap.acadaca.net -a -W -x -D
cn=Manager,dc=acadaca,dc=net -f /home/tim/txt/ldif/acadaca2.ldif
Enter LDAP Password:
adding new entry cn=defaults,ou=sudoers,ou=Services,dc=acadaca,dc=net
ldapadd: Invalid syntax (21)
additional info: objectClass: value #1 invalid per syntax


And these errors in the logs:

Nov  5 15:00:33 ldap slapd[4429]: daemon: activity on 1 descriptor
Nov  5 15:00:33 ldap slapd[4429]: daemon: activity on:
Nov  5 15:00:33 ldap slapd[4429]:
Nov  5 15:00:33 ldap slapd[4429]: slap_listener_activate(7):
Nov  5 15:00:33 ldap slapd[4429]: daemon: epoll: listen=7 busy
Nov  5 15:00:33 ldap slapd[4429]: daemon: epoll: listen=8
active_threads=0 tvp=NULL
Nov  5 15:00:33 ldap slapd[4429]:  slap_listener(ldap:///)
Nov  5 15:00:33 ldap slapd[4429]: daemon: listen=7, new connection on 12
Nov  5 15:00:33 ldap slapd[4429]: daemon: added 12r (active) listener=(nil)
Nov  5 15:00:33 ldap slapd[4429]: conn=5 fd=12 ACCEPT from
IP=75.101.129.124:55873 (IP=0.0.0.0:389)
Nov  5 15:00:33 ldap slapd[4429]: daemon: activity on 2 descriptors
Nov  5 15:00:33 ldap slapd[4429]: daemon: activity on:
Nov  5 15:00:33 ldap slapd[4429]:  12r
Nov  5 15:00:33 ldap slapd[4429]:
Nov  5 15:00:33 ldap slapd[4429]: daemon: read active on 12
Nov  5 15:00:33 ldap slapd[4429]: daemon: epoll: listen=7
active_threads=0 tvp=NULL
Nov  5 15:00:33 ldap slapd[4429]: daemon: epoll: listen=8
active_threads=0 tvp=NULL
Nov  5 15:00:33 ldap slapd[4429]: connection_get(12)
Nov  5 15:00:33 ldap slapd[4429]: connection_get(12): got connid=5
Nov  5 15:00:33 ldap slapd[4429]: connection_read(12): checking for
input on id=5
Nov  5 15:00:33 ldap slapd[4429]: do_bind
Nov  5 15:00:33 ldap slapd[4429]:  dnPrettyNormal:
cn=Manager,dc=acadaca,dc=net
Nov  5 15:00:33 ldap slapd[4429]:  dnPrettyNormal:
cn=Manager,dc=acadaca,dc=net, cn=manager,dc=acadaca,dc=net
Nov  5 15:00:33 ldap slapd[4429]: do_bind: version=3
dn=cn=Manager,dc=acadaca,dc=net method=128
Nov  5 15:00:33 ldap slapd[4429]: conn=5 op=0 BIND
dn=cn=Manager,dc=acadaca,dc=net method=128
Nov  5 15:00:33 ldap slapd[4429]: == bdb_bind: dn: cn=Manager,dc=acadaca,dc=net
Nov  5 15:00:33 ldap slapd[4429]: conn=5 op=0 BIND
dn=cn=Manager,dc=acadaca,dc=net mech=SIMPLE ssf=0
Nov  5 15:00:33 ldap slapd[4429]: do_bind: v3 bind:
cn=Manager,dc=acadaca,dc=net to cn=Manager,dc=acadaca,dc=net
Nov  5 15:00:33 ldap slapd[4429]: send_ldap_result: conn=5 op=0 p=3
Nov  5 15:00:33 ldap slapd[4429]: send_ldap_result: err=0 matched= text=
Nov  5 15:00:33 ldap slapd[4429]: send_ldap_response: msgid=1 tag=97 err=0
Nov  5 15:00:33 ldap slapd[4429]: conn=5 op=0 RESULT tag=97 err=0

Re: unable to perform authenticated binds

2010-11-04 Thread Quanah Gibson-Mount 
--On Thursday, November 04, 2010 3:37 PM -0400 Tim Dunphy 
bluethu...@gmail.com wrote:



Thanks all.. I have read the man of ldif your advice has gotten me
quite far both in my current implementation and in my overall
understanding of LDAP which I am hoping grows with each passing day.

 In my attempt to build my current directory, I have taken a dump of
my last successful implementation (which was created on FreeBSD 8.1)
and substituted values for the dc=company and dc=com values with the
correct ones for the current directory (attempting to implement under
CentOS 5.4) and even tho the correct schemas are in place it is
choking on this entry:

# defaults, sudoers, Services, acadaca.com
dn: cn=defaults,ou=sudoers,ou=Services,dc=acadaca,dc=net
objectClass: top
objectClass: sudoRole
cn: defaults
description: Default sudoOption's go here


Since you fail to provide the error message you encountered, I see no way 
to help you.


--Quanah

--

Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc

Zimbra ::  the leader in open source messaging and collaboration

Re: unable to perform authenticated binds

2010-11-04 Thread Tim Dunphy 
sorry for the oversight

Nov  4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: activity on 1 descriptor
Nov  4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: activity on:
Nov  4 15:59:47 ec2-50-16-86-188 slapd[15175]:
Nov  4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: epoll: listen=7 busy
Nov  4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: epoll: listen=8
active_threads=0 tvp=NULL
Nov  4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: listen=7, new
connection on 12
Nov  4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: added 12r
(active) listener=(nil)
Nov  4 15:59:47 ec2-50-16-86-188 slapd[15175]: conn=3 fd=12 ACCEPT
from IP=10.203.49.140:51779 (IP=0.0.0.0:389)
Nov  4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: activity on 1 descriptor
Nov  4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: activity on:
Nov  4 15:59:47 ec2-50-16-86-188 slapd[15175]:
Nov  4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: epoll: listen=7
active_threads=0 tvp=NULL
Nov  4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: epoll: listen=8
active_threads=0 tvp=NULL
Nov  4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: activity on 1 descriptor
Nov  4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: activity on:
Nov  4 15:59:47 ec2-50-16-86-188 slapd[15175]:  12r
Nov  4 15:59:47 ec2-50-16-86-188 slapd[15175]:
Nov  4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: read active on 12
Nov  4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: epoll: listen=7
active_threads=0 tvp=NULL
Nov  4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: epoll: listen=8
active_threads=0 tvp=NULL
Nov  4 15:59:47 ec2-50-16-86-188 slapd[15175]: conn=3 op=0 BIND
dn=cn=Manager,dc=acadaca,dc=net method=128
Nov  4 15:59:47 ec2-50-16-86-188 slapd[15175]: conn=3 op=0 BIND
dn=cn=Manager,dc=acadaca,dc=net mech=SIMPLE ssf=0
Nov  4 15:59:47 ec2-50-16-86-188 slapd[15175]: conn=3 op=0 RESULT
tag=97 err=0 text=
Nov  4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: activity on 1 descriptor
Nov  4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: activity on:
Nov  4 15:59:47 ec2-50-16-86-188 slapd[15175]:
Nov  4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: epoll: listen=7
active_threads=0 tvp=NULL
Nov  4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: epoll: listen=8
active_threads=0 tvp=NULL
Nov  4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: activity on 1 descriptor
Nov  4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: activity on:
Nov  4 15:59:47 ec2-50-16-86-188 slapd[15175]:  12r
Nov  4 15:59:47 ec2-50-16-86-188 slapd[15175]:
Nov  4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: read active on 12
Nov  4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: epoll: listen=7
active_threads=0 tvp=NULL
Nov  4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: epoll: listen=8
active_threads=0 tvp=NULL
Nov  4 15:59:47 ec2-50-16-86-188 slapd[15175]: conn=3 op=1 ADD
dn=cn=defaults,ou=sudoers,ou=Services,dc=acadaca,dc=net
Nov  4 15:59:47 ec2-50-16-86-188 slapd[15175]: conn=3 op=1 RESULT
tag=105 err=21 text=objectClass: value #1 invalid per syntax
Nov  4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: activity on 1 descriptor
Nov  4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: activity on:
Nov  4 15:59:47 ec2-50-16-86-188 slapd[15175]:
Nov  4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: epoll: listen=7
active_threads=0 tvp=NULL
Nov  4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: epoll: listen=8
active_threads=0 tvp=NULL
Nov  4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: activity on 1 descriptor
Nov  4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: activity on:
Nov  4 15:59:47 ec2-50-16-86-188 slapd[15175]:  12r
Nov  4 15:59:47 ec2-50-16-86-188 slapd[15175]:
Nov  4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: read active on 12
Nov  4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: epoll: listen=7
active_threads=0 tvp=NULL
Nov  4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: epoll: listen=8
active_threads=0 tvp=NULL
Nov  4 15:59:47 ec2-50-16-86-188 slapd[15175]: conn=3 op=2 UNBIND
Nov  4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: removing 12
Nov  4 15:59:47 ec2-50-16-86-188 slapd[15175]: conn=3 fd=12 closed
Nov  4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: activity on 1 descriptor
Nov  4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: activity on:
Nov  4 15:59:47 ec2-50-16-86-188 slapd[15175]:
Nov  4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: epoll: listen=7
active_threads=0 tvp=NULL
Nov  4 15:59:47 ec2-50-16-86-188 slapd[15175]: daemon: epoll: listen=8
active_threads=0 tvp=NULL


On Thu, Nov 4, 2010 at 3:49 PM, Quanah Gibson-Mount qua...@zimbra.com wrote:
 --On Thursday, November 04, 2010 3:37 PM -0400 Tim Dunphy
 bluethu...@gmail.com wrote:

 Thanks all.. I have read the man of ldif your advice has gotten me
 quite far both in my current implementation and in my overall
 understanding of LDAP which I am hoping grows with each passing day.

  In my attempt to build my current directory, I have taken a dump of
 my last successful

Re: unable to perform authenticated binds

2010-11-04 Thread Quanah Gibson-Mount 
--On Thursday, November 04, 2010 5:47 PM -0400 Tim Dunphy 
bluethu...@gmail.com wrote:



however when I do a search for sudoRole it doesn't seem to show up

[r...@ldap openldap]# ldapsearch -b '' -s base '(objectclass=*)'
sudoRole -x -W -D cn=Manager,dc=acadaca,dc=net


That is not a valid search of the cn=subschema entry.  I would note you 
fail to offer a -h or -H option, so who knows what LDAP server it is 
talking to.


ldapsearch -x -h zre-ldap001 -s base -b cn=subschema +

for example, searches the subschema entry on my system.


And my name has only one n in it.

--Quanah

--

Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc

Zimbra ::  the leader in open source messaging and collaboration

Re: unable to perform authenticated binds

2010-11-03 Thread Tim Dunphy 
sorry for the frustration all... removing the leading space in front
of rootpw did the trick :)

the directory is now populating, however I cannot understand why it is
choking on this entry

# pam_ldap, Services, acadaca.net
dn: cn=pam_ldap,ou=Services,dc=acadaca,dc=net
cn: pam_ldap
objectClass: top
objectClass: inetOrgPerson
sn: PAM
userPassword:: {SSHA}secret

AFAIK I have ALL the scemas I need to import this entry yet ldapadd chokes

[r...@ldap openldap]# ldapadd -h ldap -x -D
cn=Manager,dc=acadaca,dc=net -w secret -f /home/tim/acadaca2.ldif
ldapadd: invalid format (line 6) entry:
cn=pam_ldap,ou=Services,dc=acadaca,dc=net



include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/nis.schema
include /etc/openldap/schema/misc.schema
inlcude /etc/openldap/schema/sudoers.schema

I am sorry to ask for help again.. this sucks

On Wed, Nov 3, 2010 at 12:20 PM, Quanah Gibson-Mount qua...@zimbra.com wrote:
 --On Tuesday, November 02, 2010 7:59 PM -0700 Chris Jacobs
 chris.jac...@apollogrp.edu wrote:

 If you're not calling me out via thanks so much for the exceedingly
 useful insight then feel free to skip the rest of this.

 I didn't think he was calling you out, myself. ;)  Just noting that things
 are documented, and people who don't take the time to read the official
 project documentation (which happens a lot, unfortunately) don't deserve
 sympathy on it.  We get a lot of people who spend their time reading
 documents from other sources such as Zytrax, which contain completely wrong
 information, and then come here to talk about how bad the documentation is.
 It gets frustrating.

 --Quanah


 --

 Quanah Gibson-Mount
 Principal Software Engineer
 Zimbra, Inc
 
 Zimbra ::  the leader in open source messaging and collaboration




-- 
Here's my RSA Public key:
gpg --keyserver pgp.mit.edu --recv-keys 5A4873A9

Share and enjoy!!

Re: unable to perform authenticated binds

2010-11-03 Thread Quanah Gibson-Mount 
--On Wednesday, November 03, 2010 6:09 PM -0400 Tim Dunphy 
bluethu...@gmail.com wrote:



holy crap!! it was the extra colon that killed it! found it, fixed
it.. man oh man sorry for the intrusion!


Yeah, :: on userPassword means it is base-64 encoded already, and clearly 
that bit of LDIF was not base-64 encoded. ;)


--Quanah

--

Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc

Zimbra ::  the leader in open source messaging and collaboration

Re: unable to perform authenticated binds

2010-11-03 Thread Howard Chu 

Quanah Gibson-Mount wrote:

--On Wednesday, November 03, 2010 6:09 PM -0400 Tim Dunphy
bluethu...@gmail.com  wrote:


holy crap!! it was the extra colon that killed it! found it, fixed
it.. man oh man sorry for the intrusion!


Yeah, :: on userPassword means it is base-64 encoded already, and clearly
that bit of LDIF was not base-64 encoded. ;)


And again, stuff like this is clearly documented in the ldif(5) manpage...

--
  -- Howard Chu
  CTO, Symas Corp.   http://www.symas.com
  Director, Highland Sun http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/

Re: unable to perform authenticated binds

2010-11-02 Thread Quanah Gibson-Mount 
--On Tuesday, November 02, 2010 11:07 PM +0100 Benjamin Griese 
der.dar...@gmail.com wrote:



Hello Tim,

the password you supply won't work, as it is not encoded in base64.

Try to generate a password hash + base64-enc with slappasswd and set
this string as your password hash for rootpw.
http://linux.die.net/man/8/slappasswd


Benjamin,

There is no requirement that the password value for the rootpw entry in 
slapd.conf be SSHA hashed or Base 64 encoded.


I.e.,

rootpw  secret

is perfectly valid.

Also, an LDIF file with

userPassword: secret

is also perfectly valid, as either slapadd or slapd (via ldapadd) will take 
care of encoding it to Base64.


--Quanah



--

Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc

Zimbra ::  the leader in open source messaging and collaboration

Re: unable to perform authenticated binds

2010-11-02 Thread Tim Dunphy 
thanks for the input guys..

 I have to admit at this point, setting this up under FreeBSD was a
breeze compared to what is going on now.

 I have made 3 attempts at this today.. twice on CentOS 5.4 and once
on Ubuntu 10 Server.

 Given the differences in platform with identical outcomes I am
thinking that it _has_ to be something with my slapd.conf file.

 I am still getting error 49s even if I use the actual word secret as the pass.

Nov  2 19:02:00 ldap2 slapd[15768]: conn=0 fd=11 ACCEPT from
IP=127.0.0.1:8 (IP=0.0.0.0:389)
Nov  2 19:02:00 ldap2 slapd[15768]: conn=0 op=0 BIND
dn=cn=Manager,dc=acadaca,dc=net method=128
Nov  2 19:02:00 ldap2 slapd[15768]: conn=0 op=0 RESULT tag=97 err=49 text=
Nov  2 19:02:00 ldap2 slapd[15768]: conn=0 fd=11 closed (connection lost)


And this is how my ldap.conf is setup

BASEdc=acadaca,dc=net
HOSTlocalhost


 I would appreciate it greatly if someone could please give it a look.

 Thank you




On Tue, Nov 2, 2010 at 6:35 PM, Quanah Gibson-Mount qua...@zimbra.com wrote:
 --On Tuesday, November 02, 2010 11:07 PM +0100 Benjamin Griese
 der.dar...@gmail.com wrote:

 Hello Tim,

 the password you supply won't work, as it is not encoded in base64.

 Try to generate a password hash + base64-enc with slappasswd and set
 this string as your password hash for rootpw.
 http://linux.die.net/man/8/slappasswd

 Benjamin,

 There is no requirement that the password value for the rootpw entry in
 slapd.conf be SSHA hashed or Base 64 encoded.

 I.e.,

 rootpw  secret

 is perfectly valid.

 Also, an LDIF file with

 userPassword: secret

 is also perfectly valid, as either slapadd or slapd (via ldapadd) will take
 care of encoding it to Base64.

 --Quanah



 --

 Quanah Gibson-Mount
 Principal Software Engineer
 Zimbra, Inc
 
 Zimbra ::  the leader in open source messaging and collaboration




-- 
Here's my RSA Public key:
gpg --keyserver pgp.mit.edu --recv-keys 5A4873A9

Share and enjoy!!


slapd.conf
Description: Binary data

Re: unable to perform authenticated binds

2010-11-02 Thread Chris Jacobs 
Ya know, that leading space thing confused the heck out of me when I started 
writing a slapf.conf from scratch.  I'm guessing were ya'll to know at that 
start of spec'ing slapd.conf the methods that are now common to multi-line or 
'containerize' options, something different, more readable, and less error 
(yes, user error) prone would have been selected.

Really, white space shouldn't kill a config.

Hindsight, eh?

- chris

Chris Jacobs, Systems Administrator
Apollo Group  |  Apollo Marketing | Aptimus
2001 6th Ave Ste 3200 | Seattle, WA 98121
phone: 206.839-8245 | cell: 206.601.3256 | Fax: 208.441.9661
email:  chris.jac...@apollogrp.edu

- Original Message -
From: openldap-technical-boun...@openldap.org 
openldap-technical-boun...@openldap.org
To: Benjamin Griese der.dar...@gmail.com
Cc: Tim Dunphy bluethu...@gmail.com; openldap-technical@openldap.org 
openldap-technical@openldap.org
Sent: Tue Nov 02 17:30:29 2010
Subject: Re: unable to perform authenticated binds

Benjamin Griese wrote:
 Hello Tim,

 the password you supply won't work, as it is not encoded in base64.

Utter nonsense.

You missed the more obvious problem.

 databasebdb
 suffix  dc=example,dc=net
 rootdn  cn=Manager,dc=example,dc=net
 # Cleartext passwords, especially for the rootdn, should
 # be avoided.  See slappasswd(8) and slapd.conf(5) for details.
 # Use of strong authentication encouraged.
   rootpwsecret
 # rootpw {CRYPT}secret

The rootpw line has a leading space.

--
   -- Howard Chu
   CTO, Symas Corp.   http://www.symas.com
   Director, Highland Sun http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/


This message is private and confidential. If you have received it in error, 
please notify the sender and remove it from your system.

Re: unable to perform authenticated binds

2010-11-02 Thread Howard Chu 

Chris Jacobs wrote:

Ya know, that leading space thing confused the heck out of me when I started 
writing a slapf.conf from scratch.  I'm guessing were ya'll to know at that 
start of spec'ing slapd.conf the methods that are now common to multi-line or 
'containerize' options, something different, more readable, and less error 
(yes, user error) prone would have been selected.

Really, white space shouldn't kill a config.

Hindsight, eh?


Indeed, thanks so much for the exceedingly useful insight.

The practice was established long before I joined the Project. Enough people 
whine about all the other insignificant, backward-compatible changes we make 
that changing this is obviously a non-starter.


The use of whitespace is clearly described in the manpage and the Admin Guide. 
People who don't read the manpage deserve no sympathy.


--
  -- Howard Chu
  CTO, Symas Corp.   http://www.symas.com
  Director, Highland Sun http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/

Re: unable to perform authenticated binds

2010-11-02 Thread Howard Chu 

Howard Chu wrote:

Chris Jacobs wrote:

Ya know, that leading space thing confused the heck out of me when I started 
writing a slapf.conf from scratch.  I'm guessing were ya'll to know at that 
start of spec'ing slapd.conf the methods that are now common to multi-line or 
'containerize' options, something different, more readable, and less error 
(yes, user error) prone would have been selected.

Really, white space shouldn't kill a config.

Hindsight, eh?


Indeed, thanks so much for the exceedingly useful insight.

The practice was established long before I joined the Project.


Since long before the Project existed, actually.


Enough people
whine about all the other insignificant, backward-compatible changes we make
that changing this is obviously a non-starter.

The use of whitespace is clearly described in the manpage and the Admin Guide.
People who don't read the manpage deserve no sympathy.




--
  -- Howard Chu
  CTO, Symas Corp.   http://www.symas.com
  Director, Highland Sun http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/

Re: unable to perform authenticated binds

2010-11-02 Thread Chris Jacobs 
Well, I dunno, there's a /ton/ of material to cover for openldap newbies, and a 
simple config detail like this could be easily overlooked when figuring out how 
to do other things like multiple master scenarios/methods, syncing, bdb 
indexing for performance, the new (and exotic!) olc config, nss, pam, etc.

Frankly, you're right though, they don't need sympathy.  That's never helped a 
tech with a tech issue.

If you're not calling me out via thanks so much for the exceedingly useful 
insight then feel free to skip the rest of this.

If you were, why?  I was being colloquial, friendly, and empathetic.  We (well, 
maybe not you - I suspect you're very intelligent with a very high functioning 
memory/recall ability; no sarcasm!) will sometimes make silly mistakes or not 
understand something at first (or second!) pass.

I'm not now, nor was I then, faulting anyone's past decisions or recent replies.

- chris

Chris Jacobs, Systems Administrator
Apollo Group  |  Apollo Marketing | Aptimus
2001 6th Ave Ste 3200 | Seattle, WA 98121
phone: 206.839-8245 | cell: 206.601.3256 | Fax: 208.441.9661
email:  chris.jac...@apollogrp.edu

- Original Message -
From: Howard Chu h...@symas.com
To: Chris Jacobs
Cc: 'der.dar...@gmail.com' der.dar...@gmail.com; 'bluethu...@gmail.com' 
bluethu...@gmail.com; 'openldap-technical@openldap.org' 
openldap-technical@openldap.org
Sent: Tue Nov 02 19:23:27 2010
Subject: Re: unable to perform authenticated binds

Chris Jacobs wrote:
 Ya know, that leading space thing confused the heck out of me when I started 
 writing a slapf.conf from scratch.  I'm guessing were ya'll to know at that 
 start of spec'ing slapd.conf the methods that are now common to multi-line or 
 'containerize' options, something different, more readable, and less error 
 (yes, user error) prone would have been selected.

 Really, white space shouldn't kill a config.

 Hindsight, eh?

Indeed, thanks so much for the exceedingly useful insight.

The practice was established long before I joined the Project. Enough people
whine about all the other insignificant, backward-compatible changes we make
that changing this is obviously a non-starter.

The use of whitespace is clearly described in the manpage and the Admin Guide.
People who don't read the manpage deserve no sympathy.

--
   -- Howard Chu
   CTO, Symas Corp.   http://www.symas.com
   Director, Highland Sun http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/


This message is private and confidential. If you have received it in error, 
please notify the sender and remove it from your system.