Click here for the English version

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.

The Tentacles of orcharhino – Deploying with Many Subnets

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

But consider this: Servers in different branch offices or in isolated network segments (DMZ) should be managed centrally with strongly limited access to the outside. This is where the orcharhino proxy comes in.

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

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

1) Installation:

First, a virtual CentOS machine is deployed in the restricted network (e.g. via VMWare or directly via orcharhino). The proxy is set up on this machine. The next step is to install the orcharhino packages. To get them, the appropriate point must be created on the orcharhino and the repositories synchronized:

The Content View is now created from this:

and Activation Key as well:

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

yum -y -t install orcharhino

the orcharhino packages are installed

Once the packages are installed, the proxies will continue to be set up. To avoid error messages, it must be ensured that orcharhino knows the name of the new proxy. To do this, the proxy simply has to be entered into the DNS. Now the certificate for the proxy can be generated in the orcharhino console:

foreman-proxy-certs-generate --foreman-proxy-fqdn "" --certs-tar

This is then copied to the proxy. In the next step, the installation command for the proxy content is executed on the console of the proxy using the foreman-installer. Conveniently, the commands for copying and installing on the orcharhino appear immediately after the certificate is generated. For smooth communication between orcharhino, proxy, and the hosts, the installer must add the -enable-foreman-proxy-plugin-pulp parameter. Although the proxy is not yet fully configured, it is now enabled.

2.) Configuration:

In the next step, the subnet must be created in orcharhino.

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

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

In both cases shown, the hosts in that subnet are registered on the proxy rather than on orcharhino. However, if the packets are not obtained from the proxy, but from orcharhino, you must additionally specify orcharhino itself as the source as the baseurl for the package supply.

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

Finally, the package manager has to be informed about this.

Thus different networks and zones are no problem for an administration with orcharhino. They can be supplied with orcharhino without having to create new firewall rules for each host. In addition, a proxy does not have to be just a proxy, it can also be a Puppet Master, DNS or DHCP server in the appropriate zones, or perform other tasks.