Linux Server Hosting

The ZDV offers hosting of self administrated servers as virtual servers. We provide help in choosing the right server, depending on your workload and required resources.
This service is offered to faculties, institutes, teams and other bodies of the university.

Requirements

You must name a responsible administrator with sufficient knowledge to administrate a Linux server.

Services provided by the ZDV

  • Creation of the virtual server with required resources.
  • Installation of operating system (Debian).
  • Creation of a DNS entry.
  • Deployment of ssh keys for administrative access.
  • Integration of your server into the ZDV infrastructure (backups, system monitoring, mail).
  • Automatic installation of security updates for the base operating system.
    (❗❗This does not include updates for programs installed by an administrator.❗❗)
  • Support

Responsibilities of a server administrator

Server administrators are responsible for securing their server. This includes staying up-to-date about security vulnerabilities, and fixing them.

⚠️The ZDV reserves the right to block or shut down a server if unpatched critical security vulnerabilities, compromised machines or risks for other systems are detected.

Restrictions

The virtual servers are not designed for constantly highly demanding tasks, e.g. simulations or analysis.

Request a virtual server

Application form for a virtual server.

Additional information

To prevent abuse of our mail system, you need to sign in before you are allowed to send any mail, like you do with Outlook and Thunderbird. By doing so, the ZDV can differentiate between authorized and abusive use, e.g. making sure no one can send messages in someone else's name.

If the mail is sent by a specific program (and not a person,) this may not be possible. For this use case the ZDV provides a mailproxy.

To use the mailproxy, enter the following details into your specific program:
Mail- or SMTP-Server: mailproxy.zdv.uni-mainz.de
Port: 25
Connection security: Optional
Authentication (name and password): not necessary

This way, the mail is send to the mailproxy, the proxy checks if your server is allowed to send such a mail. To allow sending of mails, rules need to be created.

Rules are based on the receiver of the mail.
For sending mails via the mailproxy, the following restrictions apply:

  • Sending mails with a personal address is not possible.
  • If a reply is expected, the from address must be a working address, e.g. info@uni-mainz.de.
  • If no reply is expected, the from address can be noreply@uni-mainz.de.
  • If the mail is sent to an address outside of the university, the server part of the from address (e.g. "uni-mainz.de" for most university addresses) needs to be known outside of the university network. Otherwise the mail won't be accepted by the receiving server. This is the reason, why internal addresses like info@server.faculty.uni-maint.de are not usable.

It is possible to create any number of rules.
To create a rule, we need the following information:

  • Name of your server
  • Sending address
  • Recipient address

Here are some examples:

System: internal-server.zdv.uni-mainz.de

Sending address: info@uni-mainz.de
Recipient: any, worldwide

Sending address: news@zdv.uni-mainz.de
Recipient: only Uni Mainz

Sending address: status@zdv.uni-mainz.de
Recipient: postmaster@uni-mainz.de

To create a rule, send an e-mail with the subject Mailproxy to: linux@uni-mainz.de.

To ensure safety of our university network, servers are, by default, not allowed to connect to the internet.

If you need to establish a connection from your your server to the internet, a rule needs to be created. These rules are created on the ZDV webproxy.
Your server sends a request to the webproxy. The webproxy then decides, if the connection is allowed or not.

Set up the proxy on your server

To add the proxy to your system, you need to add the following lines to /etc/enviroments.

http_proxy=http://webproxy.zdv.uni-mainz.de:3128
https_proxy=http://webproxy.zdv.uni-mainz.de:3128
no_proxy=localhost,0.0.0.0,127.0.0.1,127.0.0.0/12,.zdv.uni-mainz.de,.uni-mainz.de,zdv.net,rlp.net,*.zdv.uni-mainz.de,*.uni-mainz.de,*.zdv.net,*.rlp.net,10.94.0.0/12,10.96.0.0/12
HTTP_PROXY=http://webproxy.zdv.uni-mainz.de:3128
HTTPS_PROXY=http://webproxy.zdv.uni-mainz.de:3128
NO_PROXY=localhost,0.0.0.0,127.0.0.1,127.0.0.0/12,.zdv.uni-mainz.de,.uni-mainz.de,zdv.net,rlp.net,*.zdv.uni-mainz.de,*.uni-mainz.de,*.zdv.net,*.rlp.net,10.94.0.0/12,10.96.0.0/12

Add rules for your server

To add a rule, send an e-mail with the subject Webproxy to: linux@uni-mainz.de.

