• A feature to search for packages across all SLE modules has arrived to YaST.
• Improved support for S390 systems in the network module.
• YaST command-line interface now returns a proper exit-code.
• Added progress feedback to the Expert Partitioner.
• Partial support for Bitlocker and, as a lesson learned from that, a new warning about resizing empty partitions.

The Online Search Feature Comes to YaST

As you already know, starting in version 15, SUSE Linux follows a modular approach. Apart from the base products, the packages are spread through a set of different modules that the user can enable if needed (Basesystem module, Desktop Applications Module, Server Applications Module, Development Tools Module, you name it).

In this situation, you may want to install a package, but you do not know which module contains such a package. As YaST only knows the data of those packages included in your registered modules, you will have to do a manual search.

Fortunately, zypper introduced a new search-packages command some time ago that allows to find out where a given package is. And now it is time to bring this feature to YaST.

For technical reasons, this online search feature cannot be implemented within the package manager, so it is available via the Extra menu.

YaST offers a simple way to search for the package you want across all available modules and extensions, no matter whether they are registered or not. And, if you find the package you want, it will ask you about activating the needed module/extension right away so you can finally install the package.

If you want to see this feature in action, check out the demonstration video. Like any other new YaST feature, we are looking forward to your feedback.

Fixing and Improving Network Support for S390 Systems

We have mentioned a lot of times that we recently refactored the Network module, fixing some long-standing bugs and preparing the code for the future. However, as a result, we introduced a few new bugs too. One of those bugs was dropping, by accident, the network devices activation dialog for S390 systems. Thus, during this sprint, we re-introduced the dialog and, what is more, we did a few improvements as the old one was pretty tricky. Let’s have a look at them.

The first obvious change is that the overview shows only one line per each s390 group device, instead of using one row per each channel as the old did.

Moreover, the overview will be updated after the activation, displaying the Linux device that corresponds to the just activated device.

Last but not least, we have improved the error reporting too. Now, when the activation fails, YaST will give more details in order to help the user to solve the problem.

Fixing the CLI

YaST command-line interface is a rather unknown feature, although it has been there since ever. Recently, we got some bug reports about its exit codes. We discovered that, due to a technical limitation of our internal API, it always returned a non-zero exit code on any command that was just reading values but not writing anything. Fortunately, we were able to fix the problem and, by the way, we improved the behavior in several situations where, although the exit code was non-zero, YaST did not give any feedback. Now that the CLI works again, it is maybe time to give it a try, especially if it is the first time you hear about it.

Adding Progress Feedback to the Partitioner

The Expert Partitioner is a very powerful tool. It allows you to perform very complex configurations in your storage devices. At every time you can check the changes you have been doing in your devices by using the Installation Summary option on the left bar. All those changes will not be applied on the system until you confirm them by clicking the Next button. But once you confirm the changes, the Expert Partitioner simply closes without giving feedback about the progress of the changes being performed.

Actually, this is a kind of regression after migrating YaST to its new Storage Stack (a.k.a. storage-ng). The old Partitioner had a final step which did inform the user about the progress of the changes. That dialog has been brought back, allowing you to be aware of what is happening once you decide to apply the configuration. This progress dialog will be available in SLE 15 SP2, openSUSE 15.2 and, of course, openSUSE Tumbleweed.

Recognizing Bitlocker Partitions

Bitlocker is a filesystem encrypting technology that comes included with Windows. Until the previous sprint, YaST was not able to recognize that a given partition was encrypted with such technology.

As a consequence, the automatic partitioning proposal of the (open)SUSE installer would happily delete any partition encrypted with Bitlocker to reclaim its space, even for users that had specified they wanted to keep Windows untouched. Moreover, YaST would allow users to resize such partitions using the Expert Partitioner without any warning (more about that below).

All that is fixed. Now Bitlocker partitions are correctly detected and displayed as such in the Partitioner, which will not allow users to resize them, explaining that such operation is not supported. And the installer’s Guided Setup will consider those partitions to be part of a Windows installation for all matters.

Beware of Empty Partitions

As explained before, whenever YaST is unable to recognize the content of a partition or a disk, it considers such device to be empty. Although that’s not longer the case for Bitlocker devices, there are many more technologies out there (and more to come). So users should not blindly trust that a partition displayed as empty in the YaST Partitioner can actually be resized safely.

In order to prevent data loss, in the future YaST will inform the user about a potential problem when trying to resize a partition that looks empty.

