Re: [DNG] [RFC] User services

2019-05-13 Thread Steve Litt
On Sat, 11 May 2019 17:22:45 +0100
s@po  wrote:


> In the past Debian Wheezy had a tool for that, called 'chkconfig', it
> was a lot used in the Datacenter.. # Adding a Service 'atsd':
>   chkconfig --add atsd;

ln -s /etc/sv/daemonname /var/service/daemonname

> # Enable the service in several Runlevels:
>   chkconfig --level 12345 atss on;
Run levels are fairly foreign everywhere but sysvinit.
Probably doable with runit.


> # Start the Service:
>   /etc/init.d/atsd start;
sv start daemonname

> # Stop the Service:
>   /etc/init.d/atsd stop;
sv stop daemonname

> # Disable the service in requested runlevels:
>   chkconfig --level 12345 atsd off;
Runlevels why?


> # Remove the Service:
>   chkconfig --del atsd;
rm /var/service/daemonname

SteveT
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng


Re: [DNG] [RFC] User services

2019-05-13 Thread lpb+devuan


On 5/11/19 4:40 AM, Martin Steigerwald wrote:
> Martin Steigerwald - 11.05.19, 11:26:
>> Hi.
>>
>> Now that the proof of concept is out, I am thinking about extending it
>> a little bit.
>>
>> - make is a package
>> - make "install-or-update.sh" into "/usr/bin/userservices" with the
>> following actions:
>>   - install: Sets up userservices for the user
>>   - update: Updates it
>>   - remove: Removes i
> 
> - remove: Removes user services from user directory completely (after 
> confirmation)
> 
Martin, et al.,

I think it was Steve who brought up the idea that there are different
places to enable user services, and I'd like to posit there are at least
two different kinds of user services:

* per-user (for all sessions)
* per-session

On my machine I use runit to start a per-user tor and per-use privoxy;
all my sessions share those services. On a per-session basis I see
things like pulseaudio (if you use it), ssh-agent, gpg-agent, screen
locker, and other services that you would shut down when a session closes.

You can start the per-user services either in /etc/services (with runit
strting runsvdir) or as a lazy-instantiation per user on first login.
These serives would persist and be shared across user sessions.

You can start per-session services in .xsession or .xinitrc, or .bashrc
and .bash_logout.

So I would recommend thinking about having two sets of services,
per-user and per-session, and perhaps having "uservice --user" and
"uservice --session" to manage each different kind.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng


Re: [DNG] [RFC] User services

2019-05-13 Thread Martin Steigerwald
Didier Kryn - 13.05.19, 11:49:
> Le 13/05/2019 à 10:47, Martin Steigerwald a écrit :
> > s@po, tux...@sapo.pt - 11.05.19, 18:22:
> >> Hello All,
> >> 
> >> On Sat, 11 May 2019 11:26:12 +0200
> >> 
> >> Martin Steigerwald  wrote:
> >>> Hi.
> >>> 
> >>> Now that the proof of concept is out, I am thinking about
> >>> extending
> >>> it a little bit.
> > 
> > […]
> > 
> >>> What do you think about that?
> > 
> > […]
> > 
> >> In the past Debian Wheezy had a tool for that, called 'chkconfig',
> >> it
> >> was a lot used in the Datacenter..
> >> 
> >> # Adding a Service 'atsd':
> >>chkconfig --add atsd;
> >> 
> >> # Enable the service in several Runlevels:
> >>chkconfig --level 12345 atss on;
> > 
> > AFAIK that is a tool coming from RHEL/CentOS/Fedora that was dropped
> > from Debian for some reason. It only works with system-wide services
> > as far as I am aware of.
> > 
> >> And other funcionalities, like listing the services and so on..
> >> It was a very helpfull tool.
> >> 
> >> In the absence of it( I don't know why it was removed .. ), your
> >> tool
> >> seems to come to replace it, BUT for users only? :)
> > 
> > I do not know why it was removed.
> > 
> > And yes, my approach is just for user services. I already thought
> > about making it a generic frontend for runit/s6, in order to also
> > allow it to handle system services, in order to allow
> > starting/stopping teamviewer services. But on one hand we have the
> > init system with its tools for that already and on the other how to
> > handle permissions would be something to be really clear about.
> > 
> > Also I'd rather get rid of teamviewer than to provide support for
> > it. I use it very rarely for support cases from customer of my
> > employee.> 
> >> I think it would be nice to call it like 'uservice', instead of
> >> 'u[ser]service[s]', which is a lot bigger name, or a alias called
> >> 'uservice', since 'service' is also another tool, to deal with..
> >> services.
> > 
> > I bet I'd make that a symlink or so, so the tool could work as
> > either
> > 'uservice' or 'userservice'.  'uservice' also has 'user' and
> > 'service' in it. I also thought about just 'us' but Z-Shell would
> > like to correct that to 'su' and… those really short command names
> > are better reserved for commands that the likely user calls often,
> > such as 'cp', 'mv' and so on.
> > 
> > Ciao,
> 
>  Why not call it Userd ? It can compare with Systemd. It's made
> for the user, and user-friendly, and it does one thing, the thing it
> claims to do.

