rcrun(8), service(8) and future directions

[Matthew Dillon]

We have an experimental 'svc' program that utilizes the new procctl()
system call to control and keep track of services.  start, stop, restart,
etc.  It still needs significant work such as a configuration file or
directory (say, /etc/services, with individual files) where services can be
specified, and an ability to run different scripts as part of a stop or
restart sequence.

Ultimately the goal is to be able to configure jails with significant path
and file writing restrictions, so the services can only read and write
files that they actually need to read and write no matter what uid they are
running as.  That will need some major kernel components and probably also
a UI requester component.

-Matt

On Mon, Nov 17, 2014 at 9:31 PM, Robin Hahling <
robin.hahling at gw-computing.net> wrote:

> I usually am present in the IRC channel (as Rolinh) but people sometimes
> miss
> things that are discussed there. I thought that discussing things on the
> ML was
> a good idea in this regard.
>
> In this case, I missed the parts you are mentioning. If the consensus is
> that
> the service(8) command could go, then I am in favor of removing it from 4.0
> release. I believe it was discreetly added in 3.8.2 release and has not
> been
> advertised a lot. Then, the sooner we remove it, the less we have chances
> of
> disrupting users habits.
>
> As for the missing features from rcrun(8) with regard to service(8),
> having a
> quick look at it I see:
>
>  * -e switch to list services that are enabled. rcrun(8) do have the 'list'
>    argument but it lists all services, whether they are enabled or not
> only the
>    ones that are enabled. This could be added easily.
>  * -r switch, which is similar to 'rcrun list' but the output looks a bit
>    different.
>  * -R switch to restart all enabled local services.
>
> Is there something I am missing?
>
>
> On Mon, 17 Nov 2014 16:15:25 -0700
> "Samuel J. Greear" <sjg at evilcode.net> wrote:
>
> > A discussion along these lines occurred recently on the DragonFly BSD
> > developer IRC channel on EFNet, #dragonflybsd. The consensus was that the
> > service command could go, and that rcrun could use some improvements, the
> > service interface need not necessarily be maintained if rcrun can do all
> of
> > the same things.
> >
> > You should pop into the IRC channel and continue this discussion, as well
> > as taking into account any other input on this email list.
> >
> > Sam
> >
> > On Mon, Nov 17, 2014 at 3:11 PM, Robin Hahling <
> > robin.hahling at gw-computing.net> wrote:
> >
> > > service(8) was brought in past summer, from FreeBSD, as a way to
> control
> > > system
> > > services, as an interface to rc.d system. Since version 1.0 (December
> 2003
> > > to
> > > be exact), DragonFly has had rcrun(8) while service(8) was added to
> > > FreeBSD in
> > > December 2009.
> > >
> > > Having service(8) in DragonFly allow users or sysadmins to find their
> way
> > > around the system a but more quickly since service and its syntax is
> used
> > > in
> > > popular systems such as FreeBSD or even Red Hat and other
> distributions in
> > > the
> > > linux world. However, it would make sense to have service(8)
> implemented
> > > as a
> > > wrapper around rcrun(8) and not a program in itself for obvious
> reasons. I
> > > volunteer for the task if people agree with this idea but really, it
> > > should be
> > > a no brainer.
> > >
> > > While on the subject, rcrun(8) syntax needs to evolve in order to be
> able
> > > to
> > > pass arguments to rc scripts. Future bluetooth rc scripts will need it
> for
> > > instance. The current rcrun(8) syntax is the following:
> > >
> > >     rcrun command script [script2] [script3] ...
> > >
> > > where 'command' is one of 'disable', 'start', etc. This syntax allows
> to
> > > apply
> > > the same operation to multiple rc scripts at once which is very handy
> (at
> > > least
> > > to me). Also, this kind of syntax is similar to the one used in systemd
> > > with
> > > the sysctl tool for instance. In this matter, service(8) syntax is
> > > different:
> > >
> > >     service script command
> > >
> > > This syntax means that you cannot restart or do whatever command at
> once
> > > for
> > > multiple scripts. On the other hand, if we had to add the possibility
> to
> > > add
> > > arguments to the script this could be easily done this way:
> > >
> > >     service script command arg1 arg2 ...
> > >
> > > So I tried to think about a syntax for rcrun(8) that would allow it to
> pass
> > > arguments while still being able to apply a command to multiple
> scripts at
> > > once.  This is the idea that came to my mind: add a prefix to
> arguments so
> > > as
> > > to differentiate arguments from scripts names. For instance:
> > >
> > >     rcrun command script1 :arg1 :arg2 script2 script3 :arg1 :arg2
> > >
> > > In this example, ":" is used as the arguments prefix.  I see several
> > > advantages
> > > to this syntax:
> > >
> > > * It is retro-compatible to current rcrun(8) syntax meaning that it
> won't
> > > break
> > >   users's own scripts or workflow.
> > > * It allies best of both worlds (service(8) and rcrun(8) current
> syntax).
> > > * It is easy to implement.
> > >
> > > If someone has an other/better idea, I would like to hear about it.
> If, on
> > > the
> > > other hand it reaches a consensus, then I volunteer for this task too.
> > > However, there are more things I would need to know about before
> > > processing.
> > > procctl(2) and some other features were added recently and I would
> need to
> > > know
> > > where this is going and what changes it'll bring to rcrun(8) and all of
> > > what it
> > > implies (parallel starting of services, and so on).
> > >
> > > Robin Hahling (Rolinh)
> > >
>
>
> --
> Robin Hahling <robin.hahling at gw-computing.net>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dragonflybsd.org/pipermail/kernel/attachments/20141117/7f1ad341/attachment-0003.html>