openSUSE Lizards

Archive for the ‘Programming’ Category

Highlights of YaST development sprint 27

November 10th, 2016 by Yast Team

Another three weeks of development come to an end… and our usual report starts. Take a look to what we have been cooking.

Read-only proposal modules

This week, during SUSECon 2016, SUSE announced an exciting upcoming new product. SUSE CASP – a Kubernetes based Container As a Service Platform.

That has, of course, some implications for the installer, like the need of some products (like CASP) to specify a fixed configuration for some subsystems. For example, an established selection of packages. The user should not be allowed to change those fixed configurations during installation.

We have implemented a possibility to mark some modules in the installation proposal as read-only. These read-only modules then cannot be started from the installer and therefore their configuration is kept at the default initial state.

In this sprint we have implemented a basic support in the proposal framework, in the future we could improve the respective proposal modules to better handle the read-only mode.

Per product Btrfs subvolumes handling

The ability to have read-only proposals is not the only improvement we have introduced in YaST to make SUSE CASP possible.

When Btrfs is used during the installation, YaST2 proposes a list of subvolumes to create. Unfortunatelly, that list is hard-coded and it’s the same for every (open)SUSE product… until now.

Starting on yast2-storage 3.1.103.1, a list of subvolumes can be defined in the product’s control file along with additional options (check out SLES and openSUSE examples to learn more).

<subvolumes config:type="list">
  <subvolume>
    <path>boot/grub2/i386-pc</path>
    <archs>i386,x86_64</archs>
  </subvolume>
  <subvolume>
    <path>home</path>
  </subvolume>
  <subvolume>
    <path>opt</path>
  </subvolume>
  <subvolume>
    <path>var/lib/libvirt/images</path>
    <copy_on_write config:type="boolean">false</copy_on_write>
  </subvolume>
</subvolumes>

This specification supports:

Disabling copy-on-write for a given subvolume (it’s enabled by default).
Enabling the creation of a subvolume only for a set of architectures.

Improved AutoYaST Btrfs subvolumes handling

AutoYaST Btrfs subvolumes handling has been also improved. Using almost the same syntax as for product control files, you can disable the CoW behavior for a given subvolume.

Of course, if you don’t need such a feature, you won’t need to adapt your profiles to the new syntax as it’s backward compatible. You can also mix both of them:

<subvolumes config:type="list">
  <subvolume>home</subvolume>
  <subvolume>
    <path>var/lib/libvirt/images</path>
    <copy_on_write config:type="boolean">false</copy_on_write>
  </subvolume>
</subvolumes>

On the other hand, if you’re running SLES, you’ll know that a subvolume called @ is used as the default Btrfs subvolume. Now is possible to turn-off such behavior in the profile’s general section.

<general>
  <btrfs_set_subvolume_default_name config:type="boolean">false</btrfs_set_subvolume_default_name>
</general>

Disable installer self-update by default

We have talked many times in this blog about the new self-update functionality for the installer. As expected, this functionality will debut in SLE-12-SP2 but with a small change in the original plan. In order to ensure maximum consistency in the behavior of SLE-12-SP1 and SP2 installers, the self-update functionality will be disabled by default. Not a big deal, since enabling it to get the latest fixes will be just a matter of adding a boot option in the initial installation screen.

Storage reimplementation: adapted EFI proposal in yast2-bootloader

The previous report about the status of the storage stack reimplementation finished with the following cliffhanger “we have in place all the ingredients to cook an installable ISO“. So, as expected, we worked during this sprint in adapting the bootloader proposal to the new storage layer. As you can see in the following screenshot, we succeeded and the installer can already propose a valid grub2 setup to boot an EFI system.

Does that mean that the testing ISO for the new storage stack is already fully installable? Unfortunately not. Why not, you ask? The reason is, in fact, kind of fun.

The current partitioning proposal only works with MS-DOS style partition tables because we wanted to address the most complicated case first. On the other hand, we intentionally restricted the adaptation of the bootloader proposal to the EFI scenario. And you know what? We found out that combination (MS-DOS partition table + EFI) does not currently work in Tumbleweed, so it neither does in our Tumbleweed-based testing ISO.

We will work during the following sprint to support another scenario. And hopefully we will not choose again an unsupported or broken one. 😉

Letting libYUI run free: first visible steps

As you know, YaST has both a graphical and a textual interface. They run on the same code thanks to an abstraction layer called LibYUI. Originally it served YaST only, but over time other projects started using it, notably the admin panel in Mageia. Moreover, the developers of those projects started to contribute fixes and improvements to LibYUI… faster than we can cope with.

Recently we decided to give the people outside the YaST team more power in the LibYUI project. To make that possible ensuring it does not affect YaST stability, we have been enabling more continuous integration tests.

As a first fruit of the revamped collaboration, we have merged a fix contributed by Angelo Naselli of Mageia regarding selection of tree items. As soon as we complete our continuous integration setup (of course we will keep you informed), more fixes and improvements will come for sure.

More bug squashing and bug paleontology

In the previous report we presented our new effort to integrate the fix of low-priority bugs into the Scrum process. During this sprint we refined the idea a little bit more, distinguishing two separate concepts (each of them with its own PBI) – fixing of existing bugs and closing of too old ones.

The first one doesn’t need much explanation. We managed to fix around 25 non-critical bugs in YaST and if you are using Tumbleweed you are probably already benefiting from the result.

The second task was not exactly about fixing bugs present in the software, but about cleaning bugzilla from bug reports that were simply too old to be relevant any more. Like bugs affecting very old versions of openSUSE that cannot be reproduced in openSUSE 13.2 or Leap. We must be realistic about releases that are already out of support and the limited human resources we have. We closed around 80 of those ancient bugs.

So overall, we cleaned up around one hundred bugs from our queue. Still a long way to have a bug-free YaST, but undoubtedly a step in the right direction.

More coming

We are already working in the next sprint that will hopefully bring several new improvements for CASP, quite relevant progress in the storage reimplementation, several usability improvements, some bugfixes and even some news about this blog.

To make sure you don’t get bored while waiting we are also planning to finally publish the report about our visit to Euruko 2016.

Stay tuned!

Posted in Base System, Distribution, Factory, Programming, Systems Management, YaST | 6 Comments »

Highlights of YaST development sprint 26

October 20th, 2016 by Yast Team

We did our best to keep you entertained during this development sprint with a couple of blog posts ([1] and [2]). But now the sprint is over and it’s time for a new report.

Squashing low priority bugs

One of the main reasons to adopt Scrum was to ensure we make a good use of our development resources (i.e. developers’ time and brains) focusing on things that bring more value to our users. In the past we had the feeling that many important things were always postponed because the developers were flooded by other not so important stuff. Now that feeling is gone (to a great extent) and we have a more clear and shared view of the direction of our development efforts.

But there is always a drawback. We have accumulated quite some unsolved low-priority bugs. That was an expected consequence, but still it was starting to feel wrong. On one hand, it makes us feel uncomfortable – replying “this will have to wait” so often is not nice, even if it’s for the shake a bigger goal. On the other hand, the amount of low-priority stuff was affecting the signal/noise ratio on Bugzilla, making harder to distinguish the important stuff.

So far, dealing with those low-priority bug was something that each developer did on his own, as permitted by the time dedicated to Scrum. In sprint 26 we decided to make that effort an explicit part of the process and to devote a significant portion of the sprint to it. As a result we closed or reassigned a total of 135 bugs that were just sitting in our list.

Yes, you did read it right. One hundred and thirty five bugs.

Storage reimplementation: our testing ISO can already destroy your data

On the previous sprint we already showed a screenshot of the installer using the new storage stack to calculate a partitioning proposal. Now the installer can go one step further. As you can see on this animation, the changes are now committed to the disk, meaning the system is actually partitioned, formatted and installed.

Installation with the new storage stack

The process is interrupted after installing the software, when trying to configure and install the bootloader. That was expected because yast2-bootloader has still not been adapted to use the new stack. First of all, because we wanted to leave some fun for sprint 27. But also because we used this sprint (26) to document all the requirements of yast2-bootloader in relation to the new storage stack. Now we have in place all the ingredients to cook an installable ISO.

Automatic update of translation files

Recently openSUSE has adopted Weblate to perform and coordinate the translation of the software and the project’s web pages. The openSUSE’s Weblate instance enables everybody (from dedicated translators to casual contributors) to take part in the process and makes possible to coordinate the translations of openSUSE with the ones for SUSE Enterprise Linux, boosting collaboration between the translators of both projects.

As YaST developers, is of course our responsibility to ensure that openSUSE’s Weblate contains always the latest English strings to be translated. Making our developer’s life easier sometimes not only brings advantages for us but also for our users. Until now, after each code change we had to keep in mind to trigger the translation process for every added or changed English text. Sometimes we were not quick enough so that some English leftovers remained in our awesome YaST when being used in one of the 20 languages where the translation is normally 100% complete.

Now we finally set up a Jenkins job to automate the process of triggering the translation update after code changes. This saves the developers some work and makes the update of translations even faster.

Looking at Weblate numbers, you can see we have 20 languages that are about 100% translated, another 20 that are translated more than 75% and 37 languages which are translated less than 75%. So we still need some help to bring all languages to 100% coverage. If you are willing to contribute, why not join our team of translators? Check out the localization guide to get in contact with the coordinators of your preferred language to learn about how to contribute with translations, reviews or by any other mean.

Ensure installation of packages needed for booting

We got some reports of systems not being able to work after the installation in scenarios in which the user had customized the list of packages to install. That happened because, although the bootloader component of YaST pre-selects for installation all the needed packages, the user can override that selection and manually disable the installation of those packages.

To prevent this situation, or at least to increase awareness of it, the installer now alerts in the summary screen (the last step before proceeding to installation) if some of the required packages is missing, as you can see in the screenshot below. We still allow the users to shoot their own feet if they insist, but now we warn them very clearly.

Progress in the low-vision accessibility of the installer

During this sprint, we have been working to make the (open)SUSE installer accessible to people with low-vision impairment. We already blogged about it looking for feedback.

In a few days, some changes will land in Tumbleweed:

Alternative style selection (color and font-sizes). Currently, we offer four options: default (no changes), high contrast (cyan/green/white/black), white on black and cyan on black. Those styles are just a proof of concept in order to test the code changes and, most important, to get feedback from you.
A long-standing issue, which prevented to switch to high-contrast mode during installation (shift+F4), has been fixed.

Although we have made some progress, it is still an ongoing effort and we hope to release more improvements during the upcoming weeks.

Recover from broken bootloader configuration

There are situations in which YaST Bootloader is not able to read the system configuration. For example, when the udev device originally used by Grub2 is no longer available. In the past that leaded to YaST crashes, requiring a manual fix of the bootloader configuration files. Now YaST correctly detects the situation and offers the option to propose a new configuration with correct devices.

Disable autorefresh by default in local media

We have changed the default autorefresh flag for the new repositories added by YaST. In the past the autorefresh was enabled for all repositories except CD/DVD media and ISO files.

With the new defaults the autorefresh is enabled only for remote repositories (like http, ftp, nfs,…). The reason is that some local repositories might not be always available (e.g. external hard disk, USB flash drive,…) and the automatic refresh might cause ugly errors when starting the package manager.

Of course, you can still manually change the autorefresh flag after adding a repository if you need a different value.

Note: The default has been changed in Tumbleweed distribution only, Leap 42.2 or SLE-12-SP2 keep the old defaults. The zypper behavior is unchanged as well, it by default disables autorefresh for all repositories. Only repositories imported from a .repo file have autorefresh enabled. See man zypper for more details.

