As I have previously attempted several times in the past, I am (finally) very close to switch to OpenBSD, a more stable and reliable operating system that I like. Before starting to make the actual change on both personal and work computer, I started testing some of the tools I’m currently using, and understand what are the expectations.

In general I didn’t encounter issues, or when I did, I found the answers in the documentation (which is really great), or various forums. I didn’t find however any questions regarding Proxy Minions on OpenBSD which is why I thought it might be helpful to share my experience.

Installation and Startup

With these said, I started playing with Salt, and it was simple and straight forward. First step - install Salt: pkg_add salt. This will bring several ports for Python futures, ZeroMQ, or Tornado which are needed for Salt.

After configuring the pillar_roots in the /etc/salt/master config file for the Master, I started up the master process using rcctl:

# rcctl start salt_master
salt_master(ok)

Configuring the /etc/salt/minion config file so the Minion connects to the local Salt Master (i.e., master: localhost), the Minion service starts successfully:

# rcctl start salt_minion
salt_minion(ok)

And we can verify this from the CLI:

# salt-call grains.get os
local:
    OpenBSD
# salt-call grains.get osrelease
local:
    6.2

Nothing different so far.

Starting up the Proxy Minions

The Salt package for OpenBSD comes with the rc file for salt-proxy as well, /etc/rc.d/salt_proxy:

#!/bin/sh
#
# $OpenBSD: salt_proxy.rc,v 1.1 2015/11/14 08:30:07 ajacoutot Exp $

daemon="/usr/local/bin/salt-proxy -d"

. /etc/rc.d/rc.subr

pexp="/usr/local/bin/python2.7 ${daemon}${daemon_flags:+ ${daemon_flags}}"
rc_reload=NO

rc_cmd $1

While typically you run a single regular Minion on a given machine, it is very like that there are multiple Proxy processes. Additionally, the default Salt rc file has the following configuration for the salt-proxy daemon:

daemon="/usr/local/bin/salt-proxy -d"

But this is not enough to start a proxy, as the proxyid argument is mandatory:

# salt-proxy -d
Usage: salt-proxy [options]

salt-proxy: error: salt-proxy requires --proxyid

With these said, we need to send somehow the proxyid argument. Reading the rcctl(8) manual, it explains what to do in cases like that:

The recommended way to run a second copy of a given daemon for a different purpose is to create a symbolic link to its rc.d(8) control script:

# ln -s /etc/rc.d/snmpd /etc/rc.d/snmpd6
# rcctl set snmpd6 status on 
# rcctl set snmpd6 flags -D addr=2001:db8::1234 
# rcctl start snmpd6

Our needs are very similar in this case, so I did the following in order to configure the service for the Proxy having the Minion ID dummy:

# ln -s /etc/rc.d/salt_proxy /etc/rc.d/salt_proxy_dummy
# rcctl set salt_proxy_dummy status on
# rcctl set salt_proxy_dummy flags --proxyid dummy

After starting the service and accepting the key, the Proxy is up and running:

# rcctl start salt_proxy_dummy
salt_proxy_dummy(ok)

# salt dummy test.ping
dummy:
    True

Starting many Proxy Minions

I have managed to startup a Proxy Minion, but what about many? Executing the three commands above for each and every device is tedious and cannot scale very well. I thus have figured the following way:

  1. Have a separate rc file per Proxy, each having the daemon instruction explicitly specifying its Minion ID:

    /etc/rc.d/salt_proxy_test (excerpt):

    daemon="/usr/local/bin/salt-proxy -d --proxyid test"

  2. Start the service (using the regular Minion that controls the machine where the Proxy processes are running):

    # salt-call service.start salt_proxy_test
local:
    True

    And the test Proxy Minion is then up (after accepting the key, i.e,, salt-key -a test):

    # salt test system.get_system_time
test:
    09:37:11 PM

Extending the same to a (very) large number of Proxy Minions, you can easily manage the rc files and start the services using a Salt State executed on the regular Minion:

  1. Using the file.managed State function to generate the contents of the rc file for each Proxy, with its own Minion ID.
  2. Using the service.running State function start the service.

These two steps would suffice to start an arbitrary number of Proxy Minions, and the command executed will always be the same regardless how many processes you aim to manage.

Conclusions

I am still a novice when it comes to OpenBSD, I have plenty to learn, but it looks like the transition will be much smoother than I expected. I am already looking forward to the handover, and - most importantly - I will no longer be using systemd. :-)