Home Home > 2019 > 03
Sign up | Login

Deprecation notice: openSUSE Lizards user blog platform is deprecated, and will remain read only for the time being. Learn more...

Archive for March, 2019

Żegnamy forum.suse.pl i witamy forums.opensuse.org

March 31st, 2019 by

Witajcie,

10 września 2004 roku cyberluk wysłał do mnie i do Mirona taką wiadomość:

Witam,

Od początku istnienia Forum uważnie obserwujemy użytkowników i ich wypowiedzi. Wczoraj padła propozycja, żeby zaoferować dwom osobom moderowanie Forum. Dzisiaj po dyskusji na ten temat ustaliliśmy, że faktycznie te osoby dostana status moderatora, oczywiście o ile się na to zgodzą. Jedna z tych osób jest Pan. Czy pasuje Panu status moderatora?
Drugiej osoby na razie nie ujawniamy. Dostanie takiego samego maila.
Oczywiście cala załoga będzie nadal patrzeć, co się dzieje z Forum, ale praca jest pracą i czasami nie ma czasu na zajmowanie sie Forum.
Liczymy na pozytywna odpowiedz. Na razie jest to status moderatora Forum, ale zaczęliśmy się również zastanawiać nad FAQiem, który byłby zbiorem problemów z Forum “w pigułce”. Oczywiście status moderatora wiązałby się z odpowiednimi uprawnieniami przy takim FAQu.

cyberluk

Oczywiście pod domeną forum.suse.pl już wcześniej był dostępny skrypt phpBB. Jednak to połowa 2004 roku spowodowała, że Forum otworzyło się na zwykłych użytkowników. To właśnie zwykli użytkownicy zdominowali Forum, tworzyli jego kontent, zarządzali nim i warto to podkreślić. Początkowo Novell Professional Services, a ostatecznie SUSE Polska, udostępniało nam, polskiej społeczności, zasoby i przestrzeń, z których z pożytkiem dla każdego z nas korzystaliśmy.

W ten sposób przez piętnaście lat zwykli użytkownicy, power userzy, a także ludzie zawodowo związani z branżą IT dzielili się między sobą doświadczeniem na Oficjalnym Polskim Forum SUSE Linux. Czas je pożegnać.

Obecnie przestrzenią dla nas będzie forums.opensuse.org. Będąc bliżej Projektu openSUSE, będzie nam łatwiej włączyć się w różnego rodzaju aktywności i koordynować je. Natomiast zwykli użytkownicy zyskają dostęp do znacznie większej społeczności.

Polska sekcja jest widoczna jako subforum pod adresem forums.opensuse.org lub bezpośrednio forums.opensuse.org/forumdisplay.php/936-Polski

W przypadku problemów z rejestracją, proszę o kontakt: pbojczuk@opensuse.org.

Poradnik przetrwania:
forums.opensuse.org/showthread.php/531844-Poradnik-przetrwania-na-forums-opensuse-org?p=2871109

Dostęp do forum.suse.pl będzie ograniczany, a samo Forum wkrótce zamknięte.

Love & bruises,
Przemysław “Stefan” Bojczuk

Highlights of YaST Development Sprint 74

March 29th, 2019 by

It took only 73 sprints to complete all YaST features, and there are none left to do. That’s what you might think after reading this article, because we worked on no features, just bug fixes.

It might be related to an upcoming release of SLE 15 SP1. For its openSUSE sibling we have put together a recap of YaST features in the upcoming openSUSE Leap 15.1 (scheduled for May 2019), since Leap 15.0 (May 2018).

No more locale errors during Kubic runtime

Did you know that an installed Kubic (the certified Kubernetes distribution & container-related technologies built by the openSUSE community) only has the American English locale (en_US) available? That is because it intends to be as small as possible (you can run du -h /usr/share/locale if you are curious enough).

However, YaST allows you to change the language and the keyboard layout at the very beginning of the installation process, which will be persisted as the default locale in the installed system. This is the reason for those locale errors mentioned above. Until now. Because we introduced some changes during this sprint to allow that the chosen language will be used only during the installation in case the product needs it.

So, from now on you can go through the installation of Kubic in your preferred language without those errors in the final system and, of course, preserving the selected keyboard layout. Not bad, huh? 😎

Various Fixes

