Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Alpine/musl support #50

Closed
kevin-lindsay-1 opened this issue Jun 11, 2021 · 64 comments
Closed

Alpine/musl support #50

kevin-lindsay-1 opened this issue Jun 11, 2021 · 64 comments
Assignees
Labels
distribution-support Support for new distributions or distribution versions fixed Issue is claimed to be fixed, but should be tested before closing it need testing Need more testing to see if issue us still present

Comments

@kevin-lindsay-1
Copy link

Currently attempting to build this for alpine, it looks like most things are good, a missing #include <sys/types> and <unistd.h> in a couple spots, but otherwise looks like I should be able to build this.

It would be really nice to just be able to install this via apk, or even the binaries. Building projects like this is not a specialty of mine, so ever updating might be kinda painful.

@kevin-lindsay-1
Copy link
Author

Specifically it looks like src/common/lookup.cpp and its tests don't include the headers; I created a branch that adds the headers and it got past those files just fine, although I don't know the standard libraries in C++/GNU well enough to know which of the two were specifically needed.

@dsommers
Copy link
Member

dsommers commented Jun 11, 2021

Thanks a lot for your feedback. First, in regards to providing packages for Alpine - that'd be great. Unfortunately we do not have capacity to support too many distributions directly. But if you or someone you know would be willing to do the grunt work getting it packaged, I will support you and help you figure out the various obstacles you're hit with.

In regards to the missing headers. This is most likely plausible. Just point me at your branch and I'll cherry-pick your changes. It would also be good to see a copy of your config.log from your ./configure run. So if you could just pastebin that (or use https://gist.github.com/), that'd be helpful to understand how you build it.

@dsommers dsommers self-assigned this Jun 11, 2021
@kevin-lindsay-1
Copy link
Author

I have a dockerfile for this if you'd like it when I'm done; haven't finished the build yet because there's some stuff in core that I need to patch out in some way. Rebuilding now, takes a little while.

@kevin-lindsay-1
Copy link
Author

kevin-lindsay-1 commented Jun 11, 2021

@dsommers in https://github.com/OpenVPN/openvpn3/blob/master/openvpn/common/endian64.hpp#L53

Any idea how to make sure this uses the musl variant? Getting not declared for the default, which looks like that follows, according to https://git.musl-libc.org/cgit/musl/tree/include/byteswap.h

Doing a monkeypatch to see if I can find the proper syntax.

@kevin-lindsay-1
Copy link
Author

kevin-lindsay-1 commented Jun 11, 2021

Ok looks like it built, doing a make install now, and getting:

 [openvpn3 47/47] RUN make install
       → make  install-recursive
       → make[1]: Entering directory '/usr/root/openvpn3-linux'
       → Making install in src/python
       → make[2]: Entering directory '/usr/root/openvpn3-linux/src/python'
       → make  install-am
       → make[3]: Entering directory '/usr/root/openvpn3-linux/src/python'
       → make[4]: Entering directory '/usr/root/openvpn3-linux/src/python'
       →  ../.././install-sh -c -d '/usr/bin'
       →  /usr/bin/install -c openvpn2 openvpn3-as '/usr/bin'
       →  ../.././install-sh -c -d '/usr/sbin'
       →  /usr/bin/install -c openvpn3-autoload '/usr/sbin'
       →  ../.././install-sh -c -d '/usr/lib/python3.8/site-packages/openvpn3'
       →  /usr/bin/install -c -m 644 openvpn3/constants.py '/usr/lib/python3.8/site-packages/openvpn3'
       → Byte-compiling python modules...
       → constants.py
       → Byte-compiling python modules (optimized versions) ...
       → constants.py
       →  ../.././install-sh -c -d '/usr/lib/python3.8/site-packages/openvpn3'
       →  /usr/bin/install -c -m 644 openvpn3/__init__.py openvpn3/ConfigParser.py openvpn3/ConfigManager.py openvpn3/NetCfgManager.py openvpn3/SessionManager.py '/usr/lib/python3.8/site-packages/openvpn3'
       → Byte-compiling python modules...
       → __init__.pyConfigParser.pyConfigManager.pyNetCfgManager.pySessionManager.py
       → Byte-compiling python modules (optimized versions) ...
       → __init__.pyConfigParser.pyConfigManager.pyNetCfgManager.pySessionManager.py
       → make[4]: Leaving directory '/usr/root/openvpn3-linux/src/python'
       → make[3]: Leaving directory '/usr/root/openvpn3-linux/src/python'
       → make[2]: Leaving directory '/usr/root/openvpn3-linux/src/python'
       → Making install in distro/systemd
       → make[2]: Entering directory '/usr/root/openvpn3-linux/distro/systemd'
       → make[3]: Entering directory '/usr/root/openvpn3-linux/distro/systemd'
       → make[3]: Nothing to be done for 'install-exec-am'.
       → ../.././install-sh -c -d "/etc/openvpn3"
       → ../.././install-sh -c -d -m750 "/etc/openvpn3/autoload"
       → ../.././install-sh: invalid option: -m750
       → make[3]: *** [Makefile:572: install-data-local] Error 1
       → make[3]: Leaving directory '/usr/root/openvpn3-linux/distro/systemd'
       → make[2]: *** [Makefile:456: install-am] Error 2
       → make[2]: Leaving directory '/usr/root/openvpn3-linux/distro/systemd'
       → make[1]: *** [Makefile:3609: install-recursive] Error 1
       → make[1]: Leaving directory '/usr/root/openvpn3-linux'
       → make: *** [Makefile:4088: install] Error 2

