Pre-built binary for openvpn3 client for the new stable release of Debian (version 12 codename bookworm)

[jim-barber-he]

The latest Debian stable release came out on the 10th of June 2023.
Currently there is no pre-built openvpn3 Debian package built for the bookworm distribution.
This is a request for adding a new package to support this since the other .deb packages have dependencies on packages that are too old.

[mschlachter]

I contacted support about this and they told me it's planned for the v21 release. I would love to have a timeline for when this will be available if possible.

[dsommers]

This is not a promise. But I do hope I can manage to have a v21 release out by end of August/early September. This will definitely include Debian 12 builds. It is holiday season now, so not much will happen in July.

[samiramer]

Hey @dsommers do you have an update on the release timeline? This would be a lifesaver.

[samiramer]

Related to #201 and #171

[dsommers]

The v21 release has been delayed due to work related to solve #171 as well as some issues reported in the Core library by our internal QA. Hopefully a v21 for stable distribution releases (aka LTS distros, Debian, Ubuntu LTS, RHEL/CentOS) will be ready for internal QA within 2 weeks. Since #171 has now been taken out of the v21 release, I'm already wrapping up the last outstanding issues to get a proper build and packaging done. Once QA has approved the release, it will be shipped.

The v21 release will ship with an updated OpenVPN 3 Core library, which is currently going through QA now. Even though issues found by QA in this library has so far had a very small impact on OpenVPN 3 Linux (it is also used in OpenVPN Connect), there are a still a few potential issues which might affect this project as well.

[bhack]

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=904044

[Drizzt321]

@dsommers any further work on v21? I can muddle through with old openvpn2 client, but the v3 would be great to be able to use.

[dsommers]

@Drizzt321 The v21 is going through QA these days. If all goes well, end of the month is the main goal for the final release.

I'm pushing out fixes needed for this release in the releaseprep/v21 branch.

[dsommers]

@mschlachter @jim-barber-he @samiramer @Drizzt321 I've attached here the latest QA build for Debian 12. Feel free to test it if you want. Any feedback would be valuable.

openvpn3_0-20230919git6361bd5-1+bookworm_amd64.deb.gz

Since GitHub is picky about such attachments, you need to gunzip this file before running:

 apt install ./openvpn3_0-20230919git6361bd5-1+bookworm_amd64.deb

[bhack]

@mleeman is also preparing a regular/official Debian package at:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=904044#27

[mleeman]

Dang, busted :-P

I've added some comments in the ticket, the highlights are:

1. The debian builders do not like git submodules (no network access). In order to avoid having to recompress the releases; I decided to make 2 packages: openvpn3 (library) and openvpn3-linux (client). The package names match the repository names; this allows easy maintenance with git-buildpackage when a new release is tagged
2. I have added pkg-config support in openvpn3 for better support in the client compilation.
3. Minor patches are applied to avoid git and git submodule checkout/update
4. I need to add a binary conflict to openvpn3 to avoid problems with ppl that have both repos enabled

These should work for amd64/bookworm or newer; I have a compilation issue with bullseye that I need to figure out (not much of a C++ expert, got stuck at C/glib myself).

/usr//include/openvpn/client/ovpncli.hpp:571:5: warning: inline variables are only available with ‘-std=c++17’ or ‘-std=gnu++17’

i386 compilation is also failing, didn't look into that one either.

Just checkout master and run fakeroot dpkg-buildpackage --no-sign; sudo debi

Feel free to comment, review
https://salsa.debian.org/televic-team/openvpn3
https://salsa.debian.org/televic-team/openvpn3-linux

[dsommers]

@mleeman That's really cool you're looking into this!

In regards to i386 ... There are some issues on some of the C++ templates converting between C++ data types to D-Bus data types which is not really happy on 32-bit platforms. Since the wast majority of users are on 64-bit platforms, this has not been a high priority to resolve.

The documentation need to be updated also, the minimum C++ standard now will be C++17; this is due to the OpenVPN 3 Core library moved to that a while back. Further, the glib2 refactoring for #171 will also require C++17.

In regards to source code, we will always publish source code as tarballs as well; which includes everything needed to build with ./configure. The v20 is pushed out here:
https://swupdate.openvpn.net/community/releases/openvpn3-linux-20.tar.xz
https://swupdate.openvpn.net/community/releases/openvpn3-linux-20.tar.xz.asc

If you want, I can provide a similar development source tarball for the binary posted a bit earlier today.

Please reach out to me if you see any changes on our end to make the packaging better and/or smoother. Ideally we should not need to ship our own builds as a third-party repos. And this goes both for potential packaging efforts of the OpenVPN 3 Core library as well as the OpenVPN 3 Linux project.

