Re: [Users] API read-only access / roles

2014-03-26 Thread Sven Kieske
Hi,

as we now have setup ldap, now the question which
never got answered in the first place:

1.
which rights do I need for read only access?

as stated in BZ just login rights won't suffice.

2. I want to create a user who has just the
right to open the vnc/spice connection to
every vm, is this possible?


Thanks in advance
-- 
Mit freundlichen Grüßen / Regards

Sven Kieske

Systemadministrator
Mittwald CM Service GmbH  Co. KG
Königsberger Straße 6
32339 Espelkamp
T: +49-5772-293-100
F: +49-5772-293-333
https://www.mittwald.de
Geschäftsführer: Robert Meyer
St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen
Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


Re: [Users] API read-only access / roles

2014-03-26 Thread Itamar Heim

On 03/26/2014 06:16 AM, Sven Kieske wrote:

Hi,

as we now have setup ldap, now the question which
never got answered in the first place:

1.
which rights do I need for read only access?

as stated in BZ just login rights won't suffice.


an admin role with login? why not?
i thought we even pre-created such a default read only role by now:
Bug 1038222 - [RFE] Read Only Admin role in AP

(and you can create one yourself in 3.3 as well iirc)



2. I want to create a user who has just the
right to open the vnc/spice connection to
every vm, is this possible?


but not start/stop VMs?
via admin or user portal (changed the type of role you need to give 
admin/user)


just create a role with: login, connect vm, and give it at system level 
to the user

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


Re: [Users] API read-only access / roles

2014-03-26 Thread Sven Kieske
Well Doron replied to me with another information here:

https://bugzilla.redhat.com/show_bug.cgi?id=1067036#c1

I did not know of BZ 1038 nor did anybody point me there.

How to create it myself in 3.3, directly via the SQL Command?

Is this safe on a 3.3.3-2 el6?

See the attached SQL

Am 26.03.2014 11:21, schrieb Itamar Heim:
 
 an admin role with login? why not?
 i thought we even pre-created such a default read only role by now:
 Bug 1038222 - [RFE] Read Only Admin role in AP
 
 (and you can create one yourself in 3.3 as well iirc)

-- 
Mit freundlichen Grüßen / Regards

Sven Kieske

Systemadministrator
Mittwald CM Service GmbH  Co. KG
Königsberger Straße 6
32339 Espelkamp
T: +49-5772-293-100
F: +49-5772-293-333
https://www.mittwald.de
Geschäftsführer: Robert Meyer
St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen
Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen
	Create or replace FUNCTION __temp_insert_read_only_admin_role()	1
			RETURNS VOID	2
			AS $procedure$	3
			DECLARE	4
			v_ROLE_ID UUID;	5
			BEGIN	6
			v_ROLE_ID := 'DEFC----DEFC';	7
8
			DELETE FROM roles_groups WHERE role_id = v_ROLE_ID;	9
			INSERT INTO roles(id,name,description,is_readonly,role_type,allows_viewing_children,app_mode) SELECT
v_ROLE_ID, 'ReadOnlyAdmin', 'Read Only Administrator Role', true, 1, true, 1	10
			WHERE NOT EXISTS (SELECT id,name,description,is_readonly,role_type	11
			FROM roles	12
			WHERE id = v_ROLE_ID	13
			AND name='ReadOnlyAdmin'	14
			AND description='Read Only Administrator Role'	15
			AND is_readonly=true	16
			AND role_type=1);	17
18
			-- Allowing this role to login 	19
			INSERT INTO roles_groups(role_id,action_group_id) VALUES(v_ROLE_ID, 1300);	20
21
			RETURN;	22
			END; $procedure$	23
			LANGUAGE plpgsql;	24
25
			SELECT __temp_insert_read_only_admin_role();	26
			DROP function __temp_insert_read_only_admin_role();
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


Re: [Users] API read-only access / roles

2014-03-26 Thread Sven Kieske


Am 26.03.2014 11:21, schrieb Itamar Heim:
 On 03/26/2014 06:16 AM, Sven Kieske wrote:
 Hi,

 as we now have setup ldap, now the question which
 never got answered in the first place:

 1.
 which rights do I need for read only access?

 as stated in BZ just login rights won't suffice.
 
 an admin role with login? why not?
 i thought we even pre-created such a default read only role by now:
 Bug 1038222 - [RFE] Read Only Admin role in AP
 
 (and you can create one yourself in 3.3 as well iirc)
 
What would happen if I create this user myself
and I want to upgrade to 3.4 somewhere in time?

My guess would be the upgrade would fail if this
user gets added automatically, because it is already
there?

-- 
Mit freundlichen Grüßen / Regards

Sven Kieske

Systemadministrator
Mittwald CM Service GmbH  Co. KG
Königsberger Straße 6
32339 Espelkamp
T: +49-5772-293-100
F: +49-5772-293-333
https://www.mittwald.de
Geschäftsführer: Robert Meyer
St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen
Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


Re: [Users] API read-only access / roles

2014-03-26 Thread Itamar Heim

On 03/26/2014 06:39 AM, Sven Kieske wrote:



Am 26.03.2014 11:21, schrieb Itamar Heim:

On 03/26/2014 06:16 AM, Sven Kieske wrote:

Hi,

as we now have setup ldap, now the question which
never got answered in the first place:

1.
which rights do I need for read only access?

as stated in BZ just login rights won't suffice.


an admin role with login? why not?
i thought we even pre-created such a default read only role by now:
Bug 1038222 - [RFE] Read Only Admin role in AP

(and you can create one yourself in 3.3 as well iirc)


What would happen if I create this user myself
and I want to upgrade to 3.4 somewhere in time?

My guess would be the upgrade would fail if this
user gets added automatically, because it is already
there?



its not a user. its a system defined role.
you can create a user defined role (with a different name)
you should do this via the GUI in 3.3, not via the db (then the uuid 
will be different as well, and no upgrade issues)

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


Re: [Users] API read-only access / roles

2014-03-26 Thread Sven Kieske
Thanks again,

