oVirt

Author Archives: oVirt

oVirt SAML with keyloak using 389ds user federation

In this post I will introduce how simple it is to integrate SAML with oVirt using Keycloak and LDAP user federation.

Prerequisites: I assume you have already setup the 389ds directory server, but the solution is very similar for any other LDAP provider. As SAML is not integrated into oVirt directly, we use Apache to do the SAML authentication for us. The mod_auth_mellon module nicely covers all needed functionality.

mod_auth_mellon configuration

First we need to configure oVirt's apache. SSH to the oVirt engine and create a directory where we'll store all SAML related certificates.

ssh root@engine
yum install -y mod_auth_mellon
mkdir -p /etc/httpd/saml2

When we install the mod_auth_mellon package, it will create /etc/httpd/conf.d/auth_mellon.conf. We need to modify this file to our needs, as follows:

<Location />
    MellonEnable "info"
    MellonDecoder "none"
    MellonVariable "cookie"
    MellonSecureCookie On
    MellonSessionDump On
    MellonSamlResponseDump On
    MellonSessionLength 86400

    MellonUser "NAME_ID"
    MellonEndpointPath /saml2

    MellonSPCertFile /etc/httpd/saml2/ovirtsp-cert.cert
    MellonSPPrivateKeyFile /etc/httpd/saml2/ovirtsp-key.key
    MellonSPMetadataFile /etc/httpd/saml2/ovirtsp-metadata.xml
    MellonIdPMetadataFile /etc/httpd/saml2/idp-metadata.xml

    RewriteEngine On
    RewriteCond %{LA-U:REMOTE_USER} ^(.*)$
    RewriteRule ^(.*)$ - [L,NS,P,E=REMOTE_USER:%1]
    RequestHeader set X-Remote-User %{REMOTE_USER}s
</Location>

<LocationMatch ^/ovirt-engine/sso/(interactive-login-negotiate|oauth/token-http-auth)|^/ovirt-engine/api>
  <If "req('Authorization') !~ /^(Bearer| Continue reading

oVirt SAML with keyloak using 389ds user federation

In this post I will introduce how simple it is to integrate SAML with oVirt using Keycloak and LDAP user federation.

Prerequisites: I assume you have already setup the 389ds directory server, but the solution is very similar for any other LDAP provider. As SAML is not integrated into oVirt directly, we use Apache to do the SAML authentication for us. The mod_auth_mellon module nicely covers all needed functionality.

mod_auth_mellon configuration

First we need to configure oVirt's apache. SSH to the oVirt engine and create a directory where we'll store all SAML related certificates.

ssh root@engine
yum install -y mod_auth_mellon
mkdir -p /etc/httpd/saml2

When we install the mod_auth_mellon package, it will create /etc/httpd/conf.d/auth_mellon.conf. We need to modify this file to our needs, as follows:

<Location />
    MellonEnable "info"
    MellonDecoder "none"
    MellonVariable "cookie"
    MellonSecureCookie On
    MellonSessionDump On
    MellonSamlResponseDump On
    MellonSessionLength 86400

    MellonUser "NAME_ID"
    MellonEndpointPath /saml2

    MellonSPCertFile /etc/httpd/saml2/ovirtsp-cert.cert
    MellonSPPrivateKeyFile /etc/httpd/saml2/ovirtsp-key.key
    MellonSPMetadataFile /etc/httpd/saml2/ovirtsp-metadata.xml
    MellonIdPMetadataFile /etc/httpd/saml2/idp-metadata.xml

    RewriteEngine On
    RewriteCond %{LA-U:REMOTE_USER} ^(.*)$
    RewriteRule ^(.*)$ - [L,NS,P,E=REMOTE_USER:%1]
    RequestHeader set X-Remote-User %{REMOTE_USER}s
</Location>

<LocationMatch ^/ovirt-engine/sso/(interactive-login-negotiate|oauth/token-http-auth)|^/ovirt-engine/api>
  <If "req('Authorization') !~ /^(Bearer| Continue reading

Customizing the host deploy process

In 4.2 release we have introduced a possibility to customize the host-deploy process by running the Ansible post-tasks after the host-deploy process successfully finishes.

The reason

Prior to oVirt 4.2 release administrators could customize host's firewall rules using engine-config option IPTablesConfigSiteCustom. Unfortunately writing custom iptables rules into string value to be used in engine-config was very user unfriendly and using engine-config to provide custom firewalld rules would be even much worse. Because of above we have introduced Ansible integration as a part of host deploy flow, which allows administrators to add any custom actions executed on the host during host deploy flow.

Special tasks file

As part of this role we also include additional tasks, which could be written by the user, to modify the host-deploy process for example to open some more FirewallD ports.

Those additional tasks can be added to following file:

/etc/ovirt-engine/ansible/ovirt-host-deploy-post-tasks.yml

