Администрирование кластера

Полезные материалы по настройке подсистем кластера

Учетные записи в Slurm

Пользователи и учёт

В Slurm есть две системы учёта пользователей. Первая система основана на системных учётных записях, хранит в служебных файлах обобщённую статистику истории запуска задач и используется для простой системы вычисления приоритетов - share. Вторая система - полноценная система биллинга использует БД для хранения полной истории запуска задач, системы учётных карточек (account), ограничений ресурсов (QOS) и т.п.

Первая система не требует использования БД и сохраняет текущую информацию в файлах:

assoc_mgr_state
assoc_usage
clustername
dbd.messages
fed_mgr_state
job_state
last_config_lite
layouts_state_base
node_state
part_state
priority_last_decay_ran
qos_usage
resv_state
trigger_state

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

sacctmgr -i add user testuser DefaultAccount=root 

Ассоциация (Association)

Учёт ресурсов в Slurm ведётся с точностью до учётных ассоциаций, каждая из которых объединяет четыре понятия:

  • кластер;
  • учетную карточку (account);
  • имена пользователей;
  • необязательное имя раздела.

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

Создание кластера

Кластер описывается в двух местах: в конфигурации Slurm и в учётной базе данных.

slurm.conf

AccountingStorageType=accounting_storage/slurmdbd
AccountingStoreJobComment=YES
ClusterName=uran

Создание записи в базе:

sacctmgr add cluster uran

Создание учетных карточек

  • Учетная карточка (Account) соответствует группе пользователей (например, участникам проекта);
  • Учетная карточка может содержать несколько пользователей или только одного;
  • Учетные карточки могут быть организованы как иерархическое дерево;
  • Верхний уровень иерархии имеет стандартное имя root;
  • Имя карточки должно быть уникальным и не может быть использовано повторно в другой ветви иерархии учетных карточек;
  • Пользователь может вписан в несколько учетных карточек, но должен иметь карточку по умолчанию (DefaultAccount).

Примеры команд для создания иерархии организации и иерархии внешних пользователей, работающих по договорам:

sacctmgr add account imm Description="Институт математики и механики" Organization=imm
sacctmgr add account imm_opo Description="Отдел программного обеспечения" Organization=imm_opo parent=imm
sacctmgr add account imm_opo_sector_1 Description="Сектор системного программирования" Organization=imm_opo parent=imm_opo

sacctmgr add account external Description="Внешние пользователи" Organization=external
sacctmgr add account dogovor_10 Description="Договор N10" Organization=external
sacctmgr add account dogovor_11 Description="Договор N11" Organization=external

Отображение созданных учетных записей:

sacctmgr show account
sacctmgr show account -s   # Показывает ассоциации связанные с аккаунтами

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

  • Cluster= добавить учетную карточку в указанные кластеры. По умолчанию учетная карточка добавляется ко всем существующим кластерам.
  • Description= описание учетной записи. (По умолчанию - имя учетной записи)
  • Name= имя учетной записи.
  • Organization= организация на которую зарегистрирована учетная карточка. По умолчанию это организация родительской учетной карточки, если родительская учетная запись не является корневой. Если родитель root, то по умолчанию используется имя учетной записи.
  • Parent= сделать эту учетную запись дочерним элементом этой другой учетной записи (уже существующей).

Создание пользователей

Создание пользователя Slurm с именем xxx и учетной карточкой по умолчанию (обязательно) yyy:

sacctmgr create user name=xxx DefaultAccount=yyy

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

sacctmgr add user xxx Account=zzzz

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

-A <account> или --account = <account> 

Список пользователей:

sacctmgr show user
sacctmgr show user -s
sacctmgr show account -s xxx

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

  • Account= Учетная карточка(и) для добавления пользователя (см. также DefaultAccount ).
  • AdminLevel= Это поле используется, чтобы позволить пользователю добавлять учетные привилегии этому пользователю. Возможные варианты:
    • None
    • Operator - может добавлять/изменять/удалять любой объект базы данных (пользователь, учетная запись и т. Д.) и добавлять других операторов. На SlurmDBD, обслуживаемом slurmctld, эти пользователи могут: просматривать информацию, которая блокируется для регулярного использования флагом PrivateData; создавать/изменять/удалять бронирование.
    • Admin - эти пользователи имеют тот же уровень привилегий, что и оператор в базе данных. Они также могут изменять что-либо в slurmctld, как если бы они были пользователем slurm или root.
  • Cluster= добавлять к ассоциациям только на этих кластерах (по умолчанию все кластеры)
  • DefaultAccount= учетная карточка по умолчанию. Используется, если учетная карточка не указана явно при запуске задания. (обязательный параметр).
  • DefaultWCKey= пользовательский ключ по умолчанию для пользователя, используемый, когда не указан WCkey при отправке задания. (Используется только при отслеживании WCkey .)
  • Name= имя пользователя
  • Partition= Название раздела Slurm, к которому относится данная ассоциация.

Изменение и удаление объектов

При изменении свойств объектов можно задавать параметры в стиле SQL, используя ключевые слова WERE и SET. Некоторые параметры, например имя объекта, изменить нельзя. Типичная команда имеет следующий вид:

sacctmgr modify <entity> set <options> where <options>

Например:

sacctmgr modify user set DefaultAccount=none where DefaultAccount=test

назначит всем пользователям с учетной карточкой по умолчанию "test" учетную карточку "none".

Удаление объектов аналогично изменению. Например, для удаления всех пользователей с учетной записью по умолчанию "test", используется следующая команда:

sacctmgr remove user where DefaultAccount=test

Удаление пользователя из учетной карточки:

sacctmgr remove user brian where Account=imm_opo

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

Примечание. В большинстве случаев удаленные объекты сохраняются, но помечены как удаленные. Если объект существовал менее 1 дня, то он будет удален полностью. Такое поведение предназначено для защиты от опечаток.

Использованы материалы со страницы https://wiki.fysik.dtu.dk/niflheim/Slurm_accounting

Ограничение ресурсов в Slurm

Для ограничения ресурсов необходимо включить в slurm.conf строку:

AccountingStorageEnforce=limits

TRES

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

  • пакетные буферы - burst buffers (BB)
  • ЦПУ (CPU)
  • энергия (Energy)
  • GRES
  • лицензии (License)
  • память (Mem)
  • узлы (Node)
  • вычисляемый (Billing)

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

TRESBillingWeights="CPU=1.0,Mem=0.25G,GRES/gpu=2.0"

Установка ограничений на пользователя:

sacctmgr modify user xxx set MaxTRES=cpu=1000 MaxTRESMinsPerJob=6000 GrpTRESMins=60000

Ограничения с префиксом Max - обозначают максимальный ресурс на одну задачу, с префиксом Grp - суммарное количество ресурсов на все задачи, когда либо запущенные пользователем (на самом деле, история потихоньку очищается и предел не является абсолютным) . В данном примере задано ограничение счёта одной задачи в 100 часов на 1000 процессорах и суммарное время в 1000 часов.

QOS

Качество обслуживания (QOS) объединяет несколько ограничений на TRES. Конфигурация QOS должна иметь как минимум стандартное значение QOS с названием normal. Дополнительные QOS'ы могут переопределять ограничения.

Например, QOS high256 с высоким приоритетом и ограничением на количество ЦПУ :

sacctmgr add qos high256 priority=10 MaxTRESPerUser=cpu=256

Просмотр существующих QOS:

sacctmgr show qos 

Назначение пользователю DefaultQOS:

sacctmgr -i modify user where name=XXXX set DefaultQOS=normal

Назначение дополнительных QOS пользователю:

sacctmgr -i modify user where name=XXXX set QOS=normal,high
sacctmgr -i modify user where name=XXXX set QOS+=high

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

sbatch --qos=high256 ... 

Иерархия ограничений

