Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #170784 > unrolled thread

nosh version 1.28

Back to article view | Back to linux.debian.user

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  nosh version 1.28 Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups@NTLWorld.com> - 2016-08-06 19:50 +0200
    Re: nosh version 1.28 Julian Elischer <julian@freebsd.org> - 2016-08-14 16:50 +0200
      Re: nosh version 1.28 Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups@NTLWorld.com> - 2016-08-21 13:30 +0200
        Re: nosh version 1.28 Joe Nosay <superbisquit@gmail.com> - 2016-08-30 18:00 +0200
    Re: nosh version 1.29 Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups@NTLWorld.com> - 2016-12-03 13:00 +0100
    nosh version 1.29 Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups@NTLWorld.com> - 2016-12-03 13:00 +0100

#170784 — nosh version 1.28

The nosh package is now up to version 1.28 .

* https://jdebp.eu./Softwares/nosh/
* 
https://www.freebsd.org/news/status/report-2015-07-2015-09.html#The-nosh-Project
* http://jdebp.info./Softwares/nosh/

There's a lot in this one: MySQL and MariaDB changes; more prophylaxis 
for Desktop Bus bus activation; improvements to systemd unit conversion; 
support for the old svc -x; machineenv; improvements to service 
management; fixes for the per-user manager; improvements to the console 
terminal emulator; BSD boot mode changes; the ability to pass more open 
sockets to connection-accepting programs; cron; and OpenBSD.

Italics and colour
==================

* https://jdebp.eu./Softwares/nosh/italics-in-manuals.html

This isn't a toolset change, per se.  But the WWW site now has a guide 
to seeing actual italic text in manual pages.  The nosh toolset's 
user-space virtual terminals support true italics (if one has the fonts) 
or obliquing, and this works with them.

MySQL and MariaDB changes
=========================

* https://jdebp.eu./Softwares/nosh/mariadb-and-mysql.html

New in version 1.28 is a different and up-to-date way of managing MySQL 
and MariaDB server services — where "new" translates to finally getting 
rid of that unnecessary mysql_safe wrapper and doing things the way that 
daemontools-family toolset users have wanted to do them since the turn 
of the century.

There's a lengthy exposition on the WWW site, q.v..  The major visible 
effect is that your "mysql" or "mariadb" service is now an alias, for 
something like a "mysql@" or "mysql@01" (if you have [mysql01] in your 
my.cnf) service.  The configuration file import mechanism tries to 
construct/update mariadb@NN and mysql@NN service bundles for you, based 
upon your MariaDB and MySQL configuration files.

Further prophylaxis for Desktop Bus bus activation
==================================================

* https://jdebp.eu./Softwares/nosh/avoid-dbus-bus-activation.html

The nosh toolset now comes with a dbus-daemon-launch-helper 
replacement.  The purpose of this is to sit in your 
/usr/local/etc/dbus-1/system.conf (or equivalent) and redirect to 
service management attempts, by the Desktop Bus broker daemon, to 
demand-start services.  It is slightly fiddly to install, requiring 
manual setup by the system administrator, there being no simple way to 
add overrides to /usr/local/etc/dbus-1/system.conf and it requiring that 
you allow the "messagebus" user the necessary access for starting and 
stopping services (but not necessarily *superuser* access — rembember ACLs).

To assist with this, several popular Desktop Bus "services" now exist as 
alias names for service management services.  These are just symbolic 
links to the service bundle directories, of course. So, for example: 
With the helper in place, Desktop Bus bus activation will try to 
demand-start a service named "org.freedesktop.PackageKit" using service 
management.  This is just an alias for the "packagekit" service.

Improvements to systemd unit conversion
=======================================

Ideal mode is now closer to the daemontools-family mainstream, 
defaulting to the daemontools-family norm of always restarting 
services.  Quirks mode, conversely, now implements more of the 
non-daemontools redirection semantics for standard I/O, in particular 
with regard to listening socket units.  Some more Linuxisms have been 
added.  Limits (where applicable) can now take SI and IEC suffixes (so 
you can, say, express limits in kiloseconds).  This latter is actually 
an augmentation to the underlying softlimit command.

Passing more open sockets to connection-accepting programs
==========================================================

