Accessing the Infrastructure

Target audience: Community members that are responsible for a service that is running within the typo3.org infrastructure.

Currently, the *.typo3.org server infrastructure is undergoing changes towards a new architecture. This has implications for all community members that need to access any servers via SSH or responsible for a service that requires incoming connections.

tl;dr

Before you can connect to the server again, you need to
  • Install OpenVPN.
  • If you are using Windows, make sure that OpenVPN is run with administrator rights. (Right-click the Desktop icon → Properties → Compatibility → Settings → Mark "Run this program as an administrator".)
  • Download our OpenVPN configuration file from "add-link-here":here and move it into the config/ subfolder inside the OpenVPN program folder (e.g. C:\Programme\OpenVPN\config).
  • Start OpenVPN using the Desktop icon.
  • Connecting/Disconnecting can be done by right-clicking the symbol in the task bar.

Overview

  • KVM is used for virtualization
  • All servers are located in one data center (at Hetzner)
  • All VMs have only private IP addresses. While they have unregulated internet access (via NAT), the cannot be reached directly from the outside - except using VPN.
  • Nginx is used as HTTPS proxy in front of all HTTP-based services
  • haproxy is used to make non-HTTP services available from public

VPN Access

  • VPN access to the internal network is provided via OpenVPN (you need to install an OpenVPN client and setup the configuration that you receive from us).
  • VPN clients (aka you!) receive an address from the 10.187.0.0/16 range
  • Infrastructure IP range: 10.186.0.0/16 (route pushed via VPN)
    • 10.186.0.x - network infrastructure
    • 10.186.1.x - physical servers
    • 10.186.2.x - VMs
  • You can test connectivity, by pinging 10.186.0.1.
  • Host names often resolve to internal IP addresses (srvXXX.typo3.org -> 10.186.2.XXX). You can use these hostnames once connected via VPN.

SSH Accounts

  • User accounts are managed by the Server Admin Team and provisioned via Chef (cookbook)
  • SSH pubkeys will be automatically deployed. Do not modify ~/.ssh/authorized_keys - it will be overwritten.
  • If you have a new SSH key, please contact us.

DNS Load Balancing

  • Frontend servers are redundant and use DNS load balancing. All (usually 2) frontend servers run the HTTPS proxy as well as haproxy.

HTTPS Proxy

  • All applications are running behind Nginx-based HTTPS proxies. No need to set up HTTP for your application.
  • HTTPS is mandatory, all HTTP requests will be automatically redirected.
  • The proxy adds some headers (Strict-Transport-Security and friends) automatically. Please don't duplicate them in your application. Verify the correct setup using securityheaders.io / ssllabs.com. See the add_headers section in the Chef cookbook.
  • Make sure that your application logs the correct end-user's IP address. Respect the usual proxy headers (see the proxy_set_header part of the Chef cookbook).

Public Access to non-HTTP Ports

  • TCP services that are not based on HTTP (e.g. Git) can be forwarded, too.