Add snapcraft packaging

[digitalrane]

Adds snapcraft packaging for openfortivpn.
I currently have an older snap published on the snapcraft store.
I have updated this snap to use the new core18 base, and have made it build directly from the git repository so it can use annotated tags as version information for the snap automatically.
If this is merged, it will also be possible to register this repo with the snap store (would require someone with access to this repo directly to register it) to enable automatic builds based on repository pushes, if there is desire for that. Otherwise, I can push a new version manually as requested.

Signed-off-by: James Hebden james@ec0.io

[adrienverge]

Hey @devec0, thanks for the pull request. I'm a bit relunctant to store external packaging files in the repo (.spec, .dsc, Dockerfile, and all the others that will exist with the multiplication of packaging solutions nowadays). @DimitriPapadopoulos @mrbaseman what do you think?

[DimitriPapadopoulos]

Hi @devec0,
Indeed we had already discussed snap packages back in #138 and the consensus was that we would rather not add whatever scaffolding is needed to create packages in the sources. That seems possible and even expected in other packaging systems, where additional files needed to create packages are maintained elsewhere:

• macOS/Hombrew: https://github.com/Homebrew/homebrew-core/blob/master/Formula/openfortivpn.rb
• Debian / Ubuntu: https://salsa.debian.org/debian/openfortivpn/-/tree/master/debian
• Fedora / CentOS / RedHat: https://src.fedoraproject.org/rpms/openfortivpn/tree/master
• openSUSE: https://build.opensuse.org/package/show/network:vpn/openfortivpn
• FreeBSD: https://svnweb.freebsd.org/ports/head/security/openfortivpn/

James, if I understand you correctly, Snapcraft works a little bit differently and expects the packaging machinery to be maintained within upstream sources. It is obviously not mandatory, but it is expected. Now if I follow you the pros would be that snaps would be created automatically instead of requiring human intervention. Human intervention looks like a bottleneck in the Snapcraft process, which would explain why the openfortivpn snap remains stuck at 1.3.0. Is that correct?

I rather agree with @adrienverge as was already the case in #138. On the other hand if it's the price to pay to have up-to-date packages of openfortivpn perhaps we should consider an exception.

Can you please help us a little bit by expanding on these questions?

• I don't see other software with a snap directory, at least not many repos out there. Why openfortivpn? How does it work for other software? Is there really no other way to automate things?
• Does the new directory have to be called snap? Can't we call it .snapfor example?
• I understand most snaps, including those used on Ubuntu, are created/maintained in Snapcraft. Can you confirm that?
• I understand the whole point and part of the business model of Snapcraft is that they automate the whole process of producing snaps without human intervention. New releases are pushed from developers to end users immediately. In contrast I think other packaging systems require some form of human validation at some point, although Homebrew looks like it could be fully automated like Snapcraft. James, can you comment on this specific point?
• Then there's again the expectation of Snapcraft that the machinery to build snaps is maintained with the source files in a snap directory. probably to push packaging and responsibility for deployment directly to the developers themselves - no more 3rd party packagers. We could create another Git repo, possibly under https://github.com/adrienverge, which would be a fork of the main repo with additional file needed for Snapcraft packaging. That could ba a temporary solution. Then if snaps continue to gain momentum we could move snap to the main repo. That's a bit convoluted though, just to avoid adding a snapcraft.yaml file. Alternatively can we instruct Snapcraft to take into account two repositories, one with the pristine upstream sources and the other one dedicated to snap packaging?
• James, is Snapcraft envisioned as the Linux equivalent of the Apple Store for iOS or Google Store for Android? I don't have a clear view of the situation here. I understand Snapcraft are pushing to be the unique or main "packagers" for Linux, actually pushing the responsibility of packaging down the chain to developers as much as possible. What is the future business of Linux vendors then? Are Linux vendors OK with that? Are some of them collaborating with Snapcraft? Are some Linux vendors behind Snapcraft?

[DimitriPapadopoulos]

A more technical question:

Note that openfortivpn 1.13.0 not only execs pppd but also resolvconf if available, as provided by resolvconf on Debian/Ubuntu or openresolv but not systemd on Fedora/CentOS/EPEL as this last implementation does not seem to be working as expected. Is that taken into account in the snap build process?

See also #590.

[DimitriPapadopoulos]

Finally in these times of lockdown, @m33m33 has created a snapcraft.yaml file elsewhere, he was in an hurry. Perhaps it would be worth merging them at some point:
https://github.com/m33m33/snapcraft_openfortivpn/

[mrbaseman]

@DimitriPapadopoulos to answer this question:

...What is the future business of Linux vendors then? Are Linux vendors OK with that? Are some of them collaborating with Snapcraft? Are some Linux vendors behind Snapcraft?

