Tools to create multi distribution bootable USB stick got couple of new improvements and features.
live-usb-gui now offers choice of scripts to use, depending in your need you can either use live-fat-stick with vfat partitioned stick or live-grub-stick script which works with any partition format supported by grub2 including vfat, must be used if you have iso bigger than 4G.
We are happy to announce that Ramadoni Ashudi design from Indonesia is selected as official logo for openSUSE.Asia Summit 2016 in Yogyakarta, Indonesia. As the winner Ramadoni Ashudi will receive a “magic box” from the committee.
Ramadoni Ashudi submit two designs and his design-2 selected by 28 voters. His design depicts his version of Tugu Yogyakarta, a monument built by Sultan Hamengkubuwono I, the first King of Yogyakarta in 1755.
Ana Maria Martinez from Spain also submit her version of Tugu Yogyakarta and selected by 17 voters on the 2nd place.
On the 3rd place, Shawhong Ser from Thailand submit a design that showing Arjuna character from Wayang Kulit, a traditional Javanese shadow puppet. Arjuna is the 3rd Pandava Brothers from Mahabharata. It is selected by 9 voters.
Total of voters = 65
Ramadoni Ashudi-2 = 28
Ana Maria Martinez = 17
Shawhong Ser = 9
Aris Winardi = 4
Ramadoni Ashudi-1 = 4
Kukuh Syafaat = 3
Danang Aji Bimantoro-1 = 0
Danang Aji Bimantoro-2 = 0
The complete result can be seen on the contest web page
Congratulation to Ramadoni, and many thanks and appreciation to Ana, Aris, Danang, Kukuh, Shawhong for your participation in this contest.
Have fun.
openSUSE Conference’16, Hackweek 14 and the various SUSE internal workshops are over. So it’s time for the YaST team to go back to usual three-weeks-long development sprints… and with new sprints come new public reports!
With Leap 42.2 in Alpha phase and SLE12-SP2 in Beta phase our focus is on bugs fixing, so we don’t have as much fancy stuff to show in this report. Still, here you are some bits you could find interesting.
For our SLE customers we promise installations on machines with as little as 512MB of RAM. For Tumbleweed, 1GB is required – so the situation is more relaxed there.
But look at the total size of filesystem images that must be kept in memory during installation: 176MB for SLE12 (Tumbleweed: 224MB). This is leaving not much room to run programs.
The size has grown considerably over time, and we had to look for places to save space. We came up with some major areas for improvement.
The initrd and the installation system (the file system image containing the installer) share many files (mainly libraries). By removing any overlap, we were able to reduce the image size by 17MB for SLE12 (Tumbleweed: 30MB).
After the package installation starts, kernel modules and some raw libzypp cache data are no longer needed. By deleting zypp data we save another 3MB and kernel modules occupy even 29MB in SLE12 (Tumbleweed: 50MB). But we do this only on systems with less than 1GB memory.
So, compared to the available 512MB, these savings are quite substantial and will hopefully keep us going for a while…
It’s time for our reimplementation of the storage layer to prove it can do the real work. Thus, we have integrated the new code in a set of modified Tumbleweed ISO images automatically generated in OBS. They cannot still be used to install a system, but the installer is already able to boot and reach the language selection screen (the first milestone we were aiming for).
We already had code that works in a simulated test environment (unit tests) and now we have a way to use that code in a real installer. Stay tuned for exciting news!
For SUSE Linux Enterprise we offer so many optional modules that their listing did not fit on lower resolution screens. Below you can see how the screen looked before the fix – checkbox widgets and their labels do not fit so their bottoms are cropped.
We have to make sure YaST works across different interfaces, including text-based ncurses. That limits the set of widgets we can use when designing interfaces, so finding a solution to that kind of problems is not always easy. We also took the opportunity to add a filter for beta extensions, as you can see in the following screenshot.
And finally you can see how it looks like with all the extensions, including beta ones. Instead of cropping elements we now have a scroll-bar in the right.
The next step in the storage layer reimplementation is adding support for LVM, since right now only regular partitions are supported. We always write a lot of unit tests to make sure the different pieces work in isolation before integrating everything together into the installer. During this sprint we created all the infrastructure for testing LVM at such level. Armed with that, we can start writing reliable code to handle LVM (something we have already started to do).
We recently introduced the concept of system roles during installation. The chosen role affects the selection of package patterns. But we realized that the roles were not completely overriding the default selection of packages. Before the fix introduced in this sprint, desktop related patterns were included for a KVM server role and, thus, the systemd target was graphical.
Now, only the 3 patterns explicitly intended for the KVM role are selected, with no desktop related patterns. Accordingly, the system boots to text mode.
We have explained in several previous posts how we are collaborating with Grub and hardware architecture experts to make sure the new storage layer makes always sensible partitioning proposals. For that purpose RSpec has proven to be an excellent tool. It does not only allow us to have full unit test coverage or our code, but also the generated output has become the perfect base to discuss the expected behavior of the system in every possible scenario.
During this sprint, we spent quite some time together with SUSE’s Grub genius Michael Chang defining the best possible partitioning schema in x86 architectures. Once we had a human-readable and non-ambiguous specification, we modified our code to make sure the associated RSpec tests generated exactly the same specification as output. This way we make sure that our code works and that it fits 100% the experts expectations.
Kudos to Michael for his infinite patience with our questions and for coming up with an innovative way of using Grub2 that will allow us to boot in many tricky scenarios, eliminating the need of introducing a separate /boot in almost all cases.
As said, most of the sprint was invested in chasing bugs… and we don’t expect next sprint to be different in that regard. Even though, we hope this post to contain enough new stuff to keep you entertained and informed about what is going on in the YaST trenches.
See you in three weeks!
Recently we implemented Tally ERP 9 solution for Antico Pumps. That itself is not interesting, the interesting part is they are using LTSP Fat client system on openSUSE. They have only one server from which all their client computers boot over the network, the clients do not have hard disk, client OS with all softwares they need including wine(Tally is Windows only software), as well as users’ data resides on the server. Once the client boots all the local resources are used so single low power server can be used to serve many clients.
Tally multiuser is served from a Samba share on a NAS device, Tally folder is copied to samba share and path to Tally Data is changed so that it points there. Everything they need including printing and export(CSV) works from all clients. Same way Tally can be run on standalone computers. Neither Tally, Wine or openSUSE are modified for getting it working as it would under Windows environment.
Maintenance and security updates for the stable openSUSE Leap releases are automatically tested using OpenQA, and also receive community testing prior to release. In addition, many updates to openSUSE Leap are inherited from SUSE’s enterprise products, where they already receive thorough review, and automated as well as manual testing.
Should anything go wrong, here is how to “uninstall” an online update using zypper.
zypper in --oldpackage ` \
zypper info -t patch --conflicts openSUSE-2016-XXX | \
grep " < " | while read NAME C VERSION; do \
rpm --quiet -q --queryformat "%{name}\n" $NAME && echo "${NAME}<${VERSION}"; \
done`
Replace openSUSE-2016-XXX with the update in question. All involved packages are installed in a prior version. This, of course, is an alternative to using Btrfs snapshots. Note that the update will be offered again.
If you want to help review proposed online updates, just check the “untested updates” repo in YaST or add one of the -test repositories to receive updates early.
We have come a long way since the first Li-f-e live media based on openSUSE was created, the current release is based on openSUSE Leap 42.1. Deployments by Indonesia’s education system is a shining example of openSUSE Education project’s accomplishment.
The openSUSE project has stopped producing live medias for Leap and also live-installer is dropped from live medias created for the Tumbleweed distribution. As Li-f-e is primarily a live distribution we would not be able to create any more medias without live-installer. So unless this situation changes we may not have Li-f-e based on Leap 42.2.
In the meantime I’ve had a look at Ubuntu to create Li-f-e based on the latest LTS release of Ubuntu-Mate, check it out here. Software selection available is kept identical to the Li-f-e based on openSUSE, however there is always a room for improvement, suggestions to enhance it are always welcome.
If you need to make screenshots of the installation it is useful to influence their size. You could press F3 in the boot menu and choose from a menu, but that is not well suited for scripts such as openQA.
The installer now obeys an option from the boot command line: xvideo.
xvideo=[WIDTHxHEIGHT][,DPI]
xvideo=1024x768
xvideo=1024x768,100
xvideo=,100(Available in yast2-installation-3.1.195 + yast2-x11-3.1.5. bsc#974821)
You can now install from a repository served with HTTPS that has a self-signed certificate. Use a ssl_certs=0 boot option.
(Available in yast2-packager-3.1.104. bsc#982727)
Last sprint (S#20) we improved the registration UI. Now we’ve made one more improvement: pre-filling the Register System via local SMT Server field.
Before, the widget was a single text field and a little helpful smt.example.com was always shown (no matter what your actual domain was). 
Now, if your local SMT servers are advertised via SLP they will be offered as choices. (Here acme.com stands for your domain) 
(Available in yast2-registration-3.1.176. bsc#981633.)
We have started building an installation ISO image with the new storage library. The first build contains all the pieces but they don’t work together yet.
We have documented the supported scenarios regarding booting in the new storage layer.
(Tooling note: We made this with a Markdown formatter for RSpec invoked like this.)
If you opened Network Settings to review something, made no changes, and closed the dialog with OK, the network would be restarted. That may be undesirable if you have an Important Application running. We originally thought that everyone would close the dialog with Cancel, but we were proven wrong.
Now the module properly checks whether you have made changes to the settings, and omits the restart if appropriate.
(Available in yast2-network-3.1.155. FATE#318787)
Due to a problem in the AutoYaST version shipped with SLE 12 SP1 and openSUSE Leap 42.1, the network configuration used during the first stage was always copied to the installed system regardless the value of keep_install_network.
Upcoming SLE 12 SP2 and Leap 42.2 behaves as expected and keep_install_network will be set to true by default.
(Available in yast2-network-3.1.157 + autoyast2-3.1.133. Fixes bsc#984146.)
The latest Scrum sprint of the YaST team was shorter than the average three weeks and also a little bit “under-powered” with more people on vacation or sick leave than usual. The bright side of shorter sprints is that you don’t have to wait three full weeks to get an update on the status. Here you have it!
Until now debugging the YaST installation was usually done by checking the logs. If you needed more details you would add more log calls. This is inconvenient and takes too much time but, as every Ruby developer know, there is a better way.
Being a fully interpreted and highly introspective language, Ruby offers the possibility of simply intercept the execution of the program and open a interpreter in which is not only possible to inspect the status of the execution, but to take full control of it.
From now on, you can access those unbeatable debugging capabilities during the installation. All you have to do is boot the installer with Y2DEBUGGER=1.
Moreover the same mechanism is also available when running YaST in a installed system. Just make sure the rubygem-byebug package is installed and start the YaST module like this:
Y2DEBUGGER=1 yast2 <client>
For more details see the brand new documentation. You can also see several examples and screenshots of the debugger running in text mode, through the network and in other scenarios in the description of the corresponding pull request.
Most software enthusiasts and developers, specially free software lovers, will know the mantra “release early, release often“. The earlier you allow your users and contributors to put their eyes and hands on your software, the better feedback you will get in return. And that proved to be true one more time with YaST and the awesome openSUSE community.
In the previous post we introduced a new functionality being added to YaST2 – more explicit and interactive importing of SSH host keys. Some users quickly spotted some usability problems, right in time for the fixes to be planned for this sprint.
In the description of this pull request you can see several screenshots of the new interface in several situations, with the new main dialog looking like this.
Iterative development rocks when you have involved users. Keep the constructive criticism!
The user interface was not the only aspect of SSH host keys importing that got improved. For every feature we add to the interactive installer, we always take care of making it accessible from AutoYaST as well. Thus, an AutoYaST profile file can now contain a section like this to control the behavior of the new functionality.
<ssh_import>
<import config:type="boolean">true</import>
<copy_config config:type="boolean">true</copy_config>
<device>/dev/sda2</device>
</ssh_import>
Another success story about collaboration in the YaST world. In the report about sprint 18 we mentioned we had received some contributions in order to add Firewalld support to YaST2-Firewall and that we were collaborating with the authors of those patches to get the whole thing merged in Tumbleweed. After a couple of sprints allocating some time to keep that ball rolling, we can happily announce that YaST2-Firewall in Tumbleweed already supports the “classic” SUSEFirewall2 backend and the brand new Firewalld one!
SUSE’s VNC guru Michal Srb has been working lately in improving the ability to share and reconnect to VNC sessions. Until now, YaST always created a new separate VNC session for every client and closed the session when the client disconnected. There was no simple way to share the session with additional clients or to keep it running after disconnecting.
Now, thanks to Michal, the remote module can be set up in three different VNC modes: disabled, xinetd and vncmanager. Check the definition of each mode in the description of the pull request.
Six sprints ago, the “Local User” screen got some love and the UI was greatly improved. During this sprint, and according to bug #974626, we have improved the registration UI to make it consistent with the “Local User” screen.
The old interface, displayed below, was pretty confusing. Although it was not obvious at first sight, it offered three options:
Options 1 and 2 are mutually exclusive but, if you look at the interface, that fact is not clear. Moreover, we wanted this dialog to be consistent with the new “Local User” one.
The new dialog looks like this, with the three mutually exclusive options being directly presented to the user.
As always, redesigning a UI in YaST implies making sure it works nicely in the NCurses interface with screens with a resolution of 80 columns and 25 lines of text. Doesn’t it look nice (provided the reader has a geeky aesthetic sense)?
As usual, progress goes steady in the rewrite of the storage layer. In this sprint we invested some time into the partitioning proposal, which is now able to propose a good layout in some very complex scenarios with highly fragmented disks with limited partition schemas.
In addition, preliminary support for LVM was added although is still far from being complete and full-featured.
We always finish our reports saying something like “this was just a sample of all the work done, stay tuned for another report in three weeks”. But the weeks ahead will be a little bit unusual. This week a SUSE internal workshop is taking place. That means that many YaST developers are focusing on stuff different from their daily duty. In addition, openSUSE Conference’16 and Hackweek 14 are both round the corner. As a result of all those “distractions”, next sprint will be shorter than usual (just one week) and will not start immediately. Expect next report at some point close to the start of openSUSE Conference. By the way… see you there!
Here we are after another Scrum sprint with our usual report about the activity in YaST development.
YaST bootloader module got a new option, Trusted Boot (FATE#316553). It installs TrustedGRUB2 instead of the regular GRUB2. Trusted Boot means measuring the integrity of the boot process, with the help from the hardware (a TPM, Trusted Platform Module, chip).
It enables some interesting things which we unfortunately haven’t provided out of the box. We give you a bootloader which measures the boot integrity and places the results in Platform Configuration Registers (PCRs).
First you need to make sure Trusted Boot is enabled in the BIOS setup (the setting is named Security / Security Chip on Thinkpads, for example). Then you can enable the new YaST Bootloader option that will install TrustedGRUB2.
In the description of this pull request you can find a more detailed explanation including some commands and hexadecimal dumps to check the result. Geek pr0n!
When looking at any software project, it’s common to find some feature or piece of code that is there due to the so-called “historical reasons”. YaST2 code-base has been around since 1999, adapting to changes and new requirements in a (almost literally) daily basis since then. That leads to a new level of heritage – the “prehistoric reasons”. Working in the YaST Team implies coding, debugging, testing… and archaeological research.
We got a bug report about the installer “stealing” some SSH host keys (but not all of them) from previously installed systems. It was actually the effect of a little-known YaST feature that can look surprising (not to say weird) at first sight. Ten years ago, somebody decided that when installing SUSE in a networked environment, where people use SSH to log in, it was better to import SSH keys from a previously installed Linux than to get that “ssh host key changed” for everybody who tries to connect. The rational was that forcing everybody to change the ~/.ssh/known_hosts file often could become a security breach, since people could get used to ignore the security warnings. Welcome to the world of historical reasons. 🙂 Moreover, it was decided that the operation should be performed without showing any information to the users, in order to not confuse them.
More or less at the same time (we are still talking about 2006), it was decided to introduce importing of users from an existing system, this time with user interaction. The YaST developers decided that it would be fine to share some mechanisms in the implementation of both features. Another step into the historical reasons void.
Fast forward to the present. After several fate entries, bug reports and redesigns over the years, we decided to make the importing of SSH host keys more visible and usable, to make both functionalities (SSH import and users import) more independent and more clean and to take the first step to clean up the insanity introduced through the years (see fate#320873 for details).
The installer does not longer silently just import the SSH host keys from the most recent Linux installation on the disk (remember, you might have several distributions installed), it has now become a part of the installation proposal dialog:
And from there you can change it:
Notice that one of the options is “none”, so copying of previous keys is not longer enforced. In addition, now is also possible to import the rest of the SSH configuration in addition to the keys.
When installing from a local media, like a CD/DVD or an USB stick, those sources were still enabled after the installation. It potentially could cause problems during software installation, upgrade, migration, etc. because an old or obsolete installation source is still there. On the other hand, if the source is physically removed (for instance, ejecting the CD/DVD), zypper will complain about that source not being available.
Fortunately, this behavior will change in future SUSE/openSUSE versions. Now, at the end of the installation, YaST will check every local source disabling those whose products are available also through a remote repository (so they’re not needed at all).
Support for bonding interfaces with NPar or SR-IOV capabilities has also been improved during this sprint. Too many weird words in one sentence? Don’t worry, we actually love to explain things.
Bonding is a way to combine multiple network connections to increase the throughput and bandwidth and to provide redundancy. On the other hand, NPAR and SR-IOV are technologies that provide the capability to create multiple virtual devices from the same physical or ethernet port.
Until this sprint, YaST offered no way to know whether two interfaces with these capabilities were sharing the same physical port. As a result, users could bond them without realizing that they were not getting the desired effect in terms of redundancy.
Information about the physical port ID has been added to all the relevant dialogs for all devices supporting it, like it’s shown in the following screenshots.
Additionally, the user will be alerted when trying to bond devices sharing the same physical port.
Last but not least, following the Boy Scout Rule (also known as opportunistic refactoring), we took the opportunity to fix some small quirks in YaST Network, like the counter-intuitive sorting of devices in some lists.
Somebody said once “a promise made is a debt unpaid“. In the previous post we promised you all an article on Snapper.io detailing the new space-aware cleanup introduced in Snapper. Here you are!
Enough for a blog post. That’s of course not all we did during the last sprint (to the contrary, it’s just around 20% of the finished work according to the story points count) but, you know, we need to go back to hacking!
The wait is over, the report of the latest Scrum sprint of the YaST Team is here! In the previous post we promised that after this sprint we would have much more to show… and now we do. This sprint was quite productive, so let’s go straight to the most interesting bits.
The YaST self-update feature mentioned in the two previous blog posts (sprint 16 and sprint 17) has also received a couple of improvements.
At this gist (with screenshots) you can see some of the fixes done when going back and forward in the work-flow after an installer self-update.
But even more important are the improvements done in AutoYaST to properly handle the new feature. If you want to use your own self-update repository you have to specify it on the boot command line. This is easy in a single installation, but if you want to install many machines using AutoYaST then writing the possibly long URL at each installation again sounds annoying.
In this sprint we improved handling of the custom update URL so that it can be read from the AutoYaST XML profile. Now you need to write the custom URL only once into the profile and it will be used automatically in every AutoYaST installation.
There is not much to show in the UI, the log proves that the self update was really loaded.
You can find more details about specifying the URL in the profile and evaluating the self-update repository URL at the documentation.
For quite some time, we have had the plan to stop using Perl-Bootloader as library for yast2-Bootloader and finally we managed to make it happen. There were many reasons for this change.
From the user point of view, the most visible reasons were speed and size. Getting rid of Perl-Bootloader means that we not longer perform hardware probing twice (one for Perl-Bootloader and another one for grub2-config), making kernel updates faster. In addition, we are not only simplifying and reducing the size of yast2-bootloader itself. Dropping the Perl libraries and other associated dependencies, makes possible to have a smaller minimal system, something quite relevant in various environments and scenarios.
From the developer point of view, the main reason was to unify the used programming languages and also reuse existing solution for file reading and parsing. Now yast2-bootloader uses an Augeas file parser and serializer, which does not only allow us to have less code to maintain, but also offers smarter editing and better handling of the comments in the configuration files.
As nice side effects, this change also leaded to the removal of a lot of work-arounds, the simplification of the installation work-flow for bootloader and a very visible improvement in the source code quality. In addition, we improved the test coverage of the whole module to make sure we didn’t break things too much. But all those would be bold statements if we wouldn’t have some geeky numbers to prove then, so here they are.
Of course, after such a big rewrite is not unlikely that some new bugs will pop up, but we really believe the improvements are worth the price.
For the storage-ng project we made a big step towards a modern system. We do not use geometries and cylinders for disks any longer. Instead we only use sectors.
The advantage for the user is much better control over the size of new partitions. Since so far the size had to be a multiple of the cylinder size, often 7.84 MiB, it was not possible to create very small partitions, e.g. for the BIOS boot partition. Also the size of partitions was usually not the exact number entered in YaST, e.g. 509.88 MiB instead of 512 MiB.
Now the size of partitions is as accurate as possible with the hardware, so usually a multiple of 512 B or 4 KiB.
Like in the past we also takes care of optimal partition alignment to avoid performance loss due to read-modify-write cycles.
Snapper is a great tool, but the current default configuration usually causes it to be a little bit too greedy with disk space. During this sprint a new set of cleanup rules was implemented, allowing a much more reasonable usage of the disk.
The feature is already developed, submitted to Factory and even integrated into the next version of SUSE Enterprise that is right now being cooked. But, as you all know, the testing work-flow of openSUSE Tumbleweed (staging projects, openQA and so on) can sometimes cause some delay until the new feature appears in the distribution. As soon as the new feature reaches Tumbleweed, a blog post explaining the new functionality will be published at snapper.io. Stay tuned!
The password protection widget in YaST2-Bootloader had not been changed since the GRUB1 times, but GRUB2 allows more fine tunning of the password settings. In fact, it contains a whole user management system with multiple users that can have different permissions and different passwords. For YaST we like to keep things simple, so we support only password for “root” user. That was confusing for some people, so we decided to improve the user experience by adjusting some labels… and fixing some typos in the process. 😉
Two pictures are worth a thousand words, so here you can see how the dialog looked before the change
and below the new appearance, which adds more explanation to the password specification. Of course, the help text (not displayed in the screenshots) was also improved to reflect the changes.
The YaST installer implements several possibilities how the default patterns for the installed product should be specified. One of them is using Recommends RPM dependencies for the product package. (The other possibilities include control.xml file or the content file on the medium.)
The installer by default installs the recommended packages so the default patterns are automatically installed in the initial installation.
However, this approach makes troubles during system upgrade. If you remove some packages or patterns which are installed by default and then you do a system upgrade the installer will (silently) add the removed packages or patterns back as the Recommends dependencies will pull them in again.
The solution is to provide another mechanism for selecting the default patterns. The new implementation allows using a specific Provides RPM package tag which specifies the default pattern name for the product.
The new tag is defaultpattern(pattern) where “pattern” is the name of the default pattern. YaST looks for these specific tags and collects the pattern names for all installed or updated products. This step is skipped during package based system upgrade so this should avoid adding unnecessary packages in system upgrade.
Obviously it depends on the products themselves to switch from the RPM dependencies to this new style. So far it is supported only by the SLES12 SP2 High Availability addon.
See more details at https://github.com/yast/yast-packager/wiki/Selecting-the-default-product-patterns.
A couple of reports ago we made public our intention to squeeze some booting experts brains in order to create Ruby classes capable of always proposing a sensible partitioning schema. The delicious result is finally at the repository, accompanied with a rather complete document explaining the logic behind the code.
If reading Ruby code is not your thing but you are geeky enough, you can also review the output generated by the RSpec unit tests, which shows how the new partitioning proposal will behave in all scenarios from the booting requirements point of view.
Apart from the already mentioned improvements in setting the boot-related partitions, the brand new partitioning proposal gained the ability of shrinking Windows partitions when needed (in a sensible and gentle way) and reusing partitions that can be shared with other installed systems, like swap of PReP. Even when sharing a swap partition is not possible and the proposal needs to delete an existing swap partitions to create a different one, it will take care of reusing the old label and UUID, so other systems in the same computer can still find a suitable swap for them even after changing the partitioning layout. Because we all can be better citizens…
In addition, we took the first steps to develop a smarter way of proposing a solid partitioning schema when the free space is split over several different disks or disk chunks. Is still a work in progress, but you can trust that in the future (open)SUSE will do a nice job when looking for a home for itself in your sparse hard disk space.
The management of storage devices in a Linux system running in a S/390 mainframe is a tricky topic full of corner cases. Depending on the type of disk, its format and other factors, some apparently simple operations (like creating partitions) are not possible. If you are interested in the subject and want to learn a lot of weird acronyms, we would recommend this article.
We realized that the expert partitioner allowed the user to specify some operations that were actually not supported, which resulted in the installation being aborted at a subsequent step. To avoid that situation, we improved the expert partitioner to detect those unsupported S/390 configurations and alert the user, like it’s shown in the screenshot below.
We refactored the network module to unify the handling of device naming. Now AutoYaST assigns the naming udev rules in the 1st stage of the installation already. (yast2-network-3.1.147, autoyast2-3.1.121)
We got a new server to run integration tests via openQA and AutoYaST.
The AutoYaST tests now used to take 8 hours but now finish in 1.5 hours.
Even though we call ourselves “the YaST team” we are happy to share the project with other teams in the company and people in the community. During this sprint, we had a chance to review code for two significant features.
The authentication client module, dealing with LDAP, Kerberos, Active Directory, NSS, PAM, and SSSD, got a big upgrade (yast2-auth-client-3.3.7).
Since a couple of months, Tumbleweed has had a package for firewalld (see FATE#318356 ). Work is underway to make YaST aware of it but it has not been merged yet. If you are interested you will have to find it in the git repo.
Definitely, this was a very productive sprint and, as usual, this report is just a sample of the total work delivered by the team. To be precise and to please number lovers, the features and fixes covered by this report represent 85 Scrum story points out of a total of 124 delivered ones. Hopefully enough to keep you entertained until the next report in about three weeks. See you then!
Adrian Schröter (12)
Agustin Chavarria (6)
Alessandro de Oliveira Faria (13)
Alex Barrios (12)
Alexander Naumov (10)
Alexander Orlovskyy (3)
Alin M Elena (5)
Andrea Florio (27)
Andreas Jaeger (70)
Andreas Stieger (12)
Andrew Wafaa (31)
Arvin Schnell (9)
Atri Bhattacharya (3)
Bernhard Wiedemann (31)
Bonnie Kurniawan (1)
Bruno Friedmann (98)
Calumma Brevicorne (29)
Carl Fletcher (1)
Christopher Hobbs (17)
Ciaran Farrell (3)
Stephan Kulow (17)
craig gardner (2)
Stephan Barth (2)
Thomas Schmidt (2)
Dinar Valeev (1)
Dirk Mueller (2)
Dmitry Serpokryl (7)
Efstathios Iosifidis (21)
Fabio Mucciante (5)
Federico Lucifredi (9)
Greg Freemyer (1)
Holger Sickenberg (2)
Hubert Mantel (1)
Ilya Chernykh (5)
Ismail Donmez (1)
J. Daniel Schmidt (2)
James Tremblay (7)
Jan Blunck (4)
Jan Loeser (3)
Jan Madsen (1)
Jan-Christoph Bornschlegel (3)
Jan-Simon Möller (20)
Javier Llorente (12)
Jigish Gohil (85)
Jiri Srain (1)
Jiří Suchomel (3)
Johan Kotze (5)
José Oramas M. (6)
Josef Reidinger (16)
Juergen Weigert (1)
Julio Vannini (9)
Dinar Valeev (5)
Kevin "Yeaux" Dupuy (11)
Klaas Freitag (55)
Lars Vogdt (11)
Ludwig Nussel (13)
M. Edwin Zakaria (4)
Marcus Hüwe (39)
Marcus Meissner (2)
Marcus Moeller (3)
Marcus Schaefer (4)
Martin Lasarsch (8)
Martin Mohring (11)
Masim "Vavai" Sugianto (20)
Michael Andres (1)
Michael Löffler (7)
Michal Marek (7)
Michal Vyskocil (12)
Miguel Angel Barajas Hernandez (2)
P Linnell (2)
Nelson Marques (55)
Nenad Latinović (1)
Nikanth Karthikesan (2)
Przemyslaw Bojczuk (1)
Peter Pöml (4)
Petr Gajdos (2)
Petr Mladek (60)
Petr Uzel (5)
Ray Wang (1)
Raymond Wooninck (1)
Ricardo Chung (7)
Ricardo Varas Santana (7)
Richard Bos (11)
Robert Schweikert (16)
Rossana Motta (1)
Rupert Horstkötter (10)
Sascha Manns (66)
saydul akram (3)
Sebastian Siebert (6)
Shawn Dunn (2)
Stanislav Visnovsky (7)
Stefan Haas (1)
Stefan Hundhammer (5)
Stefan Schubert (7)
Steffen Winterfeldt (8)
Suresh Jayaraman (3)
Susanne Oberhauser (3)
Thomas Göttlicher (6)
Thomas Schraitle (26)
Togan Muftuoglu (3)
Tuukka Pasanen (36)
Will Stephenson (22)
YaST Team (90)