[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
Hi,
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.
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.
- 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.
References:
-----------
[1]http://holocm.org
[2]https://git.parabola.nu/abslibre.git/log/?h=config-repository
Denis.
-------------- 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