Локальная виртуализация с использованием qemoo

Одним из ключевых элементов высокой доступности является плавающий IP-адрес – адрес, который может автоматически перемещаться между узлами в пределах одной сети. В приведённом примере используется IP-адрес 10.45.4.60.

Для регистрации IP-адреса в виде ресурса с именем v_ip используется следующая команда:

sudo pcs resource create v_ip ocf:heartbeat:IPaddr2 ip=10.45.4.60 cidr_netmask=24 op monitor interval=20s

Далее добавляется ресурс nginx, представляющий службу веб-сервера, управляемую через systemd:

sudo pcs resource create nginx systemd:nginx

Состояние ресурсов проверяется с помощью команды:

sudo pcs status resources

Если в выводе отображаются ресурсы v_ip и nginx, это означает, что плавающий IP-адрес и веб-сервер были успешно добавлены в кластер.

Запуск виртуальных машин с помощью qemoo

Для обеспечения корректной работы веб-сервера Nginx необходимо, чтобы он всегда запускался на том же узле, где активен плавающий IP-адрес. Для этого используется политика коллокации.

Настройка коллокации выполняется командой:

sudo pcs constraint colocation add nginx v_ip INFINITY

Также необходимо определить порядок запуска ресурсов: сначала должен быть активирован IP-адрес, затем – веб-сервер.

Настройка порядка запуска ресурсов:

sudo pcs constraint order v_ip then nginx

Проверка текущего состояния ресурсов кластера выполняется командой:

sudo pcs status

Загрузка в режиме EFI

Для проверки корректности настройки отказоустойчивого кластера необходимо убедиться, что ресурсы (веб-сервер Nginx и плавающий IP-адрес) автоматически переключаются между узлами в случае отказа одного из них.

Для выполнения проверки необходимо:

• Открыть веб-браузер и перейти по адресу:

  http://10.45.4.60
  

  На открывшейся странице можно увидеть индексную страницу Nginx, размещённую на первом узле webserver-01.
• Для эмуляции отказа текущего ведущего узла выполняется остановка кластера на webserver-01:

  sudo pcs cluster stop webserver-01
  

• После остановки кластера на первом узле при повторном обращении к адресу http://10.45.4.60 будет отображена индексная страница, размещённая на узле webserver-02. Это означает, что ресурсы кластера автоматически переместились на доступный узел, обеспечив непрерывность сервиса. Проверка выполнения всех шагов позволяет подтвердить успешную настройку отказоустойчивого кластера с использованием Pacemaker и Corosync.

Добавление дополнительных устройств и параметров

Для обеспечения корректной работы ресурсов в кластере необходимо настроить их регулярную проверку. В Pacemaker для этого используется операция monitor.

Операция мониторинга добавляется в момент создания ресурса с указанием интервала:

sudo pcs resource create nginx systemd:nginx op monitor interval=30s

Если ресурс уже создан, параметр можно добавить отдельно:

sudo pcs resource op add nginx monitor interval=30s

Pacemaker отслеживает результат работы проверки и реагирует согласно установленной политике. Рекомендуется также задать параметры, определяющие поведение кластера при сбоях:

• migration-threshold – количество сбоев, после которого ресурс переносится на другой узел;
• failure-timeout – интервал (в секундах), через который сбой считается неактуальным и может быть повторно допущен;
• on-fail – политика действия при сбое (restart, fence, standby, block и др.). Пример команды:

  sudo pcs resource update nginx migration-threshold=2 failure-timeout=60 on-fail=restart
  

  Для отслеживания статуса ресурсов рекомендуется использовать команду:

  sudo pcs status resources
  

  Логирование событий выполняется службой Pacemaker и доступно через системный журнал:

  journalctl -u pacemaker
  

Загрузка в режиме, имитирующем запись ISO-образа на носитель

В процессе эксплуатации кластера может потребоваться ручное вмешательство: перемещение ресурсов между узлами, временное отключение ресурса, снятие ограничений.

Перемещение ресурса на конкретный узел:

sudo pcs resource move nginx webserver-02

Запрет запуска ресурса на узле:

sudo pcs resource ban nginx webserver-01

Очистка всех ограничений, связанных с ресурсом:

sudo pcs resource clear nginx

Временное отключение ресурса:

sudo pcs resource disable nginx

Повторное включение ресурса:

sudo pcs resource enable nginx

Просмотр состояния кластера с детализацией:

sudo pcs status
sudo pcs status resources
sudo pcs status nodes

Дополнительно может использоваться команда для получения краткого отчёта по текущему состоянию кластера:

sudo crm_mon -1

Рекомендуется регулярно сохранять конфигурацию кластера:

sudo pcs config backup rosacluster-backup.tar.gz

Для восстановления используется команда:

sudo pcs config restore rosacluster-backup.tar.gz

