Cloud Server Rescue Update: Automatic Network Configuration
The news is one paragraph: rescue initrd (a special set of the kernel and initrd) is now automatically configured on the ipv4 / ipv6 addresses assigned to the cloud server and automatically starts the ssh server after the download.
Usually, the virtual machine boot looks like this: grub.cfg / grub.lst is read from the boot disk of the virtual machine (from its boot partition), the kernel and initrd are selected from it. Domain builder (a special application that creates a domain when the virtual machine starts, puts the kernel / initrd there, fomuet the start page with settings and adds memory) this kernel loads and starts the domain.
Next, the kernel is already loaded as in a normal server — the init script is run in the initrd, which prepares the root filesystem, pivot_root (root directory switching) is done and the real init is started, which reads inittab, starts the system-v initialization system, or upstart, systemd, who really like that more.
If a problem occurs: the root file system is not available, suspicion of hacking, investigation of a problem, then it may be necessary to load an alternative kernel.
')
In this case, the kernel, instead of being read from the guest virtual machine disk, is taken from the catalog of ready-made kernels. From there, the initrd is also taken. The guest car starts "as is".
In total, we have several sets of kernels and initrd - most of them allow you to run a normal system, but there are several specific initrd that do something useful while remaining “outside” the operating system.
It:
We wrote more about him immediately after launch: habrahabr.ru/company/selectel/blog/122667
In short:
Now rescue initrd itself determines the network settings. There is no magic here - when setting the kernel arguments in them, the current settings of the virtual machines are added, and the initrd scripts get these settings and configure the network in accordance with them.
At the same time, the ssh-server is now automatically started.
There is one problem whose theoretical solution we do not know. This is a private ssh server key problem. If it changes (for the same ip-address), then the ssh-client will give an unpleasant warning about the “changed server key” (and on most ssh-clients it will not even let you connect until the key is changed / removed in known_hosts).
There are several options here:
In other words, there are no beautiful solutions, so the only possible solution would be to remove the old key from the known ones, connect, and after completing the work, delete the stored key again.
... Or just use the console.
The rescue initrd includes a script that allows you to upload data to any swift storage. For example, on our cloud storage.
It looks like this:
Due to the fact that projects of storage and servers have some autonomy from each other, the username and password will have to finish manually. You can find them on the “access settings” page of the cloud storage.
Copying the user's public key to the root user in the rescue-initrd. It will be implemented in the next 1-2 updates.
How does it work?
Usually, the virtual machine boot looks like this: grub.cfg / grub.lst is read from the boot disk of the virtual machine (from its boot partition), the kernel and initrd are selected from it. Domain builder (a special application that creates a domain when the virtual machine starts, puts the kernel / initrd there, fomuet the start page with settings and adds memory) this kernel loads and starts the domain.
Next, the kernel is already loaded as in a normal server — the init script is run in the initrd, which prepares the root filesystem, pivot_root (root directory switching) is done and the real init is started, which reads inittab, starts the system-v initialization system, or upstart, systemd, who really like that more.
If a problem occurs: the root file system is not available, suspicion of hacking, investigation of a problem, then it may be necessary to load an alternative kernel.
')
In this case, the kernel, instead of being read from the guest virtual machine disk, is taken from the catalog of ready-made kernels. From there, the initrd is also taken. The guest car starts "as is".
In total, we have several sets of kernels and initrd - most of them allow you to run a normal system, but there are several specific initrd that do something useful while remaining “outside” the operating system.
It:
- Auto PTMAX is a specialized initrd that automatically expands the size of the PV, VG, and root partition file system after resizing a block device (increasing the size of the disk).
- Auto FSCK - automatically performs a root partition file system check.
- Vanilla Linux 3.2 - test version to test the operation of pv_ops kernels (use at your own risk)
- Rescue Initrd - the main character of our story
What can rescue initrd?
We wrote more about him immediately after launch: habrahabr.ru/company/selectel/blog/122667
In short:
- Almost full shell (full busybox)
- A set of tools for repairing file systems and partitions.
- A set of network diagnostic utilities
- ssh server
- Common environment for comfortable work (editors, utilities)
- supload (about him below)
What has changed?
Now rescue initrd itself determines the network settings. There is no magic here - when setting the kernel arguments in them, the current settings of the virtual machines are added, and the initrd scripts get these settings and configure the network in accordance with them.
At the same time, the ssh-server is now automatically started.
There is one problem whose theoretical solution we do not know. This is a private ssh server key problem. If it changes (for the same ip-address), then the ssh-client will give an unpleasant warning about the “changed server key” (and on most ssh-clients it will not even let you connect until the key is changed / removed in known_hosts).
There are several options here:
- Copy the key from the file system of the virtual machine. If there are any problems with the file system, then its automatic mounting can be fraught (for example, a good xfs can lead the file system into a “consistent” state by rolling back gigs like a hundred of recorded data at the time of mounting). For a rescue image, this is not an option.
- Store the server private key in our database. Contradicts the idea of ​​private keys.
- Set "your" private key during installation. Similarly.
In other words, there are no beautiful solutions, so the only possible solution would be to remove the old key from the known ones, connect, and after completing the work, delete the stored key again.
... Or just use the console.
Using supload
The rescue initrd includes a script that allows you to upload data to any swift storage. For example, on our cloud storage.
It looks like this:
supload.sh -u -k file.tar.gz
Due to the fact that projects of storage and servers have some autonomy from each other, the username and password will have to finish manually. You can find them on the “access settings” page of the cloud storage.
Immediate prospects
Copying the user's public key to the root user in the rescue-initrd. It will be implemented in the next 1-2 updates.
Source: https://habr.com/ru/post/179933/
All Articles