Bug 431103

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.