SSSD(8) Справка по SSSD SSSD(8)

sssd - cервис SSSD

sssd [options]

ОПИСАНИЕ

SSSD предоставляет набор внутренних служб для управления доступом к удалённым каталогам и механизмам проверки подлинности. Этот сервис предоставляет интерфейс NSS и PAM к операционной системе и систему подключаемых внутренних серверов для установки соединения с несколькими разными источниками учётных записей, а также интерфейс D-Bus. Также он является основой сервисов аудита и политики доступа клиентов для таких проектов, как FreeIPA. SSSD предоставляет более надёжную базу данных для хранения локальных пользователей, а также расширенных пользовательских данных.

ОПЦИИ

-d,--debug-level LEVEL

В SSSD предусмотрены два представления для указания уровня отладки. Более простое представление позволяет указать десятичное значение в диапазоне от 0 до 9, которое будет включать соответствующий уровень и все более низкие уровни сообщений отладки. Более сложное представление позволяет указать шестнадцатеричную битовую маску для включения или отключения (подавления) отдельных уровней.

Обратите внимание, что каждая служба SSSD ведёт журнал в своём собственном файле. Также следует учитывать, что включение параметра “debug_level” в разделе “[sssd]” включает отладку только для самого процесса sssd, а не для процессов ответчика или поставщика данных. Параметр “debug_level” следует добавить во все разделы, для которых требуется создать журналы отладки.

Уровень отладки можно изменить не только с помощью параметра “debug_level” в файле конфигурации (этот параметр является постоянным, но требует перезапуска SSSD), но и «на лету», с помощью инструмента sss_debuglevel(8).

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

0, 0x0010: фатальные ошибки. Всё, что не позволяет выполнить запуск SSSD или вызывает прекращение работы сервиса.

1, 0x0020: критические ошибки. Ошибка, которая не прекращает работу SSSD, но означает, что как минимум одна важная функциональная возможность не будет работать надлежащим образом.

2, 0x0040: серьёзные ошибки. Ошибка, которая сообщает о завершении неудачей определённого запроса или действия.

3, 0x0080: незначительные ошибки. Это ошибки, которые могут стать причиной ошибок 2-го уровня (ошибок при выполнении действий).

4, 0x0100: параметры конфигурации.

5, 0x0200: данные функций.

6, 0x0400: сообщения трассировки для функций действий.

7, 0x1000: сообщения трассировки для функций внутреннего управления.

8, 0x2000: содержимое внутренних переменных функций, которое может представлять интерес.

9, 0x4000: информация трассировки крайне низкого уровня.

9, 0x20000: быстродействие и статистические данные. Пожалуйста, обратите внимание, что из-за способа обработки запросов на внутреннем уровне, записанное в журнал время выполнения запроса может быть больше, чем оно было на самом деле.

10, 0x10000: информация трассировки libldb ещё более низкого уровня. Практически никогда не требуется.

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

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

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

Примечание: формат битовых масок уровней отладки был введён в версии 1.7.0.

По умолчанию: 0x0070 (то есть фатальные, критические и серьёзные ошибки; соответствует указанию значения «2» в десятичной записи)

--debug-timestamps=mode

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

0: отключить отметку времени в сообщениях отладки

По умолчанию: 1

--debug-microseconds=mode

1: добавить микросекунды в отметку времени в сообщениях отладки

0: отключить микросекунды в отметке времени

По умолчанию: 0

--logger=value

Расположение, в которое SSSD будет отправлять сообщения журнала.

stderr: перенаправлять сообщения отладки в стандартный поток ошибок.

files: перенаправлять сообщения отладки в файлы журнала. По умолчанию файлы журнала хранятся в /var/log/sssd и представляют собой отдельные файлы для каждой службы и домена SSSD.

journald: перенаправлять сообщения отладки в systemd-journald

По умолчанию: не задано (использовать journald, если это возможно, в ином случае — stderr)

-D,--daemon

Запускаться в качестве службы.

-i,--interactive

Запускаться интерактивно, не в качестве службы.

-c,--config

Позволяет указать файл конфигурации, отличный от стандартного. Стандартным является /etc/sssd/sssd.conf. Сведения о синтаксисе и параметрах файла конфигурации доступны на справочной странице sssd.conf(5).

-g,--genconf

Не запускать SSSD, но обновить базу данных конфигурации содержимым /etc/sssd/sssd.conf и выйти.

-s,--genconf-section

Аналогично “--genconf”, но будет выполнено обновление только одного раздела файла конфигурации. Этот параметр полезен главным образом при вызове из файлов модулей systemd с целью позволить ответчикам, которые активируются с помощью сокетов, обновлять свою конфигурацию без необходимости в перезапуске всего сервиса SSSD администратором.

-?,--help

Показать справочное сообщение и выйти.

--version

Вывести номер версии и выйти.

Сигналы

SIGTERM/SIGINT

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

SIGHUP

Сообщает SSSD, что следует прекратить запись в текущие дескрипторы файлов отладки, закрыть их и затем открыть снова. Это должно облегчить свёртывание журнала с помощью таких программ, как logrotate.

SIGUSR1

Сообщает SSSD, что следует имитировать работу в автономном режиме в течение времени, заданного параметром “offline_timeout”. Это полезно при тестировании. Сигнал можно отправить либо процессу sssd, либо напрямую любому процессу sssd_be.

SIGUSR2

Сообщает SSSD, что следует немедленно перейти в сетевой режим. Это полезно при тестировании. Сигнал можно отправить либо процессу sssd, либо напрямую любому процессу sssd_be.

ПРИМЕЧАНИЯ

Если переменная среды SSS_NSS_USE_MEMCACHE установлена в значение «NO», клиентские приложения не будут использовать быстрый кэш в памяти.

Если переменная среды SSS_LOCKFREE установлена в значение «NO», одновременные запросы от нескольких потоков одного приложения будут преобразованы в последовательность запросов.

СМ. ТАКЖЕ

sssd(8), sssd.conf(5), sssd-ldap(5), sssd-ldap-attributes(5), sssd-krb5(5), sssd-simple(5), sssd-ipa(5), sssd-ad(5), sssd-files(5), sssd-sudo(5), sssd-session-recording(5), sss_cache(8), sss_debuglevel(8), sss_obfuscate(8), sss_seed(8), sssd_krb5_locator_plugin(8), sss_ssh_authorizedkeys(8), sss_ssh_knownhostsproxy(8), sssd-ifp(5), pam_sss(8). sss_rpcidmapd(5)

Восходящий источник («апстрим») SSSD — https://github.com/SSSD/sssd/

04/02/2024 SSSD