Bug 661116 - 389-console Configuration tab admin permissions (nsslapd-referral ?) and folder not expending immediatly
Summary: 389-console Configuration tab admin permissions (nsslapd-referral ?) and fold...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: 389
Classification: Retired
Component: Directory Console
Version: 1.2.7
Hardware: Unspecified
OS: Unspecified
high
medium
Target Milestone: ---
Assignee: Rich Megginson
QA Contact: Viktor Ashirov
URL:
Whiteboard:
Depends On:
Blocks: 434915 389_1.3.0
TreeView+ depends on / blocked
 
Reported: 2010-12-07 20:04 UTC by Marc Sauton
Modified: 2015-12-07 16:31 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-12-07 16:31:35 UTC
Embargoed:


Attachments (Terms of Use)
java console exception right after providing admin credentials a second time (4.57 KB, application/octet-stream)
2010-12-07 20:06 UTC, Marc Sauton
no flags Details
java console exception right after providing admin credentials a second time (4.57 KB, text/plain)
2010-12-07 20:08 UTC, Marc Sauton
no flags Details
389-ds-console: git patch file (master) (1.74 KB, patch)
2011-02-05 02:05 UTC, Noriko Hosoi
nhosoi: review?
rmeggins: review+
Details | Diff

Description Marc Sauton 2010-12-07 20:04:43 UTC
Description of problem:

Testing 389-ds-base-1.2.7.2-1.el5 from epel-testing
along with
389-console-1.1.4-1.el5

when using the 389-console, only in the Configuration tab, there are multiple issues that seem to be a new behavior:
- admin permissions refused on first try, but accepted on second attempt
- folders not expending immediatly in left frame, but show content if clicked a second time


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

Red Hat Enterprise Linux Server release 5.4 (Tikanga)
Linux ca1.example.com 2.6.18-164.el5 #1 SMP Tue Aug 18 15:51:48 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux

java-1.6.0-openjdk-1.6.0.0-1.16.b17.el5
389-ds-base-1.2.7.2-1.el5 from epel-testing
389-console-1.1.4-1.el5


How reproducible:
always


Steps to Reproduce:

1. Have el5, epel-testing repo, openjdk-1.6.0

2. install 389-ds
yum --disablerepo=rhel-x86_64-server-5 --disablerepo=rhel-x86_64-server-5-rhcmsys-8 --disablerepo=rhel-x86_64-server-5-rhdirserv-8 --enablerepo=epel --enablerepo=epel-testing install 389-ds

3. start console
/usr/bin/389-console -x nologo -u admin -w password -a http://10.14.5.25:8888/

4. Try click on Configuration tab
see popup error window with title
"Insufficient Permissions"
and error in admin server log
"configuration error:  couldn't check access.  No groups file?: /Tasks/Operation/Restart"

5. click OK in popup error window

6. provide with password credential in new popup window for "Log in to Directory"
in my case, for:
uid=admin,ou=Administrators,ou=TopologyManagement,o=NetscapeRoot
and click OK
then works as expected

7. but gets a Java exception:
Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException
        at com.netscape.admin.dirserv.panel.ServerSettingsPanel$ReferralText.show(Unknown Source)
...
see other attachment in this report

8. Then, you can no longer like in the past expend the folders with one lick in the left frame, have to click a second time on the folder icon to expand it and see the contents.


Actual results:

for step 4:
in
/var/log/dirsrv/admin-serv/error
[Tue Dec 07 11:46:29 2010] [crit] [client 10.14.5.25] configuration error:  couldn't check access.  No groups file?: /Tasks/Operation/Restart

and a Java exception, see attachments


Expected results:
working like before / previous versions


Additional info:

Rich M. indicated on #389 this could be related to nsslapd-referral attribute in cn=config

Comment 1 Marc Sauton 2010-12-07 20:06:59 UTC
Created attachment 467295 [details]
java console exception right after providing admin credentials a second time

Comment 2 Marc Sauton 2010-12-07 20:08:19 UTC
Created attachment 467297 [details]
java console exception right after providing admin credentials a second time

Comment 3 Marc Sauton 2010-12-07 20:12:58 UTC
extra note
this behavior was also reported today on #389 on different versions

