rootco.de

Building a openSUSE MicroOS RPi Network Monitor

Wed, 09 Dec 2020 12:42:55 +0100

How to use combustion to reproducibly configure MicroOS -

openSUSE MicroOS is one of openSUSE’s most exciting projects, and for me has replaced openSUSE Leap as my go-to server operating system of choice. I currently have 3 MicroOS installations, all running as podman with openSUSE containers. The machines are as follows:

A nice fanless Zotac x86-64 NUC running at home as my Nextcloud and ssh-based backup server/NAS
A VM on Hetzner Cloud running this blog, my saltstack master and a few other public facing services. (Kudos to Hetzner for adding the openSUSE MicroOS ISO to the list of Cloud ISOs so I could do a custom installation)
A VM on Linode for running a US-based proxy for some of my friends who otherwise might have too-high latency accessing services on the Hetzner host. (Kudos to Linode for consistantly supporting openSUSE Leap releases on the day of release and providing ways of doing custom installs of any OS)

And so, with all these MicroOS boxes in my life, as reliable as they may be, I wanted to have a simple way of keeping an eye on whether or not the machines are up or not, possibly evolving to more interesting checks in the future. I wanted this to be able to monitor my machines even when my main laptop at home is off, and I wanted to not have to worry about updating the monitoring system at all. So an idea formed, why not use MicroOS to monitor MicroOS?

Hardware Used

I cobbled this little project together out of random bits of hardware I had lying around, namely:

Raspberry Pi 3B+ with the official RPi case
Joy IT 3.2” TFT display with 3 GPIO buttons
32GB micro SDCard
8GB random old USB stick

Software Used

I found a very nice command-line visualisation tool called sampler that perfectly fit my needs for this project. It’s nice and small, lets you draw graphs based on numbers it gets from whatever shell commands you run at whatever frequency you tell it to poll. It can also produce alerts if the results do not match expected values. So given the basic monitoring I want is basically just a ping and be alerted if they stopped responding, sampler is absolutely perfect. I packaged it for openSUSE as part of this project so it’s now available for regular Tumbleweed as well as MicroOS.

Installing MicroOS on the SDCard

First I needed to download the latest official openSUSE MicroOS aarch64 image for Rasbperry Pi from the official download page. For this project we’re using a plain old MicroOS image without any pre-installed services, not the Container Host images which come with podman.

wget https://download.opensuse.org/ports/aarch64/tumbleweed/appliances/openSUSE-MicroOS.aarch64-RaspberryPi.raw.xz

Putting in the SDCard into the reader, I simultaniously extracted the image and wrote it direct to the image with the following command. (Substitue sdX with the correct name for your SDCard device)

xzcat openSUSE-MicroOS.aarch64-RaspberryPi.raw.xz | dd bs=4M of=/dev/sdX iflag=fullblock oflag=direct status=progress; sync

And that’s it, the SDCard is ready to go…or is it?

But Wait!

By default, MicroOS images have no root password, no user accounts, and no services installed. I needed to have some way to setup the Pi when it first boots from the SDCard. MicroOS has two tools available for such first boot configuration:

Ignition, originally from CoreOS which has a lovely structured JSON config but a limited scope of what it can setup.
Combustion, written specifically for MicroOS and capable of doing anything you can write in a shell script.

As I already had a feeling I’d need to do some quirky things, especially to get the TFT display running, I opted to use combustion. I could have used ignition for the easy stuff and left combustion in combination for the trickier parts but it seemed silly to me to have to learn how to write a new JSON config file when I could just as easily write everything in a shell script.

Preparing a combustion USB stick

On first boot combustion looks for a device with a volume named combustion containing a directory called combustion and a script called script so that’s precisely what I did to my USB stick

mkfs.ext4 /dev/sdY
e2label /dev/sdY combustion
mount /dev/sdY /mnt
mkdir -p /mnt/combustion/
touch /mnt/combustion/script

After a few trial runs and a bit of hacking around the final script now looks like this:

#!/bin/bash
# combustion: network

## Copy config and device tree overlays for Pi TFT & GPIO buttons to /boot/efi
cp extraconfig.txt /boot/efi/
cp joy-IT-Display-Driver-32b-overlay.dtbo /boot/efi/overlays/
cp tft_keys.dtbo /boot/efi/overlays/

## Change boot params so framebuffer console goes to TFT display
sed -i "/^GRUB_CMDLINE_LINUX_DEFAULT=/ s/\"$/ fbcon=map:10\"/" /etc/default/grub
grub2-mkconfig -o /boot/grub2/grub.cfg

## Mount /var and /home so user can be created smoothly
mount /var
mount /home

## Make user
useradd -m ilmehtar

## Add user to sudoers
echo "ilmehtar ALL=(ALL) NOPASSWD: ALL" > /etc/sudoers.d/ilmehtar

## Create ssh folder and populate authorized_keys for remote sshd
mkdir -pm700 /home/ilmehtar/.ssh
chown ilmehtar:users -R /home/ilmehtar/.ssh
cat authorized_keys > /home/ilmehtar/.ssh/authorized_keys

## Setup vconsole so framebuffer console has right font/keyboard layout (Optional)
cp vconsole.conf /etc/vconsole.conf

## Setup Wifi
cp wpa_supplicant.conf /etc/wpa_supplicant/wpa_supplicant.conf
systemctl enable wpa_supplicant@wlan0.service
cp /etc/sysconfig/network/ifcfg-eth0 /etc/sysconfig/network/ifcfg-wlan0

## Disable IPv6 (Optional)
cp 90-disableipv6.conf /etc/sysctl.d/

## Install sampler
zypper --non-interactive install sampler
cp sampler.yaml /home/ilmehtar/sampler.yaml

## Make user login by default
mkdir -p /etc/systemd/system/getty@tty1.service.d
cp autologin.conf /etc/systemd/system/getty@tty1.service.d

## Make sampler run by default
echo "[ \$TERM = 'linux' ] && sleep 30 && sampler -c ~/sampler.yaml" >> /home/ilmehtar/.bashrc

## Reboot after setup
cp firstbootreboot.service /etc/systemd/system/
systemctl enable firstbootreboot.service

## Clear up mounts
umount /var
umount /home

The script references a number of additional files, all of which are placed alongside script in the combustion directory on the USB stick:

File Listing of the combustion directory

90-disableipv6.conf
authorized_keys
autologin.conf
extraconfig.txt
firstbootreboot.service
joy-IT-Display-Driver-32b-overlay.dtbo
sampler.yaml
script
tft_keys.dtbo
tft_keys.dts
vconsole.conf
wpa_supplicant.conf

Joy-IT-Display-Driver-32b-overlay.dtbo is a Device Tree overlay provided by the manufactorer of the TFT hat. tft_keys.dtbo is my own Device Tree overlay compiled from tft_keys.dts. All the other files are text files used to configure various aspects of the system to my liking and are documented at the bottom of this post for anyone wanting to use this idea as a basis for their own projects.

First Boot

And with all that prep work done, the first boot is now surprisingly easy. I inserted the SDCard, added the USB stick and connected the Pi to ethernet (The wifi won’t work until it’s configured by combustion). Powering on the Pi the whole device can be left alone for a few minutes. It boots itself, does all of the configuration, and the end result is a nice working desktop network monitor:

The GPIO switches on the top even work as the P and ESC keys for sampler, allowing me to pause the polling or dismiss any alerts. A little bit of hardware hacking (read: hot glue and acryrlic) finished of the project with a little stand so the whole thing sits on my desk at an angle easy for me to read.

The system doesn’t have any passwords, so can’t be logged in remotely with the exception of ssh using the non-root user using my existing public key. Simple and secure enough.

All this might seem like a little overkill, I realise it probably is, but one great benefit of having everything in this one combustion script is now I know I can wipe that SDCard or use a new Pi and get it back up and running to exactly how I like it directly from the first boot, without any manual intervention at all. Which I guess means I could reuse this Pi for other projects..anyone got any ideas?

Thanks and Have a Lot of Fun

Additional Config Files Used (For Reference)

90-disableipv6.conf

net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1

autologin.conf

[Service]
ExecStart=
ExecStart=-/sbin/agetty -a ilmehtar %I $TERM

extraconfig.txt

dtoverlay=joy-IT-Display-Driver-32b-overlay:rotate=0,swapxy=1
dtoverlay=tft_keys
gpio=18,23,24=pu
dtparam=audio=on
max_usb_current=1
hdmi_force_hotplug=1
config_hdmi_boost=7
hdmi_drive=1
hdmi_ignore_edid=0xa5000080

firstbootreboot.service

[Unit]
Description=First Boot Reboot

[Service]
Type=oneshot
ExecStart=rm /etc/systemd/system/firstbootreboot.service
ExecStart=rm /etc/systemd/system/default.target.wants/firstbootreboot.service
ExecStart=systemctl reboot

[Install]
WantedBy=default.target

sampler.yaml

runcharts:
  - title: Status
    position: [[0, 2], [80, 40]]
    rate-ms: 1000
    triggers:
      - title: Node Down
        condition: '[ $cur = "DOWN" ] && echo 1 || echo 0'
        actions:
            visual: true
    legend:
        enabled: true
        details: false
    scale: 0
    items:
      - label: node1
        sample: ping -qc5 192.168.1.1 2>&1 | awk -F'/' 'END{ print (/^rtt/? $5:"DOWN")
            }'
      - label: node2
        sample: ping -qc5 192.168.1.2 2>&1 | awk -F'/' 'END{ print (/^rtt/? $5:"DOWN")
            }'
      - label: node3
        sample: ping -qc5 192.168.1.3 2>&1 | awk -F'/' 'END{ print (/^rtt/? $5:"DOWN")
            }'
      - label: node4
        sample: ping -qc5 192.168.1.4 2>&1 | awk -F'/' 'END{ print (/^rtt/? $5:"DOWN")
            }'
      - label: node5
        sample: ping -qc5 192.168.1.5 2>&1 | awk -F'/' 'END{ print (/^rtt/? $5:"DOWN")
            }'

tft_keys.dts

/dts-v1/;
/plugin/;
/ {
	compatible = "brcm,bcm2835";
	
	fragment@0 {
		target-path = "/soc";
		__overlay__ {
			tft_keys{
				compatible = "gpio-keys";
				autorepeat;
				key1 {
					label = "Key 1";
					linux,code = <1>;
					gpios = <&gpio 18 1>;
				};
                                key2 {
                                        label = "Key 2";
                                        linux,code = <25>;
                                        gpios = <&gpio 23 1>;
                                };
                                key3 {
                                        label = "Key 3";
                                        linux,code = <1>;
                                        gpios = <&gpio 24 1>;
                                };
			};
		};
	};
};

vconsole.conf (Because uk layout is best keyboard layout)

KEYMAP=uk
FONT=eurlatgr.psfu
FONT_MAP=
FONT_UNIMAP=

wpa_supplicant.conf

network={
   ssid="My-SSID"
   psk="MyPassword"
}

Regular Release Distributions Are Wrong

Mon, 10 Feb 2020 23:58:12 +0100

Why I No Longer Use openSUSE Leap -

For those who don’t already know, openSUSE is a Linux Distribution Project with two Linux distributions, Tumbleweed and Leap.

Tumbleweed is what is known as a Rolling Release, in that the distribution is constantly updating. Unlike Operating Systems with specific versions (e.g.. Windows 7, Windows 10, iOS 13, etc..) there is just ‘openSUSE Tumbleweed’ and anyone downloading it fresh or updating it today gets all the latest software.
Leap is what is known as a a Regular Release, in that it does have specific versions (e.g.. 15.0, 15.1, 15.2) released in a regular cadence. In Leap’s case, this is annually. Leap is a variation of the Regular Release known as an LTS Release because each of those ‘minor versions’ (X.1, .2, .3) are intended to include only minor changes, with a major new version (e.g.. 16.0) expected only every few years.

It’s a long documented fact that I am a big proponent of Rolling Releases and use them as my main operating system for Work & Play on my Desktops/Laptops.
However in the 4 years since writing that last blog post I always had a number of Leap machines in my life, mostly running as servers.

As of today, my last Leap machine is no more, and I do not foresee ever going back to Leap or any Linux distribution like it.

This post seeks to answer why I have fallen out of love with the Regular Release approach to developing & using Operating Systems and provide an introduction to how you too could rely on Rolling Releases (specifically Tumbleweed & MicroOS) for everything.

Disclaimer

First, a few disclaimers apply to this post. I fully realise that I am expressing a somewhat controversial point and am utterly expecting some people to disagree and be dismissive of my point of view. That’s fine, we’re all entitled to our opinions, this post is mine.

I am also distinctly aware that, my views expressed run counter to the business decisions of the customers of my employer, who do a very good job of selling a very commercially successful Enterprise Regular Release distribution.
The views expressed here are my own and not those of my employer.

And I have no problem that my employer is doing a very good job making a lot of money from customers who are currently making decisions I feel are ‘wrong’.
If my opinion is correct then I hope I can help my employer make even more money when customers start making decisions I feel are more ‘right’.

Regular & LTS Releases Mean Well

Regular & LTS Releases (hereafter referred to as just Regular Releases) have all of the best intentions. The Open Source world is made up of thousands if not millions of discreet Free Software & Open Source Projects, and Linux distributions exist to take all of that often chaotic, ever-evolving software and condensing it into a consumable format that is then put to very real work by its users. This might be something as ‘simple’ as a single Desktop or Server Computer, or something far larger and complex such as a SystemZ Mainframe or 100+ node Kubernetes Cluster.

