Use Cases

orcharhino Use Cases

At the beginning, there was only one server. It was nurtured and maintained with a lot of care. But that was a long time ago. Today, the masters of data centers control their countless hosts mostly by automation.

orcharhino automates your entire data center. In particular, orcharhino supports automated host deployment, configuration management, and patch management.

Built by ATIX, orcharhino is based on the open-source software Foreman and Katello and bundles several other components into an all-inclusive carefree data center package.

What is orcharhino?

orcharhino is in charge of your hosts’ installation, configuration, administration, and lifecycle management. RHEL and CentOS have had the duo Foreman/Katello in their program since the beginning. ATIX developers have extended this, so that orcharhino additionally works with SUSE Enterprise Linux as well as Debian and Ubuntu. Meanwhile, a large part of its functions is also available for Windows hosts. In the spirit of open source, we give our extensions back to the community, of course.

Development and quality assurance at ATIX prepare suitable installation templates for all mentioned platforms as well as client software, which connects the hosts with orcharhino. Users of different platforms thus ultimately receive a uniform interface that offers various technical approaches equally. But as a manufacturer-independent administration software, orcharhino is also suitable for homogeneous IT landscapes. Our knowledge base and support team is available to customers to help with any problems.

Introduction and Disclaimer

Three (fictitious) companies share their experiences with orcharhino. We outline their respective deployment scenario and address particular aspects of their server management. The infrastructure differs in some aspects that are due to general conditions and the personal preferences of the local administrators. Disclaimer: None of these companies actually exist, and the selection does not represent the orcharhino user base. In fact, they are only intended to represent a cross-section of the areas of application. That said, we would like to introduce them here briefly:

1. Finesse Bank

The Finesse Bank is a relatively young FinTech company. It has a small client base and provides apps for financial management, with the larger part concerning asset management. A reliable server infrastructure is essential for its business model. Most servers are located in the central data center, while smaller remote branches are situated near important trading floors. As a bank, the company is subject to supervision by BaFin and has to design its infrastructure to be robust.

2. Value and Vision

Value and Vision offers its customers (primarily engineering agencies) central services, in particular the flexible provision of computing capacity as well as server housing and management. Due to the worldwide distribution of customers, the company has expanded. It now operates several smaller data centers, some of which are kept strictly apart from one another. At Value and Vision, the customer is king—which is why, for example, everyone wants to use their own favorite operating system. Similar to virtual machines, users normally set up hosts once to use them for a project, before replacing them (or having them replaced) by newer instances.

3. Quality University

The University of Quality has about 30,000 students from all faculties. They have access to several central services. Natural sciences and economics also use a local cluster for simulations and model calculations, which is provided and managed centrally. Thanks to orcharhino, the University of Quality has succeeded in consolidating and unifying its infrastructure management.

Use Cases

The following paragraph contains a number of use cases to give you an idea of the possible applications of orcharhino.

orcharhino as an Installation Source

Deploying hosts is one of the core functions of orcharhino, along with configuration management and lifecycle management. It provides various ways to provide new hosts with information during installation, and eliminates the need for human interaction.

Value and Vision frequently needs to deploy new hosts, often in large numbers, in response to customer requests. Usually, these are virtual machines, but some customers prefer bare-metal servers. In all cases, Value and Vision’s employees prepare the new host in the web interface of orcharhino. With virtual machines, for example, they define their performance characteristics (CPU, RAM, network, storage). Of course, they also determin in which network the host should be located so that customers can access it. Further specifications are the operating system or the configuration management in use, including roles/classes/states. Value and Vision must be prepared for each and every eventuality, which is why they keep data and clients for almost all operating systems that orcharhino can manage:

AlmaLinux 8
Amazon Linux 2
CentOS Linux 7 and CentOS Stream 8
Debian 9, 10 and 11
Oracle Linux 7 and 8
Red Hat Enterprise Linux (RHEL) 7 and 8
Rocky Linux 8
SUSE Linux Enterprise Server 12 SP3, 12 SP4, 12 SP5, 15, 15 SP1, 15 SP2 and 15 SP3
Ubuntu 18.04 and 20.04

Linux hosts require a kernel and initial ram disk, which they obtain by PXE booting from a boot image. Windows hosts can boot from a special minimal image. After that, various mechanisms are used to create the operating system automatically. In Linux, the following have been established: Kickstart/Anaconda (Red Hat family), AutoYAST (SUSE), and Preseed (Debian family). In all cases, a program queries the basic configuration via HTTP. Templates written by orcharhino admins in advance now create the Kickstart, AutoYAST, or Preseed definition from the configuration parameters. The rendered template then contains, for example, the network configuration of the respective host, password hashes, a basic packet selection, and information on how to prepare the configuration management.

