Description of problem: Run register-ds-admin.pl to create admin server, register admin config server, and register ipa directory server. Admin server is created and config ds created and registered successfully. Attempt to register ipa directory results in the error message: The map value 'ServerAdminID' for key 'as_uid' did not map to a value in any of the given information files. Version-Release number of selected component (if applicable): 1.2.8-0.3.a3 on Fedora 14 How reproducible:Run register-ds-admin.pl Steps to Reproduce: 1. Run register-ds-admin.pl 2. 3. Actual results: Script stops and produces an error message (above) along with the previous debugging statement: +Processing /usr/share/dirsrv/data/16dssuffixadmin.mod.tmpl ... Expected results: ipa directory should be registered with admin server Additional info:
I just discovered the updated 389-ds packages in f14-testing and updated my install so that I'm now running 389-ds-base-1.2.8.0-1 on Fedora 14. Still the same error message.
I just tested against new test version 389-ds-base-1.2.8.1-1.fc14. Still same result. Not sure how this was fixed previously, but would a similar approach work here? Is there a workaround to enable use of the UI as long as this is broken?
Can you run register-ds-admin.pl -ddd and attach the output to this bug? afaik there is no workaround - it is a fairly complex task to add/modify all the right entries under o=netscaperoot to register the server - that's why we have the script - if you are a perl hacker, patches are appreciated
Wow, you weren't kidding. I did run with -ddd which showed a slew of directory additions/changes. As I've previously mentioned the admin portion of the register-ds-admin.pl script works perfectly. The problem begins when registering the ds. In this case, an IPA server. 12dsconfig.mod.tmpl -> this makes changes to cn=config and works 13dsschema.mod.tmpl -> this makes changes to cn=schema and works 16dssuffixadmin.mod.tmpl -> this makes changes to ipa dc=4test,dc=net, it executes twice for some reason (that is probably a bug in itself, no?), although appears to work as the ACLs do show up properly in the ds; here's the output (just shown once here for brevity): +Processing /usr/share/dirsrv/data/16dssuffixadmin.mod.tmpl ... +++check_and_add_entry: Found entry dc=4test,dc=net +++Adding attr=aci value=(targetattr="*")(version 3.0; acl "Configuration Administrators Group"; allow (all) groupdn="ldap:///cn=Configuration Administrators,ou=Groups,ou=TopologyManagement,o=NetscapeRoot";) to entry dc=4test,dc=net +++Adding attr=aci value=(targetattr="*")(version 3.0; acl "Configuration Administrator"; allow (all) userdn="ldap:///uid=admin,ou=Administrators,ou=TopologyManagement,o=NetscapeRoot";) to entry dc=4test,dc=net +++Adding attr=aci value=(targetattr = "*")(version 3.0; acl "SIE Group"; allow (all) groupdn = "ldap:///cn=slapd-4TEST-NET,cn=389 Directory Server,cn=Server Group,cn=ipa.4test.net,ou=4test.net,o=NetscapeRoot";) to entry dc=4test,dc=net Then... +++Attempting connection to ipa.4test.net:51803 certdir configdir /etc/dirsrv/admin-serv The map value 'ServerAdminID' for key 'as_uid' did not map to a value in any of the given information files. The port 51803 here is the admin ds. As you can see from the above entries, it *does* appear to know that ServerAdminID=admin as you can see it substituted as uid=admin in the second ACL entry. I've looked at previous changelogs that lead me to believe that perhaps it's as simple as the script not knowing what ServerAdminID is at the time it tries to connect to the admin ds server this second time (it connected successfully during an earlier point of the script). If that's the case though, it seems like someone would have run into this before. I'm not sure why registering an ipa ds would create a unique situation for the script. I'm still hunting through the various perl modules and the script itself to try and find an answer, but nothing yet. If this rings true with anyone else who's previously fixed this problem, perhaps they'll know right away what the issue is.
try register-ds-admin.pl admin.ServerAdminID=admin or a different value if you used something other than "admin"
already tried that earlier without success
Which information files might it be referring to? I'm looking at /usr/share/dirsrv/inf/admin.inf. I don't see any entry for ServerAdminID there, so I thought maybe it's looking at /etc/dirsrv/admin-serv/adm.conf. There's no entry for ServerAdminID there either, but the script still fails if I add it.
It is getting the values for ServerAdminID and ServerAdminPwd from the file /etc/dirsrv/admin-serv/admpw - if this file does not exist, you can create it like this: echo admin:`pwdhash -s SHA "yourpassword"` > /etc/dirsrv/admin-serv/admpw
It is there and I executed that command and it matches my file perfectly. The permissions on the file are dirsrv:root 600.
try running setup-ds-admin.pl -u
That runs successfully and doesn't seem to change the adm.conf file from before. Then when I try to run the register-ds-admin.pl script again, it fails with the same error.
(In reply to comment #13) > That runs successfully and doesn't seem to change the adm.conf file from > before. Then when I try to run the register-ds-admin.pl script again, it fails > with the same error. If setup-ds-admin.pl -u runs successfully, are you able to use the console? If so, you should not also run register-ds-admin.pl
Yes, I can use the console, but not to administer the ipa ds server. When I run register-ds-admin.pl, the admin portion runs successfully such that I can administer the admin-ds server. However, you are supposed to be able to add other ds's to administer. I'm trying to add an ipa ds so that I can administer it (the non-ipa portions only of course) from the admin server. When I attempt to register it using register-ds-admin.pl, that part of the script fails. So it will never show up in the console as a ds that can be administered.
(In reply to comment #15) > Yes, I can use the console, but not to administer the ipa ds server. When I run > register-ds-admin.pl, the admin portion runs successfully such that I can > administer the admin-ds server. However, you are supposed to be able to add > other ds's to administer. I'm trying to add an ipa ds so that I can administer > it (the non-ipa portions only of course) from the admin server. When I attempt > to register it using register-ds-admin.pl, that part of the script fails. So it > will never show up in the console as a ds that can be administered. setup-ds-admin.pl -u has some fixup logic that tries to repair the entries. But I guess register-ds-admin.pl doesn't even get that far. I'm not really sure what the problem is. I would probably do perl -d /usr/sbin/register-ds-admin.pl and step through it in the debugger - painful (especially since the perl debugger has no readline, completion, etc.)
Here is the relevant debugging information: DB<1> Registering Sub DSes: main::(/usr/sbin/register-ds-admin.pl:449): 449: $subid =~ s/slapd-//; main::(/usr/sbin/register-ds-admin.pl:450): 450: my $passwd = 451: reg_get_passwd($setup, 'input_rootdn_passwd_sub', $subid, $subid); ============================================================================== If you want to register the server 4TEST-NET, input the Directory Manager password on the server. If you don't, type return. [Directory Manager password on 4TEST-NET or return]: main::(/usr/sbin/register-ds-admin.pl:453): 453: next if ( "" eq $passwd || !$passwd ); main::(/usr/sbin/register-ds-admin.pl:454): 454: my $subinf = createInfFromConfig("$subconfdir/$subinst", $subinst); main::(/usr/sbin/register-ds-admin.pl:455): 455: if ( ! $subinf ) 456: { main::(/usr/sbin/register-ds-admin.pl:464): 464: my $force_pta = 0; main::(/usr/sbin/register-ds-admin.pl:465): 465: if ( $orig_confdsid ne $new_confdsid ) { main::(/usr/sbin/register-ds-admin.pl:469): 469: $setup->{inf}->{slapd} = $subinf->{slapd}; main::(/usr/sbin/register-ds-admin.pl:470): 470: $setup->{inf}->{slapd}->{RootDNPwd} = $passwd; main::(/usr/sbin/register-ds-admin.pl:471): 471: push @{$subinstances{$subconfdir}}, $subinst; main::(/usr/sbin/register-ds-admin.pl:471): 471: push @{$subinstances{$subconfdir}}, $subinst; main::(/usr/sbin/register-ds-admin.pl:472): 472: $done = 0; main::(/usr/sbin/register-ds-admin.pl:473): 473: while ( !$done && !createSubDS($setup->{inf}, \@errs, $force_pta) ) 474: { main::(/usr/sbin/register-ds-admin.pl:490): 490: @errs = (); main::(/usr/sbin/register-ds-admin.pl:491): 491: if (!addConfigACIsToSubDS($setup->{inf}, \@errs)) { main::(/usr/sbin/register-ds-admin.pl:500): 500: my @subkeys = keys %subinstances; main::(/usr/sbin/register-ds-admin.pl:501): 501: if ( $#subkeys >= 0 ) 502: { main::(/usr/sbin/register-ds-admin.pl:503): 503: @errs = (); main::(/usr/sbin/register-ds-admin.pl:504): 504: if ( !registerScatteredDSWithConfigDS($setup->{inf}, \@errs, \%subinstances) ) 505: { main::(/usr/sbin/register-ds-admin.pl:506): 506: $setup->msg($FATAL, @errs); The map value 'ServerAdminID' for key 'as_uid' did not map to a value in any of the given information files. main::(/usr/sbin/register-ds-admin.pl:507): 507: $setup->doExit(1); %subinstances: slapd-4TEST-NET This debugging information leads me to believe that the ACLs where not added, yet they were. Perhaps I should delete them and make sure they can be re-created.
The error is coming from DSUtil.pm line 762 in process_maptbl. Almost all of the ldap operations to add/modify entries to register servers are in ldif template files. The ldif template files are just regular ldif except there are replaceable tokens in the files e.g. uid=%as_uid%. The function process_maptbl takes a "map table" file containing a list of tokens along with the source of the value to replace that token e.g. as_uid = ServerAdminID process_maptbl also takes a list of Inf objects (think conf.inf format) which supply the values. The code is supposed to loop through all of the Inf objects and all of the sections looking for the key value. In this case, it is looking for a key value named "ServerAdminID". The error is saying that it looked through all of the Inf objects and all of the sections and could not find a key named "ServerAdminID". But afaict it should be there. In fact, the code in registerDSWithConfigDSExt does this: # need to get the admin uid if (!$inf->{admin}->{ServerAdminID}) { my @rdns = ldap_explode_dn($inf->{General}->{ConfigDirectoryAdminID}, 1); $inf->{admin}->{ServerAdminID} = $rdns[0]; } so I have no idea what is going on. I suppose you could step into registerScatteredDSWithConfigDS which will eventually call registerDSWithConfigDSExt and see what is happening to ServerAdminID.
Well, I just traced this through step-by-step and I'm really not sure why it's not working either. The last things that happen are: 1. Inf.pm is used to collect key/values from dirserver.map 2. DSUtil.pm extracts this info (DSUtil::process_maptbl) The error occurs in DSUtil.pm before it even hands off to AdminUtil::registerDSWithConfigDSExt or registerDSWithConfigDSExt. As you previously mention, ServerAdminID is clearly in dirserver.map so I'm really confused. I'm surprised others are not running into this problem as I believe it should occur for any DS added, not just IPA.
Very strange. register-ds-admin.pl is seldom used - most people either use setup-ds-admin.pl to create new instances and register them with the console, or just use ipa and use the command line utilities.
Upstream ticket: https://fedorahosted.org/389/ticket/56
Builds tested: 389-ds-base-1.3.3.1-16.el7_1.x86_64 389-admin-1.1.40-1.el7dsrv.x86_64 # register-ds-admin.pl <snip> ============================================================================== Beginning Admin Server reconfiguration . . . Creating Admin Server files and directories . . . Updating adm.conf . . . Updating admpw . . . Registering admin server with the configuration directory server . . . Updating adm.conf with information from configuration directory server . . . Updating the configuration for the httpd engine . . . Restarting admin server . . . The admin server was successfully started. Admin server was successfully reconfigured and started. <snip> Marking as VERIFIED.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2015:1094