Snapcraft seems to be owned by Canonical, the company behind Ubuntu (see for example the footer of the snapcraft web pages)

[m33m33]

The current snap package is managed by Canonical, they host pretty much everything and gives a lot of ressources to the community.

I tried to contact the package manager, to update his package, with no response yet: I guess this is not a good time anyway, perfectly understandable.

So I was forced to create my own snap package receipe.

The openfortivpn projet should reclaim the snap package ownership at some point, and integrate it to the release process on github.

[mrbaseman]

James Hedden (@devec0) seems to be the maintainer of the snap for openfortivpn at Canonical. He has opened this pull request here

[m33m33]

James Hedden (@devec0) seems to be the maintainer of the snap for openfortivpn at Canonical. He has opened this pull request here

Haha, I hadn't noticed oO

[DimitriPapadopoulos]

We would rather avoid adding Canonical's snap directory because then we would have no reason not to accept files from other packagers. yet we cannot possibly maintain all these build infrastructures.

On the other hand we do appreciate the universal nature of snaps and acknowledge user demand. For example we have seen strong demand from @m33m33.

@devec0 @m33m33 As a first step, may I suggest one of the following:

• I am willing to create a developer account and be a maintainer of the existing openfortivpn snap.
• The openfortivpn snap could also be maintained in some other repo in "neutral ground", either the existing https://github.com/m33m33/snapcraft_openfortivpn/ or under https://github.com/DimitriPapadopoulos. Automated snap builds would be hooked to this repo. Again I am willing to help with maintainance, for example by importing the openfortivpn repo and rebasing whenever needed.

[DimitriPapadopoulos]

@devec0 I have created this repo on GitHub:
https://github.com/DimitriPapadopoulos/snapcraft_openfortivpn

Also I have a Snapcraft developer account (already had an Ubuntu One account):
https://build.snapcraft.io/user/DimitriPapadopoulos

I am willing to maintain the openfortivpn snap. Since the name "openfortivpn" is already registered, I would need your help to have access to it - if you're OK with this solution of course.

[m33m33]

@devec0 I have created this repo on GitHub: ...

