The summer is almost gone but, looking back, it has been pretty productive from the YaST perspective. We have fixed a lot of bugs, introduced quite interesting features to the storage layer and the network module refactoring continues to progress (more or less) as planned.

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. :smiley:

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. :wink:

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. :smile: 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.

Not too much noise has been made about it, but fairly recently SailfishOS for Sony Xperia XA2, XA2 Ultra and XA2 Plus (finally) came out of beta stage after the initial release last autumn. I went and got myself an XA2 Plus and have been using it for a week now and am very pleased with it. Compared to former SailfishOS devices the Android runtime for the XA2 models is at version 8.x (compared to 4.x for previous devices), meaning a lot more Android apps will run on it.

So if you’re looking for a proper GNU/Linux phone and/or an alternative to the Google/Apple duopoly now is your chance to run SailfishOS on very decent and affordable midrange hardware. Below is a video of the XA2 Plus running SailfishOS (not mine).

you can buy the image here (EUR 49,90) and installation instructions are here.

I unlocked and flashed the device on openSUSE Leap 15.0 using the android-tools package from this home repo https://download.opensuse.org/repositories/home:/embar-:/Lietukas/openSUSE_Leap_15.0/

What is SailfishOS?

SailfishOS is a proper GNU/Linux OS for mobile devices based in Finland. It’s the successor of Nokia’s MeeGo so to speak. It has a cool, smooth and efficient swipe based interface. Behind the scenes it’s using Qt, Wayland, RPM, BlueZ, Systemd, Pulseaudio etc. as well as openSUSE technologies libzypp and Open Build Service.

Intro

If you think, this is too much text and sounds far too complicated or you are not interested in background informations: install openSUSE Kubic and go directly to the “Deploy Kubernetes” Section. There is not really an easier way to deploy Kubernetes!

Why should I want to use kubic-control?

We have kubeadm on openSUSE Kubic to manage kubernetes, why do we need yet another management tool? There is a nice blog giving an answer to this: Automated High Availability in kubeadm v1.15: Batteries Included But Swappable, which explains, beside kubernetes multi master, also the scope of kubeadm very well: “kubeadm is focused on performing the actions necessary to get a minimum viable, secure cluster up and running in a user-friendly way. kubeadm’s scope is limited to the local machine’s filesystem and the Kubernetes API, and it is intended to be a composable building block for higher-level tools.”

The following tasks are out of scope for kubeadm:

• Infrastructure provisioning
• Third-party networking
• Non-critical add-ons, e.g. monitoring, logging and visualitzation
• Specific cloud provider integrations

kubic-control is such a higher-level toolkit. It configures the Host OS (in the feature, it will even be able to install new baremetal nodes with help of yomi), setups all necessary services, uses kubeadm to deploy kubernetes and installs and configures all necessary add-ons, like pod network and update and reboot services for the OS and the cluster. It will also help you to avoid mistakes like not calling kubeadm with the right arguments if you want to use flannel for the network.

What is kubic-control?

kubic-control consists of three binaries:

• kubicd, a daemon which communicates via gRPC with clients. It’s setting up kubernetes on openSUSE Kubic, including pod network, kured, transactional-update, …
• kubicctl, a cli interface
• haproxycfg, a cli interface adjust haproxy.cfg for use as loadbalancer for the kubernetes API

The communication is encrypted, the kubicctl command can run on any machine. The user authenticates with his certificate, using RBAC to determine if the user is allowed to call this function. kubiccd will use kubeadm and kubectl to deploy and manage the cluster. So the admin can at everytime modify the cluster with this commands, too, there is no hidden state-database except for the informations necessary for a kubernetes multi-master/HA setup.

Requirementes

Mainly generic requirements by kubernetes itself:

• All the nodes on the cluster must be on a the same network and be able to communicate directly with each other.
• All nodes in the cluster must be assigned static IP addresses. Using dynamically assigned IPs will break cluster functionality if the IP address changes.
• The Kubernetes master node(s) must have valid Fully-Qualified Domain Names (FQDNs), which can be resolved both by all other nodes and from other networks which need to access the cluster.
• Since Kubernetes mainly works with certificates and tokens, the time on all Nodes needs to be always in sync. Else communication inside the cluster will break.

As salt is used for the communication, the Admin Node needs to run a salt-master and all other nodes needs to be configured as salt-minion.

Installation

Currently, the easiest way to get a running kubernetes cluster on openSUSE Kubic is to take the DVD and install the nodes with YaST. There are three relevant system roles to choose from:

• Kubic Admin Node
• Additional Kubic Node
• Kubic Loadbalancer Node

Kubic Admin Node

The Kubic Admin Node is running kubicd, the salt-master and the first kubernetes master node. The overhead for kubicd and the salt-master is very low, so you don’t need a bigger machine because of this. During the first boot, some certificates are created for kubicd in /etc/kubicd/pki:

• Kubic-Control-CA.key - the private CA key
• Kubic-Control-CA.crt - the public CA key. This one is needed by kubicctl, too
• KubicD.key - the private key for kubicd
• kubicD.crt - the signed public key for kubicd
• admin.key - private key, allows kubicctl to connect to kubicd as admin
• admin.crt - public key, allows kubicctl to connect to kubcd as admin

For kubicctl, you need to create a directory ~/.config/kubicctl which contains Kubic-Control-CA.crt, user.key and user.crt. For the admin role, this need to be a copy of admin.key and admin.crt. For other users, you need to create corresponding certificates and sign them with Kubic-Control-CA.crt. If you call kubicctl as root and there is no user.crt in ~/.config/kubicctl, the admin certificates from /etc/kubicd/pki are used if they exist. Certificates for additional users can be created with _kubicctl certificates create _.

Please take care of this certificates and store them secure, this are the passwords to access kubicd!

Additional Kubic Node

Additional Kubic Nodes will become either additional master nodes for HA of the kubernetes API, or worker nodes. The procedure is in both cases the same:

• Install the Additional Kubic Node system role. At some point during the workflow, you need to enter the hostname or IP address of the Kubic Admin Node for the salt-minion.
• Accept the salt-minion on the Kubic Admin Node with salt-key -A

Kubic Loadbalancer Node

The Kubic Loadbalancer Node system role installs a MicroOS without container runtime but haproxy instead. During installation, you need to provide the hostname or IP address of the Kubic Admin Node for the salt minion. Accept the salt-minion on the Kubic Admin Node with salt-key -A

Afterwards, the haproxy needs to configured and enabled. In one of the next versions, kubic-control should be able to do this itself.

Deploy Kubernetes

Normally, after you did install the Kubic Admin Node and the needed numbers of Additional Kubic Nodes, deploying kubernetes is quite simple. Login to the Kubic Admin Node, accept the Keys of the salt-minions and run the following command to deploy the contral-plane on the master with weave net as POD network and kured to manage the reboot of nodes during an upgrade:

kubicctl init

Now we only need the worker nodes, who will run our workload. The Node names are always the minion ID, which is normally the FQHN of that node:

kubicctl node add node1,node2,...

That’s all. Two commands to setup your cluster! Run now kubectl get nodes to see your cluster!

Multi-Master Kubernetes

Setting up a control-plane with three master nodes (kubic-control currently allows any number of control-plane nodes, but this should be at minimum three and an uneven number of nodes!) is quite as simple.

At first, you need to setup a loadbalancer if you don’t have one in the network for the kubernetes API. That’s currently a manual process, but will also be handled by kubernetes-control in the near future.

Afterwards setup the initial master, where “load.balancer.dns” is the DNS name, under which the kubernetes API servers should be reacheable:

kubicctl init  --multi-master load.balancer.dns

Now add more master nodes:

kubicctl node add --type master master2,master3

And the worker Nodes:

kubicctl node add node1,node2,...

Now you have a running kubernetes cluster with 3 Master Nodes and several worker Nodes with only three commands! kubectl get nodes should show you the status of your Nodes.

Next Steps

This is just the beginning of our journey to make kubic-control a tool to manage your whole openSUSE Kubic cluster. Many more things are planned or under active development:

• Re-configure a haproxy loadbalancer when adding or removing master nodes
• Install new nodes with yomi
• Certificate handling
• Extend support and handling of add-ons, including rolling updates
• Integration of ignition
• Create “ready-to-run” images for all kinds of virtualisation consisting of the three system roles: Kubic Admin Node, Additional Kubic Node and Kubic Loadbalancer Node.
• Add support to deploy container images from the devel:kubic:containers project

As with any new software, especially stuff we’re changing so quickly, there is a chance of bugs. If you try the steps in this guide and find any, please report them to our Bugzilla under the “Kubic” component.

Please Note: kubic-control on Kubic is under heavy active development. Many new functionality will come which may change current functionality.

Thanks, and have a lot of fun!

If you happen to be using gnu find in the deadly combination with a directory that is a symlink (you just don’t know that yet), you will find face the hard truth that running:

find /path/to/directory -type f

Will return zero, nada, nichts, meiyou, which is annoying.

this will make you question your life decisions, and your knowledge on tools that you use daily, only to find out that the directory is actually a symlink :).

So next time you find yourself using find and it returns nothing, but you are sure that your syntax is correct and get no errors, try adding the --fowllow or use the -L

` find -L /path/to/directory/with/symlink -type f`

This will do what you want :)

If your are into devops or someone who take care backend of NGINX, you will notice there is limit of tools to read / transform NGINX access or error log files into colorize which is helpful and readable, compare to Httpd / Apache which have tonnes of script and tools to colorize your logs.

The last time I configuring NGINX was 4 years ago and yesterday I setup webserver for my client using NGINX instead of Httpd / Apache, after 7 minutes port 80 was open to public, I notice slowness on my client VPS machine, so I assume maybe some massive bots are scanning this webserver for some reason.

I open NGINX log with my favourite less- R command line and I feel awful and ackward. Do you know why? Because I been involve with lot of programming framework and tool that offer me ANSI colorize log.

If you are just like me, then I suggest you to install ccze! Here some currrent info from Fedora repository

[rnm@robbinespu ~] $ sudo dnf info ccze
Last metadata expiration check: 0:00:13 ago on Thu 22 Aug 2019 11:55:41 AM +08.
Available Packages
Name         : ccze
Version      : 0.2.1
Release      : 22.fc30
Architecture : x86_64
Size         : 81 k
Source       : ccze-0.2.1-22.fc30.src.rpm
Repository   : fedora
Summary      : A robust log colorizer
URL          : http://bonehunter.rulez.org/CCZE.html
License      : GPLv2+
Description  : CCZE is a roboust and modular log colorizer, with plugins for apm,
             : exim, fetchmail, httpd, postfix, procmail, squid, syslog, ulogd,
             : vsftpd, xferlog and more.

Like it said, this is a robust and modular log colorizer and comes with few plugins. It available on Fedora, Debian, Ubuntu, Centos, Opensuse and others distro repository.

Just install it:

$ sudo dnf install ccze #for Red Hat/CentOS/Fedora based
$ sudo apt install ccze #for Debian/Ubuntu based

and to use it, you need to open your file reader and pipe into ccze. For example:

$ sudo less -R /var/log/nginx/access.log | ccze -A | less -R 

You may check helps for more option how to manipulate and using ccze

