[389-users] 389 upgrade

Nathan Kinder nkinder at redhat.com
Wed Sep 23 21:02:51 UTC 2009


On 09/23/2009 01:51 PM, Rich Megginson wrote:
> Juan Asensio Sánchez wrote:
>> Hi
>>
>> Thanks Rich for your help. I finally have upgraded FDS to 389. I'll
>> try to remove the entries in the admin console referring to the old
>> Fedora DS. Now I will test replication and some other things.
>>
>> One more thing. Where is the parameter to fully disable anonymous 
>> connections?
> nsslapd-allow-unauthenticated-binds in cn=config
This setting is not for controlling anonymous binds.  It is for 
controlling unauthenticated binds (where a bind DN is specified without 
a password, which results in anonymous).  A true anonymous bind (empty 
or NULL bind DN) will still be allowed regardless of this setting.

I am working on a new setting for disabling anonymous access right now.  
This will restruct not only BIND operations, but other operations that 
are attempted as anonymous since LDAPv3 doesn't require a BIND operation 
to be performed.
>> Regards.
>>
>> 2009/9/21 Rich Megginson <rmeggins at redhat.com>:
>>> Juan Asensio Sánchez wrote:
>>>>>> And reboot... After that, when connecting with the console, we have
>>>>>> two entries for the directory server and two for the administration
>>>>>> server.
>>>>>>
>>>>> Yep, this is a known bug.  You can ignore the Fedora ones - the 
>>>>> 389 ones
>>>>> are
>>>>> the real ones.
>>>>>
>>>> Is there any bug open about this and how to fix/remove these entries?
>>>>
>>> There is a bug open - 
>>> https://bugzilla.redhat.com/show_bug.cgi?id=520493
>>>
>>> 389 1.2.3 will contain code to fix these issues during update - this 
>>> code is
>>> now in our SCM - Unfortunately, fixing/removing these entries 
>>> manually will
>>> be tricky
>>>>>> One of each does not show the icon it should, and when I click
>>>>>> on it, it tries to download new jars, but it can not.
>>>>>>
>>>>> What error does it give?
>>>>>
>>>> Failed to install a local copy of 389-ds-1.2.jar or one of it 
>>>> supporting
>>>> files.
>>>> Please ensure that the appropiate console package is installed on the
>>>> Administration Server.
>>>> HTTP response timeout
>>>>
>>>> I think it is trying to get the files with http instead of https,
>>>> although I have connected to the console with https.
>>>>
>>> One of the side effects of the bug is that it nukes your tls/ssl
>>> configuration.
>>>>>> If I use the old
>>>>>> item for the administration console (that shows the icon), in the
>>>>>> encryption tab , SSL is disabled, but before the upgrade it was
>>>>>> enabled, but if i try to access the server with the browser, i must
>>>>>> use https (¿?). Why is SSL disabled? And if it is disabled, why 
>>>>>> must I
>>>>>> access using https? Is there any step I haven't done?
>>>>>>
>>>>>>
>>>>> This is also a bug.  The update procedure does not preserve the SSL
>>>>> settings
>>>>> for your old (Fedora) servers when it adds the new (389) servers.
>>>>>
>>>> But how can I connect to the console with https if the upgrade has
>>>> disabled it?
>>>>
>>> You need to find the entries that the console uses to get the TLS/SSL
>>> information:
>>> ldapsearch -LLL -x -D "cn=directory manager" -w yourpassword -b
>>> o=NetscapeRoot objectclass=nsConfig dn
>>>
>>> you can ignore the entries that start with cn=task summary
>>>
>>> For the entry that begins with cn=configuration, cn=admin-serv-.....
>>> do an ldapmodify like this:
>>> ldapmodify x -D "cn=directory manager" -w yourpassword
>>> dn: cn=configuration, cn=admin-serv-.....
>>> changetype: modify
>>> replace: nsServerSecurity
>>> nsServerSecurity: on
>>>
>>>
>>> For the entries that begin with cn=slapd-........
>>> do an ldapmodify like this:
>>> ldapmodify x -D "cn=directory manager" -w yourpassword
>>> dn: cn=slapd-.......
>>> changetype: modify
>>> replace: nsServerSecurity
>>> nsServerSecurity: on
>>>
>>>
>>> You should also verify the nsSecureServerPort attribute in the 
>>> cn=slapd-....
>>> entries if you used a port other than 636.
>>>
>>> After you make these changes, restart your admin server (service
>>> dirsrv-admin restart), then try the console again.
>>>> -- 
>>>> 389 users mailing list
>>>> 389-users at redhat.com
>>>> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>>>
>>>
>>> -- 
>>> 389 users mailing list
>>> 389-users at redhat.com
>>> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>>>
>>>
>>
>> -- 
>> 389 users mailing list
>> 389-users at redhat.com
>> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>
>
> ------------------------------------------------------------------------
>
> --
> 389 users mailing list
> 389-users at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>    

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/fedora-directory-users/attachments/20090923/fbb161b1/attachment.htm>


More information about the Fedora-directory-users mailing list