|
|
| Line 1: |
Line 1: |
| {{TOC_right}}
| | This page is no longer maintained. See [[MAN10#Integrating_OpenNebula]]. |
| | |
| = Introduction =
| |
| | |
| [http://occi-wg.org/ OCCI] (the [http://occi-wg.org/ Open Cloud Computing Interface]) is a standard by the [http://www.ogf.org/ Open Grid Forum], specifying a protocol and API to perform various remote management tasks in clouds. The rOCCI-server extends cloud managers, which are not OCCI-compliant natively, with its own OCCI interface. It is based on the rOCCI (Ruby OCCI) Framework.
| |
| | |
| == Architecture ==
| |
| | |
| In a typical installation, shown in Figure 1, the rOCCI-server is accessed through the Apache HTTP Server. Since the OpenNebula backend is the flagship of rOCCI-server backend development, you will typically find it paired with the OpenNebula Cloud Manager.
| |
| | |
| {| border="2" style="border-collapse:collapse" cellpadding="5" width="800"
| |
| |[[File:ROCCI-server-ecosystem.png|alt=rOCCI-server in a typical setup|400px]]<BR>
| |
| '''Fig. 1:''' rOCCI-server in a typical setup with OpenNebula
| |
| |The following differences from Figure 1, which shows a typical set-up as envisioned by rOCCI-server developers, may appear in production if the site so prefers:
| |
| # The HTTP server and the Cloud Manager may be located on '''separate machines'''. In that case, the rOCCI-server is installed with the HTTP server.
| |
| # A '''different HTTP server''' can be used. [http://nginx.org/ NGiNX] is explicitly supported (including passenger). However, Apache is recommended as it provides SSL.
| |
| # A '''different cloud manager''' can be used. This requires a corresponding backend. Note that at the time of this writing (Autumn 2014) only an OpenNebula and an EC2 backend are available, but several others are in preparation. Consult the [[ROCCI-server Backend development status | Backend Development Status]] page for more information.
| |
| |}
| |
| | |
| For reference, you may also see Figure 2, showing the essentials of rOCCI-server's internal structure. Understanding the architecture at that depth is not necessary for administration, but can be useful in case troubleshooting is required.
| |
| | |
| {| border="2" style="border-collapse:collapse" cellpadding="5" width="800"
| |
| |[[File:rOCCI-server-Internals_500.png|alt=rOCCI-server Internals|500px]]<BR>
| |
| '''Fig. 2:''' rOCCI-server Internals
| |
| | The tasks of the individual components are mostly obvious. Still here are a few notes to clarify
| |
| * '''Rack middleware''' components wrap around the core of the application to act upon / augment the passing request and response data.
| |
| * In the '''MVC setup''' (Model / View / Controller), the Model is used to access CMF rather than traditional data storage, but apart from that, it acts similarly to other applications.
| |
| * Methods provided by the '''Backend APIs''' map 1:1 on requests defined by the OCCI standard, which simplifies the model greatly.
| |
| |}
| |
| | |
| === Deployment Scenarios ===
| |
| | |
| The rOCCI-server was designed with 1:1 deployment in mind, i.e., one rOCCI-server instance per cloud manager. It is also possible to use multiple rOCCI-server instances to access a single cloud manager. However, it is '''impossible''' to use a single rOCCI-server to access multiple cloud managers, even should they all be running the same application – see Figure 3.
| |
| | |
| |[[File:rOCCI-multiples_800.png|alt=Supported deployment scenarios|Supported / unsupported deployment scenarios]]<BR>
| |
| '''Fig. 3:''' Supported / unsupported deployment scenarios
| |
| | |
| Unless there is specific reason to do otherwise, install rOCCI-server instances with your cloud managers 1:1. Collocation is mildly recommended, but by no means necessary. Please note that while Fig. 3 shows OpenNebula servers, the deployment scenarios are currently the same for all [[ROCCI-server Backend development status | existing backends]].
| |
| | |
| = Installation and Configuration =
| |
| | |
| rOCCI-server installation consists of two discrete steps—[[#Installing rOCCI-server|installing the server]] and [[#configuring backends|choosing/configuring the backend]] to use, followed by [[#configuring access|setting up user access]].
| |
| | |
| '''Be aware that command-line instructions are given separately for APT-based and YUM-based distributions. You may need to use the horizontal scrollbar to view the right YUM column in most cases.'''
| |
| | |
| ''Note that the instructions are prepared in such a way that they may be copied & pasted into your command line. However, make sure that you are copying the commands in their entirety. Forgotten newlines (enters) are especially easy to overlook and difficult to debug.''
| |
| | |
| == Installing rOCCI-server ==
| |
| | |
| You can install release versions [[#from repository|from repositories]] if packages are available for your distribution, or install any release or development version [[#from source|from source]].
| |
| | |
| === Prerequisites ===
| |
| | |
| Regardless of the installation method or source, rOCCI-server requires certain preparation before you can run it, or even install it.
| |
| <OL>
| |
| <LI>Make sure the '''host certificate and key''' are already in place where <code>mod_ssl</code> expects them and that the certificate will be readable to the <code>apache</code> account (or whatever service account you are using) once you install the Web Server! Examples used throughout this Guide expect certificates in <code>/etc/grid-security</code>.</LI>
| |
| <LI>Make sure '''CA certificates''' are installed. For the context of EGI Federated Cloud, the [https://wiki.egi.eu/wiki/EGI_IGTF_Release EGI IGTF Release] is most relevant.</LI>
| |
| </OL>
| |
| Once these conditions are satisfied, you may proceed with the installation.
| |
| | |
| === From Repository ===
| |
| | |
| Multiple repositories for cloud federation and interoperability choose to include rOCCI. The literal examples bellow use EGI's AppDB repository but you may simply pick another one and replace repository URLs when downloading repo files.
| |
| | |
| The various repository providers are:
| |
| | |
| * '''EGI AppDB'''
| |
| ** https://appdb.egi.eu/store/software/rocci.server/releases/1.1.x/
| |
| * '''EGI CMD'''
| |
| ** TBA
| |
| * '''INDIGO-DataCloud Midnight Blue'''
| |
| ** http://repo.indigo-datacloud.eu/#one
| |
| | |
| ''Be sure to report issues, and come back here for updates on repository location.''
| |
| | |
| {| border="2" style="border-collapse:collapse" cellpadding="5" width="90%"
| |
| ! width="50%" | APT-based distributions (Debian, Ubuntu, …)
| |
| ! RPM-based distributions (Scientific Linux, CentOS, …)
| |
| |-
| |
| |
| |
| <font color="lightgray">#</font>Add rOCCI-server repository at the EGI AppDB, then install the rOCCI-server:
| |
| apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys 561F9B9CAC40B2F7
| |
| apt-get install -y apt-transport-https ca-certificates curl wget
| |
| echo "deb https://oss-binaries.phusionpassenger.com/apt/passenger wheezy main" > /etc/apt/sources.list.d/passenger.list
| |
| | |
| apt-key adv --fetch-keys http://repository.egi.eu/community/keys/APPDBCOMM-DEB-PGP-KEY.asc
| |
| curl --fail -sSLo /etc/apt/sources.list.d/rocci-server.list http://repository.egi.eu/community/software/rocci.server/1.1.x/releases/repofiles/debian-wheezy-amd64.list
| |
| apt-get update
| |
| apt-get install -y occi-server
| |
| <font color="lightgray">#</font>Unless already configured, make Apache listen on port 11443
| |
| if ( ! grep "Listen\s*11443" /etc/apache2/ports.conf); then echo Listen 11443 >> /etc/apache2/ports.conf; fi
| |
| <font color="lightgray">#</font>Enable required modules and the <code>occi-ssl</code> Virtual Host, and reload Apache configuration:
| |
| a2enmod ssl
| |
| a2enmod passenger
| |
| a2enmod mod-security # or 'security2' for Ubuntu
| |
| a2ensite occi-ssl
| |
| service apache2 restart
| |
| |
| |
| <font color="lightgray">#</font>Enable EPEL and add rOCCI-server repository, then install rOCCI-server.
| |
| yum install -y epel-release yum-utils
| |
| yum-config-manager --enable epel
| |
| yum install -y pygpgme curl wget
| |
| curl --fail -sSLo /etc/yum.repos.d/passenger.repo https://oss-binaries.phusionpassenger.com/yum/definitions/el-passenger.repo
| |
| | |
| curl --fail -sSLo /etc/yum.repos.d/rocci-server.repo http://repository.egi.eu/community/software/rocci.server/1.1.x/releases/repofiles/sl-6-x86_64.repo
| |
| yum install -y occi-server
| |
| <font color="lightgray">#</font>Make sure Apache listens on selected port (11443 by default). Bear in mind that multiple <code>Listen</code> attributes with the same port number will cause conflicts. Only do this if the port is not yet open.
| |
| if ( ! grep "Listen\s*11443" /etc/httpd/conf/httpd.conf); then \
| |
| echo Listen 11443 >> /etc/httpd/conf/httpd.conf; fi
| |
| <font color="lightgray">#</font>At this point you need to deal with SELinux. Although disabling it altogether is not recommended, it was the only way the authors were demonstrably able to make rOCCI-server accessible. Contributions are welcome.
| |
| sed -i 's/SELINUX\s*=\s*enforcing/SELINUX=permissive/' /etc/selinux/config
| |
| setenforce 0
| |
| <font color="lightgray">#</font>Make sure required modules <code>ssl</code>, <code>mod-security</code> and <code>passenger</code> are enabled and the <code>occi-ssl</code> Virtual Host is in place, then (re)start Apache.
| |
| service httpd restart
| |
| service memcached restart
| |
| |-
| |
| |''Tested in Debian 7 Wheezy''
| |
| |''Tested in SL 6.5 Carbon''
| |
| |}
| |
| | |
| You are now ready to continue by [[#Configuring_Backends|configuring your backend]].
| |
| | |
| === From Source ===
| |
| | |
| ''Note: These instructions are given for the 1.1.x branch (STABLE).''
| |
| | |
| <OL>
| |
| <LI>Make sure '''Ruby version at least 1.9.3''' is available to you – either already installed, or present in the repository.<BR>''Tip for SL6: rOCCI-server packages available from [https://appdb.egi.eu/store/software/rocci.server the EGI AppDB] contain an embedded Ruby 1.9.3, consider installing [[#From_Repository | From Repository]]''
| |
| </LI>
| |
| <LI>Install system prerequisites:
| |
| {| border="2" style="border-collapse:collapse" cellpadding="5" width="100%"
| |
| ! width="50%" | APT-based distributions (Debian, Ubuntu, …)
| |
| ! RPM-based distributions (Scientific Linux, CentOS, …)
| |
| |-
| |
| |
| |
| apt-get update
| |
| apt-get install -y git ruby-dev libssl-dev memcached
| |
| |
| |
| yum install -y git openssl-devel memcached
| |
| |-
| |
| |''Tested in Debian 7 Wheezy''
| |
| |''Tested in SL 6.5 Carbon''
| |
| |}
| |
| </LI>
| |
| <LI>If you plan to access rOCCI-server through Passenger/apache (recommended), continue by installing and configuring the Apache Web Server.
| |
| {| border="2" style="border-collapse:collapse" cellpadding="5" width="100%"
| |
| ! width="50%" | APT-based distributions (Debian, Ubuntu, …)
| |
| ! RPM-based distributions (Scientific Linux, CentOS, …)
| |
| |-
| |
| |
| |
| apt-get install -y libcurl4-openssl-dev \
| |
| apache2-mpm-worker libapr1-dev \
| |
| libaprutil1-dev apache2-prefork-dev \
| |
| build-essential libapache2-modsecurity
| |
| |
| |
| yum install -y gcc-c++ curl-devel httpd \
| |
| httpd-devel apr-devel apr-util-devel mod_ssl \
| |
| policycoreutils-python mod_security
| |
| |-
| |
| |''Tested in Debian 7 Wheezy''
| |
| |''Tested in SL 6.5 Carbon''
| |
| |}
| |
| ''Note: You do not need to restart Apache at this point. There will be another configuration change in the final step.''
| |
| </LI>
| |
| <LI>Install Ruby-specific prerequisites. '''Be sure'' to install them as gems rather than repository packages!
| |
| {| border="0" style="border-collapse:collapse" cellpadding="0" width="100%"
| |
| |
| |
| gem install bundler
| |
| |}
| |
| </LI>
| |
| <LI>Create <code>rocci</code> service account, create installation directory and change identity:
| |
| {| border="2" style="border-collapse:collapse" cellpadding="5" width="100%"
| |
| ! width="50%" | APT-based distributions (Debian, Ubuntu, …)
| |
| ! RPM-based distributions (Scientific Linux, CentOS, …)
| |
| |-
| |
| |
| |
| mkdir /var/lib/rocci
| |
| adduser --system --disabled-password --group \
| |
| --shell /bin/sh --home /var/lib/rocci rocci
| |
| mkdir -p /opt/rOCCI-server
| |
| |
| |
| mkdir /var/lib/rocci
| |
| adduser --system --shell /bin/sh --home /var/lib/rocci rocci
| |
| mkdir -p /opt/rOCCI-server
| |
| |-
| |
| |''Tested in Debian 7 Wheezy''
| |
| |''Tested in SL 6.5 Carbon''
| |
| |}
| |
| </LI>
| |
| <LI>Clone code from GitHub. Make sure you are using the ''1.1.x'' branch:
| |
| {| border="0" style="border-collapse:collapse" cellpadding="0" width="100%"
| |
| |
| |
| git clone https://github.com/EGI-FCTF/rOCCI-server.git /opt/rOCCI-server
| |
| cd /opt/rOCCI-server
| |
| git checkout 1.1.x
| |
| chown -R rocci:rocci /opt/rOCCI-server
| |
| |}
| |
| </LI>
| |
| <LI>Create links to system directories (as ''root''):
| |
| {| border="0" style="border-collapse:collapse" cellpadding="0" width="100%"
| |
| |
| |
| ln -sf /opt/rOCCI-server/log /var/log/rocci-server
| |
| ln -sf /opt/rOCCI-server/etc /etc/rocci-server
| |
| |}
| |
| </LI>
| |
| <LI>Install Ruby dependencies and the Passenger Apache module.
| |
| {| border="0" style="border-collapse:collapse" cellpadding="0" width="100%"
| |
| |
| |
| bundle install --deployment --without development test
| |
| bundle exec passenger-install-apache2-module --auto
| |
| bundle exec passenger-install-apache2-module --snippet > passenger.load
| |
| |}
| |
| </LI>
| |
| <LI>Finalize Web Server configuration as <code>root</code> and restart. This step relies on example config files, which may be modified to your needs. Consult the maintenance section for more. Whatever you do, make sure the ''VirtualHost'' config file is '''not publicly readable''' as it typically contains passwords (the <code>chmod</code> snippet bellow takes care of that, for instance).
| |
| {| border="2" style="border-collapse:collapse" cellpadding="5" width="100%"
| |
| ! width="50%" | APT-based distributions (Debian, Ubuntu, …)
| |
| ! RPM-based distributions (Scientific Linux, CentOS, …)
| |
| |-
| |
| |
| |
| <!-- if [ "$(whoami)" = "rocci" ]; then exit; fi-->
| |
| cp /opt/rOCCI-server/examples/etc/apache2/sites-available/occi-ssl \
| |
| /etc/apache2/sites-available/occi-ssl.conf
| |
| chmod o-rwx /etc/apache2/sites-available/occi-ssl.conf
| |
| echo Listen 11443 >> /etc/apache2/ports.conf
| |
| cp /opt/rOCCI-server/examples/etc/apache2/conf.d/security \
| |
| /etc/apache2/conf.d/
| |
| cp /opt/rOCCI-server/passenger.load /etc/apache2/mods-available/
| |
|
| |
| a2enmod passenger
| |
| a2enmod ssl
| |
| a2enmod mod-security
| |
| a2ensite occi-ssl
| |
| service apache2 restart
| |
| |
| |
| <!-- if [ "$(whoami)" = "rocci" ]; then exit; fi-->
| |
| cp /opt/rOCCI-server/examples/etc/apache2/sites-available/occi-ssl \
| |
| /etc/httpd/conf.d/occi-ssl.conf
| |
| chmod o-rwx /etc/httpd/conf.d/occi-ssl.conf
| |
| echo Listen 11443 >> /etc/httpd/conf/httpd.conf
| |
| cp /opt/rOCCI-server/examples/etc/apache2/conf.d/security \
| |
| /etc/httpd/conf.d/
| |
| cp /opt/rOCCI-server/passenger.load /etc/httpd/conf.d/passenger.conf
| |
| At this point you need to deal with SELinux. Although disabling it altogether is not recommended, it was the only way the authors were demonstrably able to make rOCCI-server accessible. Contributions are welcome.
| |
| <!--
| |
| # Allow passenger in SELinux
| |
| chcon -R -h -t httpd_sys_script_exec_t $(head -n 1 /etc/httpd/conf.d/passenger.conf | awk '{ print $3 }')
| |
| # Allow port 11443 in SELinux
| |
| semanage port -a -t http_port_t -p tcp 11443
| |
| # Temporarily:
| |
| chcon -R -h -t httpd_sys_script_exec_t /opt/rOCCI-server/vendor/bundle/ruby/1.9.1/gems/passenger-4.0.29/buildout/agents/PassengerHelperAgent
| |
| -->
| |
| service httpd restart
| |
| service memcached restart
| |
| |-
| |
| |''Tested in Debian 7 Wheezy''
| |
| |''Tested in SL 6.5 Carbon''
| |
| |}
| |
| </OL>
| |
| | |
| == Configuring Backends ==
| |
| | |
| rOCCI-server comes bundled with supported backends. In case you have followed this guide to install the rOCCI-sever, you will find backend configuration in Apache2 Virtual Host configuration file. Currently (Spring 2014) there are two backends bundled: [[#OpenNebula Backend | ''OpenNebula'']] and the [[#Dummy Backend | ''Dummy'']] backend. An [[#EC2 Backend | ''EC2'']] backend is also available but requires installation of additional dependencies. Follow the instructions below to install a backend of your choice.
| |
| | |
| Note that unless you plan to use the ''Dummy'' backend only, '''your cloud manager should already be installed at this point.'''
| |
| | |
| Then go straight to the right section for the backend of your choice:
| |
| * [[#OpenNebula Backend | ''OpenNebula'']]
| |
| * [[#EC2 Backend | ''EC2'']]
| |
| * [[#Dummy Backend | ''Dummy'']]
| |
| | |
| ''Note: For the implementation status of other backends available for the {{rOCCI:rOCCI logo}} framework, see [[ROCCI-server Backend development status]].
| |
| | |
| === OpenNebula Backend ===
| |
| | |
| {{OpenNebula Backend}}
| |
| | |
| Once you are done configuring the OpenNebula backend, you may [[#Smoke Tests | proceed to Smoke Tests]].
| |
| | |
| === EC2 Backend ===
| |
| | |
| {{rOCCI:EC2_Backend}}
| |
| | |
| Once you are done configuring the EC2 backend, you may [[#Smoke Tests | proceed to Smoke Tests]].
| |
| | |
| === Dummy Backend ===
| |
| | |
| The Dummy backend is intended for testing purposes only. It is enabled by default, but you still need to make a few adjustments to use it. Edit file <code>/etc/apache2/sites-available/occi-ssl</code> or <code>/etc/httpd/conf.d/occi-ssl.conf</code>, respectively.
| |
| <OL>
| |
| <LI>Server name attributes must be set to the rOCCI server's ''fully qualified domain name''. Set <code>ROCCI_SERVER_HOSTNAME</code> and <code>ServerName</code> accordingly:
| |
| {| border="0" style="border-collapse:collapse" cellpadding="0" width="100%"
| |
| |
| |
| ServerName rocci-server.example.com
| |
| |}
| |
| and
| |
| {| border="0" style="border-collapse:collapse" cellpadding="0" width="100%"
| |
| |
| |
| SetEnv ROCCI_SERVER_HOSTNAME rocci-server.example.com
| |
| |}
| |
| </LI>
| |
| <LI>If you have been using a different backend previously, and wish to revert to ''dummy'', change attribute <code>ROCCI_SERVER_BACKEND</code> to <code>dummy</code> as shown:
| |
| {| border="0" style="border-collapse:collapse" cellpadding="0" width="100%"
| |
| |
| |
| SetEnv ROCCI_SERVER_BACKEND dummy
| |
| |}
| |
| </LI>
| |
| <LI>Reload WebServer configuration:
| |
| {| border="2" style="border-collapse:collapse" cellpadding="5" width="100%"
| |
| ! width="50%" | APT-based distributions (Debian, Ubuntu, …)
| |
| ! RPM-based distributions (Scientific Linux, CentOS, …)
| |
| |-
| |
| |
| |
| service apache2 reload
| |
| |
| |
| service httpd reload
| |
| |-
| |
| |''Tested in Debian 7 Wheezy''
| |
| |''Tested in SL 6.5 Carbon''
| |
| |}
| |
| </LI>
| |
| </OL>
| |
| | |
| == Configuring Access ==
| |
| | |
| With your OCCI chain in place, you need to decide on maintaining user identities on the Cloud Manager side, and on the methods of authentication your users will be allowed/required to use.
| |
| | |
| === Maintaining User Identities ===
| |
| | |
| rOCCI-server itself provides only pass-through authentication, i.e., it neither stores nor checks user identities, but rather accepts your authentication information, augments it if necessary, depending on your strategy of choice, and passes it along to the cloud manager for the final authentication decision. This means that you need to maintain user identities within your Cloud Manager, e.g., Open Nebula.
| |
| | |
| ==== Basic Methods ====
| |
| | |
| Basically, there are three ways of maintaining user identities, at least considering an rOCCI-server in combination with OpenNebula:
| |
| {| border="2" style="border-collapse:collapse" cellpadding="5" width="800px"
| |
| ! width="100px" | Manual
| |
| | you maintain user accounts manually, incl. setting all details and choosing authentication drivers for each account. To do that use your Cloud Manager's built-in user management tools, e.g., the <code>oneuser</code> utility for OpenNebula.
| |
| |-
| |
| ! Perun
| |
| | EGI Federated Cloud and other infrastructures use [https://github.com/EGI-FCTF/fctf-perun Perun] to maintain user accounts. If you are an EGI member, you should use it. If not, you are welcome to consider it.
| |
| |-
| |
| ! Autocreation
| |
| | rOCCI-server provides a facility to automatically create accounts for newly arriving users. This does not necessarily mean that everybody will be allowed access; there is a validation layer that allows you to set policies that allow only users with certificates, users from given VOs, with given roles, etc. However, using autocreation is generally not advisable as it can only create accounts. There is no automated way to block, delete accounts, etc.<BR>''Note: Autocreation is currently supported only in the OpenNebula backend through the [[#The Autocreate Authentication Hook|Autocreate Authentication Hook]]. Also, only VO membership-based autocreation policy is currently supported.''
| |
| |}
| |
| | |
| ==== Authentication Drivers in OpenNebula ====
| |
| | |
| OpenNebula Supports two kinds of authentication drivers for general users:
| |
| | |
| {| border="2" style="border-collapse:collapse" cellpadding="5" width="800px"
| |
| ! width="100px" | <code>core</code><BR>
| |
| |''(default)'' The user will be using a user name and password to authenticate. Both are maintained in OpenNebula.
| |
| |-
| |
| ! <code>x509</code>
| |
| |The user will be using a certificate or proxy certificate to authenticate, possibly with VOMS extensions. OpenNebula stores the user's DN together with VOMS extensions, if provided.<BR>
| |
| ''Note: Your certificate/proxy must contain the same extensions every time you connect. Otherwise you won't be recognized as the same user and authentication will fail. On the other hand, you can possess multiple accounts mapped to the same DN but distinguished by VO.''
| |
| |}
| |
| | |
| === Choosing Authentication Strategies ===
| |
| | |
| rOCCI-server supports multiple authentication strategies. You can decide which ones will be used in your deployment, and in what order they will be attempted when a user tries to connect.
| |
| | |
| ==== Essential Settings ====
| |
| | |
| Authentication strategies are set using the <code>ROCCI_SERVER_AUTHN_STRATEGIES</code> attribute in the Virtual Host configuration file <code>/etc/apache2/sites-available/occi-ssl</code> or <code>/etc/httpd/conf.d/occi-ssl.conf</code>, respectively. For instance the following line selects three strategies, which will be attempted left-to-right:
| |
| SetEnv ROCCI_SERVER_AUTHN_STRATEGIES "voms x509 basic"
| |
| An authentication attempt for each strategy can have three outcomes:
| |
| {| border="2" style="border-collapse:collapse" cellpadding="5" width="800px"
| |
| ! width="100px" | Success
| |
| |User is authenticated, authentication finished.
| |
| |-
| |
| !Failure
| |
| |Authentication details required by the given strategy were valid, but authentication failed. For instance, username and password ''were'' available for the <code>basic</code> strategy but it still failed. In that case authentication fails and no other strategy is attempted.
| |
| |-
| |
| !Invalidity
| |
| |Authentication strategy failed due to auth. details being invalid. For instance, the <code>basic</code> strategy failed but there was no user name and password supplied in the first place. In that case authentication continues with the next strategy.
| |
| |}
| |
| | |
| The following authentication strategies are currently supported by the rOCCI-server:
| |
| | |
| {| border="2" style="border-collapse:collapse" cellpadding="5" width="800px"
| |
| ! width="100px" | <code>basic</code>
| |
| | Basic name/password authentication
| |
| |-
| |
| ! <code>x509</code>
| |
| | Authentication based on x509 certificates
| |
| |-
| |
| ! <code>voms</code>
| |
| | Authentication based on x509 certificate proxies with VOMS extensions
| |
| |-
| |
| ! <code>dummy</code>
| |
| | For testing only, authentication based on arbitrary, locally specified rules
| |
| |}
| |
| | |
| ==== Fine-Tuning Authentication Strategy Settings ====
| |
| | |
| Specific behaviour of authN strategies is controlled trhough settings in strategy configuration files:
| |
| /opt/rOCCI-server/etc/authn_strategies/*/production.yml
| |
| Caution is recommended. Use for inspiration rather than modification.
| |
| | |
| <!--
| |
| Co autentizační modul umí se pozná v konfigurácích: https://github.com/arax/rOCCI-server/blob/master/etc/authn_strategies/voms/production.yml
| |
| https://github.com/arax/rOCCI-server/blob/master/etc/authn_strategies/keystone/production.yml
| |
| -->
| |
| | |
| == Using Configuration Management ==
| |
| | |
| rOCCI-server configuration can be maintained through popular configuration management tools such as Puppet, Ansible or Chef. Configuration is not done through a separate module, but rather through setting appropriate environmental variables in respective Apache modules, which are widely available for all those configuration managers.
| |
| | |
| An example Puppet manifest is included with other examples in the rOCCI code base: [https://github.com/EGI-FCTF/rOCCI-server/blob/master/examples/etc/puppet/manifests/site.pp <code>examples/etc/puppet/manifests/site.pp</code>].
| |
| | |
| = Maintenance =
| |
| | |
| == Updates from Repository ==
| |
| | |
| {| border="2" style="border-collapse:collapse" cellpadding="5" width="100%"
| |
| ! width="50%" | APT-based distributions (Debian, Ubuntu, …)
| |
| ! RPM-based distributions (Scientific Linux, CentOS, …)
| |
| |-
| |
| |
| |
| ''Simply update all packages and restart Apache2. There are no special instructions.''
| |
| |
| |
| ''Update all packages and manually update native binaries for Phusion Passenger (instructions below).''
| |
| | |
| /opt/occi-server/embedded/bin/passenger-install-apache2-module --auto --languages ruby
| |
| /opt/occi-server/embedded/bin/passenger-install-apache2-module --snippet \
| |
| > /etc/httpd/conf.d/passenger.conf
| |
| |-
| |
| |''Tested in Debian 7 Wheezy''
| |
| |''Tested in SL 6.5 Carbon''
| |
| |}
| |
| | |
| == Updates from Source ==
| |
| | |
| In case you have installed rOCCI-server from source, you can also obtain updates that way. To update, do the following:
| |
| cd /opt/rOCCI-server
| |
| git pull
| |
| bundle install --deployment
| |
| | |
| == Changing Default Configuration ==
| |
| | |
| === Changing Default Listener Port ===
| |
| | |
| You may make rOCCI-server listen on a port different than the default 11443. The port is set in two different files and three different locations:
| |
| # <code>/etc/apache2/ports.conf</code>, using the <code>Listen</code> directive
| |
| # <code>/etc/apache2/sites-available/occi-ssl</code> in the <code>VirtualHost</code> tag
| |
| # <code>/etc/apache2/sites-available/occi-ssl</code>, the <code>ROCCI_SERVER_PORT</code> attribute
| |
| # Provided you plan to run multiple instances of rOCCI-server in one machine, then, also in <code>/etc/apache2/sites-available/occi-ssl</code>, the <code>ROCCI_SERVER_LOG_DIR</code> attribute, where it is recommended to add the given instance's port as a postfix to the log dir name for differentiation.
| |
| Choose whichever port you want, but keep the setting aligned across all three locations. After changing port settings in all places, restart the WebServer with
| |
| service apache2 restart
| |
| | |
| = Testing =
| |
| | |
| == Smoke Tests ==
| |
| | |
| There are simple tests you can perform to check you have installed rOCCI-server correctly.
| |
| | |
| === Basic Authentication ===
| |
| <OL>
| |
| <LI>You need an account in the Cloud Management Platform. Either use your existing one, or create a test account:
| |
| <UL>
| |
| <LI>'''OpenNebula''':
| |
| Create a test account in OpenNebula:
| |
| {| border="0" style="border-collapse:collapse" cellpadding="0" width="100%"
| |
| |
| |
| su - oneadmin
| |
| oneuser create roccitest '<actual_password_edited_out>'
| |
| exit
| |
| |}
| |
| </LI>
| |
| <LI>'''EC2''': you already have your access details (Key ID, Secret Key). Use them in the test.
| |
| </UL>
| |
| </LI>
| |
| <LI>Try accessing your cloud manager through the rOCCI-server in the following way (assuming account name <code>roccitest</code>):
| |
| <!--
| |
| <LI>Try accessing your cloud manager through the rOCCI-server in ''either'' of the following ways
| |
| <OL>
| |
| <LI>Use your browser to connect to the rOCCI server port, asking for the OCCI model (<code>/-/</code>):
| |
| {| border="0" style="border-collapse:collapse" cellpadding="0" width="100%"
| |
| |
| |
| https://rocci-server.example.com:11443/-/
| |
| |}
| |
| You should receive a rendering of the current model. For instance, for fresh OpenNebula, an example of a correct model listing is shown in Figure 4:
| |
| | |
| [[File:rOCCI-server-model-listing-example.png|alt=Model listing example -- browser]]<BR>
| |
| '''Fig. 4:''' Example model listing in a browser
| |
| </LI>
| |
| <LI>Use a command-line client to get the OCCI model:
| |
| -->
| |
| {| border="0" style="border-collapse:collapse" cellpadding="0" width="100%"
| |
| |
| |
| curl --insecure -u 'roccitest:<actual_password_edited_out>' https://$(hostname -f):11443/-/
| |
| |}
| |
| </LI>
| |
| </OL>
| |
| | |
| === X.509 or VOMS Authentication ===
| |
| <OL>
| |
| <LI>Make sure you have rOCCI-server configured to use GridSite and VOMS if you want to test that authentication scenario.</LI>
| |
| <LI>Create a test account in OpenNebula:
| |
| <OL>
| |
| <LI>To test '''plain X.509''' authentication, create a test account linked with your DN:
| |
| {| border="0" style="border-collapse:collapse" cellpadding="0" width="100%"
| |
| |
| |
| su - oneadmin
| |
| oneuser create roccix509 '<your certificate DN>' --driver x509
| |
| exit
| |
| |}
| |
| </LI>
| |
| <LI>To test '''VOMS''' authentication, create test account linked with your DN, including VO attributes. The DN you use, naturally, must be already registered with VOMS:
| |
| {| border="0" style="border-collapse:collapse" cellpadding="0" width="100%"
| |
| |
| |
| su - oneadmin
| |
| oneuser create roccix509 '<your certificate DN>/VO=<your VO>/Role=NULL/Capability=NULL' --driver x509
| |
| exit
| |
| |}
| |
| </LI>
| |
| </OL>
| |
| </LI>
| |
| <LI>Try accessing your cloud manager through the rOCCI-server, for instance in the following way:
| |
| {| border="2" style="border-collapse:collapse" cellpadding="5" width="100%"
| |
| ! width="50%" | Distributions with OpenSSL (Debian, Ubuntu, …)
| |
| ! Distributions with NSS SSL (Scientific Linux ≥ 6, CentOS, …)
| |
| |-
| |
| |
| |
| curl --cert <your certificate PEM file> \
| |
| --key <your key PEM file> \
| |
| --capath <path to your CA directory> \
| |
| https://$(hostname -f):11443/-/
| |
| |
| |
| pk12util -i <your certificate in PKCS12> -d sql:/etc/pki/nssdb
| |
| curl --capath <path to your CA directory> \
| |
| https://$(hostname -f):11443/-/
| |
| |-
| |
| |''Tested in Debian 7 Wheezy''
| |
| |''Tested in SL 6.5 Carbon''
| |
| |}
| |
| </LI>
| |
| </OL>
| |
| | |
| In both cases you should receive a text rendering of the OCCI model, looking approximately like the following:
| |
| | |
| [[File:ROCCI-server-model-listing-example.png|alt=Model listing example -- command line|800px]]<BR>
| |
| '''Fig. 4:''' Example model listing in the command line
| |
| | |
| If, instead of the model, you receive a message like this: "<code>Authentication failed! The following strategies are supported "voms, x509, basic"!</code>", then
| |
| the rOCCI-server works but your Cloud Manager was unable to authenticate you. Check your authentication details!
| |
| | |
| If you are able to get the model either way, your setup works. ''Note'' that this does not constitute a functionality test. It does not check for errors in either product, but it confirms that all components in your client ⇄ rOCCI-server ⇄ Cloud Manager chain are up and configured properly.
| |
| | |
| == Monitoring Probes ==
| |
| | |
| Nagios probes for rOCCI server are available as α. Documentation will be made available on release.
| |
| | |
| = Troubleshooting =
| |
| | |
| == FAQ ==
| |
| | |
| There are currently no questions asked frequently enough to merit inclusion.
| |
| | |
| == Reporting Issues ==
| |
| | |
| Use rOCCI-server's GitHub Issues to report problems or contact the developers with your issues: https://github.com/EGI-FCTF/rOCCI-server/issues
| |
| | |
| == Acknowlegments ==
| |
The wiki is deprecated and due to be decommissioned by the end of September 2022.