Hardcoded path to exec() /usr/sbin/pppd

snapcraft
1

Hi,

Still working on the future openfortivpn snap. openfortivpn forks, then execs pppd using 'execv("/path/to/pppd", …). The path to the pppd executable must be defined at build-time and the Autoconf option --with-pppd= can be used to explicitly define that path.

First I tried path /usr/sbin/pppd because I thought that snap would somehow automatically/magically run /snap/openfortivpn-test/current/usr/sbin/pppd instead. From snapcraft.yaml:

        plugin: autotools
        configflags:
            - --with-pppd=/usr/sbin/pppd

This doesn’t work, openfortivpn complains /usr/sbin/pppd: No such file or directory.

Then I tried the full system path to pppd. Again from snapcraft.yaml:

        plugin: autotools
        configflags:
            - --with-pppd=/snap/openfortivpn-test/current/usr/sbin/pppd

This works.

Just wondering if I am doing the right thing here. Can I avoid hardcoding /snap/openfortivpn-test/current? Obviously I cannot use $SNAP because this is a run-time variable and openfortivpn requires the path to pppd to be set at build-time.

2

this is an acceptable hack … more elegant would be using a layout to map $SNAP/usr/sbin/pppd to /usr/sbin/pppd dynamically at runtime instead …

1 Like
3

I have started experimenting with layouts. Works like a charm for /usr/sbin/pppd:

layout:
    /usr/sbin:
        bind: $SNAP/usr/sbin

I’m not sure about the configuration file though:

  • The configure script of openfortivpn accepts option --sysconfdir= and the value by default is /etc as usual.
  • The installation process writes a commented out sample configuration into @sysconfdir@/openfortivpn/config.
  • By default openfortivpn attempts to read the configuration file @sysconfdir@/openfortivpn/config, unless instructed otherwise at run-time with command line option -c.

Again the straightforward solution is:

layout:
    /etc/openfortivpn:
        bind: $SNAP/etc/openfortivpn

At least this avoids the error message:

WARN:   Could not load config file "/etc/openfortivpn/config" (No such file or directory).

The problem is that /etc/openfortivpn is not writable by users, let alone persistent during upgrades. It should probably be moved to $SNAP_COMMON or rather $SNAP_COMMON/openfortivpn since the openfortivpn part is hardcoded. If so:

  • The configure script of openfortivpn should be called with option --sysconfdir=/snap/openfortivpn/common but this path depends on the target and $SNAP_COMMON is of course a run-time variable. Any clue how to work around that?
  • The installation process should write a commented out sample configuration into $SNAP_COMMON. What is standard practice here? Using a wrapper script that handles that whenever starting openfortivpn? Can the snap installation do that? How?
  • I have verified that -c /snap/openfortivpn/common/config does work.
4

i’d turn that into

layout:
  /usr/sbin/pppd:
    bind-file: $SNAP/usr/sbin/pppd

there might be binaries in /usr/sbin provided by the core(18) snap that you still want to be able to use, so overlaying the whole of /usr/sbin is probably not such a good idea …

1 Like
5

I had tried that initially and thought it doesn’t work. I cannot recall the exact error message but it had given me the impression that layouts support only directories, not files. Which is of course incorrect. I have fixed it and it works:

layout:
    /usr/sbin/pppd:
        bind: $SNAP/usr/sbin/pppd

I guess I had forgotten to connect the ppp plug.

1 Like
6

Note the difference:

layout:
  /path/to/file.txt:
    bind-file: $SNAP/path/to/file.txt

vs:

layout:
  /path/to:
    bind: $SNAP/path/to

There is a semantic difference between bind and bind-file. The reason you found that you could only do it with directories is because files need a bind-file declaration instead, which tells snapd to behave slightly differently (I’m not sure what it actually does differently, though).

1 Like
7

As for adding the configuration file into $SNAP_COMMON, I believe this will help me: