From 74aa0bc6779af38018a03fd2cf4419fe85917904 Mon Sep 17 00:00:00 2001 From: Daniel Baumann Date: Fri, 19 Apr 2024 07:31:45 +0200 Subject: Adding upstream version 2.9.4. Signed-off-by: Daniel Baumann --- src/man/uk/sssd-kcm.8.xml | 304 ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 304 insertions(+) create mode 100644 src/man/uk/sssd-kcm.8.xml (limited to 'src/man/uk/sssd-kcm.8.xml') diff --git a/src/man/uk/sssd-kcm.8.xml b/src/man/uk/sssd-kcm.8.xml new file mode 100644 index 0000000..b3c2cd0 --- /dev/null +++ b/src/man/uk/sssd-kcm.8.xml @@ -0,0 +1,304 @@ + + + +Сторінки підручника SSSD + + + + + sssd-kcm + 8 + Формати файлів та правила + + + + sssd-kcm + Керування кешем Kerberos SSSD + + + + ОПИС + + На цій сторінці підручника описано налаштування засобу керування кешем +Kerberos SSSD (Kerberos Cache Manager або KCM). KCM є процесом, який +зберігає, стежить і керує кешем реєстраційних даних Kerberos. Ідея створення +засобу походить із проєкту Heimdal Kerberos, хоча у бібліотеці Kerberos MIT +також надається підтримка з боку клієнта для кешу реєстраційних даних KCM +(докладніше про це нижче). + + + У конфігураціях, де кешем Kerberos керує KCM, бібліотека Kerberos (типово +використовується за допомогою якоїсь програми, наприклад +kinit1 +) є клієнтом KCM, а фонова служба KCM +вважається сервером KCM. Клієнт і сервер обмінюються даними +за допомогою сокета UNIX. + + + Сервер KCM стежити за кожним власником кешу реєстраційних даних і виконує +перевірку прав доступу на основі UID і GID клієнта KCM. Користувач root має +доступ до усіх кешів реєстраційних даних. + + + Кеш реєстраційних даних KCM має декілька цікавих властивостей: + + + + оскільки процес виконується у просторі користувача, він підлягає обмеженням +за простором назв UID, на відміну від набору ключів ядра + + + + + на відміну від кешу на основі наборів ключів ядра, який є спільним для усіх +контейнерів, сервер KCM є окремим процесом, чия точка входу є сокетом UNIX + + + + + реалізація у SSSD зберігає дані ccache у базі даних, файл якої типово +називається /var/lib/sss/secrets. За допомогою +цього файла ccache зберігаються протягом періодів перезапуску сервера KCM +або перезавантаження комп'ютера. + + + + Це надає змогу системі використовувати кеш реєстраційних даних із +врахуванням збірок, одночасно надаючи спільний доступ до кешу реєстраційних +даних для декількох контейнерів або без контейнерів взагалі шляхом +прив'язування-монтування сокета. + + + Час очікування на дії типового клієнта KCM дорівнює 5 хвилин, таке значення +надає більшу часу на взаємодію користувача із інструментами командного +рядка, зокрема kinit. + + + + + КОРИСТУВАННЯ КЕШЕМ РЕЄСТРАЦІЙНИХ ДАНИХ KCM + + Для використання кешу реєстраційних даних KCM його слід вибрати стандартним +типом реєстраційних даних у +krb5.conf5 +. Назвою кешу реєстраційних даних має бути лише +KCM: без будь-яких розширень шаблонами. Приклад: +[libdefaults] + default_ccache_name = KCM: + + + + Далі, слід визначити однаковий шлях до сокета UNIX для клієнтських бібліотек +Kerberos і сервера KCM. Типово, у обох випадках використовується однаковий +шлях /var/run/.heim_org.h5l.kcm-socket. Для +налаштовування бібліотеки Kerberos змініть значення її параметра +kcm_socket, як це описано на сторінці підручника + +krb5.conf5 +. + + + Нарешті, переконайтеся, що з сервером KCM SSSD можна встановити +зв'язок. Типово, служба KCM вмикається за допомогою сокета з +systemd 1 +. На відміну від інших служб SSSD, її не можна запустити +додаванням рядка kcm до інструкції service. + +systemctl start sssd-kcm.socket +systemctl enable sssd-kcm.socket + Будь ласка, зауважте, що +відповідні налаштування модулів вже могло бути виконано засобами вашого +дистрибутива. + + + + + СХОВИЩЕ КЕШУ РЕЄСТРАЦІЙНИХ ДАНИХ + + Кеші реєстраційних даних зберігаються у базі даних, дуже подібно до кешів +записів користувачів і груп SSSD. Типово, база даних зберігається у +/var/lib/sss/secrets. + + + + + ОТРИМАННЯ ДІАГНОСТИЧНОГО ЖУРНАЛУ + + Типово, служба sssd-kcm активує крізь сокет +systemd 1 +. Для створення діагностичних журналів додайте вказані нижче +рядки або безпосередньо до файла /etc/sssd/sssd.conf, +або як фрагмент налаштувань до каталогу +/etc/sssd/conf.d/: +[kcm] +debug_level = 10 + Далі, перезапустіть службу sssd-kcm: +systemctl restart sssd-kcm.service + Нарешті, виконайте дії, які не призводять до +бажаних для вас наслідків. Журнал KCM буде записано до +/var/log/sssd/sssd_kcm.log. Рекомендуємо вимкнути +ведення діагностичного журналу, якщо вам не потрібні діагностичні дані, +оскільки служба sssd-kcm може породжувати доволі великий обсяг діагностичних +даних. + + + Будь ласка, зауважте, що у поточній версії фрагменти налаштувань буде +оброблено, лише якщо взагалі існує основний файл налаштувань +/etc/sssd/sssd.conf. + + + + + ПОНОВЛЕННЯ + + Службу sssd-kcm можна налаштувати на спробу поновлення TGT для поновлюваних +TGT, які зберігаються у ccache KCM. Спроби поновлення виконуватимуться при +досягненні половини строку дії квитка. Поновлення KCM налаштовуються при +встановленні таких параметрів у розділі [kcm]: +tgt_renewal = true +krb5_renew_interval = 60m + + + + Крім того, SSSD може успадковувати параметри krb5 для поновлень з наявного +домену. + + +tgt_renewal = true +tgt_renewal_inherit = domain-name + + + Вказані нижче параметри krb5 можна налаштувати у розділі [kcm] для керування +поведінкою під час поновлення. Ці параметри докладно описано нижче + +krb5_renew_interval +krb5_renewable_lifetime +krb5_lifetime +krb5_validate +krb5_canonicalize +krb5_auth_timeout + + + + + + ПАРАМЕТРИ НАЛАШТУВАННЯ + + Налаштовування служби KCM виконується за допомогою розділу +kcm файла sssd.conf. Будь ласка, зауважте, що оскільки +активація служби KCM, зазвичай, відбувається за допомогою сокетів, після +внесення змін до розділу kcm файла sssd.conf достатньо +перезапустити службу sssd-kcm: +systemctl restart sssd-kcm.service + + + + Налаштування служби KCM виконують за допомогою kcm. Докладний +опис синтаксичних конструкцій налаштувань наведено у розділі ФОРМАТ +ФАЙЛА сторінки підручника щодо +sssd.conf 5 +. + + + Службі kcm можна передавати типові параметри служби SSSD, зокрема +debug_level та fd_limit Із повним списком +параметрів можна ознайомитися на сторінці підручника +sssd.conf 5 +. Крім того, передбачено декілька специфічних для KCM +параметрів. + + + + socket_path (рядок) + + + Сокет, на якому очікуватиме на з'єднання служба KCM. + + + Типове значення: +/var/run/.heim_org.h5l.kcm-socket + + + Зауваження: на платформах, де передбачено +підтримку systemd, шлях до сокета буде перезаписано шляхом, який визначено у +файлі модуля sssd-kcm.socket. + + + + + max_ccaches (ціле число) + + + Скільки кешів реєстраційних може мати даних база даних KCM для усіх +користувачів. + + + Типове значення: 0 (без обмежень, застосовується лише квота на кількість +кешів на UID) + + + + + max_uid_ccaches (ціле число) + + + Скільки кешів реєстраційних може мати даних база даних KCM для окремого +UID. Еквівалент значення кількість реєстраційних даних, які можна +ініціювати за допомогою kinit. + + + Типове значення: 64 + + + + + max_ccache_size (ціле число) + + + Наскільки великим може бути кеш реєстраційних даних окремого ccache. Ця +квота обчислюється для усіх квитків служб разом. + + + Типове значення: 65536 + + + + + tgt_renewal (булеве значення) + + + Вмикає функціональні можливості поновлень TGT. + + + Типове значення: False (автоматичні поновлення вимкнено) + + + + + tgt_renewal_inherit (рядок) + + + Домен, з якого слід успадковувати параметри krb5_*, для використання із +поновленнями TGT. + + + Типове значення: NULL + + + + + + + + + ТАКОЖ ПЕРЕГЛЯНЬТЕ + + sssd8 +, +sssd.conf5 +, + + + + -- cgit v1.2.3