Опубликован новый выпуск gpupdate, инструмента для применения групповых политик в дистрибутивах «Альт». Механизмы gpupdate применяют групповые политики на машинах-клиентах как на системном уровне, так и для отдельных пользователей. Инструмент gpupdate является частью альтернативного решения компании «Базальт СПО» по реализации доменной инфраструктуры Active Directory под Linux. Приложение поддерживает работу в доменной инфраструктуре MS AD или Samba DC. Код gpupdate написан на языке Python и распространяется под лицензией GPLv3+. Установить gpupdate можно из стабильной ветки p10 репозиториев ALT...Подробнее: https://www.opennet.me/opennews/art.shtml?num=58509
Приведите примеры когда это полезно.
Когда надо применять доменные политики к linux-машинам.
Ваш кэп.
Когда хочется продавать винду учреждениям, но ты не майкрософт и у тебя на руках только линукс.
Из описания похоже, что оно под рутом работает. Ну или какие-то хитрые capabilities.
Это типа Puppet/Ansible? )
Нет. Это типа групповые политики для тех кто "хочу как у майкрософт"
>Active Directory под Linux
>SambaСпасибо, не надо нам ethernalblue и wannacry.
Как будто админчика в конторе кто-то будет спрашивать, что ему надо, а что не надо.
>не надо намВам и не предлагают. мамкины какеры вообще лесом идут.
А вот инструменты администрирования — вещь нужная.
Админам локалхоста действительно не надо
Поразительно. "Догнать и перегнать" в действии. MS заявляет уже больше 10 лет, что GPO мертвы как технология, но не удаляет их ради обратной совместимости, а кто-то (Базальт СПО) делает несвежий клон почившего мёртвого трупа. Мне логика видится так, будто заказчики, импортозамещуны и даватели грантов спрашивают: "а у вас есть групповые политики", а Альтовцы и отвечают: "на те, вот они"... а то, что они мертвы...Это технология времен NT 4.0, сейчас другая реальность. Эти политики были вытеснены двумя технологиями: System Center Configuration Manager (ныне Microsoft Endpoint Manager) и Desired State Configuration, которые в отличии от GPO легли в основу сервиса MS Intune.
Логика Powershell DSC криво и косо, но может быть заменена на Python + Ansible с той лишь разницей, что Ansible не подходит для синхронизации состояний с базой, хотя при желании и это можно нагородить. В DSC есть возможность использовать Pull Server.
SCCM/MEM - это больше про развертывание и управление, DSC про конфигурацию и автоматизацию. GPO же при этом немножко и херовастенько делоют и одно, и второе, но не до конца.
Если вы реализуете аналогичные технологии "как у MS", берите тогда уж нормальные. Опять же, если уж тащить старьё у MS, то то старьё, которое актуально и проверено временем, чай, "координатор распределенных транзакций", например, поддержку стандартов DMTF (WS-Management, WBEM) и файрвол еще можно нормальный сделать, который не "для сервера, админ лучше знает", а тот, который может накинуть ipsec на некоторые типы соединений, потребовать аутентификации Kerberos для установки соединений с определенными хостами и вообще загнать воркстейшены в DMZ друг от друга... но нет.
Какие дальше чудесные прорывы дна^W нас ждут от Базальт СПО? Поддержка скриптов bat и Visual Basic? Или может добаление исполняемых файлов внутрь ODF документов, с возможностью их регистрировать и обращаться к ним из других документов (OLE и ActiveX). Эдакое развитие... но только в обратном направлении.
Ну так у альта бюджет будет поменьше майкрософтовского. Выбрали простейшее и уже всем известное, не все вкурсе про новые технологии.
А кто сказал, что gpo мертво? Я уверен, что более чем 90% организаций мало-мальски приходят к домену и самое безобидное и внедряемое решение - это как раз Актив Директори с политиками. Быстро развернул, настроил и ты уже "бог" сети.
Сделали бы они это лет 5 назад... Но все равно АЛЬТовцы молодцы, это нужный и правильный шаг, пусть и немного назад.
> А кто сказал, что gpo мертво?Это сказал Microsoft и на это есть причины:
- как инструмент они не подходят ни для установки и обновления программ на конечных рабочих станциях, потому что они замкнуты на определенные версии ОС Windows и определенные версии API.
- они не вполне подходят для конфигурирования чего-то кроме того подмножества функций Windows, под которые есть шаблоны, потому что стороннее приложение должно реализовать GPO у себя и дать шаблоны. Правильно так: у ПО есть конфигурация и API для управления, вместо приписывания GPO сбоку конфигурирующая инфраструктура должна использовать родные инструменты, а не заставлять разработчика велосипедить
- GPO - это технология времен COM+/DCOM и не вполне поддерживает современный Windows Desktop, ввиду перехода последнего везде где можно на маршалинг средствами CLR
- И при конфигурировании и при развертывании нет возможности убедиться ни в верном результирующем состоянии конфигурации/развертывания ни наоборот представить всё в виде модулей патчей на конфигурацию. Это техническое ограничение самих механизмов GPO
- GPO и кластерные развертывания - отличный способ прострелить себе обе ноги, потому что GPO не поддерживают транзакционные модели конфигурирования, нет понятия инвентаря, вообще ничего нет. Отправив GPO на кластер вы можете только надеяться, что всё пройдет гладко, при условии если хранилища конфигураций что-нибудь вам гарантируют.
- Конфигурация даже собственных подсистем Windows, которые хранят конфигурации в БД (ESENT, WID, MSSQL, SQLite) не возможна по определению.
- GPO требуют наличие периметрического домена, если нужно их применять на хосты в демилитаризованной зоне.Вы вдумайтесь особенно в последнее. Не все серверы и рабочие станции должны быть в едином лесу. У вас есть внешние недоменные сервера, которые смотрят в Интернет через NAT. У вас есть переносные рабочие станции, мобильные телефоны и прочее. GPO же работает только в домене. Если вы хотите GPO, то ставьте периметрический домен или меняете устройства на те, которые поддерживают ADDS. Просто разочек разверните периметрический сайт за файрволом или периметрический домен с однонаправленым доверием ради пары GPO... мало кто так делает из-за необусловленно большого объёма работ.
На основании этих причин Microsoft заявил, что развивать GPO он не будет. Он его меняет на те инструменты, которые более эффективны для выполнения задач, но при этом никто их удалять не планирует.
GPO решает вполне конкретные задачи. Решает их из рук вон плохо чисто с технической стороны и сейчас и 5 лет назад и 10 лет назад. В Linux-инфраструктурах тоже есть эти задачи, но Альтовцы зачем-то пытаются копировать неудачный опыт MS в вопросах оркестрации и конфигурирования. Если уж не можете писать своё и надо копировать у других, ну возьмите за основу SCCM. С DSC при этом будут проблемы, потому что у большинства программ не выделенных объектов для конфигурирования (нет объекто-ориентированного API для конфигурации), но есть документы. Ну вот и реализуйте транзакционную модель применения патчей на документы в /etc и выдаёте это как API на вебсервисы, как это делает тот же https://github.com/haproxytech/dataplaneapi
Но нет, вместо того чтобы придумать что-то реально работающее и конкурентоспособное, русское IT, копирует на западе то, что плохо лежит и морально устарело, дабы "догнать и перегнать". Совковый подход, как с советской микроэлектроникой.
Поставил + за достаточно развернутое высказывание. Конечно гпо давно устарело. Но пока его окончательно не стёрли как 16битные проги, оно увы будет долго :(
Это почему устарело?
> System Center Configuration Managerя помню времена, когда это называлось "SMS".
да, иненно как спам, приходящий на телефоны.
я почитал книгу от МС, впечатлился и в тестлабе попробовал развернуть.
оно поставило жирнейшего клиента на каждую рабочую станцию.
после чего я плюнул и забил.
интересно, сейчас что-то изменилось ?
> интересно, сейчас что-то изменилось ?Нет и не изменится никогда.
Задачи, которые выполняются через SMS, он же SCCM, он же MEM - это задачи инвентарного учёта, массового развертывания и управления конечным оборудованием пользователей. Ближайшее что похоже на него в Linux - puppet. Его агент учитывает не только огромное количество служб и вариантов конфигурации пользователя, но и то что операционные системы там могут быть разные вплоть до Android. Жирность же - это понятие весьма относительное, люди под Windows ставят антивирус, каждый из которых, по сути, тоже жирный Endpoint Manager, но только под узкоспециализированные задачи. Развёртывание SCCM/MEM - это вопрос ITIL/ITSM, а не вопрос условных попугаев производительности рабочей станции.
При этом его не ставят на сервера, потому что там нет пользовательского участия при конфигурировании и установке ПО. Это касается также любых терминальных серверов и серверов виртуализации. Особенно это касается инфраструктуры виртуализации рабочих столов. Если ваши пользователи используют виртуальные рабочие столы и сессионные терминалы, особенно с тонкими клиентами, то вместо SCCM вы используете системы учета и управления родные для этих систем. Либо вы используете решения по оркестрации вроде SCOrch, Ansible или сами пишите что-то поверх DSC.
Линукс- Линуксом, а доменные политики хочется
Так уходи на Windows OS. Что что тут делаешь?
> Так уходи на Windows OS. Что что тут делаешь?А почему бы и да?