Как заставить команду NIC подойти на начальной загрузке в RHEL 7

Некоторые программные проекты предоставляют предварительно скомпилированные двоичные файлы для нескольких дистрибутивов. Для Debian найдите пакет .deb . Если вы его найдете, просто запустите:

dpkg -i your-package-name.deb

Посмотрите также: http://backports.debian.org/Instructions

Да, вы можете сделать это, обращаясь к главному ключу во время расшифровки тома.

Быстрое и грязное добавление новой парольной фразы:

device=/dev/sda5
volume_name=foo
cryptsetup luksAddKey $device --master-key-file <(dmsetup table --showkeys $volume_name | awk '{ print $5 }' | xxd -r -p)

устройство и volume _ name должны быть установлены соответствующим образом.
volume _ name - имя расшифрованного тома, отображаемое в /dev/mapper .

Пояснение:

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

Позволяет разорвать приведенную выше команду.

$ dmsetup table --showkeys $volume_name

Сбрасывает кучу информации об активно расшифровываемом томе. Выходные данные выглядят следующим образом:

0 200704 crypt aes-xts-plain64 53bb7da1f26e2a032cc9e70d6162980440bd69bb31cb64d2a4012362eeaad0ac 0 7:2 4096

Поле # 5 является главным ключом.

$ dmsetup table --showkeys $volume_name | awk '{ print $5 }' | xxd -r -p

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

$ cryptsetup luksAddKey $device --master-key-file <(...)

Это говорит cryptsetup добавить новый ключ к тому. Как правило, для этого действия требуется существующий ключ, однако мы используем -master-key-file , чтобы указать, что мы хотим использовать главный ключ.
< (...) является подстановкой и перенаправлением команд оболочки. Он в основном выполняет все внутри, отправляет выходные данные в канал, а затем заменяет < (...) путем к этому каналу.

Так что вся команда - это всего лишь одна прокладка для конденсации нескольких операций.

Сначала создайте новый файл в каталоге /etc/sysconfig/network-scripts с именем ifcfg-team0 , который выглядит следующим образом:

DEVICE=team0
DEVICETYPE=Team
ONBOOT=yes
BOOTPROTO=none
IPADDR=1.2.3.4
NETMASK=255.255.255.0
TEAM_CONFIG='{"runner": {"name": "lacp"}, "link_watch": {"name": "ethtool"}}'

Очевидно, что необходимо соответствующим образом изменить IP-адрес и маску сети.

Затем в том же каталоге измените все файлы ifcfg-eno [1-4] на следующий вид:

DEVICE=eno1
HWADDR=00:11:22:33:44:55
DEVICETYPE=TeamPort
ONBOOT=yes
TEAM_MASTER=team0
TEAM_PORT_CONFIG='{"prio": 100}'

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

Это прямо из руководства .

Файл ifcfg-team0 ссылается на уже созданный файл lacp.conf . Однако я не вижу в руководстве, как он находит этот файл. Возможно, команда запоминает его из предыдущей ручной конфигурации или, возможно, вам придется поместить его в общий каталог.

Как бы то ни было, как только это настроено, вы скажете ifup team0 , и объединенная группа NIC соберется вместе. Отдельные интерфейсы должны быть отключены в начале, но не нужно делать ничего особенного для обеспечения загрузки, так как теперь они помечены как часть команды NIC.Загрузочная конфигурация ОС осознает, что эти четыре интерфейса должны быть включены не по отдельности, а только в составе группы сетевых адаптеров.

Все вышесказанное предполагает, что вы отключили StartManager и вернулись к старому хорошему способу настройки сети на Linuxes типа Red Hat:

$ sudo systemctl stop NetworkManager.service
$ sudo systemctl disable NetworkManager.service
$ sudo systemctl start network.service
$ sudo systemctl enable network.service

Это часто хорошая идея на серверах, особенно когда их сетевая конфигурация начинает становиться сложной, как с LACP. StartManager решает множество проблем, но часто делает это с наклоном, ориентированным на рабочий стол, который не подходит для серверов. Например, он решает автоматические переходы WiFi в Ethernet, общие для ноутбуков. Как правило, серверы имеют статические сетевые конфигурации, так что в конечном итоге в путь можно просто попасть.

Тем не менее, если вы хотите придерживаться стандартных настроек Red Hat, они охватывают эту альтернативу несколькими разделами ранее в руководстве .