Hack Week is coming…

That special time of the year is already around the corner. Christmas? No, Hack Week! From February 10 to February 14 we will be celebrating the 19th Hack Week at SUSE. The theme of this edition is Simplify, Modernize & Accelerate. If you are curious about the projects that we are considering, have a look at SUSE Hack Week’s Page. Bear in mind that the event is not limited to SUSE employees, so if you are interested in any project, do not hesitate to join us.

So it is time for another sprint report. During the last two weeks, we have been basically busy squashing bugs and trying to get the network module as feature-complete as possible. But, after all, we have had also some time to improve our infrastructure and organize for the future.

YaST2 Network Refactoring Status

Although we have been working hard, we have not said a word about the yast2-network refactoring progress since the end of July, when we merged part of the changes into yast2-network 4.2.9 and pushed it to Tumbleweed. That version included quite a lot of internal changes related to the user interface and a few bits of the new data model, especially regarding routing and DNS handling.

However, things have changed a lot since then, so we would like you to give you an overview of the current situation. Probably, the most remarkable achievement is that the development version is able to read and write the configuration using the new data model. OK, it is not perfect and does not cover all the use cases, but we are heading in the right direction.

In the screencast below you can see it in action, reading and writing the configuration of an interface. The demo includes handling aliases too, which is done way better than the currently released versions.

Moreover, we had brought back support for many types of devices (VLAN, InfiniBand, qeth, TAP, TUN, etc.), improved the WiFi set-up workflow and reimplemented the support for renaming devices.

Now, during the current sprint, we are focused on taking this new implementation to a usable state so we can release the current work as soon as possible and get some feedback from you.

Finally, if you like numbers, we can give you a few. Since our last update, we have merged 34 pull requests and have increased the unit test coverage from 44% in openSUSE Leap 15.0/SUSE Linux Enterprise SP1 to around 64%. The new version is composed of 31.702 (physical) lines of code scattered through 231 files (around 137 lines per file) vs 22.542 in 70 files of the old one (more than 300 lines per file). And these numbers will get better as we continue to replace the old code

Missing Packages in Leap

It turned out that some YaST packages were not updated in Leap 15.1. The problem is that, normally, the YaST packages are submitted to the SLE15 product and they are automatically mirrored to the Leap 15 distribution via the build service bots. So we do not need to specially handle the package updates for Leap.

However, there are few packages which are not included in the SUSE Linux Enteprise product line, but are included in openSUSE Leap. Obviously these packages cannot be updated automatically from SUSE Linux Enterprise because they are not present there. In this case Leap contained the old package versions from the initial 15.0 release.

In order to fix this issue, we manually submitted the latest packages to the Leap 15.2 distribution. To avoid this problem in the future we asked the Leap maintainers to add the Leap specific packages to a check list so they are verified before the next release. Of course, if you see any outdated YaST package in Leap you can still open a bug report.

Just for reference, the affected packages are: yast2-alternatives, yast2-slp-server, yast2-docker and skelcd-control-openSUSE (the content is only present on the installation medium, it’s not released as an RPM).

Let’s use all disks!

As you may remember, three sprints ago we added some extra configuration options to make the storage guided proposal able to deal with the SUSE Manager approach. We even wrote a dedicated blog post about it!

Despite offering the new options in the Guided Setup, we tried to keep the default initial behavior of the installer consistent with other (open)SUSE products. So the installer initially tried to install the whole system in a single disk, unless that was impossible or it was told by the user to expand on several disks.

But the SUSE Manager folks found that to be contrary to the new ideas introduced in their Guided Setup. According to their feedback, in this case remaining consistent with other (open)SUSE product was not reducing the confusion, but rather increasing it. SUSE Manager should try from the very beginning to expand the product as much as possible among all available disks.

For that reason, during this sprint we introduced the first improvement (a.k.a. another configuration option), so now it is possible to tell whether the initial proposal should try to use multiple disks as first try.

Bootloader and Small MBR Gaps

We received a bug report because a system was not able to boot after installation. In this case, the user decided to use Btrfs and placed the root file system in a logical partition. In theory, this scenario should work but, unfortunately, the MBR gap was too small to embed the Grub2 bootloader code.

At first sight, this problem could be solved by asking YaST to install the bootloader into the logical partition and the generic boot code in the MBR. But this will only work if you set the logical partition as the active one. Sadly, some BIOSes could insist on having a primary partition as the active one.

