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 -- 389 users mailing list 389-users@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/389-users
