Bug 486402 - setup-ds.pl + register-ds-admin.pl generates different aci's then setup-ds-admin.pl
setup-ds.pl + register-ds-admin.pl generates different aci's then setup-ds-a...
Status: CLOSED CURRENTRELEASE
Product: 389
Classification: Community
Component: Install/Uninstall (Show other bugs)
1.1.3
i686 Linux
high Severity high
: ---
: ---
Assigned To: Nathan Kinder
Chandrasekar Kannan
:
: 488180 (view as bug list)
Depends On:
Blocks: 249650 FDS1.2.0
  Show dependency treegraph
 
Reported: 2009-02-19 11:25 EST by Ryan Braun
Modified: 2015-01-04 18:36 EST (History)
5 users (show)

See Also:
Fixed In Version: 8.1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-04-29 19:10:37 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
CVS Diffs (927 bytes, patch)
2009-02-25 15:08 EST, Nathan Kinder
no flags Details | Diff
New PTA ldif template (1.32 KB, text/plain)
2009-02-27 11:47 EST, Nathan Kinder
no flags Details
Revised Diffs (8.24 KB, patch)
2009-02-27 12:05 EST, Nathan Kinder
no flags Details | Diff
CVS commit message (1.50 KB, text/plain)
2009-02-27 12:41 EST, Nathan Kinder
no flags Details

  None (edit)
Description Ryan Braun 2009-02-19 11:25:19 EST
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.
Comment 1 Nathan Kinder 2009-02-25 12:49:39 EST
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.
Comment 2 Nathan Kinder 2009-02-25 15:08:18 EST
Created attachment 333215 [details]
CVS Diffs
Comment 3 Rich Megginson 2009-02-25 15:21:06 EST
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.
Comment 4 Nathan Kinder 2009-02-25 15:50:50 EST
(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.
Comment 5 Nathan Kinder 2009-02-27 11:47:27 EST
Created attachment 333503 [details]
New PTA ldif template
Comment 6 Nathan Kinder 2009-02-27 12:05:17 EST
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.
Comment 7 Rich Megginson 2009-02-27 12:18:30 EST
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.
Comment 8 Nathan Kinder 2009-02-27 12:41:08 EST
Created attachment 333511 [details]
CVS commit message

Checked into adminserver (HEAD).  Thanks to Rich for his review!
Comment 9 Nathan Kinder 2009-03-03 16:24:59 EST
*** Bug 488180 has been marked as a duplicate of this bug. ***
Comment 10 Jenny Galipeau 2009-03-17 12:45:03 EDT
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
Comment 11 Rich Megginson 2009-03-17 12:58:50 EDT
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.
Comment 12 Jenny Galipeau 2009-03-17 13:19:50 EDT
Great - fix verfied - RHEL 5 DS 8.1
Comment 13 Chandrasekar Kannan 2009-04-29 19:10:37 EDT
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

Note You need to log in before you can comment on or make changes to this bug.