Проброс USB-устройств

Часть из рассматриваемых далее способов удаленного подключения к Системе работает только в случае, если установлен GUI-интерфейс.

Установка ОС на виртуальный диск

Сетевые режимы и проброс устройств

OpenSSH – это бесплатный SSH-сервер, дающий возможность интерактивного управления сервером.

В большинстве дистрибутивов OpenSSH-сервер уже присутствует в ОС, и его установка не требуется. В случае отсутствия OpenSSH следующая команда выполнит установку необходимых пакетов:

sudo dnf openssh

Далее следует добавить SSH-сервер в автозагрузку. При следующем запуске сервера ОС выполнит автоматический запуск SSH-сервера. Как и в случае с другими сервисами, systemd позволяет управлять параметрами запуска, автозагрузки и рестарта демона OpenSSH. Автозапуск включается командой:

sudo systemctl enable ssh

Работоспособность утилиты проверяется командой:

ssh localhost

Автоматическое подключение к подсети virbr0

Настройка SSH необходима для улучшения защищенности Системы. Например, можно отключить возможность входа от имени пользователя root или изменить порт подключения со стандартного 22 на произвольный. Лучше использовать порты из верхнего диапазона (50000-65000).

Примечание – В стеке протоколов TCP/IP доступно 65536 портов.

Настройка выполняется в конфигурационном файле. Перед его модификацией создают резервную копию.

sudo cp /etc/ssh/sshd_config
/etc/ssh/sshd_config.factory-defaults

Все изменения конфигурации SSH проводятся в файле /etc/ssh/sshd_config. Для его редактирования нужно выполнить команду:

sudo nano /etc/ssh/sshd_config

В файле нужно раскомментировать строку Port 22 и изменить значение на 55555 (рисунок 114).

Следует учитывать, что автоматизированные системы, такие как боты, зачастую приоритетно сканируют порты с одинаковыми цифрами. Поэтому в производственных и корпоративных сетях рекомендуется применять порты с различными цифрами для повышения уровня безопасности.

й

Рисунок 114 – Изменение стандартного порта подключения

Далее нужно отключить возможность входа на сервер учетной записи суперпользователя (root) и добавить возможность входа через ключи. Для этого необходимо изменить значения параметров PermitRootLogin на "no" и PubkeyAuthentication на "yes" (рисунок 115).

Рисунок 115 – Изменение параметров PermitRootLogin и PubkeyAuthentication

После этого следует перезагрузить демон SSH. Соединение при этом будет разорвано и подключиться можно будет через новый порт и пользовательскую учетную запись (она должны быть предварительно создана):

sudo systemctl restart ssh

Далее нужно переподключиться от обычной учетной записи и по другому порту:

ssh -p 55555 ansible@192.168.0.104

После успешного подключения можно продолжать работу с сервером.

Настройка собственного сетевого моста

Еще один способ аутентификации на сервере – пара ключей RSA: открытый и закрытый. Открытый хранится на сервере, к которому будет выполняться подключение, а закрытый – на удаленном компьютере (или другом сервере), с которого выполняется подключение.

Далее (рисунок 116) в качестве примера приведена схема безопасного обмена ключами между "Отправителем" и "Получателем". "Злоумышленник" может читать сообщения, если они не зашифрованы. Здесь "Отправитель" или "Получатель" шифруют сообщение при помощи открытого ключа принимающей стороны, которая его дешифрует при помощи своего закрытого ключа.

Рисунок 116 – Безопасный обмен ключами

Чтобы сгенерировать такую пару ключей, достаточно выполнить команду:

ssh-keygen -t rsa

Команду нужно выполнять на рабочей станции от имени пользователя, который будет в дальнейшем подключаться к удаленному компьютеру. Путь к хранению ключей можно оставить по умолчанию.

После создания ключей можно переходить к следующему шагу – копированию открытого ключа на удаленный сервер, выполнив следующую команду:

ssh-copy-id -i ~/.ssh/id_rsa.pub rosa@192.168.0.104

В этом примере 192.168.0.104 – это IP-адрес удаленного сервера. После ввода пароля ключ копируется в папку .ssh домашней директории пользователя.

Сразу же после выполнения копирования следует проверить доступ при помощи созданной пары ключей:

ssh rosa@192.168.0.104

Для отключения возможности входа по паролю необходимо в файле /etc/ssh/sshd_config отредактировать значение PasswordAuthentication и присвоить "no" (рисунок 117).

Рисунок 117 – Редактирование параметра PasswordAuthentication

После изменения настроек нужно перезагрузить службу SSH:

sudo systemctl restart ssh

После проведенных настроек при попытке подключения пользователем, для которого не определена пара ключей, будет выдаваться ошибка подключения.

При этом подключение при помощи ключа будет успешным.

Отключение доступа по паролю значительно повышает безопасность сервера.