orcharhino can start virtual machines directly by addressing the hypervisor API. Most bare-metal servers are started by orcharhino via BMC (iLO/IPMI/iDRAC) after their network interfaces have been connected to the switch in the correct VLAN. At Value and Vision, all hosts (physical and virtual) are connected to at least two networks: a productive network and an installation network. In the beginning, only the installation network matters. orcharhino or its orcharhino proxies act as DHCP servers and deliver all necessary files for PXE booting via TFTP.

After a few minutes, the new hosts are basically set up and reboot. The central configuration management then takes further steps and installs additional software. For example, some customers want web servers. An Ansible role written for this purpose installs the necessary packages, creates configuration files, and sets up firewall rules. From now on, customers can use their system.

At Finesse Bank, the process is similar, but more manageable, because the only intended operating system is SUSE Linux Enterprise Server. And there are fewer application scenarios. In addition, there is a test environment parallel to the production environment, in which admins simulate adjustments to the infrastructure. Only when everything is running smoothly there, the admins take the changes to the next level.

The University of Quality, however, has to dig a little deeper for the trick up its sleeve. Some applications require Windows servers to run. These are also installed and managed via orcharhino. For this purpose, there is a golden image, which is stored on the virtualization hosts and can be directly integrated. In addition to that, there is also a customizable network installation that uses templates, similar to kickstarting or preseeding in Linux.

Lifecycle Management

A core function of orcha rhino is the provision of software repositories—besides configuration management and the deployment of new hosts. However, it is more than a simple mirror server because it can also version repositories. At Finesse Bank, there is a group of repositories for the operating system, which is updated every night. There is a similar system for third-party software. At the same time, Finesse Bank develops its own software. This is also packaged in repositories, where the upload is carried out manually from the developer system. Connected systems do not automatically get access to the latest version of the packages, but one version at a given time.

orcharhino admins combine several repositories into products. The product SLES 15 SP1, for example, includes repositories for the operating system and updates. Different repositories—not necessarily from a single product—can be grouped together as content views. This allows the relevant content for a target system to be aggregated; for example, at Finesse Bank, the content view SLES15_Puppet combines the repositories for SUSE Linux Enterprise Server 15 with the client tools for orcharhino and the configuration management tool Puppet.

At file level, all packages are in a pool, possibly in multiple versions. When administrators create a new version of a content view, a new branch is generated in the directory tree that contains links to the current packages—a snapshot, so to speak. At Finesse Bank, the latest version of SLES15_Puppet 11.0 is currently available and was released a few days ago. Version 10.0 is already almost half a year old, but has been updated several times in the meantime to fix security holes (more on this later).

The company’s software goes through several development stages that are called dev, test, and prod—the Lifecycle Path. Each of these environments is assigned to exactly one version. Hosts in test and prod are currently attached to version 10.8 of the content view SLES15_Puppet; in dev, version 11.0 is used because there are some new functions available that the developers would like to incorporate in their software. When the latest version is ready for testing, the version level in the test environment is raised.

Companies in the financial sector usually have high security standards. In order to meet these requirements, IT managers must maintain an overview of possible weaknesses in their systems. With Red Hat, errata have been established for this purpose—this concept is now also available for other distributions. Behind it, metainformation about published vulnerabilities is hidden. In addition to a code to identify and describe the vulnerability, this includes a list of affected packages and a solution, i.e., in what newer packages the bug is fixed. orcharhino gets lists with errata from the vendor repositories. At the same time, it stores information on which packages are installed on which systems. ATIX provides customers with errata for CentOS, Debian, and Ubuntu.

For each host, users of orcharhino can easily see if such errata affect the respective system, and import them directly. The previously mentioned minor release of the content view is due to the fact that security updates are contained in packages that are not yet available in SLES15_Puppet 10.0. In this case, it is possible to update only individual packages and create minor versions of a content view.

In the case of the University of Quality, this process is generally simpler, as there are no in-house developments; only upstream repositories are maintained. At Value and Vision, the situation is similar, except that the experts there have additionally inserted “Lifecycle Fast Paths,” in which minor releases of the content views are tested before they end up on customer systems.

Configuration Management

orcharhino combines several tools for automation in data centers. Configuration management plays a central role in this—along with the deployment of new hosts (see “orcharhino as an installation source”) and the versioned provisioning of repositories (see “Lifecycle Management”), this can be considered one of its core tasks. orcharhino users can choose between Ansible, Puppet, or Salt for configuration management, all of which are integrated and can be used via the web GUI. The Finesse Bank relies entirely on Puppet. The tool has established itself in areas where configuration drifts should be avoided. For this purpose, agents run on the connected systems, which regularly request their target configuration from the puppet master. If their status differs, they take all necessary steps to achieve the desired status. For example, packages could be installed or uninstalled, services configured and started. Puppet corrects all changes made by users or local software. Usually—also in the case of Finesse Bank—orcharhino assumes the role of the Puppet Master. That way, the reports of the individual Puppet Agents automatically end up there. For each host, you can see in detail what changes have been made. If there an error occurred during the run, the host is marked accordingly in the overview.

