installed minio with podman over systemd (team#41257)

`minio{1...4}.example.com` but we assume the `minio` prefix is

user-chosen, in our case `minio-0`.

The `profile::minio` class must be included in the role (currently

`role::object_storage`) for the affected server. It currently only

configures Docker and the firewall.

The [quickstart guide][] is easy enough to follow to get us started,

but we do some tweaks to:

 * make the `podman` commandline more self-explanatory using long

 options

 * assign a name to the container

 * use `/srv` instead of `~`

 * explicitly generate a (strong) password, store it in a config file,

   and use that

 * just create the container (and not start it), delegating the

   container management to systemd instead, as per [this guide](https://www.redhat.com/sysadmin/improved-systemd-podman)

This is the actual command we use to *create* (not start!) the

container:

    PASSWORD=$(tr -dc '[:alnum:]' < /dev/urandom | head -c 32)

    echo "PASSWORD=$PASSWORD" > /etc/default/minio

    chmod 600 /etc/default/minio

    mkdir -p /srv/data

    podman create \

       --name minio \

       --publish 9000:9000 \

       --publish 9090:9090 \

       --volume /srv/data:/data \

       --env "MINIO_ROOT_USER=root" \

       --env "MINIO_ROOT_PASSWORD=$PASSWORD" \

       quay.io/minio/minio server /data --console-address ":9090"

We store the password in a file because it will be used in a systemd

unit. That could be done in Puppet instead.

This is how the systemd unit was generated:

    podman generate systemd --new --name minio | sed 's/MINIO_ROOT_PASSWORD=[^ ]*/MINIO_ROOT_PASSWORD=$PASSWORD/' > /etc/systemd/system/container-minio.service

Then the unit was enabled and started with:

    systemctl enable container-minio.service && systemctl start container-minio.service

That starts MinIO with an admin interface on <https://localhost:9090>

and the API on <https://localhost:9000>, even though the console

messages mention addresses in the `10.0.0.0/8` network.

You can use the web interface to create the buckets, or the [mc

client][] which is [also available as a Docker container][].

[quickstart guide]: https://min.io/docs/minio/container/index.html

[mc client]: https://min.io/docs/minio/linux/reference/minio-mc.html

[also available as a Docker container]: https://quay.io/repository/minio/mc

The installation was done in [issue tpo/tpa/team#41257](https://gitlab.torproject.org/tpo/tpa/team/-/issues/41257) which may

have more details.

TODO: consider podman "quadlets" in podman 4.4 https://www.redhat.com/sysadmin/quadlet-podman

## Upgrades

<!-- how upgrades are performed. preferably automated through Debian -->

<!-- packages, otherwise document how upgrades are performed. see also -->

<!-- the Testing section below -->

TODO: consider podman auto-update, see https://www.redhat.com/sysadmin/improved-systemd-podman

## SLA

<!-- this describes an acceptable level of service for this service -->

## Other alternatives

<!-- include benchmarks and procedure if relevant -->

### MinIO Puppet module

The [kogitoapp/minio](https://forge.puppet.com/modules/kogitoapp/minio/) provides a way to configure one or many MinIO

servers. Unfortunately it suffers from a set of limitations:

 1. it doesn't support Docker as an install method, only binaries

    (although to its defense it does use a checksum...)

 2. it depends on the [deprecated puppet-certs module](https://github.com/broadinstitute/puppet-certs)

 3. even if it would defend on the newer [puppet-certificates

    module](https://github.com/broadinstitute/puppet-certificates), that module clashes with the way we manage our own

    certificates... we might or might not want to use this module in

    the long term, but right now it seems too big of a jump to follow

 4. it hasn't been updated in about two years (last release in

    September 2021, as of July 2023)

We might still want to consider that module if we expand the fleet to

multiple servers.