1 Installation and Configuration

In order to setup the Cloud Upload feature you will need to configure the tools required per each cloud provider. Right now we only support the AWS Amazon Cloud (https://aws.amazon.com) and Microsoft Azure (https://portal.azure.com) as providers.

1.2.1.1.1 Server setup #

Before you can start uploading images to the Amazon Web Services (AWS) you have to:

1. Install the obs-cloud-uploader package

   zypper in obs-cloud-uploader

2. Start the cloud upload services

   rcobsclouduploadworker start
   rcobsclouduploadserver start

At last you have to register the cloud uploader service in /usr/lib/obs/server/BSConfig.pm, eg. by adding following line:

our $clouduploadserver = "http://$hostname:5452";

Read more about configuring the backend in Section 1.4, “Distributed Setup”.

Warning

Ensure that the system time of your cloud uploader instance is correct. AWS is relying on the timestamps of the requests it receives. Having an incorrect system time will cause cloud uploads to fail.

cd /etc/obs/cloudupload
openssl genrsa -out secret.pem
openssl rsa -in secret.pem -out _pubkey -outform PEM -pubout

Make sure that the mysql server is started on every system reboot (use "insserv mysql" for permanent start). You should run mysql_secure_installation and follow the instructions.

Create the empty production databases:

# mysql -u root -p
mysql> create database api_production;
mysql> quit

Use a separate MySQL user (for example, obs) for the OBS access:

# mysql -u root -p
mysql> create user 'obs'@'%' identified by 'TopSecretPassword';
mysql> create user 'obs'@'localhost' identified by 'TopSecretPassword';
mysql> GRANT all privileges ON api_production.*
      TO 'obs'@'%', 'obs'@'localhost';
mysql> FLUSH PRIVILEGES;
mysql> quit

Configure your MySQL user and password in the "production" section of the api config: /srv/www/obs/api/config/database.yml

Example:

# MySQL (default setup).  Versions 4.1 and 5.0 are recommended.
#
# Get the fast C bindings:
#   gem install mysql
#   (on OS X: gem install mysql -- --include=/usr/local/lib)
# And be sure to use new-style password hashing:
#   http://dev.mysql.com/doc/refman/5.0/en/old-client.html

production:
  adapter: mysql2
  database: api_production
  username: obs
  password: TopSecretPassword
  encoding: utf8
  timeout: 15
  pool: 30

Now populate the database

cd /srv/www/obs/api/
sudo RAILS_ENV="production" rake db:setup
sudo RAILS_ENV="production" rake writeconfiguration
sudo chown -R wwwrun.www log tmp

Now you are done with the database setup.

Now we need to configure the Web server. By default, you can reach the familiar web user interface and also api both on port 443 speaking https. Repositories can be accessed via http on port 82 (once some packages are built). An overview page about your OBS instance can be found behind 'http://localhost'.

The obs-api package comes with an Apache vhost file, which does not need to get modified when you stay with these defaults: /etc/apache2/vhosts.d/obs.conf

Install the required packages via

zypper in obs-api apache2 apache2-mod_xforward rubygem-passenger-apache2 memcached

Add the following Apache modules in /etc/sysconfig/apache2:

APACHE_MODULES="... passenger rewrite proxy proxy_http xforward headers socache_shmcb"

Enable SSL in /etc/sysconfig/apache2 via

APACHE_SERVER_FLAGS="SSL"

For production systems you should order official SSL certificates. For testing follow the instructions to create a self signed SSL certificate:

mkdir /srv/obs/certs
openssl genrsa -out /srv/obs/certs/server.key 1024
openssl req -new -key /srv/obs/certs/server.key \
        -out /srv/obs/certs/server.csr
openssl x509 -req -days 365 -in /srv/obs/certs/server.csr \
        -signkey /srv/obs/certs/server.key -out /srv/obs/certs/server.crt
cat /srv/obs/certs/server.key /srv/obs/certs/server.crt \
      > /srv/obs/certs/server.pem

To allow the usage of https API in Web UI code you need to trust your certificate as well:

cp /srv/obs/certs/server.pem /etc/ssl/certs/
c_rehash /etc/ssl/certs/

Check and edit /srv/www/obs/api/config/options.yml

If you change the hostnames/ips of the api, you need to adjust frontend_host accordingly. If you want to use LDAP, you need to change the LDAP settings as well. Look at the Section 3.7, “Managing Users and Groups” for details. You will find examples and more details in the Section 2.1, “Configuration Files”.

It is recommended to enable

use_xforward: true

as well here.

Afterwards you can start the OBS web api and make it permanent via

systemctl enable apache2
systemctl start apache2

systemctl enable obsapidelayed.service
systemctl start obsapidelayed.service

systemctl enable memcached.service
systemctl start memcached.service

Now you have you own empty instance running and you can do some online configuration steps.

This check will output a critical if the HTTP server with ip address 172.19.19.19 (-I 172.19.19.19) listening on port 80 (-p 80) does not answer and output a warning if the HTTP return code is not 200. The server name that will be used is server (-H server) which is important if different virtual hosts are listening on the same port.

check_http -H server -I 172.19.19.19 -p 80 -u http://server

The same check, but this time it will check a ssl enabled HTTP server.

check_http -S -H server -I 172.19.19.19 -p 443 -u https://server

It is also possible to check the presence of a certain string in the HTTP response. In this case it will check for the string Source Service Server.

check_http -s "Source Service Server" -S -H server -I 172.19.19.19 -p 5152

Open Build Service HTTP endpoints that should be checked:

This check will output a warning if less than 10 percent disk space is available (-w 10) and output a critical if less than 5 percent disk space are available (-c 5). It will check all file systems except file systems with type none (-x none).

check_disk -w 10 -c 5 -x none

This check will output a warning if less than 10 percent memory is available (-w 10) and output a critical if less than 5 percent memory is available (-c 5). OS caches will be counted as free memory (-C) and it will check the available memory (-f). check_mem.pl is not a standard Nagios plugin and can be downloaded at https://exchange.nagios.org/ (https://exchange.nagios.org/).

check_mem.pl -f -C -w 10 -c 5

This check will compare the local time with the time provided by the NTP server pool.ntp.org (-H pool.ntp.org). It will output a warning if the time differs by 0.5 seconds (-w 0.5) and output a critical if the time differs by 1 seconds (-c 1).

check_ntp_time -H pool.ntp.org -w 0.5 -c 1

This plugin checks if the server responds to a ping request and it will output a warning if the respond time exceeds 200ms or 30 percent package loss (-w 200.0,30%) and output a critical if the respond time exceeds 500ms or 60 percent package loss.

check_icmp -H server -w 200.0,30% -c 500.0,60%

This check will output a warning if the load value exceeded 7.0 in the last minute, 6.0 in the last 5 minutes or 5.0 in the last 15 minutes (-w 7.0,6.0,5.0). It will output a critical if the load value exceeded 12.0 in the last minute, 8.0 in the last 5 minutes or 6.0 in the last 15 minutes (-c 12.0,8.0,6.0).

check_load -w 7.0,6.0,5.0 -c 12.0,8.0,6.0

This check is only relevant on physical systems with local storage attached to it. It will check the disk status utilizing the S.M.A.R.T interface and it will output a critical if any of the S.M.A.R.T values exceeds critical limits. check_smartmon is not a standard Nagios plugin and can be downloaded at https://exchange.nagios.org/ (https://exchange.nagios.org/).

check_smartmon --drive /dev/sda --drive /dev/sdb

This check will check that the MySQL database server is running and that the database api_production is available.

check_mysql -H localhost -u nagios -p xxxxxx -d api_production

MySQL Databases to check:

It is always advisable to check that the last backup run was successful and a recent backup is available. The check itself depends on the Backup solution that is used.