Gregory P. Ennis wrote: > On Mon, 2007-05-21 at 12:12 -0600, Richard Megginson wrote: > >> Gregory P. Ennis wrote: >> >>> <snip> >>> Richard, >>> >>> Thank you, one step further.... but still no cigar. >>> >>> I had about 10 users to enter as test data, but am not sure if the data >>> made it to the server. >>> >>> My entry command was : >>> ldapmodify -v -x -a -D "cn=Directory Manager" -W -f ./EcCare.ldif >>> >>> And the response was : >>> >>> add objectclass: >>> top >>> domain >>> add dc: >>> EcCare >>> add aci: >>> (target ="ldap:///dc=EcCare,dc=com";)(targetattr ! >>> ="userPassword")(version 3.0;acl "Anonymous read-search access";allow >>> (read, search, compare)(userdn = "ldap:///anyone";);) >>> (target="ldap:///dc=EcCare,dc=com";) (targetattr = "*")(version >>> 3.0; acl "allow all Admin group"; allow(all) groupdn = >>> "ldap:///cn=Directory Administrators,ou=Groups,dc=EcCare,dc=com";) >>> adding new entry "dc=EcCare,dc=com" >>> modify complete >>> ldap_add: Already exists (68) >>> >>> When I perform : >>> >>> ldapsearch -x -b 'dc=eccare,dc=com' '(objectclass=*)' >>> >>> I get : >>> >>> dn: dc=EcCare,dc=com >>> objectClass: top >>> objectClass: domain >>> dc: EcCare >>> >>> # Directory Administrators, EcCare.com >>> dn: cn=Directory Administrators, dc=EcCare,dc=com >>> objectClass: top >>> objectClass: groupofuniquenames >>> cn: Directory Administrators >>> >>> Note: I used the Example.ldif as a template with some changes of the >>> data. >>> >>> When I do : >>> >>> ldapsearch -x -b 'dc=eccare,dc=com' '(cn=Ennis)' >>> >>> I get : >>> >>> # search result >>> search: 2 >>> result: 0 Success >>> >>> Which causes me to believe the details of the data did not make it to >>> the server. >>> >>> >> You are correct. The error Already exists (68) means you tried to add >> an entry that already exists (probably dc=EcCare,dc=com). Remove that >> entry from your ldif file and try again. When you run setup, and choose >> your initial base suffix, setup will create that entry for you. You can >> also add the "-c" argument to ldapmodify to make it continue despite >> errors. >> >>> If my questions are too newbie I will certianly take some direction to >>> read, but so far I have not found the appropriate docs. >>> >>> Thanks again!!!! >>> >>> Greg >>> >>> > Richard, > > That was helpful... Looks like I have the data in the server now. I can > get ldapsearch to work but am not able to get evolution to display any > of the data. I was able to turn the logs on to debug for openldap, > where can I do this for fedora-ds so I can look at how evolution is > accessing slapd > http://directory.fedoraproject.org/wiki/FAQ#Troubleshooting Keep in mind that the access log is buffered, which means requests and responses will not be immediately available in that file. > Thanks again for your help!!!! > > Greg > > -- > Fedora-directory-users mailing list > Fedora-directory-users at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3245 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.fedoraproject.org/pipermail/389-users/attachments/20070521/9d2882d0/attachment.bin
