This package contains tools for running and managing TUI login services on both kernel and user-space virtual terminals. It also contains pre-written service bundles for such TUI login services.
run scripts look like
The run scripts are interpreted by nosh and are created from a template with the terminal name hardwired.
A run script to provide TUI login on kernel virtual terminal /dev/ttyv4 would be something like this:
#!/bin/nosh clearenv # what ttymon(1M) did vc-get-terminal ttyv4 setsid open-controlling-terminal --revoke vc-reset-terminal --hard-reset # what login(1M) did login-envuidgid --tui-level ascii local-reaper yes login-giveown-controlling-terminal setuidgid-fromenv userenv-fromenv --default-path --default-tools --default-term --default-timezone --default-locale --set-dbus --set-xdg --set-other chdir-home login-shell
A run script for a service to provide TUI login on user-space virtual terminal /run/dev/vc1 would be something like:
#!/bin/nosh clearenv # what ttymon(1M) did vc-get-terminal vc1/tty setsid open-controlling-terminal # what login(1M) did login-envuidgid local-reaper yes login-giveown-controlling-terminal setuidgid-fromenv userenv-fromenv --default-path --default-tools --default-term --default-timezone --default-locale --set-dbus --set-xdg --set-other chdir-home login-shell
run scripts are recomposable and these chains are an example of that.
One can adjust the behaviour of the service to suit particular needs by altering the tool chain or particular tool options.
getty is history, once again.
The use of getty in terminal login has been obsolete since 1988, when one of the earliest service management systems for Unix superseded it with its own mechanisms.
That is likewise the case here.
Login services for virtual terminals do not need getty programs, of any flavour; everything remaining that they need being provided by the service management system itself.
What the 1980s Service Access Facility's sac and ttymon provided by their service management system, are similarly provided by this service management system and chain-loading toolkit as follows:
service-manager handles restarting the service after logout.
vc-get-terminal sets the TERM environment variable.
open-controlling-terminal opens the terminal device file and makes it the session's controlling terminal.
vc-reset-terminal re-initializes the terminal device line discipline to sane states and the connected terminal to text mode with the initial character attributes, colours, and character repertoire.
Login services for virtual terminals have to do a lot less than the login services of real terminals, however implemented.
Weitse Venema's agetty was itself overkill for virtual terminals, and superseded at the turn of the 21st century by the likes of Florian La Roche's fgetty or Felix von Leitner's mingetty.
Several parts of virtual terminal login services are specialized, hardwiring things that are variable for real terminals, but that are in fact invariant for virtual terminals.
Serial-line getty programs like Gert Doering's mgetty and Weitse Venema's agetty deal in things like modem connect strings, serial line speeds, auto-detection by sending BREAK or by pressing the carriage return key multiple times, modem flow control, parity, dial-out interlocks, and suchlike.
None of those things apply to virtual terminals; and the tools are simpler for having no dealings with them.
As their names suggest, vc-get-tty and vc-reset-tty are specialized tools for virtual terminals; those are what they are designed for and what they primarily target.
Both the terminal types set by the former and the control sequences emitted by the latter are fixed and determined by the user-space terminal emulator or the terminal emulator in the operating system kernel, and won't change in the way that real terminals attached to serial lines can.
For user-space virtual terminals especially, login services are even more minimal than "minimal getty" was.
There are some differences between user-space and kernel virtual terminals that simplify such scripts yet further:
User-space virtual terminals are created afresh (a new pseudo-terminal back end and front end pair) at service start, so there is no need for the --revoke or --vhangup option to open-controlling-tty,
On Linux and BSDs, kernel virtual terminals may retain terminal state from previous logins that affects the viewability of subsequent logins.
Existing processes can also end up retaining open file descriptors for the terminal device.
To forcibly reset a virtual console, using mechanisms that are specific to kernel virtual consoles, one can employ the --hard-reset, --text-mode and other options to vc-reset-tty; and to forcibly remove access to open file descriptors one can employ the --vhangup or --revoke options to open-controlling-tty.
User-space virtual terminals are initialized into a sane state (both the line discipline and the terminal emulator's attributes, colours, and character repertoire) at start and do not have a graphics mode, so there is no need for vc-reset-tty at all.
login is history, too.
Previous versions of this toolkit relied upon the an external login program, usually supplied by the operating system, employed in conjunction with chain-loading tools such as login-banner and login-prompt.
With login-envuidgid in the chain, none of those are necessary any more.
Some login programs employ an idle timeout feature, whereby they exit if login has not completed within a set period of time, such as 60 seconds.
Terminal login as a proper service, managed by a service manager, operates suboptimally if the service is continually exiting, because login has timed out, every 60 seconds.
(At the very least, it is annoying chaff in the service logs.)
Thus previous versions of this toolkit used login-prompt in the chain, ensuring that the service did not keep timing out and exiting.
login presented a dumb "glass TTY" login dialogue, with just the editing functionality provided by the line discipline in the kernel; because it could be potentially be invoked against real terminals of minimal functionality, down to terminals that printed on paper (and so had to use printable characters for line kill and character erase).
Logging in on a line printer is still the UI of login to this day.
But virtual terminals have known minimal capabilities greater than that.
They always support cursor addressing; aren't paper; and always support ECMA-48 control sequences for colours and character attributes.
login-envuidgid can thus present a full-screen TUI login dialogue.
Kernel virtual terminals' support of Unicode is spotty, but on user-space virtual terminals this TUI can moreover employ Unicode box drawing, block, and MouseText characters to provide a pseudo-windowing user interface at least as good as the Apple IIc.
(Yes, it is saying something that login's UI can be improved upon by boldly marching forward to the time of the Apple IIc.
It's also saying something to observe that virtual terminals have been around since MultiScreen in the days of SCO Unix, but it wasn't until almost a quarter of the way into the 21st century that any terminal login user interface took them up on their capabilities.)
The tail end of the chain behaves somewhat akin to Bernstein checkpassword, as this is the conventional way in which login processes are set up:
setuidgid-fromenv drops superuser privileges irrevocably and makes the process run as the account chosen with login-envuidgid.
userenv-fromenv sets up the environment variables for that account, including USER, HOME, and SHELL, deliberately doing so with only the privileges of the chosen account, so that it doesn't bypass security restrictions on login.conf that might apply to that user.
chdir-home changes to the home directory just set in an environment variable, again deliberately doing so with only the privileges of the chosen account.
login-shell chain-loads the login shell just set in an environment variable.