The traditional mindset for distribution builders is that the regular release gives a nice, predictable, plan-able schedule in which the team can carefully select appropriate software from the various upstream projects.
This software can then be carefully curated, integrated, and maintained for several, sometimes many, years.
This maintenance often comes in the form of making minimal changes, seeking only to address specific security issues or customer requests, taking great care not to break systems currently in use.

This mindset is often appreciated by users, who also want from their computing a nice, predictable, reliable experience.. but they also want new stuff to keep up with their peers, either in communities or commercially.. and here begins the first problem.

All Change Is Dangerous, but Small Changes Can Be Worse

Firstly, whether the change is a security update or a new feature, that change is going to be made by humans. Humans are flawed, and no matter how great we all get with fancy release processes and automated testing, we will never avoid the fact that humans make mistakes.

Therefore, the nature of the change has to be looked at. “Is this change too risky?” is a common question, and quite often highly desired features take years to deliver in regular releases because the answer is “yes”.

When changes are made, they are made with the intention of minimising the risks introduced by changing the existing software. That often means avoiding updating software to an entirely new version but instead opting to backport the smallest necessary amounts of code and merging them with (often much) older versions already in the Regular Release. We call these patches, or updates, or maintenance updates, but we avoid referring them to what they really are … franken-software

No matter how skilled the engineers are doing it, no matter how great the processes & testing are around their backporting, fundamentally the result is a hybrid mixed together combination of old and new software which was never originally intended to work together.
In the process of trying to avoid risk, backports instead introduce entirely new vectors for bugs to appear.

Regular Releases Neglect The Strengths Of Open Source

Linus’s Law states “given enough eyeballs, all bugs are shallow.”
I believe this to be a fundamental truth and one of the strongest benefits of the Open Source development model. The more people involved in working on something, the more eyeballs looking at the code, the better that code is, not just in a ‘lack of bugs’ sense but also often in a ‘number of working features’ sense.

And yet the process of building Regular Releases actively avoids this benefit. The large swath of contributors in various upstream projects are familiar with codebases often months, if not years, ahead of the versions used in Regular Releases.
Even inside Community Distribution Projects, it is my experience that the vast majority of volunteer distribution developers are more enthused in targetting ‘the next release’ rather than backporting complex features into an old codebase months or years old.
This leaves a small handful of committed volunteers, and those employees of companies selling commercial regular releases. These limited resources are often siloed, with only time and resources to work on their specific distribution, with their backports and patches often hard to reuse by other communities.

With Regular Releases, there are not many eyes. Does that mean all bugs are deep?

I am not suggesting the people building these Releases do not do a good job, they most certainly do. But when you consider the best possible job all Regular Release maintainers possibly could do and compare it to the much broader masses of the entire open source ecosystem, how did we ever think this problem was light enough for such narrow shoulders?

A Different Perspective

I’ve increasingly come to the realisation that not only is change unavoidable in software, it’s desired. It not only happens in Rolling Releases, but it still happens in Regular Releases.
Instead of trying to avoid it why don’t we embrace it and deal with any problems that brings?

Increasingly I hear more and more users demanding “we want everything stable forever, and secure, but we want all the new features too”.

Security and Stability cannot be achieved by standing still.
New Features cannot be easily added if good engineering practice is discouraged in the name of appearing to be stable.
In software as complicated as a Linux distribution, quite often, the right way to make a change requires a significant amount of changes across the entire codebase.
Or in other words “in order to be able to change any ONE thing, you must be able to change EVERYTHING”.

Rolling Releases can already do that, and you can read my earlier blog post if you haven’t already for some reasons why Tumbleweed is the best at that.
But it’s not enough, otherwise I would have been running Tumbleweed on my servers 4 years ago.

I Am A Lazy Sysadmin

Before my life as a distribution developer I was a sysadmin, and like all sysadmins I am lazy. I want my servers to be as ‘zero-effort’ as possible.
Once they’re working I don’t want to have to patch them, reboot them, touch them, look at them, or ideally even think about them ever again. And this is a hard proposition if I am running my server on a regular Rolling Release like Tumbleweed.

Tumbleweed is made up of over 15,000 packages, all moving at the rate of contribution. Worse, Tumbleweed is designed as a multi-purpose operating system.
You can quite happily set it up to be a mail server, web server, proxy server, virtualisation host, and heck, why not even a desktop all at the same time.
This is one of Tumbleweed’s greatest strengths, but in this case it is also a weakness.
openSUSE has to make sure all these things could possibly work together. That often means installing more ‘recommended packages’ on a system than absolutely necessary, ‘just-in-case’ the user wants to use all the possible features their combination of packages could possibly allow.
And with this complexity comes an increase of risk, and an increase of updates, which themselves bring yet more risk. Perfectly fine for my desktop (for now), but that’s far too much work for a Server, especially when I typically need a Server to just do one job.

Minimal Risk, Maximum Benefits with openSUSE MicroOS

openSUSE MicroOS is the newest member of the openSUSE Family. From a code perspective, it is a derivative of openSUSE Tumbleweed, using exactly the same packages and integrated into its release process, but from a philosophical perspective, MicroOS is a totally different beast.

Whereas Tumbleweed & other traditional distributions are multi-purpose, MicroOS is designed from the ground up to be single-purpose. It’s a Linux distribution you deploy on a bit of hardware, a VM, a Cloud instance, and once it is there it is intended to do just one job.

The package selection is lean, with all you need to run on bare metal if you install from the ISO, or even smaller if you choose a VM Image for a platform where hardware support isn’t necessary. Fewer packages mean fewer reasons to update, helping lower the risks of change traditionally introduced by a rolling release. Recommended packages are disabled by default.
Being a transactional system, it has a read-only root filesystem, further cutting down the risk of changes to the system, ensuring that any unwanted change that does happen can be rolled back. Not only that, but such roll-backs can be automated with health-checker.
With rebootmgr, I can even schedule maintenance windows to ensure my updates only take effect during times I’m happy with.

Auto updating, auto rebooting, auto rolling back? I can be a lazy sysadmin even with a rolling release!

Just One Job Per Machine?

MicroOS is designed to do just one job, and this is fine for machines or VMs where all you would want to do is something like a self-maintaining webserver. That is as a simple as runningtransactional-update pkg in nginx.
But that can be rather limiting. Wouldn’t it be nice if there was some way of running services that minimised the introduction of risk to the base operating system, and could be updated independently of that base operating system?

Oh, right, that already exists, and they’re called containers.

MicroOS makes a perfect container host, so much so we deliver VM Images and a System Role on the ISO which already comes configured with podman.

Especially now openSUSE has a growing collection of official containers, a good number of services are a simple podman run podman pull registry.opensuse.org/opensuse/foo away.

In my case, I have moved all of my old Leap servers to now use MicroOS with Containers, this includes

NextCloud, using upstream containers [1][2][3][4]
Jekyll, using an upstream container [5]
Nginx, using the official openSUSE container [6]
A custom salt-master container [7]
A custom SSH container acting as both a jump-host and backup target for all my other machines [8]
and some other containers which I hope to make official openSUSE Containers once I’m happy they’ll work for everyone

All of the custom containers are built on openSUSE’s tiny busybox container which is just small and tiny and magical and I have no idea why anyone would use alpine.

All of my servers are now running MicroOS. The software is newer with all the latest features, but through a combination of containerisation and transactional-updates I find myself spending significantly less time maintaining my servers compared to Leap.

I can update the containers when I want, using container tags to pin the services to use specific versions until I decide when I want to update them.
I can easily add new containers to the to the MicroOS hosts just by adding another systemd service file running podman to /etc/systemd/system.
And I never need to worry about my base operating system which just takes care of itself, rebooting in the maintenance window I defined in rebootmgr.

I’m going to be writing further blog posts about my life with MicroOS and podman , but meanwhile I couldn’t be happier, and sincerely hope more people take this approach to running infrastructure.
Why? Well, we’re still only human, but when things do go wrong it’ll be even easier with more people looking at any problems :)

Now all I need to do is see if any of these benefits make sense for a desktop….

Changing of the Guard

Mon, 19 Aug 2019 10:00:00 +0200

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!

Creating openSUSE-style btrfs root partition & subvolumes

Fri, 19 Jan 2018 09:54:10 +0100

openSUSE’s YaST installer creates a detailed btrfs root filesystem configuration that has been designed to be flexible and secure while still efficient when used with tools like Snapper.

One of the overriding requirements is to provide a clearly defined ‘root filesystem’ containing everything we care about for ‘full system rollback’ (facilitated by snapper), while using subvolumes to exclude everything we do not want in the ‘root filesystem’ so snapper does not accidentally destroy user data when rolling back the system and its’ applications. Details of our default subvolume layout can be found on the openSUSE wiki.

However this does lead to complications for some advanced users who wish to recreate this manually, such as when doing complex system recovery, custom automated provisioning or other tinkering. (NOTE: for Full System Recovery it is often better to use a tool like ReaR).

The below steps are the steps to manually create an openSUSE-style btrfs partition believed to be correct at time of writing (19 Jan 2018).

This guide should be valid for openSUSE Tumbleweed 20180117, openSUSE Leap 15, and SUSE Linux Enterprise 15 or later. However care should be taken to double check for new or removed subvolumes in *SUSE distributions as this document gets older.

