Errata für debian-basierte Systeme in orcharhino
English Version
Release 4.0.0 von orcharhino brachte nicht nur ein komplett überarbeitetes Interface, sondern ein weiteres heiß ersehntes Feature mit sich: Die Errata Verwaltung von Debian bzw. Ubuntu Hosts.
Damit setzen wir einen neuen Meilenstein in der orcharhino Entwicklung. Bereits seit über einem Jahr arbeiten wir kontinuierlich am Ausbau des Debian/Ubuntu Supports. Eine kurze Übersicht darüber findet Ihr hier.
Der perfekte Tag für die Präsentation des neu integrierten Errata Supports für Debian-basierte Systeme war natürlich der Open Source Automation Day im vergangenen Oktober.
Exkurs:
Errata sind sozusagen Beipackzettel, die für ein bekanntes Problem eine Lösung anbieten. Mit einem Erratum möchte man also dem Admin die Informationen bereitstellen, welche Pakete aktualisiert werden müssen, um ein (Sicherheits)-Problem zu beseitigen.
In der Debian Welt ist das Konzept von Errata nicht sehr verbreitet. Die gängige Devise ist hier die regelmäßige automatische Installation aller Aktualisierungen von „debian-security“ (bzw. ubuntu-security). Gerade bei Servern im unternehmenskritischen Umfeld ist diese Herangehensweise jedoch zweifelhaft. Denn man sollte sich sehr genau überlegen, ob man wirklich Pakete wie „nginx“ oder „openssl“ automatisch auf allen produktiven Webserver einer Webanwendung automatisch über Nacht installieren bzw. erneuern möchte.
Seit dem Release von orcharhino 4.0.0 hat der Admin nun die volle Kontrolle über die von orcharhino verwalteten Debian / Ubuntu Systeme. Er kann nun gezielt entscheiden, welche Server, zu welchen Zeitpunkt, welche Sicherheitsupdates erhalten sollen. Der Errata Support für Debian / Ubuntu Systeme ermöglicht es uns, jeden Admin über eine einheitliche Oberfläche maßgeblich zu unterstützen.
Die Konfiguration des Debian/Ununtu Errata Features ist denkbar einfach: Die Bereitstellung der Debian / Ubuntu Sicherheitsupdates erfolgt über das „debian-security“ (bzw. „ubuntu-securtiy“) Repository. Diesem Repository fügt man nun die Errata hinzu, indem man die „Errata-URL: https://dep.atix.de/dep/api/v1/debian“ setzt. Über diese URL werden die Errata Informationen für Debian bzw. Ubuntu aufbereitet und in einem maschinenlesbaren Format für orcharhino zur Verfügung gestellt. Auf der Übersichtsseite, der in einem Produkt vorhandenen Repositories, wird nun die Anzahl der Errata in einem Repository angezeigt
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