Here is the dockerfile as it stands now:

# edit: more up-to-date dockerfile in below comment

@dsommers
Copy link
Member

Any idea how to make sure this uses the musl variant? Getting not declared for the default, which looks like that follows, according to https://git.musl-libc.org/cgit/musl/tree/include/byteswap.h

Ouch. We haven't paid much attention to other libc libraries than glibc on Linux. Do you have some __MUSL__ macros defined by the library already, then we could take a patch to use bswap_64() if that macro is defined. Something like

#elif __MUSL__
      return bswap_64(value);
#else

@dsommers
Copy link
Member

These lines is actually slightly embarrassing

   → make[3]: Entering directory '/usr/root/openvpn3-linux/distro/systemd'
   → make[3]: Nothing to be done for 'install-exec-am'.
   → ../.././install-sh -c -d "/etc/openvpn3"
   → ../.././install-sh -c -d -m750 "/etc/openvpn3/autoload"
   → ../.././install-sh: invalid option: -m750

The /etc/openvpn3 directories should not be installed by the distro "component", but I'll let this pass for now :)

In regards to the invalid option, that might be an incompatibility with the install tool being used under the hood. That needs to be split up then to something like this in distro/systemd/Makefile.am:

 install-data-local:
         $(MKDIR_P) "$(DESTDIR)$(openvpn3_configdir)"
         $(MKDIR_P) "$(DESTDIR)$(openvpn3_configdir)/autoload" && chmod -m750 "$(DESTDIR)$(openvpn3_configdir)/autoload"

If this works for you, it's good enough for now. But I'll dive into this more closely to find a better approach. Need to verify if automake has a wrapper macro for chmod too.

@kevin-lindsay-1
Copy link
Author

kevin-lindsay-1 commented Jun 11, 2021

If you look at my forks and branches in that dockerfile, you should be able to pretty easily see the changes I made; the change in openvpn-core is definitely a monkeypatch, because I don't know which, if any __THINGY__ flag musl has for detection. I assume that's not a lib-specific thing.

Including headers and using bswap_64 allowed me to build, and manually editing out the -m750 allowed me to install it.

Now I have the fun part of trying to get dbus to work correctly. The things I do for a CLI with a "start" and "stop" command...

btw right now I'm trying to get past this:

/usr/root # openvpn3 session-start --config ./config.ovpn 
** ERROR ** Could not establish a connection with 'net.openvpn.v3.sessions'

dbus says it's running, and it wasn't started before on my image, so I'm not where, exactly, this issue is coming from.

As part of a multi-stage build I'm grabbing the outputs of the install, seen here:

# OpenVPN binaries
COPY --from=openvpn3 ["/usr/sbin/openvpn3-admin", "/usr/sbin/openvpn3-autoload", "/usr/sbin/"]
COPY --from=openvpn3 ["/usr/lib/python3.8/site-packages/openvpn3/*", "/usr/lib/python3.8/site-packages/openvpn3/"]
COPY --from=openvpn3 ["/usr/libexec/openvpn3-linux/*", "/usr/libexec/openvpn3-linux/"]
COPY --from=openvpn3 ["/usr/bin/openvpn2", "/usr/bin/openvpn3", "/usr/bin/openvpn3-as", "/usr/local/bin/"]
COPY --from=openvpn3 ["/etc/dbus-1/system.d/net.openvpn*", "/etc/dbus-1/system.d/"]
COPY --from=openvpn3 ["/etc/openvpn3/", "/etc/openvpn3/"]
RUN addgroup -S openvpn
RUN adduser -S openvpn -G openvpn

COPY ["./config.ovpn", "./"]

RUN openrc
RUN mkdir -p /run/openrc && touch /run/openrc/softlevel

COPY ["./entrypoint.sh", "./"]
CMD [ "./entrypoint.sh" ]

Ignore the config copying, lol, that's just for testing.

@dsommers
Copy link
Member

Can you try to run openvpn3-admin version --services ? Just to see what is available.

