IM Web Interface
The IM Web client is a graphical interface to access the XML-RPC or REST APIs of IM Server.
IM web interface is based on PHP, so a web server (e.g. Apache) with PHP support must be installed.
Also the mcrypt PHP modules must be installed and enabled.
It is also required to install the PHP module to access SQLite databases.
In case of using the REST API it is also required to install the CURL PHP module.
Select a proper path in the document root of the web server to install the IM web interface (i.e. /var/www/im):
$ tar xvzf IM-web-X.XX.tar.gz
$ mv IM-X.XX /var/www/im
$ chown -R www-data /var/www/im
The web interface reads the configuration from
$IM_WEB_PATH/config.php. It has
the following variables:
A Docker image named grycap/im-web has been created to make easier the deployment of an IM web GUI using the default configuration. Information about this image can be found here: https://registry.hub.docker.com/u/grycap/im-web/.
This container is prepaired to work linked with the IM service container grycap/im, in this way:
First launch the IM service specifying the name “im”:
sudo docker run -d -p 8899:8899 --name im grycap/im
Then launch the im-web container linking to the im:
sudo docker run -d -p 80:80 --name im-web --link im:im grycap/im-web
It also supports environment variables to set the IM service location:
im_use_rest: Uses the REST API instead of the XML-RPC that is the default one. Default value “false”.
im_use_ssl: Uses HTTPS to connect with the REST or XML-RPC APIs. Default value “false”.
im_host: Hostname of the IM service. Default value “im”.
im_port: Port of the IM service. Default value “8899”.
im_db: Location of the D.B. file used in the web application to store data. Default value “/home/www-data/im.db”.
openid_issuer: OpenID Issuer supported use “” to disable OpenID support.
openid_name: OpenID Issuer name.
client_id: OpenID Client data.
client_secret: OpenID Client secret.
redirect_uri: OpenID Redirect URI.
cred_crypt_key: Key to crypt the credentials data. It must be 32 chars long.
docker run -p 80:80 -e "im_use_rest=true" -e "im_host=server.domain" -e "im_port=8800" -d grycap/im-web
There is also a version SSL enabled. In this case the docker image have a selfsigned certificate for testing purposes. Add your own in the docker command:
docker run -p 80:80 -p 443:443 -v server.crt:/etc/ssl/certs/server.crt -v server.key:/etc/ssl/certs/server.key -d grycap/im-web:1.5.5-ssl
Then you can access the IM Web portal in the following URL: http://localhost/im-web/.
The web interface of the IM enables the user to manage all the aspects related with the management of the life-cycle of his virtual infrastructures.
To access the Web interface the user must register first to the application. Each user must include a username and a password to access the platform. From 1.5.6 version OpenID authentication has been added.
The first step is to manage the user credentials to access all the components of the platform, specially the Cloud providers. Fig. 2 shows a list of user credentials. In this list there are two related with the IM components:
InfrastructureManager: user and password to access the IM service.
VMRC: user, password and URL to access the VMRC service
When a new user is registered (or access with OpenID credentials) the web UI automatically creates credentials to both of them to make easier the creation of credentials process. The rest of elements of this list are the user credentials to access diferent Cloud providers.
Fig. 3 shows the form to add or edit the user credentials. Initially the user must select the credentials type using the selectors with the corresponding images type. Then the specific form for the Cloud provider selected will be shown, where the user must fill the needed fields.
The RADL section enables the management and share RADL documents with other users of the platform. Fig. 4 shows the list of RADLs available for an specific user. From the list the user can manage the RADLs and also launch the infrastructure described in the RADL with a single click with the launch button.
The user can add or edit an RADL document (if the they have the correct permissions). In this case the platform will show the RADL document form (Fig. 6). In the top of the form the user can edit the RADL document that describes the infrastructure to be launched. In the botton he can manage the access permissions to the document to users of an specific group (Permission_Group) or to all the platform users (Permission_Other). It uses a similar schema of linux file systems. The user can give other users access to read (r), modify (w) or launch (x) the RADL document.
The Infrastructures section enables the management of the infrastructures owned by the current user
available in the IM service. The list (Fig. 7) shows a row for each infrastructure.
The user can access the information about each VM of the infrastructure clicking in the ID of desired VM.
He can also click in the message
Show of the column
Cont. Message to check the contextualization
log as shown in Fig. 9. In case of failure of the contextualization process
Reconfigure button will be available enbling the user to invoke the ctxt. step again.
The user can also delete the whole infrastructure or add new resources using the buttons of the next columns.
When adding new resources the form show in Fig. 9 will appear.
In this form the user will specify the RADL to add resources to the infrastructure.
In the VM information page (Fig. 8) the user can see all the information about the VM. In the top of the page the state, the cloud provider where it is deployed and the available IPs are shown. The rest of RADL fields are shown below. In this section the user can look up for the credentials needed to access the VM (username, password or private_key). In case of the private_key a “download” button will appear enabling the user to download the key to a file to acccess the node. The contextualizacion message of this VM will be show if the user press the message “Show >>” of the row “Cont. Message”. The user can also stop, start and destroy the VM using the buttons located at the bottom of the page.
The Recipes section enables the management of a set of recipes to make easy the installation of certain applications to non advanced users. This feature is only enabled in case that the IM service recipes database is available to the web interface (see Configuration). Only Admin users can manage recipes. “Standard” users can only see the recipes and use it in their RADL documents adding application requirements like the following:
disk.0.applications contains (name='<application_name>' [and version='<application_version>'])
Fig. 12 shows the form to edit the recipe properties. The Admin user has to specify:
Name and version: Name a version of the application to be identified in the RADL document.
Description: A text to describe the recipe
Module: A module enable to group similar recipes in modules.
Galaxy Module: If the recipe need to download an Ansible Galaxy module it must be specified here, otherwise leave it blank.
Recipe: The steps in Ansible language to install the application.
Requirements: Some hardware requirements of the application. It will me merged with the RADL document where the application is included.
In the Admin section, users with administrator permissions can manage users and groups of the web interface. Figures 13 and 14 shows the pages to manage users. The Admin user can assign groups to users and set the flag of “administrator”.