The improvements to systemd unit conversion also allow passing more than 
one listen()ing socket to connection-accepting programs.  You can use, 
say, ListenStream and ListenDatagram and the conversion utility will 
translate this into an appropriate chain of multiple invocations of 
udp-socket-listen and tcp-socket-listen.  It will do 
local-stream-socket-listen, local-datagram-socket-listen, 
netlink-datagram-socket-listen, and fifo-listen too.

The motivator for this was Daniel J. Bernstein's dnscache.  I have 
modified versions of tinydns, dnscache, and taiclockd that understand 
the LISTEN_FDS protocol for their being told about listening sockets 
that have been opened for them, and don't open their own sockets in that 
case.  dnscache, in particular, takes a UDP socket and a listening TCP 
socket.  The UCSPI tools in this version of the toolset can now provide 
these two to a dnscache process.  One simply chains through 
udp-socket-listen and tcp-socket-listen to dnscache, using the 
--systemd-compatibility flag.

The sharp-eyed will notice that the tinydns and dnscache services are 
following in the footsteps of the mariadb and mysql services, being 
instantiated for relevant IP addresses by the configuration import 
subsystem instead of being single-instance services.  It's not quite 
ready in this version, but you can see where things are headed.

svc -x
======

The -x option to service-control, a.k.a. svc, is no longer defunct. It 
does what unload-when-stopped does.

machineenv
==========

This was a little helper that was needed for running one particular Java 
program under nosh service management.  It's analogous to userenv, but 
instead of setting up environment variables from login information it 
sets up environment variables from machine information.

Improvements to service management
===================================

The system-control utility now respects a new "use_hangup" flag in 
service directories, as documented in service-manager's manual. This is 
used in the various getty@, agetty@, mgetty@, emergency-login@, and 
ttylogin@ service bundles, and causes system-control to attempt to bring 
down these services (at shutdown, for example) with SIGHUP, because some 
job control shells ignore SIGTERM and that delays shutdown.

Incidentally: There's now a family of pre-supplied agetty/mgetty/getty@ 
service bundles, set up for the various conventional serial terminal 
devices on OpenBSD, FreeBSD/PC-BSD, and Linux.  These are aliased from 
parallel ttylogin@ names, for consistent handling of /etc/ttys import 
and so forth.  They run a modem-aware getty, though; which of course the 
virtual terminal ttylogin@ services do not.  See the Terminals chapter 
of the nosh Guide.

Fixes for the per-user manager
==============================

The per-user manager, an instance of which you get when you run 
"system-control start user@${USER}" (or, more specifically, 
"system-control start user-services@${USER}"), is now more functional.  
The configuration importer sets you up with your own personal service 
bundle directory tree in ${HOME}/.config/service-bundles/ with a 
pre-supplied exit/ service bundle.  (Don't delete it! The per-user 
service manager needs to have a goal when it is signalled to terminate.)

Improvements to the console terminal emulator
=============================================

SoftTerm has a bugfix.  CUF and CUF no longer cause sideways scrolling.  
It also now understands some of the more esoteric control sequences from 
the old (pre-version 10) FreeBSD kernel terminal emulator, increasing 
the compatibility with programs that use the "cons25" terminal type.

The NetBSD terminal type for virtual terminals is now pcvtXX, and the 
OpenBSD one is pccon, per the 2015 termcap database.

There is also a minor fix in the SCO Console mode emulation.  All of the 
function key control sequences were off by one.  They are not, now.  (-:

BSD boot mode changes
=====================

* https://jdebp.eu./FGA/emergency-and-rescue-mode-bootstrap.html

I'd like to see FreeBSD and PC-BSD kernel loaders support the -b flag.  
In the meantime, for simple utility, I've changed the -s flag to invoke 
emergency mode rather than rescue mode, but only on FreeBSD/PC-BSD.

OpenBSD
=======

One of the servers providing the new WWW site is an OpenBSD machine, 
running the aforementioned modified versions of Bernstein tinydns and 
dnscache, and Bernstein publicfile, under nosh service management.  The 
nosh toolset now builds and runs on OpenBSD 5.9.

There are an awful lot of limitations to OpenBSD, from lack of realtime 
signals and nmount() to its older packaging tool.  Some of them are 
surmountable: I could write an nmount() shim function as I did for 
Linux, although for OpenBSD it would be a lot more complex. Some of 
them, like the lack of fexecve(), are not.  In concert, they preclude 
nosh as a system manager and packages with full automatic setup and 
teardown of basic system services.

But one can run the nosh service manager under OpenBSD rc; and 
everything else, from UCSPI servers to cron, under that.  I currently do.

I'm not particularly bothered about the package tool and the missing 
setup/teardown of the binary packages, myself.  I'm not running my 
system using installed binary packages in the first place.  I'm building 
from source, in true slashpackage style, into /package/admin/*/command/ 
and symbolically linking from /usr/local/bin/* to there.

The user-space virtual terminal system has not been tested on OpenBSD, 
and almost certainly doesn't quite work yet.  As mentioned earlier, the 
OpenBSD terminal type is set correctly by vc-get-tty. But 
console-terminal-emulator does not have an OpenBSD mode yet; 
console-fb-realizer doesn't really know how to use OpenBSD HID devices 
yet; and OpenBSD has the old 1980s-style pseudo-terminal management 
system instead of the "new" "UNIX98" 1990s one, which I have not 
tested.  At one point I was in a halfway-done position of having the 
nosh toolset's UCSPI tools but none of the service bundles.  So the 
toolset now has a tcpserver shim, that simply maps onto 
tcp-socket-listen, ucspi-socket-rules-check, and tcp-socket-accept.  It 
does not have the same defaults as the Bernstein tcpserver, though; and 
is in a separate binary package.

The cron mess
=============

OpenBSD has yet another not-quite-the-same version of cron, with yet 
another way to tell it not to uselessly fork.  So now there's an 
openbsd-cron service bundle alongside the debian-cron and vixiecron 
service bundles.  The cron alias is set up to point to the right one for 
the operating system.

debian-cron is the new name for the gnucron service bundle, by the way.  
"Debian/GNU Linux's prepackaged version" is what Ian Jackson originally 
called it in its README.  (Historical tidbit: Paul Vixie originally 
named his "PD cron".)  As far as I can tell, GNU cron was actually a 
project (by one Mike Meyer it appears) for the Free Software Foundation 
in 1987 that has entirely disappeared, if it ever existed in the first 
place.  In any case, "gnucron" is too generic a name for something that 
is at this point heading down the road of needing an individual service 
bundle for every single special flavour.  (Perhaps the Google Summer of 
Code people could add importing OpenBSD's cron's -n flag to FreeBSD cron 
to their list of ideas.  That would eliminate one special flavour and 
fix a deficiency at the same time.)

Thibault Godouet's fcron, Matt Dillon's/Jim Pryor's dcron, and Bruce 
Guenter's bcron don't need special treatment like this.

[toc] | [next] | [standalone]

#171074

On 7/08/2016 1:30 AM, Jonathan de Boyne Pollard wrote:

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?

[toc] | [prev] | [next] | [standalone]

#171347

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.

[toc] | [prev] | [next] | [standalone]

#171559

[Multipart message — attachments visible in raw view] — view raw

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"
>

[toc] | [prev] | [next] | [standalone]

#175359 — Re: nosh version 1.29

Bloody Thunderbird!  Here's that again, I hope without the surprise 
reformatting after pressing "send" this time:

The nosh package is now up to version 1.29.

* http://jdebp.eu./Softwares/nosh/
* 
https://www.freebsd.org/news/status/report-2015-07-2015-09.html#The-nosh-Project
* http://jdebp.info./Softwares/nosh/

There's been a lot going on since version 1.28 .

2016 leap second
----------------

The TAI to UTC conversions know about the forthcoming leap second.

service bundles
---------------

As usual, there are several new service bundles, from powerd++ through 
zfsd to fwknopd.  The new fs-servers target allows one to order the 
initialization of NFS servers before loop-to-self NFS mounts.  The new 
multi-user-pre target is another ordering target that allows services 
such as the motd file updater to be ordered before TTY login services.  
The instantiated kdm@tty7 and kdm@ttyv6 services have been replaced with 
a single kdm service, with a view to dealing with display managers 
better in the future.  I have some plans in this area.

The Samba service names have been fixed.  Debian calls them nmb, smb, 
and winbind; but the Samba doco and most places on the WWW call them 
nmbd, smbd, and winbindd.  The latter names are used in the service 
bundles package, with aliases pointing to them from the Debian names.

doco
----

The doco has been improved and kept up-to-date in various places, 
including correct descriptions of set-service-env and print-service-env 
after one confused user got in touch.  PC-BSD is now named as TrueOS 
where the reference is not historical.

code review
-----------

As a result of some code review that was offered, std::auto_ptr is now 
gone and a rare memory corruption bug in safe_execvp() has been fixed.  
Building from scratch when one doesn't have a prior daemontools or 
freedt toolset installed also no longer hits a bug.

configuration import improvements
---------------------------------

In an effort to clear those last few remaining items on the nosh 
roadmap, a whole load of configuration import (pppd, sppp, rfcomm_ppp, 
dhclient, wpa_supplicant, natd, and hostapd) has been consolidated under 
the umbrella of static-networking.  I plan to expand this further in 
1.31, given how much is already in 1.30.

Linux kernel VTs
----------------

Management of Linux kernel virtual terminals has some improvements, 
including setting UTF-8 canonical mode editing and keyboard composition 
modes, and emitting the control sequences that set up the screen saver.

tai64nlocal changes
-------------------

tai64nlocal has adopted a minor but important change from the BSD and 
GNU C libraries: before reading the start of a line it flushes its 
output.  This came from trying to use it as a co-process in GNU awk.  To 
prevent deadlocks, GNU awk co-processes need to be in what is 
effectively line buffered output mode even though their standard inputs 
and outputs are not terminal devices.  This is now the case for 
tai64nlocal and it can be used to convert TAI64N timestamps as a GNU awk 
co-process.

FreeBSD and TrueOS packaging
----------------------------

The largest change, however, is in the FreeBSD/TrueOS and OpenBSD packaging.

This is a change that is going to happen in the Debian packaging in a 
later version.  It's partly to simplify the package maintenance, and 
partly a step towards having OpenBSD packages that work.  A single 
package description is fed to both the new pkg tool that exists on 
FreeBSD/TrueOS and the old pkg tool that exists on OpenBSD.  It's not 
perfect, as there are things that are easy with the new pkg tool that 
are hard with the old one; and the OpenBSD packages are still not fully 
functional.  But things are better than they were.  The OpenBSD service 
bundles package now almost properly sets up per-service user accounts 
and log directories, for example.

=======================================================================
===========  IMPORTANT UPGRADE NOTE FOR FreeBSD/TrueOS: ===============
=======================================================================

An important consequence of the aforementioned is that the semantics of 
the nosh-bundles package have changed.  In earlier versions, the various 
nosh-run-* packages were how one set services running, except for a 
small rump set of services that were set up by the nosh-bundles 
package.  This is now no longer the case.  The nosh-bundles package now 
presets and starts no services at all. *All* running of services must be 
achieved with the nosh-run-* packages or some other sets of scripts and 
presets.

To this end, there are now two new packages, 
nosh-run-freebsd-desktop-base and nosh-run-freebsd-server-base. These 
parallel the already existing nosh-run-trueos-desktop-base and 
nosh-run-trueos-server-base packages; except that they do not start any 
of the services that exist in TrueOS but do not exist in FreeBSD, such 
as the various pc-* services.

You must install, for a working fully-nosh-managed system, exactly one 
of these four packages.  If you are running nosh service management 
under Mewburn rc, you can of course run as many or as few services under 
the nosh service manager as you care to switch over from Mewburn rc.  
But if you are running a fully-nosh-managed system these packages will 
arrange to run the various fundamentals that one pretty much cannot do 
without, such as mounting/unmounting volumes, running devd and ldconfig, 
and initializing the PRNG.

[toc] | [prev] | [next] | [standalone]

#175360 — nosh version 1.29

The nosh package is now up to version 1.29. * 
http://jdebp.eu./Softwares/nosh/ * 
https://www.freebsd.org/news/status/report-2015-07-2015-09.html#The-nosh-Project 
* http://jdebp.info./Softwares/nosh/ There's been a lot going on since 
version 1.28 . 2016 leap second ---------------- The TAI to UTC 
conversions know about the forthcoming leap second. service bundles 
--------------- As usual, there are several new service bundles, from 
powerd++ through zfsd to fwknopd. The new fs-servers target allows one 
to order the initialization of NFS servers before loop-to-self NFS 
mounts. The new multi-user-pre target is another ordering target that 
allows services such as the motd file updater to be ordered before TTY 
login services. The instantiated kdm@tty7 and kdm@ttyv6 services have 
been replaced with a single kdm service, with a view to dealing with 
display managers better in the future. I have some plans in this area. 
The Samba service names have been fixed. Debian calls them nmb, smb, and 
winbind; but the Samba doco and most places on the WWW call them nmbd, 
smbd, and winbindd. The latter names are used in the service bundles 
package, with aliases pointing to them from the Debian names. doco ---- 
The doco has been improved and kept up-to-date in various places, 
including correct descriptions of set-service-env and print-service-env 
after one confused user got in touch. PC-BSD is now named as TrueOS 
where the reference is not historical. code review ----------- As a 
result of some code review that was offered, std::auto_ptr is now gone 
and a rare memory corruption bug in safe_execvp() has been fixed. 
Building from scratch when one doesn't have a prior daemontools or 
freedt toolset installed also no longer hits a bug. configuration import 
improvements --------------------------------- In an effort to clear 
those last few remaining items on the nosh roadmap, a whole load of 
configuration import (pppd, sppp, rfcomm_ppp, dhclient, wpa_supplicant, 
natd, and hostapd) has been consolidated under the umbrella of 
static-networking. I plan to expand this further in 1.31, given how much 
is already in 1.30. Linux kernel VTs ---------------- Management of 
Linux kernel virtual terminals has some improvements, including setting 
UTF-8 canonical mode editing and keyboard composition modes, and 
emitting the control sequences that set up the screen saver. tai64nlocal 
changes ------------------- tai64nlocal has adopted a minor but 
important change from the BSD and GNU C libraries: before reading the 
start of a line it flushes its output. This came from trying to use it 
as a co-process in GNU awk. To prevent deadlocks, GNU awk co-processes 
need to be in what is effectively line buffered output mode even though 
their standard inputs and outputs are not terminal devices. This is now 
the case for tai64nlocal and it can be used to convert TAI64N timestamps 
as a GNU awk co-process. FreeBSD and TrueOS packaging 
---------------------------- The largest change, however, is in the 
FreeBSD/TrueOS and OpenBSD packaging. This is a change that is going to 
happen in the Debian packaging in a later version. It's partly to 
simplify the package maintenance, and partly a step towards having 
OpenBSD packages that work. A single package description is fed to both 
the new pkg tool that exists on FreeBSD/TrueOS and the old pkg tool that 
exists on OpenBSD. It's not perfect, as there are things that are easy 
with the new pkg tool that are hard with the old one; and the OpenBSD 
packages are still not fully functional. But things are better than they 
were. The OpenBSD service bundles package now almost properly sets up 
per-service user accounts and log directories, for example. 
======================================================================= 
=========== IMPORTANT UPGRADE NOTE FOR FreeBSD/TrueOS: =============== 
======================================================================= 
An important consequence of the aforementioned is that the semantics of 
the nosh-bundles package have changed. In earlier versions, the various 
nosh-run-* packages were how one set services running, except for a 
small rump set of services that were set up by the nosh-bundles package. 
This is now no longer the case. The nosh-bundles package now presets and 
starts no services at all. *All* running of services must be achieved 
with the nosh-run-* packages or some other sets of scripts and presets. 
To this end, there are now two new packages, 
nosh-run-freebsd-desktop-base and nosh-run-freebsd-server-base. These 
parallel the already existing nosh-run-trueos-desktop-base and 
nosh-run-trueos-server-base packages; except that they do not start any 
of the services that exist in TrueOS but do not exist in FreeBSD, such 
as the various pc-* services. You must install, for a working 
fully-nosh-managed system, exactly one of these four packages. If you 
are running nosh service management under Mewburn rc, you can of course 
run as many or as few services under the nosh service manager as you 
care to switch over from Mewburn rc. But if you are running a 
fully-nosh-managed system these packages will arrange to run the various 
fundamentals that one pretty much cannot do without, such as 
mounting/unmounting volumes, running devd and ldconfig, and initializing 
the PRNG.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web