openvpn3: init at 13_beta

[SCOTT-HAMILTON]

Motivation for this change

Closes #120116

Things done

• Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
• Built on platform(s)
  • NixOS
  • macOS
  • other Linux distributions
• Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
• Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
• Tested execution of all binary files (usually in ./result/bin/)
• Determined the impact on package closure size (by running nix path-info -S before and after)
• Ensured that relevant documentation is up to date
• Fits CONTRIBUTING.md.

[SuperSandro2000]

diff LGTM, not sure if it works and would be secure to use.

[SCOTT-HAMILTON]

Maybe @benshaw could tell us if it worked for him.

[benshaw]

Maybe @benshaw could tell us if it worked for him.

I will try testing this tonight and let you know how it goes.
Thankyou!

[benshaw]

@SCOTT-HAMILTON unsure if this is todo with your work or if there is some other steps required but Im getting an error ** ERROR ** Could not establish a connection with 'net.openvpn.v3.configuration'
From my quick research i was able to find this

> The default configuration for the services assumes a service account openvpn to be present. If it does not exist you should add one

But even after following the instructions and adding the user "openvpn" user and "openvpn" group i still get the error.

The only other report i could find of this issue was in arch and there solution was to change the ownership of the app (https://bbs.archlinux.org/viewtopic.php?id=262372) but obviously this wont work in nixos

[SCOTT-HAMILTON]

Ok, do you know how I could reproduce this error ?

[benshaw]

create a sample.opvn file https://github.com/OpenVPN/openvpn/blob/master/sample/sample-windows/sample.ovpn
run any command using this file, i have been using openvpn3 config-import --config sample.opvn

[benshaw]

@SCOTT-HAMILTON see discussion here for more information OpenVPN/openvpn3-linux#42

[benshaw]

@SCOTT-HAMILTON How is this going? Anything i can do to help ?

[SCOTT-HAMILTON]

To be honest this PR should probably be maintained by someone that actually uses and knows well openvpn3. I'll make it as draft until either someone accepts to maintain it or someone finds what's wrong.

[peterhoeg]

It looks like you cannot run this on its own - you need to either make the existing openvpn module handle this or do a minimal new module that at the very least creates the required user and registers the files for dbus.

[benshaw]

To be honest this PR should probably be maintained by someone that actually uses and knows well openvpn3. I'll make it as draft until either someone accepts to maintain it or someone finds what's wrong.

@SCOTT-HAMILTON Unfortunately i am new to both openvpn3 and nix but ill do some research in my spare time and see what i can figure out. Thanks for the effort and work so far !

[benshaw]

It looks like you cannot run this on its own - you need to either make the existing openvpn module handle this or do a minimal new module that at the very least creates the required user and registers the files for dbus.

@peterhoeg do you know what else needs to be done for dbus services ? The package @SCOTT-HAMILTON put together creates the services in the appropriate location

/nix/store/58kpy1fhl4fc0imzyqr6zdys4rnad60d-openvpn3-13_beta/share/dbus-1/system-services/net.openvpn.v3.sessions.service
/nix/store/58kpy1fhl4fc0imzyqr6zdys4rnad60d-openvpn3-13_beta/share/dbus-1/system-services/net.openvpn.v3.netcfg.service
/nix/store/58kpy1fhl4fc0imzyqr6zdys4rnad60d-openvpn3-13_beta/share/dbus-1/system-services/net.openvpn.v3.configuration.service
/nix/store/58kpy1fhl4fc0imzyqr6zdys4rnad60d-openvpn3-13_beta/share/dbus-1/system-services/net.openvpn.v3.backends.service
/nix/store/58kpy1fhl4fc0imzyqr6zdys4rnad60d-openvpn3-13_beta/share/dbus-1/system-services/net.openvpn.v3.log.service

[peterhoeg]

@peterhoeg do you know what else needs to be done for dbus services ?

Add it to `services.dbus.packages`. Couple of other things: 1. those dbus .service files expect dbus to spawn the various executables directly (they contain Exec). I'm not sure if this is due to upstream just not doing it properly or if it has something to do with how you're building it but it should instead use systemd to activate a service: Example: ```conf [D-BUS Service] Name=net.openvpn.v3.configuration Exec=/run/current-system/sw/bin/false SystemdService=net.openvpn.v3.sessions.service ``` This of course requires systemd unit definitions as well. 2. there is also an empty directory structure in $out/var/lib/openvpn3/configs. I don't know if you need openvpn3 to look in /var/lib/openvpn3/configs for anything, but if you do, that will not work.

[dsommers]

So, upstream OpenVPN 3 Linux developer here :)

