воскресенье, 21 апреля 2024 г.

Статические маршруты в NetworkManager. Ошибка Unable to save connection: Cannot modify a connection that has an associated rule- or rule6- file

В новых версия Linux управление сетевой конфигурацией выполняется специальной службой - NetworkManager.
Ранее в старых версиях Linux служба «network» в своей работе опиралась на конфигурационные файлы, расположенные в каталоге
/etc/sysconfig/network-scripts/
Теперь служба «NetworkManager» опирается на конфигурационные файлы в каталоге
/etc/NetworkManager/system-connections/,
а также на скрипты, расположенные в директории
/etc/NetworkManager/dispatcher.d/

Для добавления статического маршрута в NetworkManager можно воспользоваться удобной псевдографической утилитой «nmtui»
# nmtui
После запуска утилиты мы видим меню для работы с сетевыми соединениями. Выбираем «Edit a connection» и нажимаем Enter

В следующем окне выбираем сетевой интерфейс, переходим вправо и выбираем действие «Edit...» (Можно просто выбрать интерфейс и нажать Enter).

Открывается окно редактирования сетевого соединения. Переходим в раздел Routing и в пункт «Edit...»

Откроется дополнительное окно редактирования статических маршрутов. Выбираем «Add...»

Пример заполнения данных о статическом маршруте:

После применения изменений по кнопке «OK», окно редактирования маршрутов должно закрыться и мы должны попасть обратно в панель редактирования настроек интерфейса. Перемещаемся по этому окну до кнопки «OK», нажимаем Enter. Затем в разделе меню выбора интерфейса перемещаемся на кнопку «Back...» и выходим в в основное меню утилиты nmtui. Тут выбираем раздел «Quit» и выходим в консоль.

Для применения настроек нужно выполнить перезапуск службы NetworkManager
# systemctl restart NetworkManager
Статический маршрут пропишется в файл
/etc/NetworkManager/system-connections/<ИМЯ_ИНТЕРФЕЙСА>.nmconnection
Проcмотр правил маршрутизации:
# ip route
default via 10.10.49.254 dev ens18 proto static metric 100
10.10.49.0/24 dev ens18 proto kernel scope link src 10.10.49.166 metric 100
10.200.5.216 via 10.10.49.254 dev ens18 proto static metric 100


Для удаления статического маршрута, нужно опять запустить псевдографический интерфейс nmtui, зайти в раздел конфигурации нужного интерфейса, перейти в раздел «Routing», выбрать не нужный маршрут и применить команду «Remove». После этого выйти из программы nmtuui и перезапустить NetworkManager
# systemctl restart NetworkManager
Из файла /etc/NetworkManager/system-connections/<ИМЯ_ИНТЕРФЕЙСА>.nmconnection
статический маршрут пропадет, но команда ip route по прежнему будет отображать этот удаленный маршрут.
Для того что бы удалить маршрут окончательно нужно или применить команду удаления
# ip route del 10.10.49.0/24 dev ens18
Или перезапустить сетевой интерфейс вот так, чтобы не потерять управление:
# nmcli connection down enp0s3 && nmcli connection up enp0s3
В данном случае enp0s3 – это имя интерфейса.
Ну или можно просто перезагрузиться.

Если в Linux работает старая версия службы управления сетью «network», которая использует скрипты в директории /etc/sysconfig/network-scripts/, в случае добавления статического маршрута через nmtui мы получим ошибку «Unable to save connection: Cannot modify a connection that has an associated ‘rule-’ or ‘rule6-’ file». Это говорит о том, что NetworkManager не может выполнить изменение информации в файлах, лежащих в директории /etc/sysconfig/network-scripts/, а в этих директориях как раз есть что-то нужное для маршрутизации (например, правила маршрутизации в файле /etc/sysconfig/network-scripts/rule-eth1). Данное поведение не считается ошибкой (см https://bugzilla.redhat.com/show_bug.cgi?id=1384799), а говорит о том, что изменение файлов /etc/sysconfig/network-scripts/rule-* и /etc/sysconfig/network-scripts/route-* не поддерживается функционалом NetworkManager.

В этом случае можно пойти следующими путями:

1) Добавлять статические маршруты через редактирование файла
/etc/sysconfig/network-scripts/route-<ИМЯ_ИНТЕРФЕЙСА>
Пример записи в файле:
default via 10.11.90.54 table eth0
10.11.0.0/24 via 10.11.90.16

После изменения файла нужно перезагрузить службу «network»
# systemctl restart network

2) Отказаться от службы «network» и перейти на NetworkManager полностью.
# systemctl stop network
# systemctl disable network
# systemctl enable NetworkManager