it seems to work quite well (couldn't test everything).

Am 26.03.2014 11:46, schrieb Itamar Heim:
 its not a user. its a system defined role.
 you can create a user defined role (with a different name)
 you should do this via the GUI in 3.3, not via the db (then the uuid
 will be different as well, and no upgrade issues)

-- 
Mit freundlichen Grüßen / Regards

Sven Kieske

Systemadministrator
Mittwald CM Service GmbH  Co. KG
Königsberger Straße 6
32339 Espelkamp
T: +49-5772-293-100
F: +49-5772-293-333
https://www.mittwald.de
Geschäftsführer: Robert Meyer
St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen
Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


Re: [Users] API read-only access / roles

2014-03-26 Thread Yair Zaslavsky


- Original Message -
 From: Itamar Heim ih...@redhat.com
 To: Sven Kieske s.kie...@mittwald.de, Users@ovirt.org List 
 Users@ovirt.org, Yair Zaslavsky
 yzasl...@redhat.com
 Sent: Wednesday, March 26, 2014 12:46:28 PM
 Subject: Re: [Users] API read-only access / roles
 
 On 03/26/2014 06:39 AM, Sven Kieske wrote:
 
 
  Am 26.03.2014 11:21, schrieb Itamar Heim:
  On 03/26/2014 06:16 AM, Sven Kieske wrote:
  Hi,
 
  as we now have setup ldap, now the question which
  never got answered in the first place:
 
  1.
  which rights do I need for read only access?
 
  as stated in BZ just login rights won't suffice.
 
  an admin role with login? why not?
  i thought we even pre-created such a default read only role by now:
  Bug 1038222 - [RFE] Read Only Admin role in AP
 
  (and you can create one yourself in 3.3 as well iirc)
 
  What would happen if I create this user myself
  and I want to upgrade to 3.4 somewhere in time?
 
  My guess would be the upgrade would fail if this
  user gets added automatically, because it is already
  there?
 
 
 its not a user. its a system defined role.
 you can create a user defined role (with a different name)
 you should do this via the GUI in 3.3, not via the db (then the uuid
 will be different as well, and no upgrade issues)

Regarding your upgrade question -
I would like to add that although we have a hard-coded internal admin user, 
your read only user (that is, a user you assigned the role you created) is 
not a hard coded one. I don't think we will go for a strategy of adding another 
hardcoded user for read only , so you should not have upgrade issues.

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


Re: [Users] API read-only access / roles

2014-03-24 Thread Sven Kieske
Hi,

will this interface for 3.5 be production ready or
just a first release /draft ?

Would it be possible to add a read only user for 3.4.x releases?

Am 23.02.2014 09:52, schrieb Alon Bar-Lev:
 
 
 - Original Message -
 From: Yair Zaslavsky yzasl...@redhat.com
 To: Juan Hernandez jhern...@redhat.com
 Cc: Sven Kieske s.kie...@mittwald.de, Users@ovirt.org List 
 Users@ovirt.org, Itamar Heim ih...@redhat.com,
 Alon Bar-Lev alo...@redhat.com
 Sent: Sunday, February 23, 2014 8:55:07 AM
 Subject: Re: [Users] API read-only access / roles



 - Original Message -
 From: Juan Hernandez jhern...@redhat.com
 To: Sven Kieske s.kie...@mittwald.de, Users@ovirt.org List
 Users@ovirt.org
 Cc: Itamar Heim ih...@redhat.com, Yair Zaslavsky
 yzasl...@redhat.com
 Sent: Saturday, February 22, 2014 2:22:14 PM
 Subject: Re: [Users] API read-only access / roles

 On 02/20/2014 04:51 PM, Itamar Heim wrote:
 On 02/20/2014 05:24 PM, Sven Kieske wrote:
 Hi,

 is nobody interested in this feature at all?
 it would be a huge security gain, while lowering
 the bars for having a read only user if this could get shipped with 3.4:

 we are very interested, but we want to do this based on the
 authentication re-factoring, which in itself, barely made the 3.4
 timeline.
 Yair - are we pluggable yet, that someone could add such a user by
 dropping a jar somewhere, or still on going work towards 3.5?

 As Juan mentioned in his email, it should be possible to plug in at 3.4 as
 well.
 However, we're changing the configuration format at 3.5 as we're changing the
 mechanism to use the extensions mechanism - both Directory and Authenticator
 are extensions, the configuration for
 directory (authorization extension) and authenciator (authentication
 extension) will look a bit different.
 
 Hello,
 
 Until we announce public interface for aaa (authentication, authorization, 
 accounting) the implementation is internal and should not be used by external 
 projects.
 
 We are heading for publishing the interface within 3.5 timeline.
 
 Thanks,
 Alon
 






 Pugglability of authentication already works in 3.4. By default it uses
 the previous mechanism, but the administrator can change this. In order
 to change you need to create the /etc/ovirt-engine/auth.conf.d directory
 and then create inside one or more authentication profiles
 configuration files. An authentication profile is a combination of an
 authenticator and a directory. The authenticator is used to check
 the credentials (the user name and password) and the directory is used
 to search users and their details. For example, if you want to use local
 authentication (the users, passwords, and groups of the OS) you can
 create a local.conf file with the following content:

   #
   # The name of the profile. This is what will be displayed in the
   # combo box in the login page.
   #
   name=local

   #
   # Needed to enable the profile, by default all profiles are
   # disabled.
   #
   enabled=true

   #
   # The configuration of the authenticator used by the profile. The
   # type and the module are mandatory, the rest are optional and
   # the default values are as shown below.
   #
   authenticator.type=ssh
   authenticator.module=org.ovirt.engine.core.authentication.ssh
   # authenticator.host=localhost
   # authenticator.port=22
   # authenticator.timeout=10

   #
   # The configuration of the directory:
   #
   directory.type=nss
   directory.module=org.ovirt.engine.core.authentication.nss

 For this to work you need to install some additional modules, which
 aren't currently part of the engine. This is where plugabillity comes in
 place. This modules can be built externally. I created modules for SSH
 authentication and NSS (Name Service Switch) directory. The source is
 available here:

 https://github.com/jhernand/ovirt-engine-ssh-authenticator
 https://github.com/jhernand/ovirt-engine-nss-directory

 The NSS directory also needs JNA (Java Native Access):

 https://github.com/jhernand/ovirt-engine-jna-module

 Installing these extensions is very easy, just build from source and
 uncompress the generated .zip files to /usr/share/ovirt-engine/modules.
 In case you don't want to build from source you can use the RPMs that I
 created. The source for the .spec files is here:

 https://github.com/jhernand/ovirt-engine-rpms

 If you don't want to build form source you can use a yum repository that
 I created with binaries for Fedora 20 (should work in CentOS as well):

 http://jhernand.fedorapeople.org/repo

 So, to summarize:

 # cat  /etc/yum.repos.d/my.repo .
 [my]
 name=my
 baseurl=http://jhernand.fedorapeople.org/repo
 enabled=1
 gpgcheck=0
 .

 # yum -y install \
 ovirt-engine-ssh-authenticator \
 ovirt-engine-nss-directory

 # mkdir -p /etc/ovirt-engine/auth.conf.d

 # cat  /etc/ovirt-engine/auth.conf.d/local.conf .
 name=local
 enabled=true
 authenticator.type=ssh
 authenticator.module=org.ovirt.engine.core.authentication.ssh
 directory.type=nss
 directory.module

Re: [Users] API read-only access / roles

2014-02-23 Thread Alon Bar-Lev


- Original Message -
 From: Yair Zaslavsky yzasl...@redhat.com
 To: Juan Hernandez jhern...@redhat.com
 Cc: Sven Kieske s.kie...@mittwald.de, Users@ovirt.org List 
 Users@ovirt.org, Itamar Heim ih...@redhat.com,
 Alon Bar-Lev alo...@redhat.com
 Sent: Sunday, February 23, 2014 8:55:07 AM
 Subject: Re: [Users] API read-only access / roles
 
 
 
 - Original Message -
  From: Juan Hernandez jhern...@redhat.com
  To: Sven Kieske s.kie...@mittwald.de, Users@ovirt.org List
  Users@ovirt.org
  Cc: Itamar Heim ih...@redhat.com, Yair Zaslavsky
  yzasl...@redhat.com
  Sent: Saturday, February 22, 2014 2:22:14 PM
  Subject: Re: [Users] API read-only access / roles
  
  On 02/20/2014 04:51 PM, Itamar Heim wrote:
   On 02/20/2014 05:24 PM, Sven Kieske wrote:
   Hi,
  
   is nobody interested in this feature at all?
   it would be a huge security gain, while lowering
   the bars for having a read only user if this could get shipped with 3.4:
   
   we are very interested, but we want to do this based on the
   authentication re-factoring, which in itself, barely made the 3.4
   timeline.
   Yair - are we pluggable yet, that someone could add such a user by
   dropping a jar somewhere, or still on going work towards 3.5?
 
 As Juan mentioned in his email, it should be possible to plug in at 3.4 as
 well.
 However, we're changing the configuration format at 3.5 as we're changing the
 mechanism to use the extensions mechanism - both Directory and Authenticator
 are extensions, the configuration for
 directory (authorization extension) and authenciator (authentication
 extension) will look a bit different.

Hello,

Until we announce public interface for aaa (authentication, authorization, 
accounting) the implementation is internal and should not be used by external 
projects.

We are heading for publishing the interface within 3.5 timeline.

Thanks,
Alon

 
 
 
 
   
  
  Pugglability of authentication already works in 3.4. By default it uses
  the previous mechanism, but the administrator can change this. In order
  to change you need to create the /etc/ovirt-engine/auth.conf.d directory
  and then create inside one or more authentication profiles
  configuration files. An authentication profile is a combination of an
  authenticator and a directory. The authenticator is used to check
  the credentials (the user name and password) and the directory is used
  to search users and their details. For example, if you want to use local
  authentication (the users, passwords, and groups of the OS) you can
  create a local.conf file with the following content:
  
#
# The name of the profile. This is what will be displayed in the
# combo box in the login page.
#
name=local
  
#
# Needed to enable the profile, by default all profiles are
# disabled.
#
enabled=true
  
#
# The configuration of the authenticator used by the profile. The
# type and the module are mandatory, the rest are optional and
# the default values are as shown below.
#
authenticator.type=ssh
authenticator.module=org.ovirt.engine.core.authentication.ssh
# authenticator.host=localhost
# authenticator.port=22
# authenticator.timeout=10
  
#
# The configuration of the directory:
#
directory.type=nss
directory.module=org.ovirt.engine.core.authentication.nss
  
  For this to work you need to install some additional modules, which
  aren't currently part of the engine. This is where plugabillity comes in
  place. This modules can be built externally. I created modules for SSH
  authentication and NSS (Name Service Switch) directory. The source is
  available here:
  
  https://github.com/jhernand/ovirt-engine-ssh-authenticator
  https://github.com/jhernand/ovirt-engine-nss-directory
  
  The NSS directory also needs JNA (Java Native Access):
  
  https://github.com/jhernand/ovirt-engine-jna-module
  
  Installing these extensions is very easy, just build from source and
  uncompress the generated .zip files to /usr/share/ovirt-engine/modules.
  In case you don't want to build from source you can use the RPMs that I
  created. The source for the .spec files is here:
  
  https://github.com/jhernand/ovirt-engine-rpms
  
  If you don't want to build form source you can use a yum repository that
  I created with binaries for Fedora 20 (should work in CentOS as well):
  
  http://jhernand.fedorapeople.org/repo
  
  So, to summarize:
  
  # cat  /etc/yum.repos.d/my.repo .
  [my]
  name=my
  baseurl=http://jhernand.fedorapeople.org/repo
  enabled=1
  gpgcheck=0
  .
  
  # yum -y install \
  ovirt-engine-ssh-authenticator \
  ovirt-engine-nss-directory
  
  # mkdir -p /etc/ovirt-engine/auth.conf.d
  
  # cat  /etc/ovirt-engine/auth.conf.d/local.conf .
  name=local
  enabled=true
  authenticator.type=ssh
  authenticator.module=org.ovirt.engine.core.authentication.ssh
  directory.type=nss
  directory.module=org.ovirt.engine.core.authentication.nss

Re: [Users] API read-only access / roles

2014-02-22 Thread Juan Hernandez
On 02/20/2014 04:51 PM, Itamar Heim wrote:
 On 02/20/2014 05:24 PM, Sven Kieske wrote:
 Hi,

 is nobody interested in this feature at all?
 it would be a huge security gain, while lowering
 the bars for having a read only user if this could get shipped with 3.4:
 
 we are very interested, but we want to do this based on the 
 authentication re-factoring, which in itself, barely made the 3.4 timeline.
 Yair - are we pluggable yet, that someone could add such a user by 
 dropping a jar somewhere, or still on going work towards 3.5?
 

Pugglability of authentication already works in 3.4. By default it uses
the previous mechanism, but the administrator can change this. In order
to change you need to create the /etc/ovirt-engine/auth.conf.d directory
and then create inside one or more authentication profiles
configuration files. An authentication profile is a combination of an
authenticator and a directory. The authenticator is used to check
the credentials (the user name and password) and the directory is used
to search users and their details. For example, if you want to use local
authentication (the users, passwords, and groups of the OS) you can
create a local.conf file with the following content:

  #
  # The name of the profile. This is what will be displayed in the
  # combo box in the login page.
  #
  name=local

  #
  # Needed to enable the profile, by default all profiles are
  # disabled.
  #
  enabled=true

  #
  # The configuration of the authenticator used by the profile. The
  # type and the module are mandatory, the rest are optional and
  # the default values are as shown below.
  #
  authenticator.type=ssh
  authenticator.module=org.ovirt.engine.core.authentication.ssh
  # authenticator.host=localhost
  # authenticator.port=22
  # authenticator.timeout=10

  #
  # The configuration of the directory:
  #
  directory.type=nss
  directory.module=org.ovirt.engine.core.authentication.nss

For this to work you need to install some additional modules, which
aren't currently part of the engine. This is where plugabillity comes in
place. This modules can be built externally. I created modules for SSH
authentication and NSS (Name Service Switch) directory. The source is
available here:

https://github.com/jhernand/ovirt-engine-ssh-authenticator
https://github.com/jhernand/ovirt-engine-nss-directory

The NSS directory also needs JNA (Java Native Access):

https://github.com/jhernand/ovirt-engine-jna-module

Installing these extensions is very easy, just build from source and
uncompress the generated .zip files to /usr/share/ovirt-engine/modules.
In case you don't want to build from source you can use the RPMs that I
created. The source for the .spec files is here:

https://github.com/jhernand/ovirt-engine-rpms

If you don't want to build form source you can use a yum repository that
I created with binaries for Fedora 20 (should work in CentOS as well):

http://jhernand.fedorapeople.org/repo

So, to summarize:

# cat  /etc/yum.repos.d/my.repo .
[my]
name=my
baseurl=http://jhernand.fedorapeople.org/repo
enabled=1
gpgcheck=0
.

# yum -y install \
ovirt-engine-ssh-authenticator \
ovirt-engine-nss-directory

# mkdir -p /etc/ovirt-engine/auth.conf.d

# cat  /etc/ovirt-engine/auth.conf.d/local.conf .
name=local
enabled=true
authenticator.type=ssh
authenticator.module=org.ovirt.engine.core.authentication.ssh
directory.type=nss
directory.module=org.ovirt.engine.core.authentication.nss
.

# systemctl restart ovirt-engine

Then you can login with admin@internal, add some local users and
permissions, and then use them to login to the GUI or the API.

Take into account that I created these modules as a way to test the new
authentication infrastructure, so they may have limitations or issues. I
appreciate any feedback.


 Am 19.02.2014 15:32, schrieb Sven Kieske: I just looked into my test vm
 with the 3.4 beta
 and I can't see such an user there.

 I created an RFE at: https://bugzilla.redhat.com/show_bug.cgi?id=1067036


 I really hope this can get included in 3.4 (I know it's late)
 as it should be a very very minor change at engine-setup.

 Thanks

 Am 19.02.2014 14:55, schrieb Sven Kieske:
 Hi,

 reiterating on this somewhat old mail:

 Is there a read only user integrated in 3.4?

 Because it's a huge overhead to install somewhere
 e.g. a freeipa server just to get read only access.

 Am 21.11.2013 09:52, schrieb Sander Grendelman:
 Hi Doron,

 The user I've defined in [1] works for me.
 A built-in login-/read-only role would be nice,
 but it's quite easy to define a custom role so
 more of a nice-to-have instead of a must-have.

 Thanks for asking!

 Sander.

 On Wed, Nov 20, 2013 at 5:40 PM, Doron Fediuck dfedi...@redhat.com
 wrote:
 Hi Sander,
 We're closing the ovirt 3.4 scope, and wondering if you're handling
 Zabbix based on [1].
 If so please let me know and I'll update the 3.4 features list.

 Thanks,
 Doron

 [1] http://lists.ovirt.org/pipermail/users/2013-November/017946.html


 
 

Re: [Users] API read-only access / roles

2014-02-22 Thread Yair Zaslavsky


- Original Message -
 From: Juan Hernandez jhern...@redhat.com
 To: Sven Kieske s.kie...@mittwald.de, Users@ovirt.org List 
 Users@ovirt.org
 Cc: Itamar Heim ih...@redhat.com, Yair Zaslavsky yzasl...@redhat.com
 Sent: Saturday, February 22, 2014 2:22:14 PM
 Subject: Re: [Users] API read-only access / roles
 
 On 02/20/2014 04:51 PM, Itamar Heim wrote:
  On 02/20/2014 05:24 PM, Sven Kieske wrote:
  Hi,
 
  is nobody interested in this feature at all?
  it would be a huge security gain, while lowering
  the bars for having a read only user if this could get shipped with 3.4:
  
  we are very interested, but we want to do this based on the
  authentication re-factoring, which in itself, barely made the 3.4 timeline.
  Yair - are we pluggable yet, that someone could add such a user by
  dropping a jar somewhere, or still on going work towards 3.5?

As Juan mentioned in his email, it should be possible to plug in at 3.4 as well.
However, we're changing the configuration format at 3.5 as we're changing the 
mechanism to use the extensions mechanism - both Directory and Authenticator 
are extensions, the configuration for
directory (authorization extension) and authenciator (authentication extension) 
will look a bit different.




  
 
 Pugglability of authentication already works in 3.4. By default it uses
 the previous mechanism, but the administrator can change this. In order
 to change you need to create the /etc/ovirt-engine/auth.conf.d directory
 and then create inside one or more authentication profiles
 configuration files. An authentication profile is a combination of an
 authenticator and a directory. The authenticator is used to check
 the credentials (the user name and password) and the directory is used
 to search users and their details. For example, if you want to use local
 authentication (the users, passwords, and groups of the OS) you can
 create a local.conf file with the following content:
 
   #
   # The name of the profile. This is what will be displayed in the
   # combo box in the login page.
   #
   name=local
 
   #
   # Needed to enable the profile, by default all profiles are
   # disabled.
   #
   enabled=true
 
   #
   # The configuration of the authenticator used by the profile. The
   # type and the module are mandatory, the rest are optional and
   # the default values are as shown below.
   #
   authenticator.type=ssh
   authenticator.module=org.ovirt.engine.core.authentication.ssh
   # authenticator.host=localhost
   # authenticator.port=22
   # authenticator.timeout=10
 
   #
   # The configuration of the directory:
   #
   directory.type=nss
   directory.module=org.ovirt.engine.core.authentication.nss
 
 For this to work you need to install some additional modules, which
 aren't currently part of the engine. This is where plugabillity comes in
 place. This modules can be built externally. I created modules for SSH
 authentication and NSS (Name Service Switch) directory. The source is
 available here:
 
 https://github.com/jhernand/ovirt-engine-ssh-authenticator
 https://github.com/jhernand/ovirt-engine-nss-directory
 
 The NSS directory also needs JNA (Java Native Access):
 
 https://github.com/jhernand/ovirt-engine-jna-module
 
 Installing these extensions is very easy, just build from source and
 uncompress the generated .zip files to /usr/share/ovirt-engine/modules.
 In case you don't want to build from source you can use the RPMs that I
 created. The source for the .spec files is here:
 
 https://github.com/jhernand/ovirt-engine-rpms
 
 If you don't want to build form source you can use a yum repository that
 I created with binaries for Fedora 20 (should work in CentOS as well):
 
 http://jhernand.fedorapeople.org/repo
 
 So, to summarize:
 
 # cat  /etc/yum.repos.d/my.repo .
 [my]
 name=my
 baseurl=http://jhernand.fedorapeople.org/repo
 enabled=1
 gpgcheck=0
 .
 
 # yum -y install \
 ovirt-engine-ssh-authenticator \
 ovirt-engine-nss-directory
 
 # mkdir -p /etc/ovirt-engine/auth.conf.d
 
 # cat  /etc/ovirt-engine/auth.conf.d/local.conf .
 name=local
 enabled=true
 authenticator.type=ssh
 authenticator.module=org.ovirt.engine.core.authentication.ssh
 directory.type=nss
 directory.module=org.ovirt.engine.core.authentication.nss
 .
 
 # systemctl restart ovirt-engine
 
 Then you can login with admin@internal, add some local users and
 permissions, and then use them to login to the GUI or the API.
 
 Take into account that I created these modules as a way to test the new
 authentication infrastructure, so they may have limitations or issues. I
 appreciate any feedback.
 
 
  Am 19.02.2014 15:32, schrieb Sven Kieske: I just looked into my test vm
  with the 3.4 beta
  and I can't see such an user there.
 
  I created an RFE at: https://bugzilla.redhat.com/show_bug.cgi?id=1067036
 
 
  I really hope this can get included in 3.4 (I know it's late)
  as it should be a very very minor change at engine-setup.
 
  Thanks
 
  Am 19.02.2014 14:55, schrieb Sven Kieske

Re: [Users] API read-only access / roles

2014-02-22 Thread Yair Zaslavsky


- Original Message -
 From: Yair Zaslavsky yzasl...@redhat.com
 To: Juan Hernandez jhern...@redhat.com
 Cc: Users@ovirt.org List Users@ovirt.org
 Sent: Sunday, February 23, 2014 8:55:07 AM
 Subject: Re: [Users] API read-only access / roles
 
 
 
 - Original Message -
  From: Juan Hernandez jhern...@redhat.com
  To: Sven Kieske s.kie...@mittwald.de, Users@ovirt.org List
  Users@ovirt.org
  Cc: Itamar Heim ih...@redhat.com, Yair Zaslavsky
  yzasl...@redhat.com
  Sent: Saturday, February 22, 2014 2:22:14 PM
  Subject: Re: [Users] API read-only access / roles
  
  On 02/20/2014 04:51 PM, Itamar Heim wrote:
   On 02/20/2014 05:24 PM, Sven Kieske wrote:
   Hi,
  
   is nobody interested in this feature at all?
   it would be a huge security gain, while lowering
   the bars for having a read only user if this could get shipped with 3.4:
   
   we are very interested, but we want to do this based on the
   authentication re-factoring, which in itself, barely made the 3.4
   timeline.
   Yair - are we pluggable yet, that someone could add such a user by
   dropping a jar somewhere, or still on going work towards 3.5?
 
 As Juan mentioned in his email, it should be possible to plug in at 3.4 as
 well.
 However, we're changing the configuration format at 3.5 as we're changing the
 mechanism to use the extensions mechanism - both Directory and Authenticator
 are extensions, the configuration for
 directory (authorization extension) and authenciator (authentication
 extension) will look a bit different.

CC'ed Sven as well, 
In addition bare in mind as Directory and Authenticator will be extensions, 
there will be some interface change.

Yair

 
 
 
 
   
  
  Pugglability of authentication already works in 3.4. By default it uses
  the previous mechanism, but the administrator can change this. In order
  to change you need to create the /etc/ovirt-engine/auth.conf.d directory
  and then create inside one or more authentication profiles
  configuration files. An authentication profile is a combination of an
  authenticator and a directory. The authenticator is used to check
  the credentials (the user name and password) and the directory is used
  to search users and their details. For example, if you want to use local
  authentication (the users, passwords, and groups of the OS) you can
  create a local.conf file with the following content:
  
#
# The name of the profile. This is what will be displayed in the
# combo box in the login page.
#
name=local
  
#
# Needed to enable the profile, by default all profiles are
# disabled.
#
enabled=true
  
#
# The configuration of the authenticator used by the profile. The
# type and the module are mandatory, the rest are optional and
# the default values are as shown below.
#
authenticator.type=ssh
authenticator.module=org.ovirt.engine.core.authentication.ssh
# authenticator.host=localhost
# authenticator.port=22
# authenticator.timeout=10
  
#
# The configuration of the directory:
#
directory.type=nss
directory.module=org.ovirt.engine.core.authentication.nss
  
  For this to work you need to install some additional modules, which
  aren't currently part of the engine. This is where plugabillity comes in
  place. This modules can be built externally. I created modules for SSH
  authentication and NSS (Name Service Switch) directory. The source is
  available here:
  
  https://github.com/jhernand/ovirt-engine-ssh-authenticator
  https://github.com/jhernand/ovirt-engine-nss-directory
  
  The NSS directory also needs JNA (Java Native Access):
  
  https://github.com/jhernand/ovirt-engine-jna-module
  
  Installing these extensions is very easy, just build from source and
  uncompress the generated .zip files to /usr/share/ovirt-engine/modules.
  In case you don't want to build from source you can use the RPMs that I
  created. The source for the .spec files is here:
  
  https://github.com/jhernand/ovirt-engine-rpms
  
  If you don't want to build form source you can use a yum repository that
  I created with binaries for Fedora 20 (should work in CentOS as well):
  
  http://jhernand.fedorapeople.org/repo
  
  So, to summarize:
  
  # cat  /etc/yum.repos.d/my.repo .
  [my]
  name=my
  baseurl=http://jhernand.fedorapeople.org/repo
  enabled=1
  gpgcheck=0
  .
  
  # yum -y install \
  ovirt-engine-ssh-authenticator \
  ovirt-engine-nss-directory
  
  # mkdir -p /etc/ovirt-engine/auth.conf.d
  
  # cat  /etc/ovirt-engine/auth.conf.d/local.conf .
  name=local
  enabled=true
  authenticator.type=ssh
  authenticator.module=org.ovirt.engine.core.authentication.ssh
  directory.type=nss
  directory.module=org.ovirt.engine.core.authentication.nss
  .
  
  # systemctl restart ovirt-engine
  
  Then you can login with admin@internal, add some local users and
  permissions, and then use them to login to the GUI or the API.
  
  Take into account that I created

Re: [Users] API read-only access / roles

2014-02-20 Thread Jiří Sléžka

Hello Sander,

where can I find more informations about your zabbix monitoring plugin? 
We are using zabbix and also rhev and ovirt so I can (and would like to) 
test it.


thanks

Jiri


Dne 18.11.2013 16:46, Sander Grendelman napsal(a):

I'm working on (Zabbix) monitoring through the RESTful API.

Which role should I assign to the monitoring user?

The user only needs read access to the data but it looks like
I nead to assign at least an Admin role to the user to be
able to read data through the API.

For this I've created a AdminLoginOnly role that only has
System-Configure System-Login Permissions access.

Is this the way to go for this king of configuration? Or is there
a way to further minimize the permissions of this user?

Another issue is that a Login event is generated every time
the user connects through the API. This makes the Events
pane less useful / readable. Is there a way to disable this for
some users/roles?
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users



attachment: jiri_slezka.vcf

smime.p7s
Description: Elektronicky podpis S/MIME
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


[Users] API read-only access / roles

2014-02-20 Thread Sven Kieske
Hi,

is nobody interested in this feature at all?
it would be a huge security gain, while lowering
the bars for having a read only user if this could get shipped with 3.4:

Am 19.02.2014 15:32, schrieb Sven Kieske: I just looked into my test vm
with the 3.4 beta
 and I can't see such an user there.

 I created an RFE at: https://bugzilla.redhat.com/show_bug.cgi?id=1067036


 I really hope this can get included in 3.4 (I know it's late)
 as it should be a very very minor change at engine-setup.

 Thanks

 Am 19.02.2014 14:55, schrieb Sven Kieske:
 Hi,

 reiterating on this somewhat old mail:

 Is there a read only user integrated in 3.4?

 Because it's a huge overhead to install somewhere
 e.g. a freeipa server just to get read only access.

 Am 21.11.2013 09:52, schrieb Sander Grendelman:
 Hi Doron,

 The user I've defined in [1] works for me.
 A built-in login-/read-only role would be nice,
 but it's quite easy to define a custom role so
 more of a nice-to-have instead of a must-have.

 Thanks for asking!

 Sander.

 On Wed, Nov 20, 2013 at 5:40 PM, Doron Fediuck dfedi...@redhat.com
wrote:
 Hi Sander,
 We're closing the ovirt 3.4 scope, and wondering if you're handling
 Zabbix based on [1].
 If so please let me know and I'll update the 3.4 features list.

 Thanks,
 Doron

 [1] http://lists.ovirt.org/pipermail/users/2013-November/017946.html


-- 
Mit freundlichen Grüßen / Regards

Sven Kieske

Systemadministrator
Mittwald CM Service GmbH  Co. KG
Königsberger Straße 6
32339 Espelkamp
T: +49-5772-293-100
F: +49-5772-293-333
https://www.mittwald.de
Geschäftsführer: Robert Meyer
St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen
Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


Re: [Users] API read-only access / roles

2014-02-20 Thread Itamar Heim

On 02/20/2014 05:24 PM, Sven Kieske wrote:

Hi,

is nobody interested in this feature at all?
it would be a huge security gain, while lowering
the bars for having a read only user if this could get shipped with 3.4:


we are very interested, but we want to do this based on the 
authentication re-factoring, which in itself, barely made the 3.4 timeline.
Yair - are we pluggable yet, that someone could add such a user by 
dropping a jar somewhere, or still on going work towards 3.5?




Am 19.02.2014 15:32, schrieb Sven Kieske: I just looked into my test vm
with the 3.4 beta

and I can't see such an user there.

I created an RFE at: https://bugzilla.redhat.com/show_bug.cgi?id=1067036


I really hope this can get included in 3.4 (I know it's late)
as it should be a very very minor change at engine-setup.

Thanks

Am 19.02.2014 14:55, schrieb Sven Kieske:

Hi,

reiterating on this somewhat old mail:

Is there a read only user integrated in 3.4?

Because it's a huge overhead to install somewhere
e.g. a freeipa server just to get read only access.

Am 21.11.2013 09:52, schrieb Sander Grendelman:

Hi Doron,

The user I've defined in [1] works for me.
A built-in login-/read-only role would be nice,
but it's quite easy to define a custom role so
more of a nice-to-have instead of a must-have.

Thanks for asking!

Sander.

On Wed, Nov 20, 2013 at 5:40 PM, Doron Fediuck dfedi...@redhat.com

wrote:

Hi Sander,
We're closing the ovirt 3.4 scope, and wondering if you're handling
Zabbix based on [1].
If so please let me know and I'll update the 3.4 features list.

Thanks,
Doron

[1] http://lists.ovirt.org/pipermail/users/2013-November/017946.html






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


Re: [Users] API read-only access / roles

2014-02-19 Thread Sven Kieske
Hi,

reiterating on this somewhat old mail:

Is there a read only user integrated in 3.4?

Because it's a huge overhead to install somewhere
e.g. a freeipa server just to get read only access.

Am 21.11.2013 09:52, schrieb Sander Grendelman:
 Hi Doron,
 
 The user I've defined in [1] works for me.
 A built-in login-/read-only role would be nice,
 but it's quite easy to define a custom role so
 more of a nice-to-have instead of a must-have.
 
 Thanks for asking!
 
 Sander.
 
 On Wed, Nov 20, 2013 at 5:40 PM, Doron Fediuck dfedi...@redhat.com wrote:
 Hi Sander,
 We're closing the ovirt 3.4 scope, and wondering if you're handling
 Zabbix based on [1].
 If so please let me know and I'll update the 3.4 features list.

 Thanks,
 Doron

 [1] http://lists.ovirt.org/pipermail/users/2013-November/017946.html

-- 
Mit freundlichen Grüßen / Regards

Sven Kieske

Systemadministrator
Mittwald CM Service GmbH  Co. KG
Königsberger Straße 6
32339 Espelkamp
T: +49-5772-293-100
F: +49-5772-293-333
https://www.mittwald.de
Geschäftsführer: Robert Meyer
St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen
Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


Re: [Users] API read-only access / roles

2014-02-19 Thread Sven Kieske
I just looked into my test vm with the 3.4 beta
and I can't see such an user there.

I created an RFE at: https://bugzilla.redhat.com/show_bug.cgi?id=1067036


I really hope this can get included in 3.4 (I know it's late)
as it should be a very very minor change at engine-setup.

Thanks

Am 19.02.2014 14:55, schrieb Sven Kieske:
 Hi,
 
 reiterating on this somewhat old mail:
 
 Is there a read only user integrated in 3.4?
 
 Because it's a huge overhead to install somewhere
 e.g. a freeipa server just to get read only access.
 
 Am 21.11.2013 09:52, schrieb Sander Grendelman:
 Hi Doron,

 The user I've defined in [1] works for me.
 A built-in login-/read-only role would be nice,
 but it's quite easy to define a custom role so
 more of a nice-to-have instead of a must-have.

 Thanks for asking!

 Sander.

 On Wed, Nov 20, 2013 at 5:40 PM, Doron Fediuck dfedi...@redhat.com wrote:
 Hi Sander,
 We're closing the ovirt 3.4 scope, and wondering if you're handling
 Zabbix based on [1].
 If so please let me know and I'll update the 3.4 features list.

 Thanks,
 Doron

 [1] http://lists.ovirt.org/pipermail/users/2013-November/017946.html
 

-- 
Mit freundlichen Grüßen / Regards

Sven Kieske

Systemadministrator
Mittwald CM Service GmbH  Co. KG
Königsberger Straße 6
32339 Espelkamp
T: +49-5772-293-100
F: +49-5772-293-333
https://www.mittwald.de
Geschäftsführer: Robert Meyer
St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen
Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


Re: [Users] API read-only access / roles

2013-11-21 Thread Sander Grendelman
Hi Doron,

The user I've defined in [1] works for me.
A built-in login-/read-only role would be nice,
but it's quite easy to define a custom role so
more of a nice-to-have instead of a must-have.

Thanks for asking!

Sander.

On Wed, Nov 20, 2013 at 5:40 PM, Doron Fediuck dfedi...@redhat.com wrote:
 Hi Sander,
 We're closing the ovirt 3.4 scope, and wondering if you're handling
 Zabbix based on [1].
 If so please let me know and I'll update the 3.4 features list.

 Thanks,
 Doron

 [1] http://lists.ovirt.org/pipermail/users/2013-November/017946.html
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


Re: [Users] API read-only access / roles

2013-11-21 Thread Doron Fediuck


- Original Message -
 From: Sander Grendelman san...@grendelman.com
 To: Doron Fediuck dfedi...@redhat.com
 Cc: users users@ovirt.org
 Sent: Thursday, November 21, 2013 10:52:26 AM
 Subject: Re: [Users] API read-only access / roles
 
 Hi Doron,
 
 The user I've defined in [1] works for me.
 A built-in login-/read-only role would be nice,
 but it's quite easy to define a custom role so
 more of a nice-to-have instead of a must-have.
 
 Thanks for asking!
 
 Sander.
 
 On Wed, Nov 20, 2013 at 5:40 PM, Doron Fediuck dfedi...@redhat.com wrote:
  Hi Sander,
  We're closing the ovirt 3.4 scope, and wondering if you're handling
  Zabbix based on [1].
  If so please let me know and I'll update the 3.4 features list.
 
  Thanks,
  Doron
 
  [1] http://lists.ovirt.org/pipermail/users/2013-November/017946.html
 

Thanks Sander,
other than that anything else needed for Zabbix monitoring?
Rene mentioned this in his request:

Zabbix monitoring
Monitoring the oVirt environment should work with my check_rhev3 plugin
by adding it as an external check to Zabbix. I'll test this and if it's
working I'll provide a short guide on how to do it.
Displaying data/triggers in oVirt isn't possible yet with my Monitoring
UI-plugin, but on the feature list (help is welcome)...

So I'm wondering what should be done in order to satisfy the request?
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


Re: [Users] API read-only access / roles

2013-11-21 Thread Koch (ovido)
On Tue, 2013-11-19 at 09:55 +0100, Sander Grendelman wrote:
 On Mon, Nov 18, 2013 at 5:18 PM, René Koch (ovido) r.k...@ovido.at wrote:
  Very nice - do you use my check_rhev3 Nagios plugin
  (https://github.com/ovido/check_rhev3) or are you working on
  your own script?
 
 At the moment: both. The problem with using Nagios scripts in Zabbix is that
 the trigger/alarm decision is made in different places. In Nagios this is done
 in the check scripts / on the client side while Zabbix mainly
 collects data and
 fires triggers if certain conditions in that data are met.

Yes that's true. Maybe adding a Zabbix compatibility mode for
check_rhev3 could also be an option where no decisions about the status
is done in the script so you can let Zabbix triggers handle this? Anyway
I think you're much more experienced with Zabbix then I am, so you
properly know better what's the best solution for monitoring oVirt with
Zabbix...

 
 New(er) Zabbix versions also have a feature called low level discovery that
 automatically creates items.
 
 It also seems that there is better RESTful/ovirt API support in python
 so I'm giving
 that a try too. Although perl is usually my poison of choice too ;)

Yes, the Python SDK is really good.
But as I'm more experienced with Perl I don't use it often...

 
  For this I've created a AdminLoginOnly role that only has
  System-Configure System-Login Permissions access.
 
  Is this the way to go for this king of configuration? Or is there
  a way to further minimize the permissions of this user?
 
  I create a custom role with these permissions for Nagios monitoring,
  too.
  I was thinking that in oVirt 3.3 there should be a predefined
  viewers-role, but can't find it in my setup :(
 
 OK, that would have been nice, do you have any history on this one?
 
  Another issue is that a Login event is generated every time
  the user connects through the API. This makes the Events
  pane less useful / readable. Is there a way to disable this for
  some users/roles?
 
 
  It depends if you have your own script or check_rhev3:
  - check_rhev3 1.2: use option -o
  - check_rhev3 1.3: you should not see any login information in this
  version anymore
  - custom script: see this page on information how to use the JSESSIONID
  cookie: http://www.ovirt.org/Features/RESTSessionManagement
 
 Thanks for the info I'll look into this.
 
 It does make the logic in the script a bit harder because you have to store
 the sessionid somewhere and check if the session is still valid.

I'm not sure if Session management works out of the box in Python SDK (I
think so), so maybe the Python SDK can be the best solution when
starting new scripts for Zabbix...


Regards,
René


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


[Users] API read-only access / roles

2013-11-20 Thread Doron Fediuck
Hi Sander,
We're closing the ovirt 3.4 scope, and wondering if you're handling
Zabbix based on [1].
If so please let me know and I'll update the 3.4 features list.

Thanks,
Doron

[1] http://lists.ovirt.org/pipermail/users/2013-November/017946.html
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


[Users] API read-only access / roles

2013-11-18 Thread Sander Grendelman
I'm working on (Zabbix) monitoring through the RESTful API.

Which role should I assign to the monitoring user?

The user only needs read access to the data but it looks like
I nead to assign at least an Admin role to the user to be
able to read data through the API.

For this I've created a AdminLoginOnly role that only has
System-Configure System-Login Permissions access.

Is this the way to go for this king of configuration? Or is there
a way to further minimize the permissions of this user?

Another issue is that a Login event is generated every time
the user connects through the API. This makes the Events
pane less useful / readable. Is there a way to disable this for
some users/roles?
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users


Re: [Users] API read-only access / roles

2013-11-18 Thread Koch (ovido)
On Mon, 2013-11-18 at 16:46 +0100, Sander Grendelman wrote:
 I'm working on (Zabbix) monitoring through the RESTful API.

Very nice - do you use my check_rhev3 Nagios plugin 
(https://github.com/ovido/check_rhev3) or are you working on 
your own script?

 
 Which role should I assign to the monitoring user?
 
 The user only needs read access to the data but it looks like
 I nead to assign at least an Admin role to the user to be
 able to read data through the API.
 
 For this I've created a AdminLoginOnly role that only has
 System-Configure System-Login Permissions access.
 
 Is this the way to go for this king of configuration? Or is there
 a way to further minimize the permissions of this user?

I create a custom role with these permissions for Nagios monitoring,
too.
I was thinking that in oVirt 3.3 there should be a predefined
viewers-role, but can't find it in my setup :(

 
 Another issue is that a Login event is generated every time
 the user connects through the API. This makes the Events
 pane less useful / readable. Is there a way to disable this for
 some users/roles?


It depends if you have your own script or check_rhev3:
- check_rhev3 1.2: use option -o
- check_rhev3 1.3: you should not see any login information in this
version anymore
- custom script: see this page on information how to use the JSESSIONID
cookie: http://www.ovirt.org/Features/RESTSessionManagement


Regards,
René


 ___
 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