Commit Graph

9 Commits (d432c673e9ba7a77b89a450c85b835fe0e52bdcc)

Author SHA1 Message Date
Dustin ae948489e3 Deploy Promtail to all non-Kubernetes nodes
All the stand-alone FCOS hosts now have Promtail running, forwarding
_systemd_ journal messages to Grafana Loki.  The Kubernetes nodes will
have Promtail deployed as a Kubernetes pod.

I would really like to come up with a way to define variables for groups
of hosts, so that I do not have to add `promtail: prod.#promtail` to
every host's values file individually...
2024-02-18 12:59:14 -06:00
Dustin 786145e914 env/prod: Collect common tempates in module
In order to simplify the process of adding new template render
instructions to all hosts, I've created a list of templates in the
`env/prod` module.  This way, I only have to add templates there, and
all hosts that "inherit" from it will automatically get them.
2024-02-03 11:16:52 -06:00
Dustin b7f5d4a910 app/ssh: Configure sshd trusted user CA keys
Configuring the system-wide trusted user CA key list for *sshd(8)*.
2024-02-03 11:16:52 -06:00
Dustin f886a1bd8a sudo: Configure pam_ssh_agent_auth
I do not like how Fedora CoreOS configures `sudo` to allow the *core*
user to run privileged processes without authentication.  Rather than
assign the user a password, which would then have to be stored
somewhere, we'll install *pam_ssh_agent_auth* and configure `sudo` to
use it for authentication.  This way, only users with the private key
corresponding to one of the configured public keys can run `sudo`.

Naturally, *pam_ssh_agent_auth* has to be installed on the host system.
We achieve this by executing `rpm-ostree` via `nsenter` to escape the
container.  Once it is installed, we configure the PAM stack for
`sudo` to use it and populate the authorized keys database.  We also
need to configure `sudo` to keep the `SSH_AUTH_SOCK` environment
variable, so *pam_ssh_agent_auth* knows where to look for the private
keys.  Finally, we disable the default NOPASSWD rule for `sudo`, if
and only if the new configuration was installed.
2024-01-29 09:10:42 -06:00
Dustin fb74f0e81c nut: Configure upsmon
`upsmon` is the component of NUT that tracks the status of UPSs and
reacts to their changing by sending notifications and/or shutting down
the system.  It is a networked application that can run on any system;
it can run on a different system than `upsd`, and indeed can run on
multiple systems simultaneously.

Each system that runs `upsmon` will need a username and password for
each UPS it will monitor.  Using the CUE [function pattern][0], I've
made it pretty simple to declare the necessary values under
`nut.monitor`.

[0]: https://cuetorials.com/patterns/functions/
2024-01-19 08:52:14 -06:00
Dustin d3338a125b nut0: Configure collectd 2024-01-17 17:35:21 -06:00
Dustin 41e9fa85d2 Restructure CUE packages
A bunch of stuff that wasn't schema definitions ended up in the `schema`
package.  Rather than split values up in a bunch of top-level packages,
I think it would be better to have a package-per-app model.
2024-01-17 17:35:18 -06:00
Dustin 52642d37d9 nut: Configure collectd NUT plugin
infra/cfg/pipeline/head This commit looks good Details
2024-01-17 07:18:37 -06:00
Dustin 11f9957c11 Switch from KCL to CUE
Although KCL is unquestionably a more powerful language, and maps more
closely to my mental model of how host/environment/application
configuration is defined, the fact that it doesn't work on ARM (issue
982]) makes it a non-starter.  It's also quite slow (owing to how it
compiles a program to evaluate the code) and cumbersome to distribute.
Fortunately, `tmpl` doesn't care how the values it uses were computed,
so we freely change configuration languages, so long as whatever we use
generates JSON/YAML.

CUE is probably a lot more popular than KCL, and is quite a bit simpler.
It's more restrictive (values cannot be overridden once defined), but
still expressive enough for what I am trying to do (so far).
2024-01-15 11:40:58 -06:00