nosh version 1.22
The nosh package is now up to version 1.22 .
* http://homepage.ntlworld.com./jonathan.deboynepollard/Softwares/nosh.html
*
https://www.freebsd.org/news/status/report-2015-07-2015-09.html#The-nosh-Project
There are several things in this release:
* a new binary package for FreeBSD
* improvements to the user-mode virtual terminal subsystem
* changes and additions to UCSPI tools
* log export to remote servers
* kqueue on Linux
* miscellany
a new binary package for FreeBSD
--------------------------------
There's now a debian-shims binary package for FreeBSD. This contains the
heretofore not packaged invoke-rc.d and update-rc.d shim programs. I
decided to make this separate from the systemv-shims package because
these areless general-purpose than those shims are.
The haltsys, fasthalt, fastpoweroff, and fastboot shims are now
packaged, also.
improvements to the user-mode virtual terminal subsystem
--------------------------------------------------------
The console-fb-realizer now displays a mouse pointer sprite on the
display, to reflect the position of the mouse, when an application has
turned it on with the relevant control sequences. Mouse support via the
evdev input subsystem on Linux is thus now fully implemented, including
support for tablets that use absolute rather than relative positioning.
On the FreeBSD side, you can use sysmouse devices. But this only
permits relative positioning. This is a limitation of sysmouse itself,
as far as I can see. A lot has to change, including the kernel, the
protocol, and moused, to enable absolute positioned devices via
sysmouse. Absolute positioning devices will therefore be supported using
uhid devices. Some of that is done already, but it's not complete yet.
Keyboard maps are now generated by the external configuration import
subsystem from whatever one has in /usr/share/vt/keymaps , rather than
being hardwired to a fixed set of countries. In the absence of this
directory (as will usually be the case on Linux operating systems),
fallback U.S.A. and U.K. keyboard maps are generated.
This generation is worthy of note, as it exemplifies the mechanism that
allows multiple BSD keyboard maps to be overlaid to make one generated
map. The fallback U.K. keyboard map is generated by taking the built-in
U.S.A. keyboard map and applying a "us_to_uk" overlay map on top of it
that only has the few differences between the U.S.A. International
layout and the U.K. one. (This currently produces the basic U.K.
layout. "U.K. Extended" should be a simple matter of another overlay
that does the various Option+A -> a-acute mappings, but that's
somethingfor the future.) Similarly, versions of existing maps that
swap Caps Lock and Control are generated by adding a simple overlay that
does solely that. Likewise, generated maps have an overlay applied that
sets the Backspace key to the application-programmable DEC VT behaviour
that console-terminal-emulator supports, that out-of-the-box BSD keymaps
don't know anything about.
changes and additions to UCSPI tools
------------------------------------
For consistency, the UCSPI tools that supported a single --numeric
option now support --numeric-host and --numeric-port options, for
separately determining whether hosts and ports are taken to be names or
just numbers.
There are now client-side tcp-socket-connect and udp-socket-connect
tools, that open client sockets, connect them to servers, and then
chain. These adhere to the UCSPI conventions for inherited open file
descriptors in client-side tools.
log export to remote servers
----------------------------
The new UCSPI clients were motivated by the new export-to-rsyslog
command. This is a daemon that expects to be invoked as a UCSPI client,
connected to a remote RFC 5424/RFC 5426 ("rsyslog") server. It
maintains a set of "log cursors" that point to daemontools-stylelog
directories. Tracking its position in the logs using those cursors, it
sends new log information to the connected server. In the usual nosh
fashion, the filesystem is the database, and the "cursors" are just
files and symbolic links. The details are on the manual page.
In conjunction with the UCSPI clients, export-to-rsyslog thus makes a
log remote export service.
This isn't intended to be the last word in such things. RFC 5426is
unreliable, and RFC 5424 loses the microsecond and nanosecond
information of TAI64N. But it demonstrates the idea and shows that this
can be done in the daemontools world. One can indeed export
daemontools-stylelogsif one has (say) a suite of servers whose log data
should be copied over, on the fly, to a centralized rsyslog server.
There's room here for someone to take this idea and run further with it
using something like RELP.
miscellany
----------
The several miscellaneous items include OpenLDAP services in the
autoconfiguration subsystem and some tweaks to the /etc/fstab conversion
on Linux to deal with records that don't explicitly say either
read-write or read-only, resulting in undocumented behaviour in the
Linux fstab parsing library.
On the subject of working around the behaviours of Linux libraries ...
libkqueue
---------
Those familiar with the development will know that Linux's libkqueue has
been a perennial difficulty. Its inaccessible private internal file
descriptors are not marked close-on-exec, leaving open a security hole
if libkqueue is used in a privileged process that forks off unprivileged
children to run other programs. NOTE_WRITE for EVFILT_VNODE isn't
implemented correctly for directories. And itbreaks when inotify events
come through that have filenames in them. Those familiar with the code
will know that there was quite a lot of conditional compilation as a
consequence, replacing libkqueue with individual hand-rolled mechanisms
in those programs where libkqueue simply doesn't work or creates
security weaknesses. The final straw was a user reporting
service-dt-scanner abending on Gentoo Linux when the scan directory is
merely listed with "ls", which we eventually tracked down to libkqueue bugs.
No more.
I tried the route of patching libkqueue. It was my preferred route.
It's fairly easy to see where to add in the close-on-exec flags, for
example. The difficulty is in getting such things available both to
users using Debian binary packages (on all of its various
"stable"/"oldstable" flavours) and to users building from source on
distributions that I don't have myself. In the end I took a step back
and pondered whether libkqueue was even the right thing to be using in
the first place. After all, it's built to select from a multiplicity of
implementations for several operating systems, using an internal
abstraction layer,where the nosh toolset is only in fact ever using it
for one.
So there's now an internal C++ kqueue/kevent library for Linux in the
toolset, not ideal but "good enough" for the use that the nosh toolset
needs from kqueue/kevent and doing the various things that it needs like
close-on-exec, inotify with filenames and multiple events in one go, and
proper NOTE_WRITE for directories; and the conditional code, the
individual hand-rolled mechanisms (apart from one), and the binary
package dependenciesfrom libkqueue are now gone.
Reply to: