Become Part of our Team and Push Digital Sovereignty
- Teamleader IT / Project Manager (m/f/x)
- IT Consultant (m/f/x)
- Outbound Sales Represantative (m/f/x)
The variety of existing Open Source projects makes it easy to add new features to a modular product like UCS. The basic requirements for many things already exist and there are positive experiences with those software projects. At Univention, we pursue the goal of making these functions available to our users. In addition, we want to maintain the integration with our core components. This maintenance is definitely the larger part of the work, which is very noticeable during upgrades. One goal of UCS 5.0 is therefore to focus on the functions that strengthen the core benefit of UCS and to prevent that UCS will become unmaintainable due to feature overkill. Unfortunately, this means saying goodbye to functions and projects that won our hearts. Thus, we first have to close some chapters before we can rejoice over new features in future blog articles.
The fifth major release of Univention Corporate Server is ready and available for download. UCS 5.0 contains new features, has a fresh look, comes with several improvements and bug fixes. The new version also uses a new core: UCS 5.0 is based on Debian 10 (“Buster”) and Python 3….mehr lesen »
With UCS 5.0 we will update UCS onto the current and stable Debian platform. In the course of this process, several changes and results from decisions made by the Debian team will also affect UCS. I will not specify them here (feel free to check out the Debian Release Notes for further reference), but we also want to modernize the base.
One section that we will no longer support in UCS 5.0 is updating systems with the i386 architecture, i.e. operating UCS as a 32 bit operating system. Installation media for this architecture have not been available for some time now. With UCS 5.0, you will also no longer be able to update from existing 32-bit systems.
Another part of our base updates is the removal of the “runsv” service and the associated package “univention-runit”. This service was introduced to monitor other services and restart them in case of problems. With “systemd”, this task can be executed more easily and services such as the Univention Notifier, Univention Listener or the DHCP daemon will be converted accordingly.
As one of UCS’ most important components, Samba 4 now emulates a Windows Active Directory including compatible file and print services. Prior to UCS 3.0, it was standard to operate as a Windows NT domain – and in relation to upgrades, the UCS 4.0 releases (and further releases as well) also support this operating mode in a restricted form. With UCS 5.0 we will say goodbye to this. A new installation in the “old” mode of a Windows NT domain has not been possible for some time now. Users who have not migrated yet will have to do so before updating to UCS 5.0.
When saying goodbye to Windows NT domains, we also remove elements which are no longer needed. These include little helpers such as the “samba4wins” which allowed to run redundant WINS servers next to NT-compatible domain controllers under UCS. This will no longer be needed for Samba as an AD compatible domain controller.
The decision we have dealt with the longest and most intensively – internally and also in the exchange with customers – was the use of the Univention Virtual Machine Manager (UVMM).
We designed UVMM to meet the virtualization needs of small and medium-sized environments. It offers an easy-to-use graphical front-end for daily work, but thanks to its basis of KVM, QEMU and libvirt, it can also be used to build large virtualization environments with the appropriate expertise. It is used almost exclusively in simple scenarios, for example to provide additional services as a virtual machine on site servers.
When UVMM was introduced with UCS 2.4 over 10 years ago, tools to administer virtualization on Linux servers with a simple, remotely operable interface were missing. UVMM has successfully closed this gap in many projects. Univention’s focus was to be able to operate machines with different operating systems. In order to do so, we not only developed the UI but also supported upstream projects, including the availability of acceleration drivers for Windows operating systems. Thanks to the intensive and committed work, even with difficult details of the network stack or the live migrations, we have meanwhile developed an almost emotional attachment to this component – and changes are thus hard for us.
The possibilities and the available tools for virtualization under Linux have multiplied in the last years. Today there are numerous alternatives to UVMM out there. At the same time, virtualization is not the reason why UCS is used. In fact, it seems that people are using it simply because it is available. However, the tasks of UVMM can also be performed by the standard KVM stack included in UCS by Debian as well as by supplementary tools.
In the course of developing UCS 5.0 we therefore decided to no longer maintain UVMM for controlling virtualization. The basic components such as KVM, QEMU and libvirt will continue to be available for UCS. They will also continue to be part of the product support. Operating virtual machines under UCS will also be possible in the future, and existing virtual machines will continue to function. However, we will no longer maintain the graphical administration ourselves but recommend Open Source tools instead. Details will be communicated together with the release of UCS 5.0.
There are many other components or apps that have been available in UCS for a long time. We have also tested them for their actual benefit to our users. As to some of them, we have decided to no longer offer them for UCS 5.0:
Worthy successors for a number of UCS apps and components that are no longer “state of the art” can be found at our App Center today. Said apps and components are often accompanied by a lack of maintenance of the original software. Here we have planned the following replacements:
As already mentioned in the blog article on the changes of the system roles, we have removed some computer object types from Univention Directory Manager. Those were left over from the UCC and TCS products we discontinued a long time ago. These products also contained some packages which should simplify the work with UCS as a Linux terminal server or desktop system. The following are also no longer needed: “univention-passwd-cache” took over the transfer of passwords within a desktop session, while “univention-check-printers” monitored USB printers for accessibility.
For compatibility reasons, there was the package “univention-java”, which enabled access to the Univention Configuration Registry via Java. This package is also no longer required. With earlier versions of the proxy in UCS, access to Internet pages was controlled specifically via configurable rules in Dansguardian. Nowadays other Squid plug-ins have assumed this task.
A farewell is simultaneously a direct step into the future: As announced, we are switching our implementations from Python 2 to Python 3. In the pre-release, we will have already migrated the Univention Directory Manager and Univention Configuration Registry to Python 3 as well as other implementations based on it, such as the Samba4-Connector.
Not all of the announced changes can be carried out unnoticeably in the background. Some of them will also require intervention by the administrators of UCS and produce changes for the users. For all the changes announced here, the following applies: We are working to make these transitions as easy as possible. We will automate changes wherever it makes sense and will document them wherever it is necessary.
After the many goodbyes in this article, I look forward to using the next few blog posts to take a look at the improvements and innovations in the focus areas of UCS. Accompanying the actual pre-release, we will have more info available for you.
In other words, it is all broken and no longer works. Thanks for the good 2 years anyway! nothing works now, just one long pain-in-the-do a bunch of extra work instead of using actual working solutions. No thanksReply
i´m sorry that you have troubles after the update to UCS 5.0. Maybe you could describe your concrete problems in our help-forum or have a look, if the problem is already mentioned and there are possible ways described to solve the issues you are facing.Reply
I’m not sure what Lanny meant, but for us, giving up UVMM is a loss of 50% of UCS capability.
In many cases, container versions of applications from the repository are inconvenient to use, so we use them as independent virtual machines. We also have many dedicated applications or not available in the UCS repository. Giving up the UVMM forces us to think seriously about what to do next step …
Hi gxb, thank you for your feedback!
We discussed internally a lot about virtualization & UCS, and the decision wasn’t easy as we know that UVMM is in use. But we also saw that typicall professional IT deployments don’t mix virtualization with services, so in most cases UCS itself runs in a virtual machine. Furthermore there are various Open Source solutions out there which allow virtualization with more features than UVMM.
And if you want to keep your virtual machines on UCS 5.0 you will still find a stable and working KVM hypervisor and “virsh” as commandline tool as part of the UCS stack. You can manage virtual machines with Open Source tools like “cockpit”, which is available as unmaintained software directly in UCS 5.0.
Focus of UCS will always be to provide the best place to adminstrate your user accounts and integrate service for the end users.