Introduce support for Synology NAS

ekrekeler commented 3 years ago

Feature Request

At this time, the binaries compiled for the ARMv7 platform are incompatible with DiskStation on Synology NAS (currently DSM 6.2.3-25426 Update 2). Running the teleport command fails with error: teleport: /lib/libc.so.6: version 'GLIBC_2.28' not found (required by teleport)

Motivation

Using a jump server such as Teleport would be beneficial for enabling CLI access without port forwarding or configuring a VPN. Since the DiskStation GUI doesn't include a terminal, the only way to access the CLI is to enable SSH or Telnet server.

Who's it for?

Synology customers, power users

klizhentas commented 3 years ago

@russjones @webvictim any ideas on why it may fail like this?

webvictim commented 3 years ago

@klizhentas It fails for the same reason that caused us to create separate CentOS 6 binaries - the glibc version on the Synology boxes seems to be lower than we require.

@ekrekeler If your Synology were Intel-based, you could likely run https://get.gravitational.com/teleport-v4.4.4-linux-amd64-centos6-bin.tar.gz on it; I know Synology’s OS is Debian-based, but there’s actually nothing about these binaries specific to RHEL or CentOS - they’re just compiled against a lower version of glibc (albeit in a CentOS build environment)

I need to investigate Dockerized builds on the ARM platform soon anyway, so I’ll look into whether we can do a similar thing to build against a lower glibc version for ARM platforms.

ekrekeler commented 3 years ago

Yes some of the more expensive Synology models have Intel-based processors, but most of the SOHO customers like me use the ARM-based models.

@webvictim Thanks for looking into it, and let me know if you'd like me to test anything. I also have an RPi4 which I can use to test armv7 and arm64 containers.

webvictim commented 3 years ago

Statically-compiled binaries would fix this (#4896) but are untested and have historically introduced a number of other issues with unpredictable DNS resolution when running in Docker/Kubernetes.

One workaround for this which would prevent huge fragmentation of our build matrix while also not needing us to switch to statically-compiled binaries may be to just change the Teleport buildbox to always bootstrap and build Go from source in a container which uses an older glibc version; we do this already for CentOS 6 binaries. We could use CentOS 7 which would give us glibc 2.18.

Here's the list of required glibc versions that I know of so far (run ldd --version to see the required glibc version for a given distro):

Distro	glibc version
CentOS 6	2.12
CentOS 7	2.18
CentOS 8	2.28
Ubuntu 18.04	2.27
Ubuntu 18.10	2.28
Ubuntu 20.04	2.31
Ubuntu 20.10	2.32
Fedora 32	2.31
Synology DSM 6.2.3	2.20
Amazon Linux 2	2.26
NVIDIA Jetson AGX	2.27

webvictim commented 3 years ago

As an update for anyone following the issue, we're unlikely to be changing our Teleport build box to use a lower version of glibc any time soon. The reason is because downgrading the build box to an old enough distro to satisfy all the glibc requirements above will result in breaking changes to Teleport's enhanced session recording functionality. Downgrading glibc too far is also undesirable from a security perspective as older versions contain unpatched vulnerabilities.

If you're experiencing an error like teleport: /lib/libc.so.6: version 'GLIBC_2.28' not found (required by teleport) when trying to run Teleport, you could always look at compiling the open source version of Teleport yourself from source. You'll need Go 1.15 installed and available in your PATH, as well as gcc, make and zip.

git clone https://github.com/gravitational/teleport
cd teleport
git checkout v5.1.2 # update this to whatever version you'd like to compile
make release

Other notes:

any binaries compiled in this way won't have support for PAM or BPF, unless you also install those headers
binaries compiled in this way can't be used to run an Enterprise version of the Teleport auth server to use RBAC/SAML/OIDC functionality as they compile the OSS version
- you can connect OSS Teleport nodes to an Enterprise auth server with no problems, however.

yostinso commented 2 years ago

This is mostly a comment for anyone else coming across this issue, but I actually built a Synology package for x64 / DSM7 devices and those interested can probably figure out how to get a packaged built for ARM with a little effort:

https://github.com/yostinso/spksrc-teleport/releases/tag/teleport-v8.0.7

Gugatec commented 11 months ago

This is mostly a comment for anyone else coming across this issue, but I actually built a Synology package for x64 / DSM7 devices and those interested can probably figure out how to get a packaged built for ARM with a little effort:

https://github.com/yostinso/spksrc-teleport/releases/tag/teleport-v8.0.7

I tried on my DSM 7.1.1 ... compiled the actual arch, I was not able to make it work. Also tried the latest precompiled package, 13.1.1 spk. It didn't worked either for me. Mind that I'm following the step to make elevate its privilege, generating a tctl nodes add and using the token and ca-pin.

Any hints @yostinso ?

Cheers

yostinso commented 11 months ago

@Gugatec probably want to continue this over here: https://github.com/yostinso/spksrc-teleport/issues/2

Assuming it's installing, you probably want to check with ps while connected some other way to see if the teleport binary is actually running. You might also consider a restart if you haven't restarted since installing it.

webvictim commented 2 months ago

We have in fact downgraded the glibc version in the buildbox since this issue was created, so I'd be curious to know whether this is still an issue when running v15 Teleport binaries on ARM-based Synologies. I should be able to test it myself in a couple of weeks if nobody else can.

gravitational / teleport