I was looking to manage my server through Cockpit project.

I would like to also be able to use cockpit-machines to manage VMs on my server. However, that module is not present in nixpkgs.

I know how to deploy simple-ish packages, however, JS based projects seem a bit complicated.

https://github.com/cockpit-project/cockpit-machines

Could you suggest a starting point with this project? Any similar modules I can refer to?

  • Atemu
    3·
    1 year ago

    Step #1 is to package cockpit-machines. I haven’t dared to touch JS with even a 10ft pole, so I can’t help you with that but I can highly recommend to take a look at how similar packages work and copy what they do.

    Modules come later; they just wire up some packaged applications to the system. I’m not familiar with the project but it seems like cockpit-machines is a UI of sorts? If it doesn’t need any system configuration, you don’t need a module. Users would just install the package, run the binary and that’s that.
    Modules are for when you need e.g. a system service like a web server.

  • Matej@matejc.comEnglish
    2·
    1 year ago

    You need a Nix package first, so how I do this for NodeJS is, clone your NodeJS repo to your computer, then you will need node2nix to package it (https://github.com/svanderburg/node2nix). You can use this command inside the repo: node2nix -18 (you need to specify -18 since by default node 14 is being used). After nix files are generated, you can test it by running nix-build -A package. Now that you have this done, its time to make a PR to nixpkgs and add all the new generated files along with package.json and that is your cockpit-machines package.

    After all this its time to integrate into existing cockpit NixOS module. I would maybe add a new option called extraPackages, like so: services.cockpit.extraPackages = [ pkgs.cockpit-machines ];. On the other hand you could just add option to the cockpit package option, like so: services.cockpit.package = pkgs.cockpit.override { enableCockpitMachines = true; };. This might be easier.

    ps: I havent tested this so ask if you have any difficulties

    • sashkaOPEnglish
      1·
      1 year ago

      I wanted to say thanks for the detailed post.

      I was able to make some progress on packaging the project. A few issues I faced:

      • node2nix was not including devDependencies by default. It’s possible with the -d flag, but that would include all devDependencies into the final build, and I could not find a way to remove that for production build.
      • I tried skipping node2nix, and simply included package-lock.json file, this worked, but there were more difficulties
      • Machines (the plugin) requires source repository of the cockpit-project. I first tried building the plugin from the cockpit-project package, but that did not seem very clean. I then created a separate package like you suggested, and listed 2 project sources, that seemed a bit cleaner, and now that package can be included from cockpit-project package, avoiding circular dependency.
      • This all worked! Great! I had modified the cockpit-project package to include the plugin, and was able to have the package successfully (or so…) and copy it over so it’s found.
      • And yet, there does not seem to be clear compatibility matrix between the cockpit-project, and the plugins. Makefile for the machines plugin simply includes the commit hash of the parent project, and includes its libraries in the build process.
      • Unfortunately, the build did not result in the working plugin, and this is where my expertise in troubleshooting node applications comes to a limit.

      Despite the failure of the outcome (I don’t think I am willing to invest more time into this build right now) I learned a ton about building nix derivations, packaging software, and various troubleshooting tips.

      I was able to hack on a project really successfully, using nix repl. However, to test that on my system, I had to fork nixpkgs, include that in my flakes, and rebuild the system. I would like to find a more isolated, easier way to test my packages, without affecting my main system.

  • chkno
    2·
    1 year ago

    If you haven’t read through them already:

    It looks like cockpit has been packaged and moduled. Maybe look at cockpit’s package and module definitions for inspiration for cockpit-machines? It looks like cockpit is a hybrid python+javascript project and has been packaged primarily as a python package, and cockpit-machines is also a hybrid python+javascript project but maybe the python aspect is less central, as I don’t see a top-level pyproject.toml, so you may not be able to exactly mimic the cockpit package?