Older versions of SUSE distributions will need to adjust these instructions to handle the old /var/* subvolume layout previously used.

It should go without saying that this guide should only be followed by people who feel that they know what they are doing. It’s normally a lot easier to use openSUSE’s default tools like YaST and ReaR.

Step-by-Step

For this example we will use /dev/sda as our example disk and /dev/sda1 as our example partition for a btrfs root filesystem.

1: Create a partition table and the partition to be used as our root filesystem using your favourite tool (eg. yast, parted, fdisk)

2: Format /dev/sda1 with a btrfs filesystem

mkfs.btrfs /dev/sda1

3: Mount the new partition somewhere so we can work on it. We’ll use /mnt in this example.

mount /dev/sda1 /mnt

4: Create the default subvolume layout (this assumes an intel architecture, the /boot/grub2/* paths are different for different architectures)

btrfs subvolume create /mnt/@
btrfs subvolume create /mnt/@/.snapshots
mkdir /mnt/@/.snapshots/1
btrfs subvolume create /mnt/@/.snapshots/1/snapshot
mkdir -p /mnt/@/boot/grub2/
btrfs subvolume create /mnt/@/boot/grub2/i386-pc
btrfs subvolume create /mnt/@/boot/grub2/x86_64-efi
btrfs subvolume create /mnt/@/home
btrfs subvolume create /mnt/@/opt
btrfs subvoulme create /mnt/@/root
btrfs subvolume create /mnt/@/srv
btrfs subvolume create /mnt/@/tmp
mkdir /mnt/@/usr/
btrfs subvolume create /mnt/@/usr/local
btrfs subvolume create /mnt/@/var

5: Disable copy-on-write for var to improve performance of any databases and VM images within

chattr +C /mnt/@/var

6: Create /mnt/@/.snapshots/1/info.xml file for snapper’s configuration. Include the following content, replacing $DATE with the current system date/time.

<?xml version="1.0"?>
<snapshot>
  <type>single</type>
  <num>1</num>
  <date>$DATE</date>
  <description>first root filesystem</description>
</snapshot>

7: Set snapshot 1 as the default snapshot for your root file system, unmount it, and remount it.

btrfs subvolume set-default $(btrfs subvolume list /mnt | grep "@/.snapshots/1/snapshot" | grep -oP '(?<=ID )[0-9]+') /mnt
unmount /mnt
mount /dev/sda1 /mnt

8: You should be able to confirm the above worked by doing ls /mnt which should repond with an empty result.

Congratulations, at this point the filesystem is ‘created’ with the correct structure. But you need to know how to mount it properly to make use of it.

9: You now need to create a skeleton of the filesystem to mount all of our subvolumes

mkdir /mnt/.snapshots
mkdir -p /mnt/boot/grub2/i386-pc
mkdir -p /mnt/boot/grub2/x86_64-efi
mkdir /mnt/home
mkdir /mnt/opt
mkdir /mnt/root
mkdir /mnt/srv
mkdir /mnt/tmp
mkdir -p /mnt/usr/local
mkdir /mnt/var

10: Mount all of the subvolumes

mount /dev/sda1 /mnt/.snapshots -o subvol=@/.snapshots
mount /dev/sda1 /mnt/boot/grub2/i386-pc -o subvol=@/boot/grub2/i386-pc
mount /dev/sda1 /mnt/boot/grub2/x86_64-efi -o subvol=@/boot/grub2/x86_64-efi
mount /dev/sda1 /mnt/home -o subvol=@/home
mount /dev/sda1 /mnt/opt -o subvol=@/opt
mount /dev/sda1 /mnt/root -o subvol=@/root
mount /dev/sda1 /mnt/srv -o subvol=@/srv
mount /dev/sda1 /mnt/tmp -o subvol=@/tmp
mount /dev/sda1 /mnt/usr/local -o subvol=@/usr/local
mount /dev/sda1 /mnt/var -o subvol=@/var

11: You’re done, you’ve now successfully created an openSUSE-style btrfs root filesystem structure and mounted it for use. You can now use it for whatever you’d like, such as the manual injection of files from an existing openSUSE installation.

Once populated, care should be made to ensure the /mnt/etc/fstab also includes the appropriate entries for each of the subvolumes except @/.snapshots/1/snapshot which should not be mounted as it provides your initial installed system.

Have a lot of fun

Hackweek 0x10 Conclusion

Thu, 16 Nov 2017 17:36:10 +0100

The Birth of the Kubic Desktop -

Well it’s over, SUSE’s 16th hackweek. Here’s a quick post to sum up how my Hackweek went compared to my plans.

Small Bits and Pieces

I had a few small things on my list to look at. I didn’t get around to look at WeKan, but I understand other colleagues did and got it working on openSUSE. I plan to learn from them about whether or not the tool has much potential for my user cases.

I did get around to having fun with the large interactive whiteboard in SUSE’s Nürnberg office. Working with a bunch of colleagues we had a lot of fun, first booting it with SLE 15 Beta 2 but deciding that running an Enterprise operating system wasn’t really the best idea and replacing that with openSUSE Tumbleweed.

We found both Linux distributions booted a lot faster than Windows and had exceptionally good support for all of the involved hardware (including the touchscreen). However, just like Windows, it seems with this specific embedded system in the touch screen, we couldn’t get the embedded HDMI interface to set the resolution to 4K, despite the screen supporting 4K. Given this wouldn’t work in either Windows or *SUSE Linux after a day of hacking around we gave up and the screen is likely to be sent back to the manufacturer.

What about Kubic Desktop?

So my big idea was taking the container focused openSUSE Kubic and seeing if I could turn it into a GNOME powered Chromebook-like operating system, with user applications coming from Flatpak.

The short version is IT WORKS

It was an interesting journey. On the Kubic side of things I quickly abandoned the idea of building everything ‘clean’ in OBS first and instead just took the existing Tumbleweed Kubic Media and manually hacking the resulting installation into something that I wanted.

Our support for transactional updates got a very good workout, being used and abused to install well over 1606 packages from Tumbleweed onto the Kubic host to provide a fully fledged desktop install.

It surprised me how little I had to modify, with minor tweaks to the btrfs subvolume configuration required to get gdm working. I learned alot about PackageKit and gnome-software getting it configured just the way I wanted.

By the end, my resulting prototype VM was so promising I repeated the process on my GPD Pocket. I’m now running a Kubic Desktop installation, with automated operating system updates, and if an update ever did go wrong would have seamless rollback to the exact state of the system root filesystem.

It was really nice to prove that, even though the project as a whole is still in a very early stage, Tumbleweed Kubic is a powerful flexible platform for hacking on and getting used to this new, transactional way of looking at an operating system and it’s software management.

With a little more time and polish, I’m supremely confident we could build this into a ‘grandmother-friendly’ openSUSE desktop operating system, where the user wouldn’t even need to know that such a thing as a ‘root account’ existed, but they would still benefit from the fully tested rolling nature of openSUSE Tumbleweed.

A journey into Flatpaks

A fancy desktop operating system is nothing without apps. And as this idea aimed to have a system where it’s users shouldn’t need to worry about doing something as root, I needed a solution that provided apps that could be installed and run reliably in userspace.

As openSUSE does not (yet) have support for isolated snaps (due to Canonicals AppArmor patches still not fully available in the upstream Kernel), that left AppImage and Flatpak for consideration as a source of these applications.

As AppImage has a pretty terrible user experience story, without any kind of standard ‘AppStore’ interface, requiring users download executables from random websites, then to chmod a+x a file in the commandline before executing said file, that ruled them out as an option for this project; Though it was nice to see an AppImage running first time on the first Kubic Desktop prototypes.

But as originally planned, Flatpak seemed to have the answers to everything I needed. With solid gnome-software integration I knew I could build something that would offer users all of the applications in Flathub. Despite my previous concerns of these technologies I had high hopes.

“Everything is possible if you think in Opportunities”

The slogan attributed to the international purveyor of furniture in flat-packed form, Ikea, is really appropriate for Flatpak.

After a few days of playing with Flatpaks, I’m starting to see the opportunities and possibilities. It was really nice to be able to easily install Atom, Signal, and more with ease, when due to issues like licenses & crazy build environment requirements we haven’t (yet) been able to offer that software as part of openSUSE Tumbleweed.

But the ecosystem as a whole is flawed, possibly broken, and is in no way a software delivery system I can put any faith in at the moment. Flatpaks like Audacity would totally fail to start, claiming not to be able to read configuration files that were clearly present on the system. Other Flatpaks like Gydl complained about a lack of network, which was clearly a fault of that specific application when others were streaming YouTube just fine. And applications like libreoffice are clearly advertised on Flathub, just to not appear in gnome-software due to missing metadata.

With so many failures on a relatively small software selection, Flathub really, desperately, need to impose quality controls on their repository and stop shipping broken packages. And when they do, as they are right now, they need to have a way of actually reporting bugs against those packages. It’s nice their website has a guide on how to report Legal or Security issues, but that’s no good if users can’t get the apps to work in the first place.

As I played around with apps I got the feeling more and more that applications needed much tinkering and tuning to be able to fully support the Flatpak-way of doing things, and I think that is going to hold the Flatpak ecosystem back, unless tools like gnome-builder somehow become the predominant tooling for application development on Linux.

I was also dreadfully dissapointed with the performance, with applications taking significantly longer to load on my GPD Pocket compared to the same app provided by openSUSE Tumbleweeds rpms. On faster machines I didn’t notice, but it really put a dent in my idea of using Flatpaks for ‘netbook’ style usecases.

So I see the potential there, but at the moment I’m left feeling it will be unrealised potential.

With all that said, I’d like to extend a huge thank you to the folks in #flatpak IRC on Freenode. They were very friendly, a huge help, and I do believe they will work hard to address these problems I bumped into. Who knows, I may even help them out, they certainly are a nice enough bunch that I feel obligated to do so no matter what happens to the “Kubic Desktop”.

Next Steps

As you will see from the instructions below, installing your own Kubic Desktop isn’t a trivial process at the moment. If I have time, or if others feel like moving this idea forward with me, we really need to look into the following:

Polishing the Product & Image definitions in OBS for Kubic to remove as many of the installation steps below as possible. This would either mean extending the existing images & installation routine to support a Kubic desktop, or producing new images for a Kubic desktop.
As part of the above, remove the conflicts that stop additional patterns being installed with the openSUSE-TW-Kubic product.
Make libzypp-plugin-appdata a recommended dependency so that a system can run with only flatpaks showing in gnome-software instead of always showing the distribution packages also.
To get a complete GNOME installation I chose to use openSUSE’s “gnome” pattern. Finding (or tuning) a GNOME pattern that just installs GNOME without any applications would be nicer, as right now they clutter the installation more than I envision for the idea.
Fix the transactional-update tool to support all of zyppers additional commandline switches (like –from when using ‘dup’).
Working with Flathub so they can setup openQA and start testing their Flatpaks before distributing them.

Install your own Kubic Desktop

These instructions aren’t for the faint of heart, but if you’d like to setup your own prototype Kubic desktop to play with you can follow the guide below

Download the latest snapshot of Tumbleweed Kubic and boot the media, choosing the ‘Installation’ option
Follow the installation wizard as normal, but customise the Partition configuration. You need a btrfs root filesystem with two additional subvolumes @/var/lib/gdm and @/var/lib/flatpak
Choose to install a Plain System
Once installed and rebooted, login as root and run the following command; zypper ar http://download.opensuse.org/tumbleweed/repo/oss tw-repo
Edit /etc/zypp/zypp.conf and set solver.onlyRequires = false
Run transactional-update pkg in patterns-gnome-gnome flatpak gsettings-backend-dconf
Accept any dependency warnings but choosing option 1 and deinstalling the problematic packages
Once installed then reboot - transactional updates don’t apply until the next reboot.
Once rebooted, run the following commands
- systemctl set-default graphical to set the system to boot into a graphical mode in the future
- useradd -m $USERNAME with $USERNAME being whatever you want your useraccount to be called to create a user account
- passwd $USERNAME to set the password for that user account
- rm -Rf /var/cache/app-info to remove any trace of AppData from the official Tumbleweed repos to force gnome-software to rely only on Flatpak
- transactional-update shell to create an interactive shell that will let you modify the otherwise read-only root filesystem
- rpm -e --nodeps libzypp-plugin-appdata to remove the libzypp plugin that creates the app-info AppData
- zypper al libzypp-plugin-appdata to prevent anything installing that package again
- exit to exit the interactive shell and create a snapshot which will effectively be a custom ‘transactional update’ next time you reboot
- then reboot to activate the above changes
You should now be presented with standard gdm login screen with your $USERNAME account being offered, login
Before doing anything else, run the following commands to setup access to flatpak and tune gnome-software to run how we want it
- gsettings set org.gnome.software install-bundles-system-wide false
- gsettings set org.gnome.software allow-updates false
- gsettings set org.gnome.software download-updates false
- gsettings set org.gnome.software enable-software-sources false
- gsettings set org.gnome.software first-run true
- flatpak remote-add --user --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo
Now load up “Software” in GNOME and enjoy your experimental Kubic Desktop experience
To update the system just run transactional-update dup as root, or ideally put it in a cron job/systemd timer and forget about it and trust it to do everything automatically for you

If you are interested in working on this idea and taking it beyond the fun little experiments I’ve started here, please feel free to get in touch using the links at the bottom of this blog.

Thanks for reading!

Hackweek 0x10 - Day 0

Fri, 10 Nov 2017 10:47:12 +0100

All Good Plans... -

It’s here again, SUSE’s 16th Hackweek. A week where all of SUSE Engineering is given time away from their regular grind to work on whatever they want. And of course as this is SUSE we’re talking about, a lot of Hackweek involves the openSUSE Community also.

My Plans for Hackweek 0x10

This Hackweek I have a few small things I hope to spend a little bit of time on, and one huge exciting project I intend to throw most of my efforts in

In SUSE’s Nürnberg office there is a rather large, impressive interactive whiteboard/touchscreen for SUSE Engineering to use. However it’s currently running an inferior operating system, but seems to be reasonably hackable with easy access to the Intel-based embedded PC as part of the screen. So I’m keen to grab openSUSE Leap and make the big screen great again.

I also hear a few people will be looking at WeKan as a possible open alternative to Trello. As I’m not a huge fan of Trello, but interested in using Kanban Boards for organising a lot of what I’m doing, I plan on seeing how hard it is to get WeKan running on openSUSE if I have time; Which is unlikely, because..

The Big Idea - Kubic Desktop

These days I’m working on openSUSE Kubic. While the Project is still in its early stages, we have an exciting platform designed to run containers, with a rolling OS, safely and smoothly updated with atomic, transactional updates.

But my hackweek idea is to take these basic attributes of Kubic and repurpose them as a desktop. An Kubic Desktop should be able to provide a nice reliable GNOME environment, which can be reliably and automatically updated.

It could be a perfect way of leveraging all the existing technologies openSUSE has with Tumbleweed, OBS, and openQA to build a linux operating system which might be useful in “Chromebook”-like usecases.

The openSUSE distributions are sometimes criticised as not being suitable for “your grandmothers desktop”, which is often a fair critism and one that openSUSE shouldn’t be ashamed of - it’s not our communities core areas of interest. But a Kubic desktop could be an answer to leverage what we’re best at for that very scenario.

The only obvious problem is going to be “user space” applications. Installing packages is not a trivial task when the OS is locked down like an appliance. So for that, because I’ve already decided Kubic will have a GNOME desktop and it’s closely aligned with my favourite desktop, I’m going to try use Flatpak.

Why not?

Everybody should know that I am not a great fan of Flatpak or similar approaches to containerised application packaging.

But doing stuff that is weird, unusual, new, and sometimes counterinuative to everything you think is ‘right’ is exactly the sort of thing Hackweek is about.

So I’m excited about learning what I’m going to learn over these next days. Whether I learn to love Flatpak or find a new bunch of concerns about such technologies remains to be seen.

Will probably be a few days before I get around to the Flatpak part of the equation - first steps will be setting up a project in OBS and building basic OS images based on Tumbleweed’s GNOME LiveCD’s, but with Kubic’s read-only filesystem and transactional updates.

Expect updates to this blog once I have something fun to share.

Have a lot of fun!

LetsEncrypt on openSUSE Leap

Mon, 16 May 2016 14:19:00 +0200

with a little help from SaltStack -

I’ve been running my personal blog on rootco.de for a few months now. The server is a minimal install of openSUSE Leap 42.1 running on a nice physical machine hosted at the awesome Hetzner, who offer openSUSE Leap as an OS on all of their Physical and Virtual server hosting. I use the standard Apache available in Leap, with Jekyll to generate this blog. You can actually see the source to this Jekyll blog on GitHub. And to manage it all I use the awesome SaltStack and keep all of my Salt configuration in GitHub also so you can see exactly how my system is setup.

Why am I sharing all of this? Well this weekend there was something I needed to fix.
http://rootco.de was running without HTTPS.

So What?

This site is a blog about Free Software & Open Source stuff, why on earth does it need to be running HTTPS?.

Because every single web service that can be HTTPS, should be HTTPS. There are lots of good articles going back years as to why, but the simplest reasons is that it helps ensure the content you visit when you go to my blog is the content I intended for my blog. It’s very hard for someone to tamper with the content delivered from a HTTPS website. While I’m not (yet) currently hosting any interactive services on my server, if I do I want to ensure they’re secured by HTTPS so the data I’m sending to my server is done so as securely as possible.

And in this day and age, there is rarely an excuse to not use HTTPS for everything. Certificates used to be expensive and complicated to setup, but thanks to the wonderful project LetsEncrypt anyone can now get certificates for their domains for FREE.

Getting Stated with LetsEncrypt

I started as anyone should, by reading the Getting Started Guide.
As there is not (yet) a certbot package for openSUSE Leap, I had to use the certbot-auto wrapper script.
The documentation recommends you install it using the following commands:

$ git clone https://github.com/certbot/certbot
$ cd certbot
$ ./certbot-auto --help

As I’m actually using SaltStack to manage my system, all I did instead was add the following to my Salt State for the rootco.de Web Server.

certbot:
  git.latest:
    - name: https://github.com/certbot/certbot
    - target: /opt/certbot
    - user: root

You can see the git commit HERE.

I then ran the following on my salt master to tell SaltStack to pull down the changes and apply them to the rootco.de Web Server.

$ git -C /srv/salt pull 
$ salt 'luke.rootco.de' state.highstate --state-output=changes

NOTE: I could have just waited, I actually have the above running as a cronjob every 30 minutes to make sure my server configuration stays as I have defined it in SaltStack

I then sanity checked the contents of /opt/certbot before proceeding. I really hate randomly downloading code from GitHub, so I spent a bit of time making sure what I downloaded made sense and matched what I expected, while wishing someone would take the time to package this up on the openSUSE Build Service so I could trust them and stop worrying. Once I was happy, I ran the following command to request a certificate for rootco.de and www.rootco.de:

$ /opt/certbot/certbot-auto certonly --webroot -w /srv/www/htdocs \
-d rootco.de -d www.rootco.de

The wizard automatically detected I was running openSUSE, installed a few packages it needed, then asked me for an email address, and that was it! I had my certificate created and on my server at /etc/letsencrypt/live/rootco.de/fullchain.pem. I followed the advice to backup /etc/letsencrypt as it contains lots of important configuration and the certificates/keys for my system. Now I had to get Apache to actually use the certificate.

Configuring Apache on Leap for LetsEncrypt

Because I was a little rusty, I reminded myself of the openSUSE Leap Apache Documentation. Good thing too, because I can completely forgotten that to tell Apache to use SSL you needed to run the following command:

$ a2enflag SSL

With that set, I went about setting up an Apache vhost configuration for SSL on rootco.de:

<VirtualHost _default_:443>
	DocumentRoot "/srv/www/htdocs"
	ErrorLog /var/log/apache2/error_log
	TransferLog /var/log/apache2/access_log
	SSLEngine on
	# Path to the LetsEncrypt created certificate fullchain.pem
	SSLCertificateFile /etc/letsencrypt/live/rootco.de/fullchain.pem 
	# Path to the LetsEncrypt created private key privkey.pem
	SSLCertificateKeyFile /etc/letsencrypt/live/rootco.de/privkey.pem
	CustomLog /var/log/apache2/ssl_request_log   ssl_combined
</VirtualHost>

Now, because I absolutely hate making any change to the rootco.de Server directly and want everything managed by SaltStack, I actually put this in my Salt States folder, and modified the rootco.de Web Server state to automatically deploy the file to the appropriate place on the server. You can see the git commit for that HERE. As I am impaitent and didn’t want to wait for my automatic deployment, I again manually refreshed the Salt States on my master and used salt to deploy this new configuration:

$ git -C /srv/salt pull 
$ salt 'luke.rootco.de.' state.highstate --state-output=changes

A quick systemctl restart apache2 on the server later and I was in business - https://rootco.de was live!

That’s great but…

LetsEncrypt certificates have a duration of 90 days. I want https://rootco.de to be running for a lot longer than that, so I needed to find a solution.

The LetsEncrypt Documentation talked about a renew function so I gave it a quick try:

$ /opt/certbot/certbot-auto renew --dry-run

This seemed to work fine so I added a simple cron job to run the following every 60 days:

$ /opt/certbot/certbot-auto renew >/dev/null 2>&1

I picked 60 days as LetsEncrypt certificates only let you renew 30 days before expiration, and I want to hit their servers as little as possible while still ensuring the certificate always gets updated before it expires. >/dev/null 2>&1 is there because I really don’t care about the logs - if it works, I will never need to look at it, and if it’s broken I’m going to have to be running the command manually anyway to figure out what went wrong.

Doing a cronjob in SaltStack is so easy, I used it rather than editing the crontab for root myself.

So now my server is running with HTTPS, with a nice shiny LetsEncrypt certificate for both https://rootco.de and https://www.rootco.de, and the whole thing will auto renew ever 60 days. And if something goes horribly wrong and my server gets messed up, all of this is easily redeployable using SaltStack, which is a nice extra bonus for me.

One last thing

LetsEncrypt is awesome. This service is really revolutionary and is the sort of thing which shouldn’t be taken for granted, so please help them out by Donating to LetsEncrypt.

openSUSE & You

Sun, 03 Apr 2016 02:00:00 +0200

Contributing to our Project -

The openSUSE Project is awesome. We’re doing facinating stuff that is treading new ground in the world of Free and Open Source Software.
If you’re interested in how and why we’re doing this stuff, if you’d like to get involved, then this blog post is for you.
After reading you should have an idea of how we work and how to get started working with us.

“How does the openSUSE Project work?”
“Who decides what happens?”
“What do you need me to do?”
“How do I get started?”

How does the Project work?

The Project is a self-organised, self-governed, community working on the openSUSE Distributions (Tumbleweed & Leap) as well as various other Free and Open Source Software, including OBS, openQA, OSEM, Portus, Machinery, and more.

We have no Product Managers, Project Managers, or Community Managers.
We have no Technical Committees or Steering Groups.
For those who have read “The Cathedral and the Bazaar”, openSUSE is very much a “Bazaar” and hardly anything like a “Cathedral”. Whatever Teams we do have are self-organised by the members of those teams, with different ways of working together to accomplish whatever particular goals within the project they are working on.

The Project does have the openSUSE Board, who’s role is to ‘lead’ the Project by acting as a central point of contact and conflict resolution. In other words, they help keep everyone in the loop with what everyone else is doing, help resolve any conflicts that arise, and act as the ‘decision makers of last resort’ in situations where decisions need to be made and there is no one else available or willing to do so.
The Board is a little like the ‘A-Team’ - If you have a problem, if no one else can help, then the Board is there for you, either to help out, or help you find better help elsewhere. The Board is elected by the openSUSE Members, those contributors who have demonstrated sustained and substantial contributions to the Project.

SUSE are the primary sponsor of the openSUSE Project. All SUSE employees are encouraged to contribute to the openSUSE Project. These contributions are carried out as ‘peers’;
No special treatment is granted to SUSE employees, in fact the employer of a contributor should be irrelevant within the openSUSE Project.
In areas of particular interest or importance to SUSE, they may hire folk to work in particular roles within the openSUSE Project. With one exception (the role of Chairman of the Board), none of these roles should be considered exclusive to SUSE. There is scope for anyone to contribute to the openSUSE project at any level, assuming they are willing and capable to do the work.

Who decides what happens?

You Do.

We are driven by our contributions. If something is not being done, it’s because no one has decided to do it. We do our best to make openSUSE very accessible in order to make us the natural choice to be the Project through which you give your time & effort.

The openSUSE Project is structured the way it is to empower our contributors to really shape the direction of the Project. Also a significant amount of the tools we have as a Project exist in order to make those contributions easier. OBS and OSEM are obvious examples, but this is true in all aspects of the project, from the technical parts to the diverse range of other activities, marketing, advocacy, outreach, community, wiki, documentation, and more.

You don’t need to ask permission to get started, you just need to know what you want to do.

What do you need me to do?

You Decide.

Please don’t be terrified by this! To quote The Cathedral and the Bazaar:

“Every good work […] starts by scratching a […] personal itch.”
– “The Cathedral and the Bazaar”, Eric S. Raymond

Find things inside openSUSE, our Project, our distributions, our tools, our wiki, that you do not like, that affect you, that get in your way, and decide to change them.

While it may sound selfish, there is no better motivation than solving the issues which affect you first and foremost, the benefit of doing that as part of a community means your work ends up helping others, and others will in turn help you when they share that same itch that needs scratching.

Don’t expect someone else to do it. Don’t think it is someone else’s job to fix. It is your responsibility to help make openSUSE succeed in the areas that matter to you.

And don’t expect anyone else to tell you what to do or what needs doing - volunteers are rarely motivated when given orders from others, so that just isn’t typically the openSUSE way.
That said, I do believe we could do with having some indications of particular areas where we need help; The new openSUSE Mentoring website is a perfect example of something the Project now has to solve that problem.

In the highly unlikely event that you think everything is wonderful and there is nothing that annoys you, but you still want to give something back to the openSUSE project, then dig a little deeper, try something new, either technically in our products, or get involved in a new aspect of the Project that interests you.
I guarantee you’ll find something somewhere which could do with your help.

How to get started?

So, you’ve picked something to work on, how to get started. Here is my advice.

Do your homework

Make sure you understand the topic you are tackling. Dig through the problem to make sure you haven’t missed something.
Read our wiki pages on the topic. Use Google. Look at how other FOSS Projects deal with the problem. Is their solution better or worse than what you are thinking?
Talk to people who might know stuff about the topic, and bounce your ideas off them. Our IRC channels are a good place for such discussions, as are events like our openSUSE Conferences.

Plan your solution

You’ve decided what you want to do, now you need to decide how you intend to do it.
You don’t need to have all the details worked out, but you should have a clear understanding of the direction you want to go in, and how things should look when you are done

Do you need help?

Is this going to impact other people in a noticeable way? Do you want a second opinion?
If the answers to any of these questions are yes, continue to “Share with the Project”.
If no, skip to “Do It”.

Take everything you have learned, and what you plan, and put it all together in a clear, succinct email for the mailinglists.
Avoid writing open ended questions. Despite everyone’s best intentions, coming to the Project with a question like “What do you think we should do about X?” will lead to either silence, or an almost infinite number of responses, many of which will disagree with you, often without proposing alternatives.
Write the email from the perspective of “This is what I think we need to do, and this is what I intend to do about it”.
Describe your findings from “Do your homework”, explain your plan. Include proof of concepts if you have them.
Post this mail to an appropriate mailinglist.
If you cannot identify an appropriate list, or you think the topic is deserving of a project-wide audience, then use either opensuse-factory@opensuse.org for technical changes, and opensuse-project@opensuse.org for everything else.
Once you are happy the email makes it possible for everyone else to understand the problem, and that this is your problem and you are going to solve it, fire away!.
Now it is the responsibility of everyone else in the Project to convince you that you need to do things differently.

Listen

The openSUSE Project is full of very clever people. Listen to their feedback, consider it.
As your proposal included your reasoning, their feedback should be equally reasoned and informative, and so even a ‘failure’ of a proposal at this point is a learning experience.
And that is a good thing, sometimes better than accomplishing the thing you set out to do in the first place.

Respond

Fast feedback drives innovation.
If people are giving you feedback, discuss back with them, tell them when you agree with what they’re saying, tell them when you disagree and why.
This is how you will find other people to work with you on this thing.

Decide

You do not need to accept all, or any, of the feedback.
If nothing comes up that convinces you to deviate from your plan, then carry on as you planned.
If something gets in the way, then work together to find a solution, either one that includes a compromise that everyone is equally unhappy with, or one where ‘both’ options are possible.
This is an aspect of the openSUSE community that we often overlook - when we have two sets of contributors wanting to pull in two different directions, our collective natural instinct is to often find a way of accomplishing both.
How else do you think we ended up with KDE, GNOME, XFCE, LXDE, Enlightenment, etc?
This is a good thing, makes our project reflect everything which our contributions want to work on, and something which really sets us apart from many other Projects out there.

Do it

You’re all set! Get to work. Start your engines! Time to inconvinience some electrons with your code! and don’t forget, Have Fun!

Talk about it!

Our statistics show that the openSUSE Project is on the up and up, and we are in many ways ahead of a great many similar projects who are often perceived as being more successful than us.
A big part of that is because we excel at doing stuff, and are lousy about talking about it.

So this is a call to action to ask that everyone reading this post keeps in mind the cool stuff that they’re working on as part of openSUSE, and talk about it.

Social media, conferences, meetups, whenever you get a chance, tell the world about what you’re doing. It is not just a case of being ‘Green and Proud’, but talking about recent successes often leads to conversations that reveal what the next challenge is, and so the cycle continues, but at least it’s a lot of fun ;)

You can start with this post. Please share it on Facebook, Twitter, Google+, Reddit, Hacker News and anywhere and everywhere else people might be interested in contributing to openSUSE.

openSUSE is amazing, it can be even more incredible, and we want YOU to help us shape it and make it into something even more special.

Why You Should Use Tumbleweed

Mon, 28 Mar 2016 19:05:02 +0200

People often ask me why they should use openSUSE Tumbleweed and how it compares to other distributions like Fedora or Ubuntu. The fact is Tumbleweed is actually rather hard, if not impossible to compare to Linux distributions like Fedora or Ubuntu.

Both are ‘traditional’, released-based distributions. They build it carefully over a few months, they ship it, and they then cautiously patch things (often keeping those changes as small as possible, backports, etc) to keep it secure/usable for their users over their chosen lifespan.

If you’re interested in an openSUSE like that, we have Leap, and I believe Leap to be better than Fedora and Ubuntu for a whole bunch of reasons, starting with the fact that Leap has an Enterprise codebase (SUSE Linux Enterprise to be exact) at its heart with the openSUSE Project building a fully-fledged community distribution ontop of it.

But today I want to talk about Tumbleweed.
While Leap aims to be rock-solid, Tumbleweed rolls.

It’s more like Arch and Gentoo in that regard. Tumbleweed today contains the latest packages of every software stack that has been packaged by the openSUSE Project. Latest kernel, libraries, desktop environments, everything in Tumbleweed can and does change regularly.

But, unlike other rolling distributions, Tumbleweed does it smarter.

Built Correctly

Tumbleweed is built like a ‘traditional’ distribution. All packages in Tumbleweed are built together as a cohesive distribution, and shipped together as a cohesive distribution. If a new package is checked in that potentially can invalidate another package (eg. new glibc, new libraries, new kernel, etc) then the dependant packages are rebuilt, just like traditional distributions.

But where as traditional distributions take days, sometimes weeks to do such, we do it in hours, because we have the Open Build Service.

You can learn more about Open Build Service HERE.
You can see, and use the openSUSE Build Service for free, today.

This produces a ‘snapshot’. At this point a traditional distribution would probably call this a ‘release candidate’, an ISO and a set of repositories with all the software built and ready for testing.

Most distributions take weeks to produce coherently built and tested disk images & repositories. Tumbleweed does it about 5 times a week.

Tested Well

But building is only half the story. A good distribution needs to be tested. A good rolling distribution needs to be tested quickly. Arch and Gentoo rely on manual testers and purposefully delaying the inclusion of packages in their main repos in order to give people time to test stuff. openSUSE has openQA.

Before any human being is allowed anywhere near a snapshot, openQA tests that snapshot over 100 times across four different hardware architectures (i586, x86_64, ppc64, and aarch64).

These are not artificial ‘some developer writing some code to poke around some APIs’ kind of tests.

openQA actually does proper real-world scenarios. Installations, upgrades, dual booting, encrypted LVM, kde, gnome, xfce, live CD’s, network installs.
You name it, we test it. And if we don’t test it well enough, we most certainly want to, and you can help contribute tests as everything in openQA is 100% open source.

Just take a look at the openQA results for a recent Tumbleweed snapshot for example, just to give you an idea

Again, these aren’t some kind of artificial ‘some fancy coder wrote a robot that can mash buttons in the right order’ tests. openQA can actually see the screens it is testing.

It uses openCV and a library of reference screenshots (with areas of interest selected to allow openQA to ignore things we don’t care about) which we call ‘needles’.

So every test checks that every screen looks the way we want it to look for users. Every function that is tested presses the same keys and clicks on the same mouse buttons that a user would, and then openQA confirms that piece of software behaves in the way it has been taught to expect.

openQA does this for every step in installations & upgrades.
openQA checks all the core console commands, systemd, zypper, YaST in ncurses mode, curl, vim, firewall, ssh, etc, etc.
openQA then logs into the desktop environment of choice (GNOME, KDE, lxde, xfce, etc) and checks graphical applications. Is gedit working? firefox? thunderbird? libreoffice? inkscape? gimp? etc, etc.

And it does this all in dozens of different scenarios, over and over again, in parallel across many VMs and machines.

We even do extra testing on incoming package submissions, so many cases we catch things before they get anywhere near a snapshot, and our developers get nice fast feedback about their otherwise potentially destructive change. Yes, we have implimented Continuous Integration for distributions, and if you were using OBS and openQA you could be doing it too.

Delivered Quickly

1000’s of tests, over 100 scenarios…and with our current hardware (thanks SUSE!) a full snapshot gets tested in about 3 hours.

And if it passes, it ships, automatically.

Most distributions take weeks to produce coherently built and tested disk images & repositories.
Tumbleweed does it about 5 times a week.

And a ‘quiet’ week can consist of approx new/updated 150 packages and a new kernel.
A normal week is double, if not triple that, and it’s moving faster and faster..

All that extra work doesn’t get in the way. We often beat other rolling distributions into delivering tested versions of KDE Plasma and GNOME, because we can test them quicker and ship them with a certainty that nothing breaks.

That’s not universally true though, good testing finds bugs, those bugs need to be fixed, so if you ever notice something taking longer than you’d like, it’s often a sign that we could do with more contributors helping Package that particular software. You can learn how to contribute to Tumbleweed HERE.

Trusted by More and More

Most of what I describe above was implimented after July 2014 and culminated in the ‘merger’ of Old Tumbleweed and Factory in November 2014.

Since then, the adoption rate of Tumbleweed has been nothing short of astronomical..

If public numbers are to be believed Tumbleweed might already be larger than ‘more famous’ rolling distributions. Whether or not that’s true doesn’t change one fact - We want YOU to try Tumbleweed.

And you’ll be in good company. Not only amongst those users, but companies like SoftIron who ship Tumbleweed on their Overdrive 3000 64-bit ARM servers, and Fujitsu who offer Tumbleweed as their chosen community Linux to customers with Skylake hardware. GNOME advertise Tumbleweed-based GNOME:Next LiveCD’s so their users can play with their latest releases as soon as they are shipped, even before the tested packages appear in Tumbleweed properly.

I may be biased, but Tumbleweed is the only rolling distribution I’d recommend to any Linux enthusiast as their daily driver.

If you care about Linux, you want the latest packages, but you only want them when they actually work, Tumbleweed is the best choice, bar none.

And anyone who disagrees with me is welcome to join the openSUSE Project, find us on opensuse-factory@opensuse.org Mailing List and help make it even better ;).

NOTE: This blog post started as a response to a Reddit Post. Thanks to the OP for the inspiration!

openSUSE Face-to-Face Board Meeting 2016 Minutes - Part 3/3

Sun, 20 Mar 2016 16:20:02 +0100

18th-20th March

Present:

Richard Brown - Chair
Michal Hrušecký
Kostas Koudaras
Tomas Chvatal
Gertjan Lettink
Bryan Lunduke - Extra special thanks goes to Bryan for attending via video conference at ridiculous hours in his local timezone after urgent personal matters kept him from attending the meeting in person.

As this years Board Meeting Minutes are so long, they are split into 3 sections

Meetings - Covering the meetings the Board had with various SUSE executives, managers, and engineers.
General - Covering the general agenda items/day-to-day issues
Strategy - Covering the ‘big picture’ issues the Board discussed

This email is Part 3, containing ‘big picture’ strategy issues discussed

Part 1 is available HERE

Part 2 is available HERE

Strategy

Improve Visibility

Obviously, we want to improve the visibility of the openSUSE Project.

We have great distributions, great tools, and great technologies, and we want them to be adopted by as many people and other projects as possible.

We also want to be a natural choice for new contributors and new projects to come to openSUSE, work with us, and host their projects with us.

SUSE

SUSE is our closest, largest, partner. We have strong practical ties with them, but that does not mean we can forget about things such as regular clear communication and ‘internal marketing’.

SUSE are working on a number of exciting new things, and it’s important that internally openSUSE is seen as a natural home for SUSE’s open source contributions.

Working closely together also should enable SUSE’s corporate marketing experts to help spread the good word about all the awesome stuff the openSUSE Project is doing

AI:Bryan to investigate the possibility of Doug being invited to Weekly team meetings for SUSE Corporate Communications

AI:Bryan to drive ensuring openSUSE is well integrated with SUSE’s ongoing marketing.

Outreach

There’s no point only targeting our existing contributors and partners like SUSE. Any open source project needs new people and with new people comes new ideas, new solutions, and new exciting projects for people to hack on.

A huge challenge for new contributors and projects is understanding what is available

Who is the openSUSE Project?
What services do we provide?
Where do I go to get involved?
How do I get started?

These are questions which are key to have simple, clear, easy to find answers to

CALL FOR HELP: The Board wants to see getting started guides for

New Users
New Contributors
New Projects- to encourage other projects to come use openSUSE as their home

to answer the above questions. These should be simple, clear, and relatively short. The produced guides should be easily usable on a wiki, the website, on flyers at conferences, short blog posts..we want to be able to spread them everywhere

The guides for new Contributors and new Projects are considered a Priority by the board- to use a football related quote “There is no point having fans, if you don’t have your 11 on the pitch to play for them”

AI:Board intends to create a skeleton of the above guides to help bootstrap this idea, and will drive this, but the Board is keen to see if anyone from the community dives in and gets to work on this immediately.

Other Projects

While openSUSE is keen to see other projects call the openSUSE Project it’s home, we recognise that it’s not viable for many, especially those larger ones with their own established communities

In cases like this the Board wants to encourage strong relationships with such Projects, and seek out partnerships and other arrangements with such Projects for the benefit of all involved

Examples include ownCloud and Kolab, where we believe openSUSE is in a perfect position to offer tools, community, and a solid environment for these projects to use as a default or recommended platform for their users

AI:Bryan to arrange information exploratory discussions

Hardware vendors

Having hardware sponsors and partners is nice but is hard. Solid hardware support requires the hardware to be available and in the hands of the right contributors to make it happen.

Otherwise there is no way how to support special hardware without the things available for testing.

However, we do have some relationships which are happening, and we want to highlight those who do stuff with us, such as

Soft Iron are shipping 64-bit ARM servers with openSUSE Tumbleweed as standard
Fujitsu offer openSUSE Tumbleweed to thier customers who want a Linux option on their Desktop & Server Hardware
Epson have some printers using openSUSE and YaST
Open Mainframe are investigating the possibility of building an openSUSE distribution for s390x

Reform and Remove Mess

Improving viability and reaching out to new areas is all well and good, but we need to make sure the project internals are tidy, clear, and easy to use

The Board discussed the state of many infrastructure and project policies and processes.

We agreed a principle of, when something is imperfect, we Reform (aka improve) or Remove it.

Services identified to be removed or reformed:

Software.o.o:
- Media download needs to be easier, prefferable static page
- package search adds too much mess to the installed systems. Invalid repos should not be distributed by 1-click installs
- somehow redesign and reduce confusion to ensure that users do not end up with 80+ additional repos.
Wiki:
- In order to fix the wiki quickly ,the board approved the idea of deploying the latest version of mediawiki on a new server without branding
- branding can always be redone later
Blogs/Planet:
- Only a handful of people use lizards, but it takes a lot of resources to keep it running. We want to shut it down, and encourage it’s users move to their own blogs, which will then be aggregated on planet.opensuse.org
- Improve planet.opensuse.org. Find a maintainer, use a clean upstream OSS soltion if possible

AI:Kostas to contact the few Lizards bloggers to discuss their migration options

News.o.o:
- Wordpress consumes too many resources and poses too many security risks
- Replace with something lightweight

AI:Richard talk with Douglas about this

i18n.o.o: Translations site is being migrated to l10n.o.o as we speak and i18n will be killed including the svn prior Leap 42.2 release.
Legal layout of Board/membership: The current layout of the Board Election Rules, Membership Rules, and such are sometimes confusing and missing some details The documents will be updated and restructured to be more clear This should set the framework for discussing any reforms of the Membership process once the Membership tidy-up is complete

AI:board- get Infra team to provide list of services we have, soon to help with this endevour

openSUSE Face-to-Face Board Meeting 2016 Minutes - Part 2/3

Sun, 20 Mar 2016 16:20:01 +0100

18th-20th March

Present:

Richard Brown - Chair
Michal Hrušecký
Kostas Koudaras
Tomas Chvatal
Gertjan Lettink
Bryan Lunduke - Extra special thanks goes to Bryan for attending via video conference at ridiculous hours in his local timezone after urgent personal matters kept him from attending the meeting in person.

As this years Board Meeting Minutes are so long, they are split into 3 sections

Meetings - Covering the meetings the Board had with various SUSE executives, managers, and engineers.
General - Covering the general agenda items/day-to-day issues
Strategy - Covering the ‘big picture’ issues the Board discussed

This email is Part 2, containing general agenda items

Part 1 is available HERE

Part 3 is available HERE

General

Desktops

Board discussed the state of the various desktops in openSUSE. Improving the selection screen to better reflect the actual nature of our distributions is something we certainly want to see.

AI: Board to discuss some ideas with our various Desktop Teams

Membership Tidy

Board discussed it’s ongoing efforts to tidy up the membership list. We have plenty of members that might not be around anymore. From previous discussions we have a draft of what we want to do and it was heavilly discussed over and over. So we will move to the implementation. Current plan is to do just a small changes that were already discussed (announcement pending), there might be a room for bigger changes and cleaning up the rules, but that would need mebers agreement. We should also remove inactive members of membership comittee. Together with retiring connect.openuse.org we probably can have some space to make membership management easier and faster.

AI: Tomas should investigate Helios voting system for openSUSE

AI: Michal to draft email about inactive members

AI: Michal to start with tooling and kickstart the process of retiring inactive members according to the proposal sent

AI: Michal is retiring connect.opensuse.org and doing the Membership tooling

Mailinglist Moderation

Board discussed concerns regarding some behaviour of a few individuals on the mailinglists.

We recognise that some misbehaviour requires fast action. Agreed that any one Board member can act on behalf of the Board.

When behaviour is not inline with the Guiding Principles the Board agreed a principle of 1 private warning followed by a Ban

Sponsorships

Conference in Albania asked for support, but as no person is going there from openSUSE, we are not providing money.

openSUSE only sponsors events where openSUSE can attend. We decided to become Platinum Sponsors to Greek FOSSCOMM- Greekos will be attending

We discussed updating the sponshorship document for people interested in sponsoring our Project in order to better guide what to do and what optons are available to become openSUSE sponsor.

AI: Kostas will take care of the Negotiation regarding FOSSCOMM

AI: Board to put together a Sponsorship policy document

Trademark

Trademark requests often get lost of spam, hoping the proposed new @opensuse mail system will be better with spam.

T-systems requested permission to use openSUSE on their new Open Telekon Cloud - Approved

AI: Richard to review/tune up filtering in current system so trademark requests don’t get lost.

Maintainer tidy up

Board discussed OBS state of inactive maintainers. With the members cleanup prepared we want to clean this up too.

It’s very important to new and existing contributors alike that it’s easy to identify who is responsible for which package, or which packages are low on active maintainers.

Technically we want maintainer tidy-up like the home: repositories cleanup

AI: Tomas will talk with Craig about OBS team preparing the code for this

Treasurer

Board wants to reduce it’s time spent worrying about money, sponsorship, and TSP related matters. The Board’s role is meant to be more focused on the actual immediate and long term issues impacting the Project as a whole, and the details of money matters is quite often a distraction from these.

The board agreed to create a openSUSE position called Treasurer. They will be a non-voting board member appointed by the Board. Responsibilities of the Treasurer:

Money
Sponsorships
Event
Merchandising materials
TSP

Treasurer must provide regular reports to the Board and thus is expected to attend all Board meetings where the above responsibilities are discussed

As a Board appointee, any future Board is expected to confirm their choice of Treasurer in their first meeting after being elected

This Board has appointed Andrew Waffaa to be the current Treasurer, effective immediately

AI: board should add treasurer to board ML and create treasurer@opensuse.org mail alias

AI: Board to announce it to Project

AI: Board to put stuff on wiki regarding rules/scope

Kickstarter

With the sponsorship document updated we could provide kickstarter option for community to sponsor hadware.

This should aim to please most people requesting separate foundation, because even small donations will be allowed to flow in.

AI: Tomas will talk with Andrew and Marketing teams on how to do this

openSUSE Face-to-Face Board Meeting 2016 Minutes - Part 1/3

Sun, 20 Mar 2016 16:20:00 +0100

18th-20th March

Present:

Richard Brown - Chair
Michal Hrušecký
Kostas Koudaras
Tomas Chvatal
Gertjan Lettink
Bryan Lunduke - Extra special thanks goes to Bryan for attending via video conference at ridiculous hours in his local timezone after urgent personal matters kept him from attending the meeting in person.

As this years Board Meeting Minutes are so long, they are split into 3 sections

Meetings - Covering the meetings the Board had with various SUSE executives, managers, and engineers.
General - Covering the general agenda items/day-to-day issues
Strategy - Covering the ‘big picture’ issues the Board discussed

This email is Part 1, containing meeting minutes of meetings with SUSE

Part 2 is available HERE

Part 3 is available HERE

Meetings

Meeting with openSUSE Release Manager - Ludwig Nussel

The Board met the new openSUSE Release Manager - Ludwig Nussel

He shared the following tentative information about the planned release for Leap 42.2:

Leap 42.2 will be based on SLE 12 SP2 and their release scheduled are ‘aligned’ (ie. They will be developed together, but not necessarily release together)
Target release date for Leap 42.2 is 1st week of Nov 2016. Expected to have an updated systemd, GNOME, Qt, kernel all inherited from SLE 12 SP2
KDE of course will want to upgrade from 5.5, expected 5.6, discussions underway about what upgrade policy will make sense for the lifespan of Leap 42.2
We don’t expect X will be updated, which will mean 42.2 will have the same version as 42.1, which is newer than the version in SLE 12 SP1 or expected in SP2

Leap 42.2 will start with a base of Leap 42.1, with packages updated from that point. The process for contributing to Leap 42.2 needs explanation

We discussed the shape of how we’d like to see the wiki. We all agreed want to see a big tidy up. Many of the Portals have little benefit and serve little purpose. We want to see the namespaces removed/flattened to help the search

Tumbleweed deserves a Portal. Questions the page must answer include “What is Tumbleweed?” “Why use Tumbleweed?” and “Why might Leap be better for you?”
Leap is similarly important, needing to answer the questions “What is Leap?” “Why use Leap?” and “Why might Tumbleweed be better for you?”
Packaging Polices and the Factory process are other ‘key’ pages which must be preserved, polished, and refreshed during any wiki cleanup
Team pages would be ‘nice to have’ but many Team pages are currently woefully out of date. We would like to see a solution investigated where the wiki team page is inherited from a devel project

We discussed the idea of forming a “Release Team” with specific roles that are responsible for ensuring that key parts of the Release process are carried out

Obvious roles include “Website coordinator” to ensure the website is updated. “Wiki Coordinator”, “Marketing Coordinator”, “Test Coordinator”, “Translation Coordinator” are other obvious roles

These people would not necessarily be responsible for doing the work, but for coordinating with Ludwig and ensuring that the work gets done by someone.

AI: Ludwig to mail the Board with any other “Roles” which are expected to be needed

AI: Board + Ludwig to send a ‘Call for Volunteers’ for the roles, and to put together the team

AI: Board to request release-team@opensuse.org list for this team

Discussed some of our local teams. We share concerns that those teams with their own forums, own wikis, and own websites ultimately ‘split’ the community and make it harder for everyone to benefit from the shared knowledge, experience, and feeling of ‘collective ownership’ of the project. We’d like to see such sub-communities bought closer together and go forward more ‘aligned’ with the rest of the openSUSE Project

We discussed some concerns regarding the current openSUSE Infrastructure software.opensuse.org serves two very important roles, both as the main download portal for our distributions, and as a software search for OBS

PROPOSAL: Split http://software.opensuse.org to have the download portal and search separate.

The download portal could be a simple, clean, fast, static site that would offer the Leap and Tumbleweed ISOs.

Software search would continue as it is…but we considered some problems with that

The current implementation of One-Click installs is often dangerous. Because they add all the repos setup in the OBS repo you often end up with crazy things like Factory:ARM repos being added on systems where they are not relevant

Furthermore, making it very easy to install packages from ‘non-official’ repos dramatically reduces the motivation and impetus for developers to put their packages in the Distribution

Having packages in the Distribution though is the best way to ensure your package works, is tested, and is integrated

So we would like to see One Click only pulling from the official repos. If Packages are not in the official repos, we would like the software search to put users in touch with devel project maintainers to encourage the packages be added to the distributions

CALL FOR HELP: We would like a maintainer for software.opensuse.org to help implement the above changes to the search and download functions of software.opensuse.org

Meeting with the SUSE Infrastructure Team

The Board received an update from Gerhard Schlotter, Marcus ‘darix’ Rueckert, and Lars Vogdt from the Infrastructure Team at SUSE

SUSE host 12 physical servers for openSUSE services. This is in addition to the 127 OBS & openQA physical servers
Those 12 macines host a total of 60 VMs
The OBS and openQA hardware host a total of 820 VMs
www.opensuse.org has 2.3 million visitors per month - how can we make that bigger?

Discussed the immediate problems with some part of the infrastructure, especially the wiki. Some is hosted in SUSE’s datacenter in Provo, some is hosted in Nuremberg. Nuremberg datacentre has room and admins, but limited bandwidth (not enough for how busy stuff gets on releases). Provo datacenter has room and bandwidth, but limited admins. SUSE have an engineer moving from Nuremberg to Provo to help illivate that problem. Having sponsored hosting elsewhere is an option we want to actively pursue. We have hardware available if we can find a host.

CALL FOR HELP: Please help us find sponsors willing to help find openSUSE infrastructure

Infrastructure guys would like the Sponsorship leaflet to be updated in order to better court possible hardware and hosting sponsors

AI: Douglas to update sponsorship guide

Improvements to the @opensuse.org email system are being investigated

Infra team would like connect.opensuse.org to be shutdown

AI: Board to investigate alternatives for voting & membership management

Lunch

The Board had lunch with dozens of SUSE Engineers. Lots of different conversations but the key topics that stuck with the board include:

Discussions about how to improve translation/l10n tools and workflows
Communication with the KDE Project
How to get started with openSUSE, as a contributor and as a Project that wants to be part of the openSUSE Project.

Meeting with Ralf Flaxa - President, Product Engineering at SUSE

Ralf thanked the Board for coming and their ongoing work for the openSUSE Project, and expressed SUSE’s pleasure with the success of Leap and the general direction of the openSUSE Project

Ralf shared some ideas regarding oSC and his departments Hackweek

AI: Board to discuss the ideas with the oSC organisers

Meeting with Roland Haidl - Director, Operations & Communities at SUSE

Roland reaffirmed SUSE’s intention to continue funding the openSUSE Project at similar levels.

Roland shared Douglas DeMaio’s plan to refill our merchandise before openSUSE Conference 2016.

Board requested budget for openSUSE Asia at the same levels as last year - Approved

Discussed the possibility of the Board appointing a Treasurer to be the primary contact with SUSE on financial matters (Sponsorships, TSP, etc) - Approved

Discussed the possibility of a hackathon for the Release Team, once it’s formed - Approved in principle (Needs the team first)

Discused the possibility of more ‘minisummits’ consisting of openSUSE presentation tracks and related events colocated at other events around the world - Approved in principle (Needs events and volunteers)

Discussed the current wiki problems. Roland volunteered to help drive a solution.

AI: Richard - Infrastructure to be a standing topic in regular Chairman meetings with Roland

Tour

The Board was given a tour of the SUSE HQ, including the recently expanded office space and server rooms.

Hello New World!

Tue, 15 Mar 2016 01:13:55 +0100

I’ve had to move my old blog from http://sysrich.co.uk to this new server on http://rootco.de

Most of my favourite blog posts have made the transition and have migrated from the ‘old fashioned’ Wordpress to the new and shiny Jekyll

It’s an excuse for me to learn a bit of Ruby, practice my markdown, and keep exercising my git skills

I plan to get back to blogging more often about the goings on in my world, especially about openSUSE and openQA

And just to give Jekyll a bit of a stretch on my first real post, here’s an openQA code snippit from Frederic Crozat’s recent submission to openQA

    select_console 'root-console';
    save_screenshot;
    
    script_run "cat /home/*/.xsession-errors* > /tmp/XSE.log";
    upload_logs "/tmp/XSE.log";
    save_screenshot;

    script_run "journalctl -b > /tmp/journal.log";
    upload_logs "/tmp/journal.log";
    save_screenshot;

    script_run "cat /var/log/X* > /tmp/Xlogs.log";
    upload_logs "/tmp/Xlogs.log";
    save_screenshot;

    script_run "ps axf > /tmp/psaxf.log";