$ ccze --help
Usage: ccze [OPTION...]
ccze -- cheer up 'yer logs.

  -a, --argument=PLUGIN=ARGS...   Add ARGUMENTS to PLUGIN
  -A, --raw-ansi             Generate raw ANSI output
  -c, --color=KEY=COLOR,...  Set the color of KEY to COLOR
  -C, --convert-date         Convert UNIX timestamps to readable format
  -F, --rcfile=FILE          Read configuration from FILE
  -h, --html                 Generate HTML output
  -l, --list-plugins         List available plugins
  -m, --mode=MODE            Change the output mode
                             (Available modes are curses, ansi and html.)
  -o, --options=OPTIONS...   Toggle some options
                             (such as scroll, wordcolor and lookups,
                             transparent, or cssfile)
  -p, --plugin=PLUGIN        Load PLUGIN
  -r, --remove-facility      remove syslog-ng's facility from start of the
                             lines
  -?, --help                 Give this help list
      --usage                Give a short usage message
  -V, --version              Print program version

Mandatory or optional arguments to long options are also mandatory or optional
for any corresponding short options.

Report bugs to <algernon@bonehunter.rulez.org>.

Cheers and have fun!

Dear Community,

After six years on the openSUSE Board and five as its Chairperson, I have decided to step down as Chair of the openSUSE Board effective today, August 19.

This has been a very difficult decision for me to make, with reasons that are diverse, interlinked, and personal. Some of the key factors that led me to make this step include the time required to do the job properly, and the length of time I’ve served. Five years is more than twice as long as any of my predecessors. The time required to do the role properly has increased and I now find it impossible to balance the demands of the role with the requirements of my primary role as a developer in SUSE, and with what I wish to achieve outside of work and community. As difficult as it is to step back from something I’ve enjoyed doing for so long, I am looking forward to achieving a better balance between work, community, and life in general.

Serving as member and chair of the openSUSE Board has been an absolute pleasure and highly rewarding. Meeting and communicating with members of the project as well as championing the cause of openSUSE has been a joyous part of my life that I know I will miss going forward.

openSUSE won’t get rid of me entirely. While I do intend to step back from any governance topics, I will still be working at SUSE in the Future Technology Team. Following SUSE’s Open Source policy, we do a lot in openSUSE. I am especially looking forward to being able to focus on Kubic & MicroOS much more than I have been lately.

As I’m sure it’s likely to be a question, I wish to make it crystal clear that my decision has nothing to do with the Board’s ongoing efforts to form an independent openSUSE Foundation.

The Board’s decision to form a Foundation had my complete backing as Chairperson, and will continue to have as a regular openSUSE contributor. I have absolute confidence in the openSUSE Board; Indeed, I don’t think I would be able to make this decision at this time if I wasn’t certain that I was leaving openSUSE in good hands.

On that note, SUSE has appointed Gerald Pfeifer as my replacement as Chair. Gerald is SUSE’s EMEA-based CTO, with a long history as a Tumbleweed user, an active openSUSE Member, and upstream contributor/maintainer in projects like GCC and Wine.

Gerald has been a regular source of advice & support during my tenure as Chairperson. In particular, I will always remember my first visit to FOSDEM as openSUSE Chair. Turning up more smartly dressed than usual, I was surprised to find Gerald, a senior Director at SUSE, diving in to help at the incredibly busy openSUSE booth, and doing so dressed in quite possibly the oldest and most well-loved openSUSE T-shirt I’ve ever seen. When booth visitors came with questions about SUSE-specific stuff, I think he took some glee in being able to point them in my direction while teasingly saying “Richard is the corporate guy here, I’m just representing the community..”

Knowing full well he will continue being so community minded, while finally giving me the opportunity to tease him in return, it is with a similar glee I now hand over the reigns to Gerald.

As much as I’m going to miss things about being chairperson of this awesome community, I’m confident and excited to see how openSUSE evolves from here.

Keep having a lot of fun,

Richard

Note: This announcement has been cross-posted in several places, but please send any replies and discussion to the opensuse-project@opensuse.org Mailinglist. Thanks!