📜 ⬆️ ⬇️

Cloud news

Headline:

Console

Scrolling


We have added a display history to the screen. Now, the text that has crawled off the screen is available for a while. You can navigate through the history with the Shft-PgUp, Shift-PgDown buttons. The buffer size is chosen so that the loaded machine can see the message before rebooting. In the future, there will be more additions to this story. Traditionally, the implementation of this functionality is in our githaba repository. In the picture - the history of the boot machine. You can see the output of the machine before the reboot and the first steps of the new boot.


By the way, since we started talking about the console, here are some interesting features of the console, which maybe not everyone knows.

Alt-sysrq

Linux has such a magic combination of buttons - Alt-SysRq, which allows you to do a lot of interesting things - crash the disk cache, see what is being performed, etc. Since it is difficult for users of linux machines to press the Alt-SysRq combination (it is intercepted by local Linux), the combination Ctrl-O is provided for it in xenconsoled. Thus, Ctrl-O s makes an emergency sync, Ctrl-O t produces a terrible, but safe trace of current processes. Etc.
')
Accessibility can be controlled by
echo 0 > /proc/sys/kernel/sysrq - disable
echo 1 > /proc/sys/kernel/sysrq - enable

There is a possibility of more subtle control over which operations are allowed, they are described in the documentation (for example, with centos here , plus the description in man proc ).

Automatic end of the session when inactive


Many people forget to leave the console. In principle, the console is available to us only to a limited circle of people (see below), but, all the same, “not neatly”.

You can control this with the help of the environment variable TMOUT. It is given in seconds. Once this is done like this: TMOUT = 35 (enter) and after 35 seconds of inactivity, bash will terminate the session.

For this to work always - put the variable in the profile (.bash_profile).

Who can see your console?


Until a certain time, the console was available only to the user and developers.

Since the support team needed to see what was on the client’s console, it was decided to allow it to watch the console (without input rights).

At the moment, the rights look like this:

User - The virtual machine console is available for viewing and entering text. The time of console opening is recorded in the user event log.
Support service - the console is available only for viewing. Opening the console for viewing is recorded in the service log.
Developers - the console is read-only and writeable. Opening the console is recorded in the service log.
Administrators - full access as developers. Technically, there is an abnormal access in the guts of the Xen Cloud Platform, however, this access disrupts the operation of a conventional console.

Shutting down the console


If you do not want the console to allow login root, just remove the xvc0 and hvc0 lines from the / etc / securetty file, if you want nothing else but the kernel boot log to appear, delete the corresponding line from / etc / inittab ( with xvc0 / hvc0). In Ubuntu, this is not a line in the inittab file, but a file in the / etc / init / directory. Remember, if you “break” both the console and ssh, the only way to fix it is to reinstall the operating system.

Lower memory limit

Once upon a time, when the cloud was just starting to work, limits were written in the templates. Since MOD has matured into three major versions, we have changed the memory management algorithms and added the ability to control it from the user interface. However, the limits remained.

It's time to cancel them.

Not really, of course. Technical limitations remain.

But for 64-bit machines, limits are significantly reduced. (Although, what do you do in a 64-bit centos with 160MB of memory, I do not know - but, master sir ...). Keep in mind that at the minimum amount (128MB) disk activity increases greatly (due to the fact that there is not enough memory for the file cache).

The ban on the destruction and reinstallation

This checkbox in the properties of the machine will protect the machine from reinstalling and removing the machine. It is great for product servers, so as not to accidentally delete them along with test machines. If you try to remove or start a reinstallation of the machine with this flag, a message appears with a refusal to perform the operation before removing this checkbox.

Source: https://habr.com/ru/post/124470/


All Articles