The first report on LLD porting

January 18, 2019 posted by Kamil Rytarowski

LLD is the link editor (linker) component of Clang toolchain. Its main advantage over GNU ld is much lower memory footprint, and linking speed. It is of specific interest to me since currently 8 GiB of memory are insufficient to link LLVM statically (which is the upstream default).

The first goal of LLD porting is to ensure that LLD can produce working NetBSD executables, and be used to build LLVM itself. Then, it is desirable to look into trying to build additional NetBSD components, and eventually into replacing /usr/bin/ld entirely with lld.

In this report, I would like to shortly summarize the issues I have found so far trying to use LLD on NetBSD.

[Read More] [0 comments]


The process of upstreaming support to LLVM sanitizers has been finalized

January 03, 2019 posted by Kamil Rytarowski

I've finished the process of upstreaming patches to LLVM sanitizers (almost 2000LOC of local code) and submitted to upstream new improvements for the NetBSD support. Today out of the box (in unpatched version) we have support for a variety of compiler-rt LLVM features: ASan (finds unauthorized memory access), UBSan (finds unspecified code semantics), TSan (finds threading bugs), MSan (finds uninitialized memory use), SafeStack (double stack hardening), Profile (code coverage), XRay (dynamic code tracing); while other ones such as Scudo (hardened allocator) or DFSan (generic data flow sanitizer) are not far away from completeness.

The NetBSD support is no longer visibly lacking behind Linux in sanitizers, although there are still failing tests on NetBSD that are not observed on Linux. On the other hand there are features working on NetBSD that are not functional on Linux, like sanitizing programs during early initialization process of OS (this is caused by /proc dependency on Linux that is mounted by startup programs, while NetBSD relies on sysctl(3) interfaces that is always available).[Read More] [2 comments]


NetBSD entering 2019 with more complete LLVM support

December 30, 2018 posted by Kamil Rytarowski