openSUSE Regular Release - The Future is Unwritten, let's write it

Sat, 02 May 2015 01:46:21 +0200

The recording of my presentation from openSUSE conference 2015 is live.

During the session I talk about the success of Tumbleweed and how its the best choice for anyone who wants their Linux with the latest and greatest software

I then go on to talk about our openSUSE Regular Release, where I propose using the recently released SUSE Linux Enterprise sources as an opportunity to build a Stable Linux release that covers the needs of more conservative users as successfully as Tumbleweed covers the needs of those who want new versions of everything, regularly

Please enjoy the video and join the discussion on the opensuse-project@opensuse.org mailinglist

Hackweek 12 & openQA

Sun, 19 Apr 2015 21:09:52 +0200

Last week was SUSE's Hackweek 12.
Hackweeks are special weeks at SUSE where all of SUSE Engineering get to work on whatever they'd like, to try cool things and learn new stuff.

This Hackweek was my first at SUSE's Nuremberg office, and it was quite an experience. The whole place had a 'buzz' about it all week. Every day the company sponsored Lunch or Breakfast, which got everyone together and triggered many interesting conversations. Some times we were serenaded by the 'SUSE Band' who were working on their musical abilities and technology for hackweek.

I had lots of conversations about the upcoming openSUSE conference, some of SUSE's planned projects around openSUSE, and of course openQA, which was a big part of lots of peoples Hackweek.

