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