@DimitriPapadopoulos great, you should be able to integrate the snap build to travis ( https://docs.travis-ci.com/user/deployment/snaps/ )

What yaml file look best for a start ? Need help on this ?

_{Sent with GitHawk}

[DimitriPapadopoulos]

@m33m33 I could integrate the snap build to Travis CI but isn't the goal to integrate directly to Snapcraft?

[m33m33]

@m33@m33 I could integrate the snap build to Travis CI but isn't the goal to integrate directly to Snapcraft?

Well, to my understanding: you have to build a snap package and upload it to snapcraft.io depot.

Travis can do both it says " Travis CI can automatically upload and release your app to the Snap Store after a successful build. "

[DimitriPapadopoulos]

@m33m33 I'll try that, but then isn't this pull request missing the necessary Travis CI integration in .travis.yml?

[DimitriPapadopoulos]

I'll try this:
Continuous snap delivery from Travis CI

[DimitriPapadopoulos]

I've tried but it fails ("built but failed to release" whatever that means):
https://snapcraft.io/openfortivpn-test/builds

No error messages.

The whole process is rather complicated. Don't know whether I will have time to finalize in the near future.

[DimitriPapadopoulos]

OK, changed .snapcraft/travis_snapcraft.cfg from

name: openfortivpn

to:

name: openfortivpn-test

and it works now ('Built and released').

[DimitriPapadopoulos]

There's a problem though. Script resolvconf is not available in the build container, hence support for resolvconf if disabled. From the build log:

checking for resolvconf... DISABLED
configure: RESOLVCONF_PATH... DISABLED
configure: HAVE_RESOLVCONF... 0
configure: USE_RESOLVCONF... 0

This is OK on Fedora but not what we want on Ubuntu.

I might be missing something here (please enlighten me) but it looks like the concept of "snaps" doesn't really apply to software tightly coupled to vendor-specific mechanisms like modifying DNS parameters. Options are configured at build-time and depend on the Linux vendor. Snaps on the other hand are built once for all vendors.

The only solution would be to support resolvectl and resolvconf on all target platforms and decide at run-time instead of build-time. See also #600.

[DimitriPapadopoulos]

@m33m33 Would you be willing to test the openfortivpn-test snap?

Note that --set-dns=1 only supports modifying /etc/resolv.conf directly. Support for resolvconf is disabled. This is OK on Fedora but perhaps suboptimal on Ubuntu.

[DimitriPapadopoulos]

Then we need to add a "stable" channel with version 1.13.2 in addition to the current "edge" channel.

[digitalrane]

Wow, OK - so this certainly started some conversation.

Firstly, I figure I should state my intention and my intended outcome here, and then will try to address questions. I wrote a snapcraft package for openfortivpn some time ago for a specific requirement, that didn't materialise. So, I am not using this snap myself in production - but based on metrics, roughly 2000 people around the world are using it - so I've had it on my TODO list to get it up to date and merged upstream for some time, especially given I occasionally get emails and various other requests to do so. So this isn't a 'Canonical' snap, and should not be used as an example of how well (or how poorly!) snaps are maintained by Canonical. I am also in a position to, and totally happy to, transfer the openfortivpn snap namespace to whomever would like to maintain it, especially now that I have provided updated packaging sources I can do so with a clean conscience :)

Now, with that said, I do work for Canonical and do use Snaps and Snapcraft a lot in my work, so hopefully I can address a few of the questions raised -

• Regarding packaging metadata, the metadata is designed to live alongside the package sources - similar to many packaging systems (debian, rpm specs, etc). Snapcraft however can be used in such a way that the software source is pulled as a 'part' during the build from a remote git repository, rather then referring to the local build directory.
• The upside to having it alongside is that you can configure the store such that a push and tag of your sources leads to a release, it's essentially a zero-op for you, at the cost of a directory in your source tree, and a single YAML file. I would say that most folks using snaps are using this method because the advantages are very helpful.
• The downside to an external repo housing your snapcraft metadata, is that you would have to realistically design your own pipeline, or register the packaging repo with snapcraft, and then make sure you tagged it alongside your source repo to make sure releases keep step with upstream. You could definitely maintain a travis (or other CI system) workflow to do this for you, but most people don't want to take on this additional level of complexity, and just opt to drop the snapcraft YAML in the repo, and let the store take care of it all.
• Re: "I don't see other software with a snap directory, at least not many repos out there" - this search shows at least 10,000 hits on GitHub for projects with a snapcraft.yaml. The file can either be in the CWD of the repo, the CWD of the build folder, or by default, a 'snap' directory, which is the most recent workflow, as you can colocate any assets your snap needs in addition to the source repo in a 'snap/local' folder.
• "Why openfortivpn?" I think I've answered this one above, but let me know if you have further questions
• "How does it work for other software?" - I think I've also answered this, but let me know if further questions
• "Is there really no other way to automate things?" - I think I've answered this, too, but again, let me know.
• "Does the new directory have to be called snap?" - I think I've covered this, but if you has something else in mind, you could just ran snapcraft in whatever folder you wanted that had a snapcraft.yml file, and it would use it. You would have to tell it how to find your sources, and you loose a lot of the baked in intelligence around finding source and additional assets.
• "Can't we call it .snap for example?" See above
• "I understand most snaps, including those used on Ubuntu, are created/maintained in Snapcraft. Can you confirm that?" snapcraft is the tooling used to build snaps, so yes - the store is also called snapcraft, and catalogues all the snaps folks have published, as well as providing people ways to monitor and manage deployment.
• "I understand the whole point and part of the business model of Snapcraft is that they automate the whole process of producing snaps without human intervention. New releases are pushed from developers to end users immediately. In contrast I think other packaging systems require some form of human validation at some point, although Homebrew looks like it could be fully automated like Snapcraft. James, can you comment on this specific point?" I think that "business model" might be the wrong view here, given snapcraft is an open source bit of software, including the snapd daemon, and is supported on almost all Linux distros these days. The business model for snapcraft is focused around consultancy and private and on-prem offerings, like most of Canonical's business model - but the software itself is all open source - and whilst Canonical is a sponsor and the lead developer - it's open to anyone to contribute.
• "Then there's again the expectation of Snapcraft that the machinery to build snaps is maintained with the source files in a snap directory. probably to push packaging and responsibility for deployment directly to the developers themselves - no more 3rd party packagers." I don't think I understand this assertion. This merge is just to provide a snapcraft yaml so this project can be easily packaged as a snap.
• "We could create another Git repo, possibly under https://github.com/adrienverge, which would be a fork of the main repo with additional file needed for Snapcraft packaging." This would work, but just be mindful of my comments above. I really don't have a preference, I just wanted to provide you the snapcraft file I'd written and then recently updated, to give something back and hopefully help to keep the snap up to date.
• "Alternatively can we instruct Snapcraft to take into account two repositories, one with the pristine upstream sources and the other one dedicated to snap packaging?" - you can only monitor the repo your register alongside the package name at the moment, as far as I'm aware.
• "James, is Snapcraft envisioned as the Linux equivalent of the Apple Store for iOS or Google Store for Android? I don't have a clear view of the situation here." Snapcraft's benefit and main goal is to provide a means for securely packaging software, across various distros. So you package once, and you can run on RHEL, CentOS, Fedora, Ubuntu, Debian, Arch - the goal isn't to replace anything. Ubuntu Core (the IoT version of Ubuntu) uses snaps as the sole packaging mechanism for security and ease-of-remote update reasons - as snaps are auto-updating and intended to fix the problem around automating and rolling back software updates on your systems. They also include security features such as confinement modes which are akin to some of the containerisation techniques in use by Docker or LXD, but have been implemented to be security-focused and portability focused rather than being a way to containerise software into it's own "container".
• "I understand Snapcraft are pushing to be the unique or main "packagers" for Linux, actually pushing the responsibility of packaging down the chain to developers as much as possible. What is the future business of Linux vendors then? Are Linux vendors OK with that? Are some of them collaborating with Snapcraft? Are some Linux vendors behind Snapcraft?" This is a fairly lofty question, but I want to state that I am not aware of any plans or desire behind snapcraft replacing distros or other packaging methods. The goals and benefits from my perspective are stated above - to ease remote management of systems, to improve package security, and to easy the deployment and packaging of software across distros.

[DimitriPapadopoulos]

@devec0 Hi James, thank you very much for the thorough answers!

I have created an openfortivpn-test snap based on your snapcraft.yaml file. I have based it on a separate repo https://github.com/DimitriPapadopoulos/snapcraft_openfortivpn instead of https://github.com/adrienverge/openfortivpn. I do understand the caveats associated with this choice. Perhaps this can change in the future but that's the solution we have converged to for now.

I would be interested in taking over the maintenance of the snap if that's OK with you.

Before this happens:

• Right now there's an "edge" release, I would like a "stable" release too, based on 1.13.3. Any clue how to achieve that? I realize I need to do my homework, but a hint would be nice.
• Any clue about the resolvectl/resolvconf stuff? For years openfortivpn had been modifying /etc/resolv.conf direclty. Then openfortivpn 1.12.0 started using resolvconf if available. This broke havoc on Fedora/CentOS because resolvconf is a llink to resolvectl from systemd which does not seem to be working as expected, like Debian's resolvconf. We now disable resolvconf support if we detect a broken resolvconf at build-time. Right now the Snapcraft build container lacks the resolvconf package so the snap lacks resolvconf support - which is a good thing after all as resolvconf doesn't work as expected on some Linux distributions. Yet that's disturbing. Are snaps suited for software that interacts with vendor-specific tools? Is the only solution to change from build-time decision to run-time decision? That's something I have been thinking of anyway, see Improve DNS handling? #600.

[m33m33]

@m33m33 Would you be willing to test the openfortivpn-test snap?

Note that --set-dns=1 only supports modifying /etc/resolv.conf directly. Support for resolvconf is disabled. This is OK on Fedora but perhaps suboptimal on Ubuntu.

Tested on an ubuntu derivative:

$ sudo snap install --candidate openfortivpn-test
openfortivpn-test (candidate) 1.13.3 par Dimitri Papadopoulos installé

$ snap info openfortivpn-test
name:      openfortivpn-test
summary:   openfortivpn, a PPP+SSL VPN client
publisher: Dimitri Papadopoulos
store-url: https://snapcraft.io/openfortivpn-test
license:   unset
description: |
  Openfortivpn is a client for PPP+SSL VPN tunnel services.
  It spawns a pppd process and operates the communication between
  the gateway and this process.
commands:
  - openfortivpn-test.openfortivpn
snap-id:      Pae5Hbe6vW9VsM1g8k7xiA5262eextkA
tracking:     latest/candidate
refresh-date: today at 12:01 CEST
channels:
  stable:    –                            
  candidate: 1.13.3 2020-03-30 (25) 118kB -
  beta:      ↑                            
  edge:      git    2020-03-30 (32) 118kB -
installed:   1.13.3            (25) 118kB -

$ /snap/openfortivpn-test/current/bin/openfortivpn --version
1.13.3

$ sudo /snap/openfortivpn-test/current/bin/openfortivpn -u ... --persistent=10 ...
VPN account password: 
...
It works :)
The resolv.conf file is automatically modified with provided nameservers