Bernhard Wiedemann worked on adding subtitles to openQA's video recordings so users can see what openQA is doing when it produces the recorded screen output.

Max Lin worked on a chrome extension to provide live status monitoring of an openQA instance and its workers.

Bernhard, Stephan Kulow, and Klaus Kämpf looked at getting openQA to test bare metal hardware.
While openQA already has support for IPMI for bare metal testing of servers, pushing the already established limits is exactly the spirit of Hackweek :)
Bernhard started experimenting with the idea of using ARM development boards to emulate a keyboard and relay openQAs keyboard commands. Next Hackweek he hopes to have a HDMI grabber so it will be able to see the video output also.
Klaus and Coolo were successful in getting openQA to control hardware with Intel vPro/AMT (as found in Thinkpads and other common laptop/desktop hardware). This demonstration video shows it working on my very own X220 Thinkpad.

And Xudong Zhang from Beijing and myself worked on testing openQA by using openQA

Testing openQA on openQA, are you crazy?

Actually, only a little crazy.
We made life easy for ourselves by creating two disk images (one for SLES 12 and another for openSUSE 13.2) to represent the same production environments we have for http://openqa.opensuse.org and the internal SUSE openQA instance.

These images were created following the regular openQA Documentation and setup to test a 'known good' Distribution with a static set of tests (openSUSE 13.2 with the tests and needles from our GitHub project)