This post-task file is executed as part of host-deploy process just before setup network invocation.

Example

An example post-tasks file is provided by ovirt-engine installation, at following location:

/etc/ovirt-engine/ansible/ovirt-host-deploy-post-tasks.yml.example

This is just an example file, to add some task into host deploy flow, you need to create below mentioned file Continue reading

oVirt roles Ansible Galaxy integration

In 4.2 release we have splitted our oVirt Ansible roles into separate RPM packages and also separate git repositories, so it is possible for user to install specific role either from Ansible Galaxy or as RPM package.

The reason

The reason to split the roles into separate packages and git repositories was mainly the usage from the AWX/Ansible Tower. Since Ansible Galaxy is only integrated with github you need to store your Ansible role in single git repostiory in order to have separate Ansible role in Galaxy. Previously we used one single repository where we have stored all the roles, but because of that manual configuration was required to make those roles usable in AWX/Ansible Tower. So as you can see on image below we now have many roles in Ansible Galaxy under oVirt user:

oVirt roles in Ansible Galaxy

How to install the roles

There are still two ways how to install the roles: either using Ansible Galaxy or using RPM package available from oVirt repositories.

Ansible Galaxy

You are now able to install just a single role and not necessarily all of them at once like in previous versions For example to install just oVirt cluster upgrade role, you have to run Continue reading

oVirt roles Ansible Galaxy integration

In 4.2 release we have splitted our oVirt Ansible roles into separate RPM packages and also separate git repositories, so it is possible for user to install specific role either from Ansible Galaxy or as RPM package.

The reason

The reason to split the roles into separate packages and git repositories was mainly the usage from the AWX/Ansible Tower. Since Ansible Galaxy is only integrated with github you need to store your Ansible role in single git repostiory in order to have separate Ansible role in Galaxy. Previously we used one single repository where we have stored all the roles, but because of that manual configuration was required to make those roles usable in AWX/Ansible Tower. So as you can see on image below we now have many roles in Ansible Galaxy under oVirt user:

oVirt roles in Ansible Galaxy

How to install the roles

There are still two ways how to install the roles: either using Ansible Galaxy or using RPM package available from oVirt repositories.

Ansible Galaxy

You are now able to install just a single role and not necessarily all of them at once like in previous versions For example to install just oVirt cluster upgrade role, you have to run Continue reading

How to use oVirt Ansible roles

The recent post, An Introduction to Ansible Roles, discussed the new roles that were introduced in the oVirt 4.1.6 release. This follow-up post will explain how to set up and use Ansible roles, using either Ansible Galaxy or oVirt Ansible Roles RPM.

Ansible Galaxy

To make life easier, Ansible Galaxy stores multiple Ansible roles, including oVirt Ansible roles. To install the roles, perform the next steps:

To install roles on your local machine, run the following command:

$ ansible-galaxy install ovirt.ovirt-ansible-roles

This will install your roles into directory /etc/ansible/roles/ovirt.ovirt-ansible-roles/.

By default, Ansible only searches for roles in /etc/ansible/roles/ directory and your current working directory.

To change the directories where Ansible looks for roles, modify the roles_path option of [defaults] section in ansible.cfg configuration file.

The default location of this file is in /etc/ansible/ansible.cfg.

$ sed -i 's|#roles_path    = /etc/ansible/roles|roles_path = /etc/ansible/roles:/etc/ansible/roles/ovirt.ovirt-ansible-roles/roles|'  /etc/ansible/ansible.cfg

For more information on changing the directories where Ansible searches for roles, see the Ansible documentation pages.

Copy one of the examples from the directory /etc/ansible/roles/ovirt.ovirt-ansible-roles/examples/ into your working directory, then modify the needed variables and run the playbook.

oVirt Ansible Roles RPM

In the latest oVirt repositories Continue reading

Higher performance for oVirt Python SDK

Python SDK version 4.1.4 introduced support for sending asynchronous requests and HTTP pipelining.

This blog post explains those terms and will show you an example how to use the Python SDK in an asynchronous manner.

Asynchronous Requests

When using asynchronous requests, the client sends the request and defines a method (usually called callback), which should be called after the response is received but the client is not waiting for the response. In order for SDK to work in an asynchronous fashion, we introduced two new features to our SDK: multiple connections and HTTP pipelining.

These features provide significant value when the user wishes to fetch the inventory of the oVirt system. The time to fetch the inventory may be significantly decreased, too. A comparison of the synchronous and asynchronous requests folows.

Multiple Connections

Previously the SDK used only a single open connection that sequentially sent the requests according to user program and always waited for the server response for corresponding request.

In the new version of the SDK, the user can specify the number of connections the SDK should create to the server, and the specific requests created by user program uses those connections in parallel.

HTTP Continue reading