Question about FAQ section 10.3

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Question about FAQ section 10.3

Worik Stanton
"Processes local and package scripts in /etc/rc.d" is listed as the last
thing rc does after boot.

What does "Processes" mean in this context?

Naively I would think this means that the scripts are all executed.  But
that seems odd in this context as most of (all of?) the scripts take an
argument that they pass to rc_cmd from rc.subr, and rc is not passing
"start" to all those scripts.

Looking at https://en.wikipedia.org/wiki/Init it seems my naive
assumption is correct, but why run all those scripts?

I am puzzled.

Worik

--
Why is the legal status of chardonnay different to that of cannabis?
       [hidden email] 021-1680650, (03) 4821804
                          Aotearoa (New Zealand)

Reply | Threaded
Open this post in threaded view
|

Re: Question about FAQ section 10.3

Nick Holland
On 10/23/14 21:36, worik wrote:
> "Processes local and package scripts in /etc/rc.d" is listed as the last
> thing rc does after boot.
>
> What does "Processes" mean in this context?

like "processing food" -- do whatever needs to be done.
(not my best analogy, I'll admit)

But yeah. run the scripts that are indicated as needing to be run, they
do whatever they need to do.  USUALLY start daemons, but could be lots
of other things, too.

> Naively I would think this means that the scripts are all executed.  But
> that seems odd in this context as most of (all of?) the scripts take an
> argument that they pass to rc_cmd from rc.subr, and rc is not passing
> "start" to all those scripts.

why do you say that?
Look at the /etc/rc script...yes it does execute each of the rc.d
scripts, and yes it DOES pass "start" to them:

start_daemon()
{
        local _n
        for _n; do
                eval _do=\${${_n}_flags}
                if [ X"${_do}" != X"NO" ]; then
                        /etc/rc.d/${_n} start # <----- start!!
                fi
        done
}

now look how start_daemon is invoked...

> Looking at https://en.wikipedia.org/wiki/Init it seems my naive
> assumption is correct, but why run all those scripts?

um. because that's how we do it?

Before 4.9 or so...we hard-coded the startup process for each daemon in
/etc/rc, we decided to switch to the rc.d process for some additional
flexibility.

I'll admit I was dubious when it was first done, fearing we might be
heading down the idiotic "everything.d" directories that many Linux
distros are now doing, but it turns out I rather like it.

Nick.

Reply | Threaded
Open this post in threaded view
|

Re: Question about FAQ section 10.3

Worik Stanton
On 24/10/14 14:53, Nick Holland wrote:
> On 10/23/14 21:36, worik wrote:
>> "Processes local and package scripts in /etc/rc.d" is listed as the last
>> thing rc does after boot.
>>
>> What does "Processes" mean in this context?
>
> like "processing food" -- do whatever needs to be done.
> (not my best analogy, I'll admit)
>

[snip]

> Look at the /etc/rc script...yes it does execute each of the rc.d
> scripts, and yes it DOES pass "start" to them:

[snip]

> now look how start_daemon is invoked...

Interesting.  In /etc/rc start_daemon is called for specific named
scripts.  Except that (at line 520) it runs it for all scripts in
$pkg_scripts

My shell scripting is really bad (I am going to have to up my game there
if I am going to stick around here) but it seems it is set to an empty
string in rc.conf

(Mis)reading the FAQ I thought it meant *all* scripts in /etc/rc.d were
"Processed". .  It actually says "...local and packaged scripts...".  So
if a package wants to be sure it is run at startup does it write that
into the rc.conf where mine says...

# rc.d(8) packages scripts
# started in the specified order and stopped in reverse order


pkg_scripts=

I installed postgresql (with pkg_add) and it did not change this, I had
to change /etc/rc.local by hand.  Is there some reason why postgresql
should not be started after a reboot?  Have I completely got the wrong
end of the stick?


Worik

>
>> Looking at https://en.wikipedia.org/wiki/Init it seems my naive
>> assumption is correct, but why run all those scripts?
>
> um. because that's how we do it?
>
> Before 4.9 or so...we hard-coded the startup process for each daemon in
> /etc/rc, we decided to switch to the rc.d process for some additional
> flexibility.
>
> I'll admit I was dubious when it was first done, fearing we might be
> heading down the idiotic "everything.d" directories that many Linux
> distros are now doing, but it turns out I rather like it.
>
> Nick.
>
>


--
Why is the legal status of chardonnay different to that of cannabis?
       [hidden email] 021-1680650, (03) 4821804
                          Aotearoa (New Zealand)
                             I voted for love

[demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]

Reply | Threaded
Open this post in threaded view
|

Re: Question about FAQ section 10.3

Craig Skinner-3
On 2014-10-24 Fri 15:29 PM |, Worik Stanton wrote:
>
> I installed postgresql (with pkg_add) and it did not change this, I had
> to change /etc/rc.local by hand.  Is there some reason why postgresql
> should not be started after a reboot?  Have I completely got the wrong
> end of the stick?
>

You're very close.

$ man rc.conf:
...
..
  It is advisable to leave rc.conf untouched, and instead create and edit a
  new rc.conf.local file.  Variables set in this file will override
  variables previously set in rc.conf.

The man page then gives an example of dhcpd.

/etc/rc 'starts' /etc/rc.d/dhcpd,
but its default flag in /etc/rc.conf is 'NO', so it doesn't start.
To actually start dhcpd, override its flags in /etc/rc.conf.local

$ fgrep dhcpd /etc/rc*
/etc/rc:start_daemon relayd dhcpd dhcrelay mrouted dvmrpd
/etc/rc.conf:dhcpd_flags=NO             # for normal use: ""
/etc/rc.conf.local:dhcpd_flags=''


Then the man page then covers the 'pkg_scripts' variable,
responsible for starting and stopping daemons installed from packages.

--
Craig Skinner | http://twitter.com/Craig_Skinner | http://linkd.in/yGqkv7

Reply | Threaded
Open this post in threaded view
|

Re: Question about FAQ section 10.3

Adam Thompson
On 14-10-24 03:57 AM, Craig R. Skinner wrote:
> On 2014-10-24 Fri 15:29 PM |, Worik Stanton wrote:
>> I installed postgresql (with pkg_add) and it did not change this, I had
>> to change /etc/rc.local by hand.  Is there some reason why postgresql
>> should not be started after a reboot?  Have I completely got the wrong
>> end of the stick?
> You're very close.
>
> $ man rc.conf:

Adding to Craig's comments, no, OpenBSD packages generally do NOT modify
/etc/rc.conf.local for you.
Until very recently, /etc.rc.conf.local was executed as a shell script,
so arbitrarily modifying things in a (possibly completely custom) shell
script would be a Very Bad Thing.
Recent changes mean that /etc/rc.conf.local is now parsed instead of
being executed; the format & syntax are now much more constrained, and
AFAIK it would be possible for packages to now automatically make
changes in a safe(r) way.

However, I still don't expect to see that happen - it just doesn't feel
like the OpenBSD way.
If you want to run a process, you should have to perform some manual
step to cause it to run.  Processes that unexpectedly spring into
existence at the next reboot are also considered (at least by me) a Bad
Thing.

--
-Adam Thompson
  [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Question about FAQ section 10.3

Nick Holland
In reply to this post by Worik Stanton
On 10/23/14 22:28, Worik Stanton wrote:

> On 24/10/14 14:53, Nick Holland wrote:
>> On 10/23/14 21:36, worik wrote:
>>> "Processes local and package scripts in /etc/rc.d" is listed as the last
>>> thing rc does after boot.
>>>
>>> What does "Processes" mean in this context?
>>
>> like "processing food" -- do whatever needs to be done.
>> (not my best analogy, I'll admit)
>>
>
> [snip]
>
>> Look at the /etc/rc script...yes it does execute each of the rc.d
>> scripts, and yes it DOES pass "start" to them:
>
> [snip]
>
>> now look how start_daemon is invoked...
>
> Interesting.  In /etc/rc start_daemon is called for specific named
> scripts.  Except that (at line 520) it runs it for all scripts in
> $pkg_scripts

note here, because I get this confused myself: pkg_scripts are for added
PACKAGES.  Not stock stuff.
PLUS...stock stuff is enabled in one way (daemon_flags="") vs. being
added to pkg_scripts.

> My shell scripting is really bad (I am going to have to up my game there
> if I am going to stick around here) but it seems it is set to an empty
> string in rc.conf

yep.  Now it exists...but is empty.
YOU get to set that.

> (Mis)reading the FAQ I thought it meant *all* scripts in /etc/rc.d were
> "Processed". .  It actually says "...local and packaged scripts...".  So
> if a package wants to be sure it is run at startup does it write that
> into the rc.conf where mine says...

processed...as appropriate.  That may mean "ignore". :)

> # rc.d(8) packages scripts
> # started in the specified order and stopped in reverse order
>
> pkg_scripts=
>
> I installed postgresql (with pkg_add) and it did not change this, I had
> to change /etc/rc.local by hand.  Is there some reason why postgresql
> should not be started after a reboot?  Have I completely got the wrong
> end of the stick?

read through that section closer...  for things you want to start and
stop in the "normal" OpenBSD way, put them in rc.conf.local.  rc.local
is for things that the "normal" way isn't appropriate for.  For example,
I maintain a system where there is a daemon installed that is not
perfectly stable -- it just shuts down once in a while.  It would work
just fine from its rc.d script -- until it stops.  So, I've got a little
script that runs it in a loop; when it crashes, wait a few seconds, then
re-launch, and that's invoked in rc.local.

Yes, there are lots of reasons why various packages should not be
started at boot, and even more reasons why the ORDER of applications
starting is critical, and something that only an administrator will
know.  For reasons of order alone, I don't think you will ever see
pkg_add start daemons automatically.

I know many DBAs who prefer that database engines are started manually.
 I'm not personally in agreement with that, I like my systems to fire up
automatically at boot (something about enjoying uninterrupted
vacations), but whatever, and having seen some really unstable apps, in
some cases there might be good arguments for this, though the better
logic would be "fix your damn app!".

Other packages have both daemon and userland modes -- rsync is one of
those.  You certainly don't want rsync running as a daemon just because
you installed rsync.

In a hostile network environment, you don't want unconfigured apps
starting at boot.  Install, configure, test, THEN configure to start at
boot (then reboot to make sure it really works).

Nick.

Reply | Threaded
Open this post in threaded view
|

Re: Question about FAQ section 10.3

Marcus MERIGHI
In reply to this post by Adam Thompson
[hidden email] (Adam Thompson), 2014.10.24 (Fri) 11:19 (CEST):

> On 14-10-24 03:57 AM, Craig R. Skinner wrote:
> >On 2014-10-24 Fri 15:29 PM |, Worik Stanton wrote:
> >>I installed postgresql (with pkg_add) and it did not change this, I had
> >>to change /etc/rc.local by hand.  Is there some reason why postgresql
> >>should not be started after a reboot?  Have I completely got the wrong
> >>end of the stick?
> >You're very close.
> >
> >$ man rc.conf:
>
> Adding to Craig's comments, no, OpenBSD packages generally do NOT modify
> /etc/rc.conf.local for you.

and now there's rcctl(8), so there is almost no reason to touch
rc.conc.local(8) manually anymore.

But be warned (it's biting me a bit): using ``rcctl disable xxxxxx''
doesn't just remove xxxxxx from pkg_scripts, it removes the
xxxxxx_flags as well. In case you had carefully crafted command line
parameters there, the simple ``rcctl disable'' command might make you
unhappy. (rcctl disable is not reversed by rcctl enable, that is.)

Question: why does "rcctl disable xxxxxx" not just remove xxxxxx from
pkg_scripts? (But also removes xxxxxx_flags.) Removing the xxxxxx_flags
could be done via ``rcctl disable xxxxxx flags ""'' if really wanted,
no?

And while I'm in asking mode: the rcctl(8) ``default'' command cannot
have values for non-base services/daemons, right?

Bye + TIA, Marcus

> Until very recently, /etc.rc.conf.local was executed as a shell script, so
> arbitrarily modifying things in a (possibly completely custom) shell script
> would be a Very Bad Thing.
> Recent changes mean that /etc/rc.conf.local is now parsed instead of being
> executed; the format & syntax are now much more constrained, and AFAIK it
> would be possible for packages to now automatically make changes in a
> safe(r) way.
>
> However, I still don't expect to see that happen - it just doesn't feel like
> the OpenBSD way.
> If you want to run a process, you should have to perform some manual step to
> cause it to run.  Processes that unexpectedly spring into existence at the
> next reboot are also considered (at least by me) a Bad Thing.
> !DSPAM:544a19e1213124755513058!

Reply | Threaded
Open this post in threaded view
|

Re: Question about FAQ section 10.3

Ingo Schwarze
Hi Marcus,

Marcus MERIGHI wrote on Fri, Oct 24, 2014 at 02:22:55PM +0200:

> But be warned (it's biting me a bit): using ``rcctl disable xxxxxx''
> doesn't just remove xxxxxx from pkg_scripts, it removes the
> xxxxxx_flags as well. In case you had carefully crafted command line
> parameters there, the simple ``rcctl disable'' command might make you
> unhappy. (rcctl disable is not reversed by rcctl enable, that is.)
>
> Question: why does "rcctl disable xxxxxx" not just remove xxxxxx from
> pkg_scripts? (But also removes xxxxxx_flags.)

It's a carefully pondered design decision.  The rcctl(8) utility
is intended for use by management frameworks taking care of many
machines at once.  In such a context, it is useful to keep configuration
files in a clean, normalized state, and information stored on
individual machines is not only useless; in general, it even tends
to obstruct automated changes.  You don't have your carefully crafted
flags in rc.conf.local(8) on one single machine, but in some central
place.

Of course, you are welcome to run it manually, too, but the
requirements of management frameworks constrain the design quite a
bit, so there is not that much room left for decisions to improve
convenience for manual use.

> Removing the xxxxxx_flags could be done via
> ``rcctl disable xxxxxx flags ""'' if really wanted, no?

Well, in case we would implement saving flags for disabled services,
the quotes would be useless.  Remember:

  rcctl enable identd flags " "
  -> identd_flags=" "   # in /etc/rc.conf.local
  -> identd will start without flags

  rcctl enable identd flags
  -> identd_flags=
  -> identd will start with default flags (-e)

  rcctl enable identd
  -> no change if already enabled
  -> enable with default flags if disabled

But i don't think we will support saving flags for disabled daemons.
It's just additional complexity for little gain, and there is a
risk to confuse people who look at /etc/rc.conf.local and don't
remember whether it's a base or a package daemon.

Besides, if you really want to keep the flags when disabling,
firing up sudoedit(8) and manually editing pkg_scripts is not
significantly more keystrokes than "rcctl disable xxxxxx".

> And while I'm in asking mode: the rcctl(8) ``default'' command cannot
> have values for non-base services/daemons, right?

It can:

   $ rcctl default wesnothd
  -d
   $ rcctl default saslauthd
  -a getpwent

Yours,
  Ingo

Reply | Threaded
Open this post in threaded view
|

Re: Question about FAQ section 10.3

Marcus MERIGHI
Hello Ingo,

first of all: thanks for taking the time!

[hidden email] (Ingo Schwarze), 2014.10.24 (Fri) 15:00 (CEST):

> Marcus MERIGHI wrote on Fri, Oct 24, 2014 at 02:22:55PM +0200:
>
> > But be warned (it's biting me a bit): using ``rcctl disable xxxxxx''
> > doesn't just remove xxxxxx from pkg_scripts, it removes the
> > xxxxxx_flags as well. In case you had carefully crafted command line
> > parameters there, the simple ``rcctl disable'' command might make you
> > unhappy. (rcctl disable is not reversed by rcctl enable, that is.)
> >
> > Question: why does "rcctl disable xxxxxx" not just remove xxxxxx from
> > pkg_scripts? (But also removes xxxxxx_flags.)
>
> It's a carefully pondered design decision.  The rcctl(8) utility
> is intended for use by management frameworks taking care of many

Alright, thanks for the clue, this explains...
(But I think I've carefully read everything publicly available wrt
rcctl(8) lately. Are you guys hanging out on h..k..s@, again? ;-)

Are you talking about existing (non-base) management frameworks or are
you heading for an in-base management framework and rcctl is only the
first step?  (Talking about a ``management framework'' in base OpenBSD
feels strange.)

> machines at once.  In such a context, it is useful to keep configuration
> files in a clean, normalized state, and information stored on
> individual machines is not only useless; in general, it even tends
> to obstruct automated changes.  You don't have your carefully crafted
> flags in rc.conf.local(8) on one single machine, but in some central
> place.

Just started my central place.

> Of course, you are welcome to run it manually, too, but the

I've seen instructions to do so on current.html.

> requirements of management frameworks constrain the design quite a
> bit, so there is not that much room left for decisions to improve
> convenience for manual use.

ACK

> > Removing the xxxxxx_flags could be done via
> > ``rcctl disable xxxxxx flags ""'' if really wanted, no?
>
> Well, in case we would implement saving flags for disabled services,
> the quotes would be useless.  Remember:
>
>   rcctl enable identd flags " "
>   -> identd_flags=" "   # in /etc/rc.conf.local
>   -> identd will start without flags
>
>   rcctl enable identd flags
>   -> identd_flags=
>   -> identd will start with default flags (-e)
 
>   rcctl enable identd
>   -> no change if already enabled
>   -> enable with default flags if disabled

1) *_flags=" "      => no flags, not even default
2) *_flags=         => default flags from rc.d/* script daemon_flags
3) *_flags="-param" => use specified flags, not default
 
> But i don't think we will support saving flags for disabled daemons.

ACK

> It's just additional complexity for little gain, and there is a
> risk to confuse people who look at /etc/rc.conf.local and don't
> remember whether it's a base or a package daemon.

The gain for me would be > little, but you guys usually have the broader
picture.

> Besides, if you really want to keep the flags when disabling,
> firing up sudoedit(8) and manually editing pkg_scripts is not
> significantly more keystrokes than "rcctl disable xxxxxx".

Right, but from the point of view of rcctl I'm putting rc.conf.local in
an inconsistent state then. But rcctl handles this gracefully, after
manual removal of a service from pkg_scripts and leaving service_flags
untouched a ``rcctl service enable'' just adds the service back to
pkg_scripts and leaves service_flags alone. Since rcctl(8) appends the
service to the pkg_scripts, the order of your ``rcctl enable xxxxxx flags
yyyy'' commands might matter.

> > And while I'm in asking mode: the rcctl(8) ``default'' command cannot
> > have values for non-base services/daemons, right?
>
> It can:
>
>    $ rcctl default wesnothd
>   -d
>    $ rcctl default saslauthd
>   -a getpwent
 
You cought me there; the default values are the daemon_flags within the
individual rc.d(8) script. I assumed (yes, I know...) these were in
rc.conf.

Again, thanks for your time and knowledge!

Bye, Marcus

> !DSPAM:544a4d8a299169175019724!

Reply | Threaded
Open this post in threaded view
|

Re: Question about FAQ section 10.3

Ingo Schwarze
Hi Marcus,

Marcus MERIGHI wrote on Fri, Oct 24, 2014 at 04:22:02PM +0200:

> But I think I've carefully read everything publicly available
> wrt rcctl(8) lately.

While i have contributed a few patches to rcctl(8), mostly of a
technical nature, not adding to functionality, it's still Antoine's
baby and i'm not the right person to post a public summary about
it.  Besides, we are still far from release and rcctl(8) is under
active development.  Maybe a writeup might appear at some point,
i have no idea.

> Are you talking about existing (non-base) management frameworks

Yes.  There have been various commits in that respect.

> or are you heading for an in-base management framework and rcctl
> is only the first step?

I'm not aware of any such plans (then again, i don't hang out
on #porters, and i'm not managing a data center).

> (Talking about a ``management framework'' in base OpenBSD
> feels strange.)

Well, making sure that you remain able to comfortably administer
a small pack of OpenBSD machines *without* needing a management
framework is certainly among the OpenBSD project goals (KISS).

All the same, there are tasks that are almost impossible to
perform without using some kind of a management framework, in
particular when large numbers of machines are involved, and
there are tools in OpenBSD base that the average OpenBSD home
user is unlikely to run, like bgplg(8).

While simplicity is extremely important, that means that concepts
and code ought to be as simple *as possible*.  It doesn't mean that
complex and complicated stuff cannot make it into base, if the
complexity is there for a good reason and unavoidable.  It may if
the benefits exceed the costs (which makes it less likely to import
something huge used only by few people) and somebody sufficiently
capable and trusted invests the required effort.

That said, i'd be very surprised as well to see a data center
management framework in OpenBSD base any time soon, and i'm not
sure that could provide any benefits compared to using something
from ports.

Yours,
  Ingo