Support for user services

[mobinmob]

66 supports user services natively. This is an issue to track the implementation of them in the project. The 66 package supports user services and uses the default directories for them (~/.66). The first step to enable them is to create a scandir with proper configuration. obarun provides an excellent module for doing exactly that - scandir-66serv. The following template will create a suitable package for voidlinux:

# Template file for 'scandir-66serv'
pkgname=scandir-66serv
version=0.2.0
revision=1
wrksrc="${pkgname}-v${version}"
build_style=configure
depends="66 66-tools"
short_desc="66 module that enables user services"
maintainer="mobinmob <mobinmob@disroot.org>"
license="ISC"
homepage="https://framagit.org/pkg/obmods/scandir-66serv"
distfiles="https://framagit.org/pkg/obmods/scandir-66serv/-/archive/v${version}/scandir-66serv-v${version}.tar.bz2"
checksum=a751037001b52e35d6a1d591b2491cf4875eb3a48ccb33fa9263ed08b8f9c48b

post_install() {
    vlicense LICENSE
}

Το enable and start the scandir service for a user after installing the package: sudo 66-enable -t tree -S scandir@user Replace tree with the name of the tree you want the service enabled in and user with the account user.

[mobinmob]

The first experimental batch of user service frontends is now on a PR. In order to distinguish them from system services that run the same daemon with @runas they have the suffix _us for user service. They only run on a user scandir.

[gspe]

What do you think if they have _user suffix instead of _us? _us makes me think of United States, such a localization. _user is more obvious

[mobinmob]

I have no problem with changing it :) Ι just want something that will distinguish service files that will run only as user services by their name.

[fungilife]

I believe that tor-66serv should be strictly a user service, it shouldn't run as root, so change (root tor ) to (tor), but then you need a scandir for tor. Tor should not be in wheel or sudo groups either.

On the other hand this is not a daemon that should be forgotten and be left running in the background at all times. So an entire routine is needed where a hook triggers the scandir to be generated, started, then the service, then exits and the tree is brought down as well.

[mobinmob]

@fungilife What you descibe is the reason this issue is still open and my (and @gspe https://github.com/mobinmob/void-66-services/pull/35 ) user services are not yet merged. Before the release of utlogd it was not exactly easy to create such a scheme. I will do the necessary work to -at last...- have a decent way to accomplish that with utlogd.

However, as far as the tor service is concerned it cannot be just a user service - for the same reason transmission and other daemons have both user services (in a PR https://github.com/mobinmob/void-66-services/pull/20 ) and services that run as root. I am primarily creating the frontend service files for voidlinux and try to make them portable. Since there are runit services for them in voidlinux, the way to go is have both "system-wide" services and user services.

[fungilife]

@mobinmob the way to go is have both "system-wide" services and user services

I understand and fully agree, the reason I brought it to your attention is that torproject specifically (and the executable alerts at this) suggests not to run tor as root. Running it as a specific unprivileged user as "tor" is further enhancing the security of running it. Personally I disagree that this specific daemon needs supervision as it should be a short term running service, a temporary single use proxy. Runit or s6 the same applies.

[mobinmob]

@mobinmob the way to go is have both "system-wide" services and user services

I understand and fully agree, the reason I brought it to your attention is that torproject specifically (and the executable alerts at this) suggests not to run tor as root. Running it as a specific unprivileged user as "tor" is further enhancing the security of running it.

That is exactly what happens with the current voidlinux setup, with either the runit service or the current 66 service. Enable the service and see the output of ps aux | grep tor. The service is not running as root, but as the tor user.

Personally I disagree that this specific daemon needs supervision as it should be a short term running service, a temporary single use proxy. Runit or s6 the same applies.

Needs is a loaded term in this case. You can use it w/o supervision from the terminal for sure, but you lose everything process supervision offers, becides restarting on failure/crash. Propper logging, starting in a predictable/clean environment etc.

[Obarun]

What do you think if they have _user suffix instead of _us? _us makes me think of United States, such a localization. _user is more obvious

What about installing the user services at e.g. /usr/share/66/service/user directory instead of prefixing the service name itself? Personally i will apply this policy on Obarun.

[mobinmob]

What do you think if they have _user suffix instead of _us? _us makes me think of United States, such a localization. _user is more obvious

What about installing the user services at e.g. /usr/share/66/service/user directory instead of prefixing the service name itself? Personally i will apply this policy on Obarun.

The problem with having them in a different directory is that cannot distinguish what the service does by the name alone - one must check the contents.I have not yet separated the services into directories and I already have services with the _ns suffix, for services that use 66-ns and one day I may have more ("socket-activated" etc). That means there is a service and a service_ns frontend and maybe a service_user frontend for the same daemon.

For the user service frontends my goal is to be instantly recognizable and easy to copy to the user dir.