We then configured openQA to treat this disk image as a different 'distribution', and we wrote new tests for testing openQA (See the source code HERE)

A little bit of 'needling' later (Capturing the reference screenshots and defining the areas of interest to openQA, which can be found HERE) we had a working test run which was able to test openQA running on openSUSE 13.2

and also for testing openQA on SLES 12

These tests successfully test all the core functionality of openQA, including Upgrading from the official OBS repository, Confirming the Worker is running, Scheduling an openQA job from the shell, Confirming a Job is running from the shell, and checking the functionality of each of the UI Screens by loading up Firefox and clicking on all of the links just like a user would.

With this development, we now have a way of confirming that new builds of openQA are safe for deployment in production, which should help us be a little more fearless and rapid updating the openQA versions in use for testing openSUSE and SUSE Linux Enterprise, even when during heavy testing periods.

Expect to see these tests running on the public http://openqa.opensuse.org soon.. I just need to figure out an elegant way of triggering them automatically as soon as OBS has new RPMs for testing.

Thanks to all who made this Hackweek awesome!

Why openSUSE?

Sun, 01 Mar 2015 00:12:44 +0100

As this is hosted on my personal blog, this should probably go without saying, but given the topics covered in this post I wish to state for absolute clarity that the content of this post does not necessarily reflect the official opinion of the openSUSE Project or my employer, SUSE Linux GmbH. This is my personal opinion and should be treated as such

One thing I get asked, time and time again, is "Why openSUSE?". The context isn't always the same "Why should I use it?", "Why should I contribute to openSUSE?", "Why do you use it?", "Why not use [some other distribution]?" but the question always boils down to "What's special about the openSUSE Project?"

It's a good question, and in the past, I think it's one which both the openSUSE Project as a whole and me as an individual contributor have struggled to satisfactorily answer. But I don't believe that difficulty in answering is due to a lack of good reasons, but an abundance of them, mixed in with a general tendency within our community to be very modest.

This post is my effort to address that, and highlight a few reasons why you, the reader, should contribute to the openSUSE Project and use the software we're developing

Reason 1: We're not (just) a Linux Distribution

Normally, the first thing people think of when they hear openSUSE is our 'Regular Release Distribution', such as openSUSE 13.2 which we released last year (Download it HERE)

The openSUSE Project however produces a whole bunch more.

For starters, we have not one, but technically TWO other Linux Distributions which we release and maintain

openSUSE Tumbleweed - our amazing rolling release which manages to give it's users stable, usable, Linux operating system, with constantly updating software.
Perfect not only for Developers, but anyone who wants the latest and greatest software, leading Linux experts like Greg Kroah-Hartman have stated rolling releases like Tumbleweed represent the 'future' of Linux distributions. I agree, and I think openSUSE's is the best (for reasons that will be made clear later in this post).
In my case it's replaced all but one of my Linux installations, which previously included non-openSUSE distributions. The last (my openSUSE 13.1 server) is likely to end up running Tumbleweed as soon as I have a weekend to move it over. I started small with Tumbleweed, having it on just one machine, but after a year, I just don't see the need for the 'old fashioned' releases any more in any of my use cases.
If you want to see it for yourself, Download it HERE

openSUSE Evergreen - this is a great community driven project to extend the lifecycle of select versions of our Regular Release beyond its usual "2 Releases + 2 Months" lifespan.
While technically not a 'true' separate Distribution in the purest sense of the word, it takes a herculean effort from our community to keep on patching the distribution as it gets older and older, but it allows us to offer a 'Long Duration Support' for a significant period after the regular lifespan.
The current openSUSE Evergreen release is openSUSE 13.1, which will be supported until at least November 2016 and can be Downloaded HERE

So, we're not just *a* Linux distribution but several, but wait, there's more!

The openSUSE Project hosts a whole pile of other software Projects, always Open Source, which we both use ourselves and encourage others to use and contribute to. These include:

Open Build Service - our build tool, building all of our packages as well as ones for SUSE Linux Enterprise, Arch, Debian, Fedora, Scientific Linux, RHEL, CentOS, Ubuntu, and more.

openQA - automated testing for *any* operating system, that can read the screen and control the test host the same way a user does.

YaST - The best/only comprehensive Linux system configuration & installation tool.

KIWI - Create Linux images for deployment on real hardware, virtualisation, and now even container systems like Docker. Kiwi is the engine that powers SUSE Studio

Snapper - Create, manage, and revert system snapshots. Roll-back without hassle when your system gets messed up (p.s. It's probably your fault it messed up, so Snapper can show you what changed between snapshots too)

OSEM - Open Source Event Management. Lots of Open Source projects have their own conferences and other events. We have our own tool for managing proposals, organising schedules, taking registrations, etc.

Trollolo - Command line tool for Trello with a brilliant name ;)

And many more, many of which can be found on our GitHub project page

Reason 2: We build and use the best tools

You might have noticed a common theme among many of the software projects listed above. We're a Project that cares a lot about using the right tool for the job.
In many cases that means using many of the same tools that other projects use, IRC, Git & GitHub, Forums, Mailing Lists, etc. We're not the kind of project that wants to invent new types of wheels just because we didn't invent the first one, but when the tools that are out there don't do the job well enough, we roll up our sleeves and try to produce the *best* tool for that job.

Obviously, we do this motivated by the need to scratch our own itches, but we also work very hard to produce tools which can, and should, be adopted by a much wider audience than just 'users and contributors to the openSUSE Distributions'.
This is probably best highlighted by talking about two of our best tools, the Open Build Service, and openQA.

Open Build Service - As already mentioned, our build tool builds all of the openSUSE Distributions packages, ISOs, Images, etc.
It also generates and hosts repositories for these packages.
It has always been built as a 'cross-distribution' tool, currently able to build packages for SUSE Linux Enterprise, Arch, Debian, Fedora, Scientific Linux, RHEL, CentOS, Ubuntu and more.
With both a web-based UI (you can see and use our installation HERE) and the osc command-line tool (Documentation HERE) the barrier to entry is pretty low. Even someone with no packaging experience can easily see the contents of any package in OBS, understand how it's put together, branch it (aka fork it to use the github equivalent term) into their own Project and get hacking away.
We also allow our openSUSE instance of OBS to be used by *anyone* without charge, so they can build and host their packages on our infrastructure for free (though at the very least, we'd like it very much if they made sure their openSUSE packages work really nice in return ;) )
OBS is already used by other companies and projects like VideoLAN, Dell, HipChat and ownCloud, but if you're in the business of making software for Linux, you really need to ask yourself the question "Why don't I use OBS to build my packages?"

openQA - Another jewel in our crown and somewhere I've been spending a lot of my time lately. openQA is a testing tool that lets you build tests for any operating system or application. Unlike practically every other testing tool I've looked at, openQA actually tests software the same way *users* do. It looks at the screen, and makes sure the user will see what you expect them to see. Then press the same keyboard and mouse buttons that a user would to work through the application. You can see it in action HERE
openSUSE use openQA extensively to build Tumbleweed. Proposed code for Tumbleweed is tested by openQA before it is accepted, and tested again AFTER it's accepted (to make sure it integrates well with everything else that has been recently merged).
This is how we're able to offer Tumbleweed as a 'stable' Rolling Release, because thanks to openQA we *know* the Distribution works *before* we put any updates in the hands of any users. If something does break, openQA stops the release, and users don't notice any problems, besides perhaps a slight delay in receiving new updates. On the (exceptionally rare) chance that something slips by openQA, that becomes a new test case, so we never make the same mistake twice.
openQA is also being used by SUSE for the testing of SUSE Linux Enterprise, and the Fedora Project have recently started using it. We'd love to see more distributions using it, and while playing around we've already managed to get openQA testing different operating systems like Android and even Windows :)

Reason 3: Engineering matters

Why all this focus on tools? Well for our community, engineering matters. Beyond the tools that we use to make this happen, we spend a lot of time, braincells, and discussions, getting under the hood and trying to find the best way to build our software.

This has led to openSUSE leading the way with lots of innovations in areas like package management. zypper and libsolv mean that, unlike other RPM-based Linux distributions 'dependency-hell' is a thing of the past for us, and we manage to stand toe to toe with Debian and Ubuntu, look at their package managers and go 'yeah, we can do that, and more'

We're also not interested in being another Open Source project taking everything from dozens of upstream projects and either stamping our logo on it and calling it our own, or changing a whole bunch of stuff and not giving stuff back.
We work hard with our upstream projects, be that the Kernel, GNOME, KDE, whatever, to give our feedback, get our patches merged, not just for their benefit, but our own - the more they accept, the less work we'll have to do maintain long winded openSUSE specific patch sets in the Future.

Reason 4: Community, Community, Community

The openSUSE Community is great, so great they deserve a blog post of this length on their own. But for the purposes of this post I want to summarise a few things.

First, a little bit about SUSE. We're sponsored by SUSE, and they make up an important part of the community, employing a good number of openSUSE contributors, and regularly contributing to the openSUSE Project in terms of code, staff, money.
In many respects their the 'Patron' of the openSUSE Project, having our back when we need it, but not overarching overlords controlling the project. The openSUSE Project is independent, free to set it's own direction.
SUSE sees themselves as peers in the community, taking part in the same way as everyone else, encouraging its engineers to be involved in discussions, and help set the direction of the openSUSE Project via code submissions, just like everyone else.
Open Source works best when there is freedom to innovate, that's the business openSUSE is in, and SUSE is a company that understands at it's Core - as their current recruitment campaign says "Open Source is in their Genes" (P.S. They're Hiring)

So if SUSE aren't 'in charge', who is? Well, the community is. Those who do, decide, and we want more people to help join us doing stuff! We're the kind of project that is very open to new contributors, and we try hard to maintain a very low barrier to entry.
We're not the sort of project with lots of hoops you need to jump through before you're allowed to do anything.
If you see something that needs fixing, talk to the people also working on it, fix it for/with them, and submit your contributions. This is true for code, the website, wiki, marketing stuff, anything, anywhere. We're not a project where you need permission before you can get involved.
We try and keep our processes lean but the ones we do have are on our Wiki, and in terms of getting together with existing contributors, they can most easily be found in our IRC Channels and on our Mailing Lists

If you're a user and need help actually using openSUSE but aren't ready to get involved with contributing to the project yet, then we have a great community of contributors helping support people via IRC and our Forums

But doesn't everyone doing everything everywhere lead to chaos? No, not really. The Open Source model works, with the few processes we have in place providing enough structure and safety that problems get caught and dealt with as part of a natural flow and learning process.
But, it's not utopia, from time to time of course stuff pops up, and that's why the openSUSE project has the Board.
Our job is to help keep this Project on the right track, keep people talking to each other, resolving conflicts, keeping everyone on the same page, and being the 'decision makers of last resort' if there is no one else able/suitable to make a decision that affects the Project.

This basically boils down to being the 'Universal Escalation Point' - If you have a problem, if no one else can help, and if you can find them (and that should be easy), maybe you should contact board@opensuse.org (LINK - ahh, nostalgia)

The structure of the Board is also a nice reflection of how the rest of our community is structured - of the 5 elected Board seats, no more than 2 can be occupied by people employed/controlled by the same organisation. This means no company (not even SUSE) can have a majority of the seats on the Board, ensuring it's healthy and balanced just like the rest of our community.

And finally, the openSUSE community is just a great bunch of people. I've been contributing to this project since it started, and it's dragged me in and is as much fun as ever. We have great, smart, funny, dedicated people, and it's a pleasure working with them both as part of my day job and hobby.

A big part of that is our regular openSUSE Conferences. 2011 was my first, and the wonderful combination of meeting people, great talks, and (lots of) openSUSE Beer, enabled me to jump from being a 'casual contributor' on the fringes to someone who really felt part of this great community.

We have another openSUSE Conference coming up in May, in Den Haag/Netherlands. There's still time to Submit talks (we'd love to see more from other Projects) or Register. If this post has got you interested in openSUSE, come along, it's a great opportunity to meet us :)

And remember our motto and default /etc/motd.. Have a Lot of Fun!

Intel Power Management on openSUSE Tumbleweed

Fri, 20 Feb 2015 00:10:01 +0100

In the past I've posted several articles on various tweaks to improve Power Management on Intel Sandy/Ivybridge hardware, based on my experiments with my Lenovo X220

With more recent releases of openSUSE, I've been experimenting with my old tweaks, and found that they NO LONGER help with power management - In fact, they seem to increase it

So, my advice at the moment - if you want a Linux OS that has good Power Management on a Lenovo X220 or similar laptop.. install openSUSE Tumbleweed, and don't change the default settings :)

HTH

Testing Fedora with openQA

Tue, 23 Dec 2014 14:43:00 +0100

I've been working a lot with openQA lately, openSUSE's great operating system testing tool, and I think some of what I've been getting up is kind of interesting.

This is likely to be the first of a series of blog posts about my crazy adventures with this awesome tool.

What is openQA?

openQA is a fully featured operating system testing tool.

It takes an operating system ISO or Disk Image, and using its Domain Specific Language (DSL) conducts a series of tests consisting of keyboard and mouse inputs while analysing the screen output for specific matches (called 'needles') to ensure the operating system is behaving as intended.

A typical, simple example of an openQA test for looks like this

#Header, doesn't normally need to be changed
use base "basetest";
use strict;
use testapi;

#run() subroutine, where the test code goes
sub run() {

#test functions
assert_screen "inst-bootmenu", 6;
send_key 'ret';

}

1;

This test is used to check a boot loader. The 'assert_screen' function in this case is looking for a matching 'needle' (screenshot) which has a tag named 'inst-bootmenu'. If it doesn't find a matching needle within the defined timeout (6 seconds) the test fails. If it finds a matching needle within 6 seconds, the test continues, and presses the return key with the 'send_key' function.

The results of these tests are provided in the form of logs, screenshots, and video recordings delivered over the openQA web interface. You can have a look at openSUSE's production instance at http://openqa.opensuse.org and an example of a single set of test results HERE.

