Comments 14
Вопрос немного не по теме, но все же... Судя по всему организация у вас довольно масштабная, не проще организовать получение лицензий альтернативным способом?
В целом, проще, конечно, но есть ряд "но".
Проблема альтернативных лицензий в том, что они "не обеспечивают гарантированную работоспособность", а непрерывность бизнеса - постулат.
Плюс никто не отменял правительственную программу по импортозамещению, и вот это все.
Для малого бизнеса "иранский офис" будет допустимым выходом, наверное. Для крупного - под большим вопросом.
Стратегически это может привести к остановке бизнеса, гайки закручиваются и будут закручиваться, в один прекрасный момент софт Х может оказаться вне закона и не важно какая там лицензия, хоть марсианская. Поэтому, замещать софт стоит.
Ни одна из других существующих VDI-систем не умеет работать с Instant Clones
можно в двух словах что это и зачем?
Отдавать офисным работникам Linux с xfce на борту — это парализовать работу офиса на неопределенный срок. Если более-менее привычные к ПК ребята освоятся достаточно быстро, но тоже не сразу, то тётушки-бухгалтеры — скорее никогда, чем быстро
честно говоря не понял, если у вас активно используется VDI, то какая разница что за DE на рабочем месте?
можно в двух словах что это и зачем?
В двух словах. Или можно попробовать LMGTFU.
честно говоря не понял, если у вас активно используется VDI, то какая разница что за DE на рабочем месте?
Потому, что на тонких клиентах сидят далеко не все. И кому-то удобно сидеть на толстом клиенте, потому что им "религия не позволяет". Например, разработчики терпеть не могут VDI, потому что всем известный Kaspersky и его менее известный продукт agentless, режет скорость по сети в 42 раза. И они об этом знают, но не могут в своих темплейтах аплаенсов поменять e1000 на vmxnet3. И разрабы не хотят ждать, пока у них пересчитываются индексы по 30с вместо 0.5с, и сборка проекта занимает до получаса вместо 2 минут.
Есть еще множество причин, но и этого хватит для ответа на поставленный вопрос.
Тема моего дипломного проекта "Применение свободного программного обеспечения, при организации автоматического рабочего места медицинского работника". АРМы - моноблоки от поганого Леново. ОСь - чистый дебиан 9 с четвёртым гномом (АРМы поставились министерством здравоохранения с приказом не менять ОСь и его версию!). По итогу имеем: ВЕСЬ необходимый медикам софт для их работы + личные хотелки в виде месседжеров, просмотрщика DICOM-снимков и др . Гном вырезан под корень, вместо него накатана XFCE с самописаными темой оформления и набором иконок. Для работы софта написанного only for windows заюзал wine в режиме multiuser (экономим место на HDD, при работе не одного десятка юзеров на одном моноблоке), остальное заменено опенсурсными аналогами. Для разворота преднастроенного сеанса пользователя (панели, иконки, меню, нескучные обои ;), mimсы типов файлов), написал генератор сеансов. Для того, чтобы не линуксовые админы загоняли свежие тачки, после прошивки в домен AD, так же написал скрипт и с выборкой действий под разные ситуации - новая дефолтная тачка для стационара, тачка для гинекологов и акушеров отделений гинекологии, роддома и женских консультаций или работников мед.статистики - у них свой софт, который никто больше не юзает - изменение набора софта и преднастроенного сеанса юзера.
Сам деб поставлялся с предустановленными касперским, криптопро, випнетом и поделием под название сикретнет. КриптоПро норм работает, випнет без эл.почты, а значит - не нужен. Касперский с локального сервера поставил - требование ФСБ с их ежегодными проверками. Сикретнет - становил демоны и грохнул из авторана, если нужен будет, то он настроен не вредить системе и поднимается так же скриптом с последующей разблокировкой ОСи ибо что курил разраб, я не знаю почему он сразу блокирует тачку, при его активации либо остановке(((
Все скрипты писал на bash, вайн нафарширован и запакован в тарбол. Устанавливается нужная версия нафаршированного вайна так же скриптом загона тачки в домен. Сам образ нафаршированной ОСи и его новые релизы (хотелки врачей практически каждый месяц первого года внедрения линуха приходили, та и сами скрипты модернизирую время от времени и пишу новые) делаю клонзиллой и разворачиваются через PXE той же клонзиллой виртуальным сервером.
Принтеры в больнице и её филиалах я ногами обошёл и нашёл, установил, и проверил драйвера. Работают ;) До сканеров пока дело не дошло, т.к. мало используются медиками.
В общем, тачки активно используются. На сегодняшний день поставлено в эксплуатацию 98 машин из 178. Кому нужно было работать в современных реалиях тяжёловесности софта и заменить старые компы 20летней давности, те спокойно работают под линухом. Кто ругался по началу, те - привыкли. Кто поумнее, просит сразу помочь с литературой или практической помощью в обучении работы с новым софтом и ОСью, в чём не отказываю ибо сам натыкался так же на повсеместный RTFM 17 лет назад, когда перешёл на линух с мастдая. Ну, а отвечать тем же своей семье, которая так же работает/играет на компах и ноутах, работающим на линухе - как-то стрёмно ;)
В чём был посыл моего комента? Не так страшен и плох линух на десктопе. Просто его нужно уметь приготовить и забэкапить ;) Ну и, естесствено, обучить пользователя, если он конечно желает того...
Вместо Ansible для такой задачи я бы взял Puppet т.к у него более подходящий метод обновления, клиенты сами идут на сервер, можно настроить что бы при загрузке системы шли, собственно как gpo в винде.
Да, Puppet обеспечивает гарантированную доставку настроек, в отличии от Ansible.
Проблема Puppet в том, что он.. нечеловеколюбче. Я в процессе его деплоя, но это какой-то тихий ужас. Для того, чтобы скопировать несколько файлов, нужно написать на каждый отдельную директиву, если их нужно положить в разные каталоги.
То, что делает Ansible через loop: и список 1_строка=1_сущность, в Puppet делается через боль и страдание.
Дебажить Puppet - то еще удовольствие. У меня до сих пор вызывает удивление необходимость указывать shell для работы банального cp.. и пути, в которых он будет искать командлеты для exec..
В итоге, если у меня наконец-то получится дописать манифесты.. мы будем использовать оба инструмента, так как разворачивать ПК через Puppet невозможно, а вот гарантированно доставлять настройки - да.
У меня тоже самое, начальные настройки через Ansible, Puppet только для актуализации конфигов + список служб которые должны работать.
Я не сказал бы что паппет такой бесчеловечный, вполне себе нормальная штука, если не нужно полностью все настройки клиента описывать, но, думаю, для этого есть какие-нибудь генераторы конфигов, но тут не знаю - не искал, систему сразу такую делали.
А, да, все клиенты должны быть с поднятым vpn, если у них есть интернет, так что всегда ансиблом можно прописать новую конфигурацию.
Подскажите, почему для своей системы не установили групповые политики? У Альта есть и ГП, и вашем случае сам бог велел с ними работать. Simply поддерживает работу с ГП в ОС Альт.
Потому что громкие лозунги "мы сделали ГПО для линукс!" - это всего лишь лозунги.
Они либо не работают, либо работают не так, как от них ожидается. А та часть из них, которая действительно работает - это лишь капля в море, которую просто нет смысла использовать.
Условно: можно, наверное, мапить диски через ГПО. Но задача была более тонкой - мапить диски в момент обращения. ГПО так не умеет. Более того, судя по тому, как работает pam_mount (а он не работает вообще), политика мапинга дисков будет работать примерно так же - читай никак.
Отсюда и решение их не использовать.
И да. Постдеплой через Ansible для ПК - прохладная история. Тут нужен какой-нибудь Salt\Puppet или что-то в этом роде. Клиент-серверное.
Очень странно слышать про pam_mount. В реализации gpupdate от ALT используется automount:
https://github.com/altlinux/gpupdate/blob/master/gpoa/frontend/cifs_applier.py
Поэтому проблемы "мапить диски в момент обращения", по сути, нет.
Почитал и текст статьи, и текст плейбуков, и комментарии - автор ошибается почти везде.
И по выбору дистрибутива, и по механизмам в плейбуке (у альта есть нативные инструменты и для ввода в домен и прочего), ну и по ГП тоже ерунда
Импортозамещение на практике. Часть 6. Пользовательские рабочие места