Tons of improvements in network bridge handling

YaST Network is Swiss Army knife for network configuration which comprehends the management of routing, bonding, bridging and many other things. But, to be honest, the management of bridges was not in the best possible shape. It had quite some usability problems and it was not 100% consistent with the way in which bridges are managed nowadays by Wicked in (open)SUSE. Until now!

This pull request with several screenshots and animations tries to summarize all the changes that have been done during this sprint. Like adapting old configuration files to the new conventions or unifying the UI to make it consistent with the one for managing bonding.

This revamp includes also quite some usability improvements:

“NONE” is shown instead of 0.0.0.0 for old bridge configuration.
The bridge master is shown in the enslaved interface.
The interfaces overview is updated after a bridge is modified.

Optimizing read of hosts file

It was reported that yast2-network was slow in system with a lot of entries in the /etc/hosts file. We took that as an opportunity to test the new profiler support in YaST. The profiler revealed the problem was in some slow calls to SCR, the layer traditionally used by YaST to interact with the underlying system… which sounded like another opportunity. This time an opportunity to expand the use of CFA (the component we are developing to steady replace SCR) and its Augeas parser. Since Augeas already supports parsing of /etc/hosts files, it was quite straightforward to implement that into YaST… and the result is quite impressive.

The time needed to execute the next command in a system containing a huge /etc/hosts with around 10,000 entries (quite an extreme case, we know) was reduced from 75 seconds to just 20.

yast2 lan list

As you can see in this pull request, we also improved CFA itself, greatly reducing the time needed for reading configuration files with Augeas.

That’s all… until next report

Once again, we must conclude the report telling that this was just a small summary of all the work done during the sprint and that we will be back in three weeks with the next report. Or maybe before, now that we are starting to get used to blog more often.

In any case, see you soon and don’t forget to have a lot of fun!

Posted in Distribution, Factory, Localization, Programming, Systems Management, Usability, YaST | 1 Comment »

Reducing YaST rebuild time by 30%

October 11th, 2016 by Yast Team

Here comes the YaST team again trying to flood your aggregator with blog post! Now it’s time for the story of how we reduced the critical path of the rebuild time of YaST RPM packages from 42min 2s to 29min 40s.

Chapter 1: where to optimize

Of course, the first step to start fixing something is finding out what exactly needs to be fixed. In our case, this breaks down into

knowing the dependencies, and
knowing the individual build times.

Dependencies

It is tempting to figure out the dependencies by yourself, by parsing the spec files. But it is hard to do right, and, more importantly, a reinvention of the wheel. The Build Service must know all this to be able to schedule the builds, and provides a convenient way to access it, with osc dependson:

$ osc dependson YaST:Head openSUSE_Factory x86_64
[...]
yast2-x11 :
   yast2-devtools
yast2-xml :
   yast2-core
   yast2-devtools
yast2-ycp-ui-bindings :
   libyui
   yast2-core
   yast2-devtools

Individual build times

For each source package, the Build Service produces not only binary RPMs but also a _statistics file, available in the web UI or via osc getbinaries. We were interested in the total build time, although the data was of limited use because packages can be built on machines with vastly different power and this information is not included.

Chapter 2: how to optimize

Once we knew which screws needed to be tightened, it was time to do it. Fortunately we had more than one tool for the job.

Stop using Autotools

Autotools (automake, autoconf and configure) took up a majority of the time needed for building YaST packages. Now that most of those packages are written in pure Ruby, we don’t need autotools there checking for portability problems that we don’t have. Autotools are a leftover from the times 15 years back when they were the only sensible option. We have wiped them out where possible and have been switching to our own set of Rake tasks.

Stub the APIs used in tests

We run a mixture of unit and integration tests at RPM build time. The downside of this is that we pull in many of the run time dependencies. Fortunately Ruby is a dynamic language and makes it easy to replace interfaces by stubs. That enables us to cut those dependencies.

In fact, we also have some Perl code, notably in yast2-users. Although the stubbing techniques across languages are messier than with pure ruby, they are still effective for our purposes.

Do not build specialized documentation

This one is simple: if the development documentation is only useful for people that will check out the git repo anyway, then leave it out from the RPM.

Appendix: the details

Enough of high-level explanations, we we promised you graphs, code and all kind of gory details, and a promise made is a debt unpaid. So there we go.

Dependency graphs

A picture is worth a thousand words. That’s why we came up with this small tool to generate a graphical representation of the dependencies of the YaST packages. In the resulting graphs displayed below, a node is a source package in the build service, and an arrow means “needs for its build”. Redundant arrows are omitted (that is, we’ve erased an A→C if both A→B and B→C existed).

We can see that the most prominent conclusion is that there is a large number of packages that depend on yast2, a collection of basic libraries.

But on top of that, in the original graph there are 6 more layers, and the graph is not very dense there. After our fixes, there are only 4 layers that are more dense.

Is worth mentioning that the “layer” concept only works if the packages take roughly the same time to build; it would not be helpful if there were huge variations. To get a more accurate picture, we should have generated a histogram of build times. But the graph was good enough in our scenario… and we had to stop the analysis at some point. 🙂

The build dependency graph before our fixes:

The build dependency graph after our fixes:

Build statistics

If those graph are not geeky enough for you, here you are the detailed build statistics from the build service

<buildstatistics>
  <disk>
    <usage>
      <size unit="M">1118</size>
      <io_requests>15578</io_requests>
      <io_sectors>2156642</io_sectors>
    </usage>
  </disk>
  <memory>
    <usage>      <size unit="M">580</size> </usage>
  </memory>
  <times>
    <total>      <time unit="s">756</time> </total>         <!-- THIS -->
    <preinstall> <time unit="s">8</time>   </preinstall>
    <install>    <time unit="s">72</time>  </install>
    <main>       <time unit="s">555</time> </main>
    <download>   <time unit="s">4</time>   </download>
  </times>
  <download>
    <size unit="k">33564</size>
    <binaries>53</binaries>
    <cachehits>24</cachehits>
    <preinstallimage>preinstallimage.preinstallimage.tar.gz</preinstallimage>
  </download>
</buildstatistics>

Epilogue

This was definitely an interesting journey. We learned quite some things. Specially we learned that there is still room for improvement, but most likely the time reduction will not pay off for the time invested implementing those improvements.

We have to be realistic and keep working in other interesting stuff to fuel the next sprint report, coming next week!

Posted in Build Service, Distribution, Factory, Programming, Systems Management, YaST | 3 Comments »

Atualizando o Edison Intel no openSUSE

October 3rd, 2016 by Alessandro de Oliveira Faria

Neste post, disponibilizo os passos efetuados para atualizar o firmware do meu Intel Edison na plataforma openSUSE.

ATENÇÃO: Antes de iniciar deixo claro , que o leitor deste post é responsável por qualquer problema que venha a acontecer com o seu aparelho, logo: sendo de sua inteira responsabilidade e risco a utilização das instruções a seguir.

Primeiramente instale o pacote

# zypper addrepo http://download.opensuse.org/repositories/home:cabelo:desktop/openSUSE_Leap_42.1/home:cabelo:desktop.repo
# zypper refresh
# zypper install dfu-util

Faça o Download da ultima versão do firmware em https://software.intel.com/pt-br/iot/hardware/edison/downloads

Posicione a chave SW1 próxima ao conector micro USB de acordo com a figura abaixo e plugue os 2 cabos USB:

intel-edison-setup-1

E logo a seguir descompacte o arquivo recém baixado e execute o comando ./flashall.sh

yocto02

Se executar o comando sudo screen /dev/ttyUSB0 115200, teremos a seguinte saida no console:

Starting Reboot…

******************************
PSH KERNEL VERSION: b0182727
WR: 20104000
******************************

SCU IPC: 0x800000d0 0xfffce92c

PSH miaHOB version: TNG.B0.VVBD.0000000c

microkernel built 23:15:13 Apr 24 2014

******* PSH loader *******
PCM page cache size = 192 KB
Cache Constraint = 0 Pages
Arming IPC driver ..
Adding page store pool ..
PagestoreAddr(IMR Start Address) = 0x04899000
pageStoreSize(IMR Size) = 0x00080000

*** Ready to receive application ***

U-Boot 2014.04 (Aug 20 2014 – 16:08:32)

Watchdog enabled
DRAM: 980.6 MiB
MMC: tangier_sdhci: 0
In: serial
Out: serial
Err: serial
Hit any key to stop autoboot: 0
Target:blank
Partitioning already done…
Flashing already done…
GADGET DRIVER: usb_dnl_dfu
#
DFU complete CRC32: 0x3756edb6
DOWNLOAD … OK
Ctrl+C to exit …
#
DFU complete CRC32: 0x3756edb6
DOWNLOAD … OK
Ctrl+C to exit …
#
DFU complete CRC32: 0x6ad212b0
DOWNLOAD … OK
Ctrl+C to exit …
#
DFU complete CRC32: 0xe511e42b
DOWNLOAD … OK
Ctrl+C to exit …
#
DFU complete CRC32: 0xe511e42b
DOWNLOAD … OK
Ctrl+C to exit …
resetting …

******************************
PSH KERNEL VERSION: b0182b2b
WR: 20104000
******************************
SCU IPC: 0x800000d0 0xfffce92c
PSH miaHOB version: TNG.B0.VVBD.0000000c
microkernel built 11:24:08 Feb 5 2015

*** Ready to receive application ***
U-Boot 2014.04 (Jun 19 2015 – 12:05:55)
Watchdog enabled
DRAM: 980.6 MiB
MMC: tangier_sdhci: 0
In: serial
Out: serial
Err: serial
Writing to redundant MMC(0)… done
Writing to MMC(0)… done
Hit any key to stop autoboot: 0
Target:blank
Partitioning using GPT
Writing GPT: success!
Saving Environment to MMC…
Writing to redundant MMC(0)… done
Flashing already done…
GADGET DRIVER: usb_dnl_dfu
#
DFU complete CRC32: 0xb98db2f8
DOWNLOAD … OK
Ctrl+C to exit …
pageStoreSize(IMR Size) = 0x00080000

*** Ready to receive application ***

U-Boot 2014.04 (Jun 19 2015 – 12:05:55)

Watchdog enabled
DRAM: 980.6 MiB
MMC: tangier_sdhci: 0
In: serial
Out: serial
Err: serial
Writing to redundant MMC(0)… done
Writing to MMC(0)… done
Hit any key to stop autoboot: 0
Target:blank
Partitioning using GPT
Writing GPT: success!
Saving Environment to MMC…
Writing to redundant MMC(0)… done
Flashing already done…
GADGET DRIVER: usb_dnl_dfu
#
DFU complete CRC32: 0xb98db2f8
DOWNLOAD … OK
Ctrl+C to exit …
######################################################################################

*** Ready to receive application ***
U-Boot 2014.04 (Jun 19 2015 – 12:05:55)
Watchdog enabled
DRAM: 980.6 MiB
MMC: tangier_sdhci: 0
In: serial
Out: serial
Err: serial
Writing to redundant MMC(0)… done
Writing to MMC(0)… done
Hit any key to stop autoboot: 0
Target:blank
Partitioning using GPT
Writing GPT: success!
Saving Environment to MMC…
Writing to redundant MMC(0)… done
Flashing already done…
GADGET DRIVER: usb_dnl_dfu
#
DFU complete CRC32: 0xb98db2f8
DOWNLOAD … OK
Ctrl+C to exit …
##############################################################################################

Se tudo funcionou corretamente, teremos a seguinte tela:

yocto03

Posted in Programming | Comments Off on Atualizando o Edison Intel no openSUSE

Highlights of YaST development sprint 25

