openfortivpn icon indicating copy to clipboard operation
openfortivpn copied to clipboard

"Ignoring option use-resolvconf" on Fedora 35

Open reetis opened this issue 3 years ago • 24 comments

The message Ignoring option "use-resolvconf". is shown on Fedora 35 when using use-resolvconf = 1 in config file. It is working on Fedora 34. Package version openfortivpn-1.17.0-2.fc35.

reetis avatar Nov 18 '21 09:11 reetis

Ideally, you should open a ticket here: https://bugzilla.redhat.com/buglist.cgi?component=openfortivpn&list_id=12270035&product=Fedora

This does not look like an openfortivpn issue, at least not directly, but a packaging issue.

DimitriPapadopoulos avatar Nov 18 '21 09:11 DimitriPapadopoulos

I'll try to have a look nevertheless.

DimitriPapadopoulos avatar Nov 18 '21 09:11 DimitriPapadopoulos

Opened a bug report in Red Hat Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2024565

reetis avatar Nov 18 '21 11:11 reetis

The error message is emitted from: https://github.com/adrienverge/openfortivpn/blob/d1b2801b6e866411398414be199c7648eb3e620b/src/config.c#L363-L364

https://github.com/adrienverge/openfortivpn/blob/d1b2801b6e866411398414be199c7648eb3e620b/src/config.c#L373-L375

It is emitted because HAVE_RESOLVCONF is not defined.

DimitriPapadopoulos avatar Nov 18 '21 14:11 DimitriPapadopoulos

Now HAVE_RESOLVCONF is set at build time by autoconf, so it's a build time issue, hence a packaging issue.

It looks like openfortivpn has been configured with --with-resolvconf=DISABLE.

DimitriPapadopoulos avatar Nov 18 '21 14:11 DimitriPapadopoulos

Actually all packages have been built without --with-resolvconf=DISABLE starting with Fedora 33:

  • branch f32 has been built with --with-resolvconf=DISABLED --disable-resolvconf: https://src.fedoraproject.org/rpms/openfortivpn/blob/f32/f/openfortivpn.spec#_28
  • branch f33 has been built without --with-resolvconf=DISABLED --disable-resolvconf: https://src.fedoraproject.org/rpms/openfortivpn/blob/f33/f/openfortivpn.spec#_28
  • branch f34 has been built without --with-resolvconf=DISABLED --disable-resolvconf: https://src.fedoraproject.org/rpms/openfortivpn/blob/f34/f/openfortivpn.spec#_29
  • branch f35 has been built without --with-resolvconf=DISABLED --disable-resolvconf: https://src.fedoraproject.org/rpms/openfortivpn/blob/f35/f/openfortivpn.spec#_29
  • branch rawhide has been been built without --with-resolvconf=DISABLED --disable-resolvconf: https://src.fedoraproject.org/rpms/openfortivpn/blob/rawhide/f/openfortivpn.spec#_39

DimitriPapadopoulos avatar Nov 18 '21 14:11 DimitriPapadopoulos

I had a look at the build logs of f34 and f35: https://kojipkgs.fedoraproject.org//packages/openfortivpn/1.17.0/2.fc34/data/logs/x86_64/build.log https://kojipkgs.fedoraproject.org//packages/openfortivpn/1.17.0/2.fc35/data/logs/x86_64/build.log

They are different indeed:

  • for f34:
    checking for resolvconf... /usr/sbin/resolvconf
    configure: RESOLVCONF_PATH... /usr/sbin/resolvconf
    configure: HAVE_RESOLVCONF... 1
    checking for /usr/sbin/resolvconf... yes
    configure: USE_RESOLVCONF... 0
    
  • for f35:
    checking for resolvconf... DISABLED
    configure: RESOLVCONF_PATH... DISABLED
    configure: HAVE_RESOLVCONF... 0
    configure: USE_RESOLVCONF... 0
    

We need to understand why configure results in a different configurations.

DimitriPapadopoulos avatar Nov 18 '21 14:11 DimitriPapadopoulos

The reason has to be here: https://github.com/adrienverge/openfortivpn/blob/d1b2801b6e866411398414be199c7648eb3e620b/configure.ac#L345-L346

I believe RESOLVCONF_PATH is set to DISABLED because resolvconf is not available at build time - it was available for f34 but not f35.

DimitriPapadopoulos avatar Nov 18 '21 14:11 DimitriPapadopoulos

For some reason, resolvconf was available by default in f34 but not in f35. The packager needs to force resolvconf as a dependency at build time and run time, by changing:

BuildRequires: make
BuildRequires:  gcc autoconf automake
BuildRequires:  pkgconfig(openssl)
BuildRequires:  pkgconfig(systemd)
Requires:       ppp

into something like:

BuildRequires:  make
BuildRequires:  gcc autoconf automake
BuildRequires:  pkgconfig(openssl)
BuildRequires:  pkgconfig(systemd)
BuildRequires:  resolvconf
Requires:       ppp resolvconf

In short:

  • resolvconf support needs to be enabled at build (configure) time, either by installing a package that provides resolvconf as a prerequisite, or by hardwiring the path to resolvconf with --with-resolvconf=</path/to/resolvconf>.
  • resolvconf needs to be available at run time, by installing a package that provides resolvconf as a prerequisite.

DimitriPapadopoulos avatar Nov 18 '21 14:11 DimitriPapadopoulos

It looks like resolvconf support has not been re-enabled, despite this attempt: https://src.fedoraproject.org/rpms/openfortivpn/c/e18bf25eec9db844634286252acd46d78266a6bf?branch=f34

Again, that's because we need to either add resolvconf as a build-time dependency so that it is detected by autoconf:

BuildRequires:  openresolv

or force support of resolvonf by passing the adequate argument to autoconf:

--with-resolvconf=/usr/sbin/resolvconf

In the latter case, I believe the proper path for resolvconf is /usr/sbin/resolvconf because that's the path I see in package openresolv, throughout supported Fedora versions.

@adrienverge Could you perhaps have a look at this relevant outstanding bug against Fedora packages? https://bugzilla.redhat.com/show_bug.cgi?id=2024565

DimitriPapadopoulos avatar Feb 25 '22 08:02 DimitriPapadopoulos

The reason has to be here:

https://github.com/adrienverge/openfortivpn/blob/d1b2801b6e866411398414be199c7648eb3e620b/configure.ac#L345-L346

I believe RESOLVCONF_PATH is set to DISABLED because resolvconf is not available at build time - it was available for f34 but not f35.

I happened to realize that on my case it was 'cause the final destination for the /usr/sbin/resolvconf symlink (wich is /usr/sbin/resolvconf.openresolv) had no execute permission. I no longer see the warning <Ignoring option "use-resolvconf"> however I'm still unable to get those DNS working. I'm working on Fedora 36.

nubitic-admin avatar May 10 '22 22:05 nubitic-admin

Perhaps openresolv is broken on Fedora 36 - which could explain why /usr/sbin/resolvconf.openresolv was not executable. You may try to reinstall (dnf reinstall) opensresolv.

DimitriPapadopoulos avatar May 11 '22 07:05 DimitriPapadopoulos

That said, I believe the openfortivpn packages still need to be fixed:

  • for f36: https://kojipkgs.fedoraproject.org//packages/openfortivpn/1.17.0/4.fc36/data/logs/x86_64/build.log
    checking for resolvconf... DISABLED
    configure: RESOLVCONF_PATH... DISABLED
    configure: HAVE_RESOLVCONF... 0
    configure: USE_RESOLVCONF... 0
    

DimitriPapadopoulos avatar May 11 '22 07:05 DimitriPapadopoulos

@nubitic-admin It is unclear which version of openfortivpn you are using. Are you building from source or using the RPM package?

DimitriPapadopoulos avatar May 11 '22 07:05 DimitriPapadopoulos

I had a look at the openresolv package for Fedora 36:, indeed it does not provide executables:

$ rpm -qlpv ./openresolv-3.12.0-3.fc36.noarch.rpm
[...]
-rw-r--r--    1 root     root                        0 Jan 20 23:45 /usr/sbin/resolvconf
-rw-r--r--    1 root     root                    23971 Jan 20 23:45 /usr/sbin/resolvconf.openresolv
[...]
$ 

Really strange. I don't know if that's on purpose.

DimitriPapadopoulos avatar May 11 '22 07:05 DimitriPapadopoulos

