... | ... | @@ -953,9 +953,24 @@ This documents generally how things are setup. |
|
|
|
|
|
## Installation
|
|
|
|
|
|
TODO. It is not yet clear how the Puppetmaster was setup or how to
|
|
|
build a new one. The interactions with other tools like Nagios and
|
|
|
LDAP especially need to be documented.
|
|
|
Setting up a new Puppet server from scratch is not supported, or, to
|
|
|
be more accurate, would be somewhat difficult. The server expects
|
|
|
various external services to populate it with data, in particular:
|
|
|
|
|
|
* it [fetches data from LDAP](#ldap-integration)
|
|
|
* [Nagios generates the NRPE configuration](#nagios-integration)
|
|
|
* the [letsencrypt repository manages the TLS certificates](#lets-encrypt-tls-certificates)
|
|
|
|
|
|
The auto-ca component is also deployed manual, and so are the git
|
|
|
hooks, repositories and permissions.
|
|
|
|
|
|
This needs to be documented, automated and improved. Ideally, it
|
|
|
should be possible to install a new Puppet server from scratch using
|
|
|
nothing but a Puppet bootstrap manifest, see [issue 30770][] and
|
|
|
[issue 29387][], along with [discussion about those improvements in
|
|
|
this page](#proposed-solution), for details.
|
|
|
|
|
|
[issue 30770]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/30770
|
|
|
|
|
|
## SLA
|
|
|
|
... | ... | @@ -965,17 +980,53 @@ the future if we rely more on it for deployments. |
|
|
|
|
|
## Design
|
|
|
|
|
|
TODO. review
|
|
|
<https://bluesock.org/~willkg/blog/dev/auditing_projects.html> and
|
|
|
expand this design accordingly.
|
|
|
|
|
|
TODO: add a lead here.
|
|
|
|
|
|
<!-- how this is built -->
|
|
|
<!-- should reuse and expand on the "proposed solution", it's a -->
|
|
|
<!-- "as-built" documented, whereas the "Proposed solution" is an -->
|
|
|
<!-- "architectural" document, which the final result might differ -->
|
|
|
<!-- from, sometimes significantly -->
|
|
|
The Puppet server and PuppetDB currently live on `pauli`. That server
|
|
|
was setup in 2011 by weasel. It follows the configuration of the
|
|
|
Debian Sysadmin (DSA) Puppet server, which has its source code
|
|
|
available in the [dsa-puppet repository](https://salsa.debian.org/dsa-team/mirror/dsa-puppet/).
|
|
|
|
|
|
The service is maintained by TPA and manages *all* TPA-operated
|
|
|
machines. Ideally, all services are managed by Puppet, but
|
|
|
historically, only basic services were configured through Puppet,
|
|
|
leaving service admins responsible for deploying their services on top
|
|
|
of it. That tendency has shifted recently (~2020) with the deployment
|
|
|
of the [GitLab](gitlab) service through Puppet, for example.
|
|
|
|
|
|
The source code to the Puppet manifests (see below for a Glossary) is
|
|
|
managed through git on a repository hosted directly on the Puppet
|
|
|
server. Agents are deployed as part of the [install process](new-machine), and
|
|
|
talk to the central server using a Puppet-specific certificate
|
|
|
authority (CA).
|
|
|
|
|
|
As mentioned in the [installation section](#installation), the Puppet server
|
|
|
assumes a few components (namely [LDAP](ldap), [Nagios](nagios), [Let's
|
|
|
Encrypt](tls) and auto-ca) feed information into it. This is also
|
|
|
detailed in the sections below. In particular, Puppet consistutes a
|
|
|
duplicate "source of truth" for some information about servers. For
|
|
|
example, LDAP has a "purpose" field describing what a server is for,
|
|
|
but Puppet also has the concept of a role, attributed through Hiera
|
|
|
(see [issue 30273][]). A similar problem exists with IP addresses and
|
|
|
user access control, in general.
|
|
|
|
|
|
[issue 30273]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/30273
|
|
|
|
|
|
Puppet is generally considered stable, but the code base is somewhat
|
|
|
showing its age and has accumulated some technical debt.
|
|
|
|
|
|
For example, much of the Puppet code deployed is specific to Tor (and
|
|
|
DSA, to a certain extent) and therefore is only maintained by a
|
|
|
handful of people. It would be preferable to migrate to third-party,
|
|
|
externally maintained modules (e.g. [systemd](https://gitlab.torproject.org/tpo/tpa/team/-/issues/33449), but also many
|
|
|
others, see [issue 29387][] for details). A similar problem exists
|
|
|
with custom Ruby code implemented for various functions, which is
|
|
|
being replaced with Hiera ([issue 30020][]).
|
|
|
|
|
|
The Puppet infrastructure being kept up to date with the latest
|
|
|
versions in Debian but will require some work to port to Puppet 6, as
|
|
|
the current deployment system ("puppetmaster") has been removed in
|
|
|
that new release (see [issue 33588][]).
|
|
|
|
|
|
[issue 33588]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/33588
|
|
|
|
|
|
### Glossary
|
|
|
|
... | ... | |