![[NetBSD Logo]](/tnf/resource/NetBSD-headerlogo.png)
GSoC 2018 Reports: Configuration files versioning in pkgsrc, part 4: configuration deployment, pkgtools and future improvements
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 VCSTRACK_CONF=yes VCSCONFPULL=yes REMOTEVCS=ssh://vcs@192.168.100.112/usr/home/vcs/confpullexample.git VCS=git
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:
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 devuser $ file $HOME/.ssh/id_rsa /home/devuser/.ssh/id_rsa: PEM RSA private key $ pwd /home/devuser/sim $ git clone ssh://vcs@192.168.100.112/usr/home/vcs/confpullexample.git . Cloning into '.'... The authenticity of host '192.168.100.112 (192.168.100.112)' can't be established. ECDSA key fingerprint is SHA256:RMkiZlYqNIKlgDQUvhFBXLUpW2qcLd1nuEi4NaROkLg. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added '192.168.100.112' (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://192.168.100.112/usr/home/vcs/confpullexample.git * [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
/home/devuser
$ 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.
@authcomment@
# 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 127.0.0.1/32 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 127.0.0.1/32 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://192.168.100.112/usr/home/vcs/confpullexample.git
* [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://192.168.100.112/usr/home/vcs/confpullexample.git * [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.
@authcomment@
# 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 127.0.0.1/32 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 127.0.0.1/32 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'
> EOF
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://192.168.100.112/usr/home/vcs/confpullexample.git * [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://192.168.100.112/usr/home/vcs/confpullexample.git * [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=10.0.10.200 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://192.168.100.112/usr/home/vcs/confpullexample.git * [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 root pkghost# hostname pkghost pkghost# cat /usr/pkg/etc/pkg_install.conf VCSTRACK_CONF=yes VCSCONFPULL=yes REMOTEVCS=ssh://vcs@192.168.100.112/usr/home/vcs/confpullexample.git VCS=git 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@192.168.100.112/usr/home/vcs/confpullexample.git 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 PARAMETERS #--------------------------------------------------------------------------- # # Hot Standby related parameters are listed in postgresql.conf # #--------------------------------------------------------------------------- standby_mode = 'on' restore_command = 'cp /usr/pkg/pgsql/archive/%f "%p%"' primary_conninfo = 'host=10.0.10.200 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 7a8 > # 33c34 < :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. pkgconf#
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
. [0 comments]