Repositories for add-ons would be marked as disabled after the installation has finished. We have fixed this bug#1127818.

When registering your SUSE Linux Enterprise with the SUSE Customer Center or its proxy such as the SUSE Subscription Management Tool, a network timeout can occur. Formerly you had to use the Back and Next buttons to try again but we have added a Retry button for that.

When creating a new partition or editing an existing one, the widget for the partition type would list the types in a seemingly random order. We have made this widget more boring.

Highlights of YaST Development Sprint 73

March 14th, 2019 by

As (open)SUSE releases are approaching, the YaST team is basically in bug squashing mode. However, we are still adding some missing bits, like the bcache support for AutoYaST. Additionally, there are some interesting improvements we would like to let you know about:

  • AutoYaST support for using Btrfs subvolumes as user home directories.
  • Improved Certificates management in the registration module.
  • Correct detection of DASDs when using virtio-blk.
  • Proper handling of the resume option in the bootloader module.
  • Display fonts and icons properly during installation.

And, as a bonus, some insights about a YaST font scaling problem on the GNOME desktop (spoiler: not a YaST bug at all).

Adding bcache support to AutoYaST

A few days ago, support for bcache landed in the YaST Partitioner. In a nutshell, bcache is a caching system that allows to improve the performance of any big but slow disk (so-called backing device) by using a faster and smaller disk (caching device).

The way to describe a bcache in AutoYaST is pretty similar to how a RAID or a LVM Volume Group is described. On one hand, you need to specify which devices are going to be used as backing and caching devices by setting bcache_backing_for and bcache_caching_for elements. And, on the other hand, you need to describe the layout of the bcache device itself. As you would do for a RAID, you can partition the device or use it as a filesystem.

The example below creates a bcache device (called /dev/bcache0) using /dev/sda to speed up the access to /dev/sdb.

<partitioning config:type="list">
    <drive>
      <type config:type="symbol">CT_DISK</type>
      <device>/dev/sda</device>
      <disklabel>msdos</disklabel>
      <use>all</use>
      <partitions config:type="list">
        <partition>
          <!-- It can serve as caching device for several bcaches -->
          <bcache_caching_for config:type="list">
            <listentry>/dev/bcache0</listentry>
          </bcache_caching_for>
          <size>max</size>
        </partition>
      </partitions>
    </drive>

    <drive>
      <type config:type="symbol">CT_DISK</type>
      <device>/dev/sdb</device>
      <use>all</use>
      <!-- <disklabel>none</disklabel> -->
      <disklabel>msdos</disklabel>
      <partitions config:type="list">
        <partition>
          <!-- It can serve as backing device just for one bcache -->
          <bcache_backing_for>/dev/bcache0</bcache_backing_for>
        </partition>
      </partitions>
    </drive>

    <drive>
      <type config:type="symbol">CT_BCACHE</type>
      <device>/dev/bcache0</device>
      <bcache_options>
        <cache_mode>writethrough</cache_mode>
      </bcache_options>
      <use>all</use>
      <partitions config:type="list">
        <partition>
          <mount>/data</mount>
          <size>20GiB</size>
        </partition>
        <partition>
          <mount>swap</mount>
          <filesystem config:type="symbol">swap</filesystem>
          <size>1GiB</size>
        </partition>
      </partitions>
    </drive>
  </partitioning>

Using Btrfs Subvolumes as User Home Directories in AutoYaST

In our last report we presented a new feature to allow using Btrfs subvolumes as user’s home directories. However, the AutoYaST support for that feature was simply missing.

Now you can use the home_btrfs_subvolume to control whether a Btrfs should be used as home directory.

<user>
   <encrypted config:type="boolean">false</encrypted>
   <home_btrfs_subvolume config:type="boolean">true</home_btrfs_subvolume>
   <fullname>test user</fullname>
   <gid>100</gid>
   <home>/home/test</home>
   <shell>/bin/bash</shell>
   <uid>1003</uid>
   <user_password>test</user_password>
   <username>test</username>
</user>

Tuning the Bootloader’s resume parameter

The resume parameter is used by the bootloader to tell the kernel which swap partition should be used for the suspend to disk feature. If you are curious enough, you can find the value for your system in the Kernel Parameters tab of the YaST bootloader module. Now that we know what the resume parameter is, it is time to talk about the two issues we have solved recently.

