Skip to content

Common Questions

All pages listed under Documentation address common questions.

What do we need to set up a vhost or a new domain?

To assist you quickly and efficiently, we require as much of the following information as possible right when the ticket is opened. Providing this upfront avoids follow-up questions, which saves you both time and money.

  • What should the new domain name be?
  • Should subdomains be used? If so, which ones? (for example, www.)
  • Should domain aliases be used? If so, which ones?
  • Is SSL encryption required? If so, are SSL certificates already available or ordered? (HTTPS)
  • Are redirects required?
  • Should all traffic be redirected to HTTPS?
  • Should parts of the domain or URI be rewritten? (rewrites)
  • Is specific routing required?
  • Are special headers or cookies required?
  • Is an additional IP address required? (additional cost)
  • Is access protection required? (Keywords: .htaccess, IP allowlisting, Basic Auth)
  • Should a maintenance page be set up?

What should be considered?

Does a DNS entry already exist? (Keyword: A-record)

What do I need to consider for proxies for externally hosted sites?

Sometimes, there is a need to make an externally hosted site accessible via an HTTP proxy hosted by us (typically our load balancer). This might be part of a migration strategy when moving from another hoster to us (or the reverse), or it could serve to integrate a subsystem (for example, a blog or ticketing system) into a corporate application—or the reverse—in an SEO-friendly way. All these use cases share certain prerequisites:

What information do you need to set up a proxy?

We need to know the URL at which the externally hosted site should be made accessible (host/domain name and, if applicable, directory path) and the URL at which the proxy can reach the externally hosted site (IP address and, if applicable, a different hostname, directory path, or both). In some cases, we may require additional information if headers need to be added or modified during the forwarding process.

How must the externally hosted site be configured?

The externally hosted site must be accessible from the proxy. It must generate all links and references to itself either as relative links or using the intended public URL. During the transition phase, it may be helpful to make the external site accessible via multiple URLs; however, in this scenario, special attention must be paid to ensuring that links are generated correctly for all those URLs. If the externally hosted site processes visitor data, it must be ensured that the proxy is recognized as trusted and that the headers containing the original visitor data (which we may need to insert, as mentioned above) are processed instead of the proxy's own data.

### What does the external hoster need to know or prepare?\

Unless the external hoster has already implemented the aforementioned measures on the site itself, it may be necessary to clarify whether the hoster's network infrastructure includes protective measures that restrict accessibility from the proxy (for example, due to a suspected attack). If necessary, such protective measures must be disabled—at least for the proxy—ideally via an allowlist.

Are my servers and installed services monitored by you?

Every server that we install receives some basic checks. For example, we monitor B. the hard drive usage and memory usage on each server.

  • We monitor all the services we install with Icinga.
  • Every service should have a corresponding service check. If this is not the case, we should be informed immediately. We will then set up the service check.
  • Every live domain should also receive a string check. This allows us to search for a string on the page, for example B. part of the address or the VAT ID. These values ​​are rarely changed.
  • We also install a Zabbix agent on each server. This allows us to collect historical performance data about our customers' servers. This performance data helps to better assess server usage. We also like to set up a Zabbix dashboard that shows all important information about the servers at a glance.

For every service that is installed and managed via the configuration management system (Puppet) used by us, a configuration for measuring the availability of the service is automatically created on the respective monitoring server. This not only affects individual services on a server, but also basic metrics such as the memory usage of the hard drive, the main memory (RAM) and the general accessibility of the respective host via the network (ping/ICMP "echo request"). The following overview describes all the basic checks that are always available for every server:

Metric (Check) Description
APT Checks the return status when running the package management tool APT.
Crondaemon Checks the functionality of the local Cron service on the system.
Load Monitors CPU usage on the system.
Mailq Monitors the mail queue on the local system.
Out Of Memory Killer Occurs when a service on the virtual server has been stopped hard by the kernel of the underlying hardware node due to excessive memory requirements.
Outgoing IP Checks whether outgoing TCP connections also correspond to the first public IP address assigned to the server as the source IP address.
PING Checks the accessibility of the respective server via ICMP “echo request”.
Puppet Checks the status of the so-called puppet agent, that is, the program that applies centrally defined configuration changes to the system.
RAM Monitors the memory (RAM) usage on the system.
TotalProc Monitors the maximum number of running processes on a system.
VZFS Monitors disk usage on the system and alerts if certain limits are exceeded.
Zabbix Agent TCP Checks the availability of the Zabbix Agent via TCP port 10050, which delivers the metrics for the trending system (Zabbix), which are queried from a central server.
Zombie Proc Determines whether so-called zombie processes (dead or orphaned processes) exist in the process list.

As previously mentioned, a corresponding check is created on the monitoring server for virtually every service managed by Puppet on a system. This applies to the following services, among others, which are installed on at least one server in almost every setup:

Metric (Check) Description
SSH Monitors the availability of the SSH daemon on the server's internal, private IP address via TCP port 22.
HTTP Monitors the availability of the HTTP daemon (web server) on the server's internal, private IP address via TCP port 80.
SMTP Monitors the availability of the SMTP daemon (mail server) on the server's internal, private IP address via TCP port 25.
Redis TCP Monitors the availability of the Redis daemon on the server's internal, private IP address via TCP port 6379.
Memcache Monitors the availability/latency of the Memcache daemon on the server's internal, private IP address via TCP port 11211.
MySQL Checks the availability of the MySQL service via the local Unix domain socket (/var/run/mysqld.sock).
MySQL Log Checks the MySQL error log for error messages and reports or triggers an alert if any occur.
MySQL Replication Monitors the replication status on every additional DB server in your replication setup and issues a warning or alert if replication is significantly delayed or completely interrupted.
Elasticsearch, Health Check Checks the health status of the Elasticsearch cluster or server via the Elasticsearch Cluster API. The check triggers an alert if the Elasticsearch instance is unreachable or if the cluster health status is 'red'.
Java RAM Check Checks the RAM usage of the installed Java VM on the server and issues an alert when specific thresholds are reached.
NFS mount Monitors the mount point of an NFS share mounted on a server.
NFS space Monitors storage usage on a mounted NFS share.

How often are my servers backed up?

For every server, the entire system tree—including all files contained within it—is backed up. We perform daily, weekly, and monthly backups. Daily backups are deleted after one week, weekly backups after four weeks, and monthly backups after three months. (7/4/3)

Here is an example list of available backups as of July 28, 2017:

  • snap-20170501
  • snap-20170625
  • snap-20170702
  • snap-20170716
  • snap-20170722
  • snap-20170724
  • snap-20170726
  • snap-20170601
  • snap-20170701
  • snap-20170709
  • snap-20170721
  • snap-20170723
  • snap-20170725
  • snap-20170727