Ограничения Slurm применяются в следующем порядке:

  1. QOS раздела (partition)
  2. QOS задания
  3. Ограничение ассоциации пользователя (user+account+cluster)
  4. Ограничение ассоциации учетной карточки (account+cluster), по возрастанию иерархии
  5. Ассоциация root_account+cluster
  6. Ограничения раздела
  7. Нет ограничений

Выдача отчётов в Slurm

Запросить информацию по заданиям, используя следующие команды:

  • sacct - отображает данные всех заданий (завершившихся/считающихся/ждущих очереди);
  • sreport [options] - генерирует отчеты из данных учета Slurm;
  • sstat <JobID> - отображает информацию (использование памяти, ЦПУ и т.д) о считающейся задаче по её JobID ;
  • seff <JobID> - отображает эффективность использования ЦПУ и памяти завершившейся задачей по её JobID ;
  • scontrol show jobs - отображает состояние запущенных задач;
  • scontrol show assoc_mgr - отображает текущее содержимое внутреннего кэша slurmctld для пользователей, ассоциаций и/или qos.

sacct

Просмотр задач конкретного пользователя:

sacct -u user

Просмотр задач всех пользователей:

sacct -a

Начало и конец периода:

sacct --start=2018-07-01 --end=2018-07-15

sreport

Примеры использования sreport для создания отчетов:

sreport cluster UserUtilizationByAccount
sreport cluster AccountUtilizationByUser 

Показать статистику в виде дерева учетных карточек (accounts):

sreport cluster AccountUtilizationByUser tree 

Вывести отчета в виде таблицы с разделителем '|' для дальнейшей обработки скриптами:

sreport -p ... 

Выбор диапазонов дат:

sreport ... start=2018-06-01 end=2018-06-30
sreport ... start=`date -d "last month" +%D` end=`date -d "this month" +%D`

Изменение формата даты/времени в заголовке отчета (форматы в man strftime):

env SLURM_TIME_FORMAT = "%d-%b-%Y_%R" sreport ... 

Задание единиц времени, отображаемых в потреблении ресурсов (по умолчанию - минуты):

sreport -t hourper ... 

Задание TRES, отображаемых в потреблении ресурсов (по умолчанию - cpu):

sreport --tp cpu,gpu ... 

Показать учетные записи пятидесяти самых активных пользователей за 2017 год:

sreport user top start=2017-01-01 end=2017-12-31 TopCount=50 -t hourper --tres=cpu,gpu 

Отчет об использовании кластера:

sreport -t hourper cluster Utilization

Интеграция Linux и Active Directory

Существует несколько путей для интеграции Linux компьютеров в домен. Часть из них построена на использовании специализированной программ winbind из пакета Samba, а часть использует автономные PAM и NSS модули для непосредственного взаимодействия с сервером домена.

Общие настройки OpenLDAP

Пути к файлам, использованные на этой странице, относятся к дистрибутивам Linux CentOS 6/7.

Основные файлы конфигурации

/etc/openldap/slapd.conf

Конфигурация LDAP-сервера slapd. Содержимое файла для запуска slapd в режиме прокси описано в статье"OpenLDAP в режиме прокси для Active Directory".

/etc/openldap/ldap.conf

Базовая конфигурация клиентов из пакета OpenLDAP (ldapsearch, ldapwhoami, slapd в режиме прокси). Параметры из этого файла могут быть перезаписаны в командной строке. Этот файл не влияет на демон nslcd - у того свои настройки LDAP в /etc/nslcd.conf.

/etc/nslcd.conf

Конфигурация демона nslcd, который обеспечивает доступ к LDAP кэширующему серверу имен nscd. Конфигурационный файл описан в разделе "Имена пользователей и групп из LDAP (nslcd)".

Создание баз slapd

Используется два основных каталога для хранения баз /etc/openldap/slapd.d и /var/lib/ldap. Первый каталог используется для хранения конфигурации в виде базы database config. Второй - для хранения локальной базы записей LDAP или (в режиме прокси) для хранения кэша модулем pcache. В каталоге /var/lib/ldap для корректного создания базы должен находиться файл DB_CONFIG.

