Bug 215885

Summary: Users and Groups Tab default binding for Fedora Console Bug?
Product: [Community] 389 Reporter: Ashley Chew <ashley>
Component: Directory ConsoleAssignee: Rich Megginson <rmeggins>
Status: CLOSED CURRENTRELEASE QA Contact: Viktor Ashirov <vashirov>
Severity: medium Docs Contact:
Priority: medium    
Version: 1.0.4   
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-12-07 12:01:59 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On:    
Bug Blocks: 152373, 240316, 427409    

Description Ashley Chew 2006-11-16 01:03:50 EST
Description of problem:

There seems to be a bug relating to Fedora Console relating to the Users and 
Groups search Tab when your first run the console

Previously in 1.01 or 1.02 whne you click the Users and Groups tab and did a 
search, you click on Advanced Tab. It tells you you are searching ldap://
hostname:389/dc=www,dc=xxx,dc=yyy,dc=zzz where dc=www,dc=xxx,dc=yyy,dc=zzz
is which you specified in the setup script.

Now with Fedora Directory Server 1.04, if you click Advanced tab in Users and 
groups you can see that its bound to ldap://hostname:389/o=NetscapeRoot and
not the the one defined in the setup script. So when you do a search for users, 
groups you be unable to find any.

Is there a way to change the lookup ldap://hostname:389/o=NetscapeRoot to 
ldap://hostname:389/dc=www,dc=xxx,dc=yyy,dc=zzz where dc=www,dc=xxx,dc=yyy,
dc=zzz. 

I had a look I thought it was handled by the mappings in the config
mapping tree where it has these values
"dc=www,dc=xxx,dc=yyy,dc=zzz"
"o=NetscapeRoot"

Version-Release number of selected component (if applicable):
Seems applicable to Fedora Management Console in Fedora Directory Server 1.04, I 
know it dosn't happen for 1.02 nor 1.01. I can't say much for 1.03 because I 
havn't used it.

How reproducible:
Should be reproducible after a fresh install of Fedora Directory Server 4 after 
the setup script. Run the Fedora Directory Console


Steps to Reproduce:
1. Install FC4 installation
2. Install IBM JDK 1.4.2 (rpm -ivh IBMJava2-142-ia32-SDK-1.4.2-3.0.i386.rpm)
3. Export Java variables to shell ie export JAVA_HOME=/opt/IBMJava2-142, export
PATH=/opt/IBMJava2-142/bin:$PATH
4. Install the RPM for the appropriate distribution (rpm -ivh fedora-ds-1.0.4-1.
FC4.i386.opt.rpm)
5. Run the setup for (/opt/fedora-ds/setup/setup) and setup using the defaults
6. Run the Fedora Management Console
7. Run the Directory Server, create a user or group on your dc=www,dc=xxx,
dc=yyy,dc=zzz
8. Go back to Directory Console, and click Users and Groups tab, do a search for 
your user and group. Dosn't find it
9. Click on the advanced tab. You can see its bounded to the o=NetscapeRoot and 
not dc=www,dc=xxx,dc=yyy,dc=zzz like previously.

Actual results:
the Directory Server Console, the Users amd Groups is bounded to ldap://
hostname:389/o=NetscapeRoot

Expected results:
the Directory Server Console, the Users amd Groups should be bounded to ldap://
hostname:389/dc=www,dc=xxx,dc=yyy,dc=zzz

Additional info:
Its not a big deal as you can do a search on the Fedora Directory Server but was 
wondering why it suddenly changed and if there was a quick way to rebind the 
fedora console User and Group Tab.
Comment 1 Rich Megginson 2006-11-16 17:25:04 EST
On the Users and Groups tab, go to the User menu -> Change Directory...  The
dialog box will allow you to change the base suffix.

And thank you for the very detailed bug report.
Comment 2 Nate Bradley 2007-04-04 13:35:31 EDT
Is there a way to change this 'default' binding behavior, or shall I wait for it
to be 'fixed' in another release
Comment 3 Rich Megginson 2007-04-04 14:55:53 EDT
(In reply to comment #2)
> Is there a way to change this 'default' binding behavior, or shall I wait for it
> to be 'fixed' in another release

It sounds like a bug, and the workaround is easy, so I suppose it will be fixed
in an upcoming release.