descriptionarchnosh framagit.org mirror
repository URLhttp://framagit.org/taca/archnosh.git
ownertaca@kadisius.eu
last changeSun, 9 Jul 2017 23:36:45 +0000 (10 01:36 +0200)
last refreshTue, 22 Aug 2017 19:36:37 +0000 (22 21:36 +0200)
content tags
add:
README.md

Archnosh is nosh for Archlinux

This repository provides the build files necessary to integrate the nosh system and service manager with Archlinux package management.

The packaging here closely follows the Debian packaging provided by the author of nosh.

How do I use it?

With caution! Installing some of the nosh packages provided here can profoundly change the way your system bootstraps and runs services.

Furthermore, the packages have so far been tested locally on virtual machines with minimum installs of early 2017 Archlinux releases and on a personal laptop, where they do work for the most part but tailoring to your system will be necessary.

Caveat emptor.

The packages

This is a split-package PKGBUILD which will generate packages covering the toolset aswell as a service bundle collection which together can provide a complete working system.

Use the latest available released archive, i.e. the latest tagged git commit.

Dependencies

The make dependencies are the following and require AUR access to be set up:

For package building in general, ensure the base-devel package is installed.

Build the packages

Put the files in a directory and run:

$ makepkg

You can then install the generated packages with:

# pacman -U <package-name>

Running nosh

Read the timorous admin's installation how-to.

The following describes the two expected common setups.

Both assume that you are running the default systemd-managed install.

nosh service manager only: nosh-run-via-systemd

It is possible to run nosh as a service manager alongside systemd.

The following packages are necessary:

Due to Archlinux's default preset disable policy (/usr/lib/systemd/system-preset/99-default.preset), you need to enable the following unit:

# systemctl enable service-manager.socket

Then you should enable one or both of:

system-control-normal.service uses nosh targets to bring up enabled services. Simply run system-control enable <service> and systemctl disable <service> for its equivalent in order to switch management of the service over to nosh.

service-manager-svscan.path will scan and bring up any service bundle you place in the /service directory (which you will have to create), effectively enabling it. This is the more typical daemontools approach.

It's probably simpler to stick to just one of these methods.

Creating preset files for these units will also ensure their enabled/disabled status in case of package upgrades.

Also make sure to check the presets provided by the chosen nosh-run-debian-X-base package, they will activate some services by default.

nosh system and service manager: nosh-run-system-manager

For a fully nosh-managed system, i.e. nosh running as the init process and service manager, install the following packages:

Installing these packages will raise a lot of the following errors:

reset: ERROR: connect: /run/service-manager/control: No such file or directory

This is due to the fact that nosh isn't actually properly running yet but is not an issue. The system will work properly after a reboot (system-control reboot).

systemd-udev

The installation above assumes udev is the device manager, which is provided by the systemd package on Archlinux.

The easiest method is to simply use the binaries and configuration files provided by this package to run udev. The nosh-run-systemd-udev package will do just that and everything should work transparently. This means all udev configuration rules already set up should work as-is.

eudev

Alternatively you may wish to use the eudev implementation rather than keeping the systemd package for udev functionality.

We will detail the installation of eudev, libeudev, eudev-systemd and libeudev-systemd (available from the AUR) which should provide a drop-in replacement for systemd/udev.

  1. Install libeudev

    This conflicts with the libsystemd package, you should remove it but it will almost certainly be a dependency for other packages on your system so run:

    # pacman -dd -S libeudev
    

    The -d (or --nodeps) repeated option skips dependency checking. You will be providing replacements for these dependencies.

    It might also fail to install due to the following pre-existing files: /usr/include/libudev.h and /usr/lib/pkgconfig/libudev.pc. Remove these manually.

  2. Install libeudev-systemd

    This will provide the libsystemd.so libraries.

  3. Install eudev

    This conflicts with the systemd package and, again, will doubtless bring up many dependency warnings so run:

    # pacman -dd -S eudev
    
  4. Install eudev-systemd

    This will provide some shim systemd binaries and libraries.

The nosh-run-udev package will run the udevd binary, provided by eudev here.

From there you will have a working udev and some systemd shims which should allow installing most packages without too much trouble.

Run-packages for other device managers are provided: vdev, busybox-mdev and suckless-mdev. You will probably need to account for Archlinux's rather heavy systemd/udev integration in order to use them.

