Many of the .ee communities are in the process of migrating, so hopefully the list can be updated with their new homes.

2 years for me as well!

Ok thanks, I’ll have to be extra careful deploying any changes.

Thanks! I did see there’s a docker format and a podman format which I assume is what this difference is about. I’m not against discord but I’ve never really used it. I’ll check it out if I get desperate 🙂

Thanks, I had already played a bit with distrobox and hadn’t worked that out either. It seems adding a Z flag to my bind mount to keep SELinux happy is all that was needed.

I seem to have got it working using podman, adding a Z flag to the bind mount to make SELinux happy.

Oh shit I think that’s it! I’ve added that Z flag to each bind mount declaration in compose.yaml, and it seems to be running properly now. Thanks!

Any idea what the implications are of this transferring to an ubuntu based distro?

As far as I can tell, you just run the command with sudo to run as root? But this doesn’t help, I have been using sudo.

Edit: I think this is solved, someone else mentioned using the Z flag on the bind mount declaration and it seems to be working!

I’m already using bind mounts under the /home directory. I learnt pretty early on day 1 not to fight the distro, so I’m trying to understand the way Bazzite wants this to be done. From another reply, it sounds like it’s a difference in rootless/rootful containers so I’m going to try to work out how to run a podman container as root and see if this helps.

Thanks, I will have a go at trying to get it running as a rootful container!

I was running Nobara before, which is also based on Fedora, so not sure why it would be different in regards to SELinux?

I mentioned this in my original post.

Searching online shows everyone saying just use podman, it comes pre-installed and is a drop in replacement. The problem is that it doesn’t work.

But someone else has mentioned the issue is the containers are rootless by default, so I’ll explore that line of troubleshooting.

I guess my position is that I am not worried about someone confirming content exists on my server. But I don’t live in the US, if I did I might be more worried. I also geofence to my country to limit exposure.

Cheers for that. Many of these issues allow an authenticated user to do admin actions if they do the right things, so it seems you should never allow a user that you don’t fully trust to have an account.

But outside of this, there isn’t anything in there that on its own worries me given the nature of the platform (that is, that if it all burnt down I could retrieve all data from other sources). I’m no expert but a cursory look shows a bunch of potential issues that may be layered with other issues but no clear attack path except with prior knowledge.

These should obviously be fixed but there’s nothing that makes me want to rip my server off the open internet in a hurry.

What kids of things?

I’ve never worried that much because it’s not critical data and it’s containerised in Docker, but I am curious about specifics because large numbers of people expose it to the internet (through reverse proxies).

Isn’t there an assumption it would be behind a reverse proxy… At least I hope that’s the assumption.

Eh I don’t even need to think about this anymore. I have a cron job that backs up every March 31st.

No, they removed that clause some 2 or 3 years back.

I use Borgmatic for my scheduled backups, and sync to Backblaze B2 with Rclone. Works great!

My data doesn’t compress as well as yours though.

Docker wants you to use volumes. That data is persistent too. They say volumes are much easier to backup. I disagree, I much prefer the bind mounts, especially when it comes to selective backups.