Arch Linux User Repository

Actually, you might as well use this as it just got merged: https://codeberg.org/grunfink/snac2/src/branch/master/examples/snac-admin

Hey there, recently I've been struggling with administrating my snac instance correctly. This is because any sudo -u snac -- snac state /var/lib/snac fails because of the DynamicUser=yes restriction. I found a solution which is about calling nsenter:

nsenter -ae -S follow -G follow -t (pidof snac) -- snac state /var/lib/snac

Since the systemd unit provided by this PKGBUILD comes with this restriction, I suggest adding a script for users to easily work around this issue:

snac-admin.sh
-------------
#!/usr/bin/env sh

nsenter -ae -S follow -G follow -t $(pidof snac) -- snac $@

@Popolon done! As the translation file(s) have to be copied to the directory once initialized I have put them in /usr/share/doc/snac/po.

Hi, could you add the translations (po/ dir) in /usr/share/snac/ or maybe /usr/share/doc/snac/ please, so they can be installed on instances from this directory ?

@m040601 I have added the RELEASE_NOTES.md, the TODO.md and the doc/tp files that were missing in the package. The rest of the files although interesting are not relevant in Arch Linux as they are about how to install the application with Docker, with Alpine Linux or manually.

The PKGBUILD version has not changed because I don't see the need for people to rebuild for this reason. As soon as the next version is released, these files will be included in the corresponding builds.

@ogarcia

Thank you for the work in this PKGBUILD. Very usefull. And the nice helpfull messages in snac.install. Keep it going.

I always wanted to test this "your own instance" thing. But dont want the complexity of the mastodon installation. This snace "c" thing looks promising.

I imagined I would be spending hours to start this, ... ... but I got it running in a couple of minutes. Still lotz of testing to do ....

$ pacman -Ql snac

snac /usr/bin/snac
snac /usr/lib/systemd/system/snac.service
snac /usr/lib/systemd/user/snac.service
snac /usr/share/licenses/snac/LICENSE
snac /usr/share/man/man1/snac.1.gz
snac /usr/share/man/man5/snac.5.gz
snac /usr/share/man/man8/snac.8.gz

$ wget https://codeberg.org/grunfink/snac2/archive/2.72.tar.gz

$ tar tf 2.72.tar.gz

snac2/
.......
snac2/README.md
snac2/RELEASE_NOTES.md
snac2/TODO.md
...
snac2/artwork/
......
snac2/doc/
snac2/doc/tp/tp-01-account-migration-from-snac-to-mastodon.md
snac2/doc/tp/tp-02-account-migration-from-mastodon-to-snac.md
.......
snac2/examples/docker-entrypoint.sh
snac2/examples/formatting.txt
snac2/examples/nginx-alpine-ssl/
snac2/examples/nginx-alpine-ssl/Dockerfile
snac2/examples/nginx-alpine-ssl/default.conf
snac2/examples/nginx-alpine-ssl/dhparam.pem
snac2/examples/nginx-alpine-ssl/entrypoint.sh
snac2/examples/nginx-alpine-ssl/nginx-selfsigned.crt
snac2/examples/nginx-alpine-ssl/nginx-selfsigned.key
...
snac2/examples/static-linking-with-musl.md
... 

There is still stuff there that might not be referenced in the man pages. Example files etc. That RELEASE_NOTES/Changelog is also usefull to keep up with a fast moving thing like this. Please dont save microbytes. Put them in

/usr/share/doc/snac/RELEASE_NOTES.md
/usr/share/doc/snac/README.md
...
/usr/share/doc/snac/... this that ...
/usr/share/doc/snac/example/ this ... that

Thanks in advance.

OK

Personally I don't want to change the build options because of the Arch Linux philosophy that says that the package should always be as faithful to the upstream as possible.

If the author of snac considers it best to compile by default with -DWITH_LINUX_SANDBOX then he will include this option in the makefile and this package will have that option (which I understand that right now it does not because, I quote specifically from the README: It's still a bit experimental).

@shtrophic Communication is hard, and I failed.

I copied the “v2.68+ and Linux kernels older than 5.13.0” from the README just to show that my suggestion would be valid here (since we had snac v2.68 and kernels older than 5.13.0). I should have taken the path of Python Zen: explicit is better than implicit. Mea culpa.

When I suggested that the -DWITH_LINUX_SANDBOX definition be added to $CFLAGS in the PKGBUILD, it was because the $CFLAGS is taken from /etc/makepkg.conf and not from the environment, and I feel it is wrong to add a package-specific option to the general compiler flags. I rarely install packages separately, and when I call yay it will upgrade ArchLinux proper and AUR packages in the same session, and so the -DWITH_LINUX_SANDBOX would be given to every AUR build. Imagine if we added specific options for all AUR packages to the global makepkg.conf, that would hardly end well.

Summary: We have alle the versions necessary for letting snac use Linux sandboxing, and it will hardly harm anyone to build snac with -DWITH_LINUX_SANDBOX as people can turn off sandboxing in the configuration file if they don't like it. The other situation, that sandboxing isn't compiled into the binary, makes sandboxing unavailable for everyone — whether they like it or not.

Arguing always makes me very tired, and I recognize the package maintainer's right to author the PKGBUILD file as they see fit, so rather than having a lengthy discussion here I preferred to just use my own local PKGBUILD file.

Cheers.

@kseistrup, @ogarcia

I think you misunderstand. A linux kernel >= 5.13.0 is required to have sandboxing. linux as well as linux-lts in the repos support this. Only kernels older than 5.13.0 cannot be compiled with landlock sandboxing. So it should be OK to add this flag.