Настройка основных параметров системы#

В этом разделе описываются основы системного администрирования в Platform V SberLinux OS Server (далее - SberLinux). Основное внимание уделяется задачам, которые системный администратор должен выполнить сразу после успешной установки операционной системы:

• установка программного обеспечения с помощью yum;

• использование systemd для управления службами;

• управление пользователями, группами и правами доступа к файлам;

• использование chrony для настройки NTP;

• работа с Python 3 и другие.

Изменение основных параметров среды#

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

• дата и время;

• локали системы;

• раскладка клавиатуры;

• язык.

Настройка даты и времени#

Точный хронометраж важен по ряду причин. Хронометраж обеспечивается NTP протоколом, который реализуется демоном, работающим в пользовательском пространстве. Демон пользовательского пространства обновляет системные часы, работающие в ядре. Системные часы могут показывать время, используя различные источники синхронизации.

SberLinux использует chronyd демон для реализации NTP. chronyd доступен в пакете chrony.

Отображение текущей даты и времени

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

Процедура:

1. Введите date команду:

$ date
Mon Mar 30 16:02:59 CEST 2020

2. Чтобы увидеть более подробную информацию, используйте timedatectl команду:

$ timedatectl
Local time: Mon 2020-03-30 16:04:42 CEST
Universal time: Mon 2020-03-30 14:04:42 UTC
RTC time: Mon 2020-03-30 14:04:41
Time zone: Europe/Prague (CEST, +0200)
System clock synchronized: yes
NTP service: active
RTC in local TZ: no

Смена часового пояса

$ timedatectl set-timezone "Europe/Moscow"

Смена времени

$ timedatectl set-time 15:58:30

Настройка локали системы#

Общесистемные настройки локали хранятся в файле /etc/locale.conf, который считывается при ранней загрузке демоном systemd. Каждая служба или пользователь наследует настройки локали, настроенные в /etc/locale.conf, если только отдельные программы или отдельные пользователи не переопределяют их.

В этом разделе описывается, как управлять языковым стандартом системы.

Процедура:

• Чтобы вывести список доступных языковых настроек системы:

$ localectl list-locales
C.utf8
aa_DJ
aa_DJ.iso88591
aa_DJ.utf8
...

• Чтобы отобразить текущий статус настроек системных локалей:

$ localectl status

• Чтобы установить или изменить настройки локали системы по умолчанию, используйте localectl set-locale подкоманду от имени root пользователя. Например:

# localectl set-locale LANG=en_US

Дополнительные ресурсы:

man localectl(1), man locale(7), и man locale.conf(5)

Настройка раскладки клавиатуры#

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

Процедура:

• Получите список доступных раскладок:

$ localectl list-keymaps
ANSI-dvorak
al
al-plisi
amiga-de
amiga-us
...

• Отобразите текущий статус настроек раскладки клавиатуры:

$ localectl status
...
VC Keymap: us
...

• Установите или измените системную раскладку по умолчанию, например:

# localectl set-keymap us

Дополнительные ресурсы:

man localectl(1), man locale(7), и man locale.conf(5)

Средства антивирусной защиты#

SberLinux не предоставляет антивирусного программного обеспечения. Необходимое программное обеспечение пользователь устанавливает самостоятельно.

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

Настройка и управление сетевым доступом#

В этом разделе описываются различные варианты добавления соединений Ethernet.

Настройка сети и имени хоста в графическом режиме установки#

1. В окне Installation Summary нажмите [Network and Host Name].

2. В списке на левой панели выберите интерфейс. Детали отображаются на правой панели.

3. Переключите переключатель ВКЛ/ВЫКЛ, чтобы включить или отключить выбранный интерфейс.

Нажмите "+", чтобы добавить виртуальный сетевой интерфейс, который может быть: Team, Bond, Bridge или VLAN. Нажмите "-" для удаления виртуального интерфейса. Нажмите Configure, чтобы изменить такие параметры, как IP-адреса, DNS-серверы или конфигурацию маршрутизации для существующего интерфейса (как виртуального, так и физического). Введите имя хоста для системы в поле Host Name.

О NetworkManager

Профили nm-initrd-generator имеют более низкий приоритет, чем профили автоматического подключения. Утилита nm-initrd-generator в NetworkManager генерирует и настраивает профили подключений с помощью экземпляра NetworkManager, запущенного на инициализированном диске оперативной памяти initrd загрузчика. Сгенерированные утилитой nm-initrd-Generator профили имеют более низкий приоритет автоматического подключения, чем приоритет автоматического подключения по умолчанию. Это позволяет сгенерированным сетевым профилям в initrd сосуществовать с пользовательской конфигурацией в учетной записи root по умолчанию.

NetworkManager представляет следующие возможности:

• утилита nm-cloud-setup сохраняет адреса, добавленные извне;

• вычисляет сроки истечения срока действия для элементов, настроенных на основе сообщений обнаружения соседей IPv6;

• автоматически обновляет файл /etc/resolv.conf при изменении конфигурации;

• не устанавливает несуществующие интерфейсы в качестве основных при активации связи;

• настраивает основной интерфейс, даже если интерфейс не существует при активации привязки;

• команда –print-config не печатает повторяющиеся записи;

• подключаемый модуль ifcfg-rh считывает профили подключения InfiniBand P-Key без явного имени интерфейса;

• утилита nmcli может удалять профиль подключения к порту связи из соединения;

• отклоняет заявки на аренду DHCPv6, если на всех адресах не удается обнаружить дублирующийся адрес IPv6 (DAD);

• ожидает подключения интерфейсов, прежде чем пытаться разрешить системное имя хоста на этих интерфейсах из DNS;

• параметр no-aaaa используется для настройки параметров DNS на управляемых узлах с целью подавления запросов записей AAAA, вызванных stub resolver. Записи AAAA содержат полное доменное имя, время жизни пакета данных (TTL) и IP-адрес;

• утилита nmcli может отключать IPv6.

Также:

• Имена хостов могут содержать только буквенно-цифровые символы и "-" или ".". Имена хостов не могут начинаться или заканчиваться символами "-" и ".". Нажмите Apply, чтобы применить имя хоста к среде установщика.

• Кроме того, в окне Network and Hostname существует возможность выбрать параметр Wireless option. Для этого нажмите Select network на правой панели, чтобы выбрать подключение Wi-Fi, при необходимости введите пароль и нажмите Done.

Настройка статического соединения Ethernet с помощью утилиты nmcli#

Ниже приведен пример процедуры, которая описывает добавление соединения Ethernet с помощью утилиты nmcli:

В приведенном примере используются следующие значения:

• Статический адрес IPv4 — 192.0.2.1 с /24 маской подсети

• Статический адрес IPv6 — 2001:db8:1::1 с /64 маской подсети

• Шлюз IPv4 по умолчанию — 192.0.2.254

• Шлюз IPv6 по умолчанию — 2001:db8:1::fffe

• DNS-сервер IPv4 — 192.0.2.200

• DNS-сервер IPv6 — 2001:db8:1:ffbb

• Домен поиска DNS — example.ru

Процедура:

1. Добавьте новый профиль подключения NetworkManager для подключения Ethernet:

# nmcli connection **Add** con-name Example-Connection ifname enp7s0 type ethernet

2. Дальнейшие шаги изменяют созданный профиль подключения Example-Connection.

3. Установите IPv4-адрес:

# nmcli connection modify Example-Connection ipv4.addresses 192.0.2.1/24

4. Установите IPv6-адрес:

# nmcli connection modify Example-Connection ipv6.addresses 2001:db8:1::1/64

5. Установите способ подключения IPv4 и IPv6 manual:

# nmcli connection modify Example-Connection ipv4.method manual

6. Установите шлюзы IPv4 и IPv6 по умолчанию:

# nmcli connection modify Example-Connection ipv4.gateway 192.0.2.254
# nmcli connection modify Example-Connection ipv6.gateway 2001:db8:1::fffe

7. Задайте адреса DNS-серверов IPv4 и IPv6:

# nmcli connection modify Example-Connection ipv4.dns "192.0.2.200"
# nmcli connection modify Example-Connection ipv6.dns "2001:db8:1::ffbb"

Чтобы задать несколько DNS-серверов, укажите их через пробел и заключите в кавычки.

8. Установите домен поиска DNS для соединения IPv4 и IPv6:

# nmcli connection modify Example-Connection ipv4.dns-search example.ru
# nmcli connection modify Example-Connection ipv6.dns-search example.ru

9. Активируйте профиль подключения:

# nmcli connection up Example-Connectio
Connection successfully activated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/13)

Этапы проверки:

1. Отображение состояния устройств и подключений:

# nmcli device status
DEVICE TYPE STATE CONNECTION
enp7s0 ethernet connected Example-Connection

2. Чтобы отобразить все настройки профиля подключения:

# nmcli connection show Example-Connection
connection.id: Example-Connection
connection.uuid: b6cdfa1c-e4ad-46e5-af8b-a75f06b79f76
connection.stable-id: --
connection.type: 802-3-ethernet
connection.interface-name: enp7s0
...

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

Пропингуйте IP-адрес в той же подсети.

Для IPv4:

# ping 192.0.2.3

• Для IPv6:

# ping 2001:db8:1::2

Если команда не удалась, проверьте параметры IP и подсети.

• Пропингуйте IP-адрес в удаленной подсети. Для IPv4:

# ping 198.162.3.1

• Для IPv6:

# ping 2001:db8:2::1

• Если команда не удалась, пропингуйте шлюз по умолчанию, чтобы проверить настройки. Для IPv4:

# ping 192.0.2.254

Для IPv6:

# ping 2001:db8:1::fff3

4. Используйте host утилиту, чтобы убедиться, что разрешение имен работает. Например:

# host client.example.ru

Если команда возвращает какую-либо ошибку, например connection timed out или no servers could be reached, проверьте настройки DNS.

Действия по устранению неполадок

1. Если соединение не установлено или сетевой интерфейс переключается между состояниями вверх и вниз:

• Убедитесь, что сетевой кабель подключен к хосту и коммутатору.

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

• Убедитесь, что сетевой кабель и сетевой интерфейс работают должным образом. Выполните действия по диагностике оборудования и замените неисправные кабели и сетевые карты.

Дополнительные ресурсы:

Справочные страницы: nm-settings(5), nmcli и nmcli(1).

Настройка динамического соединения Ethernet с помощью nmtui#

Данная утилита представляет собой текстовый пользовательский интерфейс и может использоваться для настройки и конфигурирования. Используйте nmtui для настройки соединения Ethernet с динамическим IP-адресом на хосте без графического интерфейса.

Процедура:

1. Если имя сетевого устройства, которое хотите использовать в соединении, неизвестно, отобразите доступные устройства:

# nmcli device status
DEVICE     TYPE      STATE                   CONNECTION
enp7s0     ethernet  unavailable             --
...

2. Введите nmtui:

# nmtui

3. Выберите Edit a connection и нажмите Enter.

4. Нажмите кнопку Add.

5. Выберите Ethernet из списка типов сети и нажмите Enter.

6. При необходимости введите имя создаваемого профиля NetworkManager.

7. Введите имя сетевого устройства в Device поле.

Нажмите OK кнопку, чтобы создать и автоматически активировать новое соединение.

Рисунок. Новое соединение

8. Нажмите Back кнопку, чтобы вернуться в главное меню.

9. Выберите Quit и нажмите Enter , чтобы закрыть nmtui приложение.

Проверка:

1. Отображение состояния устройств и подключений:

# nmcli device status
DEVICE      TYPE      STATE      CONNECTION
enp7s0      ethernet  connected  Example-Connection

2. Показать все настройки профиля подключения:

# nmcli connection show Example-Connection
connection.id: Example-Connection
connection.uuid: b6cdfa1c-e4ad-46e5-af8b-a75f06b79f76
connection.stable-id: --
connection.type: 802-3-ethernet
connection.interface-name: enp7s0
...

Настройка статического соединения Ethernet с помощью nmtui#

Приложение nmtui предоставляет текстовый пользовательский интерфейс для NetworkManager. Используйте nmtui для настройки соединения Ethernet со статическим IP-адресом на хосте без графического интерфейса.

Процедура:

1. Если имя сетевого устройства, которое хотите использовать в соединении, неизвестно, отобразите доступные устройства:

# nmcli device status
DEVICE     TYPE      STATE                   CONNECTION
enp7s0     ethernet  unavailable             --
...

2. Начало nmtui:

# nmtui

1. Выберите Edit a connection и нажмите Enter.

2. Нажмите Add кнопку.

3. Выберите Ethernet из списка типов сети и нажмите Enter.

4. Необязательно: введите имя создаваемого профиля NetworkManager.

5. Введите имя сетевого устройства в Device поле.

6. Настройте параметры адресов IPv4 и IPv6 в областях IPv4 configuration и IPv6 configuration:

• Нажмите Automatic кнопку и выберите Manual из отображаемого списка.

• Нажмите Show кнопку рядом с протоколом, чтобы отобразить дополнительные поля.

• Нажмите Add кнопку рядом с Addresses и введите IP-адрес и маску подсети в формате бесклассовой междоменной маршрутизации (CIDR). Если маска подсети не указана, NetworkManager установит /32 маску подсети для адресов IPv4 и /64 для адресов IPv6.

• Введите адрес шлюза по умолчанию.

• Нажмите Add кнопку рядом с DNS servers и введите адрес DNS-сервера.

• Нажмите Add кнопку рядом с Search domains и введите домен поиска DNS.

Рисунок. Пример соединения Ethernet со статическими настройками IP-адреса

1. Нажмите OK кнопку, чтобы создать и автоматически активировать новое соединение.

2. Нажмите Back кнопку, чтобы вернуться в главное меню.

3. Выберите Quit и нажмите Enter, чтобы закрыть nmtui приложение.

Проверка:

1. Отобразятся состояния устройств и подключений:

# nmcli device status
DEVICE      TYPE      STATE      CONNECTION
enp7s0      ethernet  connected  Example-Connection

2. Отобразятся все настройки профиля подключения:

# nmcli connection show Example-Connection
connection.id:              Example-Connection
connection.uuid:            b6cdfa1c-e4ad-46e5-af8b-a75f06b79f76
connection.stable-id:       --
connection.type:            802-3-ethernet
connection.interface-name:  enp7s0
...

Дополнительные ресурсы:

Справочные страницы: nm-settings(5), nmcli и nmcli(1).

Управление сетью с помощью системных ролей SberLinux#

network - с помощью этой роли можно настроить сетевые подключения на нескольких целевых машинах.

Роль network позволяет настраивать следующие типы интерфейсов:

• Ethernet;

• Bridge;

• Bonded;

• VLAN;

• MacVLAN;

• Infiniband.

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

Предупреждение: Роль network обновляет или создает все профили подключения в целевой системе точно так, как указано в network_connections переменной. Поэтому network роль удаляет параметры из указанных профилей, если параметры присутствуют только в системе, но не в network_connections переменной.

В следующем примере показано, как применить роль, чтобы убедиться, что соединение Ethernet с требуемыми параметрами существует:

Пример playbook, применяющего сетевую роль для настройки Ethernet-соединения с требуемыми параметрами.

# SPDX-License-Identifier: BSD-3-Clause
---
- hosts: network-test
  vars:
    network_connections:

      # Create one ethernet profile and activate it.
      # The profile uses automatic IP addressing
      # and is tied to the interface by MAC address.
      - name: prod1
        state: up
        type: ethernet
        autoconnect: yes
        mac: "00:00:5e:00:53:00"
        mtu: 1450

  roles:
    - sberlinux-system-roles.network

Запуск служб systemd во время загрузки#

Как системный администратор, определите, каким образом службы запускаются в системе. Для управления службами используйте systemctl утилиту командной строки для управления systemd системой и диспетчером служб или веб-консоль.

Включение или отключение служб#

Как системный администратор включите или отключите запуск службы при загрузке, и эти изменения применятся после перезагрузки. Для автоматического запуска службы при загрузке, включите эту службу. Если служба отключена, она не будет запускаться при загрузке, но существует возможность запустить ее вручную. Замаскируйте службу, чтобы ее нельзя было запустить вручную. Маскировка — это способ отключения службы, который сделает ее не доступной для использования, пока не будет задействована команда unmask, которая сделает службу снова доступной.

Предварительные условия:

• Права root пользователя.

• Служба, которую хотите включить, не должна быть замаскирована. Если есть замаскированный сервис, необходимо сначала размаскировать его:

# systemctl unmask service_name

Процедура:

1. Включите запуск службы при загрузке:

# systemctl enable service_name

2. Замените service_name на службу, которую хотите включить.

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

# systemctl enable --now service_name

3. Отключите запуск службы при загрузке:

# systemctl disable service_name

Замените service_name на службу, которую хотите отключить.

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

# systemctl mask service_name

Настройка безопасности системы#

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

В этом разделе рассматриваются только основные функции безопасности, которые можно настроить после установки операционной системы.

Включение службы межсетевого экрана firewalld#

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

Служба firewalld, обеспечивающая межсетевой экран в SberLinux, автоматически включается во время установки.

Чтобы включить firewalld службу, выполните следующую процедуру.

Процедура:

• Отображение текущего состояния firewalld:

$ systemctl status firewalld
● firewalld.service - firewalld - dynamic firewall daemon
   Loaded: loaded (/usr/lib/systemd/system/firewalld.service; disabled; vendor preset: enabled)
   Active: inactive (dead)
...

• Если firewalld не включен и не запущен, переключитесь на root-пользователя, запустите firewalld службу и включите ее автоматический запуск после перезагрузки системы:

# systemctl enable --now firewalld

Этапы проверки:

• Убедитесь, что firewalld запущен и включен:

$ systemctl status firewalld
● firewalld.service - firewalld - dynamic firewall daemon
   Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled; vendor preset: enabled)
   Active: active (running)
...

Настройка правил для межсетевого экрана firewalld#

Общий синтаксис для работы с правилами

firewall-cmd [опции] [зона] <правило>

Порядок следования параметров не важен.

где:

[опции] — дополнительные параметры для создаваемого правила, например –permanent — постоянное правило, то есть будет действовать после перезагрузки. Не обязательный. [зона] — по умолчанию, правила создаются для зоны public. Для работы с конкретной зоной ее необходимо указать, например, –zone=dmz. Не обязательный. <правило> — само правило. Чтобы правила применить, перечитайте их:

firewall-cmd --reload

Чтобы добавить порты: Откройте порт 80:

firewall-cmd --permanent --add-port=80/tcp

• где ключ –permanent — добавляет постоянное правило, которое будет действовать после перезагрузки.

Чтобы добавить правило для определенной зоны:

1. Пропишите:

firewall-cmd --permanent --zone=external --add-port=80/tcp

2. Добавьте диапазон портов:

firewall-cmd --permanent --add-port=6500-6700/udp

3. Добавьте несколько правил одной командой:

firewall-cmd --permanent --add-port=80/tcp --add-port=443/tcp

Добавление сервиса

Использование служб, вместо портов, может повысить удобство управления правилами за счет объединения нескольких портов в одну службу.

1. Посмотрите список доступных служб:

firewall-cmd --get-services

2. Разрешите порт, например, для сервиса ntp:

firewall-cmd --permanent --add-service=ntp

3. Создайте собственную службу:

firewall-cmd --permanent --new-service=name-service

Где name-service — это произвольное имя создаваемой службы.

4. Добавьте порт, например TCP 2200 к службе:

firewall-cmd --permanent --service=name-service --add-port=2200/tcp

5. Задайте описание для удобства:

firewall-cmd --permanent --service=name-service --set-short="Service With This Name"

firewall-cmd --permanent --service=name-service --set-description="Long Description For Service With This Name"

Информацию о созданном сервисе можно получить командой:

firewall-cmd --info-service=name-service

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

firewall-cmd --permanent --add-service=name-service

Правило Rich-Rule

Правило rich-rule позволяет создавать правила с условиями. Например:

1. Разрешите службу http с условием, что запросы будут с определенных IP-адресов (например, подсети 000.000.0):

firewall-cmd --permanent --add-rich-rule 'rule family="ipv4" source address="000.000.0.0/24" service name="http" accept'

2. Или разрешите службу для конкретного порта:

firewall-cmd --permanent --add-rich-rule 'rule family="ipv4" source address="000.000.0.0/24" port port="5038" protocol="tcp" accept'

3. Чтобы заблокировать подсеть, воспользуйтесь командой:

firewall-cmd --permanent --add-rich-rule="rule family='ipv4' source address='000.000.1.0/24' reject"

Список правил с условиями отобразите командой:

firewall-cmd --list-rich-rules

Удаление правил

Аналогично созданию, но вместо add введите remove, например –remove-port (удалить порт) или –remove-service (удалить службу).

Удалите правило для открытия 80-о порта:

firewall-cmd --permanent --remove-port=80/tcp

Управление зонами

Все правила в firewalld могут быть разбиты по зонам. Для каждой свой набор правил и свои сетевые интерфейсы. Это нужно использовать, если необходимо для разных сетевых адаптеров создать разные по строгости правила.

1. Просмотрите список всех имеющихся зон:

firewall-cmd --list-all-zones

2. Просмотрите список используемых зон:

firewall-cmd --get-active-zones

Информация о конкретной зоне

1. Введите:

firewall-cmd --list-all --zone=public

2. Создайте правило для зоны public:

firewall-cmd --permanent --zone=public --add-port=80/tcp

3. Добавьте сетевой интерфейс в зону:

firewall-cmd --permanent --zone=public --remove-interface=ens34

firewall-cmd --permanent --zone=internal --add-interface=ens34

Перед этим необходимо удалить адаптер из текущей зоны.

4. Задайте действие по умолчанию для зоны:

firewall-cmd --permanent --zone=public --set-target=DROP

5. Создайте новую зону:

firewall-cmd --permanent --new-zone=custom_zone

firewall-cmd --reload

Пример настройки NAT (шлюза)

1. Включите masquerade:

firewall-cmd --permanent --zone=dmz --add-masquerade

Правило systemctl restart firewalld

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

firewall-cmd --direct --get-all-rules

Проброс портов

Проброс настраивается со следующим синтаксисом:

firewall-cmd --add-forward-port=port=<порт прослушивания>:proto=tcp|udp|sctp|dccp:toport=<порт назначения>:toaddr=<куда перенаправить>

Например:

firewall-cmd --zone=external --permanent --add-forward-port=port=25:proto=tcp:toport=8025:toaddr=000.000.0.15

В примере выше осуществляются запросы на порту 25 и переводятся на узел 000.000.0.15 и порт 8025.

Запретить или разрешить трафик между интерфейсами

Например, существуют два внутренних сетевых интерфейса ens35 и ens36, поэтому необходимо контролировать трафик между ними.

Чтобы запретить трафик между интерфейсами:

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

Введите следующие команды:

firewall-cmd --direct --permanent --add-rule ipv4 filter FORWARD 0 -i ens35 -o ens36 -j DROP

firewall-cmd --direct --permanent --add-rule ipv4 filter FORWARD 0 -i ens36 -o ens35 -j DROP

Чтобы разрешить трафик между интерфейсами:

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

Введите следующие команды:

firewall-cmd --direct --permanent --add-rule ipv4 filter FORWARD 0 -i ens35 -o ens36 -j ACCEPT

firewall-cmd --direct --permanent --add-rule ipv4 filter FORWARD 0 -i ens36 -o ens35 -j ACCEPT

Чтобы разрешить трафик в одном направлении:

Если необходимо сделать так, чтобы только сеть ens35 видела сеть ens36, вводите одну команду:

firewall-cmd --direct --permanent --add-rule ipv4 filter FORWARD 0 -i ens35 -o ens36 -j ACCEPT

Возможные проблемы при работе с firewalld

1. Ошибка command not found (команда не найдена).

Возможные причины: не установлен пакет или не запущена служба.

Выполните установку пакета firewalld:

yum install firewalld firewall-config

Запустите службу:

systemctl start firewalld

2. Не применяются правила.

Причина: не введена команда перезапуска правил.

Перечитайте правила:

firewall-cmd --reload

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

firewall-cmd --complete-reload

Или перезапустите сетевые службы:

systemctl restart network

Перезагрузите машину:

shutdown -r now

Управление основными настройками SELinux#

Security-Enhanced Linux (SELinux) — это дополнительный уровень безопасности системы, определяющий, какие процессы могут получать доступ к тем или иным файлам, каталогам и портам. Эти разрешения определены в политиках SELinux. Политика — это набор правил, которыми руководствуется механизм безопасности SELinux.

SELinux имеет два возможных состояния:

1 Включено. 2 Выключено.

Когда SELinux включен, он работает в одном из следующих режимов:

• Включен:

  • Принудительный

  • Разрешающий

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

В разрешающем режиме SELinux не применяет загруженные политики. SELinux не запрещает доступ, но сообщает о действиях, нарушающих правила, в /var/log/audit/audit.log журнал. Разрешающий режим является режимом по умолчанию во время установки. Разрешающий режим также полезен в некоторых специфических случаях, например, при устранении неполадок.

SELinux ограничивает udftools сервис.

Поскольку служба systemd-socket-proxyd требует особого использования ресурсов, в selinux-policy пакеты добавлена политика с необходимыми правилами. В результате служба работает в своем домене SELinux.

Обеспечение требуемого состояния SElinux#

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

Следуйте этой процедуре, чтобы изменить состояние и режим SELinux в системе.

Процедура

1. Отобразите текущий режим SELinux:

$ getenforce

2. Чтобы временно установить SELinux:

• Для принудительного режима:

# setenforce

• Для разрешительного режима:

# setenforce Permissive

Настройка политики для SELinux, функционирующего в принудительном режиме

В следующих разделах описываются файлы конфигурации и политики SELinux, а также связанные файловые системы, расположенные в /etc/ каталоге.

Конфигурационный файл /etc/sysconfig/selinux

Существует два способа настроить SELinux в SberLinux: с помощью средства настройки уровня безопасности (system-config-securitylevel) или вручную отредактировав файл конфигурации (/etc/sysconfig/selinux).

Этот /etc/sysconfig/selinux файл является основным конфигурационным файлом для включения или отключения SELinux, а также для настройки того, какую политику применять в системе и как ее применять.

Ниже объясняется полное подмножество параметров, доступных для настройки:

• SELINUX=<enforcing|permissive|disabled> — Определяет состояние SELinux верхнего уровня в системе.

• enforcing — Политика безопасности SELinux применяется принудительно.

• permissive — Система SELinux выводит предупреждения, но не применяет политику. Это полезно для целей отладки и устранения неполадок. В разрешающем режиме будет регистрироваться больше отказов, так как субъекты смогут продолжить действия, в противном случае запрещенные в принудительном режиме. Например, обход дерева каталогов приведет к появлению нескольких avc: denied сообщений для каждого прочитанного уровня каталога, где ядро в принудительном режиме остановило бы начальный обход и предотвратило появление дальнейших сообщений об отказе.

• disabled — SELinux полностью отключен. Перехваты SELinux отключаются от ядра, а псевдофайловая система не регистрируется.

• SELINUXTYPE=<targeted|strict> — Указывает, какая политика в данный момент применяется SELinux.

• targeted — Защищены только целевые сетевые демоны.

Файлы политик для этих демонов можно найти в файле /etc/selinux/targeted/src/policy/domains/program.

Принудительное применение политики для этих демонов можно включить или выключить, используя логические значения, управляемые средством настройки уровня безопасности (system-config-securitylevel). Переключение логического значения для целевого демона отключает переход политики для демона, который предотвращает, например, init переход dhcpd из unconfined_t домена в домен, указанный в dhcpd. Домен unconfined_t позволяет субъектам и объектам с этим контекстом безопасности работать под стандартной защитой SberLinux.

strict — Полная защита SELinux для всех демонов. Контексты безопасности определяются для всех субъектов и объектов, и каждое отдельное действие обрабатывается сервером принудительного применения политики.

Каталог /etc/selinux/

Каталог /etc/selinux/ является основным местом расположения всех файлов политики, а также основного файла конфигурации. В следующем примере показано примерное содержимое /etc/selinux/каталога:

-rw-r--r-- 1 root root 448 Sep 22 17:34 config
drwxr-xr-x 5 root root 4096 Sep 22 17:27 strict
drwxr-xr-x 5 root root 4096 Sep 22 17:28 targeted

Два подкаталога, strict/ и targeted/, являются конкретными каталогами, в которых содержатся файлы политики с одинаковыми именами (strict и targeted). Для получения дополнительной информации о политике SELinux и конфигурации политики обратитесь к rhel-selg.

3. Чтобы режим SELinux сохранялся при перезагрузке, измените SELINUX переменную в /etc/selinux/config файле конфигурации.

Например, чтобы переключить SELinux в принудительный режим:

# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
#     enforcing - SELinux security policy is enforced.
#     permissive - SELinux prints warnings instead of enforcing.
#     disabled - No SELinux policy is loaded.
SELINUX=enforcing
...

Предупреждение: Отключение SELinux снижает безопасность системы. Избегайте отключения SELinux с помощью SELINUX=disabled параметра в /etc/selinux/config файле, поскольку это может привести к утечке памяти и состояниям гонки (race condition), когда задействовано несколько инструкций процессора, вызывающих Kernel panic (критическую ошибку ядра). Вместо этого отключите SELinux, добавив selinux=0 параметр в командную строку ядра.

Начало работы с управлением учетными записями пользователей#

Управление учетными записями и группами с помощью инструментов командной строки#

Каждому пользователю присваивается уникальный числовой идентификационный номер, называемый идентификатором пользователя (UID). Аналогично, каждая группа связана с идентификатором группы (GID). Пользователь, создающий файл, также является владельцем и владельцем группы этого файла. Файлу назначаются отдельные разрешения на чтение, запись и выполнение для владельца, группы и всех остальных. Владелец файла может быть изменен только root пользователем, а права доступа могут быть изменены как root пользователем, так и владельцем файла.

SberLinux резервирует идентификаторы пользователей и групп ниже 1000 для системных пользователей и групп. По умолчанию Диспетчер пользователей не отображает системных пользователей. Зарезервированные идентификаторы пользователей и групп документируются в пакете установки. Чтобы просмотреть документацию, используйте эту команду:

cat /usr/share/doc/setup*/uidgid

Рекомендуемая практика - назначать идентификаторы, начинающиеся с 5000, которые еще не были зарезервированы, поскольку зарезервированный диапазон может увеличиться в будущем. Чтобы идентификаторы, назначаемые новым пользователям по умолчанию, начинались с 5000, измените директивы UID_MIN и GID_MIN в файле: /etc/login.defs, как представлено на примере:

[file contents truncated]

UID_MIN 5000

[file contents truncated]

GID_MIN 5000 >[file contents truncated]

Список всех групп хранится в конфигурационный файл /etc/group.

Теневые пароли

В средах с несколькими пользователями очень важно использовать теневые пароли, предоставляемые пакетом shadow- utils, для повышения безопасности системных файлов аутентификации. По этой причине программа установки по умолчанию включает теневые пароли.

Ниже приведен список преимуществ теневых паролей по сравнению с традиционным способом хранения паролей в системах на базе UNIX:

• Теневые пароли повышают безопасность системы, перемещая зашифрованные хеши паролей из общедоступного файла /etc/passwd в файл /etc/shadow, доступный для чтения только root пользователю.

• Теневые пароли хранят информацию о старении пароля.

• Теневые пароли позволяют применять некоторые политики безопасности, установленные в /etc/login.defs файле.

Большинство утилит, предоставляемых пакетом shadow-utils, работают должным образом независимо от того, включены или нет теневые пароли. Но поскольку информация о старении пароля хранится исключительно в файле /etc/shadow, некоторые утилиты и команды не будут работать без предварительного включения теневых паролей:

• Утилита chage для настройки параметров старения пароля.

• Утилита gpasswd для администрирования /etc/group файла.

• Команда usermod с параметром -e, –expiredate или -f, –inactive.

• Команда useradd с параметром -e, –expiredate или -f, –inactive.

Добавление новых учетных записей с помощью командной строки#

Централизованной идентификации и аутентификации пользователей не осуществляется.

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

useradd options username

где options - это параметры командной строки, как описано в таблице ниже.

По умолчанию useradd команда создает заблокированную учетную запись пользователя. Чтобы разблокировать учетную запись, выполните следующую команду под root, чтобы назначить пароль:

passwd username

При желании установите политику устаревания паролей с помощью параметров командной строки useradd, которые представлены в таблице ниже.

Таблица. Общие параметры командной строки useradd

Добавление новой группы пользователей с помощью командной строки#

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

groupadd options group_name

Где options - это параметры командной строки, как описано в таблице ниже.

Таблица. Общие параметры командной строки groupadd

Добавление существующего пользователя в существующую группу

Используйте usermod утилиту для добавления уже существующего пользователя в уже существующую группу.

Различные варианты usermod оказывают различное влияние на основную группу пользователя и на его или ее дополнительные группы.

Чтобы переопределить основную группу пользователя, выполните следующую команду как пользователь root:

~] usermod -g group_name

Чтобы переопределить дополнительные группы пользователя, выполните следующую команду, как пользователь root:

~] usermod -G group_name1,group_name2,... user_name

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

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

~] usermod -aG group_name1,group_name2,... user_name

~] usermod --append -G group_name1,group_name2,... user_name

Создание dump ядра после сбоя для последующего анализа#

Служба kdump устанавливается и активируется по умолчанию в новых установках SberLinux. В следующих разделах объясняется, что такое kdump и как установить kdump, если он не включен по умолчанию.

Настройка использования памяти kdump и целевого местоположения из командной строки#

Оценка размера kdump

При планировании и создании среды kdump - важно знать, сколько места требуется для файла аварийного dump.

Команда makedumpfile --mem-usage оценивает, сколько места требуется файлу аварийного dump. Он генерирует отчет об использовании памяти. Отчет поможет определить уровень dump и определить, какие страницы можно безопасно исключить.

Сценарий:

1. Выполните следующую команду, чтобы сгенерировать отчет об использовании памяти:

makedumpfile --mem-usage /proc/kcore

TYPE PAGES EXCLUDABLE DESCRIPTION

-------------------------------------------------------------

ZERO 501635 yes Pages filled with zero

CACHE 51657 yes Cache pages

CACHE_PRIVATE 5442 yes Cache pages + private

USER 16301 yes User process pages

FREE 77738211 yes Free pages

KERN_DATA 1333192 no Dumpable kernel data

Настройка использования памяти kdump

Память резервируется во время загрузки системы. Размер памяти настраивается в файле конфигурации system Grand Unified Bootloader (GRUB) 2. Размер памяти зависит от значения параметра crashkernel, указанного в файле конфигурации, и размера системной физической памяти.

Параметр crashkernel может быть определен несколькими способами. Укажите значение crashkernel или настройте параметр auto. Параметр crashkernel=auto резервирует память автоматически, в зависимости от общего объема физической памяти в системе. При настройке ядро автоматически резервирует соответствующий объем требуемой памяти для ядра захвата. Это помогает предотвратить ошибки нехватки памяти (ООМ).

Предварительные условия:

• Права root пользователя.

• Выполнены требования к kdump конфигурациям и целям.

Сценарий:

1. Отредактируйте /etc/default/grub файл.

2. Установите crashkernel= параметр. Например, чтобы зарезервировать 128 Мбайт памяти, используйте следующее:

crashkernel=128 М

Установите объем зарезервированной памяти в переменную в зависимости от общего объема установленной памяти. Синтаксис для резервирования памяти в переменную crashkernel=:,:. Например:

crashkernel= 512M-2G: 64M, 2G-:128M

Приведенный выше пример резервирует 64 Мбайт памяти, если общий объем системной памяти составляет от 512 Мбайт до 2 Гбайт. Если общий объем памяти превышает 2 Гбайт, резервируется 128 Мбайт.

Некоторые системы требуют резервирования памяти с определенным фиксированным смещением, поскольку crashkernel резервирование выполняется очень рано, и требуется зарезервировать некоторую область для специального использования. Если задано смещение, то зарезервированная память начинается с него. Чтобы компенсировать зарезервированную память, используйте следующий синтаксис:

crashkernel=128M@16M

В приведенном выше примере kdump резервируется 128 Мбайт памяти, начиная с 16 Мбайт (физический адрес 0x01000000). Если параметр offset установлен в 0 или полностью опущен, kdump зарезервированная память автоматически смещается. Используйте этот синтаксис при настройке резервирования переменной памяти. В этом случае смещение всегда указывается последним (например, crashkernel=512M-2G:64M,2G-:128M@16M).

3. Используйте следующую команду для обновления файла конфигурации GRUB2:

grub2-mkconfig -o /boot/grub2/grub.cfg

kdump с использованием системных ролей#

Параметры, используемые для системных ролей SberLinux dump ядра, следующие:

Можно установить основные параметры dump ядра на нескольких системах, используя системную роль dump ядра, запустив Ansible playbook.

Предварительные условия:

Пакет Ansible Core установлен на управляющей машине.

Пакет sberlinux-system-roles установлен в системе. Запустите playbook.

Файл inventory в котором перечислены системы. Разверните на них kdump.

Сценарий:

1. Создайте новый файл playbook.yml со следующим содержимым:

--- - hosts: kdump-test

vars:

kdump_path: /var/crash

roles:

- sberlinux-system-roles.kdump

2. При необходимости проверьте синтаксис playbook.

ansible-playbook --syntax-check playbook.yml

3. Запустите playbook в инвентарном файле:

ansible-playbook -i inventory_file /path/to/file/playbook.yml

Устранение неполадок с помощью лог-файлов#

Службы, обрабатывающие сообщения системного журнала#

Следующие две службы обрабатывают syslog сообщения:

• Демон systemd-journald.

• Служба Rsyslog.

Демон systemd-journald собирает сообщения из различных источников и пересылает их Rsyslog для дальнейшей обработки. Демон systemd-journald собирает сообщения из следующих источников:

• из ядра;

• на ранней стадии процесса загрузки;

• из стандартного вывода и вывода ошибок демонов при их запуске;

• из Syslog.

Служба Rsyslog сортирует сообщения syslog по типу и приоритету и записывает их в файлы в каталоге /var/log. В каталоге /var/log постоянно хранятся сообщения журнала.

Подкаталоги для хранения сообщений системного журнала#

Следующие подкаталоги в /var/log каталоге хранят syslog сообщения:

• /var/log/messages - все syslog сообщения, подкаталог содержит глобальный системный журнал, в котором пишутся сообщения с момента запуска системы, от ядра, различных служб, обнаруженных устройствах, сетевых интерфейсов и много другого;

• /var/log/secure - сообщения и ошибки, связанные с безопасностью и аутентификацией;

• /var/log/maillog - сообщения и ошибки, связанные с почтовым сервером;

• /var/log/cron - файлы журналов, связанные с периодически выполняемыми задачами;

• /var/log/boot.log - файлы журналов, связанные с запуском системы.

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

Служба ведения журнала Rsyslog:

Приложение Rsyslog в сочетании со systemd-journald службой обеспечивает локальную и удаленную поддержку ведения журнала в SberLinux. Демон rsyslogd непрерывно считывает syslog сообщения, полученные systemd-journald службой из журнала. rsyslogd затем фильтрует и обрабатывает эти syslog события и записывает их в rsyslog файлы журналов или пересылает другим службам в соответствии со своей конфигурацией.

Демон rsyslogd также обеспечивает расширенную фильтрацию, защищенную от шифрования ретрансляцию сообщений, модули ввода и вывода и поддержку транспортировки с использованием протоколов TCP и UDP.

Файл /etc/rsyslog.conf является основным файлом конфигурации для rsyslog, в нем можно указать правила, в соответствии с которыми rsyslogd обрабатывает сообщения. Можно классифицировать сообщения по их источнику, теме (объекту) и срочности (приоритету), а затем назначить действие, которое должно быть выполнено, когда сообщение соответствует этим критериям.

В файле /etc/rsyslog.conf, можно просмотреть список файлов журналов, поддерживаемых rsyslogd. Большинство файлов журнала находятся в /var/log/ каталоге. Некоторые приложения, такие как httpd и samba, хранят свои файлы журналов внутри /var/log/ подкаталога.

Дополнительные источники:

Справочные страницы: rsyslogd(8) и rsyslog.conf(5). Документация, установленная вместе с rsyslog-doc пакетом в /usr/share/doc/rsyslog/html/index.html файле.

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

Настройка Rsyslog в SberLinux#

Сервис Rsyslog?

Rsyslog - расширяемый сервис для управления логами с разнообразными возможностями. Среди его возможностей можно отметить поддержку фильтрации контента, а также передачу логов по сетям.

Основные возможности Rsyslog:

• многопоточность;

• TCP, SSL, TLS, RELP;

• поддержка MySQL, PostgreSQL;

• фильтрация журналов;

• полностью настраиваемый формат вывода.

Как происходит логирование?

Все программы SberLinux ведут лог путем отправки сообщений об ошибках или своем состоянии с помощью syslog или просто записывая все сообщения в файл, который будет находиться в каталоге /var/log/.

Но важное значение имеет уровень подробности логирования. Можно настраивать подробность в каждой отдельной программе или с помощью syslog. Это поможет уменьшить использование дискового пространства для хранения логов.

Например, ядро определяет уровни (приоритеты) логов:

• KERN_EMERG - система неработоспособна;

• KERN_ALERT - нужно немедленно принять меры;

• KERN_CRIT - критическая ошибка;

• KERN_ERR - обычная ошибка;

• KERN_WARNING - предупреждение;

• KERN_NOTICE - замечание;

• KERN_INFO - информационное сообщение;

• KERN_DEBUG - сообщения отладки.

Настройка Rsyslog в SberLinux

Все настройки Rsyslog находятся в файле /etc/rsyslog.conf и других конфигурационных файлах из /etc/rsyslog.d/. Можно посмотреть, существуют ли у вас эти файлы, выполнив:

ls /etc/rsys*

rsyslog.conf rsyslog.d/

Основной конфигурационный файл - /etc/rsyslog.conf, в нем подключены все файлы из папки /etc/rsyslog.d/ с помощью директивы IncludeConfig в самом начале файла:

IncludeConfig /etc/rsyslog.d/*.conf

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

Синтаксис конфигурационного файла прост:

$ переменная значение

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

ModLoad imuxsock # provides support for local system logging $ModLoad imklog # provides kernel logging support $ModLoad immark # provides --MARK-- message capability

provides UDP syslog reception

$ModLoad imudp $UDPServerRun 514

provides TCP syslog reception

$ModLoad imtcp $InputTCPServerRun 514

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

1. Модули ввода - можно рассматривать, как способ сбора информации из различных источников, начинаются с im.

2. Модули вывода - позволяют отправлять сообщения в файлы или по сети, или в базу данных, имя начинается на om;

3. Модули фильтрации - позволяют фильтровать сообщения по разным параметрам, начинаются с fm;

4. Модули parsing - предоставляют расширенные возможности для синтаксического анализа сообщения, начинаются с pm. Сначала загружается модуль imuxsock, который позволяет сервису получать сообщения из сокетов, а последующий загружаемый модуль imklog получает сообщения ядра. Модуль mark позволяет маркировать соединения или выводить сообщения о том, что syslog все еще работает. Например, можно дать указания rsyslog выводить сообщения каждые 20 минут:

MarkMessagePeriod 1200

Далее идут глобальные директивы:

ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat

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

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

FileOwner root
$FileGroup adm
$FileCreateMode 0640
$DirCreateMode 0755
$Umask 0022

После создания этих файлов их права можно менять, на те, которые необходимы.

Правила сортировки логов

Набор правил по умолчанию:

auth,authpriv.* /var/log/auth.log
*.*;auth,authpriv.none -/var/log/syslog
#cron.* /var/log/cron.log
daemon.* -/var/log/daemon.log
kern.* -/var/log/kern.log
lpr.* -/var/log/lpr.log
mail.* -/var/log/mail.log
user.* -/var/log/user.log

Каждое правило имеет свой синтаксис, сначала идет источник и приоритет, затем действие. Если источник и приоритет совпадают, сообщение отправляется в указанный файл. Например, можно отправить больше сообщений в лог системы /var/messages:

*.info;mail.none;authpriv.none;cron.none /var/log/messages

В этой строке выберите все сообщения уровня info, кроме mail, authpriv и cron. Шаблон mail.none означает, что ни один уровень сообщений не нужно логировать. Соответственно, конструкция *.info - означает, что логируются сообщения от всех источников, но только с уровнем info, а (точка) . - означает все сообщения, со всеми уровнями.

Источник и приоритет нечувствительны к регистру. Также приоритеты уровней error, warn и panic больше не используются, так как считаются устаревшими.

События в системном журнале группируются по источникам. В целом, в качестве источников можно использовать:

• auth;

• authpriv;

• cron;

• daemon;

• kern;

• lpr;

• mail;

• mark;

• news;

• security (эквивалентно auth);

• syslog;

• user;

• uucp;

• local0 ... local7.

Уровень событий задается приоритетом. А в качестве приоритетов можно применить:

• emerg (раньше panic);

• alert;

• crit;

• error (раньше err);

• warn (раньше warning);

• notice;

• info;

• debug.

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

Можно выполнять фильтрацию сообщений с помощью синтаксиса:

:поле, сравнение, "значение" путь_к_файлу

В качестве операции сравнения можно использовать такие варианты:

• contains — поле содержит указанное значение;

• isequal — поле должно быть идентичным значению;

• startswith — поле должно начинаться со значения;

• regex — сравнивает поле с регулярным выражением.

Например, отфильтруйте сообщения только от определенной программы:

:syslogtag, isequal, "giomanager:" /var/log/giomanager.log
& stop

Кроме того, можно использовать более простой синтаксис, в виде выражения if. Вот основной синтаксис:

if $поле сравнение 'значение' then файл

Здесь используются те же самые компоненты. Например:

if $syslogtag == 'giomanager' then /var/log/giomanager.log

Настройка syslog для удаленного логирования

Чтобы отправить лог на удаленный сервер, нужно указать @ и ip адрес удаленной машины, на которой запущен rsyslog:

*.info;mail.none;authpriv.none;cron.none @xx.xx.xx.xx:514

Где 514 - это порт, на котором осуществляется rsyslog. Настройка rsyslog на прием логов заключается в запуске сервиса с модулями imtcp и imudp.

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

if $fromhost-ip contains '192.168.1.10' then /var/log/proxyserver.log

Без фильтров, сообщения с разных машин будут писаться в один общий лог системы Sberlinux в зависимости от того как они будут распределены.

Просмотр логов с помощью командной строки#

Журнал - это компонент systemd, который помогает просматривать файлы журналов и управлять ими. Он решает проблемы, связанные с традиционным ведением журнала, тесно интегрирован с остальной частью системы и поддерживает различные технологии ведения журнала и управление доступом к файлам журнала.

Используйте команду journalctl для просмотра сообщений в системном журнале с помощью командной строки, например:

$ journalctl -b | grep kvm

May 15 11:31:41 localhost.localdomain kernel: kvm-clock: Using msrs 4b564d01 and 4b564d00

May 15 11:31:41 localhost.localdomain kernel: kvm-clock: cpu 0, msr 76401001, primary cpu clock

…

В таблицах ниже представлены команды для просмотра системной информации, информации о конкретных услугах и журналы, связанные с конкретными загрузками.

Таблица. Просмотр системной информации

Таблица. Просмотр информации о конкретных услугах

Таблица. Просмотр журналов, связанных с конкретными загрузками

Об устранении неполадок с помощью лог-файлов подробнее в разделе «Устранение неполадок с помощью лог-файлов».

Оболочки и инструменты командной строки#

Relax and Recover (ReaR) полностью поддерживается на 64-разрядной архитектуре. Базовая функциональность Relax and Recover (ReaR) полностью поддерживается rear версией пакета 2.6-9.el8 или более поздней. Резервное копирование и восстановление логических разделов (LPAR) на данный момент не поддерживается. ReaR поддерживает сохранение и восстановление структуры диска только на устройствах хранения данных с расширенным количеством ключей (ECKD) прямого доступа (DASD). Для этой цели не поддерживаются DASD-диски с фиксированным доступом (FBA) и диски SCSI, подключенные по протоколу Fibre Channel (FCP). В настоящее время доступен единственный метод вывода - начальная загрузка программы (IPL), который создает ядро и начальный диск оперативной памяти (initrd), совместимые с zIPL загрузчиком.

Управление программными пакетами#

Программные пакеты в SberLinux поставляются в виде rpm-пакетов или модулей (коллекций rpm-пакетов) через репозитории BaseOS и AppStream.

Репозиторий BaseOS#

BaseOS – это репозиторий, который содержит базовый набор программных пакетов, обеспечивающий основную функциональность операционной системы. Его содержимое доступно в виде rpm-пакетов.

Репозиторий AppStream#

Репозиторий AppStream содержит дополнительные приложения пользовательского пространства, языки различных сред выполнения, базы данных для поддержки различных рабочих нагрузок и пользовательских сценариев.

Пакеты AppStream доступны в одном из двух форматов: rpm и модули (расширение формата rpm).

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

Версии пакетов и модулей в AppStream поставляются и обновляются чаще, чем пакеты BaseOS. У каждой версии свой жизненный цикл. Это позволяет более гибко настраивать пользовательское пространство операционной системы, без ущерба стабильности работы базовой функциональности.

Модуль в AppStream может содержать несколько версий программных пакетов. Например, в модуле postgresql доступны все верси СУБД PostgreSQL: PostgreSQL 10 (по умолчанию) и PostgreSQL 9.6. В операционной системе может быть установлена только одна версия, но различные версии можно использовать в отдельных контейнерах.

Инструменты управления программным обеспечением#

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

Для утилиты YUM в SberLinux установка программного обеспечения поддерживается версией YUM tool (YUM v4), которая основана на технологии DNF.

YUM v4, используемый в SberLinux, совместим с YUM v3 при использовании из командной строки, редактировании или создании файлов конфигурации (подробнее в разделе «Настройка YUM и DNF»). Для установки программного обеспечения также используется команда yum и ее опции.

Совместимые пакеты YUM стали частью DNF и могут устанавливаться под теми же именами (которые являются символическими ссылками в рамках обеспечения совместимости), поэтому двоичные файлы, файлы конфигурации и каталоги расположены по умолчанию.

Устаревшие плагины YUM v3 несовместимы с YUM v4. Устаревший Python API, предоставляемый YUM v3, больше не доступен. Рекомендуется перенести плагины и скрипты на новый API, предоставляемый YUM v4 (DNF Python API), который является стабильным и полностью поддерживается.

Настройка YUM и DNF#

Информация о конфигурации для менеджеров пакетов YUM и DNF, а также связанных с ними утилит хранится в файлах /etc/yum.conf и /etc/dnf/dnf.conf в разделе [main] (единственный раздел в файлах). Пары ключ-значение в этом разделе влияют на работу пакетных меднеджеров с репозиториями. [main] содержит только те настройки, которые были явно заданы в данном разделе.

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

Для YUM:

yum config-manager --dump

Для DNF:

dnf config-manager --dump

Для изменения текущей конфигурации:

1. Откройте файл /etc/yum.conf или /etc/dnf/dnf.conf в текстовом редакторе.

2. Отредактируйте раздел [main] в соотвествии с требуемыми изменениями.

3. Сохраните файл.

Менеджеры пакетов позволяют использовать плагины для расширения функциональности и улучшения работы. Каждый устанавливаемый плагин может иметь свой собственный файл конфигурации в каталоге /etc/dnf/plugins/. Название файла конфигурации должно соотвествовать шаблону <plug-in_name>.conf, где <plug-in_name> - название подключаемого плагина. Чтобы отключить плагин необходимо в таком файле в режиме редактирования добавить:

[main]
enabled=False

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

Для отключения всех подключаемых плагинов:

1. Откройте файл /etc/yum.conf или /etc/dnf/dnf.conf в текстовом редакторе.

2. Добавьте параметр plugins=1 (значение по умолчанию) в раздел `[main].

3. Сохраните файл.

Для включения всех подключаемых плагинов необходимо параметру plugins установить значение 0.

Для отключения конкретного плагина:

1. Откройте файл /etc/dnf/plugins/<plug-in_name>.conf в текстовом редакторе.

2. Добавьте параметр enabled=False в раздел `[main].

3. Сохраните файл.

Для отключения всех плагинов для конкретной команды добавьте параметр --noplugins при вводе. Например, чтобы отключить все плагины для команды update введите:

dnf --noplugins update

Для отключения определенных плагинов для конкретной команды добавьте при вводе параметр --disableplugin=<plugin-name>, где <plugin-name> – название плагина. Например, чтобы отключить плагин <plugin-name> для команды update введите:

dnf update --disableplugin=<plugin_name>

Для включения определенных плагинов для конкретной команды добавьте при вводе параметр --enableplugin=<plugin-name>. Например, чтобы включить плагин <plugin-name> для команды update введите:

dnf update --enableplugin=<plugin_name>

Поиск и отображение информации с использованием с YUM и DNF#

Менеджеры пакетов в SberLinux позволяют осуществлять поиск информации о программных пакетах и модулях, установленных в системе, а также в репозиториях AppStream и BaseOS.

Поиск программных пакетов#

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

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

dnf search <term>

где <term> - название пакета или термин, который к нему относится.

Команда dnf search возвращает совпадения терминов в зоне поиска, указанной выше. Это ускоряет поиск и позволяет искать пакеты, название которых неизвестно, но известен связанный по смыслу термин.

Чтобы добавить в зону поиска полное описание пакетов введите:

dnf search --all <term>

Опция --all обеспечивает более исчерпывающий, но более медленный поиск.

Чтобы выполнить поиск по названию пакета в перечне пакетов в репозиториях введите:

dnf repoquery <package_name>

где <package_name> – название пакета.

Вывод команды также будет содержать версию этого пакета.

Для поиска пакета по файлу, который ему принадлежит, введите:

dnf provides <file_name>

где <file_name> – имя файла или путь к этому файлу.

Отображение перечня программных пакетов#

YUM и DNF можно использовать для отображения перечня пакетов и их версий, доступных в репозиториях. При необходимости список пакетов можно отфильтровать, оставив, например, только те пакеты, для которых доступны обновления.

Для вывода всех доступных пакетов, включая их архитектуру, версии и репозитории, из которых они установлены, введите:

dnf list --all

Знак @ перед указанием репозитория говорит о том, что пакет в данный момент установлен в системе.

Для того, чтобы отфильтровать список пакетов, вместо --all используйте параметры:

• --installed для формирования списка установленных пакетов в системе;

• --available для формирования списка пакетов, доступных для установки в репозиториях;

• --upgrades для формирования списка пакетов, для которых доступны новые версии для установки.

Результаты работы команды можно дополнительно отфильтровать с использованием глобальных выражений в качестве аргументов. Подробнее в разделе «Использование глобальных выражений для дополнительной фильтрации».

Отображение перечня репозиториев#

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

Для вывода списка всех включенных репозиториев введите:

dnf repolist

Для вывода списка отключенных репозиториев добавьте к команде выше параметр --disabled, для вывода списка включенных и отключенных репозиториев – параметр --all.

Чтобы отобразить дополнительную информацию о репозиториях, введите:

dnf repoinfo <repository_name>

где <repository_name> - название репозитория.

Результаты также можно дополнительно отфильтровать с использованием глобальных выражений. Подробнее в разделе «Использование глобальных выражений для дополнительной фильтрации».

Вывод информации о пакетах#

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

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

dnf info <package_name>

где <package_name> название пакета.

Дополнительно отфильтровать результаты можно с использованием глобальных выражений. Подробнее в разделе «Использование глобальных выражений для дополнительной фильтрации».

Вывод информации о группах пакетов#

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

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

dnf group list

Отфильтровать результаты команды dnf group list возможно с помощью параметров --installed и --available. Параметр --hidden при вводе команды позволит отобразить скрытые группы.

Для просмотра количества установленных и доступных групп введите:

dnf group summary

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

dnf group info "<group_name>"

где <group_name> – название нужной группы.

Дополнительно результаты можно отфильтровать с использованием глобальных выражений. Подробнее в разделе «Использование глобальных выражений для дополнительной фильтрации».

Отображение информации о модулях и их содержимом#

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

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

dnf module list

Для просмотра аналогичной информации для определенного модуля введите:

dnf module list <module_name>

где <module_name> - название нужного модуля.

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

dnf module provides <package_name>

где <package_name> - название нужного пакета.

Для вывода информации о модуле, включая его описание, перечень профилей и список всех входящих в него пакетов, введите:

dnf module info <module_name>

где <module_name> - название нужного модуля.

Для вывода перечня пакетов, соотвествующих каждому профилю, введите:

dnf module info --profile <module_name>

где <module_name> - название нужного модуля.

Использование глобальных выражений для дополнительной фильтрации#

С помощью добавления глобальных выражений в качестве аргументов можно фильтровать результаты выполнения dnf и yum команд.

При использовании глобальных выражений:

• заключите глобальное выражение целиком в одинарные или двойные кавычки:

  dnf module info --profile <module_name>
  

• экранируйте подстановочные знаки, поставив перед ними символ обратной косой черты ():

  dnf provides \*/<file_name>
  

  где <file_name> – имя используемого файла.

Установка программных пакетов#

1. Чтобы установить пакет и все зависимости этого пакета, используйте:

package-name

Замените package-name на необходимое название пакета.

2. Чтобы установить несколько пакетов и их зависимостей одновременно, используйте:

# yum install package-name-1 package-name-2

Замените package-name-1 и package-name-2 на необходимые названия пакетов.

3. Если известно имя двоичного файла, который нужно установить, но не имя пакета, используйте путь к двоичному файлу в качестве аргумента:

# yum install /usr/sbin/binary-file

Замените /usr/sbin/binary-file на путь к двоичному файлу.

yum просматривает списки пакетов, находит пакет, который предоставляет /usr/sbin/binary-file и запрашивает разрешение на установку.

4. Чтобы установить ранее загруженный пакет из локального каталога, используйте:

# yum install **/path/**

Замените /path/ на путь к пакету.

Следующая сценарий описывает, как установить группу пакетов по имени группы или с помощью идентификатора группы yum.

Сценарий:

1. Чтобы установить группу пакетов по имени группы, используйте:

# yum group install group-name

Или

# yum install @group-name

Замените group-name названием группы или группы необходимой среды.

2. Чтобы установить группу пакетов по идентификатору группы, используйте:

# yum group install

Замените groupId идентификатором группы.

Чтобы оптимизировать процесс установки и удаления, добавьте -n, -na, или -nevra суффиксы к y um install yum remove командам и, чтобы явно определить, как анализировать аргумент.

1. Чтобы установить пакет, используя его точное имя, используйте:

# yum install-n

Замените -n на необходимое имя пакета.

2. Чтобы установить пакет, используя его точное имя и архитектуру, используйте:

# yum install-na name.architecture

Замените name.architecture необходимым именем и архитектурой пакета.

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

yum install-nevra name-epoch:version-release.architecture

Замените name-epoch:version-release.architecture необходимым именем, временем, версией, выпуском и архитектурой пакета.

Обновление программных пакетов#

Следующий сценарий описывает, как проверить доступные обновления для пакетов, установленных в системе, с помощью yum.

Сценарий:

1. Чтобы узнать, какие пакеты, установленные в системе, имеют доступные обновления, используйте:

yum check-update

Выходные данные возвращают список пакетов и их зависимостей, для которых доступно обновление.

Используйте следующий сценарий для обновления одного пакета и его зависимостей с помощью yum.

2. Чтобы обновить пакет, используйте:

package-name

Замените package-name на необходимое имя пакета.

Обновление группы пакетов с помощью YUM

Используйте следующий сценарий для обновления группы пакетов и их зависимостей с помощью yum.

Сценарий

• Чтобы обновить группу пакетов, используйте:

yum group update group-name

Заменить название группы с именем группы пакетов.

Обновление всех пакетов и их зависимостей с помощью YUM

Используйте следующий сценарий для обновления всех пакетов и их зависимостей с помощью yum.

Сценарий:

• Чтобы обновить все пакеты и их зависимости, используйте:

yum update

Обновление пакетов, связанных с безопасностью, с помощью YUM

Используйте следующий сценарий для обновления пакетов доступные пакеты, содержащие ошибки безопасности, используя yum.

Сценарий:

• Чтобы перейти на последние доступные пакеты, содержащие ошибки безопасности, используйте:

yum update --security

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

yum update-minimal --security

Автоматизация обновления программного обеспечения

Чтобы автоматически и регулярно проверять и загружать обновления пакетов, используйте DNF Automatic (Автоматический), который предоставляется dnf-automatic.

DNF Automatic (Автоматический) является альтернативным интерфейсом командной строки для yum, который подходит для автоматического и регулярного выполнения с использованием системных таймеров, заданий cron и других подобных инструментов.

DNF Automatic (Автоматический) синхронизирует метаданные пакета по мере необходимости, а затем проверяет наличие доступных обновлений. После этого инструмент может выполнить одно из следующих действий в зависимости от того, как оно настроено:

• Выход.

• Загрузку обновленных пакетов.

• Загрузку и применение обновления.

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

Установка автоматического DNF

Следующий сценарий описывает, как установить DNF Automatic инструмент.

Сценарий:

• Для установки dnf-automatic, используйте:

yum install dnf-automatic

Этапы проверки:

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

rpm -qi dnf-automatic

Файл автоматической конфигурации DNF

По умолчанию, DNF Automatic использует /etc/dnf/automatic.conf в качестве его конфигурационного файла для определения его поведения.

Файл конфигурации разделен на следующие тематические разделы:

• Раздел [commands]. Устанавливает режим работы DNF Автоматический.

• Раздел [emitters]. Определяет, как результаты сообщений DNF Automatic.

• Раздел [command_email]. Предоставляет конфигурацию отправителя электронной почты для внешней команды, используемой для отправки электронной почты.

• Раздел [email]. Предоставляет конфигурацию отправителя электронной почты.

• Раздел [base]. Переопределяет настройки из основного конфигурационного файла yum.

При настройках файла /etc/dnf/automatic.conf по умолчанию DNF автоматически проверяет наличие доступных обновлений, загружает их и сообщает о результатах в виде стандартного вывода.

Включение автоматического DNF

Сценарий:

Выберите, включите и запустите системный таймер, который соответствует потребностям:

systemctl enable --now <unit>

Где unit является одним из следующих таймеров:

• dnf-automatic-download.timer

• dnf-automatic-install.timer

• dnf-automatic-notifyonly.timer

• dnf-automatic.timer

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

systemctl enable dnf-automatic-download.timer

systemctl start dnf-automatic-download.timer

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

systemctl enable dnf-automatic-install.timer

systemctl start dnf-automatic-install.timer

Для отчетности о доступных обновлениях, используйте:

systemctl enable dnf-automatic-notifyonly.timer

systemctl start dnf-automatic-notifyonly.timer

При необходимости используйте:

systemctl enable dnf-automatic.timer

systemctl start dnf-automatic.timer

Что касается загрузки и применения обновлений, этот блок таймера работает в соответствии с настройками в /etc/dnf/automatic.conf конфигурационный файл. Поведение по умолчанию аналогично dnf-automatic-download.timer: он загружает обновленные пакеты, но не устанавливает их.

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

systemctl status <systemd timer unit>

Дополнительные ресурсы:

Для получения более подробной информации о блоках таймера systemd см. руководство man dnf-automatic(8).

Обзор блоков таймера systemd, входящих в комплект поставки dnf-automatic

Блоки таймера systemd имеют приоритет и переопределяют настройки, касающиеся загрузки и применения обновлений в конфигурационном файле /etc/dnf/automatic.conf.

Например, если установлен следующий параметр в конфигурационный файл /etc/dnf/automatic.conf, но активирован dnf-automatic-notifyonly.timer unit, пакеты не будут загружены:

download_updates = yes.

В dnf-automatic пакет включает в себя следующие блоки таймера systemd, которые представлены в таблице.

Таблица. Блоки таймера systemd в dnf-automatic пакете

Удаление программных пакетов#

Удаление пакетов с YUM

Используйте следующий сценарий, чтобы удалить пакет либо по имени группы, либо по идентификатору группы.

Сценарий:

1. Чтобы удалить определенный пакет и все зависимые пакеты, используйте:

yum remove package-name

Замените package-name на необходимое название пакета.

2. Чтобы удалить несколько пакетов и их зависимости одновременно, используйте:

yum remove package-name-1 package-name-2

Замените package-name-1 и package-name-2 на необходимые названия пакетов.

Удаление группы пакетов с помощью YUM

Используйте следующий сценарий, чтобы удалить пакет либо по имени группы, либо по идентификатору группы.

Сценарий:

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

yum group remove group-name

Или

yum remove @group-name

Замените group-name необходимым названием группы.

3. Чтобы удалить группу пакетов по идентификатору группы, используйте:

yum group remove

Замените groupId идентификатором группы.

Указание имени пакета во входных данных YUM

Чтобы оптимизировать процесс установки и удаления, добавьте -n, -na, или -nevra суффиксы к yum install yum remove командам и, чтобы явно определить, как анализировать аргумент:

1. Чтобы установить пакет с необходимым именем, используйте:

yum install-n

Замените -n на необходимое имя пакета.

2. Чтобы установить пакет с необходимым именем и архитектурой, используйте:

yum install-na name.architecture

Замените name.architecture необходимым именем и архитектурой пакета.

3. Чтобы установить пакет с необходимым именем, временем, версией, выпуском и архитектурой, используйте:

yum install-nevra name-epoch:version-release.architecture

Замените epoch:version-release.architecture необходимым именем, временем, версией, выпуском и архитектурой пакета.

Управление группами пакетов программного обеспечения#

Группа пакетов - это набор пакетов, которые служат общей цели (системные инструменты, звук и видео). При установке группы пакетов извлекается набор зависимых пакетов, что значительно экономит время.

Перечисление групп пакетов с помощью YUM

Используйте yum для просмотра установленных групп пакетов и фильтрации результатов листинга.

Сценарий:

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

yum group summary

2. Чтобы перечислить все установленные и доступные группы, используйте:

yum group list

4. Чтобы перечислить обязательные и необязательные пакеты, содержащиеся в определенной группе, используйте:

yum group info group-name

Замените group-name на необходимое название группы.

Установка группы пакетов с помощью YUM

Следующий сценарий описывает, как установить группу пакетов по имени группы или с помощью идентификатора группы yum.

Сценарий:

1. Чтобы установить группу пакетов по имени группы, используйте:

yum group install group-name

Или

yum install @group-name

Замените group-name необходимым названием группы.

2. Чтобы установить группу пакетов по идентификатору группы, используйте:

yum groupId install

Замените groupId идентификатором группы.

Удаление группы пакетов с помощью YUM

Используйте следующий сценарий, чтобы удалить пакет либо по имени группы, либо по идентификатору группы.

Сценарий:

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

yum group remove group-name

Или

yum remove @group-name

Замените group-name полным названием группы.

2. Чтобы удалить группу пакетов по идентификатору группы, используйте:

yum groupId remove

Замените groupId идентификатором группы.

Указание глобальных выражений во входных данных YUM

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

Сценарий:

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

Заключите все глобальное выражение в двойные или одинарные кавычки.

yum provides "*/file-name".

Замените file-name необходимым именем файла.

2. Экранируйте подстановочные знаки, поставив перед ними символ обратной косой черты (\ слеш).

yum provides \*/file-name

Замените file-name необходимым именем файла.

Обработка истории управления пакетами#

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

Листинг сделок с YUM

Используйте следующий сценарий, чтобы перечислить последние транзакции, последние операции для выбранного пакета и сведения о конкретной транзакции.

Сценарий:

1. Чтобы отобразить список всех последних транзакций yum, используйте:

yum history

2. Чтобы отобразить список всех последних операций для выбранного пакета, используйте:

yum history list package-name

Замените package-name на необходимое имя пакета.

3. Чтобы проверить конкретную транзакцию, используйте:

yum history info transactionID

Замените transactionID на необходимый идентификатор транзакции.

Возврат транзакций с помощью YUM

Следующий сценарий описывает, как отменить выбранную транзакцию или последнюю транзакцию с помощью yum.

Сценарий:

1. Чтобы отменить конкретную транзакцию, используйте:

yum history undo transactionID

Замените transactionID на необходимый идентификатор транзакции.

2. Чтобы отменить последнюю транзакцию, используйте:

yum history undo last

Повторяющиеся транзакции с YUM

Используйте следующий сценарий, чтобы повторить выбранную транзакцию или последнюю используемую транзакцию yum.

Сценарий:

1. Чтобы повторить определенную транзакцию, используйте:

yum history redo transactionID

Замените transactionID на необходимый идентификатор транзакции.

2. Чтобы повторить последнюю транзакцию, используйте:

yum history redo last

Указание глобальных выражений во входных данных YUM

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

Сценарий:

Чтобы убедиться, что глобальные выражения передаются по назначению yum, используйте один из следующих методов:

1. Заключите глобальное выражение (как на примере: "/file-name") в двойные или одинарные кавычки.

yum provides "*/file-name".

Замените file-name необходимым именем файла.

2. Экранируйте подстановочные знаки, поставив перед ними символ обратной косой черты (\ слеш).

yum provides \*/file-name

Замените file-name необходимым именем файла.

Полный список доступных разделов [repository] см. в [repository] OPTIONS разделе руководства man yum.conf(5).

Управление репозиториями программного обеспечения#

Информация о конфигурации для yum и связанных с ней утилит хранится в файле /etc/yum.conf. Этот файл содержит один или несколько разделов [repository], которые позволяют устанавливать параметры, зависящие от репозитория. Рекомендуется определять отдельные репозитории в новых или существующих .repo файлах в /etc/yum.repos.d/ каталоге.

Конфигурационный файл /etc/yum.conf содержит разделы [repository], где repository - это уникальный идентификатор репозитория. Разделы [repository] позволяют определять отдельные репозитории yum.

Добавление репозитория YUM

Сценарий:

1. Чтобы определить новый репозиторий, сделайте следующие шаги:

Добавьте раздел [repository] в файл /etc/yum.conf.

Добавьте раздел [repository] в .repo файл в каталоге /etc/yum.repos.d/.

+

репозитории yum обычно предоставляют свой собственный .repo файл.

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

yum-config-manager --add-repo repository_URL

Замените repository_url URL-адресом, указывающим на репозиторий.

Включение репозитория YUM

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

Сценарий:

1. Чтобы включить репозиторий, используйте:

yum-config-manager --enable repositoryID

Замените repositoryID на необходимый идентификатор репозитория.

Отключение репозитория YUM

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

Сценарий:

Чтобы отключить репозиторий yum, используйте:

yum-config-manager --disable repositoryID

Замените repositoryID на необходимый идентификатор репозитория.

Ключи находятся в папке /etc/pki/rpm-gpg/, чтобы пользователь не менял настройки операционной системы. В этом случае смена ключей для подписи незаметна для пользователя. При установке rpm-пакетов из этой папки пользователи могут выделять ключи для проверки подписи пакетов.

Systemd#

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

• параллельный запуск системных служб во время загрузки;

• активацию демонов по требованию;

• логику управления сервисом на основе зависимостей.

Типы юнитов systemd#

В качестве представления системных ресурсов и сервисов systemd вводится понятие systemd units (по тексту юнит, см. «Термины и определения»). Юнит systemd выполняет или управляет определенной задачей, и является основным объектом для управления systemd. Ниже приведены следующие примеры различных типов юнитов systemd:

• обслуживание;

• цель;

• устройство;

• монтирование;

• таймер;

• другие типы, которые имеют отношение к системе инициализации.

systemctl -t help

Юнит systemd состоит из имени, типа и файла конфигурации, который определяет задачу юнита. Файлы конфигурации юнитов расположены в одном из каталогов, перечисленных в следующей таблице.

Таблица. Расположение юнит-файлов systemd

Systemd основные функции#

Конфигурация systemd по умолчанию определяется во время компиляции, конфигурация расположена в файле /etc/systemd/system.conf. Используйте этот файл для переопределения выбранных значений юнитов systemd по умолчанию. Например, чтобы переопределить значение ограничения времени ожидания по умолчанию, которое установлено равным 90 секундам, используйте параметр DefaultTimeoutStartSec для ввода требуемого значения в секундах.

DefaultTimeoutStartSec=required value

Управление системными службами с помощью systemctl#

Управление юнит-файлом с помощью systemctl#

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

Сценарий:

1. Чтобы отобразить подробную информацию о юнит-файле, соответствующем системной службе, введите:

systemctl status <name>.service

2. Замените на имя юнит-файла, который нужно проверить (например, gdm).

Эта команда отображает имя выбранного юнит-файла, за которым следует его краткое описание и описание журналов, заполняемых root пользователем. Доступная информация о сервисном юните представлена в таблице ниже.

Таблица. Доступная информация о сервисном юните

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

$ systemctl is-active <name>.service

4. Чтобы определить, включен ли конкретный юнит, введите:

$ systemctl is-enabled <name>.service

5. Чтобы определить, какие службы заказываются для запуска до указанного юнит-файла, введите:

systemctl list-dependencies --after <name>.service

Замените <name> на имя службы в команде.

6. Чтобы определить, какие службы заказываются для запуска после указанной единицы обслуживания, введите:

systemctl list-dependencies --before <name>.service

Замените на имя службы в команде.

Сравнение сервисной утилиты с systemctl#

systemctl - команда управления менеджером системы Systemd.

service - команда управления Upstart.

В таблице ниже представлено сравнение утилиты service с systemd.

Таблица. Сравнение утилиты service с systemd

Список системных сервисов#

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

Сценарий:

• Чтобы вывести список всех загруженных в данный момент юнит-файлов, выполните следующую команду::

UNIT LOAD ACTIVE SUB DESCRIPTION

abrt-ccpp.service loaded active exited Install ABRT coredump hook

abrt-oops.service loaded active running ABRT kernel log watcher

abrtd.service loaded active running ABRT Automated Bug Reporting Tool

----

systemd-vconsole-setup.service loaded active exited Setup Virtual Console

tog-pegasus.service loaded active running OpenPegasus CIM Server

LOAD = Reflects whether the unit definition was properly loaded.

ACTIVE = The high-level unit activation state, i.e. generalization of SUB.

SUB = The low-level unit activation state, values depend on unit type.

46 loaded units listed. Pass --all to see loaded but inactive units, too.

To show all installed unit files use 'systemctl list-unit-files'

По умолчанию команда systemctl list-units отображает только активные объекты. Для каждого файла юнит-файла отображается команда, где:

• UNIT: его полное название.

• LOAD: информация о том, был ли загружен юнит-файл.

• ACTIVE или SUB: состояние активации его высокоуровневого и низкоуровневого firewalld-filesystem.

• DESCRIPTION: краткое описание.

• Чтобы вывести список всех загруженных объектов независимо от их состояния, введите следующую команду с параметром –all из командной строки или:

systemctl list-units --type service --all

• Чтобы перечислить состояние (включено или отключено) всех доступных сервисных устройств, введите:

$ systemctl list-unit-files --type service

UNIT FILE STATE

abrt-ccpp.service enabled

abrt-oops.service enabled

abrtd.service enabled

...

wpa_supplicant.service disabled

ypbind.service disabled

208 unit files listed.

Для каждого сервисного подразделения эта команда отображает:

• UNIT FILE: его полное название.

• STATE: информация о том, включен или отключен юнит-файл.

Отображение статуса системной службы#

Чтобы отобразить юнит-файл, который systemd загрузила в систему, можно использовать команду cat. Например, чтобы увидеть файл модуля демона-планировщика atd, можно ввести следующее:

systemctl cat atd.service
Output
[Unit]
Description=ATD daemon
[Service]
Type=forking
ExecStart=/usr/bin/atd
[Install]
WantedBy=multi-user.target

Положительные и отрицательные сервисные зависимости#

Чтобы увидеть дерево зависимостей модуля, можно использовать команду list-dependencies:

systemctl list-dependencies sshd.service

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

Output
sshd.service
─system.slice
─basic.target
├─microcode.service
├─sberlinux-autorelabel-mark.service
├─sberlinux-autorelabel.service
├─sberlinux-configure.service
├─sberlinux-dmesg.service
├─sberlinux-loadmodules.service
├─paths.target
├─slices.target
. . .

Рекурсивные зависимости отображаются только для модулей .target, которые указывают состояние системы. Чтобы рекурсивно перечислить все зависимости, добавьте флажок –all.

Чтобы отобразить обратные зависимости (модули, зависящие от указанного модуля), можно добавить в команду флажок –reverse. Другие флажки –before и –after могут быть использованы для отображения модулей, которые зависят от указанного модуля, соответственно, перед ними и после.

Кроме systemd, существуют положительные и отрицательные зависимости между службами. Запуск конкретной службы может потребовать запуска одной или нескольких других служб (положительная зависимость) или остановки одной, или нескольких служб (отрицательная зависимость).

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

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

Запуск системной службы#

Запустите системную службу в текущем сеансе с помощью команды start.

Предварительные условия:

Права root пользователя.

Сценарий:

1. Чтобы запустить выбранный юнит-файл, соответствующий системной службе, введите следующую команду как root пользователь:

systemctl start <name>.service

2. Замените на имя юнит-файла, который запускаете (например, httpd.service).

Остановка системной службы#

Остановите системную службу в текущем сеансе, используйте команду stop.

Предварительные условия:

Права root пользователя.

Сценарий:

1. Чтобы остановить юнит-файл, соответствующий системной службе, введите следующую команду, как root пользователь:

systemctl stop <name>.service

2. Замените на имя юнит-файла, который нужно остановить (например, на bluetooth).

Перезапуск системной службы#

Можно перезапустить системную службу в текущем сеансе с помощью команды restart:

• Остановите выбранный юнит-файл в текущем сеансе и немедленно запустите его снова.

• Перезапускайте юнит-файл только в том случае, если соответствующая служба уже запущена.

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

Предварительные условия:

Права root пользователя.

Сценарий:

1. Перезапустите юнит-файл, соответствующий системной службе:

systemctl restart <name>.service

2. Замените на имя юнит-файла, который нужно перезапустить (например, на httpd).

3. Перезапустите юнит-файл, если соответствующая служба уже запущена:

systemctl try-restart <name>.service

4. В качестве альтернативы, перезагрузите конфигурацию, не прерывая выполнение службы:

systemctl reload <name>.service

Включение системной службы#

Можно настроить службу на автоматический запуск во время загрузки системы. Команда enable считывает раздел [Install] выбранного юнит-файла и создает соответствующие символические ссылки на файл / usr/lib/systemd/system/name.service в /etc/systemd/system/ каталоге и его подкаталогах. Однако он не перезаписывает ссылки, которые уже существуют.

Предварительные условия:

Права root пользователя.

Сценарий:

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

systemctl enable <name>.service

2. Замените на имя юнит-файла, который нужно включить (например, на httpd).

3. При необходимости повторно включите системный блок:

systemctl reenable <name>.service

Эта команда отключает выбранный юнит-файл и немедленно включает его снова.

Отключение системной службы#

Можно запретить автоматический запуск юнит-файла во время загрузки. Команда disable считывает раздел [Install] выбранного юнит-файла и удаляет соответствующие символические ссылки на файл / usr/lib/systemd/system/name.service из /etc/systemd/system/ каталога и его подкаталогов.

Предварительные условия:

Права root пользователя.

Сценарий:

1. Чтобы настроить юнит-файл, соответствующий системной службе, чтобы он не запускался автоматически во время загрузки, введите команду, как root пользователь:

systemctl disable <name>.service

2. Замените на имя юнит-файла, который нужно отключить (например, на bluetooth).

3. При необходимости замаскируйте любой юнит-файл и запретите его запуск вручную или с помощью другой службы:

systemctl mask <name>.service

Эта команда заменяет файл / etc/systemd/system/name.service символической ссылкой на /dev/null, делая фактический юнит-файл недоступным systemd.

4. Чтобы отменить это действие и снять маску с юнит-файла, введите:

systemctl unmask <name>.service

Работа с целями systemd#

Цели systemd действуют как точки синхронизации во время запуска системы. Файлы целевых модулей, которые заканчиваются .target расширением файла, представляют systemd цели. Назначением целевых модулей является группировка различных systemd модулей через цепочку зависимостей.

Просмотр цели по умолчанию#

Можно отобразить цель по умолчанию с помощью systemctl команды или просмотреть /etc/systemd/system/default.target файл, представляющий целевую единицу по умолчанию.

Процедура

• Определите, какая целевая единица используется по умолчанию:

$ systemctl get-default
graphical.target

• Определите цель по умолчанию, используя символическую ссылку:

$ ls -l /usr/lib/systemd/system/default.target

Просмотр целевых модулей#

Можно отобразить все типы модулей или ограничить поиск текущими загруженными целевыми модулями. По умолчанию команда отображает только активные модули.

Процедура:

• Список всех загруженных модулей независимо от их состояния:

$ systemctl list-units --type target --all

• В качестве альтернативы, перечислите все загруженные в данный момент целевые устройства:

$ systemctl list-units --type target

UNIT                  LOAD   ACTIVE SUB    DESCRIPTION
basic.target          loaded active active Basic System
cryptsetup.target     loaded active active Encrypted Volumes
getty.target          loaded active active Login Prompts
graphical.target      loaded active active Graphical Interface
local-fs-pre.target   loaded active active Local File Systems (Pre)
local-fs.target       loaded active active Local File Systems
multi-user.target     loaded active active Multi-User System
network.target        loaded active active Network
paths.target          loaded active active Paths
remote-fs.target      loaded active active Remote File Systems
sockets.target        loaded active active Sockets
sound.target          loaded active active Sound Card
spice-vdagentd.target loaded active active Agent daemon for Spice guests
swap.target           loaded active active Swap
sysinit.target        loaded active active System Initialization
time-sync.target      loaded active active System Time Synchronized
timers.target         loaded active active Timers

LOAD   = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB    = The low-level unit activation state, values depend on unit type.

17 loaded units listed.

Изменение цели по умолчанию#

Целевая единица по умолчанию представлена /etc/systemd/system/default.target файлом. Следующая процедура описывает, как изменить цель по умолчанию с помощью команды systemctl:

Процедура

1. Чтобы определить целевой модуль по умолчанию:

# systemctl get-default

2. Чтобы настроить систему на использование другого целевого устройства по умолчанию:

# systemctl set-default multi-user.target
rm /etc/systemd/system/default.target
ln -s /usr/lib/systemd/system/multi-user.target /etc/systemd/system/default.target

Команда заменяет /etc/systemd/system/default.target файл символической ссылкой на /usr/lib/systemd/system/name.target, где name — это имя целевого устройства, которое нужно использовать. Замените multi-user на имя целевого устройства, которое нужно использовать по умолчанию.

# systemctl set-default multi-user.target
rm /etc/systemd/system/default.target
ln -s /usr/lib/systemd/system/multi-user.target /etc/systemd/system/default.target

Общие цели для set-default команды (см.таблицу ниже)

Сделайте Reboot.

# reboot

Дополнительные ресурсы:

С правочные страницы: systemd.special, bootup.

Изменение цели по умолчанию с помощью символической ссылки#

Можно изменить цель по умолчанию, создав символическую ссылку на нужную цель.

Процедура:

1. Определите целевой модуль по умолчанию:

# ls -l /etc/systemd/system/default.target

Обратите внимание, что в некоторых случаях /etc/systemd/system/default.target ссылка может не существовать, и systemd ищет целевой модуль по умолчанию в файлах /usr. В таких случаях определите целевой модуль по умолчанию с помощью следующей команды:

# ls -l /usr/lib/systemd/system/default.target

2. Удалите /etc/systemd/system/default.target ссылку:

# rm /etc/systemd/system/default.target

3. Создайте символическую ссылку:

# ln -sf /usr/lib/systemd/system/graphical.target /etc/systemd/system/default.target

4. Перезагрузите систему.

Этапы проверки

• Проверьте только что созданный default.target (целевой модуль):

$ systemctl get-default
multi-user.target

Изменение текущей цели#

Когда установлен целевой модуль по умолчанию, текущая цель остается неизменной до следующей перезагрузки. Если нужно изменить целевой модуль в текущем сеансе без перезагрузки, используйте команду systemctl isolate.

Процедура:

• Перейдите к другому целевому модулю в текущем сеансе:

# systemctl isolate multi-user.target

Эта команда запускает целевой модуль с именем multi-user и все зависимые модули, и немедленно останавливает все остальные.

Замените multi-user на имя целевого устройства, которое нужно использовать по умолчанию.

Этапы проверки:

Проверьте только что созданный default.target (целевой модуль):

$ systemctl get-default
multi-user.target

Загрузка в режиме восстановления#

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

Процедура:

Чтобы войти в режим восстановления, измените текущую цель в текущем сеансе:

# systemctl rescue

Broadcast message from root@localhost on pts/0 (Fri 2013-10-25 18:23:15 CEST):

The system is going down to rescue mode NOW!

systemctl --no-wall rescue

Загрузка в аварийном режиме#

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

Процедура

Чтобы войти в аварийный режим, измените текущую цель:

# systemctl emergency

systemctl --no-wall emergency

Завершение работы, приостановка и перевод системы в спящий режим#

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

Выключение системы#

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

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

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

• Возможность отменить выключение.

Выключение системы с помощью команды shutdown#

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

Предварительные условия:

Права root пользователя.

Процедура:

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

shutdown --poweroff hh:mm

Где hh:mm (чч:мм) — время в 24-часовом формате. Файл /run/nologin создается за 5 минут до выключения системы, чтобы предотвратить новые входы в систему.

Когда используется аргумент времени, к команде может быть добавлено необязательное сообщение на экране.

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

shutdown --halt +m

Где +m — время задержки в минутах. Ключевое слово now является псевдонимом для +0.

Чтобы отменить отложенное завершение работы, используйте:

shutdown -c

Выключение системы с помощью команды systemctl#

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

Предварительные условия:

Права root пользователя.

Процедура:

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

systemctl poweroff

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

systemctl halt

Перезапуск системы#

Можно перезапустить систему, выполнив эту процедуру.

Предварительные условия:

Права root пользователя.

Процедура:

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

systemctl reboot

Приостановка системы#

Можно приостановить работу системы, выполнив процедуру, описанную ниже.

Предварительные условия:

Права root пользователя.

Процедура:

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

systemctl suspend

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

Поскольку состояние системы сохраняется в ОЗУ, а не на жестком диске, восстановление системы из режима ожидания происходит значительно быстрее, чем из режима гибернации (выключение системы при сохранении ее состояния). Однако обратите внимание, что приостановленное состояние системы также уязвимо для перебоев в подаче электроэнергии.

Спящий режим системы#

Следуя этой процедуре, можно либо перевести систему в спящий режим, либо перевести ее в спящий режим и приостановить работу системы.

Предварительные условия:

Права root пользователя.

Процедура:

Чтобы перевести систему в спящий режим, выполните следующую команду:

systemctl hibernate

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

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

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

systemctl hybrid-sleep

Обзор команд управления питанием с помощью systemctl#

Можно использовать следующий список команд systemctl для управления питанием системы.

Обзор команд управления питанием systemctl (см. таблицу ниже):

Работа с юнит-файлами systemd#

Эта глава включает описание юнитов systemd. В следующих разделах показано:

• Создание пользовательских юнит-файлов.

• Изменение существующих юнит-файлов.

• Работа с юнитами systemd.

Юнит-файлы#

Юнит-файл содержит директивы конфигурации, которые описывают сам юнит и определяют его поведение. Несколько systemctl команд работают с юнитами в фоновом режиме. Для более точной настройки юнитов системный администратор должен отредактировать или создать юнит-файлы вручную. Расположение юнитов systemd предоставляет три основных каталога, в которых хранятся юниты в системе. Этот /etc/systemd/system/ каталог зарезервирован для юнитов, созданных или настроенных системным администратором.

Имена юнит-файлов имеют следующую форму:

unit_name . type_extension

Здесь unit_name обозначает имя юнит-файла, а type_extension определяет тип юнит-файла.

Например, в системе обычно есть sshd.service и sshd.socket устройство.

Юнит-файлы могут быть дополнены каталогом дополнительных файлов конфигурации. Например, чтобы добавить пользовательские параметры конфигурации в sshd.service, создайте sshd.service.d/custom.conf файл и вставьте в него дополнительные директивы. Дополнительные сведения о каталогах конфигурации см. в разделе «Изменение существующих юнит-файлов».

Многие разделы юнит-файла можно задать с помощью так называемых спецификаторов юнита — строк с подстановочными знаками, которые динамически заменяются параметрами юнита при загрузке юнит-файла. Это позволяет создавать общие юнит-файлы, которые служат шаблонами для создания экземпляров юнитов. См. раздел «Работа с юнитами systemd».

Файловая структура юнит-файлов#

Юнит-файлы обычно состоят из трех разделов:

• Раздел [Unit]— содержит общие опции, не зависящие от типа объекта. Эти параметры предоставляют описание юнита, определяют поведение юнита и устанавливают зависимости для других юнит-файлов.

• Раздел [Unit type]— если юнит имеет директивы для конкретного типа, они сгруппированы в разделе типов юнита. Например, служебные юнит-файлы содержит [Service] раздел.

• Раздел [Install]— содержит информацию об установке юнитов, используемых systemctl enable и disable командами.

Важные параметры раздела [Unit]#

В следующей таблице перечислены важные параметры раздела [Unit].

Полный список параметров, настраиваемых в разделе [Unit], см. в руководстве man systemd.unit(5).

Важные параметры раздела [Service]#

В следующей таблице перечислены важные параметры раздела [Service].

Полный список параметров, настраиваемых в разделе [Service], см. в руководстве man systemd.service(5).

Важные параметры раздела [Install]#

В следующей таблице перечислены важные параметры раздела [Install].

Создание пользовательских юнитов#

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

Процедура

Следующая процедура описывает общий процесс создания пользовательского сервиса:

1. Подготовьте исполняемый файл с пользовательской службой. Это может быть специально созданный сценарий или исполняемый файл, предоставленный поставщиком программного обеспечения. При необходимости подготовьте файл PID для хранения постоянного PID для основного процесса пользовательской службы. Также можно включить файлы среды для хранения переменных оболочки для службы. Убедитесь, что исходный сценарий является исполняемым (выполнив команду chmod a+x) и не интерактивным.

2. Создайте юнит-файл в /etc/systemd/system/ каталоге и убедитесь, что он имеет правильные права доступа к файлу. Выполните как root пользователь:

touch /etc/systemd/system/name.service

chmod 664 /etc/systemd/system/name.service

Замените name именем создаваемой службы. Обратите внимание, что файл должен быть исполняемым.

3. Откройте name.service файл, созданный на предыдущем шаге, и добавьте параметры конфигурации службы. Существует множество параметров, которые можно использовать в зависимости от типа службы.

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

[Unit]
Description=service_description
After=network.target

[Service]
ExecStart=path_to_executable
Type=forking
PIDFile=path_to_pidfile

[Install]
WantedBy=default.target

Где:

• service_description — это информативное описание, которое отображается в файлах журнала и в выходных данных systemctl status команды.

• Настройка After гарантирует, что служба запускается только после запуска сети. Добавьте через пробел список других соответствующих служб или целей.

• path_to_executable обозначает путь к фактическому исполняемому файлу службы.

• Type=forking используется для демонов, которые выполняют системный вызов fork. Основной процесс службы создается с PID, указанным в path_to_pidfile.

• WantedBy указывает цель или цели, под которыми должна быть запущена служба. Думайте об этих целях как о замене старой концепции уровней выполнения.

1. Сообщите systemd о существовании нового name.service файла, выполнив следующую команду root пользователя:

systemctl daemon-reload

systemctl start name.service

Предупреждение: Всегда запускайте systemctl daemon-reload команду после создания новых юнит-файлов или изменения существующих юнит-файл. В противном случае команды systemctl start или systemctl enable могут завершиться ошибкой из-за несоответствия между состояниями systemd и фактических служебных юнит-файлов на диске. Обратите внимание, что в системах с большим количеством юнитов это может занять много времени, так как состояние каждого юнита должно быть сериализовано, а затем десериализовано во время перезагрузки.

Создание пользовательского юнит-файла с помощью второго экземпляра службы sshd#

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

Процедура

1. Создайте копию sshd_config файла, который будет использоваться вторым демоном:

# cp /etc/ssh/sshd{,-second}_config

2. Отредактируйте sshd-second_config файл, созданный на предыдущем шаге, чтобы назначить другой номер порта и файл PID второму демону:

Port 22220
PidFile /var/run/sshd-second.pid

Убедитесь, что выбранный порт не используется какой-либо другой службой. Файл PID может не существовать до запуска службы, он создается автоматически при запуске службы.

3. Создайте копию юнит-файла systemd для sshd службы:

# cp /usr/lib/systemd/system/sshd.service /etc/systemd/system/sshd-second.service

4. Измените sshd-second.service, созданный на предыдущем шаге, следующим образом:

• Измените Description вариант:

Description=OpenSSH server second instance daemon

• Добавьте sshd.service к службам, указанным в опции, чтобы второй экземпляр запускался только после того, как первый уже запущен:

After=syslog.target network.target auditd.service sshd.service

• Первый экземпляр sshd включает генерацию ключей, поэтому удалите строку ExecStartPre=/usr/sbin/sshd-keygen.

• Добавьте в команду -f /etc/ssh/sshd-second_config параметр sshd, чтобы использовался альтернативный файл конфигурации:

ExecStart=/usr/sbin/sshd -D -f /etc/ssh/sshd-second_config $OPTIONS

• После вышеуказанных изменений sshd-second.service должен выглядеть следующим образом:

[Unit]
Description=OpenSSH server second instance daemon
After=syslog.target network.target auditd.service sshd.service

[Service]
EnvironmentFile=/etc/sysconfig/sshd
ExecStart=/usr/sbin/sshd -D -f /etc/ssh/sshd-second_config $OPTIONS
ExecReload=/bin/kill -HUP $MAINPID
KillMode=process
Restart=on-failure
RestartSec=42s

[Install]
WantedBy=multi-user.target

• При использовании SELinux добавьте порт для второго экземпляра sshd в порты SSH, иначе второй экземпляр sshd будет отклонен для привязки к порту:

# semanage port -a -t ssh_port_t -p tcp 22220

• Включите sshd-second.service, чтобы он запускался автоматически при загрузке:

# systemctl enable sshd-second.service

• Убедитесь, что служба sshd-second.service запущена с помощью systemctl status команды.

• Убедитесь, что порт включен правильно, подключившись к службе:

$ ssh -p 22220 user@server

• Если межсетевой экран используется, убедитесь, что он правильно настроен, чтобы разрешить подключения ко второму экземпляру sshd.

Поиск описания службы systemd#

Можно найти описательную информацию о скрипте в строке, начинающейся с #description. Используйте это описание вместе с именем службы Description в опции раздела [Unit] юнит-файла. Заголовок LSB может содержать аналогичные данные в строках #Short-Description и #Description.

Поиск зависимостей службы systemd#

Заголовок LSB может содержать несколько директив, формирующих зависимости между службами. Большинство из них можно перевести в параметры юнита systemd, см. следующую таблицу.

Таблица. Параметры зависимости из заголовка LSB

Поиск целей службы по умолчанию#

Строка, начинающаяся с #chkconfig, содержит три числовых значения. Наиболее важным является первое число, представляющее уровни выполнения по умолчанию, на которых запускается служба. Сопоставьте эти уровни запуска с эквивалентными целями systemd. Затем перечислите эти цели в WantedBy опции в разделе [Install] юнит-файла. Например, postfix, ранее он запускался на уровнях запуска 2, 3, 4 и 5, что соответствует - multi-user.target и graphical.target. Обратите внимание, что graphical.target зависит от multiuser.target, поэтому нет необходимости указывать оба. Также можно найти информацию об уровнях запуска (по умолчанию и запрещенных) в строках #Default-Start и #Default-Stop в заголовке LSB.

Два других значения, указанные в строке #chkconfig, представляют собой приоритеты запуска и завершения работы сценария инициализации. Эти значения интерпретируются systemd, если он загружает сценарий инициализации, но эквивалентного юнит-файла нет.

Поиск файлов, используемых сервисом#

Сценарии инициализации требуют загрузки библиотеки функций из специального каталога и позволяют импортировать файлы конфигурации, среды и PID. Переменные среды указываются в строке, начинающейся с #config в заголовке скрипта инициализации, что соответствует EnvironmentFile параметру юнит-файла. Файл PID, указанный в строке сценария инициализации #pidfilePIDFile, импортируется в юнит-файл с параметром.

Ключевой информацией, которая не включена в заголовок сценария инициализации, является путь к исполняемому файлу службы и, возможно, некоторые другие файлы, необходимые для службы. В предыдущих версиях SberLinux сценарии инициализации использовали оператор case Bash для определения поведения службы при действиях по умолчанию, таких как start, stop или restart, а также при определенных пользователем действиях. В следующем отрывке из postfix сценария инициализации показан блок кода, который должен выполняться при запуске службы.

conf_check() {
    [ -x /usr/sbin/postfix ] || exit 5
    [ -d /etc/postfix ] || exit 6
    [ -d /var/spool/postfix ] || exit 5
}

make_aliasesdb() {
    if [ "$(/usr/sbin/postconf -h alias_database)" == "hash:/etc/aliases" ]
    then
        # /etc/aliases.db might be used by other MTA, make sure nothing
        # has touched it since our last newaliases call
        [ /etc/aliases -nt /etc/aliases.db ] ||
            [ "$ALIASESDB_STAMP" -nt /etc/aliases.db ] ||
            [ "$ALIASESDB_STAMP" -ot /etc/aliases.db ] || return
        /usr/bin/newaliases
        touch -r /etc/aliases.db "$ALIASESDB_STAMP"
    else
        /usr/bin/newaliases
    fi
}

start() {
    [ "$EUID" != "0" ] && exit 4
    # Check that networking is up.
    [ ${NETWORKING} = "no" ] && exit 1
    conf_check
    # Start daemons.
    echo -n $"Starting postfix: "
    make_aliasesdb >/dev/null 2>&1
    [ -x $CHROOT_UPDATE ] && $CHROOT_UPDATE
    /usr/sbin/postfix start 2>/dev/null 1>&2 && success || failure $"$prog start"
    RETVAL=$?
    [ $RETVAL -eq 0 ] && touch $lockfile
        echo
    return $RETVAL
}

Расширяемость сценария инициализации позволила указать две пользовательские функции conf_check() и make_aliasesdb(), которые вызываются из start() функционального блока. При ближайшем рассмотрении в приведенном выше коде упоминаются несколько внешних файлов и каталогов: основной исполняемый файл службы /usr/sbin/postfix, каталоги /etc/postfix/ и /var/spool/postfix/ каталоги конфигурации, а также /usr/sbin/postconf/ каталог.

systemd поддерживает только предопределенные действия, но позволяет выполнять пользовательские исполняемые файлы с ExecStart, ExecStartPre, ExecStartPost, ExecStop и ExecReload. Вместе со /usr/sbin/postfix вспомогательными скриптами пользовательские исполняемые файлы выполняются при запуске службы. Преобразование сложных сценариев инициализации требует понимания назначения каждого оператора в сценарии. Некоторые операторы относятся к версии операционной системы, поэтому их не нужно переводить. С другой стороны, в новой среде могут потребоваться некоторые корректировки как в юнит-файле, так и в исполняемом файле службы и вспомогательных файлах.

Изменение существующих юнит-файлов#

Службы, установленные в системе, поставляются с юнит-файлами по умолчанию, которые хранятся в /usr/lib/systemd/system/ каталоге. Системные администраторы не должны изменять эти файлы напрямую, поэтому любая настройка должна ограничиваться файлами конфигурации в /etc/systemd/system/ каталоге.

Процедура:

1. В зависимости от степени требуемых изменений выберите один из следующих подходов:

• Создайте каталог для дополнительных файлов конфигурации в /etc/systemd/system/. Этот метод рекомендуется для большинства случаев использования. Это позволяет расширить конфигурацию по умолчанию дополнительными функциями, при этом ссылаясь на исходный юнит-файл. Таким образом, изменения юнита по умолчанию, введенные при обновлении пакета, применяются автоматически.

• Создайте копию исходного файла /usr/lib/systemd/system/ в /etc/systemd/system/ и внесите в него изменения. Копия переопределяет исходный файл, поэтому изменения, внесенные с обновлением пакета, не применяются. Этот метод удобен для внесения значительных изменений юнитов, которые должны сохраняться независимо от обновлений пакета.

2. Чтобы вернуться к конфигурации устройства по умолчанию, удалите созданные пользователем файлы конфигурации в формате /etc/systemd/system/.

3. Чтобы применить изменения к юнитам без перезагрузки системы, выполните:

systemctl daemon-reload

Опция daemon-reload перезагружает все юнит-файлы и воссоздает все дерево зависимостей, которое необходимо для немедленного применения любых изменений к файлу юнитов. В качестве альтернативы можно добиться того же результата с помощью следующей команды, которую необходимо выполнить как root пользователь:

init q

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

systemctl restart name.service

Например, чтобы расширить конфигурацию network службы, не изменяйте /etc/rc.d/init.d/network файл initscript. Вместо этого создайте новый каталог /etc/systemd/system/network.service.d/ и systemd файл. Затем поместите измененные значения в systemd файл. Поэтому созданный каталог должен называться: /etc/systemd/system/network.service.d/my_config.confsystemdnetworknetwork.servicenetwork.service.d

Расширение unit конфигурации по умолчанию#

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

Процедура:

1. Чтобы расширить юнит-файл по умолчанию дополнительными параметрами конфигурации, сначала создайте каталог конфигурации в формате /etc/systemd/system/. При расширении юнит-файла обслуживания выполните следующую команду как root пользователь:

mkdir /etc/systemd/system/name.service.d/

Замените name именем службы, которую нужно расширить. Приведенный выше синтаксис применим ко всем типам юнит-файлов.

2. Создайте файл конфигурации в каталоге, созданном на предыдущем шаге (обратите внимание, что имя файла должно заканчиваться суффиксом .conf):

touch /etc/systemd/system/name.service.d/config_name.conf

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

Например, чтобы добавить пользовательскую зависимость, создайте файл конфигурации со следующим содержимым:

[Unit]
Requires=new_dependency
After=new_dependency

Где new_dependency означает юнит-файл, который будет помечен как зависимость. Другим примером является файл конфигурации, который перезапускает службу после выхода из ее основного процесса с задержкой в 30 секунд:

[Service]
Restart=always
RestartSec=30

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

1. Чтобы применить изменения, внесенные в устройство, выполните команду root пользователь:

systemctl daemon-reload
systemctl restart name.service

Пример. Расширение конфигурации httpd.service

Чтобы изменить юнит httpd.service таким образом, чтобы пользовательский сценарий оболочки автоматически выполнялся при запуске службы Apache, выполните следующие действия.

1. Создайте каталог и пользовательский файл конфигурации:

   mkdir /etc/systemd/system/httpd.service.d/

2. При условии, что скрипт, который нужно запустить автоматически с Apache, находится по адресу /usr/local/bin/custom.sh, вставьте в custom_script.conf файл следующий текст: [Service]

   ExecStartPost=/usr/local/bin/custom.sh

3. Чтобы применить изменения юнита, выполните:

   systemctl daemon-reload

systemctl restart httpd.service

Переопределение unit конфигурации по умолчанию#

В этом разделе описывается, как переопределить конфигурацию юнит-файла по умолчанию.

Процедура:

1. Чтобы внести изменения, которые сохранятся после обновления пакета, содержащего юнит-файл, сначала скопируйте файл в /etc/systemd/system/ каталог. Для этого выполните следующую команду как root пользователь:

cp /usr/lib/systemd/system/name.service /etc/systemd/system/name.service

Где name означает название юнит-файла, который нужно изменить. Приведенный выше синтаксис применим ко всем типам юнит-файлов.

2. Откройте скопированный файл в текстовом редакторе и внесите необходимые изменения. Чтобы применить изменения, выполните как root пользователь:

systemctl daemon-reload systemctl restart name.service

Изменение лимита времени ожидания#

Например, чтобы увеличить лимит тайм-аута для httpd сервиса:

Процедура:

1. Скопируйте httpd юнит-файл в /etc/systemd/system/ каталог:

cp /usr/lib/systemd/system/httpd.service /etc/systemd/system/httpd.service

2. Откройте файл /etc/systemd/system/httpd.service и укажите TimeoutStartUSec значение в разделе [Service]:

...
[Service]
...
PrivateTmp=true
TimeoutStartSec=10

[Install]
WantedBy=multi-user.target
...

3. Перезагрузите systemd демон:

systemctl daemon-reload

4. При необходимости проверьте новое значение тайм-аута:

systemctl show httpd -p TimeoutStartUSec

Мониторинг переопределенных юнит-файлов#

В этом разделе описывается, как отобразить перечень переопределенных или измененных юнит-файлов.

Процедура:

Чтобы отобразить обзор переопределенных или измененных юнит-файлов, используйте следующую команду:

systemd-delta

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

[EQUIVALENT] /etc/systemd/system/default.target → /usr/lib/systemd/system/default.target
[OVERRIDDEN] /etc/systemd/system/autofs.service → /usr/lib/systemd/system/autofs.service

--- /usr/lib/systemd/system/autofs.service      2014-10-16 21:30:39.000000000 -0400
+ /etc/systemd/system/autofs.service  2014-11-21 10:00:58.513568275 -0500
@@ -8,7 +8,8 @@
 EnvironmentFile=-/etc/sysconfig/autofs
 ExecStart=/usr/sbin/automount $OPTIONS --pid-file /run/autofs.pid
 ExecReload=/usr/bin/kill -HUP $MAINPID
-TimeoutSec=180
+TimeoutSec=240
+Restart=Always

 [Install]
 WantedBy=multi-user.target

[MASKED]     /etc/systemd/system/cups.service → /usr/lib/systemd/system/cups.service
[EXTENDED]   /usr/lib/systemd/system/sssd.service → /etc/systemd/system/sssd.service.d/journal.conf

4 overridden configuration files found.

Работа с юнитами systemd#

Во время выполнения можно создать несколько юнит-файлов из одного файла конфигурации шаблона. Символ @ используется для обозначения шаблона и связывания с ним юнит-файлов. Созданные юнит-файлы можно запустить из другого юнит-файла (с помощью Requires или Wants опций) или с помощью systemctl start команды. Созданные юнит-файлы называются следующим образом:

template_name@instance_name.service

Где template_name обозначает имя файла конфигурации шаблона. Замените instance_name именем экземпляра юнит-файла. Несколько экземпляров могут указывать на один и тот же файл шаблона с параметрами конфигурации, общими для всех экземпляров юнит-файлов. Имя юнит-шаблона имеет вид:

unit_name@.service

Например, следующий Wants параметр в юнит-файле:

Wants=getty@ttyA.service getty@ttyB.service

Этот параметр заставляет systemd искать заданные юнит-файлы. Если такие юниты не найдены, часть между @ и суффиксом типа игнорируется, и systemd ищет getty@.service файл, считывает из него конфигурацию и запускает службы.

Например, getty@.service шаблон содержит следующие директивы:

[Unit]
Description=Getty on %I
...
[Service]
ExecStart=-/sbin/agetty --noclear %I $TERM
...

Когда экземпляры getty@ttyA.service и getty@ttyB.service создаются из приведенного выше шаблона, Description = разрешается как Getty на ttyA и Getty на ttyB.

Важные спецификаторы systemd unit (юнитов)#

Подстановочные знаки, называемые спецификаторами unit (также - юнитов), можно использовать в любом файле конфигурации юнита. Спецификаторы юнитов заменяют определенные параметры юнитов и интерпретируются во время выполнения. В следующей таблице перечислены спецификаторы, которые особенно полезны для юнит-шаблонов.

Таблица. Важные спецификаторы systemd юнитов

Полный список спецификаторов юнитов см. в руководстве man systemd.unit(5).

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

Существует список файлов systemd unit (юнитов), которые включены по умолчанию. Системные службы, определенные этими юнит-файлами, автоматически запускаются при загрузке, что влияет на время загрузки.

В этом разделе описывается:

• Инструменты для проверки производительности загрузки системы.

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

Проверка производительности загрузки системы#

Чтобы проверить производительность загрузки системы, можно использовать команду systemd-analyze. Эта команда имеет множество доступных опций. Однако в этом разделе рассматриваются только те из них, которые могут быть важны для настройки systemd, чтобы сократить время загрузки.

Предварительные условия

• Прежде чем приступить к проверке systemd, чтобы настроить время загрузки, можно просмотреть список всех включенных служб:

Сценарий:

Введите:

$ systemctl list-unit-files --state=enabled

Чтобы проанализировать общее время загрузки:

Сценарий:

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

$ systemd-analyze

Чтобы проанализировать время инициализации юнит-файлов:

Сценарий:

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

$ systemd-analyze blame

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

Для определения критических юнит-файлов:

Сценарий:

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

$ systemd-analyze critical-chain

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

Рисунок. Выходные данные команды systemd-analyze critical-chain

Руководство по выбору служб, которые можно безопасно отключить#

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

Чтобы перечислить такие службы, выполните:

$ systemctl list-unit-files --state=enabled

Чтобы отключить службу, выполните:

systemctl disable service_name

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

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

Таблица. Службы, включенные по умолчанию при минимальной установке SberLinux

Чтобы найти дополнительную информацию о службе, выполните одну из следующих команд:

$ systemctl cat <service_name>

$ systemctl help <service_name>

Команда systemctl cat предоставляет содержимое служебного файла, расположенного в файле /usr/lib/systemd/system/, а также все применимые переопределения. Применимые переопределения включают переопределения единичных файлов из файла /etc/systemd/system/ или выпадающих файлов из unit.type.d справочника.

Для получения дополнительной информации введите:

systemctl help

Команда systemctl help показывает справочную страницу конкретной службы.

Дополнительные ресурсы:

Справочные страницы: systemctl(1), systemd(1), systemd-delta(1), systemd.directives(7), systemd.unit(5), systemd.service(5), systemd.target(5), systemd.kill(5).

Домашняя страница systemd

Введение в управление учетными записями пользователей и групп#

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

Знакомство с пользователями и группами#

Пользователь, создающий файл, является владельцем этого файла и владельцем группы этого файла. Файлу назначаются отдельные разрешения на чтение, запись и выполнение для владельца, группы и тех, кто находится за пределами этой группы. Владелец файла может быть изменен только root пользователем. Права доступа к файлу могут быть изменены как root пользователем, так и владельцем файла. Обычный пользователь может изменить групповое право собственности на файл и на группу, членом которой является.

Каждому пользователю присваивается уникальный числовой идентификационный номер, называемый идентификатором пользователя (UID). Каждая группа связана с идентификатором группы (GID). Пользователи внутри группы имеют одинаковые разрешения на чтение, запись и выполнение файлов, принадлежащих этой группе.

Настройка зарезервированных идентификаторов пользователей и групп#

Можно найти зарезервированные идентификаторы пользователей и групп в setup пакете. Чтобы просмотреть зарезервированные идентификаторы пользователей и групп, используйте:

cat /usr/share/doc/setup*/uidgid

Рекомендуется назначать идентификаторы новым пользователям и группам, начиная с 5000, так как зарезервированный диапазон может увеличиться в будущем.

Чтобы идентификаторы, назначаемые новым пользователям, по умолчанию начинались с 5000, измените параметры UID_MIN и GID_MIN в /etc/login.defs файле.

Сценарий:

Чтобы идентификаторы, назначаемые новым пользователям, по умолчанию начинались с 5000:

1. Откройте файл /etc/login.defs в редакторе по выбору.

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

# Min/max values for automatic uid selection in userad
#
UID_MIN 1000

3. Измените UID_MIN значение, чтобы оно начиналось с 5000.

# Min/max values for automatic uid selection in useradd
#
UID_MIN 5000

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

# Min/max values for automatic gid selection in groupadd
#
GID_MIN 1000

5. Измените GID_MIN значение, чтобы оно начиналось с 5000.

# Min/max values for automatic gid selection in groupadd
#
GID_MIN 1000

Динамически назначаемые UID и GID для обычных пользователей начинаются с 5000.

Частные группы пользователей#

SberLinux использует конфигурацию системы user private group (UPG), что упрощает управление группами UNIX. Личная группа пользователей создается всякий раз, когда в систему добавляется новый пользователь. Частная группа пользователей имеет то же имя, что и пользователь, для которого она была создана, и этот пользователь является единственным членом частной группы пользователей.

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

Список всех групп хранится в файле конфигурации /etc/group.

Управление пользователями из командной строки#

Добавление нового пользователя из командной строки#

В этом разделе описано, как использовать useradd утилиту для добавления нового пользователя.

Предварительные условия:

Права root пользователя.

Процедура:

1. Чтобы добавить нового пользователя, используйте команду:

useradd *options* *username*

2. Замените эти параметры параметрами командной строки для useradd команды и замените username именем пользователя.

Пример. Добавление нового пользователя:

Чтобы добавить пользователя maria с идентификатором пользователя 5000, используйте:

+

useradd -u 5000 maria

Этапы проверки:

Чтобы проверить, добавлен ли новый пользователь, воспользуйтесь id утилитой.

# id maria

Результат:

uid=5000(maria) gid=5000 (maria) groups=5000(maria)