The first problem was related to the way in which YaST determines which swap partition should be used. The bug report mentioned that YaST was taking a swap partition not used by the system that, in addition, was located in a removable device. After checking the code, we found out that we were using a simplistic heuristic which just selected the biggest swap partition available. We improve that logic to use the biggest swap partition which is being used by the system. However, if no suitable partition is found, YaST will fall back to the old behaviour.

The second problem was related to AutoYaST not handling the noresume option properly. When a user specified that option, AutoYaST just blindly added it to the kernel command line keeping the conflicting resume parameter too. Of course, that caused troubles. Now when noresume is given, AutoYaST simply removes all occurrences of the resume parameter.

Registration, OpenSSL and Debugging

These days, handling the SSL certificates in a proper way is key to keep our systems secured. So during this sprint, we invested quite some time improving how certificates are used in our registration module. Basically, we have improved YaST behaviour in these scenarios:

  • Using self-signed certificates.
  • Handling with unknown certificate authorities.

When the custom registration server (the new RMT or the older SMT) use a self-signed certificate, YaST offers to import the server certificate and make it known to the system.

Self-signed Certificate Dialog

On the other hand, when the server SSL key was signed by an unknown key, YaST used to just display an error popup. That was not much helpful as it was not obvious what to do. Now a new popup which contains some hints about how to import the CA certificate manually is displayed. In this case it cannot be imported automatically as YaST does not know where to obtain it, it is not present in the server response.

Unknown Certificate Authority Dialog

The work of importing and activating the certificate is now performed by a YaST script, preventing the user from having to run some complicated (and error prone) commands manually.

These improvement and some other OpenSSL details have been documented in the OpenSSL Certificates documentation. Additionally, if you ever need to debug some SSL related issue, this new OpenSSL Debugging Hints documentation might be useful for you. It covers basic topics, like displaying PEM certificate details, running a testing HTTPS server, creating a self-signed certificate, etc.

Detecting DASDs when using virtio-blk in zKVM

IBM’s S/390 platform has some special features that you will not find in conventional architectures like x86. One of them are DASD hard disks. These devices can be accessed in zKVM using the virtio-blk backend, but DASDs need special handling. For instance, the most common DASD type (CDL ECKD) cannot be used with an MS-DOS partition table nor a GPT, instead a DASD partition table is required. Having this requirement in mind, YaST now detects DASDs using virtio-blk properly and uses the correct DASD partition table.

Improving Fonts and Icons Handling in the Installer

Back some time ago, Stasiek Michalski (a.k.a. as hellcp), one of our very active openSUSE community contributors, spent quite some work for better artwork in YaST. As a result, icons are now used from the desktop’s icon theme whenever possible, and the installer font was changed.

One fallout of the latter was that the font size was now too small for users with diminishing eyesight: That new font has different font metrics, so the default font size was too small. We fixed that during this sprint. See also openSUSE/branding#107.

By the way, the disappearing icons issue was solved too. See libyui/libyui-qt#100 if you are interested in the details.

And just to get this straight: We are welcoming active community members to contribute (thanks again, @hellcp!). There will be some bugs; that’s just natural. We need to cooperate to fix them.

YaST Font Scaling Problem on the GNOME Desktop

This is not really a YaST problem, but of course it was still the natural thing to write a bug report against YaST for this bsc#1123424. And it took us quite a while to figure out what went wrong here.

Basically, when you use the GNOME Tweak Tool to set a Font Scaling Factor that is not a multiple of 0.25, this is completely ignored, and so all Qt5 applications (including the YaST Qt Control Center and all YaST modules) appear with unscaled fonts.

The problem is this GNOME Tweak Tool setting non-integer DPI values (which is already out of spec and thus a bug) and the Qt5 libraries consequently completely ignoring that DPI value. So that GNOME tool should do it correctly, but the Qt5 libs could also handle this more gracefully.

Unfortunately, there is nothing that we can do about this from the YaST side, even though we are aware that this might become reported as a YaST bug again in the future 🙂

Closing Thoughs

As we stated at the beginning of this post, we are basically in bug squashing mode. So, please, if you have some time, give the testing versions of (open)SUSE a try and report as many bugs as you can.

Thanks!