Justin

scp is one of the best options. You could also try sshfs if you want something more interactive.

This wiki page has an example on how to do automatic updates on a normal install of nixos:

https://nixos.wiki/wiki/Automatic_system_upgrades

But this won’t work for nixos-generate because nixos-generate doesn’t have a configuration.nix file in the booted system.

Here is the code I use for my nixos-generate flake that I use to generate all of the nixos images in my homelab:

https://codeberg.org/jlh/h5b/src/commit/763a873c5bb7a4706ad021ea5ac3634b4efeadce/nodes/common.nix#L113

The way this works is that it includes the flake source code as a folder in the nix store on the booted system, and the nixos-upgrade timer will then use the flake to build an updated version of itself. Note that nixos-generate uses the packages output of the flake, while nixos-upgrade uses the nixosConfigurations output of the flake. I have written the flake so that they build identical systems, but it means there’s some code that I had to write twice in flake.nix.

Feel free to try it out yourself, though note that you will probably have to rip out the agenix stuff to get it to build.

Nixos isnt really that user friendly yet, but insanely powerful once you understand how it works. Feel free to ask questions if anything seems confusing.

NixOS works really well as an image based server. Use nixos-generate to create a pre-configured image and put it on a flash drive/PXE share, and you’re good to go. Automatic updates are a bit confusing and not really documented, but doable. I have code examples.

There’s a wid range of opinions on this. Some people only access their services via tunnel, some people open most of their services up to the internet, as long as they’re authenticated. One useful option for https services is to put them behind a reverse proxy that require oauth authentication, which allows you to have services over the internet, without increasing your attack surface. But that breaks apps like Nextcloud and Lemmy, so it’s not a universal option.

That requires running either systemd or dockerd to work.

Docker containers often need to be restarted if they crash, I’m not aware of a solution for this that isn’t a monolithic service orchestrator, like systemd, dockerd, or containerd.

I’ve never used it, but I believe cockroachdb is also an option for multi-region replication.

In Swedish, we have the word “riktig”, but I guess that’s a bit of a shifted cognate, since it means “real”.

I think Lemmy is glitching out here. My comment was a reply to a now deleted comment by just_another_person. It seems that after the comment was deleted, it messed up how the thread appears. Sorry for the confusion.

OP is asking for a guard dog to keep robbers from walking through their unlocked door. I’m telling OP to just lock their door and don’t bother with a guard dog.

I respectfully disagree. Containers are 100% the right choice in this situation. They provide the defense-in-depth and access controls that combat the threats that OP is targeting by using ClamAV.

The goal isn’t securing a single database through a single attack vector. And it’s not like ClamAV would help you with that, either. The goal is preventing attackers from using your infra’s broad attack surface to get inside, and then persisting and pivoting to get to that database.

It’s just not true that you can get the same level of security by running everything bare-metal, especially as a one-man, self-hosted operation.

You can point a Cloudflare proxy at an IPv6 address, and you’ll then be able to access the website via IPv4.

Sure! I got my start with this sort of tech, just running docker containers on my home server for running stuff like nextcloud and game servers. I did tech support for a more traditional web hosting MSP for a while, and then I ended up getting hired as a DevOps trainee for a internal platform team doing Kubernetes. I did some Kubernetes consulting after that and got really experienced with the tech.

I would say to try running some Docker containers and learn the pros and cons with them, and then I would say to start studying for the CKAD certification. The CKAD cert is pretty comprehensive and it’ll show you how to run docker containers in production with Kubernetes. Kind is a great way to get a Kubernetes cluster running on your laptop. For more long term clusters, you can play around with k3s on-prem, or otherwise, I would recommend Digital Ocean’s managed Kubernetes. Look into ArgoCD once you want to get serious about running Kubernetes in production.

I think with a CKAD cert you can land a Kubernetes job pretty easily.

I would probably only recommend the CKA cert on the path to CKS. CKA gets into a lot of the nitty gritty of running a kubernetes cluster, that I think most small-to-medium companies would probably skip and just run a managed solution.

Kubernetes has a steep learning curve, since you need to understand Operations top-to-bottom to start using it, but once you have it in your tool belt, it gives you endless power and flexibility when it comes to IT Operations.

I dont see how anything I said justifies you calling me names and calling me bad at my job. Chill out.

Containers allow for more defense-in-depth, along with their multiple other benefits to maintability, updatability, reproducibility, etc. Sure, you can exploit the same RCE vuln on both traditional VMs and containers, but an attacker who gets shell access on a container is not going to be able to do much. There are no other processes or files that it can talk to or attack. There’s no obvious way for an attacker to gain persistence, since the file system is read-only, or at least everything will be deleted the next time the container is updated/moved. Containers eliminate a lot of options for attackers, and make it easier for admins to setup important security systems like firewalls and a update routine.

Obviously containers aren’t always going to be the best choice for every situation, architecting computer systems requires taking into account a lot of different variables. Maybe your application can never be restarted and needs to have a more durable, VM solution. Maybe your application only runs on Windows. Maybe your team doesn’t have experience with kubernetes. Maybe your vendor only supplies VM images. But running your applications as stateless containers in Kubernetes solves a lot of problems that we’ve historically had to deal with in IT Operations, both technically and organizationally.

I’m a senior Linux/Kubernetes sysadmin, so I deal with system security a lot.

I don’t run ClamAV on any of my servers, and there’s much more important ways to secure your server than to look for Windows viruses.

If you’re not already running your servers in Docker, you should. Its extremely useful for automating deployment and updates, and also sets a baseline for isolation and security that you should follow. By running all your services in docker containers, you always know that all of your subcomponents are up to date, and you can update them much faster and easier. You also get the piece of mind knowing, that even if one container is compromised by an attacker, it’s very hard for them to compromise the rest of the system.

Owasp has published a top 10 security measures that you can do once you’ve set up Docker.

https://github.com/OWASP/Docker-Security/blob/main/dist/owasp-docker-security.pdf

This list doesn’t seem like it’s been updated in the last few years, but it still holds true.

1. Don’t run as root, even in containers

2. Update regularly

3. Segment your network services from each other and use a firewall.

4. Don’t run unnecessary components, and make sure everything is configured with security in mind.

5. Separate services by security level by running them on different hosts

6. Store passwords and secrets in a secure way. (usually this means not hardcoding them into the docker container)

7. Set resource limits so that one container can’t starve the entire host.

8. Make sure that the docker images you use are trustworthy

9. Setup containers with read-only file systems, only mounting r/w tmpfs dies in specific locations

10. Log everything to a remote server so that logs cannot be tampered with. (I recommend opentelemetry collector (contrib) and loki)

The list goes into more detail.

I agree that DAVx^5 is really good. OP is from Mastodon, which might explain the funny post title.