Init project demos

[eljamm]

To test this, you can run:

$ nix-build . -A demo-test
$ ./result

Closes #696

[erictapen]

Nice! The examples don't work yet though, as they lack their module?

$ nix run .#project-demos.Keyoxide/keyoxide-web
error:
       … while evaluating the attribute 'config.system.build.vm'
         at /nix/store/crrwsv142k1vkwdba7q26y73760n4bll-source/lib/modules.nix:336:9:
          335|         options = checked options;
          336|         config = checked (removeAttrs config [ "_module" ]);
             |         ^
          337|         _module = checked (config._module);

       … while calling the 'seq' builtin
         at /nix/store/crrwsv142k1vkwdba7q26y73760n4bll-source/lib/modules.nix:336:18:
          335|         options = checked options;
          336|         config = checked (removeAttrs config [ "_module" ]);
             |                  ^
          337|         _module = checked (config._module);

       (stack trace truncated; use '--show-trace' to show the full, detailed trace)

       error: The option `services.keyoxide' does not exist. Definition values:
       - In `/nix/store/y54pzyxbd1bdf8i4pzg1yvq0q7q0jl24-source/projects/Keyoxide/keyoxide-web/example.nix':
           {
             enable = true;
           }

[eljamm]

Yeah, let's just keep importing all the modules for now. The example in the description is probably not the best either. I'll change that in a second.

[eljamm]

One thing I'm thinking about is that we could probably make 2 types of VMs depending on what the example needs:

• Graphical with GPU acceleration (OpenGL or Vulkan)
• Minimal CLI only

Or we could run everything in a graphical VM and have the experience be close to what it feels like using NixOS as a users.

[erictapen]

Yeah I was thinking about how much customisation each demo VM might need. My tendency would be to keep stuff as minimalistic as possible, e.g. a service that mostly provides a web interface should not boot a display manager.

[fricklerhandwerk]

Yes, another heuristic is to look at the intended use case, one of which is self hosting web services -- we don't need a GUI there.

[eljamm]

Fully contained Cryptpad demo, with ssh and service ports forwarded to the host:

# default.nix
{
  ngipkgs ?
    import
      (fetchTarball "https://github.com/eljamm/ngipkgs/tarball/init-project-demos/8eb7f038fd62fd6490e017d78e6a30e7b64a13fa")
      { },
}:
let
  servicePort = 9000;
  domainName = "localhost:${toString servicePort}";
in
ngipkgs.demo {
  services.cryptpad = {
    enable = true;
    settings = {
      httpPort = servicePort;
      httpAddress = "0.0.0.0";
      httpUnsafeOrigin = "http://${domainName}";
      httpSafeOrigin = "http://${domainName}";
    };
  };

  networking.firewall.allowedTCPPorts = [ servicePort ];
  networking.firewall.allowedUDPPorts = [ servicePort ];
}

$ nix-build
$ ./resullt

[imincik]

Having a disk image is useful because it allows you to work with larger data and it stores the state between multiple VM runs (data, shell history). Disadvantage is that it creates disk image file on your hard drive (qcow2 file).

Suggested change

diskImage = null;

[imincik]

• When diskImage is not disabled, root fs is mounted to real disk image:

/dev/vda on / type ext4 (rw,relatime)

• When diskImage = null;, root fs is mounted to tmpfs which is VM's memory

tmpfs on / type tmpfs (rw,relatime,mode=755)

[eljamm]

When diskImage = null;, root fs is mounted to tmpfs which is VM's memory

So I imagine this would be a problem for examples that require a lot of space, correct?

[imincik]

I would keep default port value.

Suggested change

ports = lib.mkDefault [ 2222 ];

[eljamm]

The default won't work if the ssh server is already running on your machine since that would cause a conflict, as you mentioned in your other comment:

Could not set up host forwarding rule 'tcp::22-:22'

I think 2222 is a sane default, which can still be overwritten by the users is they wish. We just need to document this.

[imincik]

I suggest to keep all port numbers standard/default on guest machine to avoid confusion.

SSH can run on port 22 on guest machine. But it needs to be forwarded to some other value on host - for example 10022.

We can use following port forwarding formula:

• if guest port number is < 100 then host port number = 100
• if guest port number is 100 - 1000 and then host port number = 10
• if guest port number is > 1000 and then host port number = 1

[eljamm]

SSH can run on port 22 on guest machine. But it needs to be forwarded to some other value on host - for example 10022.

How would the user change it in this case?

We can use following port forwarding formula:

I'm not sure I follow the logic here. If we have 2 guest ports: 20 and 30, then they'll both be mapped to 100 according to the formula.

[eljamm]

Further more, it could also be odd or confusing for users to set up a port and find it mapped to another and I don't see us touching any other non-service example ports, aside from ssh.

[eljamm]

That said, if this is really an issue, I think it would be sufficient to map each guest port to port + 10000 in the host and add that as a note in the instructions.

[imincik]

That said, if this is really an issue, I think it would be sufficient to map each guest port to port + 10000 in the host and add that as a note in the instructions.

Yes, I like this idea.

[imincik]

Ports can't be forwarded to the same value to the host. This might cause conflict on host or might not be permitted (forwarding ports under 1024).

[eljamm]

If a service port is not available on the host, users can just change it from the config to something that is and that will be forwarded instead.