orcharhino goes the deb-way
Update 2018-08-10 Package management in orcharhino
With release 3.6.0 we have taken Debian support in orcharhino to a new level! In addition to supporting the orcharhino client for Ubuntu systems, we have added package management of Debian-based systems in orcharhino: If a Debian-based system is managed via orcharhino, from release 3.6.0 the installed packages of this system will be listed in orcharhino. Packages from this list can be selected and the uninstallation of these packages from the system can be initiated. 
In addition, masks are available to install, delete or renew packages on this system. In addition, all packages of this system can be updated with a single command. The installation/uninstallation/update takes place – as already described – via a separate mask. As soon as the action has started, progress can be tracked step by step and finally you will receive a summary of the commands executed, for example to install a “less” package. As soon as the action has been successfully completed, you would of course want to see the current status of the system again in orcharhino. For this purpose, the Debian-based system runs a hook script that updates the current package list in orcharhino. This means you can always see the current status of the systems directly in orcharhino and you don’t have to go through the hassle of switching to the respective systems.
This represents an important step for us towards Debian support in orcharhino. But there is more to come – stay tuned.
After we developed our own plugin to integrate the SUSE Customer Center in June and massively improved the SUSE support of orcharhino, supporting Debian-based systems was now at the top of our agenda.
In addition to Debian itself, Debian-based systems also include Linux distributions that use the “deb” package format, i.e. distributions like Ubuntu or Linux Mint (if someone wants to use this on the server).
But what exactly is new about it? Previously, you could install Debian systems with orcharhino and then configure them using Puppet, Ansible or SaltStack. Since package management for Debian did not yet exist in orcharhino, lifecycle management for Debian Server could not be implemented via orcharhino. However, this feature is the fundamental part of our orcharhino story: Deployment, Patch Management, Configuration Management. For an administrator, it is essential to maintain control over which packages are provided in which version for the respective servers of the different lifecycle environments such as development, testing and production become. This is the only way to ensure that the correct packages and versions are installed on a server and, if necessary, updated via patch management. We have invested a lot of time and energy in the last few months to provide this missing piece of the puzzle to our customers. With the Tech Preview Release on the occasion of our Open Source Automation Day (http://www.osad-munich.de) we have closed this gap. With this feature we are not only significantly expanding our build system, but we have also written many lines of code in some open source projects such as Pulp, Katello and Runcible and integrated our Debian extensions. Enough of the words. Now you probably want to see how package management is implemented for Debian.
As with RPM based systems, you first need a product. Various repositories can then be added to the product – such as “yum”, “Puppet” or “deb” for Debian based systems. What should be noted with “deb” is that the URLs of the repositories are always the same and a distinction between “Component”, “Release” and “Architecture” is specified via a filter.
After adding the repository, you need to synchronize it. All Debian packages are downloaded from the upstream repository, which also correspond to the filter for “Component”, “Release” and “Architecture”.
Lifecycle management is now implemented via Content View. After creating a new content view, you select different repositories that will be managed within this content view. Different types of repositories can be combined into a content view. We added the deb repositories type here. In this tab you can see a list of repositories that have already been assigned to the content view. On the other hand, you can assign additional repositories.
As usual, you have to publish this content view via “Publish” and later assign it to the respective lifecycle environment via “Promote”. For our first Debian Support release, that’s it – almost. Briefly about the use of the content view: For RPM-based systems you are used to having access to the content views provided via an activation key. This is also where we want to get to Debian. Unfortunately, it doesn’t work so elegantly yet, but we’re working hard on it.
However, we have created a way with which you can still use the Content View: Using a provisioning template provided by us, the /etc/apt/sources.list is manipulated when installing the Debian host and the repositories of the Content View are automatically entered.
This provisioning template is installed automatically via our orcharhino web installer. It also ensures that the Debian host only receives the packages in the versions that are configured via the content view of the respective lifecycle environment.
If you create a new Debian host, the packages are provided directly via orcharhino. Of course, the configuration files for Debian, Ubuntu and other Debian-based systems can also be managed via Ansible, puppet or SaltStack.
In the future we want to manage the Debian systems analogously to CentOS, Redhat or SuSE. For us in the ATIX AG development team, Debian support is still at the top of our roadmap. We will continue to work with the Foreman / Katello community to provide the best possible Debian support for our customers in orcharhino.
