Хоть мы и немного отклоняемся от заявленной темы, позволю себе возразить, уж наступил ты на больную мозоль
Иван Левшин aka Ivan L. писал(а):Константин Ошмян писал(а):Менее понятная схема лицензирования.
Как раз в OES она куда более понятна. Лицензируется он по числу объектов пользователей, нет ни серверных, ни клиентских лицензий. И эта схема работает давным-давно - со времен NW65SP7
Как мне, не дожадаясь очередного аудита, самому оценить, какое количество лицензий мне реально необходимо? К сожалению, на этот простой вопрос не смогли ответить ни местные представители Novell, ни сами аудиторы
Подсчёт "в лоб" (по количеству объектов "пользователь" в дереве) не катит.
Во-первых, там до хрена служебных пользователей, создаваемых при инсталяции OES на сервер (навскидку -
novlxregd,
novlxsrvd,
wwwrun, плюс для каждого сервера -
{имясервера}admin и
OESCommonProxy_{имясервера}). С учётом того, что количество серверов не ограничивается - таких пользователей может быть много.
Во-вторых, могут быть другие служебные пользователи, которые не подключаются к серверу по NCP/CIFS/и т.п. Например: пользователь, от имени которого идёт бэкап на сервере NetWare; LUM-пользователь для мониторинга Linux-а (заводим один раз в дереве, чтобы не заводить на каждом SLES-е отдельно, от его имени в качестве демона запускается мониторинговый агент) и тому подобные. Их тоже надо считать?
В-третьих, могут быть пользователи, которые никогда не имели или уже никогда не будут иметь доступа ни к каким OES-сервисам. Например, уволенные сотрудники (удалять которых нельзя, поскольку тогда потеряются владельцы созданных ими файлов), либо автоматически отреплицированные IDM-ом практиканты (у них вообще нет никаких доступов и, скорее всего, не будет; но иногда может прийти заявка - и тогда этот доступ нужно будет им предоставить, он превращается в полноценного пользователя).
Наконец,
в четвёртых - по условиям
лицензионного соглашения (которое мало кто читает) я могу использовать eDirectory для хранения до 250 тысяч объектов "User". Например, при использования eDirectory в качестве LDAP-сервера для аутентификации сторонних приложений. И по каким критериям мне отличать таких "чисто пользователей eDirectory" от полноценных "пользователей OES", на которых нужна OES-овская лицензия?
Иван Левшин aka Ivan L. писал(а):Константин Ошмян писал(а):Привязка к конкретному дистрибутиву Linux (например, уже давно вышел SLES12, а OES-2015, который только ещё выйдет летом, ближайший год будет ещё на базе SLES11).
Вот этого не понял совсем. В чем прелесть немедленного перелезания на SLES12, если все и так работает на SLES11? У меня в хозяйстве есть машины, на которых, например, OpenSuSE 12/13 просто не встает - там так и работает 11 и с работой он справляется целиком и полностью. В общем, старая поговорка про шашечки и ехать.
Согласись сам, что это довольно гнилой аргумент. Вот у меня, например, наряду с такой же есть и противоположная ситуация: новый навороченный сервер, который под SLES12 сертифицирован, а под SLES11 - уже нет. Наверняка с помощью привычных инструментов (времени, молотка, зубила и такой-то матери) на него получится взгромоздить и SLES11, но производителем такая конфигурация не поддерживается.
К тому же я вот на днях был на семинаре на тему "какой крутой SLES12", где мне рассказывали про светлое будущее, уже ставшее настоящим: файловую систему
btrfs со снапшотами, итегрированную с новым бут-лоадером GRUB2 (демонстрировался красивый пример: удаляем, якобы по ошибке, файлы
/boot/vmlinu* и
/boot/initrd*, перегружаемся, после чего успешно восстанавливаемся на предыдущий снапшот), контейнеры и
docker, патчинг ядра на живую (без перезагрузки) и прочее. И я понимаю, что как минимум некоторые из этих вещей мог бы применить у себя уже сейчас. Но увы - на OES-овских серверах вся эта сказка будет минимум через год.
Добавлено: 05 мар 2015, 16:54
Если не сложно - продублируй запрос по лицензиям мне на почту, постараюсь выяснить. Потому как этот вопрос в таком ключе никогда не рассматривал.