[389-users] GUI errors when viewing replication agreements

Thu Aug 30 18:44:52 UTC 2012

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
>