Errata for debian-based systems in orcharhino
English Version
Release 4.0.0 of orcharhino not only brought a completely revised interface, but also another eagerly awaited feature: Errata management for Debian and Ubuntu hosts.
This marks a new milestone in the development of orcharhino. For over a year now, we have been working continuously on expanding Debian/Ubuntu support. You can find a short overview here.
The perfect day for the presentation of the newly integrated Errata support for Debian-based systems was of course the Open Source Automation Day last October.
Excursus:
Errata are, so to speak, package inserts that offer a solution to a known problem. The aim of an errata is to provide the admin with information on which packages need to be updated in order to eliminate a (security) problem.
In the Debian world, the concept of errata is not very common. The common approach here is the regular automatic installation of all updates from “debian-security” (or ubuntu-security). However, this approach is dubious, especially for servers in a business-critical environment. You should think very carefully about whether you really want to automatically install or update packages such as “nginx” or “openssl” on all productive web servers of a web application overnight.
Since the release of orcharhino 4.0.0, the admin now has full control over the Debian / Ubuntu systems managed by orcharhino. They can now decide which servers should receive which security updates and when. Errata support for Debian / Ubuntu systems enables us to provide significant support to every admin via a standardized interface.
The configuration of the Debian/Ununtu errata feature is very simple: Debian/Ubuntu security updates are provided via the “debian-security” (or “ubuntu-securtiy”) repository. The errata is now added to this repository by setting the “Errata-URL: https://dep.atix.de/dep/api/v1/debian”. This URL is used to prepare the errata information for Debian or Ubuntu and make it available in a machine-readable format for orcharhino. On the overview page of the repositories available in a product, the number of errata in a repository is now displayed
Preview: Application Centric Deployment (ACD)
Not part of the orcharhino 5.5 release itself, but we spent a lot of time working on another way to deploy whole applications: application centric deployment (ACD). Currently, orcharhino is host centric, i.e. you deploy a host and then configure the host using Ansible, Puppet, or Salt. With ACD, we go one step further and leave the host-centric approach behind.
Modern applications are usually distributed on several servers. Take a web application, for example: it requires a database, a web server, an application server like JBOSS, and a web proxy that distributes the requests to the web servers. Until now, four hosts had to be individually deployed and configured with orcharhino. With ACD, we want to look at the application in its entirety: deploying and configuring four hosts with an Ansible Playbook – so that at the end, a coherent web application is created. The configuration is done in a way that the web proxy already knows its web servers and can forward the requests; the web servers already have a connection to the application server; and the application server has already integrated the database server – everything is already coordinated.
While we were working on 5.5, we also laid the foundation of ACD. Application Centric Deployment will be available to our customers with the release of orcharhino 5.6. Until then, you can already have a look at screenshots of ACD.
We welcome your feedback regarding potential use cases you envision in your organization
Renaming smart proxy to orcharhino proxy
With orcharhino 5.5, we are renaming hosts running smart proxy functionality from smart proxy to orcharhino proxy. Both the orcharhino as well as the orcharhino proxy may incorporate smart proxy functionality depending on their configuration.
An orcharhino proxy allows you to deliver content and manage hosts in additional networks. It may be configured to either mirror synced content from your orcharhino or pass-through content using Squid from your orcharhino to its hosts. This is called smart proxy functionality and includes DNS, DHCP, TFTP, and CA capabilities.
The term smart proxy is used throughout the management UI. It describes the smart proxy functionality present on both your orcharhino as well as any attached orcharhino proxies.
Additionally, there are HTTP proxies as a way of relaying network traffic from one machine to another. They are often part of more advanced internal network architectures.
There are two general ways of using orcharhino proxies: orcharhino proxies running Squid to relay network traffic or running Pulp to mirror software packages. Find out more in our updated blog post orcharhino proxies -what is it and why do I need it?
Bug Fixes
- Remote Execution on ipv6 only host is failing
- applicable packages are displayed incorrectly
- Suse Scc Manager: Show “Test Connection” Failed, but repositories could be synchronized
- Orphaned packages no longer deleted by katello:delete_orphaned_content
- Ansible on windows needs parameter ansible_become_method=enable
- Code revert function is not working
- Proxmox: disk-storage scsi-controller doesn’t work
- OS matcher for ansible variables not working
