Closed Lunaphied closed 3 years ago
The suggested useradd
command creates a regular user with the home directory as /home/seance
; it might be better to change it to something like useradd --home-dir=/srv/seance
, and if you're going to explicitly put running as a special user in the service file, then it should probably also mention that if Séance is installed with pip3 install --user
, that that command will need to be run as the Unix user running Séance.
We suggest using no home directory since it's not actually required and installing globally.
If that approach sounds okay we'll rework the readme in the PR.
Installing globally on Linux tends to lead to some messiness, since it can interfere with the system package manager. On the other hand, it's the preferred approach on macOS. That's why I had plain pip3 install
in the readme — with recent versions of pip, it'll suggest --user
if you run it without sudo
.
You could have it be agnostic in the readme, something like:
Such a user can be created usually with
sudo useradd seance
, possibly with something like--home-dir=/srv/seance
if you want to install Séance withpip3 install --user
.
Installing globally on Linux tends to lead to some messiness, since it can interfere with the system package manager.
Was afraid you would say this. It's a fair point. I forgot how pip handles global installs (not well), and think you're probably right. It seems a bit silly to have a homedir just so a user install works, but it's the easiest answer here outside of system packaging for Séance.
How does this change sound to you:
Such a user can be created with
sudo useradd seance
. To avoid installing Séance globally, which might be ill-advised, you can create a home directory for the user, something likesudo useradd --create-home --home-dir /srv/seance seance
will create a home directory for the user in/srv/seance
. To install seance and sdnotify for this user usesudo -u seance pip3 install --user sdnotify git+https://github.com/Qyriad/Seance
.
This guides someone through the whole process, especially the last bit which can be confusing for a user which isn't setup with login by virtue of having no password set.
That works~
Alas, if only global pip installs installed to /usr/local
by default; then we wouldn't have any of these problems in the first place.
Alas, if only global pip installs installed to
/usr/local
by default; then we wouldn't have any of these problems in the first place.
Yes indeed. I'll make the changes.
Now the default configuration for environment and arguments matches what the bot expects when running under systemd.
Additionally there's now a suggestion (and assumption in the service) that you run it under an unprivileged "seance" user, which is a general best practice. (More tweaks in the future to further lock down the service are probably worth considering since it needs only network access at the moment).