[Dev] Migrating Parabola infrastructure from the old server to newtron

Luke Shumaker lukeshu at lukeshu.com
Thu Mar 31 02:13:21 GMT 2022


On Mon, 28 Mar 2022 15:25:03 -0600,
Denis 'GNUtoo' Carikli wrote:
> - Part of the files in /etc/ and/or in other parts of the system comes
>   from packages that come from a [config] repository. These packages
>   are generated from a configuration management tool named holo. We
>   currently use a patched version of holo[1].

Ugg, you're reminding me that I didn't just go AWOL from Parabola, I
went AWOL from Holo.  I/we should definitely endeavor to get those
patches upstream.

(I ended up becaming a significant contributor to Holo, but only after
I'd already started using it on my Parabola boxes.)

> Questions:
> ----------
> - What is the license of the packages? Is there a way to at least get
>   the configuration files under a free license? There are also scripts
>   like common.sh that lack licenses. Also I didn't found the
>   sources of the files used to generate the package repository, so I
>   would also be interested in that.

It's https://git.parabola.nu/server/config.git/

I'm the only committer to that repo, but I'm not sure it's accurate to
say that I'm the only author--it started out as me "documenting" what
was already there on the servers.

Also, I don't recall quite what the status of this was, but what I was
working toward is that https://wiki.parabola.nu/Hacking:Servers be
generated entirely from running `./doc` in that repo.  I think it was pretty
close, at least for the winston.parabola.nu section.

I forget if I ever set up a post-push Git hook for config.git that had
it `cd /srv/config.parabola.nu && ./build` or if I manually SSH'ed in
and did that whenenver I pushed.

Anyway, as far as I am concerned my contribution to config.git is
public domain.

> - Why do we need a configuration management tool to generate the
>   packages? Would migrating the packages generated by holo to more
>   standard PKGBUILDS inside abslibre in a separate config repository be
>   a good idea? So far I found several advantages in doing that:

We aren't using `holo-build`; just the core of Holo--they *are*
standard PKGBUILDs.  Well, they `source common.sh` which is a few
shell functions that I found useful for writing config-oriented
PKGBUILDs.

Aside: config.git's `./build` script uses `art`; `art` isn't anything
terribly special, it's just a tool for conveniently building all of
the packages in a directory and sticking them in a pacman repo (it
understands not just vanilla PKGBUILDs, but also `holo-build` files,
but we don't care about `holo-build` files).

So what Holo does for us is provide a pacman post-install hook that
gives us a way to patch files owned by other packages.

For example, we want to configure the `/etc/collectd.conf` file, but
that's owned by the `collectd` package.  So
`config-parabola-base-collectd.PKGBUILD` instead of including an
`/etc/collectd.conf` file which would conflict, includes a
`/usr/share/holo/files/10-config-parabola-base-collectd/etc/collectd.conf.holoscript`
which is a shell script that takes the stock collectd.conf on stdin
and uses sed and awk to emit our modifications to it on stdout.

>   - It would make the packages less obscure: developers that already
>     know how to contribute changes to packages will also be able to
>     contribute changes to the configuration of the Parabola servers in
>     this way.

That should generally still bet true; just that they're in config.git
instead of abslibre.git.

>   - It will also result in having the configuration mirrored by all
>     the Parabola mirrors so they will be backed up, so if the Parabola
>     main server is destroyed we would for sure find mirrors with that
>     configuration, and the packages will also be signed.

 1. The *are* included in https://winston.parabola.nu/backup/ (are the
    backups still encrypted to my GPG key? :grimmace:)

 2. And also mirroring config.git should be sufficient for backing
    these things up.

-- 
Happy hacking,
~ Luke Shumaker


More information about the Dev mailing list