First, in regards to the D-Bus .service files, I was not aware that SystemdService= was required. I thought that was only needed if the service was to be managed by systemd itself, as I would like to keep the ties to systemd to a bare minimum as possible. IIRC, I followed this guide in the early implementation, which is referenced by the official D-Bus documentaion. This was written ages before systemd was even invented, so it might be outdated, but it's the only documentation I could find back then.

That said, I'm open to fix things so that it is correct.

In regards to 2), yes that directory is used. It is used by openvpn3-service-configmgr. In OpenVPN 3 Linux, we're trying really hard to do privilege separation well. But that means that there are information the user on the system possess, which is unavailable to the VPN client process (openvpn3-service-client). This has been an issue with OpenVPN 2.x as well on systems with SELinux enabled, hence there is a $HOME/.cert folder with a security context label the openvpn process can reach.

This is solved that the OpenVPN 3 front-end (openvpn3, openvpn2, openvpn3-autoload and, in this context, openvpn3-as) does an initial parsing of the configuration profile, embeds all needed file artifacts (key files, certs, etc) as inlined options and sends it to the net.openvpn.v3.configuration service (openvpn3-service-configmgr). With this import, a persistent flag is indicated. If that is true, the configuration file will be saved to disk in /var/lib/openvpn3/configs together with some more meta-configuration data. This directory and these files should only be available to the openvpn user/group and should be as locked down to openvpn3-service-configmgr as possible.

Some more details here:

• https://github.com/OpenVPN/openvpn3-linux/blob/master/docs/man/openvpn3-config-import.1.rst#options
• https://github.com/OpenVPN/openvpn3-linux/blob/master/docs/man/openvpn3-config-manage.1.rst

I hope this helped clarifying a few more details. Feel free to reach out anytime you have questions!

[SCOTT-HAMILTON]

I tried this quick test-driver and it seems to work running @benshaw 's command https://gist.github.com/SCOTT-HAMILTON/33683b4265ea77b95dc1f9596d0cbc72

test script finished in 16.24s

[dsommers]

I see you add a ./configure flag. You might want to add --enable-bash-completion. To prepare for the Data Channel Offload support (ovpn-dco kernel module), you would need --enable-dco. This does not provide the kernel module itself, though.

If you want to support AWS VPC integration, you can also add --enable-addon-aws. A bit more configuration steps are needed before this service is started, but it pushes VPN routes to the AWS VPC to allow the VPN client to act as a router to the networks available via the VPN.

Finally, you can speed up building by adding --disable-build-test-progs. These test programs are not installed, and are more useful for various testing approaches and debugging and not something end-users would need to use.

[j4m3s-s]

