[389-users] restarting the 389 after a reboot
Nathan Kinder
nkinder at redhat.com
Fri Jun 25 14:44:30 UTC 2010
On 06/24/2010 03:49 PM, Steven Jones wrote:
> Steven Jones wrote:
>
>>
> 8><-----
>
>>
>> see also the configuration directory ldap url - ldapurl in
>>
>> /etc/dirsrv/admin-serv/adm.conf
>>
>>
> 8><-----
>
>> Ok, I fixed the latter by editing the adm.conf to point at
>> 636....however I now have a SSL error...
>>
>> ============
>>
>> [root at vuwunicooimm001 admin-serv]# ldapsearch -x -D "cn=ldapadmin" -w
>> XXXXXXX -b o=netscaperoot "(&(nsServerID=slapd-vuwunicooimm001))"
>>
>> ldap_bind: Can't contact LDAP server (-1)
>>
>> additional info: error:14090086:SSL
>> routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed
>>
>>
> Why is /usr/bin/ldapsearch attempting to use SSL by default? What's in
> your /etc/openldap/ldap.conf or ~/.ldaprc?
>
> Ok, fixed
>
> ldaps changed to ldap
>
>
>> ============
>>
>>
>>
>> Ive tried using this syntax but with no joy...
>>
>>
>>
>> ldapmodify -x -D "cn=directory manager" -w password
>>
>> dn: dn of your server instance entry
>>
>> changetype: modify
>>
>> replace: nsServerSecurity
>>
>> nsServerSecurity: on
>>
>>
>>
>> so my command is,
>>
>>
>>
>> ldapmodify -x -D "cn=lpdapadmin" -w password XXXXXXX
>> dn:vuwunicooimm001.vuw.ac.nz changetype: modify replace:
>> nsServerSecurity nsServerSecurity on
>>
>>
> ? this is all on one command line?
>
>
> Yes...
>
>
> I guess it's not clear from the
> example, but ldapmodify by default wants to read the LDIF input from
> stdin - so after you type in
>
> OK.......
>
>
> $ ldapmodify -x -D "cn=lpdapadmin" -w password XXXXXXX
> it will wait for you to type in the rest on stdin, followed by a blank
> line (i.e. hit Enter twice) followed by Ctrl-C or Ctrl-D to "get out" of
> ldapmodify
>
>
> ===================
> [root at vuwunicooimm001 admin-serv]# ldapmodify -x -D "cn=lpdapadmin"
> ldap_bind: Server is unwilling to perform (53)
> additional info: Unauthenticated binds are not allowed
> [root at vuwunicooimm001 admin-serv]# ldapsearch -x -D "cn=ldapadmin" -w XXXXXX
> ldap_bind: No such object (32)
> [root at vuwunicooimm001 admin-serv]#
> ===================
>
> um?
>
You need to specify a password with the "-w" option to ldapmodify.
Supplying a bind DN with no password is considered an "unauthenticated"
bind, which is not allowed by default.
I believe the ldapsearch error is saying that the "cn=ldapadmin" entry
does not exist. This does not appear to be a full DN. You can check
what your ldap "superuser" account is by looking at your nsslapd-rootdn
setting /etc/dirsrv/slapd-<foo>/dse.ldif. The default is "cn=Directory
Manager". If you actually created a "cn=ldapadmin" user in your
database, you need to specify the rest of the DN when binding as that user.
>
> you could also dump those commands in a file and run
> $ ldapmodify -x -D "cn=lpdapadmin" -w password XXXXXXX -f /path/to/file.ldif
>
> ===================
> [root at vuwunicooimm001 admin-serv]# ldapmodify -x -D "cn=lpdapadmin" -w cvbrty542 -f file.ldif
> ldap_bind: No such object (32)
> [root at vuwunicooimm001 admin-serv]#
> ===================
>
> 8><----------
>
>>
> Is the directory server listening for TLS/SSL requests on port 636?
> That is, have you configured the directory server for TLS/SSL and have
> you confirmed that it is listening?
>
>>
> 8><-----
>
>>
> Before you do anything else, confirm that the directory server is indeed
> listening for TLS/SSL requests on port 636.
>
>>
> =============
> [root at vuwunicooimm001 admin-serv]# netstat -a -n |grep :636
> tcp 0 0 127.0.0.1:49186 127.0.0.1:636 TIME_WAIT
> tcp 0 0 127.0.0.1:49185 127.0.0.1:636 TIME_WAIT
> tcp 0 0 127.0.0.1:35428 127.0.0.1:636 TIME_WAIT
> tcp 0 0 127.0.0.1:35429 127.0.0.1:636 TIME_WAIT
> tcp 0 0 127.0.0.1:35430 127.0.0.1:636 TIME_WAIT
> tcp 0 0 127.0.0.1:35424 127.0.0.1:636 TIME_WAIT
> tcp 0 0 127.0.0.1:35425 127.0.0.1:636 TIME_WAIT
> tcp 0 0 127.0.0.1:35426 127.0.0.1:636 TIME_WAIT
> tcp 0 0 127.0.0.1:35427 127.0.0.1:636 TIME_WAIT
> tcp 0 0 127.0.0.1:35412 127.0.0.1:636 TIME_WAIT
> tcp 0 0 127.0.0.1:35413 127.0.0.1:636 TIME_WAIT
> tcp 0 0 127.0.0.1:35414 127.0.0.1:636 TIME_WAIT
> tcp 0 0 127.0.0.1:35415 127.0.0.1:636 TIME_WAIT
> tcp 0 0 127.0.0.1:35408 127.0.0.1:636 TIME_WAIT
> tcp 0 0 127.0.0.1:35409 127.0.0.1:636 TIME_WAIT
> tcp 0 0 127.0.0.1:35410 127.0.0.1:636 TIME_WAIT
> tcp 0 0 127.0.0.1:35411 127.0.0.1:636 TIME_WAIT
> tcp 0 0 127.0.0.1:35420 127.0.0.1:636 TIME_WAIT
> tcp 0 0 127.0.0.1:35421 127.0.0.1:636 TIME_WAIT
> tcp 0 0 127.0.0.1:35422 127.0.0.1:636 TIME_WAIT
> tcp 0 0 127.0.0.1:35423 127.0.0.1:636 TIME_WAIT
> tcp 0 0 127.0.0.1:35416 127.0.0.1:636 TIME_WAIT
> tcp 0 0 127.0.0.1:35417 127.0.0.1:636 TIME_WAIT
> tcp 0 0 127.0.0.1:35418 127.0.0.1:636 TIME_WAIT
> tcp 0 0 127.0.0.1:35419 127.0.0.1:636 TIME_WAIT
> tcp 0 0 127.0.0.1:35404 127.0.0.1:636 TIME_WAIT
> tcp 0 0 127.0.0.1:35405 127.0.0.1:636 TIME_WAIT
> tcp 0 0 127.0.0.1:35406 127.0.0.1:636 TIME_WAIT
> tcp 0 0 127.0.0.1:35407 127.0.0.1:636 TIME_WAIT
> tcp 0 0 127.0.0.1:35403 127.0.0.1:636 TIME_WAIT
> tcp 0 0 :::636 :::* LISTEN
> [root at vuwunicooimm001 admin-serv]#
> ============
>
> regards
>
> --
> 389 users mailing list
> 389-users at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-users
>
More information about the 389-users
mailing list