But don’t worry, we have good news. Grub2 maintainers took care of this problem. In case the MBR gap is too small, Grub2 will automatically fall-back to the Btrfs partition. That’s all. And what does it mean for YaST? Well, thanks to this fix, YaST will simply work out of the box and your system will be bootable again. But not so fast! You still have to wait a little bit more to have these Grub2 improvements available in a Tumbleweed installer.

Handling Empty Comment Lines in NTP Configuration

AutoYaST supports defining an specific NTP configuration to be applied during the installation and it relies in Augeas to read/write the ntp.conf file. But it seems that Augeas has some problems when it tries to write comments with empty lines, as you can see in bug 1142026. The solution was to adapt YaST to filter out empty comment lines before saving the configuration file, working around the Augeas problem.

Error Resizing Some Partitions

Typically, an MS-DOS partition table reserves its first MiB for the MBR gap, so the partitions normally start after that point. But it is possible, especially in partitions for old Windows systems, that it starts before that first MiB. In that case, if we try to resize that partition (e.g., by using the Expert Partitioner), YaST crashes due to an error when calculating the resize information. Fortunately, this problem is gone now, and you will be able to resize this kind of partitions as well.

Side Effects of Keyboard Layouts Unification

During the sprint 81, the openSUSE and SUSE Linux Enterprise console keyboard layouts were unified after some minor changes. One of those changes was to stop using the, in appearance, useless keymaps symlinks for Arabic and Cambodian. But they were there for a reason: are being used by YaST to correctly adapt the keyboard in the X11 environment. Just visit the pull request if you prefer to scare yourself want to dive in more technical details.

Fortunately for the users of those keyboards, we realized about this problem before the upcoming SLE-15-SP2 was released And, it’s fixed.

House Keeping Tasks

As part of our development duties for this sprint, we invested quite some time in reviewing and updating our continuous integration (CI) set up. Apart from using Travis CI for pull requests, we rely on Jenkins to run the tests and submit the code to the appropriate projects in the Open Build Service instances.

Then, when the development of a new version starts or when the product is about to be released, we need to adjust the configuration. Just in case you are wondering, we do not do this work by hand anymore and we use Salt and Jenkins Job Builder to handle this configuration.

Closing Thoughts

During the next sprint (actually, the current one) we are working in three different areas, apart from squashing bugs: improving encryption support in the storage layer, adding some features to the installer (repo-less installer, support for reading product licenses from a tarball, etc.) and, of course, refactoring the network code. Obviously, we will give you all sort of details in our next sprint report.

But a post describing all that we have done would be quite long :), so let’s try to highlight a few of them.

• YaST got a security audit and, although no real security problems were found, we were asked to introduce some improvements.
• Now it is possible to run the installer through PXE Boot without any local repository. Pretty specific but cool stuff!
• We are in the process of revamping SUSE Manager Salt Formulas support in the YaST2 Configuration Management module. Do not be fooled by the name, it is not limited to SUSE Manager.
• YaST icons are now included in the package were they are used. We hope it will make things easier for icon designers.
• The Firewall module got support for creating firewalld custom zones.
• Performance when reading huge /etc/hosts files has been greatly improved.
• CD/DVD sources are always disabled after installation.

YaST Security Hardening

Our SUSE security team did a security audit for YaST. The good news is that there were no real security problems that you should be concerned about. Still, we did some hardening to make the code even more secure.

This might have caused some breakages in Factory / Tumbleweed because many places in the code were touched. We apologize for any inconveniences that might have caused; but we are sure you prefer YaST to be more secure.

Most changes were centered around calling external commands, which YaST does a lot. Since YaST is running with root permissions in most cases, we want to make sure that this is as secure as possible. If you find any problems with it, please write bug reports.

What exactly we did and how we did it is summarized here: YaST Security Audit Fixes: Lessons Learned and Reminder

Installing via PXE Boot without any Installation Repository

In data centers and other big-scale enterprise environments, administrators rarely install new software via removable media such as DVDs. Instead, administrators rely on PXE (Preboot eXecution Environment) booting to image servers.

Installing Linux Enterprise in such environments typically requires two auxiliary servers in the local network:

• The DHCP/TFTP server providing the minimal system used by PXE to execute the installer.
• A server making the SLE DVD repository accessible in the local network via FTP, HTTP or any similar protocol.

Very often, the second one is more a requisite imposed by the installer than something really useful. In most cases, the system been installed will be registered in the SUSE Customer Center (or any of its proxy technologies like SMT or RMT) and will get all the software from there. Thus, we decided to save the administrators the extra steps of downloading the SLE ISO image and setting up an install server to serve the content of that ISO, for cases in which that was really not needed.

But the repositories are not only used to get the software been installed in the final system. As explained often in this blog, we have a single installer for all the products and flavors of SUSE and openSUSE, as different as the installation process looks for all of them. That generic installer uses the information in the installation repository to get its own configuration. That includes the available products (and its corresponding system roles), the steps and options to present to the user, the desired partitioning setup and many other aspects. Without that information, the installer is basically a musician without his score.

Starting with SLE-15-SP1, it will be possible to use the boot parameter NOREPO=1 to tell the installer to not expect (and more important, to not require) any local repository in the DVD or in the local network. In that case, the installer will be able to proceed up to the registration screen and get the information for the upcoming steps of the installation from the registration server. In the openSUSE case (where registration makes no sense), it will be able to reach the screen that allows to add more repositories.

Another step (and certainly not an easy one) to improve the installation experience for our users. Data center administrators, enjoy!

Revamping SUSE Manager Salt Formulas Support

Back in 2017, the YaST Configuration Management module got support to handle SUSE Manager Salt Formulas as part of a Hack Week project. If you do not know what this feature is about, you might be interested in checking the Forms are the Formula for Success presentation or the Hack Week project follow-up post.

Since then, the forms specification has evolved quite a lot and YaST support was basically outdated. So on November 2018 we started to work in order to bring the missing pieces to the YaST module. Basically, we rewrote the forms support and, although there are still rough edges, we are pretty close to release a new version with up-to-date support for this powerful feature.

Managing Custom Zones Definitions in YaST Firewall

The new YaST UI for configuring firewalld was announced in the report of the sprint #63 (four months ago… time flies!) and, since then, we have continued improving it.

firewalld ships with some predefined zones. Although it covers most users needs, in addition it allows the user to define custom zones. During the last sprint we have added support in the new UI and also in AutoYaST to manage custom zones.

During the development process some problems detected in the AutoYaST configuration were addressed too.

Updated YaST Branding and Icon Handling

In the past the YaST icons were included in the yast2-branding-openSUSE (openSUSE) and yast2-theme-SLE (SUSE Linux Enterprise) packages. The standard YaST icons were included in these packages, the standard YaST modules did not include any icons.

However, the disadvantage for the icon designer was that it was not clear which icons were really used.
If you wanted to update the icon theme you could potentially do a lot of useless work because some icons were not used anymore.

Now the icons are included in the respective YaST package, if the package is dropped the icon is dropped as well.

The package manager UI includes compiled-in fallback icons. That means if the branding package is broken or the icon files are accidentally deleted from disk then it will be still usable for emergency recovery.

The branding still works, the vendor can still provide specific icons which will override the included ones. So it is still possible to have a different look in the openSUSE and SLE products.

A big thank you goes to Stasiek Michalski and Noah Davis from the community who did the changes in the YaST code, designed the new icons and did a lot of cleanup!

Improving Performance when Loading Huge /etc/hosts Files

It might happen that you need to maintain a huge /etc/hosts file, especially when dealing with ads blockers. Such file with thousands of lines took an incredible amount of time to get loaded into YaST2. On some configurations it could even happen that loading a /etc/hosts with around 10.000 lines freezes the system completely. After some refactoring in YaST2 Host module, the performance has been significantly improved and loading a file with 10.000 lines now takes approximately 30s on the same configuration where it crashed before.

Disabling CD/DVD Repositories After Installation

If you install your system from a CD/DVD source it usually happens that this repository was not available for whole live of the system. In some use cases this was only uncomfortable because of some warnings but, in other cases, it caused serious complications, for instance, when trying to do a migration.

In the past, under some circumstances, those repositories were already disabled. But, from now on, they will be disabled always in order to avoid unwanted side effects.

Closing Thoughts

That’s all for the first report of 2019. In case you are wondering, the plan is to stick to the plan of publishing a report after each sprint, so expect the next one in about two weeks.

However, we recently had to migrate from the so called GitHub Services (now deprecated) to GitHub web hooks, so you might get an extra blog post about that very soon.

Stay tuned!

Harder to ignore installation warning

The “installation settings” summary screen usually reports some non-critical errors displayed as a red text. Although the installation can proceed despite those errors, they are usually serious enough to lead to problems. That’s why we decided to introduce a change to highlight them a little bit more, making them harder to overlook.

The following screenshot shows the newly introduced confirmation dialog, presented before proceeding with installation.

Make DHCLIENT_SET_HOSTNAME configurable on a per-interface basis

But that’s not the only usability-oriented enhancement on this sprint. We also reworked a bit the network configuration dialog.

For home users is very common to use a fixed hostname -set during installation- for our beloved linux box. But in some circumstances it’s better to set the hostname of the machine dynamically using DHCP, something YaST has always allowed to do by just ticking a checkbox that used to be in the network configuration screen. See “Change Hostname via DHCP” below.

That checkbox used to modify the system-wide variable DHCLIENT_SET_HOSTNAME, which was fine in scenarios in which only one of the network interfaces was configured via DHCP. But with several network interfaces connected to different DHCP-enabled networks, some problems arose.

During installation, if network configuration is used, Linuxrc creates the ifcfg files with DHCLIENT_SET_HOSTNAME='yes' for all of the enabled or configured interfaces and this value has precedence over the global one.

So the main problem was that YaST only allowed us to modify the global variable and setting it to ‘no’ did nothing because it was enabled for some interface.

During this sprint we have fixed that and now the user interface offers the possibility of choosing which DHCP interface will be used to decide the hostname.

Apart from choosing one of the existing interfaces, the new setting can also be set to ‘no’ or to ‘any’. In any case, YaST will always configure the system-wide options and the interface specific ones in a consistent way, so the behavior is always predictable.

But YaST is not the only way of configuring the network, so it’s always possible to have an unpredictable configuration. Fortunately, those potentially problematic scenarios will be detected by YaST and reported to the user.

Partitioning in CASP

In the previous report we already explained how are we improving the installer to support the definition of the ultra-streamlined installation process of SUSE CASP, the new Kubernetes based member of the SUSE family.

In this sprint we introduced several additional changes to enable a different partitioning approach, more guided and automatic than ever. In a CASP node it makes no sense to use the advanced settings offered by our storage proposal, like encryption or LVM. Moreover, CASP relies on Btrfs to provide some of its cool and advanced features, like transactional updates.

As a result, although the regular SUSE and openSUSE releases will keep offering all the current possibilities in the same way than ever, in CASP the partitioning step will be skipped and the automatically calculated proposal will be simply displayed in the installation summary.

Clicking on the proposal will allow to re-target the installation to a different disk (or disks) in a similar way than the regular installer, but the options will be more limited. Again, no easy way to use LVM, encryption, separate home or any file system type other than Btrfs.

The expert partitioner is still available during CASP installation, but using it will show an extra warning, since it implies a much bigger risk than using it in a regular SUSE or openSUSE system.

Improved debugger integration

We have improved the Ruby debugger integration in YaST. So far you could start the debugger using the y2debugger=1 boot option or by setting the Y2DEBUGGER=1 environment variable. The new feature allows starting the Ruby debugger also later when the YaST module is already running.

Simply press the Shift+Ctrl+Alt+D keyboard shortcut (D as debug) and it will start the Ruby debugger. It works during installation and also in installed system (just make sure the byebug Ruby gem is installed).

Unfortunately this new feature works only in the Qt UI, the ncurses UI is not supported (currently it does not handle the debugging keyboard shortcut at all).

After pressing the keyboard shortcut the debugger window will pop up:

Storage reimplementation: it’s alive!

It took us one more sprint than originally expected, but finally we can say the testing ISO for the new storage stack is fully installable.

We fixed the UEFI + MBR partition table scenario we already had almost working in the previous sprint (turns out it was not that broken in Tumbleweed after all) and we adapted yast2-bootloader to be also able to deal with legacy (i.e. no UEFI) booting using the new storage stack.

As a nice result, our testing ISO can be used to install a perfectly functional system in both UEFI or legacy systems with the only requirement of having a pre-existing MBR partition table in the disk. It only shows a couple of error pop-ups related to the calculation of the proposal of software to be installed, but nothing that would prevent you from replacing whatever operating system you have with a new shiny openSUSE-based experiment.

This milestone opens the door to start testing the new stack with openQA, the same system that helps to guarantee the robustness of all the recent SUSE and openSUSE versions.

Storage reimplementation: preparations for the storage proposal

Now that yast2-bootloader starts to be ready to work with the new storage stack in more and more scenarios, it’s time to adapt the only component that still complains during the installation.

In order to make that task doable during the next sprint, we invested some time in this sprint analyzing the interaction between the software proposal calculator and the old storage layer. The outcome was a small document detailing what needs to be adapted in the proposal and in the new stack. The perfect input for a task in the next sprint.

Help for power-users with short memory

Our beloved YaST is packed with magic tricks below the surface. Many of them are very useful to debug installation problems or to better understand how the YaST internals work. Unfortunately developers tend to not be that good at blindly memorizing stuff and the functionality is so well hidden that most newcomers would have hard times finding it… until now.

We have added a couple of new keyboard shortcuts to show a summary of all the advanced hotkeys, so now you only have to remember one key combination instead of a dozen of them. In both text (ncurses) and graphical (Qt) mode, it will be enough to press shift+F1 to get the advanced help displayed below. Since some terminal emulators could already use that combination, ctrl+D F1 can also be used in the ncurses interface as an alternative.

Contributions keep coming!

As we have already mentioned in previous sprint reports, an important part of our daily job as open source developers is helping casual (and not so casual) contributors to bring their ideas and code into YaST and related projects.

This time that (hopefully not casual) contributor was Devin Waas, who wanted to improve the installation to make the life of cloud-lovers easier.

For cloud guys out there retrieving logs of a failed installation is was a huge problem. Now, thanks to Devin, all you need is a running a rsyslog server and you’ll be able to easily access your installation logs from there.

As a matter of fact, the newest Tumbleweed release allows us to specify the IP address of a remote server from the bootloader through the “Loghost flag”. Linuxrc will take care of setting up a UDP broadcast for dmesg contents and YaST installation logs.

This is just a first step. Devin promised further improvements of our newly implemented remote logging system. And he codes better than he draws, so stay tuned!

Storage reimplementation: LVM-based proposal

As we already mentioned in previous reports, when we started to develop the partitioning proposal we first focused in the scenario of a partition-based proposal with one or several MBR-style partition tables. That looked like the most complex scenario due to the limited number of primary partitions, the alignment problems, the overhead introduced by the EBR (extended boot record) of every logical partition and so on.

A couple of sprints ago, we got that working so we started to work on the LVM-based proposal. It took a little bit longer than expected but now we are able to generate LVM-based proposals for almost every possible scenario. The goal was to have them working in our mocked test cases. So probably the new LVM-based proposal cannot still be used to install a fully functional system, but it is backed by a full load of tests that prove we can handle many situations, from trivial to really tricky ones… and believe us, things can get quite tricky if you mix logical partitions with their EBR overhead and LVM volumes with their PE size rounding and their metadata overhead.

Bugs, bugs, bugs

In this sprint we kept the already commented approach of making the fix of low-priority and small bugs part of the Scrum process. As a result we accounted for approximately 50 deaths of those annoying creatures.

Conclusion

Looking at the report, we could say it was a quite successful sprint. But to be honest we were aiming even higher. Quite some interesting PBIs (features or bug-fixes in Scrum jargon) were almost done at the end of the sprint. But following Scrum philosophy, we never blog about almost-done stuff.

Thus, if nothing goes wrong things will be even better in the next report in three weeks. So have a lot of fun trying the new stuff and stay tuned for more!

As with previous releases we have bundled a ton of softwares on this live DVD/USB specially packaged for education, along with the Plasma, GNOME and Mate Desktop Environments, full multimedia experience is also provided out of the box thanks to the Packman repositories. Only x86_64 architecture is supported, if you have a lot of machines that only support x86 then read on to find out how you can extend their Li-f-e.

You can of course very easily turn Li-f-e to full-fledged LTSP server to PXE boot machines in your local network. Booting both i686 and x86_64 architectures is supported. In case you need to PXE boot machines below i686 then you would have to install this package.

Happy holidays!

Get Li-f-e from here: Direct Download | md5sum | Alternate download and mirrors

What ping does