I guess the version should be set with an adopt-info directive in https://github.com/DimitriPapadopoulos/snapcraft_openfortivpn/blob/master/snap/snapcraft.yaml like in https://github.com/m33m33/snapcraft_openfortivpn/blob/master/snap/snapcraft.yaml so the package shows what is pulled from git at build time. You will follow the "releases" versions right ?

[DimitriPapadopoulos]

@m33m33 I have been inferring the openfortivpn version a little bit differently, based on Git tags and commits:
https://github.com/DimitriPapadopoulos/snapcraft_openfortivpn/blob/5833e1f/snap/snapcraft.yaml#L25-L38

There are a couple other issues:

• @devec0 and myself use confinement: strict and @m33m33 uses confinement: classic. Is there a reason why classic is required?
• I plan on adding this to a future version:

  manpage:    man /snap/openfortivpn/current/usr/share/man/man1/openfortivpn.1.gz
  cli usage:  [sudo] /snap/openfortivpn/current/usr/bin/openfortivpn [-c /etc/openfortivpn/config] 
  (warning: the config file must not be world readable, better pass the password in interactive mode)

• Should we limit the architecture to amd64?
• Is plugs: [network-bind] enough or should we use plugs: [network, network-bind]? Why?
• Are these compiler flags of interest for all builds? If so shouldn't we backport this to the openfortivpn sources? Are there Autoconf macros for these options?

CFLAGS="-Wl,-pie -fPIE -fstack-protector-strong -fstack-protector-all [...]

[DimitriPapadopoulos]

@devec0 Hi James, I think the snap for openfortivpn 1.13.3 is ready.

The snap sources are here:
https://github.com/DimitriPapadopoulos/snapcraft_openfortivpn

The snap is currently available from:
https://snapcraft.io/openfortivpn-test

I'll wait a few days before I promote latest/candidate to latest/stable.

I think I am ready to take over maintenance, if you're still OK with that. I'll move the snap from:
https://snapcraft.io/openfortivpn-test
to:
https://snapcraft.io/openfortivpn
Please let me know how you want to proceed.

[digitalrane]

Hey @DimitriPapadopoulos - I've invited you as a collaborator on the openfortivpn snap, which should give you access to push to the snap on the store. There's no option to totally transfer ownership without engaging the snapcraft team, and I think this level of access will work perfectly.

Please be mindful that the current snap has been installed by roughly 2,000 users, so any push to the stable channel on this snap will be rolled out automatically, so it would be good to promote through edge and beta first.

I'd be very glad to have you take over maintenance, as I honestly don't have the spare cycles to look after this snap properly - so thank you!

[mrbaseman]

There's a problem though. Script resolvconf is not available in the build container, hence support for resolvconf if disabled.

given the fact that the current production snap is on 1.3.0 I'd consider it a good thing, that resolvconf is disabled, at least for now. The fallback is what has also been used in 1.3.0.

Possible other changes that might break so-far working snaps:

• We should think about the change of the interplay of --pppd-use-peerdns and --set-dns. Starting with 1.8.0 we have changed the behavior, several times back and forth. However, a transition 1.3.0 -> 1.13.3 might be smother than the path that we have taken with the development ;-) At least we should think about this point.
• Starting with 1.11.0 we support connecting with an empty password and also try to do so, if there is a line like that in the config file. Do we need a hook to comment out such a line in an existing config? I'm not familiar with the way how snaps work. Can they access config files outside of the "container"?
• With 1.12.0 the hostname matching of the server certificate has been enforced, which might lock out people who access their vpn via ip address instead of hostname for example.
• ... other incompatible changes?

[digitalrane]

@DimitriPapadopoulos - the currently publish snapped is based on the sources here

The one I have provided has been re-done to enable proper git versioning, and to use the new bases keyword to be compatible with newer snapcraft. There's not huge functional differences.

Regarding confinement, classic confinement is not recommended, and requires an exception to be granted for the snap, if required it function. The snapcraft forums would be the right place to request that if needed, but I can't think of a reason that openfortivpn would need it - even considering the above new changes since the 1.3 release.

You might want to look at snap layouts if anything you need for the above is not already being made available inside the snap. (you could, for example, use a layout to bind-mount the resolconf directory into the snap filesystem for this snap, I believe).

Strict confinement however is the better of the two options from a security and user UX perspective. You're less likely to interfere with things on the host system, the openfortivpn process is better contained in its own namespaces, and you don't require any special flags on install or store exceptions to publish and push updates to the snap.

[digitalrane]

Oh, and for using the host pppd - you'd want to add the ppp plug to the snap. This is not an 'auto connected' plug for snaps - so the user would have to run snap connect openfortivpn:ppp to allow access to host ppp - but you can ask on forum.snapcraft.io and the snapcraft team will set up an auto-connect for that plug for you, so users don't have to do it manually on install. These are typically granted much more freely based on use case than classic confinement - as classic confinement disables a large number of the confinement features in snaps, making it a big hammer to swing, when a simple plug can often suffice.

More information on plugs and interfaces: https://snapcraft.io/docs/supported-interfaces

[DimitriPapadopoulos]

About confinement: openfortivpn works out-of-the-box even without the ppp plug. Maybe because we run it with sudo anyway so confinement is bypassed?

[DimitriPapadopoulos]

Ah, it's not because of sudo, it's because we run the executable directly instead of executing the snap. For example when running the snap I cannot access a config file outside of the read-only snap directory:

$ sudo /snap/bin/openfortivpn-test.openfortivpn -c ~/config 
WARN:   Could not load config file "/home/dimitri/config" (Permission denied).
[...]
$ 

I'll add more plugs like home until I get the snap to work - if possible at all considering openfortivpn is closely associated to the system.

[DimitriPapadopoulos]

Even the current 1.3.0 snap fails with:

ERROR:  gethostbyname: Unknown host

I'll add the network plug too.

[DimitriPapadopoulos]

Mmmh... The home plug doesn't work because of sudo. This works:

$ sudo /snap/bin/openfortivpn-test.openfortivpn -c /root/config
INFO:   Connected to gateway.
INFO:   Authenticated.
INFO:   Remote gateway has allocated a VPN.
[...]
$ 

but this doesn't :

$ sudo /snap/bin/openfortivpn-test.openfortivpn -c ~/config
WARN:   Could not load config file "/home/dimitri/config" (Permission denied).
[...]

Hardly what we want... I can remove home for now and address this later, or set the read attribute to all - unfortunately the plug will become non-autoconnect.

[DimitriPapadopoulos]

@devec0 I'm starting to doubt it is possible to create a snap of openfortivpn: openfortivpn needs to modify DNS parameters and IP routing and it forks pppd which should itself be able to change DNS parameters. It is interacting too closely with the system.

• While stage-package: [ppp] does create a dependency on the system pppd, I cannot find a way for the openfortivpn snap to use it:
• On the other hand plugs: [ppp] embarks a pppd executable in the snap. This pppd is confined and will probably be unable or not fit to interact with the system to change DNS configuration.
• openfortivpn may need to modify /etc/resolvconf or call resolvectl or resolvconf. same problem again...

[m33m33]

@devec0 I'm starting to doubt it is possible to create a snap of openfortivpn: openfortivpn needs to modify DNS parameters and IP routing and it forks pppd which should itself be able to change DNS parameters. It is interacting too closely with the system.

• While stage-package: [ppp] does create a dependency on the system pppd, I cannot find a way for the openfortivpn snap to use it:
• On the other hand plugs: [ppp] embarks a pppd executable in the snap. This pppd is confined and will probably be unable or not fit to interact with the system to change DNS configuration.
• openfortivpn may need to modify /etc/resolvconf or call resolvectl or resolvconf. same problem again...

Well, I'm no expert in snap packages (yet ;) but it works pretty well here https://github.com/m33m33/snapcraft_openfortivpn/blob/master/snap/snapcraft.yaml with classic confinment and a local installation (this package is not published on snapcraft.io, it may be the big difference ?)

[DimitriPapadopoulos]

@m33m33 I may be wrong but I understand snap executables live in and should be run from /snap/bin:

sudo /snap/bin/openfortivpn-test.openfortivpn

Instead you have to be directly running the openfortivpn executable bundled in the snap's internal directory which is not a snap but a simple executable. On Ubuntu 18.04 it would be here:

sudo /snap/openfortivpn-test/current/bin/openfortivpn

It works of course, but then you're misusing the snap. The snap itself doesn't work and had probably never worked. openfortivpn is so closely knit with the system that it probably doesn't make sense to deploy it as a snap.

[DimitriPapadopoulos]

I'm building the snap locally now, much easier to experiment than on Snapcraft. I can even use confinement: classic as a first step.

More on pppd:

• Actually it's stage-package: [ppp] that embarks a pppd executable in the snap.
• When building with stage-package: [ppp] (and hence embarking pppd) the override-build part is not needed on Snapcraft but is needed when building locally for some reason. I need to pass --with-pppd=/usr/sbin/pppd to the configure script, otherwise openfortivpn attempts to run /root/parts/openfortivpn/install/usr/sbin/pppd instead of /usr/sbin/pppd.
• It works with stage-package: [ppp] and the embarked pppd. The embarked pppd modifies the system /etc/resolv.conf with --set-dns=0 --pppd-use-peerdns=1. openfortivpn itself modifies it with --set-dns=1 --pppd-use-peerdns=0
• It works well without stage-package: [ppp] and the embarked pppd too.

I'm not certain about this stage-package: [ppp] stuff. It works well on Ubuntu 18.04 LTS, but I'm not entirely convinced that the same pppd will work well on other distributions. That's a start though, let's try to keep stage-package: [ppp] and the embarked pppd for now.

[m33m33]

Looks like a good direction.

To me the whole point of a snap vs a simple deb is to guarantee that it works no matter what. So including dependices like pppd or whatever library needed is just fine.
Doing this I had my version of snap package running on tests VMs : Ubuntu 16, Ubuntu 18, Fedora, Centos7, Mint 19, which basically covers my users most used distributions without deb/rpm version spread of hell.