In regards to packaging, lintian will complain about D-Bus policies being too broad. I discussed a missing feature with the upstream "dbus-daemon" developers some years ago, and got acceptance for the send_destination_prefix support. IIRC, that arrived in dbus-daemon-1.14, but I'm uncertain about dbus-broker support. This is basically the main detail to get rid of the lintian complaints.

[mleeman]

To me, it does not really matter; packaging follows (as much as possible) upstream.

I have mirrored the packaging structure on the git repo; so if you tag your release in github, I can fetch the tarball from there.

$ cat debian/watch 
version=4
opts=filenamemangle=s/.+\/v?(\d\S+)\.tar\.gz/openvpn3-$1\.tar\.gz/ \
  https://github.com/openvpn/openvpn3/tags .*/v?(\d\S+)@ARCHIVE_EXT@

If you prefer to have full/integrated tarballs that you release on your website, I can change the watch files to match.

I have indeed added a number of lintian-overrides (needs to be reviewed over time), but we have a working solution atm.

As for patches, I'll send the ones that are valuable to the mailing list once the dust settles.

[mleeman]

FYI, there is some low hanging fruit (spelling errors) that got picked up by the debian tooling

https://mentors.debian.net/package/openvpn3-linux/
https://mentors.debian.net/package/openvpn3/

    authentification authentication [usr/bin/ovpncli]
    authentification authentication [usr/lib/x86_64-linux-gnu/_ovpncli.so]
    laoding loading [usr/bin/ovpncli]
    laoding loading [usr/lib/x86_64-linux-gnu/_ovpncli.so]

and

    Adress Address [usr/libexec/openvpn3-linux/openvpn3-service-netcfg]
    Transfered Transferred [usr/libexec/openvpn3-linux/openvpn3-service-configmgr]
    Transfered Transferred [usr/libexec/openvpn3-linux/openvpn3-service-sessionmgr]
    Unkown Unknown [usr/sbin/openvpn3-admin]
    authentification authentication [usr/bin/openvpn3]
    authentification authentication [usr/libexec/openvpn3-linux/openvpn3-service-client]
    laoding loading [usr/bin/openvpn3]
    laoding loading [usr/libexec/openvpn3-linux/openvpn3-service-aws]
    laoding loading [usr/libexec/openvpn3-linux/openvpn3-service-client]
    occured occurred [usr/sbin/openvpn3-admin]
    subsciber subscriber [usr/bin/openvpn3]
    subsciber subscriber [usr/sbin/openvpn3-admin]
    unkown unknown [usr/libexec/openvpn3-linux/openvpn3-service-client]

[dsommers]

• Source tarball
  While I see the simplicity of pulling the tarball from github, it is not a proper distribution tarball; it's a git snapshot not including any dependencies. The tarballs we publish will have all dependencies and those tarballs are what is being used across all our builds - including Fedora Copr builds (and later upstream Fedora packaging). These tarballs are the one used through our QA processes and should also be prepared to comply to reproducible builds requirements; that the built binary will be identical - as long as the distribution and compiler chain is the same. And the authenticity of these tarballs can be verified through our PGP signature.