Nice idea.

But it is no daemon.

It uses a (kind of) daemon, runit as in 'runsvdir' or in the future 
probably alternatively s6, but itself it is none.

It is just a script + alias (for now) that makes using runit for user 
services easy for users.

But yeah, I think I like to keep it in a way that it does one thing 
well, flexibly and efficiently.

-- 
Martin


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng


Re: [DNG] [RFC] User services

2019-05-13 Thread Didier Kryn

Le 13/05/2019 à 10:47, Martin Steigerwald a écrit :

s@po, tux...@sapo.pt - 11.05.19, 18:22:

Hello All,

On Sat, 11 May 2019 11:26:12 +0200

Martin Steigerwald  wrote:

Hi.

Now that the proof of concept is out, I am thinking about extending
it a little bit.

[…]

What do you think about that?

[…]

In the past Debian Wheezy had a tool for that, called 'chkconfig', it
was a lot used in the Datacenter..
# Adding a Service 'atsd':
chkconfig --add atsd;
# Enable the service in several Runlevels:
chkconfig --level 12345 atss on;

AFAIK that is a tool coming from RHEL/CentOS/Fedora that was dropped
from Debian for some reason. It only works with system-wide services as
far as I am aware of.


And other funcionalities, like listing the services and so on..
It was a very helpfull tool.

In the absence of it( I don't know why it was removed .. ), your tool
seems to come to replace it, BUT for users only? :)

I do not know why it was removed.

And yes, my approach is just for user services. I already thought about
making it a generic frontend for runit/s6, in order to also allow it to
handle system services, in order to allow starting/stopping teamviewer
services. But on one hand we have the init system with its tools for
that already and on the other how to handle permissions would be
something to be really clear about.

Also I'd rather get rid of teamviewer than to provide support for it. I
use it very rarely for support cases from customer of my employee.


I think it would be nice to call it like 'uservice', instead of
'u[ser]service[s]', which is a lot bigger name, or a alias called
'uservice', since 'service' is also another tool, to deal with..
services.

I bet I'd make that a symlink or so, so the tool could work as either
'uservice' or 'userservice'.  'uservice' also has 'user' and 'service'
in it. I also thought about just 'us' but Z-Shell would like to correct
that to 'su' and… those really short command names are better reserved
for commands that the likely user calls often, such as 'cp', 'mv' and so
on.

Ciao,


    Why not call it Userd ? It can compare with Systemd. It's made for 
the user, and user-friendly, and it does one thing, the thing it claims 
to do.


        Didier


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng


Re: [DNG] [RFC] User services

2019-05-13 Thread Martin Steigerwald
s@po, tux...@sapo.pt - 11.05.19, 18:22:
> Hello All,
> 
> On Sat, 11 May 2019 11:26:12 +0200
> 
> Martin Steigerwald  wrote:
> > Hi.
> > 
> > Now that the proof of concept is out, I am thinking about extending
> > it a little bit.
[…]
> > What do you think about that?
[…]
> In the past Debian Wheezy had a tool for that, called 'chkconfig', it
> was a lot used in the Datacenter.. 
> # Adding a Service 'atsd':
>   chkconfig --add atsd;
> # Enable the service in several Runlevels:
>   chkconfig --level 12345 atss on;

AFAIK that is a tool coming from RHEL/CentOS/Fedora that was dropped 
from Debian for some reason. It only works with system-wide services as 
far as I am aware of.

> And other funcionalities, like listing the services and so on..
> It was a very helpfull tool.
> 
> In the absence of it( I don't know why it was removed .. ), your tool
> seems to come to replace it, BUT for users only? :)

I do not know why it was removed.

And yes, my approach is just for user services. I already thought about 
making it a generic frontend for runit/s6, in order to also allow it to 
handle system services, in order to allow starting/stopping teamviewer 
services. But on one hand we have the init system with its tools for 
that already and on the other how to handle permissions would be 
something to be really clear about.

Also I'd rather get rid of teamviewer than to provide support for it. I 
use it very rarely for support cases from customer of my employee.

> I think it would be nice to call it like 'uservice', instead of
> 'u[ser]service[s]', which is a lot bigger name, or a alias called
> 'uservice', since 'service' is also another tool, to deal with..
> services.

I bet I'd make that a symlink or so, so the tool could work as either 
'uservice' or 'userservice'.  'uservice' also has 'user' and 'service' 
in it. I also thought about just 'us' but Z-Shell would like to correct 
that to 'su' and… those really short command names are better reserved 
for commands that the likely user calls often, such as 'cp', 'mv' and so 
on.

Ciao,
-- 
Martin


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng


Re: [DNG] [RFC] User services

2019-05-13 Thread Martin Steigerwald
Hi.

Thank you, Hendrik for your feedback.

Hendrik Boom - 11.05.19, 16:45:
> On Sat, May 11, 2019 at 11:26:12AM +0200, Martin Steigerwald wrote:
> > Now that the proof of concept is out, I am thinking about extending
> > it a little bit.
> 
> You use the spellings user-services, userservices, and userservice.

Yep, that is right.

> Is there actually a difference in meaning between these?  Or
> conventinos that have to be used in different paces?  If not, perhaps
> you should pick one spelling and stick with it.

Well I thought using 'userservices' for doing the stuff that affects all 
user services, i.e. install/update them to home directory and remove 
them. And 'userservice' to act with single user services like enable and 
disable them.

But OTOH that is not really necessary. One script that does it all would 
do. I'd call it 'userservice' as using a dash in a command name feels 
awkward to me. For the repo name I went with what Evilham suggested, 
i.e. 'user-services'.

Best,
-- 
Martin


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng


Re: [DNG] [RFC] User services

2019-05-11 Thread s
Hello All,

On Sat, 11 May 2019 11:26:12 +0200
Martin Steigerwald  wrote:

> Hi.
> 
> Now that the proof of concept is out, I am thinking about extending it a 
> little bit.
> 
> - make is a package
> - make "install-or-update.sh" into "/usr/bin/userservices" with the 
> following actions:
>   - install: Sets up userservices for the user
>   - update: Updates it
>   - remove: Removes i
> - make "userservice" alias into "/usr/bin/userservice"
>   - that way the user would not have to setup an alias anymore.
> 
> So with these changes using user services would be like:
> 
> As root:
> 
> apt install user-services
> 
> As user:
> 
> userservices install
> 
> userservice enable redshift
> 
> [x] done :)
> 
> 
> If user-services packaged gets updated, the user can decide to update 
> her installation with:
> 
> userservices update
> 
> Ideally it would take into account when the user changed some services.
> 
> 
> What do you think about that?
> 
> It would be some work, but I for me this sounds like a good idea.
> 
> 
> In anyway: This is still in proof of concept stage, so I may change 
> everything :). If you are using this, you are brave alpha tester :)
> 

In the past Debian Wheezy had a tool for that, called 'chkconfig', it was a lot 
used in the Datacenter..
# Adding a Service 'atsd':
chkconfig --add atsd;
# Enable the service in several Runlevels:
chkconfig --level 12345 atss on;
# Start the Service:
/etc/init.d/atsd start;
# Stop the Service:
/etc/init.d/atsd stop;
# Disable the service in requested runlevels:
chkconfig --level 12345 atsd off;
# Remove the Service:
chkconfig --del atsd;

And other funcionalities, like listing the services and so on..
It was a very helpfull tool.

In the absence of it( I don't know why it was removed .. ), your tool seems to 
come to replace it, BUT for users only? :)

I think it would be nice to call it like 'uservice', instead of 
'u[ser]service[s]', which is a lot bigger name, or a alias called 'uservice', 
since 'service' is also another tool, to deal with.. services.

This are my thoughts, but I like the idea.. :)

Best Regards,
tux

-- 
s@po 
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng


Re: [DNG] [RFC] User services

2019-05-11 Thread Hendrik Boom
On Sat, May 11, 2019 at 11:26:12AM +0200, Martin Steigerwald wrote:
> Hi.
> 
> Now that the proof of concept is out, I am thinking about extending it a 
> little bit.

You use the spellings user-services, userservices, and userservice.

Is there actually a difference in meaning between these?  Or conventinos 
that have to be used in different paces?  If not, perhaps you should 
pick one spelling and stick with it.

-- hendrik

> 
> - make is a package
> - make "install-or-update.sh" into "/usr/bin/userservices" with the 
> following actions:
>   - install: Sets up userservices for the user
>   - update: Updates it
>   - remove: Removes i
> - make "userservice" alias into "/usr/bin/userservice"
>   - that way the user would not have to setup an alias anymore.
> 
> So with these changes using user services would be like:
> 
> As root:
> 
> apt install user-services
> 
> As user:
> 
> userservices install
> 
> userservice enable redshift
> 
> [x] done :)
> 
> 
> If user-services packaged gets updated, the user can decide to update 
> her installation with:
> 
> userservices update
> 
> Ideally it would take into account when the user changed some services.
> 
> 
> What do you think about that?
> 
> It would be some work, but I for me this sounds like a good idea.
> 
> 
> In anyway: This is still in proof of concept stage, so I may change 
> everything :). If you are using this, you are brave alpha tester :)
> 
> Thanks,
> -- 
> Martin
> 
> 
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng


Re: [DNG] [RFC] User services

2019-05-11 Thread Martin Steigerwald
Martin Steigerwald - 11.05.19, 11:26:
> Hi.
> 
> Now that the proof of concept is out, I am thinking about extending it
> a little bit.
> 
> - make is a package
> - make "install-or-update.sh" into "/usr/bin/userservices" with the
> following actions:
>   - install: Sets up userservices for the user
>   - update: Updates it
>   - remove: Removes i

- remove: Removes user services from user directory completely (after 
confirmation)

Okay, while discussing this with Evilham, I agree that there likely is 
no need to differentiate between "install" and "update". I bet that is 
why I  started with "install-or-update.sh" to begin with.

Keep it stateless, keep it simple. As only

> - make "userservice" alias into "/usr/bin/userservice"
>   - that way the user would not have to setup an alias anymore.

will adapt the symlinks that are in ~/$SERVICEDIR/enabled 
(SERVICEDIR=".service" by default) and that on user request only.

If one really likes to overwrite own changes to "run" files, there can be 
an "--overwrite" option.

> So with these changes using user services would be like:
> 
> As root:
> 
> apt install user-services
> 
> As user:
> 
> userservices install
> 
> userservice enable redshift
> 
> [x] done :)
> 
> 
> If user-services packaged gets updated, the user can decide to update
> her installation with:
> 
> userservices update
> 
> Ideally it would take into account when the user changed some
> services.
> 
> 
> What do you think about that?
> 
> It would be some work, but I for me this sounds like a good idea.
> 
> 
> In anyway: This is still in proof of concept stage, so I may change
> everything :). If you are using this, you are brave alpha tester :)

Thanks,
-- 
Martin


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng


[DNG] [RFC] User services

2019-05-11 Thread Martin Steigerwald
Hi.

Now that the proof of concept is out, I am thinking about extending it a 
little bit.

- make is a package
- make "install-or-update.sh" into "/usr/bin/userservices" with the 
following actions:
  - install: Sets up userservices for the user
  - update: Updates it
  - remove: Removes i
- make "userservice" alias into "/usr/bin/userservice"
  - that way the user would not have to setup an alias anymore.

So with these changes using user services would be like:

As root:

apt install user-services

As user:

userservices install

userservice enable redshift

[x] done :)


If user-services packaged gets updated, the user can decide to update 
her installation with:

userservices update

Ideally it would take into account when the user changed some services.


What do you think about that?

It would be some work, but I for me this sounds like a good idea.


In anyway: This is still in proof of concept stage, so I may change 
everything :). If you are using this, you are brave alpha tester :)

Thanks,
-- 
Martin


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng