Red Hat Bugzilla – Bug 431103
Cannot setup ds with remote config DS
Last modified: 2015-01-04 18:30:33 EST
If you attempt to run setup-ds-admin.pl and use a configuration DS running on a different machine, you will get an error like this: Creating the configuration directory server . . . dn: cn=Fedora Directory Server, cn=Server Group, cn=host.example.com, ou=example.com, o=NetscapeRoot objectclass: nsApplication objectclass: groupOfUniqueNames objectclass: top cn: Fedora Directory Server nsproductname: Fedora Directory Server nsproductversion: 1.1.0 nsnickname: slapd nsbuildnumber: 2008.03.27 nsvendor: Fedora Project installationtimestamp: 20080131195003Z nsexpirationdate: 0 nsbuildsecurity: domestic uniquemember: cn=slapd-host, cn=Fedora Directory Server, cn=Server Group, cn=vhost.example.com, ou=example.com, o=NetscapeRoot ... more of entry ... Error adding entry 'cn=Fedora Directory Server, cn=Server Group, cn=host.example.com, ou=example.com, o=NetscapeRoot'. Error: No such object Could not register the directory server with the configuration directory server.
There is a workaround - if the fqdn is host.example.com, you just have to create the following entries: dn: cn=host.example.com, ou=example.com, o=NetscapeRoot objectclass: top objectclass: nsHost objectclass: groupOfUniqueNames cn: host.example.com nsosversion: output of uname -a on the machine nshardwareplatform: arch e.g. i386 or x86_64 or ... serverHostName: host.example.com dn: cn=Server Group, cn=host.example.com, ou=example.com, o=NetscapeRoot objectclass: top objectclass: nsAdminGroup objectclass: nsDirectoryInfo objectclass: groupOfUniqueNames nsAdminGroupName: Server Group nsDirectoryInfoRef: cn=User Directory, ou=Global Preferences, ou=example.com, o=NetscapeRoot
(In reply to comment #1) > There is a workaround - if the fqdn is host.example.com, you just have to create > the following entries: > The entries should be created on the configuration DS - be sure to replace example.com with the real domain and host.example.com with the real hostname.
In order for the admin server to show up as well for "host.example.com" I had to add this under bsadminsiedn: cn=admin-serv-host, cn=Fedora Administration Server, cn=Server Group, cn=host.example.com, ou=example.com, o=NetscapeRoot
spelling correction: s/bsadminsiedn/nsadminsiedn/
With newer version of fds-1.1, it seems necessary to add what Yvo mentionned, which is finally, and also a "UserPreference" entry. So put that in an ldif file, and import it on the configuration DS : dn: ou=UserPreferences, ou=example.com, o=NetscapeRoot aci: (targetattr = "*")(version 3.0; acl "Allow saving of User Preferences"; allow (add) userdn = "ldap:///all";) ou: UserPreferences objectClass: top objectClass: organizationalUnit dn: cn=host.example.com, ou=example.com, o=NetscapeRoot objectclass: top objectclass: nsHost objectclass: groupOfUniqueNames cn: host.example.com nsosversion: output of uname -a on the machine nshardwareplatform: arch e.g. i386 or x86_64 or ... serverHostName: host.example.com dn: cn=Server Group, cn=host.example.com, ou=example.com, o=NetscapeRoot objectclass: top objectclass: nsAdminGroup objectclass: nsDirectoryInfo objectclass: groupOfUniqueNames nsAdminGroupName: Server Group nsDirectoryInfoRef: cn=User Directory, ou=Global Preferences, ou=example.com, o=NetscapeRoot nsadminsiedn: cn=admin-serv-host, cn=Fedora Administration Server, cn=Server Group, cn=host.example.com, ou=example.com, o=NetscapeRoot
Created attachment 311740 [details] admin server diffs
Created attachment 311741 [details] diffs
Created attachment 311748 [details] cvs commit log Reviewed by: nkinder (Thanks!) Branch: HEAD Fix Description: This fix has two main parts. The first part is to fix setup. I took parts out of the 01nsroot template and put them into the templates that set up the directory server and admin server. So when those servers are registered, they will create those common entries if not present, or otherwise modify them to add the necessary information. I had to add uname_m and uname_a and some other items to the mapping files. I fixed a typo in one of the template files. I changed setup to create new directory server instances shutdown, so that when they are configured for the passthrough auth plugin, it will be working when started. Otherwise, directory servers you create with setup will not be manageable in the console until after they are restarted. This is the same way that ds_create works. The second part of the fix is to allow people to fix "broken" installs. I added a -u (update) option to setup. This will scan for exsiting installations are re-register all servers found. The dialog flow is pretty simple - it just confirms that you want to run update mode, then asks for the config ds information, then re-registers all servers with the config ds, updating any information that is missing or outdated. Platforms tested: RHEL5, Fedora 8, Fedora 9 Flag Day: no Doc impact: Yes - need to document the new -u option.
Created attachment 311760 [details] cvs commit log for 8.0 branch
Current code fails to create new instance if using a custom config dir (e.g. other than /etc/dirsrv) - that is, if using slapd.config_dir set to another directory. This patch uses DS_CONFIG_DIR for the location of the directory server config. DS_CONFIG_DIR is set in DSCreate.pm to the value of slapd.config_dir if set, or the default compiled in value (e.g. /etc/dirsrv) otherwise. 12-17 11:48:11.000000000 -0700 --- AdminUtil.pm.in 2008-07-24 07:43:26.000000000 -0600 *************** *** 357,364 **** sub createSubDSNoConn { my $inf = shift; my $errs = shift; ! my $dseldif = "@instconfigdir@/slapd-" . $inf->{slapd}->{ServerIdentifier} . "/dse.ldif"; my $conn = new FileConn($dseldif); return internalCreateSubDS($conn, $inf, $errs); --- 357,367 ---- sub createSubDSNoConn { my $inf = shift; my $errs = shift; + # $ENV{DS_CONFIG_DIR} is set in ds instance creation + my $dsconfdir = $ENV{DS_CONFIG_DIR} || + "@instconfigdir@/slapd-" . $inf->{slapd}->{ServerIdentifier}; ! my $dseldif = "$dsconfdir/dse.ldif"; my $conn = new FileConn($dseldif); return internalCreateSubDS($conn, $inf, $errs);
Reviewed by: nhosoi (Thanks!) Branch: HEAD and Directory_Server_8_0_Branch Fix Description: If using a non-standard config dir for the directory server, creating additional instances with setup-ds-admin.pl fails, because it doesn't take into consideration the location. DS_CONFIG_DIR is set in DSCreate.pm to the real location of the new directory server instance config directory. Platforms tested: Fedora 8 Flag Day: no Doc impact: no Commit to HEAD: Checking in AdminUtil.pm.in; /cvs/dirsec/adminserver/admserv/newinst/src/AdminUtil.pm.in,v <-- AdminUtil.pm.in new revision: 1.19; previous revision: 1.18 done Commit to Directory_Server_8_0_Branch: Checking in AdminUtil.pm.in; /cvs/dirsec/adminserver/admserv/newinst/src/AdminUtil.pm.in,v <-- AdminUtil.pm.in new revision: 1.18.2.1; previous revision: 1.18 done
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2008-0602.html
fedora-ds-admin-1.1.6-1.fc8 has been submitted as an update for Fedora 8. http://admin.fedoraproject.org/updates/fedora-ds-admin-1.1.6-1.fc8
fedora-ds-admin-1.1.6-1.fc9 has been submitted as an update for Fedora 9. http://admin.fedoraproject.org/updates/fedora-ds-admin-1.1.6-1.fc9
fedora-ds-admin-1.1.6-1.fc9 has been pushed to the Fedora 9 stable repository. If problems still persist, please make note of it in this bug report.
fedora-ds-admin-1.1.6-1.fc8 has been pushed to the Fedora 8 stable repository. If problems still persist, please make note of it in this bug report.