Date: Mon, 2 Nov 2015 02:15:55 +0000 From: Jonathan de Boyne Pollard <J.deBoynePollard-newsgroups@NTLWorld.com> To: supervision@list.skarnet.org, FreeBSD Hackers <freebsd-hackers@freebsd.org>, debian-user@lists.debian.org Subject: nosh version 1.22 Message-ID: <5636C75B.70000@NTLWorld.com> In-Reply-To: <56120D11.4080506@NTLWorld.com> References: <54430B41.3010301@NTLWorld.com> <54B86FD5.3090203@NTLWorld.com> <554E53EF.4080600@NTLWorld.com> <554E93AF.3070709@NTLWorld.com> <556BA130.50708@NTLWorld.com> <55902328.8080602@NTLWorld.com> <55D5CFA2.5010402@NTLWorld.com> <55D8B9AC.6010209@NTLWorld.com> <CADQ2Nw-506S3Gm4s40t%2BWzJu3Wzpwp=wPBWCFoQGZ2yrctCM_w@mail.gmail.com> <56089268.6080007@NTLWorld.com> <56120D11.4080506@NTLWorld.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5636C75B.70000>