[DimitriPapadopoulos]

The network-bind plugin is required to avoid this error in strict confinement:

[...]
ERROR:  getaddrinfo: Name or service not known`
INFO:   Closed connection to gateway.
ERROR:  socket: Permission denied
INFO:   Could not log out.

[DimitriPapadopoulos]

Then there's this strange build issue (at least when building locally):

• Without overriding the default autotools build, openfortivpn detects pppd as /root/parts/openfortivpn/install/usr/sbin/pppd at build-time and builds this path into openfortivpn. Then it cannot be found at run-time of course:

[...]
INFO:   Remote gateway has allocated a VPN.
ERROR:  /root/parts/openfortivpn/install/usr/sbin/pppd: No such file or directory.
INFO:   Closed connection to gateway.
INFO:   Logged out.

• Overriding the default autotools build and passing --with-pppd=/usr/sbin/pppd to Autoconf, I'm getting this error:

[...]
INFO:   Remote gateway has allocated a VPN.
ERROR:  /usr/sbin/pppd: No such file or directory.
INFO:   Closed connection to gateway.
INFO:   Logged out.

• I eventually followed the advice of @m33m33 and passed --with-pppd=/snap/openfortivpn/current/usr/sbin/pppd to Autoconf and it does work. Doesn't make any sense to me: where's the confinement if you have to use absolute paths instead of paths relative to the snap? Something's fishy here.

[DimitriPapadopoulos]

The ppp plugin does not help with this error in strict confinement:

INFO:   Connected to gateway.
INFO:   Authenticated.
INFO:   Remote gateway has allocated a VPN.
Couldn't open the /dev/ppp device: Permission denied
/snap/openfortivpn-test/current/usr/sbin/pppd: Sorry - this system lacks PPP kernel support

/snap/openfortivpn-test/current/usr/sbin/pppd: Sorry - this system lacks PPP kernel support

ERROR:  read: Input/output error
INFO:   Cancelling threads...
ERROR:  pppd: The kernel does not support PPP, for example, the PPP kernel driver is not included or cannot be loaded.
INFO:   Terminated pppd.
INFO:   Closed connection to gateway.
INFO:   Logged out.

Googling these error messages does not bring anything useful. I am at a loss how to fix this.

[digitalrane]

@m33m33 - installing locally would require --devmode, which disables all confinement, so you will not have any issues accessing any part of the host machine in that scenario, and the classic confinement will not present you any issues either, because that too is ignored in devmode.

@DimitriPapadopoulos my understanding is that the ppp plug should be giving you access to host PPP kernel modules, so regardless of where pppd is running, you should be setting up interfaces on the host. This leaves DNS, which I believe you can do with a layout, if it doesn't work already.

I've mentioned before that I don't use this snap myself, that I am just providing it given there are a number of people using it at the published 1.3 version (presumably without issue) and that one was not classic confined.

Regarding the ppp plug, did you connect it on the host? Remember that ppp is not auto-connected, so you would need to do snap connect openfortivpn:ppp, potentially with sudo

The openfortivpn binary placed in /snap/bin is what you should run to test, which should already be in your path (if you want to test confinement) - and confinement will only be in place if you install from the store, not via devmode (which I think you already know, just reiterating it here for everyone else).

[DimitriPapadopoulos]

@devec0 Ah indeed ppp was not connected. Unfortunately connecting doesn't help:

$ snap connections openfortivpn-test 
Interface     Plug                            Slot           Notes
network-bind  openfortivpn-test:network-bind  :network-bind  -
ppp           openfortivpn-test:ppp           -              -
$ 
$ sudo snap connect openfortivpn-test:ppp
$ 
$ snap connections openfortivpn-test 
Interface     Plug                            Slot           Notes
network-bind  openfortivpn-test:network-bind  :network-bind  -
ppp           openfortivpn-test:ppp           :ppp           manual
$ 
$ sudo /snap/bin/openfortivpn-test.openfortivpn -u xxxxxxx xxxxx.xxxx.de:443
WARN:   Could not load config file "/usr/etc/openfortivpn/config" (No such file or directory).
VPN account password: 
INFO:   Connected to gateway.
INFO:   Authenticated.
INFO:   Remote gateway has allocated a VPN.
Couldn't open the /dev/ppp device: Operation not permitted
/snap/openfortivpn-test/current/usr/sbin/pppd: Sorry - this system lacks PPP kernel support

/snap/openfortivpn-test/current/usr/sbin/pppd: Sorry - this system lacks PPP kernel support

ERROR:  read: Input/output error
INFO:   Cancelling threads...
ERROR:  pppd: The kernel does not support PPP, for example, the PPP kernel driver is not included or cannot be loaded.
INFO:   Terminated pppd.
INFO:   Closed connection to gateway.
INFO:   Logged out.
$ 

[digitalrane]

Do you get the same if you don't run it with sudo? Or is sudo generally required by openfortivpn?

[DimitriPapadopoulos]

Unfortunately sudo is required in at least 3 places, documented in the README:
https://github.com/adrienverge/openfortivpn/blob/master/README.md#running-as-root
I had also attempted to investigate some of these places in issue #387. Now time has passed and it might be possible to do without sudo in some cases. We currently enforce sudo here:
https://github.com/adrienverge/openfortivpn/blob/2d89a16/src/main.c#L591-L595

Perhaps it would be worth revisiting this sudo stuff but it's probably not possible in the short term.

[DimitriPapadopoulos]

Got an answer on the forum
https://forum.snapcraft.io/t/ppp-plug-dev-ppp-device-permission-denied-and-sudo/16366/8

An additional plug is need: network-control

I think we now have something that is equivalent to the existing snap. I'll move from my test snap to channel latest/beta of the definitive production snap soon.

[DimitriPapadopoulos]

@devec0 James, I cannot find a way to plug my Git repo to your snap so as to automate this process:
https://github.com/DimitriPapadopoulos/snapcraft_openfortivpn → https://snapcraft.io/openfortivpn
the same way as:
https://github.com/DimitriPapadopoulos/snapcraft_openfortivpn → https://snapcraft.io/openfortivpn-test

I had to file a "dispute" and ask for help on how to achieve that.

The only other alternative I can think of is maintaining the snap in your existing Git repo and following this process:
https://git.launchpad.net/~ec0/+git/snap-openfortivpn/ → https://snapcraft.io/openfortivpn
That's OK with me too, except there are no issues in Launchpad as far as I can tell. I don't know whether you can give me write access to this Git repo. And perhaps it wouldn't work either as you may have built the initial snaps in a more manual way.

Unless you have a clue, I'll wait for for feedback from Snapcraft on how to best achieve the transition.

[digitalrane]

Until you have a response on transitioning the name, you should simply be able to use the snapcraft cli to push releases to the openfortivpn snap. Pointing it at the Git repo is only required for automatic builds. I think maintaining the snap sources here, rather than out of my launchpad account makes it easier for existing developers and maintainers to commit changes to and manage changes to the snap. The current launchpad git repo is not actually registered with the snapcraft store at all.

[DimitriPapadopoulos]

@devec0 I've tried to follow Making your snaps available to the store using snapcraft:

$ snapcraft login
Enter your Ubuntu One e-mail address and password.
If you do not have an Ubuntu One account, you can create one at https://snapcraft.io/account
Email: xxx.xxx@xxx.xxx
Password: 
[...]
$ 
$ snapcraft release openfortivpn 4 edge
Sorry, try `snapcraft register openfortivpn` before trying to release or choose an existing revision.
$ 
$ snapcraft history openfortivpn
DEPRECATED: The 'history' command has been replaced by 'list-revisions'.
See http://snapcraft.io/docs/deprecation-notices/dn4 for more information.
Failed to get snap ID for snap 'openfortivpn'. This is an error in the store, please open a new topic in the 'store' category in the forum: https://forum.snapcraft.io/c/store
$ 
$ snapcraft list-revisions openfortivpn
Failed to get snap ID for snap 'openfortivpn'. This is an error in the store, please open a new topic in the 'store' category in the forum: https://forum.snapcraft.io/c/store
$ 

So it does look like something needs to be modified on the Store.

Other than using the Launchpad Git repo is fine with me. Will you be able to give me write access to https://git.launchpad.net/~ec0/+git/snap-openfortivpn?

[DimitriPapadopoulos]

Ah, something might have been modified on the Store. Now I get the message:
Login to your GitHub account to start building.
It looks like only GitHub repos can be attached to Snapcraft, Launchpad won't do:

Great! I will be attaching GitHub to Snapcraft soon. Let me verify a couple things first.

[DimitriPapadopoulos]

An snap of openfortivpn 1.13.3 is available from the latest/edge channel:
https://snapcraft.io/openfortivpn

[DimitriPapadopoulos]

I have moved the repository to openfortivpn/snap.

[DimitriPapadopoulos]

For what it's worth:
https://www.atechtown.com/flatpak-vs-snap/

Maybe a Flatpak package would be useful.

[DimitriPapadopoulos]

Flathub is for graphical applications only:

Desktop integration

Flathub is primarily focused on graphical desktop applications and not CLI/TUI applications. The following requirements ensure effective desktop integration.