[SRU] vtun not running on ubuntu 20.04 LTS
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
vtun (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
Focal |
Fix Released
|
Undecided
|
Unassigned | ||
Jammy |
Fix Released
|
Undecided
|
Unassigned | ||
Mantic |
Fix Released
|
Undecided
|
Unassigned | ||
Noble |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
[ Impact ]
vtund can not be run as a server as the <-s> option is not available.
The manpage at https:/
The current package when executed after installing shows:
$ vtund
vtund[3175]: Can not open /etc/vtund.conf
VTun ver 3.X 11/24/2021
Usage:
Server:
vtund <-i> [-f file] [-P port] [-L local address]
Client:
vtund [-f file] [-q] [-p] [-m] [-t timeout] <host profile> <server address>
The <-s> option is not there in the Server options.
[ Test Plan ]
1. First simple test (no need to test the package even)
- check the build log to see if it says autoconf has found fork(). With the bug fixed the log will have:
checking for fork... yes
checking for vfork... yes
checking for working fork... yes
checking for working vfork... (cached) yes
2. Test the package.
- execute the command vtund.
With the fixed package it will show:
Usage:
Server:
vtund <-s|-i> [-f file] [-P port] [-L local address]
[ Where problems could occur ]
Looking at the diff between 3.0.3-4build1 and 3.0.4-2, I can see the code is mostly same for the server and listener. upstream has only added the check for fork() and then moved the server and listerner code in #ifdef. Since the (now) disabled part of the code has been used in pre-Focal, I think there should not be any regression.
But again, this part of the code has never been used in Focal onwards, so I can not tell for sure that other parts of the system will not affect the server execution.
[ Other Info ]
Debian also had the same problem of fork() not getting detected and that was fixed in 3.0.4-2. But for some reason (I will really like to know why) Ubuntu build systems of Focal and Jammy could not detect fork() is present. And since the package was not rebuilt after Jammy, so the problem remained.
This is the build log from Debian: https:/
This is the build log from Ubuntu: https:/
The Debian build log has:
checking for fork... yes
checking for vfork... yes
checking for working fork... yes
checking for working vfork... (cached) yes
Whereas the build log from Ubuntu of the same version does not have fork in it.
[ Original Bug Description ]
When installing a new server with Ubuntu 20.04 LTS with vtun_3.0.4-2_amd64 does not run the service as a server.
It has possibly errors in the compilation for Ubuntu Focal.
It runs normally on version 3.0.3-4build1 on Ubuntu 18.04 and also on the version of the package available in the Debian repository in the same version at: http://
Error log in the current version Ubuntu(Focal).
vtun_3.
May 20 01:44:05 server vtun [3177]: * Starting virtual tunnel daemon server vtun
May 20 01:44:05 server vtun [3186]: VTun see 3.X 11/11/2019
May 20 01:44:05 server vtun [3186]: Usage:
May 20 01:44:05 server vtun [3186]: Server:
May 20 01:44:05 server vtun [3186]: # 011vtund <-i> [-f file] [-P port] [-L local address]
May 20 01:44:05 server vtun [3186]: Client:
May 20 01:44:05 server vtun [3186]: # 011vtund [-f file] [-q] [-p] [-m] [-t timeout] <host profile> <server address>
May 20 01:44:05 server systemd [1]: vtun.service: Control process exited, code = exited, status = 1 / FAILURE
May 20 01:44:05 server systemd [1]: vtun.service: Failed with result 'exit-code'.
May 20 01:44:05 server systemd [1]: Failed to start LSB: virtual tunnel over TCP / IP networks.
In the version that works the following return:
VTun ver 3.X 02/05/2018
Usage:
Server:
vtund <-s> [-f file] [-P port] [-L local address]
Client:
vtund [-f file] [-p] [-m] [-t timeout] <host profile> <server address>
Version running of Debian repository:
vtun_3.
VTun ver 3.X 11/11/2019
Usage:
Server:
vtund <-s | -i> [-f file] [-P port] [-L local address]
Client:
vtund [-f file] [-q] [-p] [-m] [-t timeout] <host profile> <server address>
In the log error, such as option -i in the new version Focal and in the previous versions running, -s for the server environment.
#lsb_release -rd
Description: Ubuntu 20.04 LTS
Release: 20.04
vtun:
Installed: 3.0.4-2
Candidate: 3.0.4-2
Version table:
3.0.4-2 500
500 http://
*** 3.0.4-2 100
100 /var/lib/
description: | updated |
description: | updated |
description: | updated |
Changed in vtun (Ubuntu Focal): | |
assignee: | nobody → Sudip Mukherjee (sudipmuk) |
Changed in vtun (Ubuntu Jammy): | |
assignee: | nobody → Sudip Mukherjee (sudipmuk) |
Changed in vtun (Ubuntu Mantic): | |
assignee: | nobody → Sudip Mukherjee (sudipmuk) |
Changed in vtun (Ubuntu Noble): | |
assignee: | nobody → Sudip Mukherjee (sudipmuk) |
Changed in vtun (Ubuntu Focal): | |
status: | New → In Progress |
Changed in vtun (Ubuntu Jammy): | |
status: | New → In Progress |
Changed in vtun (Ubuntu Mantic): | |
status: | New → In Progress |
Changed in vtun (Ubuntu Noble): | |
status: | Confirmed → In Progress |
Changed in vtun (Ubuntu Mantic): | |
status: | Confirmed → In Progress |
Changed in vtun (Ubuntu Jammy): | |
status: | Confirmed → In Progress |
Changed in vtun (Ubuntu Focal): | |
status: | Confirmed → In Progress |
Changed in vtun (Ubuntu Noble): | |
status: | Confirmed → Fix Committed |
Look like the build process has missing `HAVE_WORKING_FORK` at the build stage. For me, the issue was fixed on by rebuild from the source (so the source is correct), probably original build process affects HAVE_WORKING_FORK
Unfortunately, I have no idea, how to fix the package.