I might be mistaken, but openresolv just writes DNS entries to /etc/resolv.conf which is ignored on Fedora. On a clean Fedora 36 installation, /usr/sbin/resolvconf is provided by systemd-resolved (https://packages.fedoraproject.org/pkgs/systemd/systemd-resolved/fedora-36.html)

reetis avatar May 11 '22 09:05 reetis

@nubitic-admin It is unclear which version of openfortivpn you are using. Are you building from source or using the RPM package?

Hi, I share with you the process I followed:

  1. I tried with yum install openfortivpn
  2. At connection attempt I received this warning <Ignoring option "use-resolvconf">
  3. I removed it using yum remove openfortivpn
  4. I proceeded to download the source code and compile it, I installed openresolv using yum install openresolv
  5. At first attempt of compilation I noticed it wasn't detecting openresolv, I managed to find the reason I shared previously
  6. After granting execute permissions on /usr/sbin/resolvconf.openresolv compilation was ok, I proceeded to install it
  7. At connection attempt I no longer saw the warning but DNSs still had not working

After spending a couple of hours reading on line y tried the following

  1. Uninstalled the compiled version
  2. Reinstalled using yum install openfortivpn
  3. Droped a conf file in /etc/systemd/resolved.conf.d/ indicating DNSs IP for the vpn and the domain name it resolves
  4. Connect to the vpn using sudo openfortivpn -c myclient-vpn-config.conf without use-resolvconf option

And voila, DNSs now working.

Here the template of the conf file I used

[Resolve]
Cache=yes
DNS=10.10.XX.XX 10.10.YY.YY
Domains=miclient.maindomain

All the subdomains bellow miclient.maindomain are now resolved correctly

I glanced what this conf file changes on /etc/resolv.conf and only appends this to the end of the file

search miclient.maindomain --

I ended up writing a bash script that perform both things, drop the conf file in /etc/systemd/resolved.conf.d/ and connect to the vpn

nubitic-admin avatar May 11 '22 19:05 nubitic-admin

The whole point of resolvconf, whether the original Debian implementation or the openresolv one, is to do the right thing. My understanding is that it knows when to modify /etc/resolv.conf directly, on older systems, or when to call systemd-resolve on recent systemd-based systems. But I may be wrong.

If that's not the case, the only solution would be to use systemd-resolve directly, or perhaps call vpnc-scripts instead, which is already used by OpenConnect and does the right thing on a variety of Linux distributions and macOS.

DimitriPapadopoulos avatar May 12 '22 13:05 DimitriPapadopoulos

I might be mistaken, but openresolv just writes DNS entries to /etc/resolv.conf which is ignored on Fedora. On a clean Fedora 36 installation, /usr/sbin/resolvconf is provided by systemd-resolved (https://packages.fedoraproject.org/pkgs/systemd/systemd-resolved/fedora-36.html)

I can confirm that this is the case. Since Fedora 36, the DNS entries added to /etc/resolv.conf are ignored (it used to work on my Fedora 35 installation though, for some strange reason that escapes me).

ddobbelaere avatar May 13 '22 11:05 ddobbelaere

I know that since Fedora 36, the DNS entries added to /etc/resolv.conf are ignored.

What I do not know, is whether resolvconf only modifies /etc/resolv.conf. I was under the impression it does the "right thing", whatever the DNS backend. If it does not, resolvconf is clearly outdated and should not be used any more. On the other hand, a third version of resolvconf is (or was) provided by systemd itself, specifically for the systemd backend. That could be a temporary solution. For example on ArchLinux: https://archlinux.org/packages/?name=systemd-resolvconf Is the resolvconf from systemd available on Fedora?

I still believe the best long-term solution would be to switch to vpnc-scripts, as used by OpenConnect.

DimitriPapadopoulos avatar May 13 '22 11:05 DimitriPapadopoulos

resolvconf provided by systemd works correctly with openfortivpn. This is a problem with a Fedora package, since you can't force usage of resolvconf without building openfortivpn yourself.

reetis avatar May 13 '22 11:05 reetis

Yes, the Fedora package needs to be fixed with that respect. I suggest you add comments about the Fedora package to this existing open issue: https://bugzilla.redhat.com/show_bug.cgi?id=2024565

DimitriPapadopoulos avatar May 13 '22 12:05 DimitriPapadopoulos

I am having the same problem with fedora 36, but I still have to decide if it makes more sense to change the fedora build or consider that under systemd resolveconf is only a symlink to resolvectl hence detect that that binary exists. I think the latter has the advantage of being a more general solution.

aiace9 avatar Jul 19 '22 22:07 aiace9

I confirm the issue with the fedora package is still on fedora 38:

image

I am on Fedora Silverblue 38, with uses containerized development environments; and when I run openfortivpn, it doesn't work on the base system. However when I use a container with the correct resolv.conf in a Podman container (using toolbox), the DNS solving works fine.

yurigba avatar Oct 10 '23 09:10 yurigba