[SOLVED] Rocket.Chat https support - SELinux issues, libraries inside snap not linked correctly?

Hello everyone,

have the following problem here, already posted it in the RocketChat support channels and got directed here.

So I’m trying to set up RocketChat with the official snap on an Odroid N2 with aarch64/arm64, Ubuntu MATE 18.04. That did work so far, but I’m getting a suspicious error about SELinux, see below.

The problem I’m facing is that when trying to set up https like in the official guide, it fails at the following step:

$ sudo snap set rocketchat-server https=enable
error: cannot perform the following tasks:
- Run configure hook of "rocketchat-server" snap (run hook "configure": 
-----
cmd_run.go:884: WARNING: cannot create user data directory: failed to verify SELinux context of /root/snap: exec: "matchpathcon": executable file not found in $PATH
dig: error while loading shared libraries: libdns.so.162: cannot open shared object file: No such file or directory
Error: Can't resove DNS query for <server DNS name>, check your DNS configuration, disabling https ...
-----)

That looks like dig in /snap/rocketchat-server/1376/usr/bin/dig can’t find the libdns.so.162 in /snap/rocketchat-server/1376/usr/lib/aarch64-linux-gnu/libdns.so.162 (and likely none of the other libraries too):

$ ldd /snap/rocketchat-server/1376/usr/bin/dig
 shell-init: error retrieving current directory: getcwd: cannot access parent directories: No such file or directory
	linux-vdso.so.1 (0x0000007f83ecf000)
	libdns.so.162 => not found
	liblwres.so.141 => not found
	libbind9.so.140 => not found
	libisccfg.so.140 => not found
	libisc.so.160 => not found
	libpthread.so.0 => /lib/aarch64-linux-gnu/libpthread.so.0 (0x0000007f83e32000)
	libc.so.6 => /lib/aarch64-linux-gnu/libc.so.6 (0x0000007f83cd9000)
	/lib/ld-linux-aarch64.so.1 (0x0000007f83ea4000)

What could be the problem here? Is this all caused by the SELinux environment being broken, or are they separate errors? I’ll be happy to add further details.

Aaron Ogle from the RocketChat team could fill in any details about the snap itself if needed, he told me.

Thanks in advance for any help.

I suspect it might be the same problem as described here Selinux warning when running lxc.

Can you run mount|grep selinux and post the output?

That’s interesting, thanks.

$ mount | grep selinux
selinuxfs on /sys/fs/selinux type selinuxfs (rw,relatime)

It’s a relatime FS! :grinning:

Edit:

Kernel is

$ uname -a
Linux odroid 4.9.182-31 #1 SMP PREEMPT Tue Jun 18 14:45:56 -03 2019 aarch64 aarch64 aarch64 GNU/Linux

Should I try your workaround @mborzecki as posted in the other topic?

As a workaround, install selinux-policy-default, and set SELINUX=disabled in /etc/selinux/config, like so:

# Preformatted textThis file controls the state of SELinux on the system. # SELINUX= can take one of these three values: # enforcing - SELinux security policy is enforced. # permissive - SELinux prints warnings instead of enforcing. # disabled - No SELinux policy is loaded. SELINUX=disabled …

Then reboot the system.

Edit 2: So, tried the workaround and could get around the SELinux issues, the second error message about dig however remains. Thanks so far.

So I think first of all you won’t be able to do this from the outside. You will need to execute this from inside of the snap environment.

snap run --shell rocketchat-server I think is how you hop into a shell inside the snap.

I think you’ll likely have to execute:

export PATH="$SNAP/usr/sbin:$SNAP/usr/bin:$SNAP/sbin:$SNAP/bin:$PATH"
export LD_LIBRARY_PATH="$LD_LIBRARY_PATH:$SNAP/lib:$SNAP/usr/lib:$SNAP/lib/x86_64-linux-gnu:$SNAP/usr/lib/x86_64-linux-gnu"
export LD_LIBRARY_PATH=$SNAP_LIBRARY_PATH:$LD_LIBRARY_PATH

Then if you hop into /snap/rocketchat-server/current you could give that a go.

When I run: ldd /snap/rocketchat-server/current/usr/bin/dig it seems to find everything in the core snap.

Any idea where the kernel comes from?

Can you post the output of snap debug sandbox-features ?

Thanks for your answers.
So I did what you said, switched to a shell inside the snap, ran set the env variables like you mentioned, but it still didn’t work, same error. ldd also showed the same results (libraries missing). What could be wrong with my snap (installation)?

The kernel is from the Ubuntu Mate 18.04 image by Hardkernel. Actually, I probably updated it via apt in the meantime.

$ snap debug sandbox-features
confinement-options:  classic devmode
dbus:                 mediated-bus-access
kmod:                 mediated-modprobe
mount:                freezer-cgroup-v1 layouts mount-namespace per-snap-persistency per-snap-profiles per-snap-updates per-snap-user-profiles stale-base-invalidation
seccomp:              bpf-argument-filtering
udev:                 device-cgroup-v1 tagging

I’ve now found a workaround for the SSL issue. Running Apache web server and configured it as reverse proxy as described in the docs: https://rocket.chat/docs/installation/manual-installation/running-in-a-sub-folder/

Apache takes care of SSL/HTTPS encryption so it’s not Rocketchats business anymore.

This workaround is until the arm64 snap builds are fixed, as far as I can see this is already being worked on.

Thanks for your effort anyway.

… this is what you get wen people do not actually work with the ubuntu teams to build an image with their own homebrewed kernels :slight_smile: (i’m pretty sure calling it Ubuntu breaks our trademark policy) …

have you tried adding “selinux=0 apparmor=1” to your kernel commandline ? that should switch you to the ubuntu-supported LSM (indeed, only if the kernel config doesnt have apparmor disabled completely)…

The SELinux error isn’t related to the dig error. I get where you’re coming from, but in this case it actually seems to be the fault of the snap build of Rocketchat for aarch64 (and perhaps armhf) which is missing the correctly linked dig, not the fault of the custom-brewed Ubuntu™ image. :slightly_smiling_face:

1 Like

Just for the record, I found that the error concerning matchpathcon is resolved by adding /usr/sbin (or whereever “which matchpathcon” says it lives) to $PATH before invoking the snap. No need to disable SELinux.