September 28th, 2016 by Yast Team

Another development sprint is over. Time flies! In our previous post we already reported about the branching of Tumbleweed and the upcoming releases and about the expected consequences: the landing of some cool features in a less conservative Tumbleweed.

We are still dedicating quite some effort to polish the upcoming stable releases (SLE12-SP2 and Leap 42.2), but in this sprint we finally found some time to play. Which is great because blogging about new features is more fun than doing it about bug fixes. 🙂

Importing Authorized Keys with AutoYaST

When logging in via SSH, public key authentication should be preferred over password authentication. Until now, the best way of setting up the required authorized_keys files in AutoYaST was using the files section.

However, that approach is tedious and error prone, as you need to make sure you set the correct owner, permissions, etc. Moreover you need to keep in sync the user definition (username and home directory) with the file definition.

AutoYaST now supports the specification of a set of public keys for each user with a pretty straightforward syntax:

<user>
  <username>suse<username>
  <authorized_keys config:type="list">
    <listentry>ssh-rsa your-public-key-1</listentry>
    <listentry>ssh-rsa your-public-key-2</listentry>
  <authorized_keys>
<user>

AutoYaST takes care of writing the files and setting the ownership and the proper permissions.

While documenting this new feature we realized the AutoYaST documentation about users management could be more detailed, which leads us to…

Improving the documentation

Usually developers love to create programs loaded with cool features but hate to write documentation. Fortunately there are people out there who enjoy writing documentation and bringing all those features to light. We have already mentioned in previous reports how grateful we are for having the SUSE documentation team polishing and publishing our documentation drafts and how open and straightforward the process is.

We updated the YaST documentation to include information about the installer self-update feature, which will debut in SUSE Linux Enterprise 12 SP2 and openSUSE Leap 42.2. As part of the same pull request and in the AutoYaST side, some additional improvements were made, including cleaning-up some duplicated information about SUSE registration.

On the other hand and as a consequence of the above mentioned new feature, the AutoYaST documentation regarding users management has been rewritten adding missing information like groups, user defaults and login settings.

All our pull requests are already merged in the doc-sle repository. At a later point in time, the SUSE documentation team will review and polish all the new content (including ours) and will publish an up-to-date version of the online documentation. If you don’t want to wait, you can easily generate an HTML or PDF version of the documentation including all the non-reviewed contributions just following the very simple instructions in the README file of the doc-sle repository.

Did we already mention we love the open source, programmer-friendly processes of the documentation team? 😉

Storage reimplementation: something you can touch

We promised news about the storage reimplementation and here they are. Our customized Tumbleweed image (labeled as NewStorage) in the storage-ng OBS repository can now perform some simple actions during installation and display the result to the user.

First of all, when proposing the timezone settings it will, as usual, check for MS Windows installations in the disk to guess if the hardware clock should be set to UTC. The news is that check is performed using the new storage stack, that offers more functionality in every sprint.

More important is that the installer will show the partitioning proposal calculated also using the new stack. As you can see in the screenshot below, the screen is way more simpler than the one you would find in a regular Tumbleweed. There are no buttons to change the settings or to run the expert partitioner yet. That doesn’t mean the functionality is not there, it’s simply that we prefer to focus first on modifying all the installer steps to use the new stack (what will enable us to use openQA) before refining every screen to add all options there.

Right now the system works only in disks containing a MS-DOS style partition table and will always propose a partition-based (no LVM) setup. That’s because we prefer to solve the hardest scenarios first. Using LVM and/or GPT partition tables is less challenging than the already supported scenario.

Reduce global warming by saving OBS build power

As you may know, we use the awesome Open Build Service (OBS) to generate both the YaST rpm packages and the openSUSE/SLE ISO images. Every time the source code of any component changes, OBS rebuilds that component and all the packages that depend on it.

Our beloved openSUSE and SLE release managers told us that there were several YaST packages that often triggered rebuild of other YaST packages, that triggered yet another rebuild, that triggered… you got the idea. 😉

The mentioned problem slows down the creation of new ISO images, interferes with the continuous integration process (specially visible in Tumbleweed) and wastes valuable OBS resources.

During this sprint we reduced the rebuild time of YaST by 30%. That’s for sure interesting, but knowing the details about how we did it could be even more interesting for many readers. We feared the explanation could be too complex and technical to fit into this report… which gives us just another opportunity for blogging. So expect an upcoming post including interesting technical stuff and crazy graphs like this one.

Some adjustment for the installer in the LiveCDs

One of the good things about working in open source is that sometimes the evolution of the projects you have created can surprise you. Quite some time ago, the YaST team dropped support for the live installer. It was simply too demanding to keep it alive while still doing our regular work (bug fixes and new features for YaST and the regular installer).

Recently the live installer was removed from Tumbleweed, the only system in which it was still available (after having been dropped in the past from stable openSUSE releases). One could have expected that somebody would decide then to step up and take the maintainership of the live installer.

But what actually happened was that Fabian Vogt decided to try a different approach we haven’t considered – adding the standard network installer to the LiveCDs images of Tumbleweed. He managed to make it work well enough and asked us for help to debug some problems. We fixed the initial problems by disabling the self-update functionality in the LiveCDs (it’s simply not designed to work on that scenario).

There are still quite some problems to be resolved to make everything work flawlessly, but if Fabian and others don’t give up, we will keep assisting them in order to bring the installation back to the LiveCDs… even in unexpected ways.

UI Designer

The YaST user interface is quite difficult to design and code. The main problem is that there is was no interactive UI designer where you could build a dialog or modify an existing one. Instead, you had to write new code or modify the existing code which creates and opens the dialog. Then, to see your changes you had to start the YaST module, go to the respective dialog and check its content. If it didn’t look like you intended, you had to close it, modify the code and start it again. And again… and again. Very annoying especially if the dialog is hidden deep in the module and you need to take several steps to get there.

