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
[root@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 quanah@zimbra.com wrote:
--On Tuesday, November 02, 2010 7:59 PM -0700 Chris Jacobs Chris.Jacobs@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
holy crap!! it was the extra colon that killed it! found it, fixed it.. man oh man sorry for the intrusion!
On Wed, Nov 3, 2010 at 6:02 PM, Tim Dunphy bluethundr@gmail.com wrote:
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
[root@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 quanah@zimbra.com wrote:
--On Tuesday, November 02, 2010 7:59 PM -0700 Chris Jacobs Chris.Jacobs@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!!
--On Wednesday, November 03, 2010 6:09 PM -0400 Tim Dunphy bluethundr@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
Quanah Gibson-Mount wrote:
--On Wednesday, November 03, 2010 6:09 PM -0400 Tim Dunphy bluethundr@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...
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
And again I should have all the schemas in place to make this work...
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
Why this ldif will work in one directory but not another is a mystery at this point..
thanks again
On Wed, Nov 3, 2010 at 9:43 PM, Howard Chu hyc@symas.com wrote:
Quanah Gibson-Mount wrote:
--On Wednesday, November 03, 2010 6:09 PM -0400 Tim Dunphy bluethundr@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/
--On Thursday, November 04, 2010 3:37 PM -0400 Tim Dunphy bluethundr@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
On 11/3/10 11:02 PM, Tim Dunphy wrote:
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
remove the second ':' in userPassword. The value is not Base64 encoded.
userPassword: {SSHA}secret
openldap-technical@openldap.org
-
Emmanuel Lecharny -
Howard Chu -
Quanah Gibson-Mount -
Tim Dunphy