10. December 2024

The tentacles of orcharhino – Deploying with many subnets

Setting up and deploying servers manually and individually is a tedious task. But wait a minute – there’s orcharhino, which automates exactly that. With our data center automation tool, hosts can be configured, provisioned and deployed at the touch of a button.

But let’s assume the following: Servers in various branch offices or hosts operated in isolated network segments (DMZ) with severely limited access to the outside are to be managed centrally. This is where the orcharhino proxy can help.

This acts as a “contact person” for the orcharhino. There are now two options for the further procedure: By default, the host repositories are mirrored directly on all proxies. As each host addresses the subnet of the associated proxy directly, high traffic to and from the orcharhino is avoided. For servers within a DMZ, only one exception is required in the firewall to ensure communication between the subnet and orcharhino .

However, if many subnets are in use, there is a risk that the resource storage space will become scarce. In such a case, the identical content must be mirrored many times to different locations. However, this can be avoided by configuring the proxy so that requests from the hosts are passed directly to orcharhino. This works as follows:


1) Installation:

First, a virtual CentOS machine is deployed in the access-restricted network (e.g. via VMWare or directly via orcharhino). The proxy is set up on this machine. To install this, the orcharhino packages are required in the next step. To obtain these, the corresponding point must be created on the orcharhino and the repositories synchronized:

The content view is now created from this:

and Activation Key are generated:

The next step is to ensure that the proxy knows the name of the . There are two ways to do this. Either you enter the orcharhino with its name and IP address in /etc/hosts or you write the DNS in which the orcharhino is registered in /etc/resolv.conf. The proxy host is then registered on the orcharhino with the activation key. With the command

yum -y -t install orcharhino

the orcharhino packages are installed

As soon as the packages have been installed, the proxy setup continues. To avoid error messages, it must be ensured that orcharhino knows the name of the new proxy. To do this, the proxy must simply be entered in the DNS. The certificate for the proxy can now be generated in the orcharhino console:

foreman-proxy-certs-generate --foreman-proxy-fqdn "" --certs-tar "~/-certs.tar"

This is then copied to the proxy. In the next step, the installation command for the proxy content is executed on the proxy’s console using the foreman installer. Conveniently, the commands for copying and installing are displayed on the orcharhino immediately after the certificate has been generated. For smooth communication between orcharhino, proxy and the hosts, the parameter -enable-foreman-proxy-plugin-pulp must be added to the installer. Although the proxy is not yet fully configured, it is now activated.


2.) Configuration:

The next step is to create the subnet in orcharhino.

The proxy is now assigned to the organization and the location, but not to a lifecycle. To mirror the content on the proxy, it must first be synchronized.

If there is not enough memory available for synchronization, you must specify in the settings that the hosts connected via the proxy do not receive their packets directly from the proxy, but from orcharhino via the proxy server. This is easily done by configuring the proxy server service squid (which is already installed and started when the proxy content is installed).

In both cases shown, the hosts in the relevant subnet are not registered at orcharhino, but at the proxy. However, if the packets are not obtained from the proxy but from the orcharhino, the orcharhino itself must also be specified as the baseurl for the packet supply.

subscription-manager register โ€“baseurl=/pulp/repos --org=ATIX --activationkey=centos7-lib

Finally, this must be communicated to the package manager.

This means that different networks and zones are no problem for administration with orcharhino. These can be supplied with an orcharhino without having to create new firewall rules for each host. In addition, a proxy does not just have to be a proxy, it can also be a puppet master, DNS or DHCP server or take on other tasks in the corresponding zones.

Further contributions

Ready to get started?
Start your
free trial today!

If you have any questions about our products and services or any other
topics, please do not hesitate to contact us.

Suche
Search