Debian
Плюсы - ассортимент доступного софта, строгий QA, Debian Policy...
Просто знакомы лучше, видимо. Вот Вам и не кажется "странным" подключать кучу сторонних репозитариев.
У меня лично с проблемой пересобрать пакет (или собрать с нуля) под CentOS/Debian - нет.
Только это не значит, что я не выбиру после этого дистрибутив где такое потребуется заведомо часто, ибо софт в штатных репах - сильно ограничен. Зачем себе лишнюю работу навыдумывать?
Каждому свое, конечно. Оно ведь не дороже себе выходит - если у каждого сопровождаемого клиента свой дистрибутив, нет?
1) А что такое "системные апи"? И чем они от "несистемных" отличаются? Или "бессистемных" - так правильнее?
2) Мучаться - нет, не мучаемся. Я не знаю системных сервисов, в которые уже не была бы интегрирована поддержка PAM. Помимо C - есть биндинги для популярных языков, вплоть до PHP.
3) Что касается "панелек". Как вы любите говорить - "у меня все работает" :) Чем изобретать свою собственную библиотеку для аутентификации - мне показалось разумнее и дешевле привязать все к PAM. После чего получилось много бонусов, в частности - возможности настройки разнообразных политик для паролей (см. pam_cracklib). Без никаких "C".
Не нравится - не ешьте...
Начинать надо с того, что привести заголовки спам-письма. В абузе пример письма должен быть полностью, со всеми техническими заголовками.
man passwd
man sshd_config (директива Listen)
Не знаю, как директадмин - но мне ничего не мешает использовать pam для почты. Например, на postfix и dovecot. Почтовые аккаунты - не системные (хотя можно хоть для каждого ящика делать отдельный системный аккаунт - это дело параллельное).
Для директадмина проблемы также не должно быть. Биндинги к PAM есть у большинства системных сервисов. Если какая-то панелька сует реквизиты доступа хоть в самое нестандартное место - ничто не мешает написать новый модуль, который будет лезть в это самое место. И подключить в конфиг PAM для этого самого сервиса...
Панелька может _поменять_ пароль напрямую в базе, в обход политик PAM. Это - да. Тут нужна привязка в самой панельке.
А во-вторых. Неужели, прикрутить авторизацию к PAM такая проблема для "админа-непрограммиста"? Даже на C это достаточно "шаблонный" и небольшой код, требует только заглянуть раз в документацию. Не говоря уже о всяких обертках к PAM для PHP и проч...
Для авторизации. Чего угодно в чем угодно. Совершенно необязательна какая-либо связь с системными учетными записями. Специалист Вы наш :)
Виртуальный ftp-пользователь для vsftpd - это что - "системный аккаунт" какой-то?
"Pluggable authentication modules, or PAM, is a mechanism to integrate multiple low-level authentication schemes into a high-level application programming interface (API)."
На физическом сервере ее вполне можно скрыть. Выставить права на соответствующие файлы в /proc (linux) - патчи для такого есть. Да и нужно ли скрывать подобное от клиентов?
Что за такой "конфиг сервера"?
В том то и дело, что спрашивает. Пусть и не в названии темы. Если он считает, что ему chroot нужен для изоляции пользователей друг от друга - не нужно подкреплять это заблуждение.
Тогда только ldap/sql в качестве хранилища passwd. А что еще за "конфиг", который также можно посмотреть?
Ну может и нужно устранить в первую очередь эти проблемы? Не думаю, что костыль в виде chroot поможет от ошибок администрирования.
"Конфигурация Apache по-умолчанию позволяет из корня одного сайта получать доступ к файлам других сайтов и к корню сервера. "
многим показалось, что "доступ к файлам других сайтов" и есть ключевая проблема. Если вы считаете, что это не так - мне жаль ваш хостинг.