Prepared by Michał Górny (mgorny AT

I'm recently helping the NetBSD developers to improve the support for this operating system in various LLVM components. As you can read in my previous report, I've been focusing on fixing build and test failures for the purpose of improving the buildbot coverage.

Previously, I've resolved test failures in LLVM, Clang, LLD, libunwind, openmp and partially libc++. During the remainder of the month, I've been working on the remaining libc++ test failures, improving the NetBSD clang driver and helping Kamil Rytarowski with compiler-rt.

[Read More] [0 comments]


The NetBSD support update before the LLVM-8.0 branching point

December 16, 2018 posted by Kamil Rytarowski

Prepared by Michał Górny (mgorny AT

I'm recently helping the NetBSD developers to improve the support for this operating system in various LLVM components. My first task in this endeavor was to fix build and test issues in as many LLVM projects as timely possible, and get them all covered by the NetBSD LLVM buildbot.

Including more projects in the continuous integration builds is important as it provides the means to timely catch regressions and new issues in NetBSD support. It is not only beneficial because it lets us find offending commits easily but also because it makes other LLVM developers aware of NetBSD porting issues, and increases the chances that the patch authors will fix their mistakes themselves.

[Read More] [0 comments]


Reducing the delta with upstream version of sanitizers

December 02, 2018 posted by Kamil Rytarowski

I've been actively working on reducing the delta with the local copy of sanitizers with upstream LLVM sources. Their diff has been reduced to less than 2000 Lines Of Code. I've pushed to review almost all of the local code and I'm working on addressing comments from upstream developers. [Read More] [0 comments]


NetBSD LLVM Sanitizers in The Bay Area

November 01, 2018 posted by Kamil Rytarowski

I have presented the state of NetBSD sanitizers during two conferences in the San Francisco Bay Area: Google Summer of Code Mentor Summit (Mountain View) and MeetBSDCa (Santa Clara, Intel Campus SC12). I've also made progress in upstreaming of our local patches to LLVM sanitizers and introducing generic NetBSD enhancements there.[Read More] [1 comment]


EuroBSDCon 2018 and NetBSD sanitizers

October 01, 2018 posted by Kamil Rytarowski

I presented the state of NetBSD sanitizers during EuroBSDCon 2018 held in Bucharest, Romania.

I gave two talks, one covered userland sanitizers and the other one kernel sanitizers. Unfortunately video recordings from the conference are not available, but I've uploaded my slides online:

[Read More] [0 comments]


EuroBSDCon 2018 travel report and obligatory pics

October 01, 2018 posted by Maya Rashish

This was my first big BSD conference. We also planned - planned might be a big word - thought about doing a devsummit on Friday. Since the people who were in charge of that had a change of plans, I was sure it'd go horribly wrong.

The day before the devsummit and still in the wrong country, I mentioned the hours and venue on the wiki, and booked a reservation for a restaurant.

It turns out that everything was totally fine, and since the devsummit was at the conference venue (that was having tutorials that day), they even had signs pointing at the room we were given. Thanks EuroBSDCon conference organizers!

At the devsummit, we spent some time hacking. A few people came with "travel laptops" without access to anything, like Riastradh, so I gave him access to my own laptop. This didn't hold very long and I kinda forgot about it, but for a few moments he had access to a NetBSD source tree and an 8 thread, 16GB RAM machine with which to build things.

We had a short introduction and I suggested we take some pictures, so here's the ones we got. A few people were concerned about privacy, so they're not pictured. We had small team to hold the camera :-)

At the actual conference days, I stayed at the speaker hotel with the other speakers. I've attempted to make conversation with some visibly FreeBSD/OpenBSD people, but didn't have plans to talk about anything, so there was a lot of just following people silently.
Perhaps for the next conference I'll prepare a list of questions to random BSD people and then very obviously grab a piece of paper and ask, "what was...", read a bit from it, and say, "your latest kernel panic?", I'm sure it'll be a great conversation starter.

At the conference itself, was pretty cool to have folks like Kirk McKusick give first person accounts of some past events (Kirk gave a talk about governance at FreeBSD), or the second keynote by Ron Broersma.

My own talk was hastily prepared, it was difficult to bring the topic together into a coherent talk. Nevertheless, I managed to talk about stuff for a while 40 minutes, though usually I skip over so many details that I have trouble putting together a sufficiently long talk.

I mentioned some of my coolest bugs to solve (I should probably make a separate article about some!). A few people asked for the slides after the talk, so I guess it wasn't totally incoherent.

It was really fun to meet some of my favourite NetBSD people. I got to show off my now fairly well working laptop (it took a lot of work by all of us!).

After the conference I came back with a conference cold, and it took a few days to recover from it. Hopefully I didn't infect too many people on the way back.



Using for Let's Encrypt certificates on servers

September 17, 2018 posted by S.P.Zeidler

Peter Wemm's writeup about using for served as inspiration, but I chose to do a few things different:
  • using DNS alias mode with sub-domains dedicated to ACME verification
  • delegating the sub-domains to the servers where the certificate will be needed
  • using bind on the servers where the certificate will be needed (where it was running as resolver already anyway)
  • using dns_nsupdate (i.e. dynamic DNS) to add the challenge to the ACME subzone.
Appropriately restricted, that gives the following addition to named.conf on the target server (with an update key named acme-ddns):
options {
        allow-update { localhost; };

zone "" {
        type master;
        file "acme/";
        update-policy {
                grant acme-ddns name TXT;
And last but not least, deployment of certificates via make, i.e. completely independent of

Due to all of the above, does not need to tentacle about in the filesystem and can run as a plain user in a chroot. It's not a tiny chroot, though (20M), since needs a bunch of common shell tools:

  • awk basename cat chmod cp curl cut date egrep/grep head mkdir mktemp mv nsupdate od openssl printf readlink rm sed sh sleep stat tail touch tr uname, and their shared libs, /libexec/ld.elf_so and /usr/libexec/ld.elf_so;
  • under the chroot /etc a resolv.conf, the CA cert for Let's Encrypt (mozilla-rootcert-60.pem) and to make openssl complain less an empty openssl.cnf
  • and in the chroot /dev: null, random and urandom.

I call both the --cron job and the certificate deployment make from daily.local, which adds the output to the daily mail and makes it easy to keep an eye on things. [0 comments]


Finishing leftover tasks from Google Summer of Code

September 03, 2018 posted by Kamil Rytarowski

Over the past month, I was coordinating and coding the remaining post-GSoC tasks. This mostly covers work around honggfuzz and sanitizers.[Read More] [0 comments]


NetBSD 7.2 released

September 03, 2018 posted by Martin Husemann

The NetBSD 7.2 release is available now.

[Read More] [0 comments]


GSoC 2018 Reports: Configuration files versioning in pkgsrc, part 4: configuration deployment, pkgtools and future improvements

August 26, 2018 posted by Thomas Klausner

As introduced in GSoC 2018 Reports: Configuration files versioning in pkgsrc, part 2: remote repositories (git and CVS) pkgsrc supports using some version control system repositories to search for site-specific configuration for packages being installed, and deploys it on the system.

Configuration deployment: intro to VCSCONFPULL

Support for configuration tracking is in scripts, pkginstall scripts, that get built into binary packages and are run by pkg_add upon installation. The idea behind the proposal suggested that users of the new feature should be able to store revisions of their installed configuration files, and of package-provided default, both in local or remote repositories. With this capability in place, it doesn't take much to make the scripts "pull" configuration from a VCS repository at installation time.

That's what setting VCSCONFPULL=yes in pkg_install.conf after having enabled VCSTRACK_CONF does: You are free to use official, third party prebuilt packages that have no customization in them, enable these options, and point pkgsrc to a private conf repository. If it contains custom configuration for the software you are installing, an attempt will be made to use it and install it on your system. If it fails, pkginstall will fall back to using the defaults that come inside the package. RC scripts are always deployed from the binary package, if existing and PKG_RCD_SCRIPTS=yes in pkg_install.conf or the environment.

This will be part of packages, not a separate solution like configuration management tools. It doesn't support running scripts on the target system to customize the installation, it doesn't come with its domain-specific language, it won't run as a daemon or require remote logins to work. It's quite limited in scope, but you can define a ROLE for your system in pkg_install.conf or in the environment, and pkgsrc will look for configuration you or your organization crafted for such a role (e.g., public, standalone webserver vs reverse proxy or node in a database cluster)

Configuration files should be put in branches named according to a specific convention, their paths relative to the repository is implied to be their absolute path, prepending a "/", on the target system.

Branch names define the package name they contain configuration for, the role, the version of the package the configuration is made for and a range of compatible software releases that should work with such configuration options, a best match is attemped inside of compatible ranges to the nearest software release, and roles can be undefined (both on the branch, to make it apt for any system, or on the target to ignore roles specified in branch names where they don't matter). More on that later, now some practical examples using git:

Set up a remote repository on some machine, if you are not using a public facing service or private repositories in third party services:

$ id                                                                                                          
uid=1001(vcs) gid=1001(vcs) groups=1001(vcs)
$ mkdir confpullexample.git                                                                                   
$ cd confpullexample.git/                                                                                     
$ git --bare init                                                                                             
Initialized empty Git repository in /usr/home/vcs/confpullexample.git/                                        

Check for correct settings on the target machine: (a REMOTEVCS URI is required, the VCSDIR is NOT used)

pkghost# cat /usr/pkg/etc/pkg_install.conf

Do no reuse repositories that track existing configuration files from packages, set a new one here. It will be structured differently, with branches that can specialize between them and yet contain configuration files common to each one (from master/trunk/...). Some technicalities are needed before making practical examples. I will now cheat and cite direcly the comment in mk/pkginstall/versioning:

The remote configuration repository should contain branches named according to the following convention: category_pkgName_pkgVersion_compatRangeStart_compatRangeEnd_systemRole an optional field may exist that explicitates part of the system hostname category_pkgName_pkgVersion_compatRangeStart_compatRangeEnd_systemRole_hostname .

the branch should contain needed configuration files. Their path relative to the repository is then prepended with a "/" and files force copied to the system and chmod 0600 executed on them. Permission handling and removal upon package uninstallation are not supported.

The branch to be used, among the available ones, is chosen this way: branches named according to the convention that provide configuration for category/packageName are filtered from the VCS output; then, all branches whose ranges are compatible with the version of the package being installed are selected. The upper bound of the range is excluded as a compatible release if using sequence based identifiers. If system role is set through the ROLE environment variable, and it's different from "any", and branches exists whose role is different from "any", then their role gets compared with the one defined on the system or in pkg_add config. The last part of the branch name is optional and, if present, is compared character by character with the system hostname, finally selecting the branches that best match it. As an example, a branch named mail_postfix_3.3.0_3.0.0_3.3.20_mailrelay_ams will match with system hostname amsterdam09. A system with its ROLE unspecified or set to ANY will select branches independently of the role they are created for, scoring and using the one with the best matching optional hostname and/or nearest to the target release as explained below:

The checks now further refine the candidates: if a branch pkgVersion exactly corresponds with the version of the package being installed, that branch gets selected, otherwise the procedure uses the one which is closest to the package version being installed. Non-numerical values in package versions are accounted for when checking for an exact match, and are otherwise ignored. Only integer versions and dot-separated sequence based identifiers are understood when checking for compatible software ranges and for the closest branch, if no branch exactly matches with the package version being installed. Dates are handled provided they follow the ISO 8601 scheme: YYYY-MM-DD, YYYYMMDD

Let's suppose that an hypothetical team uses a common ssh configuration, on all systems, to disable root and passwordless logins, and enable logins from users in a specific group.

the main/master branch of the repository will then contain one custom object, etc/ssh/sshd_config that will get included when branching from there (specific removals are always possible).

$ whoami
$ file $HOME/.ssh/id_rsa
/home/devuser/.ssh/id_rsa: PEM RSA private key
$ pwd
$ git clone ssh://vcs@ .
Cloning into '.'...
The authenticity of host ' (' can't be established.
ECDSA key fingerprint is SHA256:RMkiZlYqNIKlgDQUvhFBXLUpW2qcLd1nuEi4NaROkLg.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '' (ECDSA) to the list of known hosts.
warning: You appear to have cloned an empty repository.
$ mkdir -p etc/ssh
$ cat /etc/ssh/sshd_config > etc/ssh/sshd_config

customize it as needed, then

$ echo "PermitEmptyPasswords no" >> $HOME/sim/etc/ssh/sshd_config
$ echo "PermitRootLogin no" >> $HOME/sim/etc/ssh/sshd_config
$ echo "AllowGroup ops" >> $HOME/sim/etc/ssh/sshd_config

and load it in the repo:

$ git add etc/ssh/sshd_config
$ git commit -m "add common sshd_config to master"
[master (root-commit) ec91ffc] add common sshd_config to master
 1 file changed, 134 insertions(+)
 create mode 100644 etc/ssh/sshd_config
$ git push
Counting objects: 5, done.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (5/5), 1.89 KiB | 966.00 KiB/s, done.
Total 5 (delta 0), reused 0 (delta 0)
To ssh://
 * [new branch]      master -> master

With respect to this example, two different nginx configuration sets will exist, one for reverse proxies (role reverseproxy) and one for standalone webservers (role webserver). A standalone webserver will also install a default database configuration file, which will be customized for clustered postgresql instances (roles dbcluster-master and dbcluster-replicas).

Furthermore, nodes part of the same cluster will have hostnames the likes of toontowndc-node03 so that branches ending with _toontowndc-node will match and have configuration files with the addresses of nodes in the same cluster deployed.

The branch net_net-snmp_5.7.3_5.2_6_any will work on all systems you want to monitor via snmpd independently of their defined role, provided the version of net-snmp being installed is >= 5.2 and < 6

In order to keep the tutorial short, I will only show how to deploy configuration for postgresql.

I'll start with a generic configuration file, for the role webserver; the branch databases_postgresql10_10.4nb1_10.0_11_default may be created to contain default configuration from the package (the role isn't any, so it will not be accidentally selected on systems that define a role), then branch it into the specialized roles webserver, dbcluster-master, dbcluster-deplicas.

A master-node address specific to each cluster site will be included in recovery.conf by specializing the branch ...dbcluster-replicas to branches specific for earch location, e.g., dbcluster-replicas_toontowndc that will be deployed on db nodes in the "Toontown" site.

NOTE that files from the branch will get copied unconditionally on the system, replacing existing files or files coming with the binary package, even if they are not installed to location/handled by the +FILES script

This means that it's possible to write configuration files to ${pgsql_home}/data, by default /usr/pkg/pgsql/data/, where the rc.d script usually sets postgresql to look into.

$ pwd
$ mkdir -p sim/usr/pkg/pgsql/data
$ cd sim
$ ls -a
.    ..   .git etc  usr
$ git checkout -b databases_postgresql10_10.4nb1_10.0_11_default
Switched to a new branch 'databases_postgresql10_10.4nb1_10.0_11_default'
$ ls
etc usr
$ cp /home/devuser/postgresql.conf.sample usr/pkg/pgsql/data/postgresql.conf                                  
$ cp /home/devuser/pg_hba.conf.sample usr/pkg/pgsql/data/pg_hba.conf                                          
$ vi usr/pkg/pgsql/data/pg_hba.conf 
$ tail -n 23 usr/pkg/pgsql/data/pg_hba.conf   

# Put your actual configuration here                                                                          
# ----------------------------------                                                                          
# If you want to allow non-local connections, you need to add more                                            
# "host" records.  In that case you will also need to make PostgreSQL                                         
# listen on a non-local interface via the listen_addresses                                                    
# configuration parameter, or via the -i or -h command line switches.                                         
# TYPE  DATABASE        USER            ADDRESS                 METHOD                                        
@remove-line-for-nolocal@# "local" is for Unix domain socket connections only                                 
@remove-line-for-nolocal@local   all             all                                    ident                 
# IPv4 local connections:                                                                                     
host    all             all              md5                                            
# IPv6 local connections:                                                                                     
host    all             all             ::1/128                md5                                            
# Allow replication connections from localhost, by a user with the                                            
# replication privilege.                                                                                      
@remove-line-for-nolocal@local   replication     all                                    ident                 
#host    replication     all               md5                                           
#host    replication     all             ::1/128                 md5   

$ echo "log_destination = 'syslog'" >> usr/pkg/pgsql/data/postgresql.conf                                     
$ echo "syslog_ident = 'postgres'" >> usr/pkg/pgsql/data/postgresql.conf   
$ git add usr/pkg/pgsql/*                                                                                     
$ git commit -m "import common config for not to be deployed default role"                                    
[databases_postgresql10_10.4nb1_10.0_11_default 1ce080d] import common config for not to be deployed default e
 2 files changed, 749 insertions(+)                                                                           
 create mode 100644 usr/pkg/pgsql/data/pg_hba.conf                                                            
 create mode 100644 usr/pkg/pgsql/data/postgresql.conf                                                        
$ git push --set-upstream origin databases_postgresql10_10.4nb1_10.0_11_default                               
Counting objects: 8, done.                                                                                    
Compressing objects: 100% (5/5), done.                                                                        
Writing objects: 100% (8/8), 9.10 KiB | 4.55 MiB/s, done.                                                     
Total 8 (delta 0), reused 0 (delta 0)                                                                         
To ssh://                                                     
 * [new branch]      databases_postgresql10_10.4nb1_10.0_11_default -> databases_postgresql10_10.4nb1_10.0_11_default
Branch 'databases_postgresql10_10.4nb1_10.0_11_default' set up to track remote branch 'databases_postgresql10_10.4nb1_10.0_11_default'

the branch with role webserver will get deployed, and doesn't differ in configuration from the default branch:

$ git checkout -b databases_postgresql10-server_10.4nb1_10.0_11_webserver                                            
Switched to a new branch 'databases_postgresql10-server_10.4nb1_10.0_11_webserver'                                   
$ git push --set-upstream origin databases_postgresql10_10.4nb1_10.0_11_webserver
Total 0 (delta 0), reused 0 (delta 0)                                                                         
To ssh://                                                     
 * [new branch]      databases_postgresql10_10.4nb1_10.0_11_webserver -> databases_postgresql10_10.4nb1_10.0_11_webserver
Branch 'databases_postgresql10_10.4nb1_10.0_11_webserver' set up to track remote branch 'databases_postgresql10_10.4nb1_10.0_11_webserver'

now change it for the role dbcluster-master:

$ git checkout -b databases_postgresql10_10.4nb1_10.0_11_dbcluster-master
M       usr/pkg/pgsql/data/pg_hba.conf
M       usr/pkg/pgsql/data/postgresql.conf
Switched to a new branch 'databases_postgresql10_10.4nb1_10.0_11_dbcluster-master'
$ vi usr/pkg/pgsql/data/pg_hba.conf 
$ tail -n 23 usr/pkg/pgsql/data/pg_hba.conf   

# Put your actual configuration here                                                                          
# ----------------------------------                                                                          
# If you want to allow non-local connections, you need to add more                                            
# "host" records.  In that case you will also need to make PostgreSQL                                         
# listen on a non-local interface via the listen_addresses                                                    
# configuration parameter, or via the -i or -h command line switches.                                         
# TYPE  DATABASE        USER            ADDRESS                 METHOD                                        
@remove-line-for-nolocal@# "local" is for Unix domain socket connections only                                 
@remove-line-for-nolocal@local   all             all                                    ident                 
# IPv4 local connections:                                                                                     
host    all             all              md5                                            
# IPv6 local connections:                                                                                     
host    all             all             ::1/128                md5                                            
# Allow replication connections from localhost, by a user with the                                            
# replication privilege.                                                                                      
@remove-line-for-nolocal@local   replication     all                                    ident                 
host    replication     all               trust                                         
host    replication     all             ::1/128                 trust                                         

$ cat << EOF >> usr/pkg/pgsql/data/postgresql.conf 
> listen_addresses = '*'                                                                                      
> wal_level = hot_standby                                                                                     
> max_wal_senders = 10                                                                                        
> hot_standby = on                                                                                            
> archive_mode = on                                                                                           
> archive_command = 'cp %p /usr/pkg/pgsql/archive/%f'                                                         

No automation exists to run mkdir other than creating a placeholder file. you will have to chown the archive dir! File permissions are not yet handled. This may change in the future, by reusing the +DIRS script with new input for example, if deemed necessary by the community.

$ mkdir -p usr/pkg/pgsql/archive/
$ echo "remember to chown this dir to the user pgsql runs as" > usr/pkg/pgsql/archive/placeholder
$ git add usr/pkg/pgsql/archive/placeholder 
$ git commit -m "create dbcluster-master role for postgresql10"
[databases_postgresql10_10.4nb1_10.0_11_dbcluster-master 98fe514] create dbcluster-master role for postgresql0
 3 files changed, 9 insertions(+), 2 deletions(-)
 create mode 100644 usr/pkg/pgsql/archive/placeholder
$ git push -u origin databases_postgresql10_10.4nb1_10.0_11_dbcluster-master
Counting objects: 10, done.
Compressing objects: 100% (7/7), done.
Writing objects: 100% (10/10), 827 bytes | 827.00 KiB/s, done.
Total 10 (delta 2), reused 0 (delta 0)
To ssh://
 * [new branch]      databases_postgresql10_10.4nb1_10.0_11_dbcluster-master -> databases_postgresql10_10.4nb1_10.0_11_dbcluster-master
Branch 'databases_postgresql10_10.4nb1_10.0_11_dbcluster-master' set up to track remote branch 'databases_postgresql10_10.4nb1_10.0_11_dbcluster-master'

create a generic node/replica configuration from the default config files and add the recovery.conf file...

$ git checkout databases_postgresql10_10.4nb1_10.0_11_default         
Switched to branch 'databases_postgresql10_10.4nb1_10.0_11_default'
Your branch is up to date with 'origin/databases_postgresql10_10.4nb1_10.0_11_default'.

$ mkdir -p usr/pkg/pgsql/archive/
$ echo "remember to chown this dir to the user pgsql runs as" > usr/pkg/pgsql/archive/placeholder
$ cp /home/devuser/recovery.conf.sample usr/pkg/pgsql/data/recovery.conf
$ echo "standby_mode = 'on'" >> usr/pkg/pgsql/data/recovery.conf 
$ echo "restore_command = 'cp /usr/pkg/pgsql/archive/%f \"%p%\"'" >> usr/
$ git checkout -b databases_postgresql10_10.4nb1_10.0_11_dbcluster-replicas
A       usr/pkg/pgsql/archive/placeholder
A       usr/pkg/pgsql/data/recovery.conf
Switched to a new branch 'databases_postgresql10_10.4nb1_10.0_11_dbcluster-replicas'
$ git add usr/pkg/pgsql/archive/placeholder 
$ git add usr/pkg/pgsql/data/recovery.conf 
$ git add usr/pkg/pgsql/data/postgresql.conf 
$ git add usr/pkg/pgsql/data/pg_hba.conf     
$ git commit -m "create generalized dbcluster-replica role schema"
[databases_postgresql10_10.4nb1_10.0_11_dbcluster-replicas 9260a88] create generalized dbcluster-replica role schema
 2 files changed, 161 insertions(+)
 create mode 100644 usr/pkg/pgsql/archive/placeholder
 create mode 100644 usr/pkg/pgsql/data/recovery.conf
$ git push -u origin databases_postgresql10_10.4nb1_10.0_11_dbcluster-replicas
Counting objects: 9, done.
Compressing objects: 100% (6/6), done.
Writing objects: 100% (9/9), 2.71 KiB | 2.71 MiB/s, done.
Total 9 (delta 0), reused 0 (delta 0)
To ssh://
 * [new branch]      databases_postgresql10_10.4nb1_10.0_11_dbcluster-replicas -> databases_postgresql10_10.4nb1_10.0_11_dbcluster-replicas
Branch 'databases_postgresql10_10.4nb1_10.0_11_dbcluster-replicas' set up to track remote branch 'databases_postgresql10_10.4nb1_10.0_11_dbcluster-replicas'.

Now specialize the schema for the cluster at @ToonTown by specifying part of the hostname the machines will have in that cluster:

$ git checkout -b databases_postgresql10_10.4nb1_10.0_11_dbcluster-replicas_toontowndc-node
Switched to a new branch 'databases_postgresql10_10.4nb1_10.0_11_dbcluster-replicas_toontowndc-node'
$ echo "primary_conninfo = 'host= port=5432 user=replicauser application_name=toons'" >> usr/pkg/pgsql/data/recovery.conf
$ git add usr/pkg/pgsql/data/recovery.conf 
$ git commit -m "create specialized branch for dbcluster at ToonTown dc"
[databases_postgresql10_10.4nb1_10.0_11_dbcluster-replicas_toontowndc-node 90d9731] create specialized branch for dbcluster at ToonDown dc
 1 file changed, 1 insertion(+)
$ git push -u origin databases_postgresql10_10.4nb1_10.0_11_dbcluster-replicas_toontowndc-node
Counting objects: 7, done.
Compressing objects: 100% (5/5), done.
Writing objects: 100% (7/7), 604 bytes | 604.00 KiB/s, done.
Total 7 (delta 2), reused 0 (delta 0)
To ssh://
 * [new branch]      databases_postgresql10_10.4nb1_10.0_11_dbcluster-replicas_toontowndc-node -> databases_postgresql10_10.4nb1_10.0_11_dbcluster-replicas_toontowndc-node
Branch 'databases_postgresql10_10.4nb1_10.0_11_dbcluster-replicas_toontowndc-node' set up to track remote branch 'databases_postgresql10_10.4nb1_10.0_11_dbcluster-replicas_toontowndc-node'.

Let's try to deploy it on a node!

pkghost# whoami
pkghost# hostname
pkghost# cat /usr/pkg/etc/pkg_install.conf 
pkghost# echo "ROLE=dbcluster-replicas" >> /usr/pkg/etc/pkg_install.conf 
pkghost# hostname toontowndc-node05
toontowndc-node05# #show use with pkg_add and a local package, for once
toontowndc-node05# /usr/pkg/sbin/pkg_add ./postgresql10-10.3.tgz
Trying to deploy configuration from ssh://vcs@ via git
About to use remote branch databases_postgresql10_10.4nb1_10.0_11_dbcluster-replicas_toontowndc-node
Cloning into 'confpullexample'...
remote: Enumerating objects: 45, done.
remote: Counting objects: 100% (45/45), done.
remote: Compressing objects: 100% (28/28), done.
remote: Total 45 (delta 5), reused 0 (delta 0)
Receiving objects: 100% (45/45), 15.23 KiB | 12.00 KiB/s, done.
Resolving deltas: 100% (5/5), done.
/tmp/pkgsrcdeploy-17103/work/etc/ssh/sshd_config -> /etc/ssh/sshd_config
/tmp/pkgsrcdeploy-17103/work/usr/pkg/pgsql/archive/placeholder -> /usr/pkg/pgsql/archive/placeholder
/tmp/pkgsrcdeploy-17103/work/usr/pkg/pgsql/data/pg_hba.conf -> /usr/pkg/pgsql/data/pg_hba.conf
/tmp/pkgsrcdeploy-17103/work/usr/pkg/pgsql/data/postgresql.conf -> /usr/pkg/pgsql/data/postgresql.conf
/tmp/pkgsrcdeploy-17103/work/usr/pkg/pgsql/data/recovery.conf -> /usr/pkg/pgsql/data/recovery.conf

toontowndc-node05# tail /etc/ssh/sshd_config 

# Example of overriding settings on a per-user basis
#Match User anoncvs
#       X11Forwarding no
#       AllowTcpForwarding no
#       PermitTTY no
#       ForceCommand cvs server
PermitEmptyPasswords no
PermitRootLogin no
AllowGroup ops

toontowndc-node05# tail /usr/pkg/pgsql/data/recovery.conf
# Hot Standby related parameters are listed in postgresql.conf
standby_mode = 'on'
restore_command = 'cp /usr/pkg/pgsql/archive/%f "%p%"'
primary_conninfo = 'host= port=5432 user=replicauser application_name=toons'

toontowndc-node05# ls /tmp/pkgsrcdeploy-17103
ls: /tmp/pkgsrcdeploy-17103: No such file or directory

The same way goes if you should choose to set VCS=hg or VCS=svn in pkg_install.conf. All are supported when pulling configuration, you should adapt to managing branches the way these other VCSs expect you to work with them. It might be in scope for this tutorial, but it's getting a bit long! Also remember to set an appropriate URI in REMOTEVCS for these other Version Control Systems.

CVS is not supported: tags (branch names) cannot contain dots with CVS, and this breaks the chosen naming scheme for many software applications. It could be replaced with another special meaning character when using this vcs, but this workaround would make for possible confusion in branch naming. Furthermore, as with svn, there is no way to list remote branches before getting a local copy of the repository, with the added headcache of having to parse its log to extract branch names. I considered it not to be worth the hassle, but I'm open to adding PULL mode support for cvs if required by any user.

One word about subversion: I expect you to follow conventions and keep branches at /branches/ in your repository!

pkgconftrack store: storing changes when not upgrading packages

Even when merging changes in configuration files is not attempted because of VCSAUTOMERGE=no or unset, pkgsrc will keep track of installed configuration files by committing them to the configuration repository, as a user-modified file under user/$filePath (see mk/pkginstall/files). No VCS will commit files that haven't changed since the last revision (I hope!).

But what if you made changes to a configuration file and you want to store it in the configuration repository as a manually edited file, neither waiting for its package to be updated nor forcing a reinstallation? You could interact with your vcs of choice direcly, or just use the new script in pkgsrc at pkgtools/pkgconftrack

pkgconf# cd pkgtools/pkgconftrack/
pkgconf# make install
===> Skipping vulnerability checks.
===> Installing binary package of pkgconftrack-1.0
pkgconf# pkgconftrack
prefix: /usr/pkg, VCSDIR: /var/confrepo, VCS: svn, REMOTEVCS: no
: unknown action
Usage: pkgconftrack [-p PREFIX] [-m commit message] store packagename [... packagenames]

pkgconftrack will search for pkgsrc VCS configuration on your shell environment or in pkg_install.conf, reading it via pkg_admin config-var $VARNAME.

pkg_admin, in order to work with the correct configuration file, and look in the right package database to check if a package exists and its list of configuration files, is called relative to the prefix. By default, if unspecified, /usr/pkg is assumed and /usr/pkg/sbin/pkg_admin is executed.

You can work in packages of a different prefix by calling pkgconftrack -p /path/to/other/prefix followed by other options (you are free to chose a custom commit message with -m "my commit message") and the action to be performed.

As of now, pkgconftrack only support one action: store followed by one or more packages you wish to store configuration files from, into the configuration repository.

When storing configuration for more than one package, a unique commit is made (if using a VCS other than the old RCS, which doesn't support multi file commits and atomic transactions). This opens the way to storing config files for a service made working by a combination of software packages when these are in a known-good status, to be accessed and restored checking out one commit id.

So, let's say one last change was needed to have mail working:

pkgconf# diff /usr/pkg/etc/spamd.conf /usr/pkg/share/examples/spamd/spamd.conf 
> #
<       :method=https:\
>       :method=http:\
pkgconf# pkgconftrack -m "5 august 2018: mail service: blacklist only accessible via https" store spamd postfix dovecot opendkim
prefix: /usr/pkg, VCSDIR: /var/confrepo, VCS: svn, REMOTEVCS: no
Storing configuration files for opendkim
A         opendkim.conf
Package not found: dovecot in the pkgdb for /usr/pkg
Package not found: postfix in the pkgdb for /usr/pkg
Storing configuration files for spamd
Adding         usr/pkg/etc/opendkim.conf
Transmitting file data .done
Committing transaction...
Committed revision 7.

Yeah, I haven't really installed a mail server just to test pkgconftrack, so neither dovecot nor postfix are installed on the system!

future improvements

Well, it all begins with the new features being tested by end users, more bugs being found, changes made as requested. Then, once things get more stable, the versioning script could be reimplemented as part of pkgtasks, and files.subr changed there to interact with the new functions.

More VCSs could be handled, there could be more automation in switching repositories and adding remote sources, but all this is maybe best kept in a separate tool such as pkgconftrack. Speaking of which, well, it stores installed config files for one or more packages at once, but it does not restore them yet! RCS needs to be supported, being the default Version Control System, but it has no concept of an atomic transaction involving more than one file, so there would be nothing the user could reference to when asking the script to restore configuration. The script could track, by checking the log for all files, for identical commit message and restore each revision of each file having the same commit message, but what if some user mistakingly reused the same commit message as part of different transactions? Should each custom commit message be prepended with a timestamp?

All this would still lead to differences in referencing to a transaction, or the simulation thereof, and in listing available changes the user can select for restore.

pkgconftrack could also help in interactively reviewing conflicting automerge results, some scripts already do it, and in restoring the last user-installed file from the repository in case of breakage. This should really consist in a cp from vcsdir/user/path/to/file /path/to/installed/file, maybe preceded by a checkout, but there is good marging for making the tool more useful.

And yes, configuraction deployment/VCSCONFPULL does not handle permissions or the creation of empty directories, executable files: I think this would require making the way users interact with the configuration repository more complex, more akin to a configuration management and monitoring software, and widen the chances for mistakes when working across branches. Any good idea of how to implement these missing bits while still keeping things simple for users?

I'd really like to see the code tried out! it's now at Github