2018 so far has been a great year for Veyon. The release of Veyon 4.1 marks a milestone with important improvements in all areas. Since then lots of bugs were fixed resulting in several maintenance releases. If you’re wondering what we’re planning for 2019 read on.
About 10 months after we launched Veyon 4.0.0 we’re happy to announce Veyon 4.1.0. First of all we would like to thank everyone who helped to make up this release, especially the people who kept on testing and giving feedback. The new 4.1.x release series brings major improvements and changes, most importantly regarding platform integration and administration. We already blogged about the most notable achievements in previous articles but of course we want to give you a summary of highlights you’ll find in this new release:
Maybe you have already read about the new features and improvements coming with Veyon 4.1 in previous articles. You might have noticed that most of the described changes “only” affect internal implementation details, administrative tasks or technical details regarding the operating system integration. While this is basically true we also have goodies for the end user (i.e. teachers). We’d like to present the most notable one in this article.
If you use Veyon without LDAP/AD integration you always have to configure rooms and computers (in general also referred as network objects) manually. In Veyon 4.0 rooms and computers could only be added one by one using the graphical interface provided by Veyon Configurator. Starting with Veyon 4.1 there are additional possibilities which allow scripted and automated management of network objects.
As you might have already read Veyon 4.1 will come with full systemd support. This means on Linux the Veyon Service can now be managed the same way as it has been possible on Windows for many years. Unlike typical Linux daemons/services such as SSH, HTTP or database servers the Veyon Service requires full access to graphical user sessions. Moreover it’s recommended to run the process as a different user (usually root) in order to prevent users from killing the process to avoid control by the instructor. These requirements made things a bit complicated and required some fundamental changes in the implementation.