openfortivpn
openfortivpn copied to clipboard
"Ignoring option use-resolvconf" on Fedora 35
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
.
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.
I'll try to have a look nevertheless.
Opened a bug report in Red Hat Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2024565
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.
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
.
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
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.
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
.
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 providesresolvconf
as a prerequisite, or by hardwiring the path toresolvconf
with--with-resolvconf=</path/to/resolvconf>
. -
resolvconf
needs to be available at run time, by installing a package that providesresolvconf
as a prerequisite.
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
The reason has to be here:
https://github.com/adrienverge/openfortivpn/blob/d1b2801b6e866411398414be199c7648eb3e620b/configure.ac#L345-L346
I believe
RESOLVCONF_PATH
is set toDISABLED
becauseresolvconf
is not available at build time - it was available forf34
but notf35
.
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.
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.
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.logchecking for resolvconf... DISABLED configure: RESOLVCONF_PATH... DISABLED configure: HAVE_RESOLVCONF... 0 configure: USE_RESOLVCONF... 0
@nubitic-admin It is unclear which version of openfortivpn you are using. Are you building from source or using the RPM package?
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.
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)
@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:
- I tried with yum install openfortivpn
- At connection attempt I received this warning <Ignoring option "use-resolvconf">
- I removed it using yum remove openfortivpn
- I proceeded to download the source code and compile it, I installed openresolv using yum install openresolv
- At first attempt of compilation I noticed it wasn't detecting openresolv, I managed to find the reason I shared previously
- After granting execute permissions on /usr/sbin/resolvconf.openresolv compilation was ok, I proceeded to install it
- 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
- Uninstalled the compiled version
- Reinstalled using yum install openfortivpn
- Droped a conf file in /etc/systemd/resolved.conf.d/ indicating DNSs IP for the vpn and the domain name it resolves
- 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
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.
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).
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.
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.
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
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.
I confirm the issue with the fedora package is still on fedora 38:
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.