Screenshots? Isn't it a pain in the arse maintaining the Needles?

Not at all. The openQA webUI contains a needle editor (example HERE) which lets testers see both the reference screenshots and the accompanying JSON file, and edit both with a WYSIWYG editor.

Select the areas of the UI you're interested in, click save, done. It takes seconds to update your needles to accept intended changes to a UI.

As needles are only looking for specific UI elements on the screen, well crafted needles can often allow regular UI changes to pass unmolested. If you're not interested in confirming the version number drawn on the screen, don't include the version number in your needles, and you'll have a version neutral needle - like in the example HERE.

The openQA web interface can automatically commit and (if you want) push your needles to a git repository (openSUSE's are HERE) making it really easy for testers/test developers to work together on keeping your needle collection up to date.

Is openQA just for openSUSE?

NO! While it's mainly used and contributed to by the openSUSE Project for testing Tumbleweed and the openSUSE Distribution, it's always been designed to be not only distribution-neutral (ie. it can test any Linux Distribution) but technically operating system-neutral - Linux, BSD, Windows, openQA doesn't care about what it's testing.

Yeah, right...prove it.

I haven't been working on openQA for a very long time. For a few weeks I've been working on new openQA tests for openSUSE and SUSE Linux Enterprise, but as we already have a huge collection of tests in our public git repository, a good number of my new tests are borrowing code and ideas from our existing test library.

So I got wondering, how hard is it to test a totally differing operating system, with a totally different installation workflow?

So, after reading the recent Register review of Fedora 21 that had a subtitle mentioning 'install woes', I decided to pick on our friends at the Fedora Project and downloaded a copy of Fedora 21 Workstation.

'Designing' tests for openQA is easy. I fired up the ISO in a VM and kept notes on which screens would make good needles and which keys to press. Each of the screens became an 'assert_screen' call in my tests, and each keypress became a 'send_key'.

NOTE: I could have used openQA's 'assert_and_click' function to check the screen for a needled area and click in the middle of it - it's a great for pressing buttons, but I decided to take a very keyboard centric approach.

In a few hours I had thrown together a basic set of tests, which you can get on GitHub

These tests successfully complete a full installation of Fedora 21 Workstation, as you can see from the openQA-produced Video I uploaded to YouTube

It wasn't perfect though, no QA tool is any good if it doesn't find bugs - luckily even these really simple tests were able to reliably reproduce a known issue in anaconda which apparently had been causing problems since October and hasn't yet been fixed.

Wanting to prove the tests and needles were generic enough that they could be reused for future testing, I've also run these against a recent Rawhide build.

Everything looks really promising, but a bug in Rawhide with Keyboard Shortcuts needs to be fixed before my tests can complete a full run.

Not bad for a few hours work if I say so myself, and I'd really like it if other people want to pick up where I've left off and extend these tests to provide more comprehensive coverage.

I'm interested, where can I find out more?

The main openQA website on GitHub is at http://os-autoinst.github.io/openQA/ and contains all the Documentation and Downloads you need to get started.

It takes about 1 hour to setup openQA on a basic openSUSE installation, and it doesn't have any crazy hardware requirements. If you can run KVM virtualisation, you can run openQA. All these Fedora tests have been run on a local instance of openQA on my X220 Laptop running openSUSE Tumbleweed.

I'd especially recommend the Getting Started Guide which explains a lot more about the fundamentals of openQA

For more help, the best place is the #opensuse-factory IRC channel on irc.freenode.org (where I can be found as ilmehtar and/or sysrich) or the opensuse-factory@opensuse.org mailinglist

Have a lot of fun!

Changing of the Guard

Thu, 17 Jul 2014 16:05:12 +0200

I recently received some bittersweet news, my good friend Vincent Untz is stepping down as Chairman of the openSUSE Board as a result of a happy personal event that I'm sure is going to keep him busy in the months and years ahead.

In addition the formal thanks as part of the official announcements, I'd like to add my own personal thanks to Vincent. I owe much to Vincent's help and support throughout the years, both technically as a maintainer of GNOME in openSUSE, and as an Board Member to the Project. I know this isn't goodbye, and look forward to still seeing Vincent around the Geeko world in the future.

As a result of Vincent's decision, the openSUSE Board requires a new Chairman. I'm excited and humbled to be able to announce that I have been appointed by SUSE to serve as the new Chairman of the openSUSE Board, effective from today.

When I started contributing to openSUSE in 2005, I never thought I could find myself in a position like this. I'm looking forward to doing the best I can to help keep openSUSE moving forward and become more recognised as the exceptional, wonderful, and successful open source project that it already is.

For anyone who doesn't know the governance structure of openSUSE, the Board is a group of six members, five who are elected by the community and a Chairperson who is appointed by SUSE. It's the Board's job to 'lead' the openSUSE Project, by providing guidance, governance and support to the rest of the project. As I was one of those elected Board members, the Board are currently discussing our options regarding my now vacant Board member seat, and we hope to be able to announce something soon.

I'm also very pleased to be able to be able to share that this October 18th-19th openSUSE will be having an openSUSE Summit Asia in Bejing!
Sunny and her team have put together a great website with all the information, please Check It Out!

There's also lots of very interesting developments happening around openSUSE Factory, which is progressing towards becoming a fully rolling release. You can download the latest snapshots HERE. And to provide feedback or learn more, you can join the conversation in our openSUSE Factory mailing list or in IRC at #opensuse-factory in irc.freenode.org

Have a lot of fun!

openSUSE Election Platform

Sun, 01 Dec 2013 14:17:02 +0100

This is a copy of my openSUSE Election Platform, that I'm putting here with the shameless intention of doing my best to ensure as many people read my thoughts as possible. The original can be found on our official wiki

Introduction and Biography

Hi! I'm Richard Brown, 31 years old, and since last month living in Nürnberg in Germany.

Originally from London, England, I used to joke that I had been steadily moving south and was on my way to becoming French, however it seems once I crossed the Channel I turned left, skipped right past France, and ended up in a land of good Beer and Bratwurst :)

Email: RBrownCCB at openSUSE.org
IRC: ilmehtar on irc.freenode.org
I'm @sysrich on twitter
My Blog is here

I currently work as a QA Engineer for SUSE, the wonderful Enterprise Linux company that also is the main sponsor of our openSUSE Project.

Previously I worked as a Systems Manager for City College Brighton and Hove, a large UK further education college where we use a lot of openSUSE, SUSE, and other FOSS technologies. I was also the UK Representative on the Advisory Board of the TTP Academic User Group, an usergroup for sysadmins working in Academia that deals with SUSE, Novell, and NetIQ products, with good links to the developers and management teams in these companies and their partners. The TTP is very supportive of both SUSE & the openSUSE Project, and was proud to have a track of sessions during our oSC 12 conference in Prague.

I've used SUSE/openSUSE since 2003, and have found myself getting more involved as time has gone on.

I'm part of the team which maintains GNOME in openSUSE, as well as lead maintainer for the 'Branding' packages in openSUSE, which leads me to work very closely with our great Artwork team. I also am heavily involved in Marketing, as well as the Advocates & Local Coordinators Programmes, where I was involved in implementing many of the changes transforming the former 'Ambassadors' programme into its new structure.

I'm an active Advocate for our project, who regularly attends conferences where I do my best to to both evangelise about our work, but also gather ideas and feedback on how we could improve. My session at oSC 12 "Using openSUSE for Real Work" really helped gather feedback which shaped my efforts to improve our project over the last year. At oSC13 I gave talks about the transformation of the Ambassador programme into the Local Coordinator and Advocates groups, as well as a talk about the work involved in Branding openSUSE. I also led the organisation of openSUSE's presence at the last two FOSDEM conferences.

I'm a keen tester who especially enjoys the crunch in the weeks leading up to releases, frantically testing and packaging patches to try and get bugs big and small squashed out so our releases are as polished as possible. I'm also very interested in Power Management, and have done a lot of work finding ways to optimise Power consumption on Intel laptop chipsets

I spend a lot time in our IRC channels, where I go by the handle ilmehtar (a very obscure Lord of the Rings/JRR Tolkien reference, I'll owe a prize to anyone who figures it out)

I have very broad interests which finds me often getting involved in both the technical and more 'community' aspects of our project.
I'm always keen to help out, try and resolve issues, come up with ideas, and then get my hands dirty trying to implement them.
I'm very happy learning new things and trying to help out in areas outside of my 'comfort zone', such as this year where I was given the opportunity to join the openSUSE Board - and after a year of hard work and interesting challenges, I'm back again hoping for your votes so I can continue the work I started this year.

Issues

Managing Change - In the last few weeks the openSUSE team from SUSE have initiated a number of discussions (1), (2), (3) proposing changes to our projects goals and practical changes to our 'Factory' development distribution. Over these next few weeks and (if I am elected) into the early months of next year I intend to work hard to ensure that the discussions progress well and we, together as a cohesive project, find an exciting way forward.

I do not expect this to be a painless process, and I expect there will be occasions where some people will want things to develop in one direction, while others pull for another. This is precisely the sort of issue the Board is there to deal with, and I'm prepared to put in the work to make sure everyone can contribute to shaping the future of our Project and its Distribution(s).

Improve Working Relationship with the openSUSE Team @ SUSE - The Board have a responsibility to 'Facilitate communication with all areas of the community' - ie. We need to make sure all the Teams that make up our project have strong communication and therefore are able to work effectively with each other.

This is important for every Team in our project, but especially so for the openSUSE Team at SUSE, because not only are they contributing to openSUSE to make it better for themselves as well as everyone else, but as paid employees of our primary sponsor (SUSE) they currently control some aspects of the project the 'wider community' have little or no involvement in. As has been mentioned on our mailing lists, over the last year, the working relationship between the openSUSE Team and the Board has become strained.

I have already begun working on this issue, and if I am elected, I intend to continue to work hard to improve the situation. I think the Board can do a better job of keeping the members of the openSUSE Team informed about the current needs, wants, desires and 'pain points' of our wider openSUSE community, and inversely, I think with improved communication between us, the Board will be in a better position to help the openSUSE Team at SUSE in their communications with the wider openSUSE community. We need to squash the feeling of 'us & them' which has started to creep into that narrative, we're all one Project and one Community, and it's down to the Board to keep it that way.

openSUSE Membership - I think the Project needs to start thinking about changing the way 'openSUSE Membership' works. With our growing maturity as an independent project, it's very important that we have a healthy way of making big decisions which impact the entire Project. I do not think our current system is wholly broken (it's certainly healthy enough for these elections), but I'm concerned about a number of areas, especially the growing number of 'former Members' who maintain full voting rights. If I am elected, I intend to begin the discussions to reform the openSUSE membership, focusing first on a suitable way of 'retiring' openSUSE members who are no longer involved in the project, and after that looking at other issues such as improving the selection/approval process and the 'perks' of becoming an openSUSE member.

Role of the board

Last year, I said that I wanted the board to become more approachable and more prepared to 'step in' and help resolve issues.
While I think we have been broadly successful in achieving this, there is always room for improvement, and I'm hoping will a fully staffed Board we'll be able to build on the improvements we've seen in these last 12 months.

I don't think leadership in a project like ours should be dictatorial. I feel the board should act as 'enablers', 'cheerleaders', 'champions', and troubleshooters. The board's job should be to help you (the community) by proactively identifying where the project is going wrong and help pull people together to steer it in the right direction.

The board should be the primary point of contact for contributors and users to raise issues that cant be addressed elsewhere, which is why our board needs to be active, visible, and accessible. I do not think enough of our community know the Board is there to address their issues, so I think we need to make a big push to advertise our purpose and availability.

The board should also be a source of new ideas and proposals for the community to consider, and should also encourage other contributors to field their own ideas and help keep the great green Geeko rolling forward

Why you should vote for me?

I've worked hard for you all as a Board member this year, and would like the opportunity to continue to do so.
SuSE/openSUSE is my first distribution and I've been a loyal user and contributor since 2003. I care a great deal about seeing our project continue and improve.
I've provided both technical and non-technical contributions to the project, and so have a strong working knowledge both the technical and community aspects of our project.
While I have my own opinions and will often argue passionately for them, I always listen to and consider the opinion of others, especially when they disagree with me. If I am elected I will continue to champion the desires of the community, not just my own agenda.
My experience outside of openSUSE, especially as a board member of the TTP, give me skills and knowledge I think will help me here
I enjoy learning and getting involved in new things, and see working on the board as an opportunity to get help out in parts of the project that I'd probably otherwise not see.

Aims/Goals

If elected I will strive to

Continue the work I've started over the last year as a Board Member
Investigate ways to better advertise the work the Board is doing for the project
Be involved in the recently started discussions about the Future of our project to find a viable plan for our Project going forward, especially one that addresses the needs of both our users desiring stability and a moderate pace of change, and for those whom using the latest and greatest stable versions is more important.
Listen to the our users and contributors as much as possible, to figure out what you want the Board to be doing

Endorsements

Michal '-miska-' Hrusecky
I know Richard for few years and he always cared a lot about openSUSE. He is active on our channels and whenever he sees some troubles, he steps up and do his best to help the project. Not only technically but also on ''boring'' organization tasks. I can imagine, that being part of the board is a hard work although not that appreciated and visible to the outside. But nevertheless it is important for the project and I believe that Richard will continue to represent us very well. What is also great about Richard as board candidate is that he is not a classical politician - he doesn't do long speeches without content and he prefers to cut to the chase.