В этом случае (в случае использования полностью NetworkManager) так же рекомендуется использовать службу NetworkManager-dispatcher, которая предназначена для отлова событий в системе, таких как падение или поднятие интерфейса. После наступления подобного события, связанного с сетью, благодаря службе NetworkManager-dispatcher будет запускаться скрипт из директории /etc/NetworkManager/dispatcher.d/, связанный с этим событием. Например, после поднятия интерфейса eth2, будет автоматически монтироваться шара по NFC.
Запуск службы NetworkManager-dispatcher:
# systemctl start NetworkManager-dispatcher
# systemctl enable NetworkManager-dispatcher

У NetworkManager-dispatcher есть расширение NetworkManager-dispatcher-routing-rules, которое может использовать в скриптах диспетчера старые правила описанные в файлах
/etc/sysconfig/network-scripts/route-*
/etc/sysconfig/network-scripts/rule-*
и прописывать маршруты на основе этих правил при событиях up и down интерфейсов
Установка этого расширения:
# yum makecache
# yum -y install NetworkManager-dispatcher-routing-rules





пятница, 12 апреля 2024 г.

Решение проблемы сбойного триггера в базе Mariadb. Trigger does not exist

Есть база данных Mariadb.
При бэкапе базы я получаю ошибку триггера:
mysqldump: Couldn't execute 'SHOW CREATE TRIGGER `orders_after_delete`': Trigger does not exist (1360)
При дампе таблиц базы поочередно, все же удается сохранить дамп базы частями, но при развертывании таблицы order опять фикируем ошибку:
ERROR 1359 (HY000) at line 13313: Trigger 'al.orders_after_delete' already exists

Подключаюсь к основной базе и командой SHOW TRIGGERS; смотрю, что такой триггер есть orders_after_delete.
Хочу его пересоздать (удалить и добавить заново), но при удалении триггера, его как буд-то нет:
MariaDB [al]> DROP TRIGGER orders_after_delete;
ERROR 1360 (HY000): Trigger does not exist


Проверка базы на ошибки проходит успешно, но триггер все равно висит у таблицы orders и не удаляется ни через консоль, ни через phpmyadmin.
# mysqlcheck -u**** -p -r al orders
al.orders OK


РЕШЕНИЕ ПРОБЛЕМЫ:

1) Необходимо создать одноименный триггер из консоли mariadb для этой же таблицы
При этом SHOW TRIGGERS будет показывать два триггера orders_after_delete.
Но зато команда выполнения дампа базы и восстановления базы будут идти без сбоев.

2) В час наименьшей нагрузки выполняем удаление сбойного триггера так:

2.1) Подключаемся к базе

# mysql -hlocalhost --user <ПОЛЬЗОВАТЕЛЬ> -p<ПАРОЛЬ>
>USE al;

2.2) Вводим команду удаления триггера:
DROP TRIGGER orders_after_delete;
Удаляется при этом один триггер (который создали ранее для решения проблемы создания дампа), а второй сбойный триггер остается в системе.
Попытки его удалить вновь не удачные:
MariaDB [al]> DROP TRIGGER orders_after_delete;
ERROR 1360 (HY000): Trigger does not exist

2.3) Переименовываем таблицу orders
MariaDB [al]> ALTER TABLE orders RENAME TO orders2;
Query OK, 0 rows affected (0.07 sec)


2.4) Удаляем сбойный триггер. Теперь он удаляется без проблем:
MariaDB [al]> DROP TRIGGER orders_after_delete;
Query OK, 0 rows affected (0.01 sec)


2.5) Возвращаем таблице исходное название:
MariaDB [al]> ALTER TABLE orders2 RENAME TO orders;
Query OK, 0 rows affected (0.00 sec)


2.6) Создаем триггер

Теперь в системе отображается один триггер, дампы выполняются успешно, восстановление - тоже.

понедельник, 8 апреля 2024 г.

Изменение пользовательского приветствия (banner) при подключении к консоли Linux.

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

Добавление пользовательского приветствия перед авторизацией.
Нужно создать файл приветствия. Например: /etc/login.warn
# touch /etc/login.warn
Открываем файл и вписываем туда приветствие
# nano /etc/login.warn
Пример:
 *** Тестовый сервер Королева В.С. ***
 *** Самарская область, г. Самара ***
 *** Необходима авторизация ***

Теперь данный файл /etc/login.warn необходимо прописать в настройках SSH.
Находим строки:
# no default banner path
#Banner none

Прописываем путь до файла приветствия:
Banner /etc/login.warn
Перезапускаем демон SSHD
# systemctl restart sshd

Добавление приветствия после авторизации:
Приветствие после авторизации прописывается в файле /etc/motd
motd - это сокращение от Message Of The Day (Приветствие дня).
# nano /etc/motd
Пример текста:
*** Добро пожаловать ***
Теперь при авторизации будут выдаваться приглашения:
$ ssh korolev@10.10.49.166
*** Тестовый сервер Королева В.С. ***
*** Самарская область, г. Самара ***
*** Необходима авторизация ***
korolev@10.10.49.166's password:
*** Добро пожаловать ***
Web console: https://KVS:9090/ or https://10.10.49.166:9090/
Last login: Sun Apr 7 11:53:30 2024 from 10.10.49.252