advesperascit

  • a day ago
  • Joined Nov 5, 2021
  • to be honest i haven't tested. I gave you the options used by systemd service.
    If you want to use the Artix version be sure to remove the fdmove -c 2 1 and exec part . this is done automatically by 66. But i think the one given by @advesperascit correspond to the one given by artix (in better way regarding 66 syntax)

    • eric Ha yes, the user ovpn is there but if I add again the @runas key I get a permission denied error in opening the certificate and key files in the client folder. I think it's something to do with the openvpn user owning the client folder and requiring a password. Actually I don't even have a server conf file, my VPN just gives a single config file (that should be the client) to put in /etc/openvpn, without need to authenticate. Even simply moving the conf file to /etc/openvpn (outside the client folder) works, using the @advesperascit template.
      /etc/66/service/openvpn@:

      [main]
      @type = classic 
      @version = 0.0.1
      @description = "OpenVPN daemon"
      @user = ( root )
      
      [start]
      @execute = (
      cd /etc/openvpn
      execl-cmdline -s { openvpn ${conf_file} }
      )
      
      [environment]
      conf_file=!--config @I.conf

      Is it fine ? I removed the --nobind option because it's already in the conf file, however I think that this option and --suppress-timestamps are instead needed by the systemd service to avoid conflicts.

      Also, I took a look at the s6 service in the Artix repos, it basically uses the same command:

      #!/bin/execlineb -P
      fdmove -c 2 1
      exec openvpn --config /etc/openvpn/openvpn.conf
    • Thanks @advesperascit and @eric , the service configuration for the client worked but only if I remove the @runas =openvpn line, it looks like I have no "openvpn" user, is that normal?

      • eric replied to this.
      • for the server:

        create a file at /etc/66/service/openvpn-server@ with the following

        [main]
        @type = classic
        @version = 0.0.1
        @description = "OpenVPN server daemon"
        @user = ( root )
        
        [start]
        @runas = openvpn
        @execute = (
            cd /etc/openvpn/server
            execl-cmdline -s { openvpn ${conf_file} }
        )
        
        [environment]
        conf_file=!--status /run/openvpn-server/status-@I.log --status-version 2 --suppress-timestamps --config @I.conf

        be sure to have an existing configuration file at /etc/openvpn/server/ with the name used to enable the service. For example, if you do 66-enable openvpn-server@myenterprise you need to name the configuration file myenterprise.conf

        for the client

        create a file at /etc/66/service/openvpn-client@ with the following

        [main]
        @type = classic
        @version = 0.0.1
        @description = "OpenVPN client daemon"
        @user = ( root )
        
        [start]
        @runas = openvpn
        @execute = (
            cd /etc/openvpn/client
            execl-cmdline -s { openvpn ${conf_file} }
        )
        
        [environment]
        conf_file=!--suppress-timestamps --nobind --config @I.conf

        Again, be sure to have the corresponding configuration file at /etc/openvpn/client.
        like said @advesperascit, no warranties etc

        Please tell us if you got it running correctly

      • Hyperspace

        No error on your part. @advesperascit has to decide whether to add their signing key to the obcommunity-keyring or remove it from each of the listed packages and allow those packages to be built just with the obcommunity key.

        If you want to install these packages in the meantime, you can follow the same process for installing the obcommunity-keyring itself, i.e. temporarily setting SigLevel to Never for the obcommunity repo, install the packages, and set the SigLevel back to DatabaseOptional.

      Powered by Obarun