Usually your AppArmor profile would look something like this:

#include <tunables/global>

/usr/lib/colord {
  ...
}

Now if we check if our profile is actually used:

$ ps axZ | grep '^/usr/lib/colord'
/usr/lib/colord (enforce)  4466  ?  Ssl  0:00 /usr/lib/colord

The Z parameter makes ps print the AppArmor profile name, or in the case of selinux the context of the program. /usr/lib/colord (enforce) tells us what AppArmor profile is used and in which mode it is. Another option you can see there is complain. With long binary paths this can become ugly very quickly.

I haven’t been using apache for a few years now … oh wow maybe like 15 years now.

There was one feature I really liked with apache and apparmor though … mod_changehat. The module allows me to assign different apparmor scopes to apache scopes. So you could limit that your wordpress vhost can not access the files of your nextcloud vhost even though they are running in the same apache.

So I am working on a Nextcloud package at the moment. Something that does not have such brain dead default permissions as the docs give you. To give all users who need access to the files, I used ACLs. This worked quite fine. Until during one update … suddenly all my files got executable permissions.

I ran rpm --setperms nextcloud to reset the permissions of all files and then I reran my nextcloud-fix-permissions. Nothing. All was good again. During the next update … broken again. I fixed the permissions manually by removing the x bit and then rerunning my script … bugged again. Ok time to dig.

When you are hear 2 coworkers complaining about breaking each other’s changes to a package, you wonder what is going on. And this time it turns out they were complaining about a rubygem package. So yeah time to find a nice solution to this problem finally.

The conflict

rubygem-annotate and gd. Both provide a /usr/bin/annotate. In the case of our gem based packaging this is of course only a symlink handled by update-alternative. Though the code handling this is split over 2 places - the script that handles installing each gem and our template for the subpackages.

We already mentioned Instantiated Services a few times. However, there is one question we did not yet cover:

How to hook up those instances with our package manager

For a normal service file this is pretty easy. Such a service can be handled as follow in the spec file:

%pre
%service_add_pre superduper.service

%post
%service_add_post superduper.service

%preun
%service_del_preun superduper.service

%postun
%service_del_postun superduper.service

That is it. It will do all the things we want.

After all the fun we had in part 1 of our FreeIPA + DNS series, we now come to a new chapter.

During the move of openSUSE to Let’s Encrypt we used the excellent tool from ssllabs to verify each server after we changed the certificate. One of our coworkers noted “Hey, why don’t you have a CAA record. It would give you an even better score”. CAA records allow the domain owner to specify which certificate authorities are allowed to create certificates for this domain. Which seems to be a nice benefit for little work. For a longer explanation see this blog post from Qualys.

Requests are one of the staples for collaboration in the OBS. You can review via the webui or with OSC.

WebUI

Lets take the request listing for openSUSE:Factory. Your normal workflow will probably end up as

1. middle mouse click on the little magnifying glass icon on the right.
2. review the request in a new tab
3. close the new tab
4. go back step 1

My issues with the WebUI

1. no advancing to the next request in my current list.
2. I have to manually unfold/fold many diff chunks for a proper review.
3. In the latest version of the WebUI: “We truncated the diff of some files because they were too big. If you want to see the full diff for every file, click here.” But even then I have to unfold every change myself again.

OSC - The normal way

1. one terminal: osc rq list -t submit -s new openSUSE:Factory
2. 2nd terminal: osc rq show -d ID - the ID is taken from the first listing.
3. 2nd or in worst case 3rd terminal: osc rq youraction ID
4. go back to step 2

My issues

1. all manually copy pasting of IDs

OSC interactive mode

My config:

One step at a time. Today: Requires

You might have seen that we package rails apps for a while now. We have discourse, gitlab-ce, errbit and our own open build service. I probably forgot an app or 2 here. Anyway if you look at all the spec files e.g. this one. You notice we have to specify the Requires manually.

BuildRequires:  %{rubygem rails:5 >= 5.1}
Requires:       %{rubygem rails:5 >= 5.1}

This comes with a few problems actually.

Restic had been on my watch list for a while, but i never really got around to play with it.

After Jan-Piet Mens blogged about it [1, 2], I thought it was finally time to give it a go. Of course this means, first we need to package it.

This is done now. You can find the packages in home:darix:restic. After reading the first blog post I did restic and rest-server. Happy camper I was until i noticed to next post. Minio was another item on my “Lets play with that” list. So one stone, two birds. Added 2 packages to my collection, because you know just packaging the server without the client is a no go.

I have been a haproxy user for quite a few years now. Even using snapshots in production for a very long time. Especially after support was added to terminate SSL connections directly in haproxy. Getting rid of stunnel was so nice.

For a very long time i was doing really well with this setup. But over time more and more services were put behind haproxy and the connections/s and the total amount of connections went up. We started to see some performance issues. Which at first sounds weird … if you look at the benchmarks on the haproxy website they can do thousands if not hundred thousands of connections per seconds.