Проброс каталогов в гостевую систему

При работе с сервером пользователь может запускать различные процессы (например, tmux или screen), завершение которых происходит по окончании сеанса пользователя.

После выхода пользователя из SSH-сессии Система автоматически завершает процессы, но в некоторых случаях выполнение определённых процессов необходимо сохранить.

Важно – Для выполнения дальнейших действий пользователю необходимо иметь несколько машин, подключение к которым происходит с помощью SSH. Настройка SSH описана в п. 8.1.

Для завершения процесса после выхода пользователя из SSH-сессии нужно выполнить следующие действия:

1. создать нового пользователя test1 на основной машине (рисунок 118);

Рисунок 118 – Создание пользователя test1

2. подключиться к другой машине под именем нового пользователя с помощью следующей команды (рисунок 119):

ssh test1@192.168.1.131

• где:
• test1 – имя пользователя;
• 192.168.1.131 – IP-адрес машины, к которой подключается пользователь.

Рисунок 119 – Успешное подключение пользователя test1

3. выполнить команду screen, после чего должна открыться консоль;
4. в открывшейся консоли нужно выполнить команду sleep infinity (рисунок 120);

Рисунок 120 – Запуск процесса бесконечного ожидания

5. выйти из screen с помощью комбинации клавиш Ctrl+A, а затем Ctrl+D;
6. выйти из SSH-сессии одним из следующих способов:

• выполнить команду exit;
• использовать комбинацию клавиш Ctrl+D;
• закрыть консоль.

7. открыть новую SSH-сессию с помощью команды ssh test1@192.168.122.76 (рисунок 121);
8. вывести список запущенных сессий внутри screen с помощью команды screen -r (рисунок 121).

Рисунок 121 – Результат выполнения команды screen -r после повторного открытия SSH-сессии

В результате выполнения команды screen -r видно, что процессы screen и sleep были автоматически завершены после выхода пользователя из SSH-сессии.

При отсутствии активных screen-сеансов команда может вывести сообщение:

There is no screen to be resumed.

Для сохранения процессов после выхода пользователя из SSH-сессии можно воспользоваться одним из следующих вариантов:

• использовать команду systemd-run --scope --user screen;
• установить пакет systemd-settings-disable-kill-user-processes.

Проброс USB-устройств

При использовании команды systemd-run --scope --user screen вместо screen указывается команда, запускающая определенный процесс.

В качестве примера использования команды systemd-run --scope --user screen можно выполнить следующие шаги:

1. начать SSH-сессию с помощью команды:

ssh test1@192.168.122.76

где test1 – имя пользователя, созданного в шаге а) п.8.1.4. 2. выполнить команду systemd-run --scope --user screen для запуска процесса screen; 3. выполнить команду sleep 9999999h, запускающую процесс ожидания (рисунок 122);

Рисунок 122 – Новый процесс ожидания

4. выйти из screen с помощью последовательного нажатия комбинаций клавиш Ctrl+A и Ctrl+D;
5. выйти из SSH-сессии одним из следующих способов:

• выполнить команду exit;
• использовать комбинацию клавиш Ctrl+D;
• закрыть консоль.

6. открыть новую SSH-сессию, как в шаге а), и вывести список запущенных сессий внутри screen с помощью команды screen -r (рисунок 123).

Рисунок 123 – Список запущенных процессов

В результате выполнения команды screen -r видно, что процессы screen и sleep, запущенные пользователем до выхода из SSH-сессии, не завершились после выхода из SSH-сессии.

Таким образом, с помощью команды systemd-run --scope --user screen можно сохранить начатый процесс и после закрытия пользователем SSH-сессии.

Работа в демон-режиме (SPICE)

Пакет systemd-settings-disable-kill-user-processes предотвращает уничтожение всех пользовательских процессов после завершения SSH-сессии, в которой они были запущены.

Важно – Установку пакета нужно выполнять с правами суперпользователя.

Для установки пакета systemd-settings-disable-kill-user-processes пользователю необходимо выполнить следующую команду (рисунок 124):

dnf install systemd-settings-disable-kill-user-processes

Рисунок 124 – Успешная установка пакета

Для применения настроек после установки пакета пользователю нужно выполнить перезагрузку Системы. Для перезапуска можно использовать одну из следующих команд:

• reboot;

  systemctl reboot.
  

  Примечание – Пользователь может применить настройки без перезагрузки Системы с помощью команды:

  systemctl restart systemd-logind.
  

  Перезапуск systemd-logind завершит все активные пользовательские сессии.

Запуск в SPICE-режиме

После установки пакета systemd-settings-disable-kill-user-processes все пользовательские процессы должны продолжить выполнение по окончании сеанса пользователя.

Для проверки сохранения процессов нужно выполнить следующие шаги:

1. открыть SSH-сессию под именем нового пользователя с помощью следующей команды (рисунок 125):

ssh test1@192.168.1.131

• где:
• test1 – имя пользователя, созданного в шаге а) п.8.1.4;
• 192.168.1.131 – IP-адрес машины, к которой подключается пользователь.

Рисунок 125 – Успешное подключение пользователя test1

2. выполнить команду screen, после чего должна открыться консоль;
3. в открывшейся консоли нужно выполнить команду sleep infinity (рисунок 126);

Рисунок 126 – Запуск процесса бесконечного ожидания

4. выйти из screen с помощью комбинации клавиш Ctrl+A, а затем Ctrl+D;
5. выйти из SSH-сессии одним из следующих способов:

• выполнить команду exit;
• использовать комбинацию клавиш Ctrl+D;
• закрыть консоль.

6. открыть новую SSH-сессию с помощью команды ssh test1@192.168.122.76;
7. выполнить команду screen -r.

В результате выполнения команды screen -r видно, что начатый процесс бесконечного ожидания продолжает выполняться и после выхода пользователя из SSH-сессии (рисунок 127).

Рисунок 127 – Процесс бесконечного ожидания, сохраненный после выхода пользователя из SSH-сессии

Примечания – Пользователь может:

• Проверить наличие пакета в репозитории с помощью команды dnf search systemd-settings (рисунок 128);

Рисунок 128 – Проверка наличия пакета systemd-settings-disable-kill-user-processes в репозитории

• Проверить содержимое пакета с помощью команды rpm -ql systemd-settings-disable-kill-user-processes (рисунок 129);

Рисунок 129 – Содержимое пакета systemd-settings-disable-kill-user-processes

• С правами суперпользователя выполнить команду dnf remove systemd-settings-disable-kill-user-processes для удаления пакета.

Управление виртуальной машиной через systemd

Терминальный сервер XRDP предназначен для организации удалённого доступа пользователей к графическому сеансу рабочего стола через протокол RDP. После подключения пользователь проходит аутентификацию и получает полноценную рабочую среду, аналогичную локальному сеансу.

Для установки терминального сервера XRDP необходимо выполнить установку следующих пакетов с помощью команды:

sudo dnf install xrdp task-x11

После установки требуется включить и запустить службу XRDP командой:

sudo systemctl enable --now xrdp

Для корректной работы терминального сеанса необходимо работать в одном из доступных графических окружений:

• Минимальное KDE Plasma 5; устанавливается командой:

  sudo dnf install task-plasma5-minimal
  

• Полное KDE Plasma 5 с базовым набором программ; устанавливается командой:

  sudo dnf install task-plasma5
  

• KDE Plasma 5, соответствующее десктопному образу ОС; устанавливается командой:

  sudo dnf install task-iso-plasma5
  

• Минимальное XFCE; устанавливается командой:

  sudo dnf install task-xfce-minimal
  

• XFCE с настройками РОСА и дополнительным ПО; устанавливается командой:

  sudo dnf install task-xfce
  

• Окружение MATE; устанавливается командой:

  sudo dnf install task-mate
  

• GNOME, соответствующее десктопному образу ОС; устанавливается командой:

  sudo dnf install task-iso-gnome
  

Конфигурация и приоритет параметров

Для предоставления доступа по RDP локальным пользователям необходимо:

1. создать локальную учётную запись:

sudo useradd <имя_пользователя>

2. задать пароль пользователю:

passwd <имя_пользователя>

3. добавить пользователя в группу tsusers, обладающую правом на запуск XRDP-сессий:

usermod -a -G tsusers <имя_пользователя>

Типовые параметры конфигурации

Для обеспечения подключения доменных пользователей по протоколу RDP через XRDP необходимо настроить сопоставление доменных групп с локальной группой tsusers, используемой XRDP для контроля доступа:

Необходимо убедиться, что сервер введён в домен и Система успешно распознает доменные учетные записи. Проверить наличие информации о домене можно командой:

realm list

Если сервер введён в домен, в ответ будет показан список обнаруженных доменов.

Подробнее о вводе в домен см. раздел 6.3.5.

На контроллере домена добавить пользователей, которым требуется доступ по XRDP, в одну общую доменную группу, например, RDP-Users.

На сервере с ОС РОСА "ХРОМ" выполнить команду для сопоставления этой доменной группы с локальной группой tsusers:

sudo roleadd "Доменная_группа" tsusers

Например:

sudo roleadd "DOMAIN\\RDP-Users" tsusers

После выполнения этой команды все члены доменной группы RDP-Users будут автоматически считаться членами локальной группы tsusers и смогут подключаться к серверу через XRDP без необходимости вручную добавлять каждого пользователя в локальные группы.

• Проверить корректность настроек командой:

  id 'доменный_пользователь'
  

  Вывод команды должен содержать группу tsusers.