base presets

The nosh-run-debian-X-base packages have not currently been renamed but one of them must be used.

They provide essential presets for booting your system. The "desktop-base" extends the "server-base" presets.

Make sure to check and modify your preset files where necessary in /usr/share/system-control/presets.

per-user service management

For user-controlled services, a per-user manager can be enabled for user my_user with:

# system-control enable user@my_user

This will start per-user service management for my_user on system boot.

User service bundles can be placed under $HOME/.config/service-bundles/services/ and controlled with:

$ system-control --user <command>
networking

Service bundles are available for various network managers, such as Wicd and NetworkManager.

A dhcpcd@ service (the default enabled tool for wired devices on Archlinux) is generated for each interface and is preset enabled by 90-linux-static-networking.preset.

To activate it, add the following lines in /etc/rc.conf or /etc/rc.conf.local:

dhclient_program=dhcpcd
ifconfig_<your-interface>=DHCP

Don't forget to run redo all after applying configuration changes. Check /etc/system-control/convert/static-networking to make sure your interface is set to on.

non-root Xorg

Since we are not using systemd's logind, starting X as an unpriviledged user requires adding that user to the "input" and "video" groups.

See https://wiki.gentoo.org/wiki/Non_root_Xorg for further details.

elogind might conceivably be used to achieve systemd behaviour here.

shims

Various "shim" packages exist to provide the following:

  1. Commands from other service or system managers that will invoke the corresponding nosh management actions, e.g. nosh-debian-shims, nosh-systemd-shims, nosh-upstart-shims, etc.

  2. Utilities which may be provided by other packages, e.g. nosh-execline-shims, nosh-ucspi-tcp-shims, nosh-kbd-shims, etc.

virtual terminals

Rather than kernel virtual terminals, user-space virtual terminals may be used by installing nosh-run-user-vt.

The nosh-execline-shims package is necessary if you do not have execline available.

troubleshooting and exceptional boot modes

https://jdebp.eu/Softwares/nosh/guide/troubleshooting.html

The link above may come in useful.

In certain cases your system may need to be booted in an exceptional mode.

Some nosh guidelines

The online nosh guide, also available in the nosh-guide package, and command manpages provide comprehensive documentation.

The nosh toolset follows general daemontools design which includes:

To these features nosh adds:

For a general presentation you may read the following:

https://jdebp.eu/Softwares/nosh/guide/introduction.html

Service bundles

A standard bundle will look something like this:

/var/sv $ tree kamailio
kamailio
├── after
│   ├── basic -> /etc/service-bundles/targets/basic
│   └── log -> ../log
├── before
│   └── shutdown -> /etc/service-bundles/targets/shutdown
├── conflicts
├── log -> ../cyclog@kamailio
├── required-by
├── service
│   ├── env
│   ├── restart
│   ├── run
│   ├── start
│   └── stop
├── stopped-by
│   └── shutdown -> /etc/service-bundles/targets/shutdown
├── supervise
│   ├── control
│   ├── lock
│   ├── ok
│   └── status
├── wanted-by
│   └── server -> /etc/service-bundles/targets/server
└── wants
    └── basic -> /etc/service-bundles/targets/basic

The before and after directories allow for linking to other service bundles to set ordering constraints.

The conflicts, required-by, stopped-by, wanted-by and wants directories allow for linking to other service bundles to set dependency constraints.

The log directory points to a logging service.

The service directory contains the scripts used to run the service. service/env can be used to store configuration information.

The supervise directory contains the control/status API files.

logging

Logging is a service on par with any other. In general one logging service is associated with each daemon to capture and manage its output (log rotation, capping etc.) although fan-in from multiple services to one logging service is also possible.

The daemontools assumption is that daemons log to their standard error, not to syslog. Specialised logging tools can then be used to manage this output.

More generally, daemons are expected not to implement functions such as dropping priviledges, socket management, resource limiting, etc. which could be provided by external tools, typically the daemontools family toolsets and other service managers (see the same argument for systemd's "new-style" daemons).

In practice, nosh connects a service's standard output and error to the service pointed to by the "log" directory of the service bundle. Below are some excerpts of the lsof command to illustrate:

COMMAND   PID     USER   FD      TYPE             DEVICE SIZE/OFF   NODE NAME

# the sshd service, file descriptors 1 and 2 refer to pipe 17119
tcp-socke 976     root  cwd       DIR              254,0     4096 198091 /var/sv/sshd/service
tcp-socke 976     root  txt       REG              254,0   212968  62095 /usr/bin/tcp-socket-accept
tcp-socke 976     root    0r     FIFO               0,10      0t0  17188 pipe
tcp-socke 976     root    1w     FIFO               0,10      0t0  17119 pipe
tcp-socke 976     root    2w     FIFO               0,10      0t0  17119 pipe

# the cyclog@sshd service, file descriptor 0 refers to pipe 17119: reading sshd's stdout and stderr
cyclog    963 sshd-log  txt       REG              254,0   212968  63713 /usr/bin/cyclog
cyclog    963 sshd-log    0r     FIFO               0,10      0t0  17119 pipe
cyclog    963 sshd-log    1w     FIFO               0,10      0t0   8409 pipe
cyclog    963 sshd-log    2w     FIFO               0,10      0t0   8409 pipe
cyclog    963 sshd-log    6w      REG              254,0        0 202749 /var/log/sv/sshd/current

# note that cyclog@sshd's own stdout and stderr point to pipe 8409 which is actually the system-wide logger's input
cyclog    163     root  txt       REG              254,0   130984  63711 /usr/bin/system-manager
cyclog    163     root    0r     FIFO               0,10      0t0   8409 pipe
cyclog    163     root    1u      CHR                5,1      0t0   6547 /dev/console (deleted)
cyclog    163     root    2u      CHR                5,1      0t0   6547 /dev/console (deleted)
cyclog    163     root    5w      REG               0,18    81718   8433 /run/system-manager/log/current

# ... just as init's own stdout and stderr also point to the system-wide cyclog
init        1     root  txt       REG              254,0   130984  63711 /usr/bin/system-manager
init        1     root    0r      CHR                1,3      0t0   6465 /dev/null
init        1     root    1w     FIFO               0,10      0t0   8409 pipe
init        1     root    2w     FIFO               0,10      0t0   8409 pipe

The "log" directory name is a bit misleading insofar as one could chain anything to the service and create an arbitrarily long pipe chain. That being said, service run files already use chain-loading mechanisms so it generally really is a logging service that is ultimately piped to.

system-control

system-control is the system workhorse command from a user perspective.

It provides high-level system-wide and per-user service management (start/stop, enable/disable etc.) aswell as system management (reboot, poweroff etc.) and various other specialised commands for e.g. converting systemd-style unit files to service bundles.

Converting systemd unit files

system-control convert-systemd-units <unit-file> supports conversion for various types of systemd unit files to service bundles.

It also understands extended syntax to express service bundle-specific functionality in a systemd-like unit file, which can be used for easy distribution for example.

In other words, one can benefit from existing systemd unit files through automatic conversion in many cases.

Repositories

This repository is publicly available at the following locations:

  1. https://framagit.org/taca/archnosh
  2. https://repo.or.cz/archnosh.git
  3. https://github.com/tacatac/archnosh

License

These packaging configuration files are distributed under the public domain Unlicense, see the UNLICENSE file provided.

The nosh software, however, is distributed under BSD/BSD-compatible licensing.

shortlog
2017-07-09 tacaUpdated READMEmaster
2017-07-06 tacaMerge branch 'next'v1.34-1
2017-07-06 tacaUpdate to 1.34 release
2017-07-06 tacaUpdated README for DHCP config
2017-07-06 tacaUpdated changelog
2017-06-16 tacaUpdated README.
2017-05-03 tacaAdded package changelog
2017-05-03 tacaAdded logging section to documentation and further...
2017-04-21 tacaUpdated documentation for split udev and networking
2017-04-20 tacaUpdated checksum for latest 1.34 and fixed removed...
2017-04-20 tacaAdded nosh-run-systemd-udev package
2017-04-20 tacaDependency information updatedv1.33-3
2017-04-17 tacaChanged package release version -> 2v1.33-2
2017-04-17 tacaFixed maintenance.sh for nosh-run-system-manager.instal...
2017-04-17 tacaFixed error in maintenance.sh
2017-04-17 tacaUpdated latest 1.34 checksums
...
tags
6 weeks ago v1.34-1
4 months ago v1.33-3
4 months ago v1.33-2
4 months ago v1.33-1
heads
6 weeks ago master