Brief introduction to terminals and console
Here live dragons and there are no mentiners (instead of an epigraph)
Very concise combat description of “what is pseudo-terminal” and “console”.
So, first, let's decide what the console is: the console is a program that accepts buttons from the user, and from the connection to the computer - letters on the screen and specials. commands for drawing pictures on the screen.
')
The terminal is a generic name for both the program and the special piece of hardware (there are no such in nature anymore). A special exception is when you launch a putti or someone else to connect to the serial port of a switch / router / modem (or even a server), then you act (or rather a computer with a putt) acts as a terminal (the name “terminal” - because it terminates cable (i.e. hanging at the very end)).
As it is easy to understand by cable, there are two ends: the terminal and what the Baitik sends to it in the cable.
When a shell is launched, it gets at its disposal a virtual device / dev / tty, which is different for each process - this is the “reverse” part of the terminal. In the case of a cable, the front end is realized by a putty + computer, in the case of a computer console, by a specialized nuclear driver (virtual consoles). Important: the driver emulates the presence of the terminal.
There is an interface unix98 (/ dev / ptmx), which allows you to create a couple of "input and output" for all the applied programs. In this case, one half is the “opposite” half, and the second is the console. It is used, in particular, by openssh and x'th terminalki.
There is a lot of confusion in this place, but the rule is simple: on the one hand, the one who draws, on the other - the one who says to draw. On the side from which draw, with the same is the user with the keyboard. His data comes to the opposite side to the program.
The most frequent program from the “program” side is getty of various kinds (mgetty, atetty, etc.), whose task is to set the speed of the channel and launch the login command to enter a password.
As the front part (drawing bytes), there is either a virtual Linux console, or a terminal program (almost any), or a terminal located behind a serial lace (for example, another computer).
Each drawing device (terminal, virtual console, etc.) has its own set of capabilities (supported characters and commands). The terminal type is defined by the TERM variable, but only in the sense that it tells the programs which terminal they work with. It is impossible to force the TERM variable to force the terminal to emulate other terminals - it does not know anything about this variable.
Sudden use: KVM, XEN (and, I'm not sure, but it seems OpenVZ) use this mechanism to access the virtual machine console: a specialized device is created in the virtual machine that interacts with the daom daemon. In terms of the domU, it has a serial device for the terminal. In order to see the login line on this device, you need to register the line with the getty call in the inittab and enable the login (/ etc / securetty).
In dom0, the daemon sees the serial device from the domU, creates the corresponding pseudo-terminal using / dev / ptmx). Created devices for connecting terminals appear in / dev / pts / *. In addition, consoled writes in xenstore to whom which domain corresponds, specialized terminalki (xenconsole) can read and execute this. When the xl console (xm console) command is given, it just calls xenconsole with the given parameter.
Instead of xenconsoled, you can use any other terminalka - at least minicom, at least cu, at least socat, at least putty. After connecting to the console, it is correct to set the type of console to be used (set TERM = linux or set TERM = xterm, setting to vt100 will give a black and white screen).
Exactly the same way you can organize a connection to the machine via a modem (if anyone else remembers them) - the modems simply “extend” the serial port by N kilometers. On the one hand, you need to configure the modem for auto answer and hang mgetty (and do not forget about / etc / securetty), on the other hand you need to dial a number and get a regular login message.
It was very concise and which is a description of pseudo terminals. Full is almost impossible, because for a complete understanding of how it works, you need to start with teletypes and device mechanical typewriters.
The main point to be aware of is that there are always two participants in tty, one of whom can draw (himself, or throwing the contents onto the screen so that the user’s terminal draws it), and the other gives what to draw and accepts sequences button presses.
Main reading material: tldp.org/HOWTO/Text-Terminal-HOWTO.html
Very concise combat description of “what is pseudo-terminal” and “console”.
So, first, let's decide what the console is: the console is a program that accepts buttons from the user, and from the connection to the computer - letters on the screen and specials. commands for drawing pictures on the screen.
')
The terminal is a generic name for both the program and the special piece of hardware (there are no such in nature anymore). A special exception is when you launch a putti or someone else to connect to the serial port of a switch / router / modem (or even a server), then you act (or rather a computer with a putt) acts as a terminal (the name “terminal” - because it terminates cable (i.e. hanging at the very end)).
As it is easy to understand by cable, there are two ends: the terminal and what the Baitik sends to it in the cable.
When a shell is launched, it gets at its disposal a virtual device / dev / tty, which is different for each process - this is the “reverse” part of the terminal. In the case of a cable, the front end is realized by a putty + computer, in the case of a computer console, by a specialized nuclear driver (virtual consoles). Important: the driver emulates the presence of the terminal.
There is an interface unix98 (/ dev / ptmx), which allows you to create a couple of "input and output" for all the applied programs. In this case, one half is the “opposite” half, and the second is the console. It is used, in particular, by openssh and x'th terminalki.
There is a lot of confusion in this place, but the rule is simple: on the one hand, the one who draws, on the other - the one who says to draw. On the side from which draw, with the same is the user with the keyboard. His data comes to the opposite side to the program.
The most frequent program from the “program” side is getty of various kinds (mgetty, atetty, etc.), whose task is to set the speed of the channel and launch the login command to enter a password.
As the front part (drawing bytes), there is either a virtual Linux console, or a terminal program (almost any), or a terminal located behind a serial lace (for example, another computer).
Each drawing device (terminal, virtual console, etc.) has its own set of capabilities (supported characters and commands). The terminal type is defined by the TERM variable, but only in the sense that it tells the programs which terminal they work with. It is impossible to force the TERM variable to force the terminal to emulate other terminals - it does not know anything about this variable.
Sudden use: KVM, XEN (and, I'm not sure, but it seems OpenVZ) use this mechanism to access the virtual machine console: a specialized device is created in the virtual machine that interacts with the daom daemon. In terms of the domU, it has a serial device for the terminal. In order to see the login line on this device, you need to register the line with the getty call in the inittab and enable the login (/ etc / securetty).
In dom0, the daemon sees the serial device from the domU, creates the corresponding pseudo-terminal using / dev / ptmx). Created devices for connecting terminals appear in / dev / pts / *. In addition, consoled writes in xenstore to whom which domain corresponds, specialized terminalki (xenconsole) can read and execute this. When the xl console (xm console) command is given, it just calls xenconsole with the given parameter.
Instead of xenconsoled, you can use any other terminalka - at least minicom, at least cu, at least socat, at least putty. After connecting to the console, it is correct to set the type of console to be used (set TERM = linux or set TERM = xterm, setting to vt100 will give a black and white screen).
Exactly the same way you can organize a connection to the machine via a modem (if anyone else remembers them) - the modems simply “extend” the serial port by N kilometers. On the one hand, you need to configure the modem for auto answer and hang mgetty (and do not forget about / etc / securetty), on the other hand you need to dial a number and get a regular login message.
It was very concise and which is a description of pseudo terminals. Full is almost impossible, because for a complete understanding of how it works, you need to start with teletypes and device mechanical typewriters.
The main point to be aware of is that there are always two participants in tty, one of whom can draw (himself, or throwing the contents onto the screen so that the user’s terminal draws it), and the other gives what to draw and accepts sequences button presses.
Main reading material: tldp.org/HOWTO/Text-Terminal-HOWTO.html
Source: https://habr.com/ru/post/112797/
All Articles