This page describes the setup of the main OICE server, Romulus, including details of all important services.

The following table lists the services provided by romulus and the location of the relevant configuration files.

SSH access on romulus is only allowed for members of the (LDAP) group ssh-logins. Furthermore, access by encrypted transfer of the user password is disabled for security reasons. The preferred way of accessing the server is via public-private-key authentication.

When logged in as a specific user, you can generate your own public private-key pair easily with the command ssh-keygen -t rsa. For usage in the Windows program Putty, the private key (usually named .ssh/id_rsa) first has to be converted to a suitable format with puttygen.

romulus has its root directory / mounted on a 600 GiB RAID 1 array at /dev/sda. Addtionally, a 5.9 TiB RAID 6 array on remus (192.168.231.218) consisting of 12 Seagate Cheetah ST3600057SS (600 GB, 15000 rpm) is connected via Ethernet and iSCSI at /dev/sdb and mounted on /srv.

The iSCSI connected mount point /srv holds the managed repository of OMERO and thus all uploaded image files and files attached to OMERO images/projects/datasets. Additionally, /srv holds part of the regularly taken system and storage backup for synchronization with rheasilvia.

romulus runs an OpenLDAP server used for storing all OICE wide user accounts and group memberships. For this server, the RFC 2307bis was implemented and a modified nis-scheme was used to allow for GroupOfNames and PosixGroup in a single entry. The LDAP configuration files were adapted accordingly (cf. https://www.heinlein-support.de/blog/howto/ldap-und-unix-gruppen/ (german) and https://tools.ietf.org/html/draft-howard-rfc2307bis-02)

OpenLDAP is configured largely inside its own directory structure instead of using the traditional configuration files inside /etc. Permissions where chosen as restrictively as possible while still allowing external authentication requests where necessary. Please refer to https://help.ubuntu.com/lts/serverguide/openldap-server.html for a starter on how to configure OpenLDAP on Ubuntu LTS 14.04.4.

The web frontend GOsa² is provided by romulus to conveniently manage central OICE user accounts stored via the OpenLDAP backend. New users can be easily added by using the “oice_user” template in the creation process. Upon adding a new user, the post-creation script /usr/local/scripts/oice-userpostcreate is called that is assigning a default password if nothing else was assigned (February 2016: FirstnameLastnameSTED). Additionally, this script will trigger a custom implementation of a python API for the PPMS HTTPS API to add the new user to the PPMS booking system's database with external authentication turned on. This will happen only if the LDAP field “department number” contains a valid unique group login, such as group-sclaus. If no such field is present, the user will not be automatically added to the PPMS system and has to be added manually. If there is not yet a valid group for the uses that is to be added, the group has to be added manually to the PPMS before the user is added. Groups are, unfortunately, not queried by the PPMS server on our LDAP database. Also, account information cannot be automatically requested, which is why the double account creation is necessary. However, the authentication (via username and password) is happening on our LDAP server, the the usernames of users in the PPMS database and int he LDAP server need to be identical. Also, the authentication is happening via LDAP SSL (ldaps) on port 636, since STARTTSL encryption is not supported, so port 636 has to be opened for the appropriate IP addresses (which was the case in February 2016). User information during the authentication process is thus transferred on encrypted channels. Care should be taken that this is not accidentally changed.

Ubuntu LTS comes with an effective and easily configurable firewall, termed “uncomplicated firewall” (ufw) (cf. https://help.ubuntu.com/lts/serverguide/firewall.html). It has been restrictively configured to allow only necessary incoming connections. In February 2016, the configuration was as follows:

where the application “Samba” is defined as ports Ports: 137,138/udp and 139,445/tcp (needed for CIFS and PDC authentication). The IP 134.213.137.186 on port 636/tcp is needed for the Stratocore PPMS system to authenticate the logins with the LDAP server on romulus. 52.31.192.143 on port 636 is needed as a backup in case the normal Stratocore server is not functioning.

OMERO, the DokuWiki platform and GOsa² all run on an Apache 2.4.7 web server. All configuration files have been adapted to the syntax necessary for Apache servers >= 2.4 (e.g. require all granted instead of Allow from all, etc.), which was necessary since most examples for web services are still tailored to Apache 2.2.

/etc/apache2/sites-available contains configuration files for GOsa² and for OMERO/DokuWiki. The latter two are combined inside omero-ssl.conf, since they both run on romulus.oice.uni-erlangen.de. The GOsa² service can be reached via its own domain name gosa.oice.uni-erlangen.de and is consequently configured in its own configuration file gosa-ssl.conf

For backup purposes, there is an extra storage server rheasilvia, currently on IP 192.168.231.216. It features 29 TiB of HDD space contained on a RAID 6 array consisting of 8 Hewlett Packard 8 TB 7200 rpm disks.

Encrypted and compressed backups are currently (February 2016) transferred every night via the application “duplicity” (uses rsync and gpg internally, see https://help.ubuntu.com/community/DuplicityBackupHowto). Additionally, rsync is used to synchronize a directory with snapshots of various other backups (such as the LDAP directory) contained in /srv/backups/settings.

A slightly abbreviated version (without the error messages) of the current (February 2016) backup cronjob is listed as follows:

AGES=0,1,2,3,4,5,6,7,14,30,60,182,365,730

# *** OMERO database and setting files, ldap directory, system setting files
00 3    *    * *   omero    /usr/local/scripts/backuplocal-omero
10 3    *    * *   root     /usr/local/scripts/backuplocal-ldap
30 3    *    * *   root     /usr/local/scripts/backuplocal-system
40 3    *    * *   backup   /usr/local/scripts/thinout-backups $AGES
45 3    *    * *   root     /usr/local/scripts/backupremote-settings

# *** Users' home directories, the OICE network share, the OMERO data repository and the wiki
# Incremental backup most of the time
00 4    2-31 * *   root     /usr/local/scripts/backupremote-home
20 4    2-31 * *   root     /usr/local/scripts/backupremote-oiceshare
40 4    2-31 * *   root     /usr/local/scripts/backupremote-omerodata
00 5    2-31 * *   root     /usr/local/scripts/backupremote-wiki

# Full back up in regular intervals
00 4    1    * *   root     /usr/local/scripts/backupremote-home full
20 4    1    * *   root     /usr/local/scripts/backupremote-oiceshare full
40 4    1    * *   root     /usr/local/scripts/backupremote-omerodata full
00 5    1    * *   root     /usr/local/scripts/backupremote-wiki full

This will start the backup process at 3 a.m. every night. All custom scripts, which are internally documented as well, including the ones used for backups are residing in /usr/local/scripts. The purpose of the backup scripts is as follows:

All scripts that run duplicity can receive an additional argument full. If full is present, it will force a full backup even in cases where an incremental backup would have been possible. According to the current (February 2016) backup cronjob, this happens on every first day of the month.

The output of all backup operations is logged to /srv/backup-logs for inspection in case of problems. Currently, the account tnowak (can be changed in /etc/cron.d/backups receives an internal mail in case errors occurred.