Factorise other configuration options #22
No reviewers
Labels
No labels
blocked
project-management
question
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: Fediversity/Fediversity#22
Loading…
Reference in a new issue
No description provided.
Delete branch "factorise-other-config"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
This PR builds on top of #21; it factorises the other options that are in common between all configurations.
system.stateVersion
bd2f65a963nixpkgs.hostPlatform
bb99a2a4c2networking.useDHCP
e908954b8cenvironment.systemPackages
e663179fd1security.sudo.wheelNeedsPassword
612517e4c1nix.settings.trusted-users
2403f14c73services.xe-guest-utilities
@ -7,0 +16,4 @@
system.stateVersion = "24.05"; # do not change
nixpkgs.hostPlatform = mkDefault "x86_64-linux";
## REVIEW: Do we actually need this?
yes because then you can ditch passwords entirely. you already have authorization when getting logged in over SSH, why would you type random strings into your keyboard again?
I was wondering what security specialists thought about this. @koen said on Matrix that they very much dislike direct
root
SSH, but they were fine with password-less sudo, so let's keep this option then.@ -7,0 +21,4 @@
nix.settings.trusted-users = [ "@wheel" ];
environment.systemPackages = with pkgs; [
my rant won't fix it, so this is not a change request, but for the record: everyone should just bring their own tools to the server via ssh, there's technically no need to clutter the config with some random preferences that will never age well.
there's a thing called sshrc that demonstrates the principle, but these days with Nix you can have your exact favorite environment, defined locally on each remote login via SSH. to my surprise, no one seems to have thought it through to write the handful lines of bash and Nix required for that, but in my humble opinion this is how it should be done.
I very much agree with all this, and I was not happy copying these packages, but I decided that it was easier to just refactor, and to discuss this later. I have started keeping track of this discussion in #25.
@ -1,5 +1,3 @@
{ lib, ... }:
I recommend keeping
so it's clear at first glance that it's a module.
37b1cc01c4
tofca563a987