• Packaging of OpenVPN 3 Core library is dubious
  It is primarily a source header-only library. While it can produce a libopenvpn3.so in some cases; that is only used for clients not written in C++ where a glue layer is needed - and it depends on swig to work. OpenVPN 3 Linux does not depend on a shared library (and probably won't go that path). Packaging OpenVPN 3 Core library should probably just be a -dev package with only the header files from ./client, ./doc and ./openvpn.

• I'll look at all the typos and such; that should be fine to get fixed.

[dsommers]

@mleeman Two quick patches fixing the openvpn3-linux typ0s ...

• https://codeberg.org/OpenVPN/openvpn3-linux/commit/2755c95728cae3bfe347c4153d6d4f959d02a4ca
• https://codeberg.org/OpenVPN/openvpn3-linux/commit/8881bf35c835c7deab439c87a7efc09444caef84

These are queued up for the coming v21 release.

[mleeman]

fine with me, I will adjust the client to use your published snapshots.

Is there a page where the index can be queried of the releases, any other URL but https://swupdate.openvpn.net/community/releases/openvpn3-linux-21.tar.xz does not seem to work.

the openvpn maintainers use this page:

https://openvpn.net/index.php/open-source/downloads.html 

But openvpn3 is not listed there.

$ cat Development/salsa/openvpn/debian/watch 
version=4
https://openvpn.net/index.php/open-source/downloads.html \
(?:|.*/)openvpn(?:[_\-]v?|)(\d[^\s/]*)\.(?:tar\.xz|txz|tar\.bz2|tbz2|tar\.gz|tgz)

[dsommers]

@mleeman Good point on the publicity aspects of new releases. We will look into how to do that better. Perhaps a quick solution for now would be to have use this file I just now pushed out: https://swupdate.openvpn.net/community/releases/openvpn3-linux.latest

If you want a different layout here, we can probably script that a bit better.

The version scheme is also fairly simple. I'm going to use three "release categories":

• stable releases: v20 - openvpn3-linux-20.tar.xz{,.asc}
• beta releases: v19_beta - openvpn3-linux-19_beta.tar.xz{,.asc}
• development releases: v22_dev - openvpn3-linux-22_dev.tar.xz{,.asc}

Stable releases will be the only releases which might have a minor version, like v20.1. This is only happening where the next stable release is "too far away" and there is an important bug or security fix needed. In this case, the version strings will be:

• stable hotfix: v20.1 - openvpn3-linux-20.1.tar.xz{,.asc}

This openvpn3-linux.latest could perhaps be extended to have a "release category" tag as well. Like stable:20 and development:22_dev. With a "stable hotfix", the stable: line would be stable:20.1.

In a Debian and Ubuntu LTS context, I think it would be best stay on the stable releases in the longer run. For Ubuntu non-LTS, the beta releases might be applicable. The development builds might be best being a separate repository we update more frequently.

Let me know what you think about this.

[mleeman]

• Starting from your snapshot and by removing all the patches (that I had previously added) gives a clean compilation, so your release tarball is an excellent starting point. If you prefer this route, then this is the one we'll be taking. It's easy and it's clean.
• I agree that only the stable releases should come in Debian, it's fine if someone uses the build infrastructure to experiment, but that is outside of the scope of Debian itself.
• One thing I was thinking about over the weekend is the name of the package. At the moment it is openvpn3 or openvpn3-linux. When comparing this to the openvpn2 releases, a better name might be openvpn3-client, since (AFAIK) it only contains the client part. Nothing changes at your end, just on mine.

Let me know what you prefer and I'll reset my salsa branches to your to the release tarball instead of the one generated from github.

[dsommers]

Regarding 1), that sounds like the best approach to me too; I generally would like package maintainers to add as few additional patches as possible - get them upstream first. (I'm also a Fedora package maintainer, so I have some packaging experience as well)

We are aligned on the "stable" versions in Debian, so nothing more to discuss there.

Packaging names ... okay, so this is "complicated". But it is related to some project names:

• "OpenVPN 3 Linux" (openvpn3-linux) is this project; the (primarily, but not necessarily restricted to) Linux implementation of the "OpenVPN 3 generation"
• "OpenVPN 3 Core Library" (openvpn3) is the implementation of the OpenVPN protocol as the 3rd generation.

Currently the openvpn3-linux project has only implemented the client side - but I would like to have a server side implementation too in the future. In the Fedora packaging, there are more sub-packages:

• openvpn3
  Provides the generic components; configuration manager (openvpn3-service-configmgr), log service (openvpn3-service-logger), network configuration (openvpn3-service-netcfg), the Python module [1], the openvpn3and openvpn3-admin CLI tools, the openvpn3-autoload (deprecated, but will be shipped at least until next summer - RHEL 7 EOL), as well as some support files for all of this and some docs.
• openvpn3-client
  Provides the client side components: The client services (openvpn3-service-backendstart, openvpn3-service-client), the openvpn2 and openvpn3-as CLI tools and the openvpn3-systemd helper and the [email protected] systemd unit, plus other related support files, man pages and such
• openvpn3-addon-aws -
  Contains an optional add-on component (for AWS-VPC integration), provides the openvpn3-service-aws and related support files and man page
• openvpn3-selinux
  SELinux policy to confine the some of the services and allow D-Bus daemon to pass access to the tun/dco interfaces between two D-Bus enabled processes.
• openvpn3-devel
  Contains some generated files which is installed under /usr/include/openvpn3 ... and they are not related to the Core library itself.

The intension behind these package names is that

• openvpn3 itself is what is needed to run either a client or a server functionality. It does not relate to the OpenVPN 3 Core library (header) files, as that is not an end-user functionality.
• openvpn3-client need to depend on openvpn3, since that component builds on the openvpn3 basic functionality to provide the client functionality. This is the same rationale as for the openvpn3-addon-aws package.
• When a server functionality will come, that would ideally be an openvpn3-server sub-package; which can be installed without the openvpn3-client package installed - and vice versa.

If we would package the OpenVPN 3 Core library, that should be named libopenvpn3-devel or something like that. It does not provide an end-user product, but a library to implement the OpenVPN protocol. This code does contain a reference test client, but that is not something you would put into production as is.

The reason the Debian packaging does not have such splits as the Fedora is that I heard from a Debian maintainer many years ago that Debian generally prefers to avoid sub-packages and only use them when strictly needed. In the Fedora land, sub-packages are more often used to split out functionality which does not need to be installed to have something working. The -selinux package is also more a common way how to clearly indicate that this project will touch the SELinux policy on the system.

But you are of course free to do package this project in Debian as you see fit best with the Debian packaging guidelines.

[mleeman]

Debian packaging (in general) does tend to use smaller sub packages. What I would propose is to:

1. start by packaging openvpn3-linux into a package openvpn3-client. It describes clearly what it is: a client for openvpn3 functionality. For starters, I'd bundle all the tools that are shipped with openvpn3-linux.
2. it's great that there is a server component coming. At that point a bit more work will be needed; though I think that the starting point will probably not be the tarball we discussed before; but a number of different sub releases. When this is the case, we'll probably have packages with names like: libopenvpn3-dev (including the version to avoid conflicting with /usr/include/openvpn) and libopenvpn3 that are dependencies for openvpn3-client and openvpn3-server. To some extent, this was they way I started working; but in retrospect (and until there is a server component,) it is probably overkill.

This way, the packaging names match to some extent the ones you defined for rpm packaging. As the need arises and if it is useful, I can split off components into different packages. At the moment, I would focus on getting openvpn3 into Debian/Ubuntu as is, while staying very close to your releases: it give you a much better level of control on what you want to release and in what form.

How does this sound?

[dsommers]

That sounds great! Currently the packages (and docs) in our provided releases uses the openvpn3 package name. There are also some docs for CloudConnexa which also needs to be updated.

Perhaps we should move our (OpenVPN Inc provided) packaging to also use the openvpn3-client with a "Provides" openvpn3 for a short time as we move forward? It would be great if the packages we provide will be compliant with the upstream Debian ones and not causing conflicts in any way.

[flichtenheld]

In openvpn2 we use the official Debian/Ubuntu packages as base and update from that as needed for the Community releases. Once there is official Debian packaging for openvpn3 we should probably go to a similar model.

[mleeman]

I have an initial version, most of the code could be re-used

https://salsa.debian.org/televic-team/openvpn3-client

One lintian error popped up that will probably require me to re-package the code:

E: openvpn3-client source: license-problem-convert-utf-code [openvpn3-core/openvpn/common/unicode-impl.hpp]
N: 
N:   The following file source files include material under a non-free license from Unicode Inc. Therefore, it is not possible to ship this in main or contrib.
N:   
N:   This license does not grant any permission to modify the files (thus failing DFSG#3). Moreover, the license grant seems to attempt to restrict use to "products supporting the Unicode
N:   Standard" (thus failing DFSG#6).
N:   
N:   In this case a solution is to use libicu and to remove this code by repacking.
N: 
N:   Please refer to Bug#823100 for details.
N: 
N:   Visibility: error
N:   Show-Always: no
N:   Check: cruft
N: 
N:

Another one I need to look into, seems to be some data that is used during a test

E: openvpn3-client source: source-is-missing [openvpn3-core/test/unittests/comp-testdata/sum]

[dsommers]

We need to come up with a solution for that license issue in the OpenVPN 3 Core library. It's essentially a public domain license, which shouldn't really be a problem - but legalese is always annoying.

that comp-testdata/sum is essentially just a random binary which is only used for compression testing in the Core library unit tests. That file should also be replaced by some real random binary data and not a binary executable (which in this case is even for the Sparc CPU arch).

Both of these issues are coming from the OpenVPN 3 Core library.

[mleeman]

I am searching a bit and have found e.g.

https://llvm.org/doxygen/ConvertUTF_8h_source.html

it seems to be the same source and llvm is in main. The warning states:

N:   This license does not grant any permission to modify the files (thus failing DFSG#3). Moreover, the license grant seems to attempt to restrict use to "products supporting the Unicode
N:   Standard" (thus failing DFSG#6).

while the header file says (copy):

17  * Unicode, Inc. hereby grants the right to freely use the information
 18  * supplied in this file in the creation of products supporting the
 19  * Unicode Standard, and to make copies of this file in any form
 20  * for internal or external distribution as long as this notice
 21  * remains attached.

The file in llvm has a more recent copyright:

/*===--- ConvertUTF.h - Universal Character Names conversions ---------------===
 *
 * Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
 * See https://llvm.org/LICENSE.txt for license information.
 * SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
 *
 *==------------------------------------------------------------------------==*/
/*
 * Copyright © 1991-2015 Unicode, Inc. All rights reserved.
 * Distributed under the Terms of Use in
 * http://www.unicode.org/copyright.html.
 *
 * Permission is hereby granted, free of charge, to any person obtaining
 * a copy of the Unicode data files and any associated documentation
 * (the "Data Files") or Unicode software and any associated documentation
 * (the "Software") to deal in the Data Files or Software
 * without restriction, including without limitation the rights to use,
 * copy, modify, merge, publish, distribute, and/or sell copies of
 * the Data Files or Software, and to permit persons to whom the Data Files
 * or Software are furnished to do so, provided that
 * (a) this copyright and permission notice appear with all copies
 * of the Data Files or Software,
 * (b) this copyright and permission notice appear in associated
 * documentation, and
 * (c) there is clear notice in each modified Data File or in the Software
 * as well as in the documentation associated with the Data File(s) or
 * Software that the data or software has been modified.
 *
 * THE DATA FILES AND SOFTWARE ARE PROVIDED "AS IS", WITHOUT WARRANTY OF
 * ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE
 * WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
 * NONINFRINGEMENT OF THIRD PARTY RIGHTS.
 * IN NO EVENT SHALL THE COPYRIGHT HOLDER OR HOLDERS INCLUDED IN THIS
 * NOTICE BE LIABLE FOR ANY CLAIM, OR ANY SPECIAL INDIRECT OR CONSEQUENTIAL
 * DAMAGES, OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE,
 * DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER
 * TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
 * PERFORMANCE OF THE DATA FILES OR SOFTWARE.
 *
 * Except as contained in this notice, the name of a copyright holder
 * shall not be used in advertising or otherwise to promote the sale,
 * use or other dealings in these Data Files or Software without prior
 * written authorization of the copyright holder.
 */

Maybe there has been an update since the 2001-2004 version that is in the core lib?

Another reference:
https://sources.debian.org/src/desmume/0.9.11-2/src/utils/ConvertUTF.h/

[dsommers]

Good find! Thanks a lot for your research! Will dig into this and find a better licensed version.

This is anyhow something needed to be tackled in the openvpn3 repository and will need to come in the next OpenVPN 3 Core release before pulling it into this (openvpn3-linux) project.

[bhack]

A bit unrelated:
do you think that this package is going to conflict with network manager openvpn in distros?
See #46

[mleeman]

yes there is,

There have been a number of iterations that improved the quality of the package itself and the licensing was also a bit of a struggle to get through (and it needed some review).

Unfortunately; Debian is not what is used to be wrt the inclusion of new packages: I have uploaded the package twice to be included via mentors only to be removed again after a timeout since it no-one was willing to sponsor it.

Coincidentally, I was planning to upload the package again with hopes that it would be picked up at some point.

[detlefla]

Is your package available somewhere (as a .deb)?
Building from source fails for me (e.g. libgdbuspp-dev cannot be found).

[mleeman]

Sure, I uploaded the bookworm backport to my opensuse account [1], once it finished publishing, you should find it here [2]

[1] https://build.opensuse.org/project/show/home:den_erpel:bookworm-backports
[2] https://download.opensuse.org/repositories/home:/den_erpel:/bookworm-backports/Debian_12/amd64/

[detlefla]

Thank you for making the package available. It doesn't install, however, on testing / unstable (trixie) as it depends on libtinyxml2-9 and trixie has libtinyxml2-10. (That's the one it fails on; not sure if there are more broken dependencies.)

[mleeman]

I will make a package available tomorrow for unstable.

…

On Mon, 4 Nov 2024, 19:04 detlefla, ***@***.***> wrote: Thank you for making the package available. It doesn't install, however, on testing / unstable (trixie) as it depends on libtinyxml2-9 and trixie has libtinyxml2-10. (That's the one it fails on; not sure if there are more broken dependencies.) — Reply to this email directly, view it on GitHub <#193 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAKXDFAAJBUYMU34K2X7KZDZ66ZLPAVCNFSM6AAAAABREIUM46VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINJVGM3TIMZYGA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[alee-ntap]

@mleeman Would you mind to forward previous reject message from Debian's ftp-master to your ITP on Debian's bug tracker, and continue to work to make it in Debian unstable? I know there are some reasons you possibility doesn't agree. So make it in the public in the ITP and request for help then.

[mleeman]

Here you go:

https://download.opensuse.org/repositories/home:/den_erpel:/trixie-backports/Debian_Unstable/amd64/

[mleeman]

@mleeman Would you mind to forward previous reject message from Debian's ftp-master to your ITP on Debian's bug tracker, and continue to work to make it in Debian unstable? I know there are some reasons you possibility doesn't agree. So make it in the public in the ITP and request for help then.

Yeah, I'll pick it up again: I gave it a breather because of the long discussions about the licence checks. Unrelated, I had a reject on a introducing a package because it was circumventing bandwidth limitations :-) (apt-fast).

[mleeman]

@alee-ntap The feedback of ftp-master was handled IIRC; I prepared a package (I believe just before the summer) and got it uploaded and reviewed on mentors. There was even an endorsement of a very helpful British guy; but no-one was interested in picking it up for for upload.

Like I said, I'll push it again and see if I can get things rolling again...

[detlefla]

@mleeman Many thanks for providing the .deb! It's installable and runnable. Can't make it connect to our server yet – but this may be a local problem.

[alee-ntap]

@mleeman

@alee-ntap The feedback of ftp-master was handled IIRC; I prepared a package (I believe just before the summer) and got it uploaded and reviewed on mentors. There was even an endorsement of a very helpful British guy; but no-one was interested in picking it up for for upload.

I uploaded it once for you into NEW queue, but got rejected by ftp-master.

Like I said, I'll push it again and see if I can get things rolling again...

And I can upload it again. It would be nice to append the rejected message into your ITP. So that we can check if all the issue mentioned by ftp-master got fixed in the next try. :)

[mleeman]

@alee-ntap

Sorry for the delay, was caught up i n other work. Unfortunately, I fail to find the original mail from ftp-master, but the ITP [1] has remarks and replies from a couple of people, so has the discussion on mentors [2] and the RFS [3]. I uploaded a new version last week that disables the aws service at the moment (default it failed to start so it's good to get that out).

I believe that most of the remarks that can be addressed, have been addressed.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=904044
[2] https://mentors.debian.net/package/openvpn3-client/
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1053565

[danterolle]

Hello everyone! I'm joining those who have tried building openvpn3-linux. In the guide, libssl1.1 is listed among the dependencies, but if I'm not mistaken, it is no longer needed (on Debian 12, for instance, the package is not found). Perhaps it should be removed? I'm eagerly waiting for libgdbuspp-dev to become available, and especially for the .deb package.

[mleeman]

@danterolle if you use the sources on salsa [1], you can just use the standard debian tooling; I've built it in a clean chroot a couple weeks ago for bookworm and trixie.

libssl1.1 is a dependency that is generated during packaging. See the posts above for packages built for debian 12 and debian 13 [2][3].

[1] https://salsa.debian.org/erpel/openvpn3-client
[2] https://download.opensuse.org/repositories/home:/den_erpel:/trixie-backports/Debian_Unstable/amd64/
[3] https://download.opensuse.org/repositories/home:/den_erpel:/bookworm-backports/Debian_12/amd64/

[dsommers]

@mleeman I just had a look at your salsa tree .... that is quite outdated now, unless I looked at the wrong places.

The v23 release is the latest stable release (I'm wrapping up v24 these days). Some huge and important differences ...

• autotools are now removed in favour of the Meson build system (that's the huge change)
• You also need the GDBus++ library now to build anything newer than the v21 release. Everything needed is here: https://codeberg.org/OpenVPN/gdbuspp/

I believe I have applied some suggested changes from you, but I'm not up-to-date right now if anything is missing. Please bug me if there are things which could be done better - and I'll try to get things sorted out quicker.

[mleeman]

No, no, it is still the same one.

bummer, I must have missed the releases, I'll update the tree.

I'll need to have a look at the changes, but the most important ones for me at the moment are listed under DFSG changes:
https://salsa.debian.org/erpel/openvpn3-client/-/blob/master/debian/README.source?ref_type=heads

These require me to recreate the release tarball.

[dsommers]

I'll follow up on the Sparc binary ... I have a few options here. It's too late for the v24 release (I pushed out an updated master the yesterday).

In regards to the unicode headers ... the LLVM versions did not work out in the Core library without more modifications in the Core library. This is on our todo list to fix. But it's a different project OpenVPN 3 Linux depends on, so it's a bit more work to complete this one.

When it comes to a "watch file" for releases ... this should be possible to use: https://swupdate.openvpn.net/community/releases/openvpn3-linux.latest

[mleeman]

I am having a look at updating the the release of September. The most important issue atm is that the new version depends on a new library that is also not in Debian. Packaging is not a problem (done it already), but getting it in will take some time (ITP, RFS, review, ...).

Only then will I be able to upload the new openvpn3-client.

I'll keep on trying to get the v21 in in parallel since this one has been reviewed extensively.

I can provide the working progress packages as above.

The gdbuspp packages build for bookworm and trixie, so that's good.

'../libgdbuspp3_2~televic12+1_amd64.deb'.
'../libgdbuspp3-dbgsym_2~televic12+1_amd64.deb'.
'../libgdbuspp-dev_2~televic12+1_amd64.deb'.

[dsommers]

@mleeman Just a heads-up on v21 and older versions. They will have issues with glib2-2.76 and newer (see #171 for an extensive discussion). That's what led to writing the GDBus++ library.

[dsommers]

Also ... v24 is being pushed out the door ... our own apt/dnf/yum repos are not yet updated (that's what's brewing right now), but source tarballs are published:

• OpenVPN 3 Linux v24
  https://swupdate.openvpn.net/community/releases/openvpn3-linux-24.tar.xz
  https://swupdate.openvpn.net/community/releases/openvpn3-linux-24.tar.xz.asc

• GDBus++ v3
  https://swupdate.openvpn.net/community/releases/gdbuspp-3.tar.xz
  https://swupdate.openvpn.net/community/releases/gdbuspp-3.tar.xz.asc

[mleeman]

No worries, I'm working on getting this in Debian for a year now, not about to give up now...

[mleeman]

The port to debian 12 is done, the one to unstable/trixie should be a breeze now. Most work was in figuring out new Build-Depends in the chroot builds. Tomorrow, I'll clean up the commits.

I need to change the openvpn user again with the new build system though to include an underscore, the env. variables are no longer taken into account in debian/rules (they are listed in meson_options.txt):

marc@moya:~/Development/salsa/openvpn3-client$ ps -ef |grep vpn
openvpn  1855769       1  0 17:58 ?        00:00:00 /usr/libexec/openvpn3-linux/openvpn3-service-sessionmgr
openvpn  1855774       1  0 17:58 ?        00:00:00 /usr/libexec/openvpn3-linux/openvpn3-service-configmgr --state-dir /var/lib/openvpn3/configs
openvpn  1855776       1  0 17:58 ?        00:00:00 /usr/libexec/openvpn3-linux/openvpn3-service-log --state-dir /var/lib/openvpn3
openvpn  1855908       1  0 17:58 ?        00:00:00 /usr/libexec/openvpn3-linux/openvpn3-service-client 1de169d4t61f4t40aat8110t787902c08a7d
openvpn  1855915       1  0 17:58 ?        00:00:00 /usr/libexec/openvpn3-linux/openvpn3-service-netcfg --state-dir /var/lib/openvpn3

Next, I'll pull in the 24 release. For completeness, I prefer to have the official releases included in the gbp repositories.

I'll call it a day.

[dsommers]

@mleeman Just for clarity ... Those sources I pointed at are the official release source tarballs; they are complete. I've just not announced the release yet. We have our own set of package repos in parallel to upstream Linux distro repos, the announcement will be done when those repos are updated.

Here is a signed blob (with the [email protected] key, same key used in the .asc files above) with the SHA256 hashes of all the files:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

9ecf8dccdbc601c4325b0248db7cb1e39c8689e3b99f5fc801b42056d68a7256  openvpn3-linux-24.tar.xz
a3d6bd735d46958f2458484a4338eaf894e710ac895852c9c734671a2e46e821  openvpn3-linux-24.tar.xz.asc
c7a053a13c4eb5811a542b747d5fcdb3a8e58a4a42c7237cc5e2e2ca72e0c94e  gdbuspp-3.tar.xz
b9cf732d7a347f324d6a5532dc48f80c2815dbf6704c169b4ee97a411506a99b  gdbuspp-3.tar.xz.asc
-----BEGIN PGP SIGNATURE-----

iQJJBAEBCAAzFiEEV+lQSddqo5p0Q5YDUzpoYFKfI8UFAmdRZBwVHHNlY3VyaXR5
QG9wZW52cG4ubmV0AAoJEFM6aGBSnyPF9VUP/jXBW/EtQ4Efgz87mGklOOtMGYax
nz5Dt8KOAFuSj38y7Y1Zwo5cQQlnVcZGmfByohalf3XDGpb3Pci2cIvB42cSZYh3
z7oSZvCorndKwmhQIByz0FSiLwD0iQ4gEwdPO7UjES7Vb3X9iYU+6ijQkvfuaYfe
UQ7Vmc8+lHDNp0iqepM9mw2dDGOx4A03l8nsvxvgWLIiZ1/1/IVBmNaifZEpQH5S
KOOCElkSlQT+zZ9rgKtuLmPw2hJhsLIDmdn/yobdpZ2wR2pWxPCg8HxUFEi9AvoZ
+K2uc8KPh+04YNfo8RJKpdveAtMETpwF+dRiTk3lPYdfD2horsIk89hgFpXi2UPU
krE0u68woUAJFMy2tWFR4IrQBFptT0Mp14R4ddkJId2ukemVuhwlimdv61uzJx9r
kYfyc3H66sPKcexDnVSFi+aJEzo7DjpUx4oq4Ix64DXVBRqmCzGnc8jEiUOn5MdB
PMi7ipLHJiSqfAMWhNC424Oudrv4/ytXL8j7bamj2bl6tZW0uYc4tCrAA/37kwB5
Aud8gW4w0gZVY6rA5tOYSjikIndQu8f0UFBsoryjUNJBBJNDw8tcDZY9YeWIkTdi
glLp6RuHnk4dLkgOARK9qARKefFscx/VSnPxnWBjfW73vBllz3mXX0CSFmDgS5UB
EKHEgnllibySz+t+
=RPsC
-----END PGP SIGNATURE-----

[mleeman]

@dsommers

repositories are up to date, packages built in clean chroot. openvpn3-client is still dfsg

https://salsa.debian.org/erpel/openvpn3-client
https://salsa.debian.org/erpel/gdbuspp

once I am at home, my ITP will be sent by my MTA; when I have some time, I'll upload/update the versions on my OBS repositories too.

Published (amd64):

https://download.opensuse.org/repositories/home:/den_erpel:/bookworm-backports/Debian_12/amd64/
https://download.opensuse.org/repositories/home:/den_erpel:/trixie-backports/Debian_Unstable/amd64/

[mleeman]

Hmm,

seems as if not all replacements are done when using a different user:

These 3 files have the default user:

/usr/share/dbus-1/system-services/net.openvpn.v3.configuration.service
/usr/share/dbus-1/system-services/net.openvpn.v3.log.service
/usr/share/dbus-1/system-services/net.openvpn.v3.sessions.service

I think this should do it, testing it now:

$ cat debian/patches//0002_fix-openvpn-to-_openvpn.patch
Index: openvpn3-client/src/configmgr/meson.build
===================================================================
--- openvpn3-client.orig/src/configmgr/meson.build
+++ openvpn3-client/src/configmgr/meson.build
@@ -45,7 +45,6 @@ configure_file(
             'BUSNAME': 'net.openvpn.v3.configuration',
             'SERVICE_BIN': bin_backend_configmgr.name(),
             'SERVICE_ARGS': '--state-dir "' + openvpn3_statedir + '/configs"',
-            'OPENVPN_USERNAME': 'openvpn',
         }
     ),
     install: true,
Index: openvpn3-client/src/log/meson.build
===================================================================
--- openvpn3-client.orig/src/log/meson.build
+++ openvpn3-client/src/log/meson.build
@@ -44,7 +44,6 @@ configure_file(
             'BUSNAME': 'net.openvpn.v3.log',
             'SERVICE_BIN': bin_backend_log.name(),
             'SERVICE_ARGS': '--state-dir "' + openvpn3_statedir + '"',
-            'OPENVPN_USERNAME': 'openvpn',
         }
     ),
     install: true,
Index: openvpn3-client/src/sessionmgr/meson.build
===================================================================
--- openvpn3-client.orig/src/sessionmgr/meson.build
+++ openvpn3-client/src/sessionmgr/meson.build
@@ -46,7 +46,6 @@ configure_file(
             'BUSNAME': 'net.openvpn.v3.sessions',
             'SERVICE_BIN': bin_backend_sessionmgr.name(),
             'SERVICE_ARGS': '',
-            'OPENVPN_USERNAME': 'openvpn',
         }
     ),
     install: true,

[dsommers]

@mleeman whoops! That's an ugly mishap! I agree, that patch should fix it.

Could you send a patch to the openvpn-devel mailing list with your fix? Then I'll get that applied to git master asap.

[mleeman]

after I get my VPN connection up and running ;-)

