389-ds-base

#47708 Undefined resource: mappingtree-error-add-mapping-msg when setting up sub-suffix on 1.2.11.15-31 (CentOS 6.5) via 389-console
Closed: wontfix Opened by epepepep.

Closed: wontfix
Reopen Issue 
I recently setup two new 389-ds servers in a multi-master replicated

pair. I am only replicating the userRoot database at this time.

Everything is working well, SSL is setup, replication is working on

both nodes.

I'm using CentOS 6.5 with the EPEL packages, everything is up to date.
I would like this new multi-master pair to start being a read-only

consumer for a few other ldap servers in our environment. Here is the
tree breakdown.

dc=ias,dc=edu (multi-master pair)
dc=math,dc=ias,dc=edu (separate ldap server)
dc=sns,dc=ias,dc=edu (separate ldap server)
dc=itg,dc=ias,dc=edu (separate ldap server)
dc=net,dc=ias,dc=edu (separate ldap server)

If I'm reading things correctly, I need to have a separate database

for each of the sub domains in order to setup a new replication agreement.

So, I load up the Directory Server Console, navigate to Configuration->Data

and right click on the suffix dc=ias,dc=edu. I select "New
Sub Suffix" and fill it out. For example, I'll put in "dc=math" for
the New Suffix, and create an associate database automatically and
name it "math".

One thing to note, the suffix dc=ias,dc=edu displays as

"dc\3Dias\2Cdc\3Dedu". I'm guessing that the hex encoding isn't a big
deal, but just in case....

When I click "OK", I'm greeted with the following error.

Undefined resource: mappingtree-error-add-mapping-msg.
The suffix could not be created. 

I must be missing something, although my Google-fu has been lacking

on finding the answer. Am I headed down the right path for what I
want to do?

Thanks for your help,
Brian

I could not reproduce the problem on my test machines (sorry, I'm running Fedora)
389-console-1.1.7-3.fc18.noarch
389-ds-console-1.2.7-2.fc18.noarch
idm-console-framework-1.1.7-5.fc18.noarch

389-console-1.1.7-4.fc19.noarch
389-ds-console-1.2.7-2.fc19.noarch
idm-console-framework-1.1.7-6.fc19.noarch

What are your console and admin server versions?

Hello, epepepep.

Could you provide us the version info as I asked 2 weeks ago?
So far, we have no luck to reproduce your problem.

Also, we have released 389-ds-base-1.2.11.28 for epel6.
http://directory.fedoraproject.org/wiki/Releases/1.2.11.28
We recommend to upgrade to the version.

Thanks.

I'm using 389-ds-base-1.2.11.15-31.el6_5.x86_64. I believe I have found the issue. I had set up TLS for the admin and slapd servers, but something wasn't set up incorrectly. Parts of the UI were hanging at various times.

A deeper inspection showed that some communication was using TLS, and some was not. Obviously the communication that was not was just failing after a while.

So, I started over again following the procedure of:

  1. Fresh install, no TLS.
  2. copying my *.db files in the admin-serv and slapd directory
  3. Configuring Encryption for the admin server first in the GUI
  4. Configuring Encryption for the slapd server in the GUI

This solved my other issues, and it seems to have solved this issue as well. Some of the guides I was using had me manually editing console.conf and dse.ldif and nss.conf. I believe that they were missing some critical component that was breaking things.

Thanks, and sorry I missed your email two weeks ago.
ep

Thanks for getting back to us! I'm glad to hear it was simply a configuration issue. I'll go ahead and close this ticket.

Metadata Update from @epepepep:
- Issue set to the milestone: N/A

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/389ds/389-ds-base/issues/1043

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Metadata Update from @spichugi:
- Issue close_status updated to: wontfix (was: Invalid)
Metadata
None
None
None
None
Normal
None
Community
None
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.