I might be wrong, but I think that the python packages need to be wrapped with the correct PYTHONPATH, for the import to work. (e.g launching ./result/bin/openvpn3 didn't work on my side).

[dsommers]

I might be wrong, but I think that the python packages need to be wrapped with the correct PYTHONPATH, for the import to work. (e.g launching ./result/bin/openvpn3 didn't work on my side).

Hmm. The openvpn3 binary should not depend on Python at all; that's a C++ program. The openvpn2 "binary" is a Python script; PYTHONPATH might not be correct - but need to verify that better. But can you clarify if you're using openvpn3 or openvpn2 first?

Also note that OpenVPN 2.x is using just openvpn (no digits), just so we don't mix in that into the confusion here. The openvpn2 Python script is a wrapper provided by OpenVPN 3 Linux, to give a more OpenVPN 2.x-like command line.

[j4m3s-s]

Indeed, my bad, only openvpn2 needs to be wrapped for it to work.

Also this package needs a module for it to work since dbus service files reference the user/group openvpn.
Maybe something like programs.openvpn3.enable = true, I'm not sure how we should do it.
Otherwise it seems to work on my end.

[agarden]

This works for me, after creating the necessary user and group and adding it to dbus.packages.

[benshaw]

This works for me, after creating the necessary user and group and adding it to dbus.packages.

@agarden can you link the config you used for setting this up ?

[j4m3s-s]

I use this config and it has been working for a few months :

users.users.openvpn = {
      isSystemUser = lib.mkForce true;
      description = "Openvpn user";
    };
users.users.openvpn.group = "openvpn";
users.groups.openvpn = {};
environment.systemPackages = [ myPkgs.openvpn3 ];

[agarden]

Sorry I missed the notification back in August. Here are the relevant bits of my config, still working smoothly:

  services.dbus.packages = [ openvpn3Nixpkgs.openvpn3 ];
  users = {
    users = {
      openvpn = { isNormalUser = true; group = "openvpn"; };
    };
    groups = {
      openvpn = {};
    };
  };
  environment.systemPackages = with pkgs; [ openvpn3Nixpkgs.openvpn3 ];

[dsommers]

I see that one of the configs use isNormalUser = true;. I would advice the openvpn user and group to be a system account, not a normal user account.

[agarden]

I would advice the openvpn user and group to be a system account, not a normal user account.

@dsommers Thank you for the tip. Why is that better?

[dsommers]

All the OpenVPN related processes run as the openvpn user are essentially system processes. They don't use '/home', as it does not have any user data and such. It does however store persistent information in system directories (like /etc/openvpn3 and /var/lib/openvpn3).

Depending on distro and security setup, system processes may be further limited to what they are allowed to do and which file area they can access.

OpenVPN 3 Linux is designed to run with as few privileges and capabilities as possible. And so far only the openvpn3-service-netcfg process is the only one required to start as root - but as soon as it has been able to set capabilities right and initialize, it drops all unneeded capabilities and permissions. All other processes run as the openvpn (system) user and can be started directly as this user.

[stale]

I marked this as stale due to inactivity. → More info

[kravemir]

To be honest this PR should probably be maintained by someone that actually uses and knows well openvpn3. I'll make it as draft until either someone accepts to maintain it or someone finds what's wrong.

@SCOTT-HAMILTON I have put together functional PR #171678 based on note about missing DBus and user setup from others here.

Can you please find some time to look at it? Also, this is my first PR for NixOS, so I hope I've followed contributing process correctly.

[KFearsoff]

I've put another PR #173937 with the help of Matrix server people. I used #171678 as a basis (which didn't build for me because of the hardcoded gio path) and made some fixes, namely:

• bumped the version so that the gio would no longer be hardcoded
• added gtest support, so that the package now runs the upstream's unit test suite when building
• replaced the git submodules approach with hand-patching, which allows us to reuse the existing gtest package
• added optional flags: Bash completion, AWS addon and not-building-debug-suite

I also tried to make sure there are no useless dependencies in the build, and I think I did a good job at that. Left some comments for the packaging to be easier to understand. Feel free to try it out!

[dsommers]

Just a heads up, we're getting close to release the v18_beta. That fixes the gio problem you've encountered.

But beware, that release does a massive overhaul on the openvpn3-service-logger service. We discovered that Ubuntu 20+ and Debian 10+ needed a D-Bus policy tweak (it'll be in the git tree and tarball) to work as expected. The D-Bus policy files also moves from /etc/dbus-1/system.d to /usr/share/dbus-1/system.d (which is the recommended destination for policies shipped by projects).

Once our internal QA gives the green light, I'll push out the updated git tree.

[KFearsoff]

Hey, thanks for the heads up!

I've patched the gio problem using the f7d6d3a commit, which let me package the v17_beta in #173937 . I have, however, a few questions I'd like to clarify, if I may.

1. How strict is the versioning requirement for the dependencies? In particular, I'm interested in asio: we have asio 1.16.1 in Nixpkgs, while openvpn3-linux has a submodule for asio 1.18.2 and the upstream version is asio 1.22.1. I didn't manage to find anything related to asio in builds logs, so I am scared of it being able to introduce silent problems. Will we be warned in case the dependency is incompatible?
2. Related: can we just ship our versions of dependencies and expect the build to break loudly instead of silently if things go wrong?
3. Any chance for zsh/fish completions? Pretty please? :)

I apologize if any of those questions sound dumb, as I'm not too involved with open source community and don't know how things are usually done. I have, however, already taken it upon myself to invest my time into packaging openvpn3, so I'd like to do it properly.

[dsommers]

So, cherry-picking commit f7d6d3a is the right solution for the glib2 issues; we have done a similar hack for the v17_beta build for Ubuntu 22.04 as well. To your questions:

1. Dependencies are not that strict. If there are hard requirements, I do try to remember to add it in the commit message when upgrading the vendor/ git submodules. Otherwise, it is configure.ac which normally sets the other build-time dependencies. A don't think there will be any issues using ASIO 1.16.1. And in v18_beta, the asio submodule is updated to v1.22.1 as well.

2. For the vendor/ based dependencies, it typically breaks during build time, as that is build time dependencies. For the dependencies which is linked (typically, detected via configure.ac), it normally doesn't build as well if the API changes. If you install a pre-built binary, the dependencies must match the .so files (typically handled by the libtool versioning scheme). In that case, it won't run at all. As with all software linked to third-party libraries, there is of course possibilities of runtime breakage due to bugs in certain library versions. OpenVPN 3 Linux isn't that much different here.

3. The current bash-completion script should work fine with zsh. But I do take patches with further improvements or additional shells (like fish) 😉 . From the openvpn3 bash-completion script:

   #         Also works with zsh after loading bascomphinit
   #         (autoload -U +X bashcompinit && bashcompinit)
   

There has not been any dumb questions here. You're doing exactly what's expected of any kind of open source project involvement. I'm also not a NixOS user, so I don't grasp all those details. But I know Linux very well and has been involved in the OpenVPN project for a very long time, so that's the expertise I can bring to the table.

[KFearsoff]

Thanks for the detailed explanations and for the kind words!

The current bash-completion script should work fine with zsh

The completion script for openvpn3 works great, thank you! But it requires additional set up: one needs to add the bash-compinit and source <path-to-completions> lines in their Zsh config. Nix usually enables available completions for Bash, Zsh and Fish automagically, but it wants Bash completions to be .bash files, Zsh completions to be .zsh and Fish to be .fish for this magic to work. It can use the provided Bash completions in this case for reasons I don't quite understand, but it would be extra nice to have completions to all of the shells use magic.

Here's an example of kubectl providing completions for Bash, Zsh and Fish, and Nix installing them:
https://github.com/NixOS/nixpkgs/blob/nixos-unstable/pkgs/applications/networking/cluster/kubernetes/kubectl.nix#L26

I might try to write completions for Zsh and Fish myself and commit them to the upstream. It doesn't look overly hard on the first glance. I am a bit unsure about how that would play with the fact that openvpn2 completions are autogenerated, though: I doubt that completions can be generated for Zsh and Fish from the same script or even using a similar approach.

[dsommers]

@KFearsoff I suggest opening up a new issue in the OpenVPN 3 Linux project for improving the bash-completion, if anything needs to be done there to make it simpler. I'm open to have a zsh and fish specific completion scripts there, as long as someone is willing to maintain them (or I can put them into a contrib/ folder)

My hunch is that the --bash <($out/bin/kubectl completion bash) step could be handled fairly simple by just providing the content of the src/shell/bash-completion/openvpn3. But I'm not familiar enough with the .nix syntax to know for sure.

The main trick with src/shell/bash-completion/openvpn3 and as well as the completion script for openvpn3-admin is that they invoke the /usr/bin/openvpn3 shell-completion command. The --help mode gives an overview. But basically the --list-commands just lists all the available "sub commands" in openvpn3. The --list-options takes a "sub command" argument, and lists all the options/arguments this command takes. Finally there is the --arg-helper which is used together with the --list-options argument. The --arg-helper takes the full option with the leading dashes. An example:

 $ openvpn3 shell-completion --list-options config-manage --arg-helper --config

This lists all available configuration profile names which can be used with openvpn3 config-manage --config ....

The bash-completion scripts just calls openvpn3 shell-completion in various ways to present the most reasonable option alternatives. Now, the --config, --grant and --revoke options are a bit more special as the first one scans the directory for .conf and .ovpn files containing a few options typical for OpenVPN client configurations.

The gen-openvpn2-completion.py script generates the openvpn2 bash-completion, as you noticed. It uses a simple Python Jinja2 template to generate the script itself. This generator script can be extended to support other shells as well. This script builds on a RetrieveShellCompletionData() method in the openvpn3.ConfigParser Python class, which returns a Python dict of all options and possible values (with the same exception in regards to --config and files on the file system). This should be reasonably easy to extend to support more native modes.

The reason for calling openvpn3 shell-completion each time is that it can extract data more easily which is stored inside the various D-Bus services. And as the openvpn3 and openvpn3-admin as well as the Python openvpn3.ConfigParser is extended, the completion scripts does normally not need to be updated at all.

[KFearsoff]

@dsommers Thanks for the info, once again. I'll proceed by opening an issue in OpenVPN3 Linux repo, then! Will also try to do something myself.

[ckiee]

Preceded by #173937.