SSSD(8)

NAME
sssd - Фонова служба безпеки системи

SYNOPSIS

sssd [параметри]

ОПИС

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

ПАРАМЕТРИ

-d,--debug-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: незначні помилки. Це помилки які можуть призвести до помилок під час виконання дій.

    4, 0x0100: параметри налаштування.

    5, 0x0200: дані функцій.

    6, 0x0400: повідомлення трасування для функцій дій.

    7, 0x1000: повідомлення трасування для функцій внутрішнього трасування.

    8, 0x2000: вміст внутрішніх змінних функцій, який може бути цікавим.

    9, 0x4000: дані трасування найнижчого рівня.

    9, 0x20000: швидкодія і статистичні дані; будь ласка, зауважте, що через спосіб, у яких програма обробляє запити на внутрішньому рівні записаний до журналу час виконання запиту може бути довшим за справжній.

    10, 0x10000: ще докладніші дані трасування libldb низького рівня. Навряд чи коли знадобляться.

    Щоб до журналу було записано дані потрібних бітових масок рівнів діагностики, просто додайте відповідні числа, як це показано у наведених нижче прикладах:

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

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

    Зауваження: формат бітових масок для рівнів діагностики впроваджено у версії 1.7.0.

    Типове значення: 0x0070 (тобто фатальні, критичні та серйозні помилки; відповідає встановленню значення 2 у десятковому записі)

--debug-timestamps=режим
    1: додати часову позначку до діагностичних повідомлень.

    0: вимкнути часову позначку у діагностичних повідомленнях

    Типове значення: 1

--debug-microseconds=режим
    1: додати значення мікросекунд до часової позначки у діагностичних повідомленнях

    0: вимкнути додавання мікросекунд до часової позначки

    Типове значення: 0

--logger=значення
    Місце, куди SSSD надсилатиме повідомлення журналу.

    stderr: переспрямувати діагностичні повідомлення до стандартного виведення помилок.

    files: переспрямувати діагностичні повідомлення до файлів журналу. Типово файли журналів зберігаються у /var/log/sssd, передбачено також окремий журнал для кожної служби і домену SSSD.

    journald: переспрямувати діагностичні повідомлення до systemd-journald

    Типове значення: не встановлено (резервною буде journald, якщо вона доступна, інакше буде використано stderr)

-D,--daemon
    Перейти у режим фонової служби після запуску.

-i,--interactive
    Запустити програму у звичайному режимі, не створювати фонової служби.

-c,--config
    Визначити нетиповий файл налаштувань. Типовим файлом налаштувань є /etc/sssd/sssd.conf. Довідку щодо синтаксису та параметрів файла налаштувань можна знайти на сторінці довідника (man) sssd.conf(5).

-?,--help
    Показати довідкове повідомлення і завершити роботу.

--version
    Вивести номер версії і завершити роботу.

Сигнали

SIGTERM/SIGINT
    Повідомляє SSSD, що слід поступово завершити роботу всіх дочірніх процесів, а потім завершити роботу монітора.

SIGHUP
    Повідомляє SSSD, що слід припинити запис до файлів діагностичних даних з поточними дескрипторами, закрити і повторно відкрити ці файли. Цей сигнал призначено для полегшення процедури архівування журналів за допомогою програм, подібних до logrotate.

SIGUSR1
    Наказує SSSD імітувати автономну дію, тривалість якої визначається параметром «offline_timeout». Найкориснішим застосуванням є тестування служби. Сигнал може бути надіслано або процесу sssd, або процесу sssd_be безпосередньо.

SIGUSR2
    Наказує SSSD перейти у режим роботи у мережі негайно. Найкориснішим застосуванням є тестування служби. Сигнал може бути надіслано або процесу sssd, або процесу sssd_be безпосередньо.

SIGRTMIN+1
    Повідомляє SSSD, що слід змінити планування періодичних завдань. Внутрішній засіб спостереження надсилає цей сигнал до надавачів даних при виявленні зсуву годинника, хоча його можна надсилати до будь-якого процесу sssd_be безпосередньо.

СТАН ВИХОДУ

0
    SSSD завершив роботу штатно.

1
    Помилкові налаштування або помилковий параметр командного рядка.

2
    Помилка розподілу пам'яті.

6
    SSSD вже запущено.

Інші коди
    Інші коди означають інші помилки, найімовірніше пов'язані із нестачею потрібних прав доступу. Див. журнали SSSD і системи, щоб дізнатися більше.

ЗАУВАЖЕННЯ

Якщо для змінної середовища SSS_NSS_USE_MEMCACHE встановлено значення «NO», клієнтські програми не використовуватимуть fast у кеші у пам’яті.

Якщо для змінної середовища 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-idp(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(1), sss_ssh_knownhosts(1), sssd-ifp(5), pam_sss(8). sss_rpcidmapd(5)

AUTHORS

Основна гілка розробки SSSD — https://pagure.io/SSSD/sssd/