During Hack Week 14, a project to improve the situation a bit was started. We already had a dialog spy which can be opened by Ctrl+Shift+Alt+Y keyboard shortcut, but that was read-only. You could only inspect the dialog tree and see the details of the selected widget but you could not change anything.

During that Hack Week project it was improved so it could edit the properties of the existing widgets, remove them or even add some new widgets. However the code was more or less a proof of concept than ready to be merged into the YaST UI and released to public. So we decided to finish it in this sprint.

As usual, it was harder than expected… but we made it and here is a short demo showing how it works and what you can do there:

The new UI designer in action

The new tool is still far from being perfect. The most obvious missing feature is that the dialog is changed in place and you cannot save or export you changes. After closing the dialog everything is lost. But it can still help to try things in the UI or make a quick prototype, specially when discussing solutions with interface designers. Hopefully we find some more time in the future to make it even better.

Storage reimplementation: encryption support

Although the partitioning proposal still does not support encryption or LVM, we implemented full LUKS (encryption) support in the underlying library (libstorage-ng). Together with the LVM support implemented in the previous sprint, that makes the new library already a valid replacement for the old libstorage in many situations and scenarios. Now it’s mainly a matter of switching from one version to another in every single YaST component, starting with the expert partitioner that we plan to start redesigning in the next sprint.

As usual, new features in the library are hard to illustrate, unless you accept the action diagrams as screenshots. In that case, here you can see the sequence of actions performed by the library when creating an encrypted home volume.

Syncing keyboard layouts and console fonts in Leap and Tumbleweed

In parallel to our Scrum sprints, we have been for some time steady working, together with the openSUSE maintainers of X.Org and systemd, in redesigning how keyboard maps and console fonts are managed by YaST. Some changes were introduced in Tumbleweed some time ago but never made it to SLE (or Leap) because they needed more testing.

Recently Ludwig Nussel, the Leap’s release manager, decided that he wanted to sync 42.2 with Tumbleweed in that regard, using the new approach instead of the more conservative SLE one. Thus, we also invested quite some time coordinating again with Stefan Dirsch (X.Org) and Franck Bui (systemd) to push the changes just in time for the beta2 version of Leap 42.2… just in time to introduce bug#1000565, that was honored with its inclusion in the list of most annoying bugs in 42.2 Beta2.

The bright side is that a fix for the bug has already been provided (see bug report) and you can now finally test the new fonts and keyboard maps. Please, do so and provide feedback in order to get a properly localized Leap 42.2 release.

See you soon

As usual, this post was just a quick overview of the most interesting part of the sprint, because most people (including ourselves) don’t want to read about the boring part of the work, which is mainly fixing bugs.

The good news is that this time you will not have to wait another three weeks to read interesting stuff about YaST. As mentioned, we plan to publish a blog post about the reduction of the build time of YaST. And we will probably also publish a post about the visit of a YaST geecko to Euruko 2016.

So this time more than ever… stay tuned!

Posted in Base System, Distribution, Documentation, Factory, Hackweek, Programming, Systems Management, YaST | Comments Off on Highlights of YaST development sprint 25

Highlights of YaST development sprint 24

September 7th, 2016 by Yast Team

We are back to this blog after another three weeks of (mainly) bug-fixing. In the previous post we promised some news about the self-update functionality and about the LVM support in the new storage stack. We have that… and much more!

So this will be a long post, but it also hides some gems. You will have to keep reading in order to find them.

Self-update improvements

We have already mentioned in several previous reports the new self-update feature in YaST, which allows updating the installer itself before performing installation of the system.

But it turned out that the initial implementation had an important drawback. The self-update process happened after having performed some of the installation steps. Then, after updating the installer it was restarted and several of those steps lost their configuration or simply did their operations twice.

After some discussions we decided to move the self-update step earlier, at the very beginning. For downloading the updates we basically need just working network connection and initialized package management. So we moved the self-update step after the initial automatic network setup (DHCP) and added package initialization to the self-update step.

The self-update in action

As you can see the self-update step is the very first step in the installation workflow, the language selection and the EULA dialog is displayed after the self update is finished and YaST is restarted. That means all the following steps do not need to remember their state as they will not be called twice after the restart.

The disadvantage is that we had to drop some features. The self-update step happens before the language selection and the optional disk activation. That means by default the self-update progress (and potential error messages) will be displayed in English. But you can still use the “language” boot option and set the language manually via linuxrc.

On the bright side, we fixed like half a dozen of reported bugs just by relocating the self-update process. So we are pretty sure it’s worth the price.

For more details see the updated documentation.

Gem one: using the `info` boot parameter

The info boot parameter is a pretty old linuxrc option but it is probably not known well. The parameter is an URL which points to a text file which can contain more boot options.

When we tested the updated self-update described above we needed to build a driver update disk and pass several boot options. To avoid repeating the same options on the boot command line and to share the boot options across the team we created an info.txt file with content like

insecure=1
startshell=1
dud=ftp://example.com/self_update.dud

Then you simply boot the installation with info=ftp://example.com/info.txt and linuxrc will read the additional parameters from the file. This can save you a lot of typing, especially if you need to repeat the tests many times.

Fixed a security bug for 7 (yes, seven) different SLE releases

Some weeks ago, during a routine code review, our security experts found a vulnerability in YaST’s libstorage related to the way we provide the encryption passwords to some external commands. It is debatable how dangerous this threat really is. It was never a problem during system installation, but it would affect admins who create encrypted partitions (mostly encrypted LVM physical volumes) or crypto files in the installed system.

A potential attacker with access to /tmp could intercept the password in the very precise moment in which the “cryptsetup” or “losetup” command are invoked by YaST. It’s really only a matter of milliseconds. But we don’t want to take any risks, however small they may be.

So not only did we fix that for the current code streams, we backported it to all the SLE releases out there that are still supported (even though in some cases it’s just a single customer) – back to SLES-10 SP3 from late 2009. That meant backporting the fix to no less than 7 SLE releases (for Leap, those fixes are picked automatically).

As you can imagine, this got more difficult the farther back in history we went: In a central library like libstorage, things are constantly changing because the tools and environment (kernel, udev, you name it) are constantly changing. There was only a single case where the patch applied cleanly; in all other cases, it involved massive manual work (including testing, of course).

Was this fun? No, it certainly was not. It was a tedious and most frustrating experience. Do we owe it to our users (paying customers as well as community users) to fix security problems, however theoretical they are? Yes, of course. That’s why we do those things.

Storage reimplementation: every LVM piece in its place

As time permits, we keep adding new features to the future libstorage replacement. During previous sprints we added support to read and manipulate all kinds of LVM block devices (PVs, VGs and LVs) but an important aspect was missing: deciding the order of the operations is as important as performing them. We instructed the library about the dependencies between operations and implemented several automated test cases to ensure we don’t try to do not-so-smart things like removing a physical volume from a volume group and shrinking its logical volumes afterwards.

The good thing about our automated test-cases is that they generate nice graph that are quite useful to illustrate blog posts. 🙂

Gem two: enjoy Google Summer of Code result

As you may know, openSUSE is one of the Free Software organizations selected to take part in Google Summer of Code 2016. For YaST that means we had the huge pleasure of having Joaquín Yeray as student. You can know more about him and his experience diving into YaST and Open Source in his GSoC blog.

But the openSUSE community is not only gaining a new member, we also have a new YaST module. The yast2-alternatives package has already been accepted into Tumbleweed and will be also part of Leap 42.2. So we have a new gadget in our beloved configuration Swiss Army knife!

We liked Joaquín and his module so much that we are revamping the YaST development tutorial to be based on his module (instead of yast2-journal). He is already working on that, so hopefully we will have Joaquín around quite some time still. 😉

Unify license handling screens

We got a report about the license agreement screen in automatic installation (AutoYaST) being different to the one showed during common installation. So we decided to take a look to the problem and unify them. We are in a quite late phase of the development process of both the next SLE and the next Leap, so we decided to not unify the code but simply adapt one dialog to look like the other. Also we are after string freeze due to translations, so we had to use a trick and reuse another already translated text. We also took the opportunity to fix some small usability problems.

This is one of those cases in which some images are worth a thousand words, so in order to understand what we did, take a look at the description of this pull request, which includes many images (too many for this blog post).

Smarter check to avoid duplicated repositories

The openSUSE software server defines the online repositories which can be added during installation. The openSUSE DVD also specifies its own online repositories that are always added to the system. And these repositories overlap.

In openSUSE 42.1 it happened that one repository was added twice, even though there was already a check to avoid that. So we investigated why.

We found that the URLs for the problematic repository were not exactly the same, one of them had a trailing slash. Therefore we made the URL comparison more tolerant and if the URLs differ only by the trailing slash, they are still considered the same.

After the fix all repositories are added only once, without any duplicates.

Gem three: we are looking for new teammates!

After 12 sprint reports, most readers would have already realized that the life as a full-time YaST developer is everything but boring… and that we are always pretty busy. The fun and the work are better when you share them so… we are looking for a new hero to join us in our journey.

Even if you don’t feel hacking in YaST would be your thing, maybe you are interested in any of the other jobs at SUSE.

Improved documentation about YaST environment variables

The behaviour of YaST can be affected by several environment variables, but not all of them are well known by everybody. During this sprint we also decided to invest some time documenting them better. The resulting document will be soon properly integrated in our centralized documentation for developers, but you can sneak it already here.

Branching Tumbleweed and the upcoming stable releases

Most of the features and bug-fixes we have blogged about in the last months were incorporated to Tumbleweed, the upcoming Leap 42.2 and the future SLE 12-SP2, since we always try to keep those three codebases as close as possible to each other.

Now Leap 42.2 and SLE 12-SP2 are close enough to their release date, so we plan to be more conservative with the changes. At the end of this sprint we decided to branch the code for Tumbleweed and for the stable siblings. From now on, most exciting stuff will appear only in Tumbleweed, with SLE 12-SP2 and Leap 42.2 becoming more and more boring.

And the wheel keeps on turning

So that was a very minimal selection of the most interesting stuff from the just finished sprint. What comes next? Another sprint, of course! We have already planned some interesting stuff for it, like integrating the new partitioning proposal into the installer or finishing the ultra-cool UI designer that was started during latest Hack Week.

As always, you can follow development in a daily basis in the usual channels (#yast IRC channel and the yast-devel mailing list) or wait another three weeks for the next sprint report. Meanwhile… have a lot of fun!

Posted in Distribution, Factory, GSOC, Programming, Systems Management, YaST | Comments Off on Highlights of YaST development sprint 24

Highlights of YaST development sprint 23

August 18th, 2016 by Yast Team

As already mentioned in our previous blog post, with Leap 42.2 in Alpha phase and SLE12-SP2 in Beta phase, the YaST Team is concentrating the firepower in fixing bugs in the installer. We fixed more than 40 bugs in three weeks! The dark side is that most bug fixes are not juicy enough for writing a blog post… but there is always some interesting stuff to report.

Integration of installer self-update with SCC and SMT

The installer self-update feature integrates now with SUSE Customer Center (SCC) and Subscription Management Tool (SMT) servers. Until now, there were three different mechanisms to get the URL of the installer updates repository:

User defined (using the `SelfUpdate` boot option).
Using an AutoYaST profile.
The default one, specified in the `control.xml` which is shipped in the media.

Now YaST2 is able to ask for the repository URL to SCC/SMT servers. The details of how the URL is determined are documented in the repository.

Fixes and enhanced usability in dialogs with timeout

As you may know, it’s possible to install (open)SUSE in an automatic, even completely unattended, basis using AutoYaST. AutoYaST can be configured to display custom configuration dialogs to the user and wait for the reply a certain amount of time before automatically selecting the default options. Until now, the only way for the user to stop that countdown was to start editing some of the fields in the dialog.

We got a bug report because that functionality was not working exactly as expected in some cases so, in addition to fixing the problem, we decided to revamp the user interface a little bit to improve usability. Now there are more user interactions that are taken into account to stop the counter, specially we added a new “stop” button displaying the remaining seconds. You can see an example of the result below.

Following, as usual, the Boy Scout Rule we also took the opportunity to add automated tests to make that part of YaST more robust for the future.

Automatically integrating add-on repositories during installation

Sometimes you want to extend the regular installation media by adding just a few extra packages or provide a number of fixed packages along with the media.

For this purpose, the installer can automatically register an add-on repository. All you have to do is to put the repository on the installation medium and to add a file /add_on_products.xml that points to this repository.

The file looks like this:

<?xml version="1.0"?>
<add_on_products xmlns="http://www.suse.com/1.0/yast2ns"
    xmlns:config="http://www.suse.com/1.0/configns">
    <product_items config:type="list">
        <product_item>
            <name>My Add-on</name>
            <url>relurl://myaddon?alias=MyAddon</url>
            <priority config:type="integer">70</priority>
            <ask_user config:type="boolean">false</ask_user>
            <selected config:type="boolean">true</selected>
            <check_name config:type="boolean">false</check_name>
        </product_item>
    </product_items>
</add_on_products>

You can define the following elements:

<name> is the name of your repository
<url> points the the repository location; you’ll likely want to use the relurl scheme here that gives the location relative to the main installation repository
<priority> is the repository priority (lesser number means higher priority, the main installation repository has priority 99)
<ask_user>: should the user be asked about adding the repository?
<selected>: should the repository be automatically selected?
<check_name>: should the repository’s actual name be matched against the value of the <name> element?

You can of course list several repositories in this file.

If you’re too lazy to remember all this, mksusecd can do all this for you.

For example, if you have a set of new kernel packages you would like to use, do:

mksusecd --create new.iso --addon kernel-*.rpm --addon-name 'my kernel' sles12-sp2.iso

This creates a new iso based on sles12-sp2.iso that will install your new kernel packages instead.

Storage reimplementation: small steps for the code, giant leap for continuous integration

During bug squashing we managed to find some time to keep the storage stack reimplementation rolling… slow and steady. The customized Tumbleweed images (labeled as NewStorage) in the storage-ng OBS repository are already able to analyze most systems, creating a representation of the system storage devices in memory that will be used to manipulate the disks and propose a partitioning schema. Unfortunately, this representation is only visible in the YaST logs since fixing installer bugs was more urgent than representing that information in the UI.

This turned to be an important milestone, not because of the functionality itself or the value of the code (we just added a couple of lines of Ruby code), but because for the first time the dependencies in some packages were switched from libstorage to libstorage-ng. That had important implications for the code organization and for our continuous integration infrastructure, specially the Travis CI integration, which implies the generation of .deb packages. We can now say that our continuous delivery workflow (from Github to OBS, passing through Jenkins, Travis, Coveralls and Code Climate) is free of any trace of the old storage code.

In addition, we also did some good progress in LVM support in the new library, being able to recognize and manipulate in memory all kind of LVM structures.

The joy of openness: updating the SUSE Linux Enterprise documentation

An important part of our job, specially as a new release date approaches, is helping to shape the SUSE Linux Enterprise (SLE) documentation. One of the strongest points of SUSE products is the awesome SUSE’s documentation team which, as the rest of the company, have open source in their genes. Suggesting improvements and updates for the documentation is as straightforward as creating a pull request in the completely open documentation repository at Github… and anybody can do it!

The documentation team uses Docbook, but they would accept contributions in other formats (e.g. Markdown) and transform it themselves into Docbook… just because they are that cool. 🙂

Better support for ARM systems using EFI

The world is getting full of cool ARM64 devices and both SUSE and openSUSE are actively working in supporting as many of them as possible. We took another small step during this sprint improving the installer’s partitioning proposal for ARM systems that use EFI.

That’s not all, folks

As we always say, this was just the small portion of the work done that we consider exciting enough to be part of our development reports, since we don’t want to bore you with details about every single fixed bug. During this installer bug-fixing phase, this is more true than ever and the next sprint, which is already planned, will be similar to this in that regard. Nevertheless, in the next report we expect to have some interesting news about the installer self-update functionality and about the LVM support in the new storage stack. Stay tuned.

Posted in Distribution, Documentation, Factory, Programming, Systems Management, YaST | 2 Comments »

Live USB improvements

August 14th, 2016 by Jigish Gohil

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.

(more…)

Tags: Fedora, iPXE, Mint, openSUSE, ubuntu
Posted in Miscellaneous, Programming | Comments Off on Live USB improvements

Highlights of YaST development sprint 22

July 27th, 2016 by Yast Team

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.

Installer memory consumption reduced

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…

Storage reimplementation: another step to an installable system

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!

Make many extensions fit on the screen properly

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.

Storage reimplementation: LVM unit testing

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).

Improved patterns handling for system roles

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.

Storage reimplementation: the future of booting

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.

Conclusion

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!

Posted in Distribution, Factory, Programming, Systems Management, YaST | 1 Comment »

Highlights of YaST development sprint 20

June 7th, 2016 by Yast Team

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!

Debugger in the installer

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.

Interface improvements for SSH host keys importing

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!

AutoYaST support for SSH host keys importing

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>

Firewalld support in YaST2-Firewall

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!

Support for vncmanager 3

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.

New registration UI

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:

Register the system using scc.suse.com by introducing an e-mail and a registration code.
Register the system using a local SMT server (no e-mail or registration code are used).
Skip the registration step.

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)?

Text-based Registration UI

Progress in the new storage layer

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.

Will be back… very soon

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!