Sure, that goes with it. Good reminder.

Any plans to support FreeBSD in the future? Or mainly focusing on a docker solution?

So far the only real vulnerabilities that Ai have spun up seem to be really obscure edge case privilege escalation bugs that have been around for ages but nobody discovered. They then get patched in days if not less. I would expect them to run out of low hanging fruit pretty soon.

Most of them can even be mitigated by preventing local access to a system.

There's tools to audit your network and systems. You can setup a SIEM like Wazuh. It'll tell you the same kind of stuff that have been good practice for a while and mitigate most of the ai assisted vulnerabilities.

Prevent password logins where ever possible too, especially SSH. Use ed25519 keys. Perform server actions with least privilege users, prevent root logins. Immutable systems and containers are a helpful tool too.

I also just host my public facing stuff on a VPS. DDOS protection and just otherwise isolated. 2FA on the VPS too.

I have a directory in my home folder for all my different docker containers. I back that up like my other critical files on my NAS, Backup NAS, cloud storage and external drive. Its all scripted to happen periodically.

The docker compose files I also upload to my local Git so I can version them. Make the git ignore skip everything that isn't a .yml

If you would want to spin them up again, yeah you could just copy them in a new place, make sure the docker-compose.yml is at the top and docker-compose pull the image, then docker-compose up. If your yml specifies that your configs are ./ , it'll know to look for them in the same folder as your yml and begin its file paths there. Anything outside your ./ in theory should be read only or be some kind of data off a NAS that is independent from the service. Its just not best practice in my eyes for your docker application to write outside of the folders beneath its docker-compose.yml location.

Just organize your volumes correctly and you can move the docker container anywhere you want with a copy paste and a docker-compose up. Imo docker-compose is WAY easier and faster than any GUI instance of Docker.

Distros are tools for a job. I stick with the ones that have the most helpful communities and/or the best documentation. I avoid communities that tell you off for asking help or documentation that is obtuse.

Still successfully troubleshooting stuff through 10 year old Ubuntu forum threads. Meanwhile learning the most through the FreeBSD handbook and it's not even Linux. lol

Hell yeah! I was using Ubuntu 10-14 in college and now back on the train with 24, 25 and 26. Everything just works every time and all the professional apps I need are first class citizens and well supported.

Ubuntu Server, FreeBSD and OpenBSD are my server distros of choice as well. FreeBSD for a NAS. Gotta pick the right tools for the job!

Fuck yeah! This slaps. Brb while I get my headphones to listen to it again.

We should celebrate these kinds of changes. Like its great that they've already achieved so much and not just that, but left behind a group of folks just as committed in the future of the project.

I always feel that posterity of your work beyond your own contribution is the real achievement and a sign of humility.

Oh, I've been there! lol Yeah, you sometimes don't expect to have to update an entire stack, not just one thing. Possible the companion app image was just released later and it wasn't on you either. :P

But yeah, give the cron job a try. I'd be curious to try it out myself! In theory your webinstance shouldn't cut out unless you click on something the exact moment the container is resetting.

What kind of issues have you had? How did you resolve them?

I haven't used this tool specifically, but anything involving Youtube is always going to be an uphill battle. In the instance of a video downloader like Channeltube, you frequently need to feed it fresh cookies to make sure Youtube doesn't flag it as a bot. I assume this is a similar situation.

The requirements also list ''2gb if you restart frequently'' so there might be a memory leak issue, or the way it's setup means the RAM usage will increase in perpetuity.

I would just script a task to restart the docker container every hour. Shouldn't be too much a hassle, you're unlikely to ever notice since it shouldn't take more than a few seconds. I would track its RAM usage over a few days too. See if there's something fishy happening. Something like Beszel will let you track your docker socket, so usage per container. Preferably left on read only imo.