Static files not embeded

[alerque]

Having downloaded the v0.9.0-beta generic linux build and trying to run, I'm faced with this message:

$ sudo -u listmonk listmonk --config /etc/listmonk/config.toml --install
2021/05/05 12:46:31 main.go:84: v0.9.0-beta (e90fb1d 2021-02-13T12:41:40Z)
2021/05/05 12:46:31 init.go:98: reading config: /etc/listmonk/config.toml
2021/05/05 12:46:31 init.go:175: connecting to db: localhost:5432/listmonk
021/05/05 12:46:31 init.go:122: unable to initialize embedded filesystem: no ID found in the file
2021/05/05 12:46:31 init.go:123: using local filesystem for static assets
2021/05/05 12:46:31 init.go:143: failed to initialize local file for assets: stat config.toml.sample: no such file or directory

I read #20 which seems to be the same issue it repeatedly suggests this is a problem with "old versions, try the new one". However it looks like something new has not gotten embeded properly.

[knadh]

$ ./listmonk --config=/tmp/config.toml --install
2021/05/05 16:37:33 main.go:84: v0.9.0-beta (e90fb1d 2021-02-13T12:41:40Z)
2021/05/05 16:37:33 init.go:98: reading config: /tmp/config.toml
2021/05/05 16:37:33 init.go:175: connecting to db: localhost:9432/listmonk

** first time installation **
** IMPORTANT: This will wipe existing listmonk tables and types in the DB 'listmonk' **
continue (y/n)?  y
2021/05/05 16:37:34 install.go:134: Setup complete
2021/05/05 16:37:34 install.go:135: Run the program and access the dashboard at 0.0.0.0:9000

https://github.com/knadh/listmonk/releases/download/v0.9.0-beta/listmonk_0.9.0-beta_linux_amd64.tar.gz

^ The binary is fine. I suspect this could have something to do with -u listmonk where the app doesn't have permissions to read itself. Did you put the binary in a path that requires root access?

[alerque]

I put the binary in /usr/bin/listmonk, owned by root with permissions 755. The system has a listmonk user (and group) and that user is allowed to execute (and read) the binary. It also successfully reads the config file from etc. and successfully connects to the database.

I can't think what more permissions it should have, 755 for a static binary should be correct.

[knadh]

What OS are you running this on? The binary definitely has static files embedded, does work cross-platform, and is in production in many environments. This must have something to do with permissions somehow (or SELinux, if you've that running?).

This is the binary downloaded from the releases page.

$ stuffbin -a id -in ./listmonk
./listmonk: stuffbin (11004.00 KB binary, 495.01 KB stuff)

34 files totalling 1939.51 KB
9.44 KB                  /schema.sql
23.99 KB                 /frontend/css/main.fd985d68.css
0.00 KB                  /public/static/script.js
295.15 KB                /frontend/css/app.55b6435b.css
10.31 KB                 /frontend/img/logo.b296cf65.svg
30.94 KB                 /frontend/js/app.9d71a056.js
26.17 KB                 /i18n/en.json
29.29 KB                 /i18n/fr.json
4.21 KB                  /public/static/style.css
...

[alerque]

I'm using Arch Linux, and specifically setting up packaging for the distribution. There are three flavors of packaging, all of which I'm getting configured:

• listmonk is a recipe for the last release tag, specifically built from sources
• listmonk-git builds and installs the latest Git HEAD
• listmonk-bin is also the last release tag, but downloads the binary from the release page

All of the builds add config file backups, a systemd service, creation of a non privileged user, etc. The builds for the first two make no attempt to embed static files at all and place them in a known system location. The third of course should have them built in.

This issue is specifically about listmonk-bin using the upstream built binary.

SELinux is not involved at all.

[alerque]

Given the discussion on #340 I finally figured out what the difference is here.

The distribution packaging system by default runs strip on all binaries as it packs them into the final package. I have explicitly disabled binary stripping for the listmonk-bin package to avoid this problem.

Normally when this fails for any reason the binary just won't run at all (e.g. electron based anything) so it wasn't something that even crossed my mind when it seemed to be working fine except for what felt like a permissions problem. Especially confusing because --version was still showing the exact version and build timestamp seen in your tests.

Thanks for your time trying to figure it out.

[knadh]

The packaging system by default runs strip on all binaries.

Whew, that explains it :)