Re: nosh version 1.28

2016-08-21 Thread Jonathan de Boyne Pollard
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,

Re: nosh version 1.28

2016-08-15 Thread Jonathan de Boyne Pollard

Guillermo:


OpenBSD
===

[...]
There are an awful lot of limitations to OpenBSD, [...]

How funny it is that this summary and the WWW page echo the sentiments 
in skarnet.org packages' source files comments and commit messages :D




We didn't collaborate.  (-:  I don't actually know what M. Bercot has 
said on the matter.  It's not unexpected that two projects sharing 
several design principles will hit the same problems with OpenBSD, though.


The more interesting things to consider are other operating systems.

For starters: Ubuntu on Windows NT would possibly be a less problematic 
port than OpenBSD.  Whilst it, too, has obstacles with pseudo-terminals, 
framebuffers, and the system manager; what it doesn't have, that OpenBSD 
has, is the difficulty with the package management.  Ubuntu on Windows 
NT has APT like Debian, of course. I've said before, elsewhere, that one 
could probably successfully get nosh service management, UCSPI support, 
and log management working on Ubuntu on Windows NT; although obtaining 
an actual daemon context is still problematic. 
(https://news.ycombinator.com/item?id=11416376)


Moreover: UbuntuBSD and Debian FreeBSD shouldn't have the obstacles with 
the pseudo-terminals, framebuffers, and the system manager; these, after 
all, being things that the FreeBSD operating system kernel provides in 
largely suitable form. (https://news.ycombinator.com/item?id=11326457)


Incidentally: I wrote a while ago that UbuntuBSD probably wouldn't use 
Mewburn rc.  It doesn't.  UbuntuBSD 16.04, released this month, uses 
BusyBox init and (the Debian port of) OpenRC rc.




Re: nosh version 1.28

2016-08-15 Thread Jonathan de Boyne Pollard
> 
> I'm going to be very naughty and patch 1.28 post-release. It's a minor
> change.
> 

I've changed my mind.  I'm going to point the two of you at a potential version
1.29 and see how you get on.

This is because I have ended up doing slightly more than a 2-line script patch.

Re: nosh version 1.28

2016-08-14 Thread Jonathan de Boyne Pollard

Guillermo:

Could the plain 'setlock' invocation in script source/default.html.do 
be changed to './exec setlock', as in scripts source/default.1.do and 
source/default.8.do, please? Otherwise we have the chicken-and-egg 
situation we had with nosh-1.19:



It was supposed to be that way already.  (-:

You've been beaten by the person who is kindly doing a PKGBUILD for Arch 
Linux, who spotted this a couple of days ago.  I'm going to be very 
naughty and patch 1.28 post-release.  It's a minor change.


It turns out that even when I was building from scratch on OpenBSD, I 
was building on machines that always had *someone's* setlock available.  (-:


I had a similar problem building something else quite recently. It had 
several Bernstein libraries in it.  I didn't see several C2011 build 
problems because I had libowfat installed and that was being used instead.




Re: nosh version 1.28

2016-08-14 Thread Guillermo
Hi,

2016-08-06 14:30 GMT-03:00 Jonathan de Boyne Pollard:
>
> The nosh package is now up to version 1.28 .

Could the plain 'setlock' invocation in script source/default.html.do
be changed to './exec setlock', as in scripts source/default.1.do and
source/default.8.do, please? Otherwise we have the chicken-and-egg
situation we had with nosh-1.19:



> OpenBSD
> ===
>
> [...]
> There are an awful lot of limitations to OpenBSD, [...]

How funny it is that this summary and the WWW page echo the sentiments
in skarnet.org packages' source files comments and commit messages :D

Thanks,
G.