The Plan

+---------+    +------------------------+    +---------------------------+
| FreeIPA | -> | upstream hidden master | -> | public facing dns servers |
+---------+    +------------------------+    +---------------------------+

Sounds simple enough right? Well …

The Fun

Let’s get right too it … FreeIPA only sends out notifications to the NS records listed in the zone. But our hidden master is not reachable from the outside and should not be listed as an NS.

‘But bind has “also-notify” just use that.’ you might say now. Which is correct. So a quick check on the ldap scheme reveals there is no setting in the LDAP tree for it. Ok… the nice solution is dead.

As i regularly look it up from my mailbox. lets post it here.

osc co yourproject/yourpackage
cd yourproject/yourpackage
quilt setup -v *spec
cd yourpackage-*/
quilt push -a # apply old patches
quilt new yourpackage-version_fixbuild.patch
quilt edit src/foo.c
quilt refresh

foo-fixbuild.patch will automatically be created in the parent dir. if you work on a package which doesnt have a patch yet. you have to remember to copy the patch from the patch directory to your package directory.

A very simple frontend/backend definition in haproxy can look like this:

frontend http
  bind 0.0.0.0:80    tfo
  bind 0.0.0.0:443   tfo ssl npn http/1.1,http/1.0 no-sslv3 crt /etc/ssl/services/
  default_backend somebackend

backend somebackend
  option forwardfor
  option httpchk HEAD /check.txt HTTP/1.1\r\nHost:\ somehost
  server somebackend1 172.16.0.1 check port 80

$ curl -I http://haproxy.example.com/

Works.

$ curl -I https://haproxy.example.com/

Does not work.

The log snippet also looks ok:

http~ somebackend/somebackend1 0/3004/-1/-1/3005 503 3090 - - SC-- 529/126/0/0/3 0/0 "GET / HTTP/1.1"

But why does it report 503?

By default the epmd on (open)SUSE only listens on 127.0.0.1. Which in itself is a sane default policy. We don’t expose any services directly to everyone just because we install and run them. But if you want to cluster erlang services you need it to listen on more addresses.

$ export EDITOR=vim
$ systemctl edit epmd.socket

Add the following content:

[Socket]
# unset all ports defined in the global file, in our case this is 127.0.0.1:4369
ListenStream=
# add our new ports
ListenStream=[::]:4369

Then run:

If you ever discussed packaging in person with me, you might have noticed i normally don’t call “osc build” but a little shell thingie. The reason is i don’t want to maintain a long command line all the time.

So in my shell RC file i have the following:

osc_build() {
  pkg_dir=$1
  shift
  repo=$1
  shift
  osc build -x vim -k ../rpms/$pkg_dir -p ../rpms/$pkg_dir $repo x86_64 $@
}

ob-15.1() {
  osc_build 15.1 openSUSE_Leap_15.1 $@
}

ob-15.2() {
  osc_build 15.0 openSUSE_Leap_15.0 $@
}

ob-tw() {
  osc_build tw openSUSE_Tumbleweed $@
}
ob-twf() {
  osc_build tw openSUSE_Factory $@
}

-x vim

So i can edit inside the build environment. There is actually really a nice helper to get into the build env:

FFI is a method to interface with native libraries, which is becoming more and more popular in many scripting languages. Unlike with native extensions though, we have nothing that links the shared library. As such our requires generator for shared libraries doesn’t kick in and we get no requires on the shared library package.

To make matters worse with the shared library policy the soversion is dependent on against which distro you build against.

Disclaimer: I am aware that python does not allow easy installation of 2 libraries in parallel. It is just an example.

Let’s say you have an upstream requirement "needs pyfoo >= 1.6.0 but smaller than 2". Sounds easy right? Our naive solution will be:

Requires: python-pyfoo >= 1.6.0
Requires: python-pyfoo < 2

so far … so good. If your repository has only one version of pyfoo available we will probably get the package you want. now lets say we have more than one version available.

Since we have staging for Factory/Tumbleweed, it became surprisingly stable. Major breakages at least for core packages are really rare now. But even for leaf packages it is not a common sight.

One thing was still annoying: for upgrading you should use zypper dist-upgrade or short zypper dup normally. zypper dup will upgrade all the packages to the latest version it finds but also downgrade/uninstall packages, if required. Something a zypper up will not do. This is all fine when you only use the core distribution repositories. If you start using e.g. packman or any other repository from the build service, zypper did switch around the package to the distribution package and a few days later back to the OBS based repository. Depending on what was newer. It is allowed to do that because zypper dup allows also vendor changes.

After I was asked again today how to properly patch a rubygems package, here is a quick how to.

First things first we branch the package.

darix@tengu ~/osc/tmp % osc bco devel:languages:ruby:extensions/rubygem-net-ssh-session
A    home:darix:branches:devel:languages:ruby:extensions
A    home:darix:branches:devel:languages:ruby:extensions/rubygem-net-ssh-session
A    home:darix:branches:devel:languages:ruby:extensions/rubygem-net-ssh-session/net-ssh-session-0.1.6.gem
A    home:darix:branches:devel:languages:ruby:extensions/rubygem-net-ssh-session/rubygem-net-ssh-session.changes
A    home:darix:branches:devel:languages:ruby:extensions/rubygem-net-ssh-session/rubygem-net-ssh-session.spec
At revision 9edd872bc9121e1c68a71d057dfa607f.
Note: You can use "osc delete" or "osc submitpac" when done.

darix@tengu ~/osc/tmp % cd home:darix:branches:devel:languages:ruby:extensions/rubygem-net-ssh-session

So far nothing unexpected a gem file and spec+changes.

This is just a quick post but imho still pretty neat. If you are a postgresql user you probably know about the commands with \ to inspect your database server e.g. .

mirrorbrain=> \l mirro*
                                  List of databases
    Name     |    Owner    | Encoding |   Collate   |    Ctype    | Access privileges 
-------------+-------------+----------+-------------+-------------+-------------------
 mirrorbrain | mirrorbrain | UTF8     | en_US.UTF-8 | en_US.UTF-8 | 
(1 row)

mirrorbrain=> \dt
           List of relations
 Schema |  Name   | Type  |    Owner    
--------+---------+-------+-------------
 public | country | table | mirrorbrain
 public | file    | table | mirrorbrain
 public | hash    | table | mirrorbrain
 public | marker  | table | mirrorbrain
 public | mirror  | table | mirrorbrain
 public | pfx2asn | table | mirrorbrain
 public | region  | table | mirrorbrain
 public | server  | table | mirrorbrain
 public | version | table | mirrorbrain
(9 rows)

mirrorbrain=> 

So far … nothing new … right?