Astra linux systemd resolved
В состав диструбутива Astra Linux входит сетевая служба NetworkManager и графический инструмент настройки сетевых интерфейсов апплет NetworkManager, обеспечивающий графический пользовательский интерфейс для выполнения всех стандартных операций по настройке сети в режиме настольного компьютера.
При стандартной установке Astra Linux служба NetworkManager и соответствующий графический инструмент устанавливаются и запускаются автоматически, получая под своё управление все внешние сетевые интерфейсы.
Графический инструмент после установки доступен через меню «Пуск» — «Панель управления» — «Сеть» — «Сетевые соединения», или через иконку быстрого запуска на всплывающей линейке в нижней части экрана.
Документация по использованию NetworkManager находится в каталоге
Конфигурационные файлы NetworkManager находятся в каталоге
Инструмент командной строки nmcli для работы с NetworkManager
В составе пакета имеется инструмент командной строки nmcli для работы с NetworkManager.
Инструмент может работать с устройствами (devices, dev) или с соединениями (connection, con).
Примеры применения командного интерфейса к устройствам:
# устанавливаем IP-адрес для устройства eth0
nmcli device modify eth0 ipv4.address 192.168.32.97/24
# устанавливаем адрес шлюза для устройства eth0
nmcli device modify eth0 ipv4.gateway 192.168.32.1
# устанавливаем адрес DNS для устройства eth0
nmcli device modify eth0 ipv4.dns 192.168.32.1
# проверяем настройки устройства eth0
nmcli device show eth0
При установке ОС по умолчанию устанавливается сетевой интерфейс «Проводное соединение 1», настроенный на получение динамического адреса по протоколу DHCP.
Кроме «длинного» имени «Проводное соединение 1» можно использовать опции path (выбор соединений по номеру конфигурации в шине dBus) или apath (выбор активных соединений по номеру конфигурации в шине dBus), например:
nmcli con show path 3
nmcli con show apath 1
При этом типовой задачей при настройке серверов является задача переключения этого соединения на статический адрес.
Пример сценария настройки соединения (connection, сокращенно con), выполняющего эту задачу:
# Имя соединения, и устанавливаемые начальные параметры: адрес/маска (ip), адрес шлюза (gw), адреса DNS (dns, можно несколько адресов через пробел), шлюз для статического маршрута (gwroute)
con=»Проводное соединение 1″
ip=»10.0.2.254/24″
gw=»10.0.2.1″
dns=»10.0.2.254 8.8.8.8″
gwroute=»10.0.2.2″
# Проверяем наличие соединения
if nmcli con show «$con» > /dev/null ; then
echo «Настраиваем «$con» на работу со статическим адресом $ip gw $gw.»
# Задаем адрес и адрес шлюза
nmcli con mod «$con» ip4 $ip gw4 $gw
# Задаем адреса DNS
nmcli con mod «$con» ipv4.dns «$dns 8.8.8.8»
# Добавим статический маршрут
nmcli con mod «$con» +ipv4.routes «192.168.1.0/24 $gwroute»
# Отключаем DHCP, переводим в «ручной» режим настройки
nmcli con mod «$con» ipv4.method manual
echo «Применены следующие настройки:»
nmcli -p con show «$con» | grep ipv4
# Перезапускаем соединение для применения новых настроек. Лучше всегда делать перезапуск одной командой, чтобы не терять машину при работе через удалённое подключение:
nmcli con down «$con» ; nmcli con up «$con»
else
echo «Соединение «$con» не найдено, настройте адрес вручную.»
exit 1
fi
Полное описание командного интерфейса доступно в общей системе документации:
man nmcli
man nmcli-examples
man nm-online
Во избежание конфликтов со службой networking настроенная по умолчанию служба NetworkManager НЕ РАБОТАЕТ с сетевыми интерфейсами, перечисленными в файле
присутствует только интерфейс локальной петли (loopback).
Для того, чтобы NetworkManager прочитал изменения конфигурации (в том числе изменения списка интерфейсов, перечисленных в файле
), следует перезапустить службу NetworkManager:
sudo systemctl restart NetworkManager
При работе со службой NetworkManager можно использовать её псевдоним network-manager:
sudo systemctl restart network-manager
Для того, чтобы изменения настроек сетевого адаптера, сделанные через графический интерфейс, вступили в силу, следует перезапустить сетевой адаптер. При работе в графическом интерфейсе это можно следать просто нажав левой кнопкой мыши на апплет управления сетями и ещё раз нажав левой кнопкой мыши на имя сетевого адаптера в открывшемся списке.
Networking: Настройка сети из командной строки
Теоретически, службы NetworkManager и networking конфликтовать не должны, так как первая не работает с сетевыми интерфейсами, перечисленными в файле
, а вторая — работает только с интерфейсами, перечисленными в этом файле, но при переходе к использованию службы networking лучше отключить NetworkManager, для чего выполнить команду:
sudo systemctl —now mask NetworkManager
По желанию после удаления службы NetworkManager можно скрыть графическую оснастку NetworkManager (значок сети в панели задач).Для запрета запуска графической оснастки выполнить команду
sudo mv /etc/xdg/autostart/nm-applet.desktop /etc/xdg/autostart/nm-applet.desktop.disabled
Иконка будет скрыта в следующей сессии пользователя. Если нужно, чтобы оснастка была скрыта немедленно, перезапустить fly-dm:
sudo systemctl restart fly-dm
При перезапуске fly-dm пользовательская сессия будет перезапущена.
Традиционно, настройка сети TCP/IP из командной строки выполняется с использованием инструментов ifup и ifdown, входящих в пакет ifupdown, и предназначенных для высокоуровневого конфигурирования сети.
При этом можно выделить два типичных случая
1. Для систем, работающих в статичной сети (например, для серверов), следует сохранять как можно более простую конфигурацию;
2. Для систем, работающих с динамически меняющимися сетями и IP-адресами (например, для мобильных компьютеров) рекомендуется дополнительно использовать для настройки пакет resolvconf, упрощающий переключение конфигураций при смене сетевого адреса.
Пакеты resolvconf и NetworkManager могут конфликтовать, так как работают с одним файлом /etc/resolv.conf
Пакет ifupdown содержит три команды: команды ifup и ifdown, обеспечивающие настройки сетевых интерфейсов в соответствии с конфигурационным файлом
, и команда ifquery, проверяющая корректность конфигурационного файла
При этом список включенных в данный момент интерфейсов хранится в файле
Сценарий изменения настройки сетевого интерфейса (на примере интерфейса eth0):
1. Внести изменения в файл /etc/network/interfaces в секцию, относящуюся к интерфейсу eth0.
2. Проверить корректность файла:
3. Перезапустить интерфейс. Лучше всегда делать это одной командой, чтобы не потерять машину при работе через удалённое подключение:
sudo ifdown eth0; sudo ifup eth0
Не следует использовать низкоуровневые конфигурационные команды как, например, ifconfig(8) и ip(8) для переключения сетевых интерфейсов во включенное (up) состояние.
Типичной ошибкой при использовании команд ifdown/ifup является повторное назначение параметров интерфейса неотключенным и некорректно работающим сервисом NetworkManager,
что выглядит как игнорирование изменений, внесённых в файл /etc/network/interfaces.
Для проверки полного состояния сетевого интерфейса вместо устаревшей команды ifconfig следует использовать современную команду ip из пакета iproute2:
1. проверить все сетевые адреса, назначенные сетевому интерфейсу:
2. очистить все сетевые адреса, назначенные сетевому интерфейсу:
sudo ip address flush dev eth0
Сервисы
Вот 1-й вопрос: этот набор комплектовщики дистрибутива поставили по дефаулту как самый общий, на усреднённого пользователя.
Но что здесь не всегда обязательно, можно остановить/удалить?
P.S. На этот вопрос подтолкнула тема, например, Долгий запуск графических приложений — где рассматривается работа дистрибутива на оборудовании с ограниченными ресурсами (памятью) . здесь пассивно выполняющиеся сервисы могут а). поджирать бесцельно процессорное время + б). занимать память, а при её нехватке вызывать активный своп, что опять выражается (ещё раз) снижением производительности.
Olej
New member
По идее, тот же список, но уже выполняющихся сервисов (демонов) даст и команда service в «старом стиле» (sysV а не systend):
root@astra:~# service --status-all [ + ] acpid [ + ] acpi-support [ - ] aldd [ - ] alsa-utils [ - ] anacron [ + ] avahi-daemon [ - ] console-setup.sh [ + ] cron [ - ] cryptdisks [ - ] cryptdisks-early [ + ] cups [ + ] dbus [ + ] dnsmasq [ - ] exim4 [ - ] firewalld [ + ] fly-dm [ + ] gpm [ - ] hwclock.sh [ - ] keyboard-setup.sh [ + ] kmod [ + ] libvirtd [ + ] libvirt-guests [ + ] networking [ + ] network-manager [ - ] nfs-common [ - ] ntp [ - ] openvpn [ - ] plymouth [ - ] plymouth-log [ + ] procps [ + ] quota [ - ] quotarpc [ + ] rpcbind [ + ] rsyslog [ + ] ssh [ + ] sssd [ - ] sudo [ + ] udev [ + ] ufw [ - ] virtlogd [ + ] virtualbox [ - ] x11-commonПричём команда service даст (как пишут) сервисы, которые запущены через systemd, так и сервисы из /etc/init.d, запущенные в старом стиле инициализации.
Olej
New member
А 2-й вопрос, связанный с сервисами (если точнее с юнитами systemd) . Отследить юниты запускаемые при загрузке системы, упорядоченные по потребовавшемуся им времени на загрузке:
olej@astra:~$ systemd-analyze blame 15.986s vboxadd.service 5.608s apt-daily.service 4.792s sssd.service 4.218s keyboard-setup.service 3.828s libvirtd.service 2.853s dev-sda1.device 2.765s apt-daily-upgrade.service 2.192s NetworkManager-wait-online.service 1.982s networking.service 1.598s virtualbox.service 1.580s NetworkManager.service 1.572s upower.service 1.082s rpcbind.service 1.025s quota.service 995ms rsyslog.service 944ms avahi-daemon.service 868ms alsa-restore.service 780ms systemd-udevd.service 750ms systemd-udev-trigger.service 661ms dnsmasq.service 617ms gpm.service 607ms systemd-modules-load.service 563ms quotarpc.service 557ms acpi-support.service 426ms ssh.service 419ms udisks2.service 411ms systemd-journald.service 410ms polkit.service 353ms systemd-logind.service 334ms libvirt-guests.service 330ms systemd-journal-flush.service 286ms run-rpc_pipefs.mount 284ms systemd-tmpfiles-setup-dev.service 207ms systemd-sysctl.service 164ms systemd-tmpfiles-setup.service 155ms sys-fs-fuse-connections.mount 147ms kmod-static-nodes.service 144ms dev-hugepages.mount 141ms user@999.service 139ms vboxadd-service.service 138ms systemd-remount-fs.service 135ms ufw.service 127ms plymouth-start.service 95ms user@1000.service 90ms plymouth-quit-wait.service 83ms console-setup.service 81ms fly-dm.service 76ms plymouth-read-write.service 73ms nfs-config.service 68ms dev-disk-by\x2duuid-7678ec6a\x2dd050\x2d4ed6\x2d96d0\x2dd9c89130c58f.swap 66ms sys-kernel-config.mount 66ms systemd-user-sessions.service 64ms dev-mqueue.mount 43ms sys-kernel-debug.mount 42ms plymouth-quit.service 30ms systemd-random-seed.service 28ms systemd-update-utmp.service 15ms systemd-update-utmp-runlevel.service 8ms systemd-tmpfiles-clean.serviceolej@astra:~$ systemd-analyze critical-chain The time after the unit is active or started is printed after the "@" character. The time the unit takes to start is printed after the "+" character. graphical.target @22.432s └─multi-user.target @22.432s └─vboxadd-service.service @22.292s +139ms └─vboxadd.service @6.304s +15.986s └─basic.target @5.308s └─paths.target @5.306s └─acpid.path @5.306s └─sysinit.target @5.266s └─systemd-update-utmp.service @5.237s +28ms └─systemd-tmpfiles-setup.service @5.057s +164ms └─local-fs.target @5.042s └─local-fs-pre.target @5.042s └─keyboard-setup.service @823ms +4.218s └─system.slice @752ms └─-.slice @647msВо-первых, таким образом можно отследить «виновника» в тех случаях, когда загрузка системы становится до неприличного длительной (при разных внесенных изменениях).
Но, самое интересное, из этой длинной цепочки путём конфигурации systemd можно повыбрасывать (запретить) те сервисы-юниты, которые не нужны мне в конкретных условиях. Утверждается, что в некоторых случаях такой оптимизацией под свои нужды время перезагрузки системы можно уменьшить в разы.