But ... are you trying to run an OpenVPN session inside a docker container?

@kevin-lindsay-1
Copy link
Author

kevin-lindsay-1 commented Jun 11, 2021

I missed two directories, which I added above.

Yep, I've done it before with openvpn2. I have CI/CD runners that need to connect to an AWS VPN in order to do kubernetes deployments via helm/helmfile.

Here's what I get right now:

/usr/root # openvpn3-admin version --services
OpenVPN 3 D-Bus services:

  - Client backend starter service

@dsommers
Copy link
Member

Alright, so there are massive difference between OpenVPN 2.x and OpenVPN 3 Linux. And we haven't fully prepared it for Docker/containers yet. But figuring out what's needed to make it happen is very valuable anyhow.

If you don't get anything else than just that from openvpn3-admin that means it is not capable of starting any services over D-Bus at all. The current model facilitates the D-Bus auto-start feature, and OpenVPN 3 Linux services will also automatically stop running when not needed any more. Without any logs, it's hard to see what happens and why. But might be related to privileges.

For a quick run-down of how these pieces are connected, have a look at this comment: #42 (comment)

Right now fetching logs related to the dbus-daemon/dbus-broker will be important to fully understand what is happening and not.

@kevin-lindsay-1
Copy link
Author

Oh, I'm doing a multi-stage build, so I think I was missing a file.

When I go over to the build container, here's what I get:

> docker run -it --privileged openvpn3-alpine sh
 * Checking local filesystems  ...                                                                 [ ok ]
 * Remounting filesystems ...                                                                      [ ok ]
 * Mounting local filesystems ...                                                                  [ ok ]
 * Starting System Message Bus ...                                                                 [ ok ]

/usr/root # openvpn3-admin version --service
OpenVPN 3 D-Bus services:

  - Client backend starter service
     openvpn3-service-backendstart: git:fix/musl:92b6ca8b3aedee2e

  - Configuration Service
     openvpn3-service-configmgr:    git:fix/musl:92b6ca8b3aedee2e

  - Log Service
     openvpn3-service-logger:       git:fix/musl:92b6ca8b3aedee2e

** ERROR ** Failed preparing proxy: Error calling StartServiceByName for net.openvpn.v3.netcfg: Process net.openvpn.v3.netcfg received signal 11

/usr/root # openvpn3 session-start --config ./config.ovpn 
** ERROR ** Failed calling D-Bus method Import: Message recipient disconnected from message bus without replying

@dsommers
Copy link
Member

dsommers commented Jun 11, 2021

That's a step forward. The net.openvpn.v3.netcfg error is critical. That's the service which will create/destroy tun devices and configure IP addresses, routing and DNS resolving. That error might indicate an unexpected exception. Would be great to see the logs when that happens.

If you're able to get the openvpn3-admin version --services to run without an error, then you're getting close.

@kevin-lindsay-1
Copy link
Author

kevin-lindsay-1 commented Jun 11, 2021

How do I grab those logs?

If you'd like to peruse, here's the files:

Dockerfile

###
# OpenVPN3
###
FROM alpine:3.13.5 AS openvpn3

WORKDIR /usr/root

## deps
RUN apk add --upgrade --no-cache "autoconf"
RUN apk add --upgrade --no-cache "autoconf-archive"
RUN apk add --upgrade --no-cache "automake"
RUN apk add --upgrade --no-cache "build-base"
RUN apk add --upgrade --no-cache "cmake"
RUN apk add --upgrade --no-cache "curl"
RUN apk add --upgrade --no-cache "gcompat"
RUN apk add --upgrade --no-cache "git"
RUN apk add --upgrade --no-cache "glib-dev"
RUN apk add --upgrade --no-cache "jsoncpp-dev"
RUN apk add --upgrade --no-cache "libc6-compat"
RUN apk add --upgrade --no-cache "libcap-ng-dev"
RUN apk add --upgrade --no-cache "linux-headers"
RUN apk add --upgrade --no-cache "lz4-dev"
RUN apk add --upgrade --no-cache "ninja"
RUN apk add --upgrade --no-cache "openssl-dev"
RUN apk add --upgrade --no-cache "pkgconf"
RUN apk add --upgrade --no-cache "tinyxml2"
RUN apk add --upgrade --no-cache "tinyxml2-dev"
RUN apk add --upgrade --no-cache "unzip"
RUN apk add --upgrade --no-cache "util-linux"
RUN apk add --upgrade --no-cache "wget"
RUN apk add --upgrade --no-cache "zip"

## download
WORKDIR /usr/root
ARG OPENVPN3_VERSION=13_beta
RUN git clone https://github.com/kevin-lindsay-1/openvpn3-linux
WORKDIR /usr/root/openvpn3-linux
# RUN git checkout v${OPENVPN3_VERSION}
RUN git checkout fix/musl
## bootstrap
WORKDIR /usr/root/openvpn3-linux
RUN ./bootstrap.sh
RUN rm -rf openvpn3-core
RUN git clone https://github.com/kevin-lindsay-1/openvpn3 openvpn3-core
# OpenVPN3-core submodule
WORKDIR /usr/root/openvpn3-linux/openvpn3-core
ARG OPENVPN3_CORE_VERSION=3.6.1
# RUN git checkout release/${OPENVPN3_CORE_VERSION}
RUN git checkout fix/musl
# Asio submodule
WORKDIR /usr/root/openvpn3-linux/vendor/asio
ARG ASIO_VERSION=1.18.2
RUN git checkout asio-${ASIO_VERSION//./-}
# Google Test submodule
WORKDIR /usr/root/openvpn3-linux/vendor/googletest
ARG GOOGLE_TEST_VERSION=1.10.0
RUN git checkout release-${GOOGLE_TEST_VERSION}
# OpenVPN-DCO submodule
WORKDIR /usr/root/openvpn3-linux/ovpn-dco
ARG OPENVPN3_DCO_VERSION=13
RUN git checkout linux-client-v${OPENVPN3_DCO_VERSION}

## build
WORKDIR /usr/root/openvpn3-linux
RUN ./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var --enable-addons-aws --disable-selinux-build --disable-build-test-progs --enable-debug-options CXXFLAGS="-g -Wall"
RUN make -j$(nproc)
RUN make install

# below is a horrible mashup of the main container into this multi-stage build
WORKDIR /usr/root

RUN apk add --upgrade --no-cache "bash"
RUN apk add --upgrade --no-cache "bash-completion"
RUN apk add --upgrade --no-cache "curl"
RUN apk add --upgrade --no-cache "dbus"
RUN apk add --upgrade --no-cache "dbus-dev"
# NOTE: compatibility layer between musl and glibc, because AWS CLI isn't built for musl
RUN apk add --upgrade --no-cache "gcompat"
RUN apk add --upgrade --no-cache "glib"
RUN apk add --upgrade --no-cache "git"
RUN apk add --upgrade --no-cache "groff"
RUN apk add --upgrade --no-cache "jq"
RUN apk add --upgrade --no-cache "jsoncpp"
RUN apk add --upgrade --no-cache "lz4-dev"
RUN apk add --upgrade --no-cache "openrc"
RUN apk add --upgrade --no-cache "tar"
RUN apk add --upgrade --no-cache "unzip"
RUN apk add --upgrade --no-cache "util-linux"
RUN apk add --upgrade --no-cache "yq"

RUN addgroup -S openvpn
RUN adduser -S openvpn -G openvpn

COPY ["./config.ovpn", "./"]

RUN openrc
RUN mkdir -p /run/openrc && touch /run/openrc/softlevel

COPY ["./entrypoint.sh", "./"]
ENTRYPOINT [ "./entrypoint.sh" ]
CMD [ "sh" ]

entrypoint.sh

#!/bin/bash
rc-service dbus start

exec "$@"

config.ovpn

<mine's a secret>

To test:

  1. shove those into a directory
  2. docker [buildx] build [--platform=linux/amd64] -t test .
  • You could use the newer buildx to build, which supports cross-platform builds (not really used for this, but it's part of my standard toolchain)
  • If you want straight-down logging you can use --progress=plain
  1. docker run -it --privileged test sh

@kevin-lindsay-1
Copy link
Author

You asked earlier about my ./configure, here you are:

[43/70] RUN ./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var --enable-addons-aws
       → checking for a BSD-compatible install... /usr/bin/install -c
       → checking whether build environment is sane... yes
       → checking for a thread-safe mkdir -p... ./install-sh -c -d
       → checking for gawk... no
       → checking for mawk... no
       → checking for nawk... no
       → checking for awk... awk
       → checking whether make sets $(MAKE)... yes
       → checking whether make supports nested variables... yes
       → checking how to create a pax tar archive... none
       → checking whether make supports nested variables... (cached) yes
       → checking for g++... g++
       → checking whether the C++ compiler works... yes
       → checking for C++ compiler default output file name... a.out
       → checking for suffix of executables... 
       → checking whether we are cross compiling... no
       → checking for suffix of object files... o
       → checking whether we are using the GNU C++ compiler... yes
       → checking whether g++ accepts -g... yes
       → checking whether make supports the include directive... yes (GNU style)
       → checking dependency style of g++... gcc3
       → checking for gcc... gcc
       → checking whether we are using the GNU C compiler... yes
       → checking whether gcc accepts -g... yes
       → checking for gcc option to accept ISO C89... none needed
       → checking whether gcc understands -c and -o together... yes
       → checking dependency style of gcc... gcc3
       → checking for pkg-config... /usr/bin/pkg-config
       → checking pkg-config is at least version 0.9.0... yes
       → checking how to run the C preprocessor... gcc -E
       → checking for ranlib... ranlib
       → checking whether ln -s works... yes
       → checking for a sed that does not truncate output... /bin/sed
       → checking whether make sets $(MAKE)... (cached) yes
       → checking whether g++ supports C++11 features by default... yes
       → checking whether g++ supports C++14 features by default... yes
       → checking for a Python interpreter with version >= 3.5... python3
       → checking for python3... /usr/bin/python3
       → checking for python3 version... 3.8
       → checking for python3 platform... linux
       → checking for python3 script directory... ${prefix}/lib/python3.8/site-packages
       → checking for python3 extension module directory... ${exec_prefix}/lib/python3.8/site-packages
       → checking for LIBLZ4... yes
       → checking for LIBJSONCPP... yes
       → checking for LIBGLIBGIO... yes
       → checking for LIBGLIBGIOUNIX... yes
       → checking for LIBUUID... yes
       → checking for LIBCAPNG... yes
       → checking for OPENSSL... yes
       → configure: Using ASIO source directory: ./vendor/asio
       → configure: Using OpenVPN 3 Core Library directory: ./openvpn3-core
       → checking OpenVPN 3 Core Library version... ./configure: line 1: ./openvpn3-core/scripts/version: not found
       → 
       → configure: Using ovpn-dco source directory: ./ovpn-dco
       → configure: Checking for SELinux policy development files
       → checking for /usr/share/selinux/devel/Makefile... no
       → checking for /usr/share/selinux/devel... no
       → checking for LIBTINYXML2... yes
       → checking presence of XMLDocument::ErrorName... yes
       → checking presence of XMLDocument::ErrorStr... yes
       → checking for rst2man... no
       → checking for git... git
       → checking if this is a git checkout ... yes
       → checking that generated files are newer than configure... done
       → configure: creating ./config.status
       → config.status: creating Makefile
       → config.status: creating distro/systemd/Makefile
       → config.status: creating doxygen/Makefile
       → config.status: creating doxygen/openvpn3-linux.doxy
       → config.status: creating docs/man/Makefile
       → config.status: creating src/policy/Makefile
       → config.status: creating src/python/Makefile
       → config.status: creating src/selinux/Makefile
       → config.status: creating src/service-autostart/Makefile
       → config.status: creating addons/aws/Makefile
       → config.status: creating config.h
       → config.status: executing depfiles commands

@dsommers
Copy link
Member

Just tested your Dockerfile .... inspecting a crash in openvpn3-service-netcfg now. That service is not able to start

@kevin-lindsay-1
Copy link
Author

lol feels like a herculean effort just to be able to get this crashing that far in

@dsommers
Copy link
Member

Okay, so I'm understanding what happens.

This is related to that the openvpn3-service-netcfg services are not allowed to drop privileges. A debug option can be enabled, which skips the capabilities drop. But that won't be enough, because then the process needs to run as root. And that will require a quite different D-Bus policy, to allow the netcfg to run as root and access various service net.openvpn.v3.* interfaces and methods as root.

I do not have a quick fix for this at hand right now.

In addition to that, I need to understand why openvpn3-service-netcfg SIGABRT in memcpy() when applying the capability changes. This behavior is quite confusing and unclear.

@kevin-lindsay-1
Copy link
Author

kevin-lindsay-1 commented Jun 11, 2021

It felt so close, too!

That's alright, I can fall back on ovpn2 for now, but I'm willing to help on this more.
I don't really really know what logs you were looking at or how you got to them; I snooped around and I wasn't really sure what the easiest way to grab them was.

You have the dockerfile that I have right now, and I'll leave my forked monkeypatches around for cherry-picking; the only thing missing here is that once this build is done, I intend to pull out only the files necessary to actually run. Way too many layers to include in a runtime image.

Not sure about the memcpy() error; I would have to see when it happens, where it happens, the "trace" as it were, and whether or not something weird like a discrepancy between musl & glibc was the cause.

@dsommers
Copy link
Member

I need to get some debug info from the musl libc library to be able to understand the fuller picture. But I'm narrowing down on where it goes really awry (somewhere in drop_root_ng()). But it's quite a perplexing issue. It almost feels like a bug in the musl libc library; but too early to point finger.

@kevin-lindsay-1
Copy link
Author

As for dropping privileges, are you saying that they should drop privileges, or that they shouldn't?

I wonder if the user it's running as is set up correctly; most of my implementation here has been hacks to just see if it's possible, and it builds, so ayy.

@dsommers
Copy link
Member

It fails when dropping all the not needed root privileges. The security model of OpenVPN 3 Linux is to run with as few privileges as possible by default.

@kevin-lindsay-1
Copy link
Author

But it's quite a perplexing issue. It almost feels like a bug in the musl libc library; but too early to point finger.

lol, the finger is probably the qausi-random smattering of dependencies installed (assuming nothing is missing, too), which is on me.

@dsommers
Copy link
Member

Found the first real clue ... in lookup.hpp

 size_t buflen = sysconf(_SC_GETPW_R_SIZE_MAX);

This returns 18446744073709551615 and then this line just makes it explode - understandably

buf = (char *) malloc(buflen);

That's quite a size for a buffer to retrieve getpwnam_r() results.

@dsommers
Copy link
Member

And the unit test does indeed explode as well. Okay, this is a real clue to follow.

@kevin-lindsay-1
Copy link
Author

kevin-lindsay-1 commented Jun 11, 2021

lookup.hpp is one of the ones that I monkeypatched, which either means that something I did was weird, there really is a discrepancy in musl's implementation, or you know, coincidence (pfft ;)).

@dsommers
Copy link
Member

The value 18446744073709551615 as a signed integer is -1. So the sysconf() call returns an error, which was not checked. I haven't checked yet, but I suspect errno is EINVAL - meaning the _SC_GETPW_R_SIZE_MAX value is not available/found.

@dsommers
Copy link
Member

dsommers commented Jun 11, 2021

Can you try to apply this patch and see if that works for you? https://termbin.com/67en

This is a crude hack, to move forward. But if it works, I'll clean it up and do the proper error checking. I could at least start openvpn3-service-netcfg and src/tests/unit/unit-tests passes now.

efc426389ad2:/usr/root/openvpn3-linux# openvpn3-admin version --services
OpenVPN 3 D-Bus services:

  - Client backend starter service
     openvpn3-service-backendstart: git:fix/musl:92b6ca8b3aedee2e+

  - Configuration Service
     openvpn3-service-configmgr:    git:fix/musl:92b6ca8b3aedee2e+

  - Log Service
     openvpn3-service-logger:       git:fix/musl:92b6ca8b3aedee2e+

  - Network Configuration Service
     openvpn3-service-netcfg:       git:fix/musl:92b6ca8b3aedee2e+

  - Session Manager Service
     openvpn3-service-sessionmgr:   git:fix/musl:92b6ca8b3aedee2e+

efc426389ad2:/usr/root/openvpn3-linux# 

@kevin-lindsay-1
Copy link
Author

kevin-lindsay-1 commented Jun 11, 2021

Just saw this, patching my branch. Once I do so, you'll want to clear your docker cache. The mass-murder approach is docker system prune -a, as long as you're not running the image.

@kevin-lindsay-1
Copy link
Author

kevin-lindsay-1 commented Jun 12, 2021

Here is my current download section:

## download
WORKDIR /usr/root
ARG OPENVPN3_VERSION=13_beta
RUN git clone https://github.com/kevin-lindsay-1/openvpn3-linux
WORKDIR /usr/root/openvpn3-linux
# RUN git checkout v${OPENVPN3_VERSION}
RUN git checkout fix/musl
## bootstrap
WORKDIR /usr/root/openvpn3-linux
RUN ./bootstrap.sh
# OpenVPN3-core submodule
RUN cd openvpn3-core && git remote add patched https://github.com/kevin-lindsay-1/openvpn3 && git fetch patched && git checkout fix/musl && cd ..
# ARG OPENVPN3_CORE_VERSION=3.6.1
# RUN git checkout release/${OPENVPN3_CORE_VERSION}
RUN git checkout fix/musl

Judging by your diff, this aligns, correct?

With this download section, and with my particular config.ovpn, I get the same message as above (Failed calling D-Bus LookupConfigName). I don't have a test config on-hand that is a trivial OpenVPN config.

@dsommers
Copy link
Member

That should be right. Btw, the last RUN git checkout fix/musl seems superfluous when I see it now.

I'll rerun my tests on clean container images again.
As a workaround, you should be able to do this:

[term 1] # openvpn3 config-import --config config.ovpn
[term 1] # openvpn3 log --log-level 6 --config config.ovpn
[term 2] # openvpn3 session-start --config config.ovpn

That should at least load the profile before any other operations. You can also verify this with openvpn3 configs-list.

@kevin-lindsay-1
Copy link
Author

Btw, the last RUN git checkout fix/musl seems superfluous when I see it now.

Agreed. Removing and attempting said recommendation.

@kevin-lindsay-1
Copy link
Author

kevin-lindsay-1 commented Jun 12, 2021

Still occurs:

# openvpn3 log --log-level 6 --config config.ovpn
Waiting for session to start ...** ERROR ** Failed calling D-Bus method LookupConfigName: Message recipient disconnected from message bus without replying

# openvpn3 configs-list
Configuration path
Imported                        Last used                 Used
Name                                                      Owner
------------------------------------------------------------------------------
/net/openvpn/v3/configuration/d0a9c7bbxdef0x4de0x8176x5bd854c6f813
Sat Jun 12 01:12:31 2021                                  0
config.ovpn                                               root
------------------------------------------------------------------------------

For the sake of sanity, I just verified that this config works locally. So much for sanity.

@dsommers
Copy link
Member

Okay, can you try to stop all the openvpn3-service-* processes and then run this manually:
/usr/libexec/openvpn3-linux/openvpn3-service-logger --log-level 6 --colour --idle-exit 0 --service

@kevin-lindsay-1
Copy link
Author

# killall /usr/libexec/openvpn3-linux/openvpn3-service-*
DEAD

# /usr/libexec/openvpn3-linux/openvpn3-service-logger --log-level 6 --colour --idle
-exit 0 --service
[INFO] Dropping root group privileges to openvpn
[INFO] Dropping root user privileges to openvpn
OpenVPN 3/Linux git:fix/musl:9dcde01ea41efa1a (openvpn3-service-logger)
OpenVPN core  linux x86_64 64-bit built on Jun 12 2021 01:09:30
Copyright (C) 2012-2020 OpenVPN Inc. All rights reserved.
Idle exit is disabled
 Logger VERB2: Attached: {tag:10879932299807129880}  [:1.12/net.openvpn.v3.sessions]
 Logger VERB2: Attached: {tag:16817071248560997210}  [:1.13/net.openvpn.v3.configuration]
 {tag:16817071248560997210} Config Manager INFO: Parsed single-use configuration 'config.ovpn', owner: root
 Logger VERB2: Attached: {tag:16813641438023107021}  [:1.14/net.openvpn.v3.backends]
 Logger VERB2: Attached: {tag:11756465532326408939}  [:1.15/net.openvpn.v3.backends]
 Logger VERB2: Attached: {tag:17274865932450918438}  [:1.15/net.openvpn.v3.sessions]
 {tag:11756465532326408939} Client VERB1: Initializing VPN client session, token 63465194t35a2t4d68t9571t5e32011aeacd
 {tag:11756465532326408939} Backend Session Process VERB2: Backend client process started as pid 194 daemonized as pid 195
 {tag:11756465532326408939} Backend Session Process DEBUG: BackendClientDBus registered on 'net.openvpn.v3.backends.be195': /net/openvpn/v3/backends/session
 Logger VERB2: Attached: {tag:1095817401319636054}  [:1.16/net.openvpn.v3.sessions]
 Logger VERB2: Detached: {tag:16813641438023107021}  [:1.14/net.openvpn.v3.backends]

@kevin-lindsay-1
Copy link
Author

kevin-lindsay-1 commented Jun 12, 2021

This config isn't in use right now if you care; I can DM this if need be.

It is a standard AWS VPN Client connection, though. The easy-rsa is pretty much the hardest part, and I'm sure you know your way around that particular lib.

@dsommers
Copy link
Member

That didn't give much clues.

One last shot for today. In yet another terminal window, can you run this command as the openvpn user? (you might need to tweak /etc/passwd to provide a shell instead of /sbin/nologin)

  su -c "/usr/libexec/openvpn3-linux/openvpn3-service-backendstart --log-level 6 --idle-exit 0 --client-log-level 6 --client-log-file stdout: --client-colour" openvpn

@dsommers
Copy link
Member

Now I'm getting the same error!

@dsommers
Copy link
Member

It's getting late in my end; brain capacity is about to run out. I'll pick it up again next week.

@kevin-lindsay-1
Copy link
Author

Same

@kevin-lindsay-1
Copy link
Author

I don't do it very often, but an alternative to tmux is docker exec -it <container name> after the docker run <image tag>, which will let you fairly easily connect multiple terminals.

@kevin-lindsay-1
Copy link
Author

@dsommers I ran a monitor via dbus-monitor, which was a little goofy to set up (I had to emulate x11 on mac and then forward that to docker), but I was able to pull these logs.

Notably, I see the following errors:

error time=1623686214.281944 sender=org.freedesktop.DBus -> destination=:1.24 error_name=org.freedesktop.DBus.Error.ServiceUnknown reply_serial=11                                                                                                                                                                             
   string "The name org.freedesktop.DBus was not provided by any .service files"
error time=1623686214.328202 sender=org.freedesktop.DBus -> destination=:1.21 error_name=org.freedesktop.DBus.Error.ServiceUnknown reply_serial=70                                                                                                                                                                             
   string "The name net.openvpn.v3.backends.be239 was not provided by any .service files"

@kevin-lindsay-1
Copy link
Author

kevin-lindsay-1 commented Jun 14, 2021

After doing a little more troubleshooting, I followed your recommendation and ran a config-import, but I noticed that the configuration file wasn't actually created after this command (or at least, the file that I would have expected at /net/... was not created).

So it seems like there's a (possibly intermittent) issue creating the actual configuration files, which then causes "object not found" to occur.

@kevin-lindsay-1
Copy link
Author

While running a dmesg, I also see the following:

[14195.226999] openvpn3-servic[20835]: segfault at 7f8fd8000024 ip 00007f8fd92c348e sp 00007ffdb33d4e20 error 4 in libglib-2.0.so.0.6600.8[7f8fd928e000+64000]
[14195.231047] Code: 8d 15 9c ad 03 00 be 08 00 00 00 48 8d 3d 38 f5 03 00 31 c0 e9 a8 86 ff ff f0 ff 07 c3 48 8d 15 57 ad 03 00 51 48 85 ff 74 0d <8b> 07 85 c0 7f 1e 48 8d 15 50 ad 03 00 48 8d 35 ae ad 03 00 48 8d

dsommers added a commit that referenced this issue Oct 18, 2021
It was discovered that the sysconf(_SC_GETPW_R_SIZE_MAX) call on
Alpine Linux returns 18446744073709551615, which is -1 as a signed
long type.  This will fail in the following malloc() call.

Rework the code a bit to add a failsafe where it will use a hard
coded 16KiB buffer size if sysconf() fails.  This should be more than
enough for most cases.

Reported by: Kevin Lindsay (@kevin-lindsay-1)
URL: #50
Signed-off-by: David Sommerseth <davids@openvpn.net>
@dsommers
Copy link
Member

Just a quick follow-up here. We believe we've fixed the build issue related to musl in the OpenVPN 3 Core library now, with this commit. There are still a few more issues left to sort out, but we're moving slowly forward.

@kevin-lindsay-1
Copy link
Author

Is an alpine build potentially going to be created, if the work is already being done to support it?

@dsommers
Copy link
Member

We are preparing the code to be able to build on Alpine with the musl library, yes. The change I pointed at resolves the issue with the missing byte-swap function. I've just pushed out an update to openvpn3-linux fixing the "GNUism" in the automake file, which you also stumbled across (commit e7218bb).

We will probably not provide an Alpine build directly, but we want to ensure the community has all it needs to be able to build on that platform. There are still a few corner cases to iron out before it builds straight from the git sources. We are also preparing the ground for OpenSSL 3.0 builds too; I hope most of this is out during this week.

With all these issues resolved, I'll dive into the segfault we've seen (I've reproduced it recently) when running OpenVPN 3 Linux inside an Alpine docker image.

@dsommers
Copy link
Member

I am now capable of doing a complete build (compilation) of OpenVPN 3 Linux binaries on Alpine as of commit 44b2970. The OpenVPN 3 Core library has also been updated, resolving the bswap issue with musl.

I consider this being the goal for this issue. Being able to run OpenVPN 3 Linux inside a docker container will be a separate issue (and this curent issue is already far too long).

Please confirm if you are able to build the latest git master on Alpine as well, then we can close this issue.

@dsommers dsommers added distribution-support Support for new distributions or distribution versions fixed Issue is claimed to be fixed, but should be tested before closing it need testing Need more testing to see if issue us still present labels Nov 18, 2021
@kevin-lindsay-1
Copy link
Author

kevin-lindsay-1 commented Nov 20, 2021

Ok, will do, I haven't looked at this in a while, but I'll try again on all-official release branches.

Perhaps I'll make some kind of automation that watches the commits and publishes an alpine release. If I sat down and built it, would OVPN support it as an official(ish) build and adopt/promote it in some way? Don't want to go through the trouble of making it apk-able and have nobody use it because it's not "official".

@dsommers
Copy link
Member

Thanks for giving it a test, @kevin-lindsay-1 !

We can definitely promote your apk work, as long as we know there is some commitment behind it. And if you are willing to do the efforts getting it into Alpine as an official apk, that would be really great as well. We certainly will support your efforts and can update the community wiki pages to include instructions installing it on Alpine as well. If this ends up as an official apk package in Alpine, we can also add this to the announcement mails as well - with some coordinated efforts when we do new releases.

And we will certainly help out as best we can in regards to fixing issues in OpenVPN 3 Linux appearing on Alpine.

@dsommers
Copy link
Member

v17_beta has been released now, including the build fixes mentioned here.

@kevin-lindsay-1
Copy link
Author

Ok cool, I am going to look at the apk support for this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
distribution-support Support for new distributions or distribution versions fixed Issue is claimed to be fixed, but should be tested before closing it need testing Need more testing to see if issue us still present
Projects
None yet
Development

No branches or pull requests

2 participants