Комментарии 49
Статья опоздала лет на пять?
0
Может я чего не понимаю, но зачем брать для контроллера домена 500 Гб? Хватает и SSD на 60 Гб. И затраты на такой сервер — 25-30 тысяч рублей, без учёта лицензий, разумеется.
От RAID можно вообще отказаться, имея второй дублирующий сервер.
Тем более, если есть файловый сервер, куда будут литься бэкапы — вот на этом уже точно не стоит экономить и уж под бэкапы обязательно нужен RAID, а не «один терабайтник».
От RAID можно вообще отказаться, имея второй дублирующий сервер.
Тем более, если есть файловый сервер, куда будут литься бэкапы — вот на этом уже точно не стоит экономить и уж под бэкапы обязательно нужен RAID, а не «один терабайтник».
+2
Брать 2 SSD на 60ГБ или 2 500 ГБ SATA (возможно, бу) — тут все упирается в деньги, какое решение более подходит под бюджет, такое лучше и выбрать.
Что зеркалить — вопрос дискуссионный. При выходе из строя одного из дисков многие предпочтут иметь живой DC, чем восстанавливать его из бэкапов.
по поводу зеркала на бэкапы — тут смотря какие бэкапы. Если там только бэкапы самого контроллера, то нет особого смысла их зеркалить, а если что-то еще будет туда бэкапится, тогда да, нужно зеркало. В рассматриваемом случае имелось ввиду, что на этот диск бэкапится только сам DC, а остальное (виртуальные машины, файловые шары и БД) бэкапятся на другой массив, и вот там уже да, зеркало.
В описанном случае необходимость в Raid обусловлена тем, что диски у нас тоже б/у, причем он интегрированный, так что кроме стоимости 2-го диска и небольшой доп.нагрузки на CPU этот рейд ничего не стоит в плане затрат
Что зеркалить — вопрос дискуссионный. При выходе из строя одного из дисков многие предпочтут иметь живой DC, чем восстанавливать его из бэкапов.
по поводу зеркала на бэкапы — тут смотря какие бэкапы. Если там только бэкапы самого контроллера, то нет особого смысла их зеркалить, а если что-то еще будет туда бэкапится, тогда да, нужно зеркало. В рассматриваемом случае имелось ввиду, что на этот диск бэкапится только сам DC, а остальное (виртуальные машины, файловые шары и БД) бэкапятся на другой массив, и вот там уже да, зеркало.
В описанном случае необходимость в Raid обусловлена тем, что диски у нас тоже б/у, причем он интегрированный, так что кроме стоимости 2-го диска и небольшой доп.нагрузки на CPU этот рейд ничего не стоит в плане затрат
0
Вы же понимаете, что в случае критичных данных вариант «один SATA» — не вариант, потому что надёжность и корректность таких данных под вопросом?
Конечно, при переходе от рабочих групп к домену хочется сэкономить. Но экономить на дисках, у которых стоимость в разы отличается от стоимости лицензий — это экономия на спичках, причём совершенно ненужная и опасная.
Да и максимум проблем, которые можно поиметь с выходом основного DC из строя — то, что второй контроллер из slave надо переводить в master, а потом уже думать, что делать с первым.
Конечно, при переходе от рабочих групп к домену хочется сэкономить. Но экономить на дисках, у которых стоимость в разы отличается от стоимости лицензий — это экономия на спичках, причём совершенно ненужная и опасная.
Да и максимум проблем, которые можно поиметь с выходом основного DC из строя — то, что второй контроллер из slave надо переводить в master, а потом уже думать, что делать с первым.
0
Не вполне понятно, о чем вы — о бу-дисках? Но использование новых дисков никак не гарантирует их безупречность и отказоустойчивость, гарантируется лишь их бесплатная замена. Примеров, когда новые диски сыплются хоть отбавляй. Для этого Raid и нужен. А какие диски туда поставить, это уже вопрос возможностей бюджета.
С выходом из строя основного контроллера домена при наличии второго инфраструктура продолжит работать и пользователи ничего не заметят. В этом и есть весь смысл иметь 2-ой КД. А вот использовать на КД один сата без зеркала — это и есть экономия на спичках.
С выходом из строя основного контроллера домена при наличии второго инфраструктура продолжит работать и пользователи ничего не заметят. В этом и есть весь смысл иметь 2-ой КД. А вот использовать на КД один сата без зеркала — это и есть экономия на спичках.
0
Ну б\у диски тоже не гарантируют качества и надёжности. Им-то как раз меньше доверия. А брак в партии новых дисков — вполне обычная вещь. Мои основные претензии к выбору дисков под бэкапы, пусть даже если туда бэкапится только КД (и вопрос ещё — чем бэкапится. Если Windows Archive, то терабайтник тут перебор, а уж если диск под бэкапы на той же машине — тем более сомнительно всё это выглядит).
А ещё, как правило, у малых организаций под бэкапы уже есть NAS какой-нибудь и его вполне достаточно будет.
Поэтому смысла пичкать КД дисками нет, соответственно, нет смысла покупать полноразмерный сервер. Потому что про стоимость владения забывать тоже не стоит.
А ещё, как правило, у малых организаций под бэкапы уже есть NAS какой-нибудь и его вполне достаточно будет.
Поэтому смысла пичкать КД дисками нет, соответственно, нет смысла покупать полноразмерный сервер. Потому что про стоимость владения забывать тоже не стоит.
0
1. В т.ч. поэтому нужен Raid.
2. По размеру — может и перебор, но больше — не меньше. Если есть желание поставить диск поменьше или утилизировать побольше — ради бога.
3. Про NAS — если есть, то да. Но если нет — диск в сервере будет дешевле, чем NAS, да и умрет NAS быстрее, чем выделенный только под бэкапы DC диск. Мухи отдельно, котлеты отдельно. Но это уже вопрос выбора в каждой конкретной ситуации.
2. По размеру — может и перебор, но больше — не меньше. Если есть желание поставить диск поменьше или утилизировать побольше — ради бога.
3. Про NAS — если есть, то да. Но если нет — диск в сервере будет дешевле, чем NAS, да и умрет NAS быстрее, чем выделенный только под бэкапы DC диск. Мухи отдельно, котлеты отдельно. Но это уже вопрос выбора в каждой конкретной ситуации.
0
Мухи отдельно, котлеты отдельно.Не стоит складывать все яйца в одну корзину. Откажет сервер и толку нам от диска с бэкапами, который внутри вышедшей из строя машины?
Вообще, в каком сценарии Ваш вариант с одним диском на той же машине позволяет без проблем восстановить нужные данные из бэкапа и это выгоднее, чем бэкапы на сетевое расположение?
Вот сценарии, где этот вариант проигрывает:
Пропадает электропитание — головка HDD паркуется неправильно и приплыли.
Пошли невосстановимые ошибки системы и надо либо переустановить всё (если бэкапим только базу КД), либо восстановить из образа системы — так Windows Archive не делает полный бэкап системы на диск, принадлежащий этой же системе. Да и инкрементный не делает.
Использовать не Windows Archive, а контрольные точки — это опять же привязка к текущей системе, а вне её будет очень проблематично восстанавливать нужную информацию, что сводит на нет такой способ.
0
Насчет расположения диска с бэкапами на том же сервере — никто и не настаивает именно на таком решении, это лишь один из вариантов.
Есть принципиально 3 наиболее вероятных точки отказа на КД — это HDD, БП и MB. CPU — маловероятно. HDD у нас в рэйде. БП крайне желательно иметь в зипе. Ну, а если MB умрет, какая разница где бэкап лежит? Лишь бы он был. Какие бэкапы и каким софтом делать — это отдельная тема. Мы делаем штатными средствами, через Windows Server Backup по сценарию Full server.
Есть принципиально 3 наиболее вероятных точки отказа на КД — это HDD, БП и MB. CPU — маловероятно. HDD у нас в рэйде. БП крайне желательно иметь в зипе. Ну, а если MB умрет, какая разница где бэкап лежит? Лишь бы он был. Какие бэкапы и каким софтом делать — это отдельная тема. Мы делаем штатными средствами, через Windows Server Backup по сценарию Full server.
0
Если КД один и умирает MB (или любое другое железо) — то стоит иметь запасную в холодном резерве. Не такие уж и большие расходы (тем более, их можно растянуть во времени) для бесперебойной работы и малого времени простоя.
Да и второй КД тоже можно докупить со временем. Расходы не обязательно могут быть единомоментны.
Да и второй КД тоже можно докупить со временем. Расходы не обязательно могут быть единомоментны.
0
Чем отличается второй КД в инфраструктуре от зипа для КД? Минусом корпус, плюсом — время на ремонт и восстановление. Стоит оно того?
0
В идеале холодный резерв должен быть в дополнение к двум КД.
Потому что второй, третий, четвёртый и так далее КД — это не главный КД в инфраструктуре, главный всегда в единственном экземпляре, и при выходе его из строя лучше его и восстанавливать как можно быстрее, чем перенастраивать дублирующие.
Потому что второй, третий, четвёртый и так далее КД — это не главный КД в инфраструктуре, главный всегда в единственном экземпляре, и при выходе его из строя лучше его и восстанавливать как можно быстрее, чем перенастраивать дублирующие.
0
Понятие главного КД — преданья седины глубокой. Мы говорим о первом и единственном домене в первом и единственном лесу. Роль GC MS рекомендует поднимать на каждом КД в домене. В данном случае у нас не будет ГЛАВНЫХ и НЕглавных контроллеров, в этом вся прелесть. Остальные роли могут быть просто захвачены любым контроллером по желанию Администратора, лишь бы этот КД был GC.
0
Главную ТО забыли — пользователь.
Бекапы должны быть 3-х уровневыми:
1. Диск на сервере который бекапим — допустимо при ГАРАНТИИ полного восстановления из Архива;
2. Архив на Отдельном сервере — максимально удаленном ФИЗИЧЕСКИЙ от первого сервера;
3. Внешний диск в машине админа/ДИТ/ДСБ — таких дисков должно быть 3 один в сейфе в банке, второй в сейфе в конторе третий в работе и ротаци не реже ОДНОГО раза в месяц.
И самое главное — раз в Квартал(лучше раз в месяц) генерал/дит/дсб — должны Видеть и проверять как Админ восстанавливает с ПОСЛЕДНЕГО бекапа хотя бы по одному ключевому компоненту системы(ДБ, КД, Архив Документов пользователей).
и то есть шансы просрать все… опыт…
Бекапы должны быть 3-х уровневыми:
1. Диск на сервере который бекапим — допустимо при ГАРАНТИИ полного восстановления из Архива;
2. Архив на Отдельном сервере — максимально удаленном ФИЗИЧЕСКИЙ от первого сервера;
3. Внешний диск в машине админа/ДИТ/ДСБ — таких дисков должно быть 3 один в сейфе в банке, второй в сейфе в конторе третий в работе и ротаци не реже ОДНОГО раза в месяц.
И самое главное — раз в Квартал(лучше раз в месяц) генерал/дит/дсб — должны Видеть и проверять как Админ восстанавливает с ПОСЛЕДНЕГО бекапа хотя бы по одному ключевому компоненту системы(ДБ, КД, Архив Документов пользователей).
и то есть шансы просрать все… опыт…
0
Немого ошиблись с определением «критической массы». Меньше 100 пользователей это все еще малый бизнес — с соответствующим бюджетом на IT.
Ставить 2 сервера (пусть и один виртуальный) только для удобства управления доступами или любознательности админа никто в здравом уме не будет. А еще и лицензии покупать.
Обычно все ограничивается самосборным файловым/почтовым/прокси сервером.
Исключительно по экономическим причинам, или после проверки ПО на легальность.
Ставить 2 сервера (пусть и один виртуальный) только для удобства управления доступами или любознательности админа никто в здравом уме не будет. А еще и лицензии покупать.
Обычно все ограничивается самосборным файловым/почтовым/прокси сервером.
Исключительно по экономическим причинам, или после проверки ПО на легальность.
0
Малый с какой точки зрения? Существуют предприятия с численностью 40 человек и оборотами на сотни миллионов в месяц. С точки зрения налогообложения это уже ни разу не малый бизнес.
Второй сервер ведь нужен не для удобства или экспериментов, а для отказоустойчивости инфраструктуры, дабы не остановились бизнес-процессы из-за какого-нибудь сбоя на мат.плате или в БП например.
Второй сервер ведь нужен не для удобства или экспериментов, а для отказоустойчивости инфраструктуры, дабы не остановились бизнес-процессы из-за какого-нибудь сбоя на мат.плате или в БП например.
0
Да вы правы, не сразу заметил что это платный блог.
Зная я несколько подобных компаний с большими оборотами (8 человек, AD, Exchange, Docvision) там реальная работа — по старинке, в смысле бумажными документами.
Но сегодня есть куда более интересный вариант — полностью работать в облаках, что и выбирают начинающие стартаперы
Зная я несколько подобных компаний с большими оборотами (8 человек, AD, Exchange, Docvision) там реальная работа — по старинке, в смысле бумажными документами.
Но сегодня есть куда более интересный вариант — полностью работать в облаках, что и выбирают начинающие стартаперы
0
Б/у железо дешевле нового. Спасибо, кэп!
+1
И тут от внезапной необходимости капитальных затрат впору схватится за голову: ведь одного контроллера домена будет недостаточно, его падение будет означать остановку работы всех пользователей.
Не будет если настроить кеширование входа в домен. Поэтому если уже есть сервер (почтовый, файловый или приложений) можно смело поднимать контроллер на нем. Затраты 0р при условии, что этот сервер у вас на windows.
0
Так мы теряем не только контроллер, но и те сервисы, которые жили рядом + получаем периодическую деградацию производительности, на таком сервере она гарантирована. Кэширование — это костыль, имеющий очевидную проблему с безопасностью и управлением.
При наличии физического доступа к компьютеру у злоумышленника есть возможность воспользоваться сохраненными учетными данными, то для повышения безопасности рекомендуется отключать локальное кэширование.
При наличии физического доступа к компьютеру у злоумышленника есть возможность воспользоваться сохраненными учетными данными, то для повышения безопасности рекомендуется отключать локальное кэширование.
0
Откуда взялась деградация производительности? От того что на сервер добавили роль контроллера домена?
Кеширование это не костыль а функция имеющая очевидную пользу при отсутствии резервирования контроллера домена.
Расскажите про очевидные проблемы с безопасностью и управлением. Мне они не очевидны.
Кеширование это не костыль а функция имеющая очевидную пользу при отсутствии резервирования контроллера домена.
Расскажите про очевидные проблемы с безопасностью и управлением. Мне они не очевидны.
0
Деградация производительности случится от трафика репликации, если есть другие КД, от трафика инфраструктурных сервисов и нагрузки от них на CPU, RAM и HDD.
Кэширование предназначено для входа в ОС при отсутствии доступа к КД. При этом у пользователя нет доступа к Active Directory, следовательно, нет доступа к сетевым ресурсам и сервисам. Что толку в корпоративной среде от того, что пользователь вошёл в ОС локально с использованием кэша?
Он максимум будет иметь только доступ к локально сохраненным файлам и папкам. А что делать с DNS и DHCP в случае падения единственного КД? Кэширование входа в домен подходит только для использования на мобильных устройств за пределами домена, но никак не в качестве замены упавшему КД.
Совмещать инфраструктурные роли с прочими ролями технически возможно, но крайне не рекомендуется MS и best practice.
Кэширование предназначено для входа в ОС при отсутствии доступа к КД. При этом у пользователя нет доступа к Active Directory, следовательно, нет доступа к сетевым ресурсам и сервисам. Что толку в корпоративной среде от того, что пользователь вошёл в ОС локально с использованием кэша?
Он максимум будет иметь только доступ к локально сохраненным файлам и папкам. А что делать с DNS и DHCP в случае падения единственного КД? Кэширование входа в домен подходит только для использования на мобильных устройств за пределами домена, но никак не в качестве замены упавшему КД.
Совмещать инфраструктурные роли с прочими ролями технически возможно, но крайне не рекомендуется MS и best practice.
0
Деградация производительности случится от трафика репликации, если есть другие КД, от трафика инфраструктурных сервисов и нагрузки от них на CPU, RAM и HDD.
Стоп, стоп, стоп. Откуда у нас взялись другие КД? У нас же был один сервер с почтой файлами и приложениями.
Кэширование предназначено для входа в ОС при отсутствии доступа к КД. При этом у пользователя нет доступа к Active Directory, следовательно, нет доступа к сетевым ресурсам и сервисам. Что толку в корпоративной среде от того, что пользователь вошёл в ОС локально с использованием кэша?
У него есть интернет (если мы его раздаем через роутер, а не через этот же сервер), есть Word, есть Excel. Уже можно жить)
Он максимум будет иметь только доступ к локально сохраненным файлам и папкам. А что делать с DNS и DHCP в случае падения единственного КД? Кэширование входа в домен подходит только для использования на мобильных устройств за пределами домена, но никак не в качестве замены упавшему КД.
А что мы до этого делали с DNS и DHCP, когда у нас не было КД, но так же был один сервер?
Роль КД добавленная на единственный сервер не сильно повлияет на надежность. У нас по прежнему будет большая точка отказа в виде сервера.
0
Ну вот и мы и пришли к общему знаменателю!))) Должно быть 2 КД — или оставаться в рабочей группе.
Сеть с доменом на одном КД — это бомба с часовым механизмом.
Сеть с доменом на одном КД — это бомба с часовым механизмом.
0
Нет, я не согласен))) КД имеет смысл поднимать даже на одном сервере. Плюсы появятся, а минусы останутся теже.
0
Плюсы то появятся, но и риски простоев из-за отказа в узком месте тоже появятся. Если не планировать второй КД — это выстрел в ногу раньше или позже. А если планировать, так почему не сразу? Не такой уж большой будет бюджет по сценарию из данной статьи, не?
0
Риски новые не появятся. Если исходить из того, что уже был сервер для файлов, почты и 1с, то поднятие КД незначительно увеличит риски (сервер не работает — все лежит, независимо от того есть КД или нет).
Если есть бюджет, то вопросов нет. Я бы тоже зарезервировался по железу. Просто я не согласен с тем что КД можно поднимать только в паре. Я считаю, что даже если нет бюджета на второй сервер, КД на одном сервере принесет пользу.
Если есть бюджет, то вопросов нет. Я бы тоже зарезервировался по железу. Просто я не согласен с тем что КД можно поднимать только в паре. Я считаю, что даже если нет бюджета на второй сервер, КД на одном сервере принесет пользу.
0
При наличии физического доступа к компьютеру у злоумышленника есть возможностьсделать с компьютером всё, что угодно.
0
Тоже при обсуждении конфигурации сервера настаивал на SSD.
Просто зачем брать диск на 500 когда будет использоваться 40-50 Гб?
Жаль что пока флеш дороговат для больших объёмов.
Думаю через пару лет даже на 1ТБ HDD уже будут редкостью.
Уже давно железо может стоит гораздо дешевле софта.
Ведь в качестве варианта можно взять само железо БУ а диски поставить новые.
Просто зачем брать диск на 500 когда будет использоваться 40-50 Гб?
Жаль что пока флеш дороговат для больших объёмов.
Думаю через пару лет даже на 1ТБ HDD уже будут редкостью.
Уже давно железо может стоит гораздо дешевле софта.
Ведь в качестве варианта можно взять само железо БУ а диски поставить новые.
0
Зачем SSD на DC? Там нет требований по быстродействию дисковой подсистемы. В цене — выйдет дороже. 2x500Gb б/у = 5400руб, SSD бу не встречал, новые на 40-60Gb тоже не нахожу доступных к поставке. 80Gb SSD Intel стоит от 6000 руб/шт.
0
А вы в DC пихаете Enterprise диски, или сойдут и обычные?
Например, те же интеловские SSD, даже для десктопа, имеют гарантию на 5 лет. И версия на 56 гигабайт стоит дешевле, чем 500 Гб HDD.
Например, те же интеловские SSD, даже для десктопа, имеют гарантию на 5 лет. И версия на 56 гигабайт стоит дешевле, чем 500 Гб HDD.
0
Во первых, хоть 25 лет — гарантия не гарантирует безотказность, выше кажется уже об этом упоминали. Во вторых, где вы их нашли? Дайте пруф-линк, плиз.
0
Спасибо, не надо, уже сам нашел. 3400 в стоке за штуку или 3100 по предзаказу, срок поставки 2 недели. Ну ок, это ваше право, ставьте SSD. )) А я вот о другом задумался — куда б использовать бесхозные 450Gb на КД с пользой для дела ))) Может выделить в отдельный том под репозиторий WDS, например?
0
Слушайте, я, может, отстал, и CIFS опять новой версии, но раньше SAMBA рулила доменом легко… И все дела через openldap настраивались…
0
Б/У Dell C6100 — при цене в пределах 300к (сервак+второй БП + пачка SSD + HDD на 3ТБ резервированного хранения) — ПОЛНОСТЬЮ закрывает потребности предприятия до 200 пользователей. Причем это все реализуется на бесплатном ESXi + Ubuntu server — включая терминалы для пользователей, бекапы(хотя тут всетаки нужна внешняя машина для архива), офис, маршрутизацию, 1с, сайт + магазин и тп… и все в пределах 2-х юнитов и это со 100% резервом по всем критичным компонентам…
0
Во-первых, это в 2 раза дороже. Во-вторых, хотелось бы увидеть очередь из желающих, а главное — способных — все это дело поднять, сопровождать и обслуживать. В-третьих, входит ли в эти деньги резервирование по MB, контроллеру? Сколько памяти у кентавра? Какие процы и сколько их в эти деньги? Какую нагрузку генерят эти 200 пользователей? Сколько в пачке SSDшек и каких?
0
4 ноды — по 1 маме по 2 проца по 24GB памяти
настривается по инструкции из интеренета и реально не требует ничего сложного кроме навыка чтения и базовых знаний по системному администрированию.
не «в два раза» дороже, а полнофункциональное решение закарывающее ВСЕ нужды Небольшой компании.
настривается по инструкции из интеренета и реально не требует ничего сложного кроме навыка чтения и базовых знаний по системному администрированию.
не «в два раза» дороже, а полнофункциональное решение закарывающее ВСЕ нужды Небольшой компании.
0
Ачётакдорага-та, а? На наге ценник 90 645.24 P / шт. И чует моя опа что что-то тут не так )))
0
второй бп + пачка дисков(hdd+ssd), и за 90к там камни квады а не 6 ядерные
0
Я все пытаюсь представить, как обслуживать и ремонтировать такой комбайн. Там хотсвап дисков есть? А если вдруг умрет мамка на средней ноде, её заменить без останова соседних возможно?
0
Хотсвапа на ICH10 в базе вроде нет, но можно отдельно купить и поставить raid контроллер как специальный так и обычный. Hot Add есть и в базе, так что делал программную реализацию показавшую за 2 года достаточную стабильность.
В случае специального контроллера правда теряется возможность установки 10G, но это обычно не критично.
можно —
В случае специального контроллера правда теряется возможность установки 10G, но это обычно не критично.
можно —
0
За что люблю хабр, так это за экспертные комментарии.
«Периодически будет происходить трафик репликации, что будет нагружать сеть – но такова плата за экономию.»
«Такая схема (с двумя КД) теоретически способна выдерживать 100-200 пользователей в сети»
«От RAID можно вообще отказаться, имея второй дублирующий сервер»
«максимум проблем, которые можно поиметь с выходом основного DC из строя — то, что второй контроллер из slave надо переводить в master, а потом уже думать, что делать с первым.»
«Поэтому если уже есть сервер (почтовый, файловый или приложений) можно смело поднимать контроллер на нем. Затраты 0р при условии, что этот сервер у вас на windows.»
«Слушайте, я, может, отстал, и CIFS опять новой версии, но раньше SAMBA рулила доменом легко… И все дела через openldap настраивались…»
«Периодически будет происходить трафик репликации, что будет нагружать сеть – но такова плата за экономию.»
«Такая схема (с двумя КД) теоретически способна выдерживать 100-200 пользователей в сети»
«От RAID можно вообще отказаться, имея второй дублирующий сервер»
«максимум проблем, которые можно поиметь с выходом основного DC из строя — то, что второй контроллер из slave надо переводить в master, а потом уже думать, что делать с первым.»
«Поэтому если уже есть сервер (почтовый, файловый или приложений) можно смело поднимать контроллер на нем. Затраты 0р при условии, что этот сервер у вас на windows.»
«Слушайте, я, может, отстал, и CIFS опять новой версии, но раньше SAMBA рулила доменом легко… И все дела через openldap настраивались…»
+1
«Слушайте, я, может, отстал, и CIFS опять новой версии, но раньше SAMBA рулила доменом легко… И все дела через openldap настраивались…»
Настраивал так zentyal в качестве PDC. Машинки в сети разношерстные были, у кого-то linux, у бухов и кадровиков windows, у шефа MacOS. Windows машинки подключались к домену на ура. Политики тоже работали через windows remote administration tools. Несколько внутренних сервисов: jenkins, icinga, redmine — использовали общую с PDC LDAP базу.
0
Зарегистрируйтесь на Хабре , чтобы оставить комментарий
Бюджетный вариант перехода от рабочей группы к домену