CFEngine is a program to administrate a number of computers via a central server. This way, there is no need to set up every computer manually.
On ZDV Linux and virtual servers CFEngine comes preinstalled and configured.

CFEngine consists of 2 components.

  1. A local client, which makes changes to the system.
  2. A server, which provides information to the client on what to change.

Changes could be creation, deletion or changing of files.
Different changes are made based on the computer. For example, a desktop needs other changes than a server.
To differentiate between the different computers, CFEngine assigns different classes to each computer.
The server instructs the client to make a changes to a specific group. The client checks, if the computer is a member of this group and applies the change accordingly.
During this process, local changes can be overridden.

Local changes are overridden by CFEngine

If local changes are overridden by CFEngine, exceptions can be made to preserve local changes.
If you need an exception for your computer, please send an e-mail with the subject CFEngine to unix@uni-mainz.de.
We will work with you to add such an exception.

Which files are changed by CFEngine?

The need for different configurations may change over time, based on the type of computer. The instructions for the clients are kept up to date by the ZDV. This means, changes made by CFEngine to a computer can change over time, based on the type of computer.

This documentation explains how to check what changes are made on a computer. To do so, you need to check the classes of the computer and the changes assigned to this class.

What classes are associated with my computer?

To get a list of all classes your computer is associated with, type
cf-promises --show-classes
with roots rights into a terminal.

Where can I find changes made to my computer?

All changes made by CFEngine are stored in .cf files. These files can be found at /var/lib/cfengine3/inputs/local.
The name of the file indicates what it configures.

Reading a .cf file

.cf files are divided into different sections. Everything belonging to a section is indented.
Changes of files are found at the files section.
Here is a snippet of the backup.cf file.

...
	files:

		burpclients.!backup_01::

		    "/etc/cron.d/burp"
                        copy_from	=> secure_cp_b("$(g.dir_masterfiles)/etc/cron.d/burp", $(sys.policy_hub));

		burpclients::

		    "/etc/burp/burp.conf"
                        copy_from	=> secure_cp_b("$(g.dir_masterfiles)/etc/burp/$(sys.host).conf", $(sys.policy_hub));

		    "/etc/burp/clientconfdir/incexc/zdv"
                        copy_from	=> secure_cp_b("$(g.dir_masterfiles)/server/backup-01/etc/burp/clientconfdir/incexc/zdv", $(sys.policy_hub));
...

Line 2: This marks the start of section "files:" everything that is indented belongs to this section.

Line 4: Sets the classes which the changes should apply to. Every indented line will be executed, if the classes are met.
Checking for a class can be done in different ways:

  • class1:: If the computer is in class1.
  • class1.class2:: The dot means the computer needs to be in class1 and in class2.
  • class1|class2:: The | means the computer needs to be in class1 or in class2.
  • class1.!class2:: The ! stand for not. The computer needs to be in class1, but mustn't be in class2.

In this case the computer needs to be in class burbclients and musn't be in in class backup_01.

Line 6: Which file is going to be changed.

Line 7: How the file is changed. In this case a new file is copied from the server and replaces the old one.

Line 9: A new rule is set for all computers in class burbclients.

Line 11, 14: Which files are changed, same as in line 6.

Line 12, 15: How the file is changed, same as in line 7.

 

Configure your own server

If you use a ZDV Linux version or a virtual server provided by the ZDV, CFEngine is installed and configured by default.
If you installed Linux by yourself, you need to install and configure CFEngine manually.

Keep in mind, that the ZDV doesn't provide configurations for all distributions. If your distribution is not in any class configured by the ZDV, no changes will be made.

Installation
Install the CFEngine package provided by your distribution e.g. cfengine3(Debian, Ubuntu), cfengine(Suse, Fedora).

Bootsrap
After installation, enter cf-agent -B config-01 with root rights into your terminal.

The university provides an OpenID Connect server. With OpenID connect, you can authenticate a user via the ZDV and request data about this user.

A tutorial on how to implement OpenID Connect can be found here.

The current ZDV server configuration is available at openid.uni-mainz.de/.well-known/openid-configuration.

OpenId connect can only be implemented after prior consultation with the ZDV. Please send an e-mail with the subject OpenID Connect to hotline@uni-mainz.de.

To set up OpenID Connect access, the ZDV needs the following information:

  • Which claims are needed
  • A valid redirect_url for your website.
    If you want to develop an own application, this will be coordinated individually.
  • Which flow is being used:
    • Authorization Code Flow (It's recommended to use this flow.)
    • Implicit Flow
    • Hybrid Flow

The ZDV defines the following parameters:

  • client_id
  • client_secret (if necessary)