10:23 a.m.
When viewing replication agreements in the 389-console (under the Configuration
tab, Replication, userRoot), the first time I select each replication agreement,
I am greeted by an error window titled "Insufficient Permissions" stating
"The
user cn=root does not have the permission to perform this operation."
cn=root is my directory manager account. I am not trying to make any changes, I
get this error simply by selecting the agreement so I can view it and check the
status. I can click OK to acknowledge the error and then I am prompted to login
again. I can hit cancel and continue navigating, but if I attempt to make any
change in this area, the "Save" button does not activate to let me do so. I
can
use the Directory tab and navigate down through cn=config tree and change the
agreement entries via the normal property editor window. I can also delete the
agreement from the Configuration tab.
I'm using 389-console 1.1.7-0ubuntu1 on Kubuntu 12.04, but I have colleagues who
run the 389-console from the server (389-console-1.1.7-3.el5.noarch) and see the
same error.
These are the packages on the server, which is CentOS 5.7:
# rpm -qa 389-\*
389-admin-1.1.29-1.el5.x86_64
389-console-1.1.7-3.el5.noarch
389-ds-base-libs-1.2.10.4-5.el5.x86_64
389-admin-console-1.1.8-1.el5.noarch
389-ds-base-devel-1.2.10.4-5.el5.x86_64
389-ds-base-1.2.10.4-5.el5.x86_64
389-ds-console-1.2.6-1.el5.noarch
389-ds-console-doc-1.2.6-1.el5.noarch
389-adminutil-1.1.15-1.el5.x86_64
389-admin-console-doc-1.1.8-1.el5.noarch
389-adminutil-devel-1.1.15-1.el5.x86_64
While troubleshooting replication a while back, I lost all my replication
agreements and recreated them all from the CLI using some instructions I found
for RHDS. I don't recall if this error occurred before that or not. If I
delete and re-create the agreement through the GUI, I do not get this error when
selecting that same agreement, even after restarting the GUI.
--
/* Wes Hardin */
UNIX/Linux Systems Administrator, IT Engineering Support
Office: +1 (972) 371-6909 | Mobile: +1 (972) 342-5679
Maxim Integrated Products | Innovation Delivered® | www.maxim-ic.com
11:19 a.m.
On 08/28/2012 10:23 AM, Wes Hardin wrote:
When viewing replication agreements in the 389-console (under the
Configuration
tab, Replication, userRoot), the first time I select each replication agreement,
I am greeted by an error window titled "Insufficient Permissions" stating
"The
user cn=root does not have the permission to perform this operation."
I found I am able to get rid of this error popup by populating the
"Description"
field for each replication agreement. I am able to set and save the description
under the "Configuration" tab, but I still cannot modify the schedule or
connection details here.
--
/* Wes Hardin */
UNIX/Linux Systems Administrator, IT Engineering Support
Maxim Integrated Products | Innovation Delivered® | www.maxim-ic.com
11:21 a.m.
On 08/28/2012 10:19 AM, Wes Hardin wrote:
On 08/28/2012 10:23 AM, Wes Hardin wrote:
> When viewing replication agreements in the 389-console (under the Configuration
> tab, Replication, userRoot), the first time I select each replication agreement,
> I am greeted by an error window titled "Insufficient Permissions" stating
"The
> user cn=root does not have the permission to perform this operation."
I found I am able to get rid of this error popup by populating the
"Description"
field for each replication agreement. I am able to set and save the description
under the "Configuration" tab, but I still cannot modify the schedule or
connection details here.
What is your platform? What version of 389-ds-base, 389-admin, and
389-ds-console? Are you logging into the console as "admin" or as
"cn=directory manager"? Do you have any trouble editing any other
fields in any other config tabs, or is this problem strictly limited to
editing replication agreements? Have you filed a ticket at
https://fedorahosted.org/389?
11:33 a.m.
On 08/28/2012 11:21 AM, Rich Megginson wrote:
On 08/28/2012 10:19 AM, Wes Hardin wrote:
> On 08/28/2012 10:23 AM, Wes Hardin wrote:
>> When viewing replication agreements in the 389-console (under the Configuration
>> tab, Replication, userRoot), the first time I select each replication agreement,
>> I am greeted by an error window titled "Insufficient Permissions"
stating "The
>> user cn=root does not have the permission to perform this operation."
> I found I am able to get rid of this error popup by populating the
"Description"
> field for each replication agreement. I am able to set and save the description
> under the "Configuration" tab, but I still cannot modify the schedule or
> connection details here.
>
What is your platform? What version of 389-ds-base, 389-admin, and
389-ds-console? Are you logging into the console as "admin" or as
"cn=directory manager"? Do you have any trouble editing any other
fields in any other config tabs, or is this problem strictly limited to
editing replication agreements? Have you filed a ticket at
https://fedorahosted.org/389?
cn=root is my directory manager account.
I'm using 389-console 1.1.7-0ubuntu1 on Kubuntu 12.04, but I have colleagues who
run the 389-console from the server (389-console-1.1.7-3.el5.noarch) and see the
same error.
These are the packages on the server, which is CentOS 5.7:
# rpm -qa 389-\*
389-admin-1.1.29-1.el5.x86_64
389-console-1.1.7-3.el5.noarch
389-ds-base-libs-1.2.10.4-5.el5.x86_64
389-admin-console-1.1.8-1.el5.noarch
389-ds-base-devel-1.2.10.4-5.el5.x86_64
389-ds-base-1.2.10.4-5.el5.x86_64
389-ds-console-1.2.6-1.el5.noarch
389-ds-console-doc-1.2.6-1.el5.noarch
389-adminutil-1.1.15-1.el5.x86_64
389-admin-console-doc-1.1.8-1.el5.noarch
389-adminutil-devel-1.1.15-1.el5.x86_64
I use the Apache Directory Studio for most of my general directory data
management. I typically only use the 389-console for 389-specific configuration
changes. The only other time I notice getting this message is when I first
click on the "Configuration" tab. I am still able to change values and click
save them though. I tested this by changing the max number of entries returned.
--
/* Wes Hardin */
UNIX/Linux Systems Administrator, IT Engineering Support
Maxim Integrated Products | Innovation Delivered® | www.maxim-ic.com
12:16 p.m.
On 08/28/2012 09:23 AM, Wes Hardin wrote:
When viewing replication agreements in the 389-console (under the
Configuration
tab, Replication, userRoot), the first time I select each replication agreement,
I am greeted by an error window titled "Insufficient Permissions" stating
"The
user cn=root does not have the permission to perform this operation."
That should have been fixed, although I can't seem to find the ticket.
cn=root is my directory manager account. I am not trying to make any changes, I
get this error simply by selecting the agreement so I can view it and check the
status. I can click OK to acknowledge the error and then I am prompted to login
again. I can hit cancel and continue navigating, but if I attempt to make any
change in this area, the "Save" button does not activate to let me do so. I
can
use the Directory tab and navigate down through cn=config tree and change the
agreement entries via the normal property editor window. I can also delete the
agreement from the Configuration tab.
I'm using 389-console 1.1.7-0ubuntu1 on Kubuntu 12.04, but I have colleagues who
run the 389-console from the server (389-console-1.1.7-3.el5.noarch) and see the
same error.
These are the packages on the server, which is CentOS 5.7:
# rpm -qa 389-\*
389-admin-1.1.29-1.el5.x86_64
389-console-1.1.7-3.el5.noarch
389-ds-base-libs-1.2.10.4-5.el5.x86_64
389-admin-console-1.1.8-1.el5.noarch
389-ds-base-devel-1.2.10.4-5.el5.x86_64
389-ds-base-1.2.10.4-5.el5.x86_64
389-ds-console-1.2.6-1.el5.noarch
389-ds-console-doc-1.2.6-1.el5.noarch
389-adminutil-1.1.15-1.el5.x86_64
389-admin-console-doc-1.1.8-1.el5.noarch
389-adminutil-devel-1.1.15-1.el5.x86_64
While troubleshooting replication a while back, I lost all my replication
agreements and recreated them all from the CLI using some instructions I found
for RHDS. I don't recall if this error occurred before that or not. If I
delete and re-create the agreement through the GUI, I do not get this error when
selecting that same agreement, even after restarting the GUI.
So if you create the
agreements via the CLI, the console gives an error
when you try to edit the agreements, but when you create the agreements
via the console, the console will allow you to edit the agreements?
3:35 p.m.
On 08/28/2012 12:16 PM, Rich Megginson wrote:
On 08/28/2012 09:23 AM, Wes Hardin wrote:
> When viewing replication agreements in the 389-console (under the Configuration
> tab, Replication, userRoot), the first time I select each replication agreement,
> I am greeted by an error window titled "Insufficient Permissions" stating
"The
> user cn=root does not have the permission to perform this operation."
That should have been fixed, although I can't seem to find the ticket.
>
> cn=root is my directory manager account. I am not trying to make any changes, I
> get this error simply by selecting the agreement so I can view it and check the
> status. I can click OK to acknowledge the error and then I am prompted to login
> again. I can hit cancel and continue navigating, but if I attempt to make any
> change in this area, the "Save" button does not activate to let me do so.
I can
> use the Directory tab and navigate down through cn=config tree and change the
> agreement entries via the normal property editor window. I can also delete the
> agreement from the Configuration tab.
>
> I'm using 389-console 1.1.7-0ubuntu1 on Kubuntu 12.04, but I have colleagues who
> run the 389-console from the server (389-console-1.1.7-3.el5.noarch) and see the
> same error.
>
> These are the packages on the server, which is CentOS 5.7:
> # rpm -qa 389-\*
> 389-admin-1.1.29-1.el5.x86_64
> 389-console-1.1.7-3.el5.noarch
> 389-ds-base-libs-1.2.10.4-5.el5.x86_64
> 389-admin-console-1.1.8-1.el5.noarch
> 389-ds-base-devel-1.2.10.4-5.el5.x86_64
> 389-ds-base-1.2.10.4-5.el5.x86_64
> 389-ds-console-1.2.6-1.el5.noarch
> 389-ds-console-doc-1.2.6-1.el5.noarch
> 389-adminutil-1.1.15-1.el5.x86_64
> 389-admin-console-doc-1.1.8-1.el5.noarch
> 389-adminutil-devel-1.1.15-1.el5.x86_64
>
> While troubleshooting replication a while back, I lost all my replication
> agreements and recreated them all from the CLI using some instructions I found
> for RHDS. I don't recall if this error occurred before that or not. If I
> delete and re-create the agreement through the GUI, I do not get this error when
> selecting that same agreement, even after restarting the GUI.
So if you create the agreements via the CLI, the console gives an error
when you try to edit the agreements, but when you create the agreements
via the console, the console will allow you to edit the agreements?
I cannot edit any replication agreements (except for the description field)
regardless of their origin from the "Configuration" tab. I don't receive
any
error, but if I make a change to the schedule for instance, the tab gets the
little red dot indicating a change occurred, but the "Save" button remains
grayed out and unclickable.
--
/* Wes Hardin */
UNIX/Linux Systems Administrator, IT Engineering Support
Maxim Integrated Products | Innovation Delivered® | www.maxim-ic.com
3:43 p.m.
On 08/28/2012 02:35 PM, Wes Hardin wrote:
On 08/28/2012 12:16 PM, Rich Megginson wrote:
> On 08/28/2012 09:23 AM, Wes Hardin wrote:
>> When viewing replication agreements in the 389-console (under the Configuration
>> tab, Replication, userRoot), the first time I select each replication agreement,
>> I am greeted by an error window titled "Insufficient Permissions"
stating "The
>> user cn=root does not have the permission to perform this operation."
> That should have been fixed, although I can't seem to find the ticket.
>
>> cn=root is my directory manager account. I am not trying to make any changes, I
>> get this error simply by selecting the agreement so I can view it and check the
>> status. I can click OK to acknowledge the error and then I am prompted to login
>> again. I can hit cancel and continue navigating, but if I attempt to make any
>> change in this area, the "Save" button does not activate to let me do
so. I can
>> use the Directory tab and navigate down through cn=config tree and change the
>> agreement entries via the normal property editor window. I can also delete the
>> agreement from the Configuration tab.
>>
>> I'm using 389-console 1.1.7-0ubuntu1 on Kubuntu 12.04, but I have colleagues
who
>> run the 389-console from the server (389-console-1.1.7-3.el5.noarch) and see the
>> same error.
>>
>> These are the packages on the server, which is CentOS 5.7:
>> # rpm -qa 389-\*
>> 389-admin-1.1.29-1.el5.x86_64
>> 389-console-1.1.7-3.el5.noarch
>> 389-ds-base-libs-1.2.10.4-5.el5.x86_64
>> 389-admin-console-1.1.8-1.el5.noarch
>> 389-ds-base-devel-1.2.10.4-5.el5.x86_64
>> 389-ds-base-1.2.10.4-5.el5.x86_64
>> 389-ds-console-1.2.6-1.el5.noarch
>> 389-ds-console-doc-1.2.6-1.el5.noarch
>> 389-adminutil-1.1.15-1.el5.x86_64
>> 389-admin-console-doc-1.1.8-1.el5.noarch
>> 389-adminutil-devel-1.1.15-1.el5.x86_64
>>
>> While troubleshooting replication a while back, I lost all my replication
>> agreements and recreated them all from the CLI using some instructions I found
>> for RHDS. I don't recall if this error occurred before that or not. If I
>> delete and re-create the agreement through the GUI, I do not get this error when
>> selecting that same agreement, even after restarting the GUI.
> So if you create the agreements via the CLI, the console gives an error
> when you try to edit the agreements, but when you create the agreements
> via the console, the console will allow you to edit the agreements?
I cannot edit any replication agreements (except for the description field)
regardless of their origin from the "Configuration" tab. I don't receive
any
error, but if I make a change to the schedule for instance, the tab gets the
little red dot indicating a change occurred, but the "Save" button remains
grayed out and unclickable.
Ok. I would like to see
excerpts from the directory server and admin server access log and
errors log from around the time of this console behavior
/var/log/dirsrv/slapd-INSTANCE/errors and access
/var/log/dirsrv/admin-serv/error and access
run the console with 389-console -D 9 -f console.log - then reproduce
the problem and post the console.log
before you post any logs, be sure to scrub or obscure any sensitive data
4:11 p.m.
On 08/28/2012 03:43 PM, Rich Megginson wrote:
On 08/28/2012 02:35 PM, Wes Hardin wrote:
> On 08/28/2012 12:16 PM, Rich Megginson wrote:
>> On 08/28/2012 09:23 AM, Wes Hardin wrote:
>>> When viewing replication agreements in the 389-console (under the
Configuration
>>> tab, Replication, userRoot), the first time I select each replication
agreement,
>>> I am greeted by an error window titled "Insufficient Permissions"
stating "The
>>> user cn=root does not have the permission to perform this operation."
>> That should have been fixed, although I can't seem to find the ticket.
attached console.log
When I ran the 389-console in debug mode, I think I located the where the issue arises.
Starting at line 1778:
DSEntrySet.getAttributes(): failed to get attribute nsslapd-referral in cn=config
ServerSettingsPanel.ReferralText.show: <>
DSEntrySet.show(): some of the attributes of cn=config could not be read. Either they are
not present in the entry or there is an ACI which prevents that attribute from being read.
Try authenticating as a user with more access
In a quick test, this only seems to occur on my single master. The consumers I tested did
not complain when selecting the "configuration" tab.
>>> cn=root is my directory manager account. I am not trying
to make any changes, I
>>> get this error simply by selecting the agreement so I can view it and check
the
>>> status. I can click OK to acknowledge the error and then I am prompted to
login
>>> again. I can hit cancel and continue navigating, but if I attempt to make
any
>>> change in this area, the "Save" button does not activate to let me
do so. I can
>>> use the Directory tab and navigate down through cn=config tree and change
the
>>> agreement entries via the normal property editor window. I can also delete
the
>>> agreement from the Configuration tab.
>>>
>>> I'm using 389-console 1.1.7-0ubuntu1 on Kubuntu 12.04, but I have
colleagues who
>>> run the 389-console from the server (389-console-1.1.7-3.el5.noarch) and see
the
>>> same error.
>>>
>>> These are the packages on the server, which is CentOS 5.7:
>>> # rpm -qa 389-\*
>>> 389-admin-1.1.29-1.el5.x86_64
>>> 389-console-1.1.7-3.el5.noarch
>>> 389-ds-base-libs-1.2.10.4-5.el5.x86_64
>>> 389-admin-console-1.1.8-1.el5.noarch
>>> 389-ds-base-devel-1.2.10.4-5.el5.x86_64
>>> 389-ds-base-1.2.10.4-5.el5.x86_64
>>> 389-ds-console-1.2.6-1.el5.noarch
>>> 389-ds-console-doc-1.2.6-1.el5.noarch
>>> 389-adminutil-1.1.15-1.el5.x86_64
>>> 389-admin-console-doc-1.1.8-1.el5.noarch
>>> 389-adminutil-devel-1.1.15-1.el5.x86_64
>>>
>>> While troubleshooting replication a while back, I lost all my replication
>>> agreements and recreated them all from the CLI using some instructions I
found
>>> for RHDS. I don't recall if this error occurred before that or not. If
I
>>> delete and re-create the agreement through the GUI, I do not get this error
when
>>> selecting that same agreement, even after restarting the GUI.
>> So if you create the agreements via the CLI, the console gives an error
>> when you try to edit the agreements, but when you create the agreements
>> via the console, the console will allow you to edit the agreements?
> I cannot edit any replication agreements (except for the description field)
> regardless of their origin from the "Configuration" tab. I don't
receive any
> error, but if I make a change to the schedule for instance, the tab gets the
> little red dot indicating a change occurred, but the "Save" button remains
> grayed out and unclickable.
>
Ok. I would like to see
excerpts from the directory server and admin server access log and
errors log from around the time of this console behavior
/var/log/dirsrv/slapd-INSTANCE/errors and access
/var/log/dirsrv/admin-serv/error and access
run the console with 389-console -D 9 -f console.log - then reproduce
the problem and post the console.log
before you post any logs, be sure to scrub or obscure any sensitive data
Getting these logs will take a little bit longer. But to make sure I provide useful logs,
what debug logging options should I enable for access and error?
--
/* Wes Hardin */
UNIX/Linux Systems Administrator, IT Engineering Support
Maxim Integrated Products | Innovation Delivered® | www.maxim-ic.com
4:24 p.m.
On 08/29/2012 03:11 PM, Wes Hardin wrote:
On 08/28/2012 03:43 PM, Rich Megginson wrote:
> On 08/28/2012 02:35 PM, Wes Hardin wrote:
>> On 08/28/2012 12:16 PM, Rich Megginson wrote:
>>> On 08/28/2012 09:23 AM, Wes Hardin wrote:
>>>> When viewing replication agreements in the 389-console (under the
Configuration
>>>> tab, Replication, userRoot), the first time I select each replication
agreement,
>>>> I am greeted by an error window titled "Insufficient
Permissions" stating "The
>>>> user cn=root does not have the permission to perform this
operation."
>>> That should have been fixed, although I can't seem to find the ticket.
attached console.log
When I ran the 389-console in debug mode, I think I located the where the issue arises.
Starting at line 1778:
DSEntrySet.getAttributes(): failed to get attribute nsslapd-referral in cn=config
ServerSettingsPanel.ReferralText.show:<>
DSEntrySet.show(): some of the attributes of cn=config could not be read. Either they
are not present in the entry or there is an ACI which prevents that attribute from being
read. Try authenticating as a user with more access
In a quick test, this only seems to occur on my single master. The consumers I tested
did not complain when selecting the "configuration" tab.
Hmm - this should have been fixed - https://fedorahosted.org/389/ticket/78
Please add your information to that ticket and reopen
>>>> cn=root is my directory manager account. I am not trying to make any
changes, I
>>>> get this error simply by selecting the agreement so I can view it and
check the
>>>> status. I can click OK to acknowledge the error and then I am prompted
to login
>>>> again. I can hit cancel and continue navigating, but if I attempt to
make any
>>>> change in this area, the "Save" button does not activate to let
me do so. I can
>>>> use the Directory tab and navigate down through cn=config tree and change
the
>>>> agreement entries via the normal property editor window. I can also
delete the
>>>> agreement from the Configuration tab.
>>>>
>>>> I'm using 389-console 1.1.7-0ubuntu1 on Kubuntu 12.04, but I have
colleagues who
>>>> run the 389-console from the server (389-console-1.1.7-3.el5.noarch) and
see the
>>>> same error.
>>>>
>>>> These are the packages on the server, which is CentOS 5.7:
>>>> # rpm -qa 389-\*
>>>> 389-admin-1.1.29-1.el5.x86_64
>>>> 389-console-1.1.7-3.el5.noarch
>>>> 389-ds-base-libs-1.2.10.4-5.el5.x86_64
>>>> 389-admin-console-1.1.8-1.el5.noarch
>>>> 389-ds-base-devel-1.2.10.4-5.el5.x86_64
>>>> 389-ds-base-1.2.10.4-5.el5.x86_64
>>>> 389-ds-console-1.2.6-1.el5.noarch
>>>> 389-ds-console-doc-1.2.6-1.el5.noarch
>>>> 389-adminutil-1.1.15-1.el5.x86_64
>>>> 389-admin-console-doc-1.1.8-1.el5.noarch
>>>> 389-adminutil-devel-1.1.15-1.el5.x86_64
>>>>
>>>> While troubleshooting replication a while back, I lost all my
replication
>>>> agreements and recreated them all from the CLI using some instructions I
found
>>>> for RHDS. I don't recall if this error occurred before that or not.
If I
>>>> delete and re-create the agreement through the GUI, I do not get this
error when
>>>> selecting that same agreement, even after restarting the GUI.
>>> So if you create the agreements via the CLI, the console gives an error
>>> when you try to edit the agreements, but when you create the agreements
>>> via the console, the console will allow you to edit the agreements?
>> I cannot edit any replication agreements (except for the description field)
>> regardless of their origin from the "Configuration" tab. I don't
receive any
>> error, but if I make a change to the schedule for instance, the tab gets the
>> little red dot indicating a change occurred, but the "Save" button
remains
>> grayed out and unclickable.
>>
> Ok. I would like to see
> excerpts from the directory server and admin server access log and
> errors log from around the time of this console behavior
> /var/log/dirsrv/slapd-INSTANCE/errors and access
> /var/log/dirsrv/admin-serv/error and access
>
> run the console with 389-console -D 9 -f console.log - then reproduce
> the problem and post the console.log
>
> before you post any logs, be sure to scrub or obscure any sensitive data
Getting these logs will take a little bit longer. But to make sure I provide useful
logs, what debug logging options should I enable for access and error?
Don't
worry about it. This looks like ticket 78. I'm very confused as
to why this was not fixed for you. Did you upgrade this 389 from an
earlier release? If so, it is possible that there is an empty
nsslapd-referral attribute in your dse.ldif - try this:
shutdown dirsrv
edit /etc/dirsrv/slapd-INST/dse.ldif - look for a line like
nsslapd-referral:
that is, there is nothing after the ":"
delete this line
then restart dirsrv
11:29 a.m.
On 08/29/2012 04:24 PM, Rich Megginson wrote:
On 08/29/2012 03:11 PM, Wes Hardin wrote:
> On 08/28/2012 03:43 PM, Rich Megginson wrote:
>> On 08/28/2012 02:35 PM, Wes Hardin wrote:
>>> On 08/28/2012 12:16 PM, Rich Megginson wrote:
>>>> On 08/28/2012 09:23 AM, Wes Hardin wrote:
>>>>> When viewing replication agreements in the 389-console (under the
Configuration
>>>>> tab, Replication, userRoot), the first time I select each replication
agreement,
>>>>> I am greeted by an error window titled "Insufficient
Permissions" stating "The
>>>>> user cn=root does not have the permission to perform this
operation."
>>>> That should have been fixed, although I can't seem to find the
ticket.
> attached console.log
>
> When I ran the 389-console in debug mode, I think I located the where the issue
arises. Starting at line 1778:
>
> DSEntrySet.getAttributes(): failed to get attribute nsslapd-referral in cn=config
> ServerSettingsPanel.ReferralText.show:<>
> DSEntrySet.show(): some of the attributes of cn=config could not be read. Either
they are not present in the entry or there is an ACI which prevents that attribute from
being read. Try authenticating as a user with more access
>
> In a quick test, this only seems to occur on my single master. The consumers I
tested did not complain when selecting the "configuration" tab.
Hmm - this should have been fixed - https://fedorahosted.org/389/ticket/78
Please add your information to that ticket and reopen
>
>>>>> cn=root is my directory manager account. I am not trying to make any
changes, I
>>>>> get this error simply by selecting the agreement so I can view it and
check the
>>>>> status. I can click OK to acknowledge the error and then I am
prompted to login
>>>>> again. I can hit cancel and continue navigating, but if I attempt to
make any
>>>>> change in this area, the "Save" button does not activate to
let me do so. I can
>>>>> use the Directory tab and navigate down through cn=config tree and
change the
>>>>> agreement entries via the normal property editor window. I can also
delete the
>>>>> agreement from the Configuration tab.
>>>>>
>>>>> I'm using 389-console 1.1.7-0ubuntu1 on Kubuntu 12.04, but I have
colleagues who
>>>>> run the 389-console from the server (389-console-1.1.7-3.el5.noarch)
and see the
>>>>> same error.
>>>>>
>>>>> These are the packages on the server, which is CentOS 5.7:
>>>>> # rpm -qa 389-\*
>>>>> 389-admin-1.1.29-1.el5.x86_64
>>>>> 389-console-1.1.7-3.el5.noarch
>>>>> 389-ds-base-libs-1.2.10.4-5.el5.x86_64
>>>>> 389-admin-console-1.1.8-1.el5.noarch
>>>>> 389-ds-base-devel-1.2.10.4-5.el5.x86_64
>>>>> 389-ds-base-1.2.10.4-5.el5.x86_64
>>>>> 389-ds-console-1.2.6-1.el5.noarch
>>>>> 389-ds-console-doc-1.2.6-1.el5.noarch
>>>>> 389-adminutil-1.1.15-1.el5.x86_64
>>>>> 389-admin-console-doc-1.1.8-1.el5.noarch
>>>>> 389-adminutil-devel-1.1.15-1.el5.x86_64
>>>>>
>>>>> While troubleshooting replication a while back, I lost all my
replication
>>>>> agreements and recreated them all from the CLI using some
instructions I found
>>>>> for RHDS. I don't recall if this error occurred before that or
not. If I
>>>>> delete and re-create the agreement through the GUI, I do not get this
error when
>>>>> selecting that same agreement, even after restarting the GUI.
>>>> So if you create the agreements via the CLI, the console gives an error
>>>> when you try to edit the agreements, but when you create the agreements
>>>> via the console, the console will allow you to edit the agreements?
>>> I cannot edit any replication agreements (except for the description field)
>>> regardless of their origin from the "Configuration" tab. I
don't receive any
>>> error, but if I make a change to the schedule for instance, the tab gets the
>>> little red dot indicating a change occurred, but the "Save" button
remains
>>> grayed out and unclickable.
>>>
>> Ok. I would like to see
>> excerpts from the directory server and admin server access log and
>> errors log from around the time of this console behavior
>> /var/log/dirsrv/slapd-INSTANCE/errors and access
>> /var/log/dirsrv/admin-serv/error and access
>>
>> run the console with 389-console -D 9 -f console.log - then reproduce
>> the problem and post the console.log
>>
>> before you post any logs, be sure to scrub or obscure any sensitive data
> Getting these logs will take a little bit longer. But to make sure I provide useful
logs, what debug logging options should I enable for access and error?
Don't worry about it. This looks like ticket 78. I'm very confused as
to why this was not fixed for you. Did you upgrade this 389 from an
earlier release? If so, it is possible that there is an empty
nsslapd-referral attribute in your dse.ldif - try this:
shutdown dirsrv
edit /etc/dirsrv/slapd-INST/dse.ldif - look for a line like
nsslapd-referral:
that is, there is nothing after the ":"
delete this line
then restart dirsrv
I don't know the full history of this server since I assumed management of it
from someone else. I believe it began life as 1.2.2 (based on version shown on
the initial screen of 389-console; have not run setup-ds.pl -u due to bug #377),
was upgraded to 1.2.5rc2, then 1.2.10.{4,14}. I believe it also started as a
consumer of a single master and then was promoted to be the new single master
pretty early on.
I reopened the bug as you suggested. A quick grep of dse.ldif shows no instance
of 'nsslapd-referral:'. The only reference to referral I find is this:
# grep -i referral dse.ldif
nsreferralonscopedsearch: off
--
/* Wes Hardin */
UNIX/Linux Systems Administrator, IT Engineering Support
Maxim Integrated Products | Innovation Delivered® | www.maxim-ic.com
1:44 p.m.
On 08/30/2012 10:29 AM, Wes Hardin wrote:
On 08/29/2012 04:24 PM, Rich Megginson wrote:
> On 08/29/2012 03:11 PM, Wes Hardin wrote:
>> On 08/28/2012 03:43 PM, Rich Megginson wrote:
>>> On 08/28/2012 02:35 PM, Wes Hardin wrote:
>>>> On 08/28/2012 12:16 PM, Rich Megginson wrote:
>>>>> On 08/28/2012 09:23 AM, Wes Hardin wrote:
>>>>>> When viewing replication agreements in the 389-console (under the
Configuration
>>>>>> tab, Replication, userRoot), the first time I select each
replication agreement,
>>>>>> I am greeted by an error window titled "Insufficient
Permissions" stating "The
>>>>>> user cn=root does not have the permission to perform this
operation."
>>>>> That should have been fixed, although I can't seem to find the
ticket.
>> attached console.log
>>
>> When I ran the 389-console in debug mode, I think I located the where the issue
arises. Starting at line 1778:
>>
>> DSEntrySet.getAttributes(): failed to get attribute nsslapd-referral in
cn=config
>> ServerSettingsPanel.ReferralText.show:<>
>> DSEntrySet.show(): some of the attributes of cn=config could not be read. Either
they are not present in the entry or there is an ACI which prevents that attribute from
being read. Try authenticating as a user with more access
>>
>> In a quick test, this only seems to occur on my single master. The consumers I
tested did not complain when selecting the "configuration" tab.
> Hmm - this should have been fixed - https://fedorahosted.org/389/ticket/78
> Please add your information to that ticket and reopen
>
>>>>>> cn=root is my directory manager account. I am not trying to make
any changes, I
>>>>>> get this error simply by selecting the agreement so I can view it
and check the
>>>>>> status. I can click OK to acknowledge the error and then I am
prompted to login
>>>>>> again. I can hit cancel and continue navigating, but if I
attempt to make any
>>>>>> change in this area, the "Save" button does not
activate to let me do so. I can
>>>>>> use the Directory tab and navigate down through cn=config tree
and change the
>>>>>> agreement entries via the normal property editor window. I can
also delete the
>>>>>> agreement from the Configuration tab.
>>>>>>
>>>>>> I'm using 389-console 1.1.7-0ubuntu1 on Kubuntu 12.04, but I
have colleagues who
>>>>>> run the 389-console from the server
(389-console-1.1.7-3.el5.noarch) and see the
>>>>>> same error.
>>>>>>
>>>>>> These are the packages on the server, which is CentOS 5.7:
>>>>>> # rpm -qa 389-\*
>>>>>> 389-admin-1.1.29-1.el5.x86_64
>>>>>> 389-console-1.1.7-3.el5.noarch
>>>>>> 389-ds-base-libs-1.2.10.4-5.el5.x86_64
>>>>>> 389-admin-console-1.1.8-1.el5.noarch
>>>>>> 389-ds-base-devel-1.2.10.4-5.el5.x86_64
>>>>>> 389-ds-base-1.2.10.4-5.el5.x86_64
>>>>>> 389-ds-console-1.2.6-1.el5.noarch
>>>>>> 389-ds-console-doc-1.2.6-1.el5.noarch
>>>>>> 389-adminutil-1.1.15-1.el5.x86_64
>>>>>> 389-admin-console-doc-1.1.8-1.el5.noarch
>>>>>> 389-adminutil-devel-1.1.15-1.el5.x86_64
>>>>>>
>>>>>> While troubleshooting replication a while back, I lost all my
replication
>>>>>> agreements and recreated them all from the CLI using some
instructions I found
>>>>>> for RHDS. I don't recall if this error occurred before that
or not. If I
>>>>>> delete and re-create the agreement through the GUI, I do not get
this error when
>>>>>> selecting that same agreement, even after restarting the GUI.
>>>>> So if you create the agreements via the CLI, the console gives an
error
>>>>> when you try to edit the agreements, but when you create the
agreements
>>>>> via the console, the console will allow you to edit the agreements?
>>>> I cannot edit any replication agreements (except for the description
field)
>>>> regardless of their origin from the "Configuration" tab. I
don't receive any
>>>> error, but if I make a change to the schedule for instance, the tab gets
the
>>>> little red dot indicating a change occurred, but the "Save"
button remains
>>>> grayed out and unclickable.
>>>>
>>> Ok. I would like to see
>>> excerpts from the directory server and admin server access log and
>>> errors log from around the time of this console behavior
>>> /var/log/dirsrv/slapd-INSTANCE/errors and access
>>> /var/log/dirsrv/admin-serv/error and access
>>>
>>> run the console with 389-console -D 9 -f console.log - then reproduce
>>> the problem and post the console.log
>>>
>>> before you post any logs, be sure to scrub or obscure any sensitive data
>> Getting these logs will take a little bit longer. But to make sure I provide
useful logs, what debug logging options should I enable for access and error?
> Don't worry about it. This looks like ticket 78. I'm very confused as
> to why this was not fixed for you. Did you upgrade this 389 from an
> earlier release? If so, it is possible that there is an empty
> nsslapd-referral attribute in your dse.ldif - try this:
>
> shutdown dirsrv
> edit /etc/dirsrv/slapd-INST/dse.ldif - look for a line like
> nsslapd-referral:
> that is, there is nothing after the ":"
> delete this line
> then restart dirsrv
I don't know the full history of this server since I assumed management of it
from someone else. I believe it began life as 1.2.2 (based on version shown on
the initial screen of 389-console; have not run setup-ds.pl -u due to bug #377),
See the workaround in https://fedorahosted.org/389/ticket/377#comment:6
Then try setup-ds-admin.pl -u
See if that solves your console problem as well
was upgraded to 1.2.5rc2, then 1.2.10.{4,14}. I believe it also
started as a
consumer of a single master and then was promoted to be the new single master
pretty early on.
I reopened the bug as you suggested. A quick grep of dse.ldif shows no instance
of 'nsslapd-referral:'. The only reference to referral I find is this:
# grep -i referral dse.ldif
nsreferralonscopedsearch: off
4259
days inactive
4261
days old
389-users@lists.fedoraproject.org
10 comments
2 participants
participants (2)
-
Rich Megginson -
Wes Hardin