Thank you very much.
And have a blessed day.

On Sun, Aug 21, 2016 at 7:04 AM, Jonathan de Boyne Pollard <
J.deBoynePollard-newsgroups@ntlworld.com> wrote:

> I don't know why you asked about FreeBSD rc.d just on the Debian mailing
> list; but I'm going to deal in both of those and others besides, here, and
> things that apply across both, so I've re-included the FreeBSD mailing
> list.  (-:
>
> 2016-08-14 15:10, Julian Elischer:
>
> I don't know if I just missed it, or it isn't there but  I have a
>> question..
>>
>> You give examples of importing systemd service files.  What about
>> importing rc.d files with all their ability to run arbitrary shell commands.
>>
>> And once you have the services defined, what is the logical equivalent of
>> rc.conf, which can supply parameters for each service and turn them on and
>> off?  can you import from rc.conf?
>>
>> You did miss it.  (-:
>
> What you missed has grown to be a significant subsystem. It was actually
> mentioned a couple of times in the 1.28 announcement. It's the external
> configuration import subsystem.  You can read about it in the nosh Guide:
>
> xdg-open /usr/local/share/doc/nosh/external-formats.html
>
> As you can see, there's a whole section on importing from rc.conf into
> native service management mechanisms.  ("rc.conf" covers several sources,
> note, including a FreeNAS configuration database and /etc/defaults/rc.conf
> .)
>
> The native service mangement mechanisms are the "enable" and "disable"
> subcommands to the system-control command, and using the envdir command in
> the normal daemontools-family style way.  The enable/disable mechanism in
> "rc.conf" is treated as if it were a preset (in systemd nomenclature).  You
> tell service management to "preset" a service, and it will look at
> /etc/rc.conf and /etc/rc.conf.local (as well as some other preset
> mechanisms) to determine what to set the native enable/disable state to.
> The user manual page for the preset subcommand (of system-control) explains
> what the preset mechanisms are in detail.
>
> You can set up environment directories how and where you like, but there's
> a convention that is shared by the "convert-systemd-units" tool, the
> "rcctl" shim, and the external configuration import subsystem as a whole.
> This convention is an environment directory named "env" that is in the
> service directory.  The "rcctl" shim gets and sets variables there; and the
> import subsystem places converted "rc.conf", /etc/fstab, /etc/ttys,
> /etc/my.cnf, and other stuff there.
>
> One example of this in action, out of many in the import subsystem, is
> jails that have been set up the version 9 way in "rc.conf".  Those are
> turned into service bundles, with "env" environment directories that
> contain environment settings such as "hostname", "mount_devfs", and
> "interface".  The "run" script for the jail service very simply turns the
> environment variables into arguments to the "jail" comand.  In a system
> with an original OpenBSD "rcctl" command, one would expect to be able to
> set (version 9) jail control variables by manipulating /etc/rc.conf with
> commands like "rcctl set wibble hostname wobble".  The "rcctl" shim and
> this shared convention mean that one need not stray that far from this if
> "rcctl" is one's habit: "rcctl set v9-jail@wibble hostname wobble" does
> the "native" thing of setting the "hostname" variable in the (conventional)
> environment variable directory for the "v9-jail@wibble" service.
>
> Bonus feature for those with other habits: With nosh service management in
> place, one can actually import from /etc/rc.conf settings *on Debian* (as
> long as one sets up a FreeBSD/PC-BSD-style /etc/defaults/rc.conf pointing
> to it with rc_conf_files).  One can use /etc/ttys, too.
>
> As for importing scripts that run "arbitrary shell commands", there are
> several points.
>
> First, you may not need to.  Note that most of what you get out of the box
> in /etc/rc.d/ and /usr/local/etc/rc.d/ on FreeBSD and PC-BSD has already
> been converted.  Remember that project that I had to convert 157 services?
> Take a look at the nosh roadmap page.  It's almost done.
>
> Second, you may not need to.  Take a look at what actually comes in the
> nosh-bundles package nowadays.  Discounting the 'cyclog@' service bundles
> there are just over 540 service bundles in there, from samba to ntp, from
> saned to ossec@agentd.  (Including the 'cyclog@' service bundles, it is
> over a thousand service bundles.)  The Debian world doesn't get left out,
> either. Although it's a lot more difficult than in the BSD worlds to come
> up with a list of "core" Debian services, a lot of the basics of Debian are
> also covered by this, from kernel-vt-setfont through irqbalance to
> update-binfmts.  And those more-than-540 service bundles cover lots of
> "non-core" stuff, from (as aforementioned) OSSEC-HIDS, Salt, and RabbitMQ
> to publicfile httpd over IPV6.
>
> Third, you may not need to.  This was mentioned in the 1.28 announcement,
> in fact.  The external configuration import subsystem makes *further*
> service bundles, beyond the pre-made ones that come in a binary package.
> It creates service bundles to run (optional) per-user service management,
> per-user Desktop Bus brokers, MySQL and MariaDB servers (according to your
> my.cnf), PPP and SPPP, md and pefs, jails (set up with v9 rc.conf or the
> PC-BSD Warden), tinydns and dnscache services (not quite ready when 1.28
> came out, as the announcement said), static IP4/IP6/ARP/NDP setup and
> teardown, and more besides.
>
> Fourth, you may not need to.  Out of all of this, there's probably already
> an existing service bundle for something similar that one can copy and
> adapt.
>
> Fifth, you may not need to.  The convert-systemd-units tool exists, after
> all.  If there's a system service/socket unit around, converting that may
> well be simpler starting point than starting with an rc script.  It's
> usually significantly simpler than starting with a van Smoorenburg rc
> script, although Mewburn and OpenBSD rc scripts can themselves be fairly
> simple starting points.  I did a "make fetch" on the PC-BSD ports tree a
> couple of months ago.  (As an aside: there are several broken ports that
> don't do the right thing here.)  There are a growing number of packages
> where there's now a systemd service/socket unit in the fetched source
> archive.
>
> Sixth, the easy cases are easy.  As just noted, Mewburn and OpenBSD rc
> scripts can themselves be fairly simple.  (They are not *always* so,
> though, contrary to popular belief.)  If you have an rc script that says
> "The command name is this, its arguments are that.", it is very easy indeed
> to convert this into something that can execute as a "run" program.
> Setting up all of the stuff around the "run" program for a complete service
> bundle is merely an exercise in two-line shell scripts (for things like
> "start" and "stop") and making directories and symbolic links (for things
> like the "before" and "wants" directories).
>
> Seventh, the hard cases require a human being anyway.  Parsing a shell
> script that runs "arbitrary shell commands" would require creating what is
> essentially a full shell script interpreter, that can handle the Almquist,
> Bourne Again, and Korn shell syntaxes (because such a hypothetical
> *general-case* conversion tool would have to address van Smoorenburg rc
> scripts on Debian, Mewburn rc scripts on FreeBSD/PC-BSD/NetBSD and friends,
> and OpenBSD rc scripts) that knows about at least five quite different sets
> of "helper" commands (from start-stop-daemon to startproc) and that works
> out how an entire shell script translates into the actual acts of executing
> one or (in really bad cases) more services.  At this point, I defer to a
> human being *understanding what is needed* and writing one or more service
> bundles.  (-:
>
> And there is, of course, scads of doco, written over the past two decades
> by many people, on how to write daemontools-family-style "run" scripts.
>
> _______________________________________________
> freebsd-hackers@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"
>