I was in similar shoes (my server is running Debian, as it has been for the past two decades), and am going to rebuild it on something else. I chose NixOS, which I recently switched to on my desktop, because it lets me configure the entire system declaratively, even the containers. The major advantage of a declarative configuration is that it will never be out of date.
My main reason for switching is that I’ve been running the server for a good few years, initially maintained via ansible, but that quickly turned into a hellish bash-in-yaml soup that never quite worked right. So I just made changes directly. And then I forgot why I made a change, or had the same thing copy & pasted all over the place. Today, it’s a colossal mess. With NixOS, I can’t make such a mess, because the entire system is declared in one single place, my configuration.
Like you, I also planned to use containers for most everything, but… I eventually decided not to. There’s basically two things that I will run in a container: Wallabag (because it’s not so well integrated into NixOS at the moment), and my Mastodon instance (which runs glitch-soc, which is considerably easier to deploy via the official containers). The rest will run natively. I’ll be hardening them via systemd’s built-in stuff, which will give me comparable isolation without the overhead of containers. Running things natively helps a lot with declarative configuration too, a nice bonus.
For reference, you can find my (work in progress) server configuration here. It might feel a bit overwhelming at first, because it’s written in a literate programming style using org mode & org roam. I found this structure to work great for me, because my configuration is thoroughly documented, both the whys and hows and whats.
Better NixOS integration, less resources used, similar levels of containment. The containers I planned to use don’t provide any additional safety than the system services. In many cases, I could harden the system services more. Like, if a container has a /bin/bash in it, it’s hard to remove that, while I can pretty easily prevent my systemd service from accessing it.
Like, systemd.services.<name>.confinement is pretty darn strong. If enabled, NixOS will set up a tmpfs-based chroot with just the required runtime store paths for the service. Good luck doing something similar in a container!
I’m using an RX6700XT iirc, been having issues with it since day one. Somewhat random DE crashes. For the longest time I ran with only this, and not the above:
disclaimer: I’ve no idea what this does but it works for me
I’m not sure if the high-power udev rule improved anything, but for me electricity is cheap and my will to troubleshoot ran out.
right now I’m having issues with my monitors blinking at times. My 2nd monitor especially, sometimes 10 ‘disconnects’ in less than a minute, but often hours without a single one.
I’ve kinda settled on just accepting not knowing exactly what’s wrong, cause I’m not sure if it’s a bad GPU, bad config, wayland or hyprland screwing me over, and I’m kinda more overwhelmed by learning it than the problem itself.
I added the udev rule, but the issue was still happening when I resume after a suspend.
Strangely enough, I have not seen the issue since a clean install with only hyrpland (no Desktop environment installed alongside). No change to the rest of my config.
see Nix System Manager. Of course, you’ll have to be really creative with selective module imports if you want to use something as complex as Nextcloud.
All of the configuration options you’re specifying there are for the nextcloud NixOS module, it’s not a magical part of Nix itself. Same with the self and other arguments at the top. Outside of NixOS (and home-manager, for user-level installations), all Nix is going to be able to do for you is build software, it cannot do runtime configuration or other alterations to your system like that.
Thanks, that makes sense. When I saw the error about how self and config weren't being passed in, I assumed those must be values that NixOS gives you, not the plain package manager.
I saw a blog post a while ago that said you can basically get all the benefits of NixOS just by using the package manager. Sounds like that's not so true, although the package manager is definitely very cool by itself.
I think there’s a way that might be easy-ish. In short what the services setting does is to get necessary packages, write configuration files, and install systemd unit files. You can build a NixOS configuration, and symlink or copy the necessary systemd units and configuration files. I think that would work, and would not interfere with other stuff on your system.
NixOS configurations must be built with nixos-rebuild - you can’t use nix-build by itself. You can put your configuration wherever, and run:
That will build everything in paths under /nix/store/ without touching anything else on your system. It will create a symlink in your working directory called result/ with a fully-built, bot not installed, NixOS. If you were running NixOS you would run nixos-rebuild switch to update symlinks to point to all of this stuff. But you’d skip that step.
result/etc/systemd/system/ contains systemd units. There will be a lot of stuff there that you don’t want. You’d need to selectively symlink or copy units from this directory to your /etc/systemd/ tree.
The units use full paths to binaries in /nix/store/ so you don’t need to do anything extra to install software packages.
You might need to symlink or copy configuration files for your services. Those should also be somewhere in result/.
If NixOS and Debian use the same systemd target names your services should run automatically on boot. If not you might have to do some fix-up, or run systemctl commands manually. I think you’d need to run some systemctl commands to start and stop services if you want to update without rebooting.
You can probably do all that symlinking just once if you symlink everything through that result symlink.
Edit: Although, taking a closer look at what services.nextcloud does I see that it does a lot, like initializing databases and creating user accounts if you choose to use a local database. It might be a lot of work to chase down all of the configuration that you would have to copy over. Running NixOS is definitely going to be easier.
I realized I made an implicit assumption that I didn’t explain. You can use Nix without NixOS. But the configuration you’re looking at is specifically a NixOS configuration. The shortcuts for setting up nextcloud services are based on the NixOS module system. You could get the same setup with Nix without NixOS, but you’d have to reproduce some of the functionality that is provided out-of-the-box in NixOS. My answer is one way to use the functionality from NixOS without fully installing NixOS.
Oh, that's a really cool idea. I'll check that out just for my own nix education, although I'm a little leery about doing something so custom for my first nix setup, especially if services.nextcloud has a lot in it. Thanks for the info, though! That's really good to know about. I'll probably end up running NixOS in a docker container. The server is an Orange Pi 5, which doesn't have a stable NixOS image available for it, unfortunately.
Sounds like that's my best bet. My goal here was to stop using docker and use nix instead, but at least this would allow me to still use NixOS for the configuration and mostly ignore the fact that it's actually running in docker. I used the stones to destroy the stones kind of thing.
You can also use nix to get docker so, its kinda meta.
There’s a tool called devbox that uses nix under the hood and has services. Probably not what you’re looking for, but its nice to know there are people working on a native solution.
I am pretty certain you’ll need to be using NixOS, as the goal of the blogpost from my reading is about having an OS configured specifically for NextCloud hosting on Nix in a performant way
However, having a faster and more optimized setup can take some effort on these platforms. Thankfully, on NixOS it’s not hard at all, as I’ll show you.
I see, thanks. I hadn't realized the difference between installing one package vs. configuring the system. (And in the case of creating a server setup, that would be configuring the system.) Well, that's good to know.
What’s still not obvious to me is the remote management of the nix config on 500 machines. Without a config management system like Ansible, how to you push a change to those systems?
I’m far from an expert on NixOS but using another package manager with nixos seems like it would defeat the entire purpose of the distro. It really seems like you must be ok with creating your own packages.
I can’t answer the “how to make it work” part, as I’m on a different device using a Guix System. But yes, I can vouch that what you’ve done is actually wrong. There’s no entry for Krita under NixOS options. The program.<name> options are defined here. Someone will have to create a custom expression just for the Krita fork of G’Mic. Might as well have to involve patches.
nixos
Hot
This magazine is from a federated server and may be incomplete. Browse more on the original instance.