How is Everyone Managing secrets in a Compose File Repo
I've migrated off of Portainer to standard docker compose recently so that I can script some major tasks like updating all the containers or restarting all of them. I also liked the idea of being able to put the compose files into a git repo and push it up so that they are automatically backed up. I hope to be able to turn this into more of infrastructure as code implementation where I can edit the repo and have it auto push to my server and redeploy. That's a bit further down the line though.
That said, with the compose files living in their remote, they currently still have their secrets on them, either in a corresponding .env file or in the compose file itself. I really don't like this since if someone ever gains access to the repo they have all my services' secrets. What is the best way to use a git repo for compose files while not exposing a bunch of secrets potentially?
I know podman supports secrets, though I guess I'd have to manually ssh into the server to create them in the session. Currently these services are all through docker however.
Nice, people will absolutely try to steal it if you don't properly lock it up. Make sure you get a good U lock and take the battery with you if it's not lockable (and take it with you even if it is if you'll be gone for a while)
On the fly atomic updates (the recommended update path for DNF installed apps requires a system reboot.) Though you can do it live, doing offline upgrades is safer so you don't replace some runtime something is using midflight.
Also, flatpaks have some system isolation and have to use flatpak portals and explicit permissions/mounts giving them less ability to negatively affect my system.
Also, Flathub just has everything that I need to run anyway, at least for GUI apps.
Fedora Workstation is what I use for my desktop. If I were to have to reinstall now I'd do Silverblue.
For my home lab I do Proxmox with a couple of VM's for Ubuntu server for pihole DNS servers and an OpenMediaVault VM for my docker workloads. I'd probably do CoreOS or IoT if I was starting over there though.
Every graphical app I have installed that isn't a basic system application included with the distro install is either in a podman container or flatpak.
You can try Organic Maps if you have a pressing need for privacy in your maps app.
It seems... okay... when I used it. No support for android or apple auto integration though.
Matrix is the usual suggestion. I've never used voice chat on it or the clients for it like Element though so I can't speak to how well it works if you need that function in Discord.
If the Fedora group starts doing dumb stuff I'll consider switching. But so far they've been rock solid. While Red Hat is certainly a major contributor to Fedora (the biggest easily) they don't control it per-say.
I agree wholeheartedly with this. Block Threads if they do a shitty job moderating their users and they post stuff not permitted by our instance like homophobia, transphobia, racism, etc. Preemptively blocking them to "protect privacy" won't do that and gives the false impression that what you're posting to the fediverse can't be just hoovered up by google/meta anyway.
Twitter isn't their customer friends.
I'm generally pretty happy with it, though I'd have used podman rather than docker if I were starting now.
Check out Podlet to convert your existing docker run commands or docker-compose.yaml files to quadlet files https://github.com/k9withabone/podlet
A really helpful tool for converting from Docker to Podman
Generate podman quadlet (systemd-like) files from a podman command - GitHub - k9withabone/podlet: Generate podman quadlet (systemd-like) files from a podman command
I've been using "Podlet" recently to convert my docker-compose.yaml files over to quadlet files. For those who aren't familiar, Quadlet is basically a halfway point between a compose file and a systemd entry and it simplifies the process for using systemd to manage your podman containers. This tool can convert podman run commands or docker-compose.yaml files into their appropriate quadlet files in one fell swoop. If you have some really complicated stuff going on with networks it may not work though. Especially if they origional docker file is trying to do stuff that's only possible with root.
Podlet can also be run as a container rather than directly installing it. If you do: podman run --rm --pull=newer -w $PWD -v $PWD:$PWD quay.io/k9withabone/podlet
It will run it on your current working directory, so if you have a docker-compose.yaml file there it'll spit out the appropriate quadlet files.
What I did is install proxmox on the bare metal, setup a vm in which I put the containers.
Proxmox itself stays (almost) completely stock. The only changes I've made to it were to add the NUT client package so it could gracefully shut down if my NUT server indicates that the UPS is running out of power during an outage.
In your VMs you can do whatever. Setup OMV, or a stock Ubuntu or Debian vm and install your services on the VM or use Docker/Podman. Setup Fedora CoreOS or IoT vms and host all your services in Podman containers.
The great thing about Proxmox is you can do snapshot backups which take mere moments to complete. Then pass those off to a NAS where they can survive a irreparable loss of your Proxmox server.
You can also spin up new vms as needed to just try to fuck around with new techs or just a new way of setting up your home lab. It gives you a ton of flexibility and makes backing stuff up way easier.
Another great thing you can do is if 3 years down the line you are looking to replace your server hardware with some newer or more powerful stuff you can just add the new device as a node to the cluster. Then you can migrate all your existing VMs over to your new hardware and decommission your old one with very little to no downtime on anything.