Value and Vision uses Ansible for configuration management. With Ansible, it is possible to map sequential processes in a better way and to avoid configuration drifts. For Value and Vision, this is not as important because after the handover, the customers themselves are responsible for their machines. In orcharhino, the hosts are linked to Ansible roles for this purpose. After installation, these are automatically executed once and install certain packages, make configurations, or execute certain commands.

At the University of Quality, the managed system is altogether more heterogeneous. This is due to the fact that in the past, the institutes were responsible for their own infrastructure. orcharhino now offers them a common interface, but according to the respective LDAP affiliation, the admins only have access to their own systems. Part of this heterogeneity is also due to the fact that different configuration management tools are in use. Some institutions also use a mix. The orcharhino team has therefore activated the plug-ins for Ansible, Puppet, and Salt. The reports show that all three are in use.

Separate Infrastructure

The University of Quality now uses orcharhino (see “How does orcharhino arrive at the customer?”) for the entire campus. What started as a project purely for the administration of central services now involves almost all institutes. Thus, a collection of tools and approaches has been concentrated in one tool. In the course of this process, it has become apparent that it is important for the individual institutions involved (department chairs, administrative units) to be able to continue to map the original separation between institutes and departments.

Mechanisms for this separation in orcharhino are primarily known as organizations and locations. As organizations, for example, there are universities for the central services and the department infrastructure as well as administration and the hospital. The locations are one level below. The administration does not make any further distinctions here; the hospital has opted for a division into infrastructure and teaching operations. For the organization university, there are locations with the names of the individual departments, data centers, clusters, and media. All objects in orcharhino are assigned to an organization and a location. This allows users to filter lists and to assign rights.

For user authentication, orcharhino is connected to the central LDAP server of the university and also to the one of the hospital. When users log on to the web front end, the system assigns them to a user group. The assignment is made according to the group assignment in LDAP. Department administrators, for example, only see their own computers and can only manage these.

The managed objects are primarily the hosts as this is where the administrators work most, but the access permissions of subnets, for example, can also be restricted. Thus, the admins can only register newly created hosts in certain IP ranges.

A class C network is available to each administration unit. Almost all computers receive public IPs. Only the computing cluster is located in a private network, and there is a separate DMZ for certain servers. The cluster network is extremely isolated, similar to a DMZ. Only two nodes are accessible from the university network and can establish connections to the outside: a login node for users and the orcharhino proxy. The latter is a separate instance and belongs to the orcharhino infrastructure. It does not have its own web GUI, as it only serves as a link for networks to which orcharhino has no direct access or mirrors repositories if this is recommended to minimize the used bandwidth. It also receives puppet reports and serves as a proxy for Ansible Calls. The orcharhino proxy runs similar services to orcharhino, but in a subordinate role. Pulp synchronizes selected repositories from the orcharhino—in this case Debian—and supplies the nodes with packages. It is a DHCP server and name server and provides the necessary data for installing new nodes via PXE and TFTP.

Besides the cluster, there are currently eight subnets connected to orcharhino. This includes a central network, in which the university’s server services are located (intranet, mail server, etc.), and several institute networks if these operate their own central services or small local computing clusters, as in physics or chemistry.

In all networks, a orcharhino proxy runs as a link between the hosts and orcharhino. Since the network load so far is manageable, almost all hosts use orcharhino directly as packet source, but they have to use their respective orcharhino proxy as HTTP proxy, because there is no direct route—orcharhino itself is connected to an internal network. Workstations are so far excluded from the central administration by orcharhino, although this is being considered at least for the Linux pools.

Value and Vision operates a comparable infrastructure but has predominantly private networks that customers access via VPN. The administrators automatically create a separate organization for each customer. Hosts authenticate themselves to orcharhino via SSL certificates and therefore only see allowed repositories. Some customers deposit self-developed software and can thus ensure that no competitor can easily access it.

Finesse Bank has a central network in the main branch and subnets in the remote locations. The orcharhino proxies there mirror the repositories of orcharhino. The operation of orcharhino is completely in the hands of the infrastructure team, so that no highly granular rights management at user level is necessary. This requires more stringent guidelines for the network and is actually outside the range that orcharhino manages. However, the hardware can be controlled via Ansible, which in turn can be managed via orcharhino.

Hypervisors/Coasters

