Closed Misterio77 closed 1 year ago
Thanks for the contribution! I'm glad the module is working well for you, and I'll certainly look out for what you do with it in the future, if it ends up being public. (Note to self: Perhaps an 'Examples in the Wild' section of the readme?)
The addition definitely makes sense, though I do shake my fist in the direction of the plugins and servers that don't gracefully handle read-only files. (Aside: Did you know that LuckPerms requires write access to your mods/plugins folder to do its own dependency management? It really did not like being in the Nix store lol)
The file backup scheme is sound, and is good to see.
One potential problem with this is files that are left over from files being renamed or removed from the Nix-side, since the file under the old name isn't removed.
This is also a problem for symlinks
that I haven't really figured out yet, and honestly, I'm not sure what a satisfactory solution for it would be.
This hasn't been much of a problem in my case for a mods
directory because I use linkFarmFromDrvs
to make a single folder to symlink in, instead of single-mod symlinks, but the latter use-case should be supported properly, which it isn't yet.
Perhaps a post-exit script to remove files and clean up symlinks? Not sure what the correct solution is.
Overall, looks good to me! I am curious if you have any ideas on how to handle the renamed/moved file problem, though.
Thanks a lot for your kind words!
I'm glad the module is working well for you, and I'll certainly look out for what you do with it in the future, if it ends up being public. (Note to self: Perhaps an 'Examples in the Wild' section of the readme?)
Feel free to take a look (very much WIP!): https://github.com/Misterio77/nix-config/blob/main/hosts/electra/services/minecraft/default.nix. I've packaged a few other servers (velocity, paper) and created a couple helper functions for writing YML and TOML configs; simple stuff, but configuring everything in nix makes the experience so much better!
The addition definitely makes sense, though I do shake my fist in the direction of the plugins and servers that don't gracefully handle read-only files. (Aside: Did you know that LuckPerms requires write access to your mods/plugins folder to do its own dependency management? It really did not like being in the Nix store lol)
Absolutely insane. There's a few plugins that will refuse to work if they can't "fill in the blanks" in your config, some will refuse to work even if the config is complete but readonly, while a few others simply won't work if there's missing fields at all!
This hasn't been much of a problem in my case for a mods directory because I use linkFarmFromDrvs to make a single folder to symlink in, instead of single-mod symlinks, but the latter use-case should be supported properly, which it isn't yet.
I wish plugins did the same as mods and place their configs in a separate directory so I could use linkFarmFromDrvs
, oh well
Perhaps a post-exit script to remove files and clean up symlinks? Not sure what the correct solution is.
This is actually something I just tackled right now! Here's the commit from the post-stop
branch: https://github.com/Misterio77/nix-minecraft/commit/1d38d8a9a16ee3c15bc321664255c4a16c16702c.
I also noticed that eula.txt
, server.properties
, and ops.json
could simply be files
and symlinks
, so I grouped them together in that commit.
I commented on it in the commit itself (not sure if you get notifications for that). My only concern with how it was implemented was the changes to the unlink/remove/backup&move logic.
(If I want to get nitpicky, I think the eula/whitelist/server properties actual derivations should be made separately in the let-block, since how they are defined right now feels dense and hard to read, but that doesn't really matter)
Oops didn't quite see your previous comment. I'm gonna go ahead and pull the postStop commits into this branch and integrate your feedback!
Rebased and ready to go!
@Infinidoge, I've recently made a change that allows users to specify placeholders on files that will be replaced by values from an environmentFile
upon copying them. This allows servers to safely configure plugins with databases credentials and other secrets.
I'll push the change to this branch, but I can open a separate PR if you prefer.
Hmm,
I'd say leave it in the PR for now, since it's somewhat intrinsically tied to the files
option.
Hey @Infinidoge, I've been away for a little while busy with life stuff, but now everything's awesome and I can get back into this.
Is there anything I can do to help push these features forward? Do you happen to have any new suggestions?
I'm very interested in your project and I'd love to help make it the absolute best solution for building declarative minecraft networks!
(Fixed conflicts)
Sorry for taking so long to finally address this. My school semester just ended, so now going back through and getting things done.
Hello!
First of all, thanks a lot for this awesome module!
I've been trying to get a full minecraft server network going, and it's been going great! I've made a couple of changes for my own use, so here's one of them, in case you're interested.
The ideia is that a lot of configuration files (specially plugins) behave terribly when faced with the read-only fs link destinations. Paper, for example, completely crashes if
config/paper.yml
is read-only. A solution I've come up with is adding afiles
option that behaves similarly tosymlinks
, but it dereferences the file, making it mutable. That way, the plugin/mod/server can behave as expected, while keeping reproducibility (as the files are copied again each time the service starts).An existing file with the same name is only backed up if: 1) it's not a symlink 2) it's different to the one being copied (that way a useless
.bak
won't replace a potentially useful one).I've also went ahead and added a
mkdir
command, so that any parent directories are created (both for files and for symlinks).