El 2016-08-12 20:38, Ondra Machacek escribió:
On 08/12/2016 05:53 PM, nico...@devels.es wrote:
El 2016-08-10 14:46, Nicolás escribió:
En 10/8/2016 2:29 p. m., Alexander Wels <aw...@redhat.com> escribió:

On Wednesday, August 10, 2016 9:02:16 AM EDT Alexander Wels wrote:

On Wednesday, August 10, 2016 9:10:25 AM EDT nico...@devels.es
wrote:

El 2016-08-10 08:58, Ondra Machacek escribió:

> On 08/10/2016 09:37 AM, Nicolás wrote:

>> Hi,

>>

>> We're running oVirt 4.0.1.1 [1], and we're trying to grant a
permission to

>> a

>> user on a VM. Thing is when we open the 'Permissions' subtab
on that

>> VM,

>> we click on Add, the LDAP backend shows up but any value
entered into

>> the search box returns nothing, even when I know the values
exist.

>>

>> This has been working on oVirt 3.x, we actually migrated to
4.x last

>> week and didn't notice this issue.

>>

>> Additionally, there's no combobox to choose the permission to
grant?

>

> There should be combo box to choose a role.



I've attached a screenshot, seems there's not.



Its highly likely the dropdown is there, but its scrolled below
the bottom

of the dialog and thus you can't see it. I thought I made sure all
the

dialogs were working, seems like I missed one. Let me check it out
and see

what is going on.





Okay I double checked, I went to the VMs main tab, selected a VM,
then went to

the permissions sub tab. Clicked add. The dialog that popped up
looks like the

one attached, which is what I was expecting. The one you attached
appears to

be missing some styling, which is likely what caused the Role to
Assign part

to be scrolled below the bottom of the page.



Can you complete clear your cache (not shift reload, but
settings->clear

cache). If that doesn't work can you tell us the version of the
patternfly rpm

installed on your engine?



Yes, I already did that, also opened the engine on different clients
and the behavior is the same, I believe this is not a client issue.
Patternfly package is patternfly1-1.3.0-1.el7.centos.noarch


Ok, this indeed seems like a graphics problem since I am seeing this
connecting to a machine through a VNC server and the Role combobox is
moved down out of the dialog.

However, the LDAP issue persists. When I choose the 'internal' domain, I can search the 'admin' user successfully, however, if I set it to be the
LDAP domain, any search returns nothing.

Any hints or ideas how to debug this?

Can you please enable debug log[1] and send it here?

[1]
https://github.com/oVirt/ovirt-engine-extension-aaa-ldap/blob/master/README#L442


Thanks. I was now able to see why it is failing:

TRACE [org.ovirt.engineextensions.aaa.ldap.Framework] (default task-13) [] SearchRequest: Exception: LDAPSearchException(resultCode=11 (admin limit exceeded), numEntries=0, numReferences=0, errorMessage='admin limit exceeded')

Indeed, if I run that query using the ldapsearch command I can clearly see it is returning an "admin limit exceeded" error.

The applied filter is: (&(objectClass=posixAccount)(uid=*)(|(givenName=username)(sn=username)(displayName=username)(uid=username)))

Strange thing is this hasn't been an issue on oVirt 3.6.x and we've not changed our LDAP configuration. Has the filter been changed in 4.x by default?

If so, is there a way to override the filter to make it simpler? (In our case we'll always seek by username, so no need to search by givenName, sn or displayName).

Thanks.


Thanks.




Anyhow, I see there are lots of packages to update so I'll do so
within a few days and report results.



>> All this is done with the admin@internal user, so I guess
this is not

>> a

>> self-permission issue.

>>

>> Interesting thing is that I can successfully log-in to the
user portal

>> with a LDAP based user and manage all the VMs assigned to
them.

>>

>> Just to see if there's been any configuration change, we also
run the

>> ovirt-engine-extension-aaa-ldap-setup tool, the configuration
it

>> returns

>> is pretty similar to ours, and even the test commands (Login,
Search)

>> work successfully (I can see search returning user's data
like name,

>> surname, ...). We even applied this configuration to engine
to see if

>> it

>> makes a difference but the result is the same, the search
dialog

>> returns

>> nothing and neither I can see the permission to grant.

>>

>> Any hint about this?

>

> Maybe you hit similar issue to this one[1].

>

> Can you please share engine.log, while you hit search button?



I'm also attaching the log at the time I hit the search button,
but I'm

afraid there's no entry about that.



Thanks.



> [1] https [2]://bugzilla.redhat.com/show_bug.cgi?id=1356675
[2]

>

>> Thanks

>> _______________________________________________

>> Users mailing list

>> Users@ovirt.org

>> http [3]://lists.ovirt.org/ [3]mailman [3]/ [3]listinfo [3]/
[3]users [3]



_______________________________________________

Users mailing list

Users@ovirt.org

http [3]://lists.ovirt.org/ [3]mailman [3]/ [3]listinfo [3]/
[3]users [3]

_______________________________________________

Users mailing list

Users@ovirt.org

http [3]://lists.ovirt.org/ [3]mailman [3]/ [3]listinfo [3]/
[3]users [3]





Links:
------
[1] http://4.0.1.1
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1356675
[3] http://lists.ovirt.org/mailman/listinfo/users

_______________________________________________
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
_______________________________________________
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
_______________________________________________
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Reply via email to