Value and Vision operates several data centers around the world. Customers typically require computing capacity for certain project phases, but do not want to keep it permanently available or manage it. Usually, they then order virtual machines, which are preconfigured when they get them. Once they have completed their task, they can simply delete them again. This is why the data centers are primarily equipped with virtualization hosts. At the beginning, these were just VMware ESXi hosts. More recently, however, there has been an innovation: some data centers are switching to Proxmox clusters.

The API end points and credentials of the virtualization hosts can be entered in orcharhino as “Compute Resources.” This allows users to create, switch on/off, and delete virtual machines on these hosts via the orcharhino GUI. For VMware, snapshots can also be managed with orcharhino.

So, when Value and Vision employees create a new host, they select the virtualization host and virtual machine specification in addition to the operating system. Clicking “Create Host” automatically creates and boots the VM. It then appears as a new host in the list in the web interface—both in orcharhino and the hypervisor.

For other customers, Value and Vision manage bare-metal servers. They also depend on orcharhino, which takes over configuration management and lifecycle management. Thanks to an “Intelligent Platform Management Interface,” admins can also control the power settings for these machines via orcharhino.

Recently, the admins also installed the plug-ins for the cloud providers Amazon Web Services, Google Cloud Engine, and Microsoft Azure. This means that they are also available as compute resources, and orcharhino can create instances there. Originally, the idea was to be able to absorb peak loads dynamically. However, the first customers are seeing new opportunities to link their virtual machines to other services from the respective providers.

At first, Finesse Bank only used physical servers, but they gradually replaced them with virtual machines. The flexibility extended the deployment scenarios and meant that the use of the data centers could be better adapted to requirements. The fact that these can be managed so easily via orcharhino has almost completely replaced physical hosts.

At the University of Quality, however, people rely almost exclusively about physical servers—scientists are too worried about losing CPU cycles to hypervisors that they actually need for their calculations. Only central network services are virtualized. The Institute for Information Systems recently established a special feature. A new professor is giving courses on IT infrastructure there. In the first semester, it was not possible to spontaneously provide enough resources to set up training environments for course participants. During planning, someone from the data center suggested that cloud instances could be used and that orcharhino was already ready for this. The person then demonstrated how to create hosts in the Azure cloud that had been set up after installation using Ansible. During the first semester, Azure instances were started for the courses (block courses) and deleted directly afterwards—again through orcharhino. This procedure remains in place until today, and the course content now also includes infrastructure management with orcharhino.

How Does orcharhino Get to the Customer

When the University of Quality was founded in the 1970s, there was no IT infrastructure at the individual departments; everything was managed centrally via the data center. In the meantime, however, computers have become cheaper and it is easier to administrate Windows and Linux. Knowledge and financial resources no longer accumulated in the data center, and the IT landscape fragmented. When configuration management tools emerged, a discourse about a renewed consolidation started. Over time, isolated solutions established themselves despite efforts to standardize the infrastructure. Then the data center began to set up the so-called Gondor cluster and thus offer HPC resources centrally. In the course of this, various management tools were evaluated. The University of Quality decided to use orcharhino. ATIX was assigned to build a proof-of-concept environment. For this, an ATIX consultant installed orcharhino in the University of Quality’s computer center, including an orcharhino proxy in the cluster network, and prepared it to provision Debian hosts. In addition, the consultant included some ready-made Puppet modules that can be used to add hosts to the cluster queue system and install scientific packages. These on-site tasks took a week, during which the computer center employees had the opportunity to look at individual aspects immediately.

After the setup week, the quality university had its first orcharhino and could start building up the cluster completely. Its active test phase began soon afterwards. The proof of concept quickly became a productive system, and it was decided to add further systems to orcharhino. First other central servers, which also ran on Debian Linux. It quickly became clear that most isolated applications could also be integrated without much effort. The biggest hurdle was that different distributions or even operating systems were being used. Hence, the University of Quality agreed with ATIX to conduct an on-site training so that more employees woulod be able to work with orcharhino. Furthermore, an ATIX consultant would visit the University of Quality regularly for the next months to support the migration process. First, a central Git server was built to host the definitions for the configuration management. Package sources for the different distributions were synchronized and, based on this, content views and activation keys were created. The central user administration was integrated and, finally, a use for a compute resource from the cloud was found, as a new professor used training infrastructure in Azure for a course.

The visits of ATIX consultant would be more frequent at the beginning of course—two days every two weeks—and went back to once per month toward the end, when the computer center employees became more familiar with the system.

For the basic installation of the productive systems at Value and Vision and Finesse Bank, the companies got support from ATIX. However, both had previously conducted tests with orcharhino on their own initiative. There is a test license for this. Incidentally, the proceeds from this will go to the “Save the Rhino” conservation project. After the system was found suitable, Finesse Bank ordered someone to install the productive system. Value and Vision has no true central location, so the installation was carried out via remote sessions. As a result, the whole process took a little longer, but was much more flexible.

Try me

Request call

Become partner

–