Describe the bug

I'm using DHCP on a cloud provider and srvos seems to not like it:

error: The option `networking.useDHCP' has conflicting definition values:
       - In `/nix/store/b04ysr6cypqgwhrz5180l9q26skj2nq2-source/nixos/common/networking.nix': false
       - In `/nix/store/jb02bxn7gpplmjcilj7cv120m0rxh1bm-source/hosts/ovh/hardware-configuration.nix': true

If I remove the networking.useDHCP = true then the network interface doesn't get an IP.

DigitalOcean has a web console. Does it mean it's not headless?

Is your feature request related to a problem? Please describe.

In commit 43d2842 all nix files were chosen to be self-referenced using _file attribute to be better supported by nix flake check.

Describe the solution you'd like

I think it would be important to document why this choice was made for newcomers, for example a note of its use in README.md, and importantly, any possible open issues that track this issue upstream.

Describe alternatives you've considered

Not documenting its usage, risking teams not applying this pattern correctly, or even wanting it removed because they do not see its value for being there.

Additional context

When reading over the source code, especially if you are new to nix, the use of _file = file.nix may seem very counter intuitive and strange to read. Since surely nix knows where its own files are, right?

Is your feature request related to a problem? Please describe.

Hi,

why isn't /nixos/hardware/hetzner-online/default.nix exposed in nixosModules or imported by /nixos/hardware/hetzner-cloud/default.nix?

In particular - I have no idea how baremetal works on Hetzner, but the way of setting up IPv6 should be exactly the same between cloud and online. Perhaps these two should have some shared networking module?

Is your feature request related to a problem? Please describe.

The images published by the NixOS projects don't have cloud-init enabled by default.

Describe the solution you'd like

For each commit on master, build and publish new images.

Describe alternatives you've considered

Additional context

Just now we only target nixos-unstable. I am leaning into having release branches to avoid having to put conditionals in the code whenever module options changes.

Isn't cloud-init already set in cloud-init.nix?

nixos-anywhere generates a temporary ssh key for deployment. it puts it into $HOME/.ssh which

won't allow for security.

How can I use the nixpkgs default in my flake?

We currently have the following 3 dependencies:

• nixpkgs (only used for testing)
• flake-parts (Used but not really needed since we don't have to write the normal boiler code for to access packages.<system> for nixos modules)
• flake-compat (not used in the flake but by the old model)

I think we can move nixpkgs and flake-compat to a subflake only used for development. In this new flake we can also add things like linters and auto formatters needed by the project without bloating up the dependency trees

Advantages of this move: Usually you want to set up srvos.follow.<input> for many dependencies in your project. Not having those makes it easier to use srvos. There is a point to make that some users might want to use our tested nixpkgs version, however in practice I see it more often that users need to update nixpkgs with their own pace (or maybe their own fork) rather relying on a third party to make a move.

Is your feature request related to a problem? Please describe.

When calling nixpkgs.lib.nixosSystems, all the NixOS modules of the repo are getting loaded, making the evaluation quite expensive.

Describe the solution you'd like

Provide a compatible function that only loads a subset of the nixpkgs NixOS modules.

Describe alternatives you've considered

Additional context

I just updated srvos, but ran into problems :

$> nix flake lock --update-input srvos
warning: updating lock file '/home/palo/dev/nixos/nixos-config/flake.lock':
• Updated input 'srvos':
    'github:nix-community/srvos/5d4550de420ee501d7fa0e6cd9031cd00354554c' (2024-05-27)
  → 'github:nix-community/srvos/414d1039a58b667e4512ad9f7068aa935ebf8d59' (2024-05-30)
• Updated input 'srvos/nixpkgs':
    'github:NixOS/nixpkgs/b5995681aa319d0e33a6d83a31710d6c6f092820' (2024-05-26)
  → 'github:NixOS/nixpkgs/c598bbfe379934e8f379bc474cc1914a7c34fbdc' (2024-05-29)

$> clan machines update orbi
All secrets and facts are already up to date
...
[orbi] updating GRUB 2 menu...
[orbi] Error: Failed to load unit file /etc/systemd/system/zfs-import-zmedia.service
[orbi]
[orbi] Caused by:
[orbi]     3:39 unknown character in \xHH form
[orbi] warning: error(s) occurred while switching to the new configuration

setting

system.switch.enableNg = false;
system.switch.enable = true;

fixes the issue.

I couldn't find out which file contains the \xHH (in 3:39).

Stage 1 networking and systemd should work since NixOS/nixpkgs#169116

For some reason I can't activate a nix-config using srvos on digitalocean.

I'm not done testing, but it seems I had to set this:

  networking.useNetworkd = false;
  networking.useDHCP = true;
  networking.nameservers = [ "1.1.1.1" "1.0.0.1" ];

Also, I don't know if digitalocean has cloud-init and if it matters.

old issue #287

Is your feature request related to a problem? Please describe.

Right now, the runners are accepting multiple jobs, and that can leave some files around. Runners can run arbitrary code and are open to the world to be executed.

Describe the solution you'd like

I don't know if that's already the case but the design would be:

• Use a DynamicUser
• Use a PreStart that wipes the WorkingDirectory
• Configure the runner so that it only runs a single job and then exists
• Configure the unit, so it gets restarted on exit.

Describe alternatives you've considered

Additional context

What do you think @jfroche ?

Is your feature request related to a problem? Please describe.

I tried to use common module but the upgrade diff does some weird stuff and the activation fails. I don't need that diffing, it would be cool if there is a option to disable it

Is your feature request related to a problem? Please describe.

Cloud-Init together with the networking here does not work as cloud-init generates a network configuration which will be loaded first.

Solution is to delete /etc/systemd/network/10-cloud-init-enp1s0.network and then restart networking then the NixOS configuration works

flake.nix

{
  description = "My machines flakes";
  inputs = {
    srvos.url = "github:numtide/srvos";
    nixpkgs.follows = "srvos/nixpkgs";
  };
  outputs = { self, nixpkgs, srvos }: {
    nixosConfigurations.myHost = nixpkgs.lib.nixosSystem {
      system = "x86_64-linux";
      modules = [
        srvos.nixosModules.server
      ];
    };
  };
}

❯ nix build .#nixosConfigurations.myHost
error: 'nixosConfigurations.myHost.type' is not a string but

Is your feature request related to a problem? Please describe.

A bunch of customers are using Azure.

Describe the solution you'd like

A new hardware profile optimized for Azure.

Describe alternatives you've considered

Additional context

Is your feature request related to a problem? Please describe.

Currently a lot of folders inside ./nixos follows a set of "concepts" so to say, like hardware, mixins, modules, and roles. It seems out of place that the default configs for servers and computers are put into this top level, especially since they are both essentially single files of default.nix.

Describe the solution you'd like

This is very much up in the air, and very much for discussion. But something among the lines of ./nixos/kind/server.nix or ./nixos/kinds/computer/default.nix could be a better structure here to follow the idea of having top level "concepts".

Describe alternatives you've considered

Continuing having the ./nixos/computer and ./nixos/server folders.

Additional context

Describe the bug

I noticed that hosts tend to get new SSH keys on reboot. It might be a bug in cloud-init.

To Reproduce

I don't have a good repro right now. It happened to me multiple times, both on Hetzner Cloud and Vultr that the sops-nix age keys are different and the host cannot decrypt the secrets anymore. TBI.

Expected behavior

Keep the same SSH key-pair once it's generated.

System information

Additional context

This file defines the option services.openssh.authorizedKeyFiles, which now causes the failed assertion:

The option definition `services.openssh.authorizedKeysFiles' in `/nix/store/7q9yw6ka5wkdb5slmk69g6v0cyzivrvz-source/darwin/common/openssh.nix' no longer has any effect; please remove it.

since this commit.