Ansible configuration policy for the private network/home lab of Dustin C. Hatch
http://dustin.hatch.name/
So it turns out Gitea's RPM package repository feature is less than stellar. Since each organization/user can only have a single repository, separating packages by OS would be extremely cumbersome. Presumably, the feature was designed for projects that only build a single PRM for each version, but most of my packages need multiple builds, as they tend to link to system libraries. Further, only the repository owner can publish to user-scoped repositories, so e.g. Jenkins cannot publish anything to a repository under my *dustin* account. This means I would ultimately have to create an Organization for every OS/version I need to support, and make Jenkins a member of it. That sounds tedious and annoying, so I decided against using that feature for internal packages. Instead, I decided to return to the old ways, publishing packages with `rsync` and serving them with Apache. It's fairly straightforward to set this up: just need a directory with the appropriate permissions for users to upload packages, and configure Apache to serve from it. One advantage Gitea's feature had over a plain directory is its automatic management of repository metadata. Publishers only have to upload the RPMs they want to serve, and Gitea handles generating the index, database, etc. files necessary to make the packages available to Yum/dnf. With a plain file host, the publisher would need to use `createrepo` to generate the repository metadata and upload that as well. For repositories with multiple packages, the publisher would need a copy of every RPM file locally in order for them to be included in the repository metadata. This, too, seems like it would be too much trouble to be tenable, so I created a simple automatic metadata manager for the file-based repo host. Using `inotifywatch`, the `repohost-createrepo` script watches for file modifications in the repository base directory. Whenever a file is added or changed, the directory containing it is added to a queue. Every thirty seconds, the queue is processed; for each unique directory in the queue, repository metadata are generated. This implementation combines the flexibility of a plain file host, supporting an effectively unlimited number of repositories with fully-configurable permissions, and the ease of publishing of a simple file upload. |
||
---|---|---|
.certs@13f97e4fa1 | ||
certs | ||
ci | ||
group_vars | ||
host_vars | ||
passwords/kojiweb_secret | ||
roles | ||
vars | ||
vault | ||
.gitignore | ||
.gitmodules | ||
.vault-secret.sh | ||
alertmanager.yml | ||
ansible.cfg | ||
ansible.yml | ||
aria2.yml | ||
base.yml | ||
bitwarden_rs.yml | ||
blackbox-exporter.yml | ||
burp-client.yml | ||
burp-server.yml | ||
certbot.yml | ||
collectd.yml | ||
dch-gw.yml | ||
dch-proxy.yml | ||
dch-root-ca.crt | ||
dch-vpn.yml | ||
dhcpcd.yml | ||
dhcpd.yml | ||
docker.yml | ||
domain-controller.yml | ||
dyngroups.yml | ||
facts.yml | ||
fileserver.yml | ||
firewalld.yml | ||
frigate.yml | ||
gitea.yml | ||
grafana.yml | ||
graylog.yml | ||
hassdb.yml | ||
homeassistant.yml | ||
hostname.yml | ||
hosts | ||
hosts.offline | ||
jellyfin.yml | ||
jenkins-slave.yml | ||
journal2ntfy.yml | ||
koji-builder.yml | ||
koji-hub.yml | ||
koji-web.yml | ||
koji.yml | ||
kube-root-ca.crt | ||
metricspi.yml | ||
minio.yml | ||
motioneye.yml | ||
named-server.yml | ||
net-ifaces.yml | ||
network.yml | ||
nextcloud.yml | ||
ntp.yml | ||
nut.yml | ||
postgresql.yml | ||
protonvpn.yml | ||
pxe.yml | ||
pyrocufflink.yml | ||
radius.yml | ||
radvd.yml | ||
remount.yml | ||
repohost.yml | ||
rngd.yml | ||
samba-dc.yml | ||
smtp-relay.yml | ||
squid.yml | ||
synapse.yml | ||
systemd-networkd.yml | ||
systemd-resolved.yml | ||
taiga.yml | ||
unifi.yml | ||
victoria-metrics.yml | ||
vmhost.yml | ||
websites.yml | ||
wheelhost.yml | ||
zabbix-agent.yml | ||
zabbix-server.yml | ||
zabbix.yml | ||
zezere.yml | ||
zigbee2mqtt.yml | ||
zwavejs2mqtt.yml |