getting this with 24, investigating

Dec 06 09:21:43 moya net.openvpn.v3.log[1403]:  {tag:13961402122662001886} Client !! CRITICAL !!: Failed changing DNS Scope: No DNS resolver configured

[dsommers]

@mleeman Stop all the openvpn3-service-* processes (kill -INT will be enough). Then try running openvpn3-admin init-config --write-configs as root. See if that helps.

In our own .deb packaging we do this in a postinst script:

# Do not fail, just log any errors
set +e
LOGDEST="/var/lib/openvpn3/openvpn3-init-config.log"
echo "" >> "$LOGDEST"
echo "** openvpn3-admin init-config start -- `date`" >> "$LOGDEST"
/usr/sbin/openvpn3-admin init-config --write-configs >> "$LOGDEST" 2>&1
echo "** openvpn3-admin init-config done (exit-code: $?)" >> "$LOGDEST"

The --write-configs can be removed for a "dry-run". And it will never overwrite any pre-existing configuration files, unless you give the --force argument in addition.

The reason for preserving the log is for our support team to quickly get an idea how the openvpn3-linux stack has been configured when the package was installed.

[mleeman]

Thanks, that did the trick, I'll add it.

[dsommers]

@mleeman FYI ... I've applied your patch and fixed spelling issues. They're in the master branch, commit 9a1cf3f and commit 6b16d11