>> Примерно так и сделал. Разве что автоматическое управление конфигурацией прикручивать
>> пока не стал, пока все проблемы с AD не утрясутся -
>> нужно, похоже, его уровень поднимать, а это не совсем тривиально в
>> силу локальных причин.
> и чем дальше тем сложнее, по мере роста инфраструктурыА что делать, нужен апгрейд LDAP-схемы. :(
>> Энтерпрайз разный бывает. В одном случае это сотни одинаковых виртуалок, а в
>> другом - несколько десятков разных, да ещё и с сильно специфическими
>> требованиями.
> если у них одна ОС, то уже можно спокойно настроить автоматический деплоймент.
> все правильно распланировать и автоматизировать - это как раз и есть
> работа админа, все остальное - инструменты
Планировать хорошо, когда у заказчика не семь пятниц на неделе. До сих пор хочется креститься от воспоминаний о "написании документации"... Но это уже совсем оффтопик, могу в личке рассказать. :)
>> Я в курсе, зачем он нужен, как работает, и как его настраивать.
>> Он просто своей работой реально мешает. Потому что далеко не всегда
>> очевидно, что тот или иной сбой спровоцирован именно им. Apache+SVN, например,
>> пробовали когда-нибудь настраивать? Там в итоге приходишь или к такой конфигурации,
>> где от SELinux остаётся одна видимость, либо просто его отключаешь.
> Он не везде подходит, и не везде нужен, но свое дело делает
> отлично.
Вот и я вырубил его на половине сервисов.
> Кстати, у меня был случай когда я с ним замучился,
> в рабочей конфигурации он был практически выключен, но это было небезопасно.
> Дан Волш у себя в жж тогда очень помог - я
> прямо ему и написал
Мысль хорошая, спасибо.
>> Да кто ж спорит, что AD - это вечно ходячий (вернее, падучий)
>> источник проблем. :) Но когда некое средство конфигурации декларирует, мол, хозяин,
>> я тебе сейчас сделаю хорошо, а потом за ним приходится подчищать
>> и доделывать ещё столько же - как-то нехорошо, согласитесь.
> я давно перестал верить в сказки, особенно в сказку про кнопку "сделать
> все чтоб было ништяк". Именно для этого и есть системы управления
> конфигурацией - чтоб построить самому как надо, и не рассчитывать на
> простые инсталлеры.
В моём случае разница между использованием системы управления конфигурацией и работы "ручками" невелика: есть плюсы, есть и минусы. Папеты и компания не убирают необходимость знать устройство системы для поддержки, а у меня требование к работе специфическое: нужно, чтобы несколько откровенно слабо разбирающихся в никсах людей могли по моим инструкциям как-то весь этот зоопарк поддерживать. Система управления конфигурацией в таком случае становится лишь ещё одной приблудой, в которой надо разбираться. Хотя, повторюсь, смотрю в указанную сторону.
>> Во всяком случае, ФС (ext3 и ext4) в виртуалках у меня рушилась
>> только в Linux'е. Поживём-увидим, конечно.
> как именно рушилась?
Капитально. Восстановлению не подлежала. При том пару раз это произошло на абсолютно пустом месте, не было ни одного внештатного выключения ОС.
> а то мне за уже почти 5 лет работы
> с kvm еще не приходилось видеть убитыю фс в виртуалке, если
> все было правильно настроено. А с кривой настройкой, убить фс можно
> и на железе
Сами ФС во всех случаях были с дефолтными настройками - как раз, чтобы обойтись без экспериментов. Т.е., я просто выбирал ext4 или ext3, и - вперёд. Вроде бы в CentOS 6.3 такого уже не было, а ещё в 6.2 - несколько раз.
Ещё вспомнил: один или два случая были под KVM с CentOS, остальные - под VirtualBox на Win7.
