Pre-built binary packages for nosh are available for x86/64 OpenBSD version 5.9 (or compatible).
You can view a list of the packages in the repository via GOPHER or via FTP in EPLF.
This is the nosh Guide, in HTML. Open it when installed with
or your favourite HTML viewing tool.xdg-open /usr/local/share/doc/nosh/index.html
nosh, and the chain-loading utilities)
service-controland related utilities)
ttylogin-starterand related utilities)
ptyrunand related utilities) Important notes on limitations
nosh-zsh-completion-1.37.tgz(Z Shell completions for the toolsets)
servicectlshims for systemd compatibility)
chkconfig, and related shims for old-style System 5/BSD compatibility)
initctl, and related shims for upstart compatibility)
serviceshim for old-style System 5/BSD compatibility)
update-rc.dshims for Debian compatibility)
utxand and related shims for FreeBSD compatibility)
chvtshims for compatibility with the old Linux kbd package)
These install the toolsets under
However, to avert a problem that otherwise makes systems unbootable, they also install a handful of binaries in
This is a suite of service bundles. It comprises:
/etc/service-bundles/targets/, including the
poweroff, and other standard system targets.
ttylogin@tty6(Important notes on limitations);
This is an extensive service bundle collection.
There are a lot of service bundles here, including services that conflict (e.g.
exim4-smtp-relay) and services that you probably will not have (e.g.
/etc/system-control/presets. So, for example, to have
exim4-smtp-relayautomatically enabled, include
enable exim4-smtp-relay.socketin your preset configuration files.
Installation will not actually start any services. Deinstallation does not disable or stop services. Installation and uninstallation of other "-run" packages, reliant upon this one, does that.
In an ideal world, the world would ship nosh bundles with its softwares itself, of course. ☺
The "-run" family of packages require the service bundle collection. They employ services in it; which are not started or enabled unless the packages are installed; and which are stopped, disabled, and unloaded from the service manager when the packages are uninstalled.
system-manageras process #1
nosh-run-kernel-vt-1.37.tgz(old-style kernel virtual terminals)
nosh-run-user-vt-1.37.tgz(a new-style application-mode virtual terminal) Important notes on limitations
The old-style kernel virtual terminal system auto-starts a
ttylogin@ttyCN service on each kernel virtual terminal at startup, as configured by
The new-style application-mode virtual terminal auto-starts a
console-fb-realizer@head0 service; the "realizer" service that realizes the multiplex VTs via the (head #0) framebuffer and input event devices.
This connects to the user-mode virtual terminal that is supplied by
console-multiplexor@head0; which in turn multiplexes the user-mode virtual terminals generated by the
terminal-emulator@vc2 services; whose emulated virtual terminals in their turn are employed by the
The realizer service tells the kernel to disable its built-in terminal emulator program for the duration.
These systems conflict. The head #0 framebuffer and input event device are used by the kernel's virtual terminal emulator. One cannot (without a massive mess of overlapped output and input going to two separate places) realize application-mode virtual terminals onto head #0 whilst simultaneously realizing kernel virtual terminals on the same hardware. So you must only install one of these packages at any one time. The BSD package manager does not provide an easy means of enforcing this, unfortunately.
This package auto-starts the Freedesktop.org system bus services.
nosh-run-freedesktop-kits-1.37.tgz(Freedesktop.org "kit" services — policykit, NetworkManager, et al.)
This package auto-starts the various Freedesktop.org "kit" services.
Avoid Desktop Bus bus activation.
This package auto-starts the various services that form the VirtualBox Guest Additions: the
VBoxService dæmon and the four "vbox" kernel modules.
This package runs the
klogd service, providing logging service to the kernel.
This package runs the
local-syslog-read service, providing old-style logging service to programs that still use
This installs various
rc.d scripts for running allowing one to use the nosh service management under OpenBSD
It also disables the nosh
sysinit standard target, on the basis that
rc handles what that target otherwise handles on a nosh-system-managed system.
Thus, installing this package will break a nosh-system-managed system.
OpenBSD has several limitations that severely impact nosh.
system-manager uses the filesystem-neutral API
nmount() for mounting the "API" filesystems such as
/dev at system bootstrap.
As such, a fully-nosh-managed system, where
system-manager is process #1 with complete system management available, is not yet possible.
OpenBSD does not have POSIX realtime signals.
system-manager and acompanying
system-control require the use of 10 realtime signals, including for signalling state changes for halt and poweroff amongst other things.
As such, a fully-nosh-managed system, where
system-manager is process #1 with complete system management available, is not possible.
OpenBSD does not have the dynamic pseudo-terminal allocation system introduced in the 1990s.
On OpenBSD, pseudo-terminal master and slave devices are still statically named in
nosh terminal management was designed for systems that implemented the "new" dynamically-naming pseudo-terminal allocation system that arrived in the 1990s, and that can be found in FreeBSD, TrueOS, and Linux.
It may or may not work with the old 1980s system.
nosh service management and chain loading uses file-descriptor-relative versions of many POSIX APIs whereever possible.
It does this in order to avoid well-known security holes where paths are resolved twice or more and attackers can slip in
rename()s or links in between steps.
OpenBSD lacks some of them, such as this one.
On OpenBSD, the toolset has to rely upon
execve() and pathnames.
OpenBSD does not have pkgng. It has its predecessor. pkgng has an easy-to-manage system of running pre-/post- installation/deinstallation scripts. Its predecessor has a less easy to set up system. The nosh package's build system is geared towards the pre/post-install/deinstall paradigm, because that's what package management on Debian Linux, FreeBSD, and TrueOS provide.
Also note that the framebuffer realizer for console virtual terminals has yet to be tested.