As an augmentation to, or a complete replacement for, kernel virtual terminals, this package also allows you to set up user-space virtual terminals. A user-space virtual terminal comprises four things:
a pseudo-terminal
a TUI login service that has the pseudo-terminal as its controlling terminal
a console-terminal-emulator process, that conects the pseudo-terminal to a display buffer and an input FIFO
one or more realizer processes, that connect the display buffer and input FIFO to real I/O devices of some kind
In a plain system, the TUI login service, the terminal emulator process, and the realizer process all run as ordinary services.
This package comes with service bundles for running three user-space virtual terminal emulators (vc1
, vc2
, and vc3
), multiplexed onto a single realizer (head0
) through a multiplexor.
In a containerized system, the TUI login services and the terminal emulation services run in the container.
The realizer and console multiplexor services, conversely, run outwith the container.
One simply directs the (external) console multiplexor service to include the contained user-space virtual terminal devices, alongside any that it already has.
With the console-multiplexor@head0
service bundle that comes in this package, simply symbolically link the contained user-space virtual terminal directories into the multiplexor's service directory before starting it.
This is nothing more than an instance of the general-case procedure for adding another user-space virtual terminal to a multiplexor service.
ln -s /var/container/run/dev/vc1 /var/sv/console-multiplexor@head0/service/vc9 ln -s /var/container/run/dev/vc2 /var/sv/console-multiplexor@head0/service/vc10 ln -s /var/container/run/dev/vc3 /var/sv/console-multiplexor@head0/service/vc11
Each user-space virtual terminal has one service, running console-terminal-emulator
.
This duplicates the function of the old-style kernel terminal emulator code, but as an application-mode process outwith the kernel.
It is explicitly not an emulator for any model of real terminal.
Its function is to correctly cope with the outputs of programs that are using (according to operating system) the linux
, wsvt25
, or xterm
entries in the termcap/terminfo databases; those being the entries that are used for kernel terminal emulators.
In other words, one should be able to switch from a kernel virtual terminal to a user-space virtual terminal without changing the terminal type used in the ttylogin service.
It is the terminal emulator service that creates the tty
device file, and so the terminal emulator service must start before any TUI login service for that terminal does.
A console-terminal-emulator@1.service
must be ordered before its corresponding ttylogin@1.service
in the startup sequence with an appropriate symbolic link in the latter's service bundle's after/
directory, for example.
Terminal emulator services do not require superuser privileges at any stage; and for best security should be run under the aegis of an unprivileged account dedicated to the service(s).
The relationship between realizers and terminals is many-to-many. A realizer may be a simple realizer, that handles just one user-space virtual terminal. Or it may be a complex realizer that handles multiple user-space virtual terminals, multiplexing their displays onto its output device, and allowing the user to switch amongst virtual terminals with a hotkey sequence, or a mouse action of some kind. One can also attach multiple display-only realizers to a single user-space virtual terminal with no ill-effects. All realizers will operate concurrently.
The lifetimes of realizers do not affect the lifetimes of the associated virtual terminals. One can detach all realizers from a user-space virtual terminal, and it will continue operating, its output stored in its display buffer file, unaffected. This differentiates user-space virtual terminals from, say, X Window System terminal programs, which signal hangup to the session leader programs running in the terminal when rendering is commanded to close its window.
Realizers only require access to the files of the user-space virtual terminals that they are attached to, and to the various I/O devices that they are realizing the virtual terminal with. The exact security model depends from the kind of realizer, and there are many possible kinds; one could have:
console-ncurses-realizer
—
a realizer that uses wide character ncurses (ncursesw) to render one user-space virtual terminal on the console that the realizer itself is attached to.
This realizer needs no additional privileged access to anything apart from the files of the user-space virtual terminal.
console-fb-realizer
—
a realizer that uses a framebuffer device, and mouse and keyboard input devices, realizing one user-space virtual terminals.
This realizer needs additional privileged access to the device files, in order to open them at startup, but needs no more privileges than that.
a realizer that realizes multiple user-space virtual terminals using X Window System windows, and allowing one to switch amongst them using hotkeys and mouse actions. This realizer initially needs no additional privileged access.
a realizer that realizes one user-space virtual terminal on a Braille device. This realizer initially needs additional privileged access to the Braille device file, in order to open it, but can drop privileges afterwards.