Update 2018-08-10 Package management in orcharhino
With the release 3.6.0 we have raised the Debian support in orcharhino to a new level! In addition to the support of the orcharhino client for Ubuntu systems, we have added the package management of Debian-based systems in orcharhino: If a Debian-based system is managed via orcharhino, the installed packages of this system are listed in orcharhino from release 3.6.0. Packages from this list can be selected and the uninstallation of these packages from the system can be triggered.
In addition, masks are available for installing, deleting or renewing packages on this system. Furthermore, all packages on this system can be updated with a single command. The installation/uninstallation/update runs – as already described – via a separate mask. As soon as the action has been started, progress can be tracked step by step and a summary of the commands executed is displayed at the end, e.g. to install a “less” package. As soon as the action has been successfully completed, you naturally want to see the current status of the system again in orcharhino. For this purpose, the Debian-based system executes a hook script that updates the current package list in orcharhino. This means that you can always see the current status of the systems directly in orcharhino and do not have to switch to the respective systems.
This is an important step for us in the direction of Debian support in orcharhino. But there is more to come – stay tuned. After we developed our own plugin for the integration of the SUSE Customer Center in June and massively improved the SUSE support of orcharhino, the support of 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 such as Ubuntu or Linux Mint (if someone wants to use this on the server). But what exactly is new about it? Until now, you could use orcharhino Debian systems and then configure them using Puppet, Ansible or SaltStack. As package management for Debian did not yet exist in orcharhino did not yet exist, it was not possible to implement lifecycle management for Debian Server via orcharhino could not be implemented. However, this feature is the elementary component of our orcharhino For an administrator it is essential to keep control over which packages are provided in which version for the respective servers of the different lifecycle environments such as development, testing and production. 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 recent months to provide our customers with this missing piece of the puzzle. 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 extending our build system significantly, but we have also written many lines of code in some open source projects like Pulp, Katello and Runcible and integrated our Debian extensions. Now you surely want to see how the package management for Debian is implemented.
As with RPM-based systems, you first need a product. Various repositories can then be added to the product – such as “yum”, “Puppet” or even “deb” for Debian-based systems. What should be noted with “deb” is that the URLs of the repositories are always the same and a differentiation of “Component”, “Release”, “Architecture” is specified via a filter.
After you have added the repository, you must synchronize it. This will download all Debian packages from the upstream repository that also match the filter for “Component”, “Release” and “Architecture”. Lifecycle management is now implemented via Content View. After creating a new content view, you select various repositories that are managed within this content view. Different types of repositories can be combined into one content view. We have added the “deb Repositories” type here. In this tab you can see a list of repositories already assigned to the content view. On the other hand, you can assign further 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 release of Debian Support that was it – almost. Briefly on the use of the content view: For RPM-based systems, one is used to getting access to the provided Content Views via an Activation Key. This is where we want to go with Debian. Unfortunately, this does not yet work so elegantly, but we are working hard on it.
However, we have created a way to use the content view anyway: Using a provisioning template provided by us, the /etc/apt/sources.list is manipulated when the Debian host is installed and the repositories of the Content View are automatically entered.
This provisioning template is automatically installed via our orcharhino web installer automatically. 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 provided. Of course, the configuration files for Debian, Ubuntu and other Debian-based systems can also be managed via Ansible, puppet or SaltStack.
In future, we want to manage the Debian systems in the same way as CentOS, Redhat or SuSE. For us in the development team at ATIX AG, 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 for our customers.
orcharhino goes the deb-way – English
Update 2018-08-10 package management in orcharhino
With the release 3.6.0 we have taken Debian support in orcharhino to a new level! Besides the support of the orcharhino client for Ubuntu systems we have added the package management of Debian-based systems in orcharhino: If a Debian-based system is managed via orcharhino, the installed packages of this system will be listed in orcharhino as of Release 3.6.0. Packages from this list can be selected and the uninstallation of these packages can be triggered by the system.
Additionally, masks are available to install, delete or renew packages on this system. In addition, all packages of this machine can be updated with a single command. The installation / uninstallation / update runs – as already described – via a separate mask. Once the action has started, progress can be tracked step by step and finally receives a summary of the commands executed, e.g. to install a “less” package. As soon as the action is successfully completed, you want to see the current status of the system in orcharhino again. For this purpose, the Debian-based system executes a hook script that updates the current package list in orcharhino. This means that you always see the current status of the systems directly in orcharhino and do not have to switch to the respective systems.
This is an important step towards Debian support in orcharhino for us. But there’s more – stay tuned. After we developed our own plugin for the integration of the SUSE Customer Center in June and massively improved the SUSE support of orcharhino, support for Debian-based systems was at the top of our agenda. In addition to Debian itself, we also count Linux distributions using the “deb” package format, i. e. distributions like Ubuntu or Linux Mint, as Debian-based systems. But what exactly are the news here? Up to now you could install Debian systems with orcharhino and configure them using Puppet, Ansible or SaltStack. Because the Debian package management for Debian did not yet exist in orcharhino, it was not possible to implement the lifecycle management for Debian servers via orcharhino. However, this feature is the elementary part of our orcharhino story: Deployment, Patch Management, Configuration Management. It is essential for an administrator to retain control over which packages are made available in which version for the respective servers of the different lifecycle environments such as development, testing and production. 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 make this missing piece of the puzzle available 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 not only extend our build system significantly, but we have also written many lines of code for open source projects such as Pulp, Katello and Runcible to integrate our Debian extensions. But enough of words. Surely now you want to see how the package management for Debian is implemented.
Similar to RPM-based systems, you first need a product. Different repositories can then be added to the product – such as “yum”, “puppet” or “deb” for Debian based systems. What needs to be considered with “deb” is that the URLs of the repositories are always the same and a distinction is made between “Component”, “Release”, “Architecture” via a filter. After adding the repository, you have to synchronize it. All Debian packages will be downloaded from the upstream repository, which are also in accordance with the filters for “Component”, “Release” and “Architecture”.
Content View now implements lifecycle management. After creating a new content view, you select different repositories that are managed within this content view. You can combine different types of repositories into one content view. We have added the type “deb repositories” here. In this tab you can see a list of repositories already assigned to the content view. On the other hand, you can assign further repositories.
As usual, you have to publish this content view via “Publish” and later assign it to the respective lifecycle environment via “Promote”. And thats it for our first release of Debian support – almost. A brief comment on the use of the content view: For RPM-based systems, you are used to having an activation key to access the provided content views. This is also the point we want to reach with Debian. Unfortunately, it doesn’t yet work as elegantly as we would like, however we are working hard to get it done as quickly as possible. We have created a way to use the content view anyway: A provisioning template, provided by us, manipulates the /etc/apt/sources. list of the Debian host during the installation and automatically enters the repositories of the content view. With our orcharhino web installer this Provisioning Template is automatically installed. It also ensures that the Debian host only gets the packages in the versions provided by the content view of its lifecycle environment. If you provision a new Debian host, the packages will be 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 analogous to CentOS, Redhat or SuSE. Debian support is still at the top of our roadmap in the ATIX AG development team. We will continue to work with the Foreman / Katello community to provide the best possible Debian support for our customers in orcharhino.
