[389-users] GUI errors when viewing replication agreements

[Rich Megginson]

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