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

Denis 'GNUtoo' Carikli GNUtoo at cyberdimension.org
Mon Mar 28 21:25:03 GMT 2022


I've some questions on the server(s) configuration management.

Background information:
Since updates are not done for a while on Winston, after some
discussions on IRC with Bill Auger, I understood that the current plan
was to migrate all the services to Newtron (the new server) instead of
trying to fix the situation on Winston.

I've started looking into it last week, and I tried to migrate a very
simple service (the package redirection service that is done
by an nginx configuration file).

While doing that I found out a bit how it worked on Winston:
- All the files in /etc/ are handled by etckeeper in an almost
  completely automatic way: files are committed automatically after
  package installation, at regular interval, etc, and the git repository
  contains very few commits made by humans.
- 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].

I think that having the configuration files that are not tied to
specific hardware or IP addresses inside packages is a really good idea:
it avoids the overlap between package management and configuration
management, and it also enables everybody to install the packages and
simplify testing and deployment: People can more easily test the
packages, generate VM images with the packages, etc.

I've started looking into holo but I've not yet managed to understand
the full picture yet, so I've some questions on why or how it was done.

- 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.

- 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:
  - 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.

  - 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.

  - It will also be easier to that configuration in the official
    Parabola servers, and since it's easier we could also test it more
    easily in virtual machines or different servers. Contributors could
    also test things more easily.

  Because of that I've started working on migrating the packages to
  abslibre in a branch[2]. I think that I'll end up converting it to
  more standard packages if the active Parabola developers are OK
  with that.

My changes on Newtron:
I've also started added etckeeper for the changes that are very specific
to Newtron, like the hostname. I've done it in a completely
non-automatic way: none of the commits were made automatically and
all the commit messages were written by humans (me).

This enables to track changes more easily. I probably need to write a
script to generate .etckeeper automatically though from the permissions
of the files being tracked, while still enabling humans to override the
permissions somehow (for instance to disable a script with chmod -x).

As etckeeper wasn't used before that, It's also relatively easy to
remove etckeeper and restart from scratch in the same way it was done
before if needed.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20220328/27c0848c/attachment.sig>

More information about the Dev mailing list