Description of problem: Hey guys, I'm setting up 2 mmr servers, and am wondering why the aci's on both machines don't end up being the same. All of the replication and configuring of the servers has been done in perl and NOT the console. Here is the process I used when setting up the servers. I'm using custom built packages on etch. I can attach my perl module if need be. Version-Release number of selected component (if applicable): ii fedora-ds-admin 1.1.6 Fedora Administration Server (admin) ii fedora-ds-admin-console 1.1.2 Fedora Admin Server Management Console ii fedora-ds-base 1.1.3 Fedora Directory Server (base) ii fedora-ds-console 1.1.2 Fedora Directory Server Management Console ii mozldap 6.0.5 Mozilla LDAP C SDK ii mozldap-dev 6.0.5 Mozilla LDAP C SDK ii mozldap-tools 6.0.5 Mozilla LDAP C SDK ii ldapsdk 4.17-4 Enables applications to manage information s ii perldap 1.5.2 PerLDAP is a set of modules written in Perl ii libadminutil 1.1.7 Utility library for directory server adminis ii libsvrcore 4.0.4 Secure PIN handling using NSS crypto ii libapache2-mod-nss 1.0.8 mod_nss is an SSL provider derived from the How reproducible: Steps to Reproduce: 1. install mmr1 server using setup-ds-admin.pl 2. install mmr2 server using setup-ds.pl 3. configure ssl/tls on each machine and confirm ldapsearchs etc are encrypted. 4. create root suffix o=netscaperoot on mmr2. 5. enable mmr replication of userroot on both mmr1 and mmr2 6. init UserRoot replication agreement on mmr1. 7. enable mmr replication of o=netscaperoot on both mmr1 and mmr2. 8. init NetscapeRoot replication agreement on mmr1. 9. run register-ds-admin.pl on mmr2 At this point, I can confirm that encryption is working over both machines, all replication agreements are over SSL and are working as expected. admin server is running on both machines, and both servers are accessible from each admin-server instance. Actual results: Different aci's on mmr1 and mmr2 for cn=schema and cn=config Expected results: Same aci's on both. Additional info: aci dumps mmr1 - cn=schema # schema dn: cn=schema aci: (target="ldap:///cn=schema")(targetattr !="aci")(version 3.0;acl "anonymo us, no acis"; allow (read, search, compare) userdn = "ldap:///anyone";) aci: (targetattr="*")(version 3.0; acl "Configuration Administrators Group"; a llow (all) groupdn="ldap:///cn=Configuration Administrators, ou=Groups, ou=To pologyManagement, o=NetscapeRoot";) aci: (targetattr="*")(version 3.0; acl "Configuration Administrator"; allow (a ll) userdn="ldap:///uid=admin,ou=Administrators, ou=TopologyManagement, o=Net scapeRoot";) aci: (targetattr = "*")(version 3.0; acl "SIE Group"; allow (all) groupdn = "l dap:///cn=slapd-xxxdmns0, cn=Fedora Directory Server, cn=Server Group, cn=xxx dmns0.xxx.xx.xx.xx, ou=xxx.xx.xx.ca, o=NetscapeRoot";) mmr2 - cn=schema # schema dn: cn=schema aci: (target="ldap:///cn=schema")(targetattr !="aci")(version 3.0;acl "anonymo us, no acis"; allow (read, search, compare) userdn = "ldap:///anyone";) mmr1 - cn=config dn: cn=config aci: (targetattr="*")(version 3.0; acl "Configuration Administrators Group"; a llow (all) groupdn="ldap:///cn=Configuration Administrators, ou=Groups, ou=To pologyManagement, o=NetscapeRoot";) aci: (targetattr="*")(version 3.0; acl "Configuration Administrator"; allow (a ll) userdn="ldap:///uid=admin, ou=Administrators, ou=TopologyManagement, o=Ne tscapeRoot";) aci: (targetattr = "*")(version 3.0; acl "SIE Group"; allow (all) groupdn = "l dap:///cn=slapd-xxxdmns0, cn=Fedora Directory Server, cn=Server Group, cn=xxx dmns0.xxx.xx.xx.ca, ou=xxx.xx.xx.ca, o=NetscapeRoot";) mmr2 - cn=config none.
The difference in aci's is due to setup-ds.pl not adding any Admin Server specific aci's (which it shouldn't). The "cn=schema" and "cn=config" trees are not replicated, hence the aci's don't get sync'd up. (there is some replication of schema, but it's not sending the whole tree). I suppose the proper thing would be for register-ds-admin.pl to add the proper default aci's for "cn=schema" and "cn=config" to the instance being registered with the Admin Server. It should be noted that any custom aci's in these two trees will NOT be replicated, however we should attempt to make the defaults the same after registration.
Created attachment 333215 [details] CVS Diffs
Does register-ds-admin.pl also enable and configure the PTA plugin? If not, then the console admin user won't be able to manage the DS. This also seems to be problem with ds_create.
(In reply to comment #3) > Does register-ds-admin.pl also enable and configure the PTA plugin? If not, > then the console admin user won't be able to manage the DS. This also seems to > be problem with ds_create. It appears that register-ds-admin-pl doesn't enable and configure PTA either.
Created attachment 333503 [details] New PTA ldif template
Created attachment 333508 [details] Revised Diffs There were a few other issues to deal with in addition to the missing ACIs. The PTA plug-in was not being configured since the LDIF template that was used was an entire new PTA plug-in entry, which never gets added since it already exists. I changed this to a LDIF mod template. We also only want to configure PTA if it is not already configured, or if we are switching the config DS. This will prevent overwriting any custom tweaks to the PTA plug-in, such as using LDAPS to communicate with the config DS. I found another issue during testing with the ldapStart parameter in adm.conf getting set incorrectly after running register-ds-admin.pl. This parameter is supposed to point to the start-slapd script of the config DS, but register-ds-admin.pl was always changing this to the last instance that it registered (which will never be the config DS if you have more than one instance). We need to ensure that the slapd info in the inf is the config DS before updating the Admin Server config files.
Ok. Another problem is that there is no resource key for error_create_inf_from_config, and we need to pass in the errno ($!) to that error. We can open a separate bug for that though.
Created attachment 333511 [details] CVS commit message Checked into adminserver (HEAD). Thanks to Rich for his review!
*** Bug 488180 has been marked as a duplicate of this bug. ***
I've confirmed that post server registration with another admin server, you are able to access the ds console for the remote replica from the hosting admin server's console without prompting for directory manager's password and that all the proper default ACIs are added to the remote server. However, comment #6 appears that an issue was fixed with PTA - can you add steps to verify this issue? thanks
If you are able to create a new instance of directory server, from the command line or console, and you can access it in the console without having to authenticate as directory manager, and are able to change configuration settings, then the PTA bug is fixed. It is PTA that allows the console admin user (not directory manager) to access a directory server instance in the console.
Great - fix verfied - RHEL 5 DS 8.1
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/RHEA-2009-0455.html