cp /usr/share/openldap-servers/DB_CONFIG.example /var/lib/ldap/DB_CONFIG

Конфигурация slapd может храниться в двух форматах: в файле /etc/openldap/slapd.conf и в каталоге /etc/openldap/slapd.d. Конфигурация из каталога имеет больший приоритет, поэтому при изменениях файла /etc/openldap/slapd.conf надо удалить базу /etc/openldap/slapd.d и сгенерировать ее заново:

sudo rm -rf /etc/openldap/slapd.d/*; sudo -u ldap slaptest -f /etc/openldap/slapd.conf -F /etc/openldap/slapd.d -v -d -1

slaptest проверяет синтаксис slapd.conf, строит базу config в /etc/openldap/slapd.d и пытается создать bdb/hdb базы (если они описаны в slapd.conf) в /var/lib/ldap. Опция -d -1 - обеспечивает выдачу отладочной информации, что бывает полезно для поиска ошибок в файле конфигурации.

Иногда при генерации баз в /var/lib/ldap slaptest выдает ошибку:

Checking configuration files for : bdb_db_open:
db_open(/var/lib/ldap/id2entry.bdb) failed: No such file or directory (2)

В этом случае имеет смысл один раз запустить slapd от root'а (с опцией отладки, чтобы он не ушел в фоновый режим), а потом поменять владельца сгенерированых файлов.

slapd -d -1; chown -R ldap:ldap /var/lib/ldap

Целостность баз slapd

Для обеспечения целостности баз соответствующая библиотека ведёт логи транзакций, которые позволяют восстановить базу в случае сбоя на диске или аварийного отключения питания. Логи транзакций накапливаются в каталоге /var/lib/ldap/ с именами вида log.0000000001, log.0000000002 и т.д. Для кеширующего прокси целостность баз не имеет значения, поэтому сохранение логов транзакций можно отключить, добавив в файл /var/lib/ldap/DB_CONFIG строку set_flags DB_LOG_AUTOREMOVE

Запись логов

Для записи логовов slapd в конфигурационный файл syslog/rsyslog необходимо добавить правило

local4.* /var/log/ldap.log

Отладка slapd

Для отладки slapd запускается с опцией -d N, где N - число, каждый бит которого включает определенный тип отладочной печати. При запуске с опцией отладки slapd не уходит в фоновый режим и выдает отладочную печать на stderr. slapd -d -1 включает вывод всей доступной отладочной печати. Запуск slapd с опцией -d \? выдает список допустимых значений отладочных режимов и мнемонические обозначения для них. В зависимости от подключенных модулей-оверлеев, список отладочных режимов может меняться. В частности, модуль pcache добавляет свой отладочный флаг. При запуске slapd -d pcache выдается предупреждение, что используется неверный флаг отладки, но работает как надо.

Если есть желание отлаживать slapd, запущенный в фоновом режиме, то вместо опции -d следует использовать -s - запись в syslog.

Список битов, используемых с опциями -d и -s

    Any                            (-1, 0xffffffff)
    Trace                          (1, 0x1)
    Packets                        (2, 0x2)
    Args                           (4, 0x4)
    Conns                          (8, 0x8)
    BER                            (16, 0x10)
    Filter                         (32, 0x20)
    Config                         (64, 0x40)
    ACL                            (128, 0x80)
    Stats                          (256, 0x100)
    Stats2                         (512, 0x200)
    Shell                          (1024, 0x400)
    Parse                          (2048, 0x800)
    Sync                           (16384, 0x4000)
    None                           (32768, 0x8000)
    pcache                         (4096, 0x1000)

Мониторинг нагрузки

В slapd.conf включаем монитор и разрешаем доступ локальному root'у

database monitor
access to *
        by dn.exact="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" read
        by * none

Просмотр данных

#Просмотр разделов, доступных для опроса
ldapsearch  -Y EXTERNAL -H ldapi:/// -b 'cn=Monitor' 
#Просмотр конкретного раздела
ldapsearch -Y EXTERNAL -H ldapi:/// -b 'cn=Statistics,cn=Monitor' -s base '(objectClass=*)' '*' '+'

Пример использования ldapsearch

Для отладки можно формировать запросы к LDAP-серверу командой ldapsearch. Например:

ldapsearch -H ldap://localhost/ -x -b "dc=example,dc=com" -LLL '(sAMAccountName=testuser)'

Тестирование запроса nslcd:

ldapsearch -H ldap://localhost/ -x -b "ou=People,dc=example,dc=com" -LLL '(&(&(&(&(objectClass=user)(!(objectClass=computer)))(uidNumber=*))(unixHomeDirectory=*))(sAMAccountName=testuser))'

OpenLDAP в режиме прокси для Active Directory

Общие настройки slapd описаны в статье "Общие настройки OpenLDAP".

Предполагается, что slapd выступает кэширующим прокси между Linux компьютерами в локальной сети и внешним сервером AD, работающим под управлением Win2008R2 или старше. Задачей кэширующего сервера является обеспечение отказоустойчивости при кратковременных разрывах связи с сервером АД. Клиентом выступает Linux с сервером nslcd. Соответствующая конфигурация nslcd описана в отдельной статье.

Для доступа к LDAP в AD заведен пользователь Manager с паролем secret.

Изменение схемы LDAP

В поставке CentOS нет схемы LDAP из AD. Отсутствие необходимых атрибутов приводит к тому, что запросы с этими атрибутами не обрабатываются модулем pcache, причём без какой-либо диагностической информации.

Источником схемы может быть репозиторий https://github.com/dkoudela/active-directory-to-openldap + доработка схемы NIS, в которую для совместимости с AD добавлено имя атрибута 'unixHomeDirectory', причем, обязательно в первой позиции.

/etc/openldap/schema/nis.schema

attributetype ( 1.3.6.1.1.1.1.3 NAME ('unixHomeDirectory' 'homeDirectory')
        DESC 'The absolute path to the home directory'
        EQUALITY caseExactIA5Match
        SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )

Ещё один вариант (неполный) схемы AD в прикреплённом файле. Источник схемы.

Тестирование кэша

Для проверки работоспособности кэша необходимо запустить сервер в режиме отладки slapd -d 4096 и заставить nslcd обратиться к нему (например выполнив команду nscd -i passwd;id testuser).

В хорошем случае при первом запросе атрибутов пользователя в логе будут строки вида :

QUERY NOT ANSWERABLE
QUERY CACHEABLE

при повторных запросах будет выдаваться

QUERY ANSWERABLE (answered 3 times)

В плохом случае постоянно будут выдаваться строки

QUERY NOT ANSWERABLE
QUERY NOT CACHEABLE

Файлы конфигурации

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

/etc/sysconfig/ldap

Файл содержит опции, которые используются при запуске slapd командой systemctl start slapd или service slapd start

#Явно перечисляем интерфейсы по которым будет доступен прокси
SLAPD_LDAP=no
SLAPD_LDAPI=no
SLAPD_LDAPS=no
SLAPD_URLS="ldapi:/// ldap://192.168.1.1/ ldap://192.168.2.1/ ldap://127.0.0.1/"

/etc/openldap/ldap.conf

В этом файле важен параметр TLS_REQCERT allow. Без него невозможно подключиться к серверу АД с самоподписанным сертификатом.

#URI - адрес сервера. Протокол доступа может быть ldap: и ldaps:
URI ldaps://ldapserver.example.com/
#BASE - ветка дерева LDAP в которой ведется поиск
BASE dc=example,dc=com
#TLS_CACERTDIR - путь к каталогу с сертификатами SSL для установки защищенного соединения с сервером
TLS_CACERTDIR /etc/openldap/certs
#TLS_REQCERT - что делать если сертификат сервера не найден. 'allow' - продолжить соединение
TLS_REQCERT allow

/etc/openldap/slapd.conf

Основной конфигурационный файл

# Схема из репозитория https://github.com/dkoudela/active-directory-to-openldap
# nis.schema  с небольшой модификацией
include         /etc/openldap/schema_ad/microsoftattributetype.schema
include         /etc/openldap/schema_ad/microsoftattributetypestd.schema
include         /etc/openldap/schema_ad/corba.schema
include         /etc/openldap/schema_ad/core.schema
include         /etc/openldap/schema_ad/cosine.schema
include         /etc/openldap/schema_ad/duaconf.schema
include         /etc/openldap/schema_ad/dyngroup.schema
include         /etc/openldap/schema_ad/inetorgperson.schema
include         /etc/openldap/schema_ad/java.schema
include         /etc/openldap/schema_ad/misc.schema
include         /etc/openldap/schema_ad/nis.schema
include         /etc/openldap/schema_ad/openldap.schema
include         /etc/openldap/schema_ad/ppolicy.schema
include         /etc/openldap/schema_ad/collective.schema
include         /etc/openldap/schema_ad/microsoftobjectclass.schema


#Источник данных
database ldap                                                                 
suffix          "DC=example,DC=com"
uri             ldap://ldap.example.com/ 
rootdn          "OU=People,DC=example,DC=com"
rebind-as-user  yes

# От чьего имени подключаемся к АД
idassert-bind   bindmethod=simple
                binddn="CN=Manager,DC=example,DC=com"
                credentials="secret"
                mode=none
# Кто может подключаться к нам (все - анонимно и без авторизации)                                                                              
idassert-authzFrom "*"

# Опциональное отображение атрибутов passwd на схему AD
# в нашем варианте оно делается на уровне nslcd
#moduleload rwm
#overlay  rwm
#rwm-map attribute uid sAMAccountName
#rwm-map attribute dn distinguishedName
#rwm-map attribute homeDirectory unixHomeDirectory
#rwm-map attribute gecos displayName

# Кэширование
# Загрузка модуля и включение оверлея к базе LDAP
moduleload pcache.la
overlay pcache

# pcache <database> <max_entries> <numattrsets> <entry_limit> <cc_period> 
# параметры базы:
# <database> for cached entries. 
# <max_entries> when reached - cache replacement is invoked
# <numattrsets> = pcacheAttrset
# <entry_limit> limit to the number of entries returned 
# <cc_period> Consistency check time to wait

# в базе в формате BerkleyDB хранится 2000 записей, один набор атрибутов/фильтров с индексом 0
pcache hdb 2000 1 1000 300

#кэшируем все атрибуты (0 - индекс)
pcacheattrset 0 *

#шаблон запроса должен в точности совпадать с указанным, иначе запрос не кэшируется
#нужные шаблоны запросов можно отследить, запустив slapd в отладочном режиме - slapd -d 4096
#ниже приведены шаблоны запросов nslcd в CentOS 7 с модификацией фильтра, описанной в http://parallel.uran.ru/node/408
#кэшируем перечисленные запросы и храним их 900 секунд  (0 - индекс)

pcacheTemplate (&(&(objectClass=)(uidNumber=*)(unixHomeDirectory=*))(uidNumber=)) 0 900 120
pcacheTemplate (&(&(objectClass=)(uidNumber=*)(unixHomeDirectory=*))(sAMAccountName=)) 0 900 120
pcacheTemplate (&(objectClass=)(uidNumber=*)(unixHomeDirectory=*)) 0 900 120
pcacheTemplate (&(|(objectClass=)(objectClass=))(|(memberUid=)(member=))) 0 900 120
pcacheTemplate (&(|(objectClass=)(objectClass=))(gidNumber=)) 0 900 120
pcacheTemplate (&(|(objectClass=)(objectClass=))(memberUid=)) 0 900 120
pcacheTemplate (&(|(objectClass=)(objectClass=))(cn=)) 0 900 120

# максимальный размер запроса
sizelimit unlimited

# путь к базе
directory /var/lib/ldap
cachesize 200

# индексы для ускорения доступа
index objectClass                       eq,pres
index                                   member
index ou,cn,mail,surname,givenname      eq,pres,sub
index uidNumber,gidNumber,loginShell    eq,pres
index uid,memberUid                     eq,pres,sub
index nisMapName,nisMapEntry            eq,pres,sub

Ссылки

  1. Обход ошибки missing id2entry.bdb

  2. OpenLDAP proxy для M$ Active Directory

Прикрепленный файлРазмер
Иконка простого текстового файла ad_schema.txt4.09 КБ

Имена пользователей и групп из LDAP (nslcd)

Всё необходимое для получения имен пользователей из LDAP в CentOS 7 находится в пакете nss-pam-ldapd. Этот пакет добавляет модуль pam_ldap.so в библиотеку libpam, модуль libnss_ldap.so в библиотеку libnss и сервер nslcd (работающий в связке с кэширующим сервером nss - nscd), который и выполняет запросы к LDAP серверу.

В файле /etc/nsswitch.conf необходимо добавить ldap, как источник данных для баз passwd, group и shadow:

passwd:   files ldap
shadow:   files ldap
group:    files ldap

В файле /etc/nslcd.conf гнобходимо настроить сервер LDAP и набор запросов к нему. Запросы включают фильтры, которые позволяют выбрать записи относящиеся к той или иной базе, и отображения стандартных имен в базе на эквивалентные по смыслу имена, которые использует схема LDAP на сервере. В примерах есть пара рабочих вариантов настроек для доступа к серверу Active Directory. Для сервера slapd из OpenLDAP модификация запросов, скорее всего, не требуется.

# Выбираем записи имеющие атрибуты uidNumber и unixHomeDirectory
# При запросе к фильтру добавляется &(sAMAccountName=username)
# 
# Не совсем понятно зачем явно отбрасываются  записи для компьютеров.
# Возможно существуют сценарии с назначением компьютеру атрибута unixHomeDirectory.
filter passwd (&(objectClass=user)(!(objectClass=computer))(uidNumber=*)(unixHomeDirectory=*))

# Отображение полей passwd на атрибуты АД
map    passwd uid              sAMAccountName
map    passwd homeDirectory    unixHomeDirectory
map    passwd gecos            displayName

Сложнее с вариантом, когда для доступа к АД используется slapd в режиме кэширующего прокси, используемого для отказоустойчивости при кратковременных обрывах связи с сервером АД. Этот прокси не кэширует запросы с фильтром, использующим операцию "НЕ", а следовательно, и запрос из предыдущего примера. Для работы через кэширующий прокси рабочим оказался упрощённый вариант фильтра:

filter passwd (&(objectClass=user)(uidNumber=*)(unixHomeDirectory=*))

Авторизация пользователей в Kerberos (pam_krb5 и другие)

Ссылки:

Linux: SSH + LDAP(Kerberos) - http://xvoids.blogspot.ru/2008/09/linux-rhel-ssh-kerberos-ldapad.html

Аутентификация в apache используя Active Directory и kerberos - http://val-khmyrov.blogspot.ru/2011/04/apache-active-directory-kerberos.html

Прокси сервер Squid в Active Directory с Kerberos аутентификацией - http://www.theadmin.ru/linux/squid/proksi-server-squid-v-active-directory-s-kerberos-autentifikaciej/

Admin Guide for Mod_auth_kerb - http://www.its.mn/hp_docs/apache/mod_auth_kerb.admin.guide mod_auth_kerb - http://modauthkerb.sourceforge.net/configure.html

Kerberos Single Signon with Joomla! or other PHP apps - http://sammoffatt.com.au/knowledge-base-mainmenu/9-joomla/7-kerberos-single-signon-with-joomla-or-other-php-apps

Using mod_auth_kerb and Windows 2000/2003/2008R2 as KDC - http://www.grolmsnet.de/kerbtut/