Ping consumes ICMP-protocol which is very low level and I don’t know is it used for anything anymore these days (correct me if I’m very wrong) only with ping-command. If Wikipedia is correct ping calculates round-trip so how long takes data to find it’s way to server and come back (Small tip here! You can use traceroute to see how you packet is finding it’s way on the Internet and back to you).
So how can I use ping to tell me is my server up? Short answer is simple: ‘you can’t’. Little bit longer answer: ‘Yes you can but it’s little bit more complicated than you first thought’ and the long version: ‘You get information about if your server’s network card answers to (and most of the time kernel network stack) received ICMP-packet. If there is firewall rule that turns ICMP-packet answer off you are out of luck. Ping doesn’t tell if your service is up or Apache running correctly and reliable. Remember ping answer can work even if most of user space is smashed down and kernel is malfunctioning (been there done that!)’.
So what you get it answer from network card and that’s it. If it’s enough (99% times it is) keep reading.

Script

Show me code you scream and I give it to you and please read comments on code before using. This is edited version from Stackoverflow.com message script (so nothing original here):

#!/bin/bash

echo "Press [CTRL+C] to stop.."

# Make at least 10 pings in one time
COUNT=50
SUCCESS=0
LASTFAIL=NONE
# Change this to Domain name/IP
# or ip you want to monitor
IP=192.168.1.1
FAILS=0

while true
do
        #
        # Ping with interval 0.5s to IP (192.168.1.1)
        # COUNT (50) times
        # after that we just grep 'byte from' from output
        # or ping and them calculate how many we got
        # with wc -l (Lines of output) bacause we drop
        # other from output
        # You can use up (normally) 2000 size (-s) of package
        # to see if it's starts to drop..
        LINES=$(ping -s 1024 -i 0.5 -c ${COUNT} ${IP} | \
                grep "bytes from ${SERVERSERVER}" | wc -l)

        # Calculate how many fails there were
        let FAILS=${COUNT}-${LINES}+${FAILS}
        # Add to success rate
        let SUCCESS=${LINES}+${SUCCESS}

        # If there were error but date to LASTFAIL
        # so if you not every moment looking you can
        # see when this error happened
        if [ ${LINES} -ne ${COUNT} ]; then
             LASTFAIL=$(date)
        fi

        # Ok ping all together failed
        if [ $? -ne 0 ] ; then
          echo "Can't Connect to server ${IP}"
        else
          # Print statistics to screen
          echo "$(date) ${IP} Success: ${LINES} (Tot. F ${FAILS}) \
(Tot. S ${SUCCESS}) (Last F ${LASTFAIL})"
        fi

        # Sleep a while (not consume all the bandwidth)
        sleep 1
done

Output

Script prints mystical output. Things that matters that Success rate is 50 (or what pinging rate you are using) and Fails are not rising fast. It they are rising fast packets are dropped if you are not getting anything check IP/domain name. With this one you can get ping time. If success level is 50 but ping time is high you network is still very slow but that you have to check with ping-command by hand. Even with 2G mobile modem you should get under 300ms (3G should be like 100ms).
To have any clue about your connection you have make this at least 30 minutes (First ping packets can tell everything but if you want to see whole picture). Actually this is stupid way to find out is your server up but if your WIFI-card is working everywhere else great you can check are you packets going through. If ICMP-packets are dropping very fast then your TCP/IP packages are dropping very fast and you network stack have to re-send them so you notice that your network is slow (even though it has nothing to do with that). Again it can be route, WIFI-card or firewall problem still.. and ping doesn’t answer to that question. So this was this days script stuff. If you have better ways to do this.. please share I’m always interested in this topic.

* Install Li-f-e on a server from which other machines will PXE boot, make sure you have plenty of space assigned to / partition(about 20G)
* Set up LTSP by following this quick start guide
* Create /srv/nfs folder and copy Li-f-e iso there
* Run the following as root in terminal:

mount /srv/nfs/openSUSE-Edu-li-f-e.x86_64-42.1.1.iso /mnt
cp /mnt/boot/x86_64/loader/linux /srv/tftpboot/boot/linux-life64
cp /mnt/boot/x86_64/loader/initrd /srv/tftpboot/boot/initrd-life64
echo "/srv/nfs *(ro,no_root_squash,async,no_subtree_check)" >> /etc/exports
cat <<EOF>> /srv/tftpboot/pxelinux.cfg/default
LABEL Li-f-e
kernel boot/linux-life64
append initrd=boot/initrd-life64 isofrom_device=nfs:10.0.0.254:/srv/nfs/ isofrom_system=/openSUSE-Edu-li-f-e.x86_64-42.1.1.iso
IPAPPEND 2
EOF
chkconfig rpcbind on && service rpcbind restart
chkconfig nfsserver on && service nfsserver restart