(10:20:13 AM) Moe__: 389-ds-base version 1.2.7.1
(10:20:22 AM) Moe__: release 1.fc13
(10:20:43 AM) Moe__: 389-admin version 1.1.13
(10:20:50 AM) Moe__: release 1.fc13
...
(11:16:36 AM) Moe__: are you able to drill into your server group
(11:16:43 AM) Moe__: open the direcroty server.....
(11:17:17 AM) Moe__: click the configuration tab
(11:17:25 AM) Moe__: I get an error at that step
(11:17:52 AM) Moe__: it says that the user cn=directory manager does nto have permission to perform this operartion
(11:18:40 AM) Moe__: Insufficient Permissions
(11:18:49 AM) Moe__: that wierd on a vanilla install
(11:24:06 AM) richm: Moe__: you logged into the console as directory manager?
(11:25:45 AM) Moe__: yes
(11:25:50 AM) Moe__: I also tried admin
(11:26:25 AM) richm: ok - with cn=directory manager I get your error
(11:26:28 AM) Moe__: lete me login but I get those errors
(11:26:43 AM) Moe__: how about with admin?
(11:27:25 AM) richm: yep - admin too
(11:27:46 AM) Moe__: how did you avoid the error?

Comment 4 Marc Sauton 2010-12-22 01:14:21 UTC
similar report in
https://bugzilla.redhat.com/show_bug.cgi?id=627906

similar finding in 389-users:
Date: Tue, 21 Dec 2010 16:50:31 -0500
Subject: [389-users] issues with 1.2.7.5

Comment 5 Robert Viduya 2010-12-22 20:42:44 UTC
I see similar issues.  We're running RHEL5 and have the following packages installed:

389-admin.x86_64                    1.1.13-1.el5            installed           
389-admin-console.noarch            1.1.5-1.el5             installed           
389-admin-console-doc.noarch        1.1.5-1.el5             installed           
389-adminutil.x86_64                1.1.8-4.el5             installed           
389-console.noarch                  1.1.4-1.el5             installed           
389-ds.noarch                       1.2.1-1.el5             installed           
389-ds-base.x86_64                  1.2.7.5-1.el5           installed           
389-ds-base-devel.x86_64            1.2.7.5-1.el5           installed           
389-ds-console.noarch               1.2.3-1.el5             installed           
389-ds-console-doc.noarch           1.2.3-1.el5             installed           
389-dsgw.x86_64                     1.1.5-1.el5             installed           
idm-console-framework.noarch        1.1.5-4.el5             installed

However, we don't see any errors in the admin-serv/error file.

Also, re-entering the credentials the second time does _not_ fix it for us.  I'm trying to turn on SSL and the server configuration page where that's done is completely blank.  However, if I hit "Cancel" instead of typing the password into the second prompt for authorization, I can then see what's there, but cannot make changes (which is expected).

Comment 7 Noriko Hosoi 2011-02-05 02:05:52 UTC
Created attachment 477155 [details]
389-ds-console: git patch file (master)

Description: ds-console always expects nsslapd-referral in
cn=console, which is not true.
This patch appends the empty attribute value if the search
result does not contain expected attributes.

Note by Rich: it is quite annoying.  But it also doesn't do anything - that is, you can just ignore the error and do whatever you need to do - everything still works.

Comment 8 Noriko Hosoi 2011-02-07 17:46:36 UTC
Reviewed by Rich (Thanks!!)

Pushed to master.

$ git merge work
Updating 77b69ba..d77ff59
Fast-forward
 .../netscape/admin/dirserv/panel/DSEntrySet.java   |    7 ++++++-
 1 files changed, 6 insertions(+), 1 deletions(-)

$ git push
Counting objects: 17, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (6/6), done.
Writing objects: 100% (9/9), 994 bytes, done.
Total 9 (delta 4), reused 0 (delta 0)
To ssh://git.fedorahosted.org/git/389/ds-console.git
   77b69ba..d77ff59  master -> master

Comment 9 Amita Sharma 2011-05-11 12:31:16 UTC
I am working on the 389-console since last few days and I have not faced any such issue. Even I use the same Configuration tab to setup the winsync and MMR, But never come across with such an issue.
Hence, for now marking this bug as VERIFIED.


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