tunnels are restarted every time highstate runs

[cmclaughlin]

I recently upgraded to the latest version of this formula for systemd suppor (on AWS Linux 2).

And I noticed every time I run highstate my tunnels are restarted.

          ID: obsolete_openvpn_employees-udp-1194_service
    Function: service.dead
        Name: openvpn@employees-udp-1194
      Result: True
     Comment: Service openvpn@employees-udp-1194 has been disabled, and is dead
     Started: 04:51:09.669200
    Duration: 250.489 ms
     Changes:
              ----------
              openvpn@employees-udp-1194:
                  True
----------
          ID: openvpn_employees-udp-1194_service
    Function: service.running
        Name: openvpn@employees-udp-1194
      Result: True
     Comment: Service openvpn@employees-udp-1194 has been enabled, and is running
     Started: 04:51:10.094798
    Duration: 254.426 ms
     Changes:
              ----------
              openvpn@employees-udp-1194:
                  True

In service.sls there's a comment "For an successful upgrade we need to make sure the old services are deactivated". I guess there's a bug on the name of the old service though? It's not clear what case we're trying to cover here. Perhaps we can just delete the entire service.dead block?

[cmclaughlin]

@aboe76 I noticed you added service.dead in #110. I don't have any BSD or Debian hosts... and it's not clear what upgrade case you were working on. Do your tunnels get restarted every time highstate is applied?

[n-rodriguez]

it's not clear what upgrade case you were working on

migration from openvpn@service to openvpn-server@service systemd units.

[cmclaughlin]

Ok, so I suppose there's a bug such that I ended up with openvpn@service not openvpn-server@service - on AWS Linux 2.

[myii]

Just a quick note, we've got Amazon Linux 2 configured in kitchen.yml but it isn't currently enabled in Travis. Looking back through the build history, there's a failure at the installation stage:

https://travis-ci.org/myii/openvpn-formula/jobs/574197634#L875:

                 ID: openvpn_pkgs
           Function: pkg.installed
             Result: False
            Comment: Error occurred installing package(s). Additional info follows:
              
              errors:
                  - Running scope as unit run-261.scope.
                    Loaded plugins: ovl, priorities
                    No package openvpn available.
                    Error: Nothing to do

@cmclaughlin Did you already have openvpn installed before using this formula? Could you suggest the improvements needed to get the installation working here?

[cmclaughlin]

Did you already have openvpn installed before using this formula? Could you suggest the improvements needed to get the installation working here?

Yes and no...

I had an older EC2 instance running that was built off an older version of this formula. I ran a highstate with test=True and saw too many changes to feel comfortable proceeding. So I launched a new instance off the latest version of the formula.

So basically, no, I didn't perform the upgrade.

[myii]

@cmclaughlin Do you know what the package name is on Amazon Linux 2?

[cmclaughlin]

The package name is just openvpn - installed from EPEL 7.

[myii]

OK, thanks. The repo will need to be enabled to install the package.

[myii]

@cmclaughlin Thanks, adding the repo worked:

• https://travis-ci.org/myii/openvpn-formula/builds/583326179

@javierbertoli Can the EPEL repo be added to the pre-salted images or should we really be installing the repo using this formula before package installation?

[daks]

I think if a repo is needed to run this formula:

• we can choose to not manage it, but it means that doc/README/pillar.example should be explicit about the need to have this repo configured previously
• choose to manage it, but it needs to be possible to not use it, so a separate state or a pillar to not use it. This is necessary so that anyone can use its own method to manage repos

[myii]

@daks I had a search through the whole SaltStack Formulas organisation, to see what other formulas do. There are one or two (e.g. zfs-formula), which actually use the epel-formula as a dependency but that's not recommended here. Quite a few use the epel-formula as a dependency in Kitchen and that may be something worth considering. I couldn't find an example of using pkgrepo for this. Probably because it can be configured using:

$ yum install -y https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm

[n-rodriguez]

Why not using the repo pattern? saltstack-formulas/php-formula@3c9efc7 https://github.com/saltstack-formulas/php-formula/blob/master/test/salt/pillar/debian.sls#L5

[myii]

@n-rodriguez The repo pattern could definitely be useful. The issue right now is getting pkgrepo.managed working for the EPEL repo -- have you got any experience with this?

[n-rodriguez]

https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm

The content of https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm should help ;)

There's the key and the repo :

[epel]
name=Extra Packages for Enterprise Linux 7 - $basearch
#baseurl=http://download.fedoraproject.org/pub/epel/7/$basearch
metalink=https://mirrors.fedoraproject.org/metalink?repo=epel-7&arch=$basearch
failovermethod=priority
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7

[epel-debuginfo]
name=Extra Packages for Enterprise Linux 7 - $basearch - Debug
#baseurl=http://download.fedoraproject.org/pub/epel/7/$basearch/debug
metalink=https://mirrors.fedoraproject.org/metalink?repo=epel-debug-7&arch=$basearch
failovermethod=priority
enabled=0
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7
gpgcheck=1

[epel-source]
name=Extra Packages for Enterprise Linux 7 - $basearch - Source
#baseurl=http://download.fedoraproject.org/pub/epel/7/SRPMS
metalink=https://mirrors.fedoraproject.org/metalink?repo=epel-source-7&arch=$basearch
failovermethod=priority
enabled=0
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7
gpgcheck=1

Copy/paste in formula pillars (defaults.yaml and friends) if users can use the new openvpn.repo state or in test pillars (like in php-formula) if the state is not meant to be used.

[n-rodriguez]

Copy/paste in formula pillars (defaults.yaml and friends) if users can use the new openvpn.repo state or in test pillars (like in php-formula) if the state is not meant to be used.

From a global perspective, I think it could be nice to implement the repo pattern as soon as the package can be downloaded from a different repo than the distribution.

By default we should rely on distribution packages.

But with the repo pattern, people could feed pillars with the repo they want to use and call the <formula>.repo state when needed.

What do you think?