Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 431385

Summary: Server discovery stopped working in Management console.
Product: [Retired] 389 Reporter: Alan Madill <amadill>
Component: Directory ConsoleAssignee: Rich Megginson <rmeggins>
Status: CLOSED NOTABUG QA Contact: Chandrasekar Kannan <ckannan>
Severity: low Docs Contact:
Priority: low    
Version: 1.1.0CC: benl
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: All   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-12-20 00:30:48 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Screenshot
none
Console logs from -D 9 -f console.log none

Description Alan Madill 2008-02-04 00:36:59 UTC 
Description of problem:
Server discovery stopped working in Management console.
Console opens in both Windows and Linux versions.  The list of servers and 
applications is blank.  Can still add and manipulate users and groups

Version-Release number of selected component (if applicable):


How reproducible:
Happens only with one directory server.  Others behave normally.

Steps to Reproduce:
1. Open console.
2.
3.
  
Actual results:
No list of servers

Expected results:


Additional info:
Checked logs - no errors
Comment 1 Alan Madill 2008-02-04 00:36:59 UTC 
Created attachment 293847 [details]
Screenshot
Comment 2 Alan Madill 2008-02-04 01:14:11 UTC 
I find that I can log in as cn=Directory Manager see thread...
http://www.redhat.com/archives/fedora-directory-users/2007-
February/msg00005.html
Comment 3 Rich Megginson 2008-02-04 15:11:30 UTC 
So it works if you login as cn=Directory Manager, but not as admin?

Can you run the console in the failure mode with -D 9 -f console.log then attach
the file console.log to this bug?  Thanks.
Comment 4 Alan Madill 2008-02-05 16:57:42 UTC 
Created attachment 294019 [details]
Console logs from -D 9 -f console.log
Comment 5 Alan Madill 2008-02-05 17:06:56 UTC 
Looking back on the sequence of events I created a new administrative user, 
logged in as that entity, logged off and back on again as admin, and I think it 
was at that point that the server list disappeared.  Attached are two console 
logs, one as admin and the other as Directory manager.
I see in a ldif export that the console user settings are stored in the 
directory itself with a new one created with each login.  Would those help?
Comment 6 Rich Megginson 2008-02-28 04:14:00 UTC 
What happens if you restart the Admin Server?
Comment 7 Rich Megginson 2008-07-08 21:19:05 UTC 
(In reply to comment #5)
> Looking back on the sequence of events I created a new administrative user, 
> logged in as that entity, logged off and back on again as admin, and I think it 
> was at that point that the server list disappeared.  Attached are two console 
> logs, one as admin and the other as Directory manager.
> I see in a ldif export that the console user settings are stored in the 
> directory itself with a new one created with each login.  Would those help?

What do you mean by "created a new administrative user"?
Comment 8 Alan Madill 2008-07-09 00:27:24 UTC 
Under ou=administrators,ou=topologymanagement,o=netscaperoot I created a new 
user and then logged in as that identity.
Comment 9 Rich Megginson 2008-07-09 02:17:20 UTC 
(In reply to comment #8)
> Under ou=administrators,ou=topologymanagement,o=netscaperoot I created a new 
> user and then logged in as that identity.

I think there is more that needs to happen.  There are several ACIs that need to
be set to allow that new user to have certain types of access.  There are
certain groups that user needs to be added to.  One quick&dirty way to see would
be to search for everything under o=NetscapeRoot and grep for uid=admin.
Comment 10 Rich Megginson 2008-12-20 00:30:48 UTC 
I'm going to close this bug as not a bug.  I think the real solution to this particular problem would be to have a GUI or a least a written procedure that allows you to create another admin user.