Now you can PXE boot any machine over the network, select Li-f-e from the end of the boot menu to boot live DVD iso instead of normal LTSP session.

Use “yast2 live-installer” to install Li-f-e on the client machine.

One can only thank everyone in the community for pulling together, getting a lot of stuff done and delivering a great release.

Yet, there’s one sprinkle that rains on our parade. While we completed the switch to systemd we somewhere along the lines forgot to check the status of NetworkManager on an installed system. Thus, when you upgrade from a previous release and NetworkManager is disabled, it will be enabled and running after the upgrade is complete, sorry. If you happen to be running a network bridge your bridge will not be working and you’ll end up in some weird network state where ifconfig will tell you that both your bridge and your Ethernet card have an IP address. Your routing table will also be messed up. Addressing the issue is easy.

Login as root, which you will have to do at the login manager if you happen to run NIS, disable NetworkManager, stop the NetworkManager service, and restart your network. You are now back to your original configuration, no sweat . Below is a list of commands you want to run as the root user to make this happen:

# systemctl –force disable NetworkManager.service

# systemctl stop NetworkManager.service

# rcnetwork restart

“x2go is an open (GPL/AGPL) source “server based computing” project. Combining the advantages of existing systems it features ease of use, performance and scalability. x2go provides you with access to your desktop – from within your own network and via the internet. x2go is not limited to particular hardware, it supports a variety of devices and architectures.” -from their website.

Some of the features/benefits of x2go that are not available on LTSP are:

* Remote login from within local lan and internet from any OS
* Session persistence, you can disconnect session from one client and continue where you left off from any other client
* Low bandwidth usage
* Session sharing with other users

Apart from these, x2go also supports sound redirection via pulseaudio, folder sharing for access to local disks similar to LTSP.

I would personally still prefer LTSP session in local network, and as x2goserver and LTSP server can coexist on same server we can choose x2goclient to connect over the internet and log in using LTSP in local lan.

Here is how to run x2go as kiosk session by PXE booting a thin-client/PC/laptop.

* Install kiwi-ltsp-profile-x2go on openSUSE Edu Li-f-e or 12.2 via 1-click from here.
* Run kiwi-ltsp -ln openSUSE_12_2_x2go as root to create KIWI-LTSP image that is used for PXE booting clients, (this step requires fast internet connection and about 250M download)
* Run kiwi-ltsp -c to configure required services
* Add the following to /srv/tftpboot/KIWI/root.default/etc/lts.conf under [default] for all clients or under [MA:CA:DD:RE:SS] for a particular client and boot up the client, openSUSE_12_2_x2go will be available at the end of boot menu.

SCREEN_07=kiosk
KIOSK_EXE="/usr/bin/x2goclient --no-menu --maximize --link=lan --geometry=fullscreen --thinclient --haltbt --no-session-edit --add-to-known-hosts"
KIOSKUSER=x2goclient


You can also have normal LTSP session on tty8 along with this by adding SCREEN_08=ldm. To connect to the server from non-thin-client install and run x2goclient.

You can simply poweroff the client without the need to disconnect or do normal shutdown.

Note: this method of using x2go is just for testing and development purpose, you can use x2goserver and x2goclient in a standalone mode without kiwi-ltsp bits. Nothing additional than installing x2goserver package is needed to setup the server, except firewall should allow access to ssh port(22).

But you don’t have to anymore. Because modern web servers support delivering only parts of a file (using the “Range” header field), that allowed me to implement curlwwwfs that mounts remote HTTP directories into your local filesystem. And then you can use fuseiso on top to access the actual content within the .iso. All without root access.

This is how it works:

First you have to install the required packages (replace 12.2 with your version of openSUSE (or if you use a different Linux distribution, do git clone git://github.com/bmwiedemann/curlwwwfs and “make install” in there)):

zypper ar http://download.opensuse.org/repositories/home:/bmwiedemann/openSUSE_12.2/home:bmwiedemann.repo

zypper in curlwwwfs fuseiso

# Then you start it:

mkdir mnthttp mntiso

curlwwwfs http://zq1.de/bootcd mnthttp &

ls -la mnthttp/

fuseiso mnthttp/bmwinux-8.2-040808.iso mntiso

cat mntiso/isolinux/isolinux.cfg

# and later you clean it up with

fusermount -u mntiso

fusermount -u mnthttp