User Tools
GPO для Linux из подручных материалов
Всем привет!
Когда меня спрашивали, а есть ли аналог групповых политик Microsoft для Linux систем, долгое время просто отвечал - “Конечно, ведь есть Ansible”! Сегодня хочется подтвердить это практическим примером, использование которого помогает нам управлять множеством Linux систем в сети и за ее пределами. Еще одна причина появления этого решения заключается в том, что некая компания планировала внедрить на нашем предприятии ПО с красивым названием “Система управления конфигурациями” (представьте, как звучала аббревиатура:), но, что-то пошло не так, и после Нового года понадобилось (срочно, как обычно) все сделать самим. Поэтому было решено реализовать только тот функционал, который понадобился в первую очередь:
1. Простой способ инициализации (подключения к нашей системе управления) вводимых в эксплуатацию или уже существующих систем
2. Возможность автоматического управления системами, недоступными по сети “напрямую” (за NAT или Firewall)
3. Возможность поддержки нескольких категорий (профилей) систем
4. Возможность предварительного тестирования конфигураций, перед передачей их в “прод”
IMG_1.png
Эти требования привели к решению, использующему связку Git и ansible-pull (совершенно случайно узнал про него, и вот как пригодилось:)
Коротко про ansible-pull (будем считать, что с самим ansible аудитория уже знакома, иначе вот) - эта утилита загружает из Git репозитория (GitLab, Gitea, …) копию проекта и выполняет из него плейбук с именем local.yml, либо с именем, которое совпадает с hostname системы. Остается описать в проекте все необходимые роли и “запускать” их из этих плейбуков.
По поводу ролей, рассмотрим описанные в предыдущих статьях (см. ссылки):
2. Настройка на использование корпоративного прокси
3. Установка ПО и “иконки” для корпоративного аналога TeamViewer
По аналогии, можно будет добавить любые другие, в том числе, под другие дистрибутивы (в нашем случае будет Debian/Ubuntu).
Итак, поехали!
На компьютере разработчика (у нас будет client1) создаем каталог (в дальнейшем, для краткости, команды создания и переходов в каталоги будут опущены) для нашего проекта, например, ansible-pull-gpo (делать это будем в учетной записи root, что позволит сразу тестировать результат)
client1:~# apt install ansible client1:~# mkdir ansible-pull-gpo client1:~# cd ansible-pull-gpo/ client1:~/ansible-pull-gpo#
Создаем роль (назовем “kerberos”), для включения рабочей станции в домен (все, как в статье по ссылке)
client1:~/ansible-pull-gpo# nano kerberos/files/etc/krb5.conf
[libdefaults]
default_realm = CORP.RU
client1:~/ansible-pull-gpo# nano kerberos/files/etc/pam.d/common-auth
auth [success=2 default=ignore] pam_krb5.so minimum_uid=1000 auth [success=2 default=ignore] pam_unix.so nullok_secure try_first_pass auth requisite pam_deny.so auth sufficient pam_script.so auth required pam_permit.so
client1:~/ansible-pull-gpo# nano kerberos/files/usr/share/libpam-script/pam_script_auth
#!/bin/bash id "$PAM_USER" &>/dev/null || useradd -m -s /bin/bash "$PAM_USER"
client1:~/ansible-pull-gpo# nano kerberos/tasks/main.yml
- name: Install krb5-user libpam-krb5 libpam-script
apt:
pkg:
- krb5-user
- libpam-krb5
- libpam-script
state: present
update_cache: true
- name: Copy krb5.conf common-auth
copy:
src: '{{item.0}}'
dest: '{{item.1}}'
loop:
- [ 'etc/krb5.conf', '/etc/' ]
- [ 'etc/pam.d/common-auth', '/etc/pam.d/' ]
- name: Copy pam_script_auth
copy:
src: usr/share/libpam-script/pam_script_auth
dest: /usr/share/libpam-script/
mode: '0755'
Создаем роль, настраивающую использование корпоративного прокси (самую простую из трех)
client1:~/ansible-pull-gpo# nano proxy/files/etc/environment
https_proxy=http://authproxy.corp.ru:3128 no_proxy=localhost,127.0.0.1,corp.ru
client1:~/ansible-pull-gpo# nano proxy/tasks/main.yml
- name: Copy environment
copy:
src: etc/environment
dest: /etc/environment
Третья роль, обещанная в этой статье, устанавливает ПО и “иконку” для корпоративного аналога TeamViewer
client1:~/ansible-pull-gpo# nano help/files/usr/share/applications/help.desktop
[Desktop Entry] Name=Help Name[ru_RU]=Помощь Exec=/bin/bash -c 'echo -n "Enter ID: "; read -r ID; /usr/bin/x11vnc -connect help.corp.ru:"$ID"' Terminal=true Type=Application Icon=help-browser Categories=Network
client1:~/ansible-pull-gpo# nano help/tasks/main.yml
- name: Install x11vnc
apt: pkg=x11vnc state=present update_cache=true
- name: Copy help.desktop
copy:
src: usr/share/applications/help.desktop
dest: /usr/share/applications/
Создаем плейбук, объединяющий все эти роли и тестируем результат:
client1:~/ansible-pull-gpo# nano local.yml
- hosts: localhost
roles:
- role: kerberos
- role: proxy
- role: help
client1:~/ansible-pull-gpo# ansible-playbook local.yml client1:~/ansible-pull-gpo# reboot
После перезагрузки, должна появиться возможность подключаться любым доменным пользователем, браузер должен работать через authproxy, а в меню графической оболочки, в разделе “Интернет”, должна появиться иконка “Помощь”.
Для доступа к этим ролям с других рабочих станций, разместим все в корпоративном GitLab, если его еще нет, см. 3-й шаг из этой статьи. В дальнейшем, подразумевается имя GitLab сервера - gitlab.corp.ru и учетная запись владельца проекта - student
Создаем публичный проект без readme с названием ansible-pull-gpo (см. 4-й шаг из той же статьи) и выполняем внутри каталога ansible-pull-gpo команды из подсказок нового проекта, предварительно установив утилиту git:
client1:~# apt install git client1:~# cd ansible-pull-gpo/ client1:~/ansible-pull-gpo# git config --global user.email "student@corp.ru" client1:~/ansible-pull-gpo# git init --initial-branch=main client1:~/ansible-pull-gpo# git remote add origin http://gitlab.corp.ru/student/ansible-pull-gpo.git client1:~/ansible-pull-gpo# git add . client1:~/ansible-pull-gpo# commit -m "Initial commit" client1:~/ansible-pull-gpo# push -u origin main
Для сдачи в эксплуатацию следующей системы достаточно выполнить на ней команды (вот он - ansible-pull в действии :)
client2:~# apt install git ansible client2:~# ansible-pull -U http://gitlab.corp.ru/student/ansible-pull-gpo.git client2:~# reboot
Инструкцию ansible-pull можно прописать в cron, что бы обновления конфигурации загружались периодически, но еще лучше, добавить в проект файлы, облегчающие процесс ввода в эксплуатацию новых рабочих станций:
Скрипт start.sh будет устанавливать необходимое ПО и прописывать ansible-pull в cron (каждые 2 часа со случайной задержкой и после перезагрузки), добавляя возможность указывать (например, тестовую) ветку проекта. Вывод команды ansible-pull будет передаваться в syslog
client1:~/ansible-pull-gpo# nano start.sh
#!/bin/bash apt update apt install -y git ansible echo -e "0 */2 * * * \ /usr/bin/ansible-pull -s 120 -U http://gitlab.corp.ru/student/ansible-pull-gpo.git -C $BR 2>&1 | /usr/bin/logger -t ansible-pull\n\ @reboot sleep 1m; /usr/bin/ansible-pull -U http://gitlab.corp.ru/student/ansible-pull-gpo.git -C $BR 2>&1 | /usr/bin/logger -t ansible-pull" | crontab -
Проверить работу скрипта можно здесь же:
client1:~/ansible-pull-gpo# BR=main bash start.sh client1:~/ansible-pull-gpo# crontab -l ...
В readme.md опишем способ запуска, позволяющий инженеру просто скопировать команды из браузера сдаваемой в эксплуатацию системы (цифра 2, между projects и repository, это Project ID проекта из General Settings)
client1:~/ansible-pull-gpo# nano readme.md
sudo -i export BR=main; bash <(curl -s http://gitlab.corp.ru/api/v4/projects/2/repository/files/start.sh/raw?ref=$BR)
После синхронизации изменений в репозитории
client1:~/ansible-pull-gpo# git --no-optional-locks status | grep 'modified\|deleted\|new file\|renamed' | git commit -a -F - client1:~/ansible-pull-gpo# push -u origin main
процесс подключения следующей рабочей станции выглядит как на титульном скриншоте, а именно, после базовой инсталляции системы, инженер подключается локальной учетной записью, открывает браузер, находит (через Explore в GitLab) проект ansible-pull-gpo и копирует из readme.md две команды в терминал. После перезагрузки рабочей станции можно наблюдать процесс применения конфигурации:
clientN$ sudo journalctl -f
Остается рассказать про профили систем. Например, домашние компьютеры сотрудников не нужно включать в домен, но иконка “Помощь/Help” для разрешения удаленного подключения инженера может очень пригодиться. Для этого опишем профиль - просто еще один плейбук, аналогичный local.yml с названием home-comp.yml (в реальности, удобнее использовать отдельный каталог для профилей)
client1:~/ansible-pull-gpo# nano home-comp.yml
- hosts: localhost
roles:
- role: help
Далее, уточняем hostname компьютера сотрудника (например, petrov-home) и создаем одноименный линк на созданный плейбук (hostname должны быть уникальны, компьютерам предприятия они назначается по определенному правилу, которое исключает возможность совпадений)
client1:~/ansible-pull-gpo# ln -s home-comp.yml petrov-home.yml client1:~/ansible-pull-gpo# git --no-optional-locks status | grep 'modified\|deleted\|new file\|renamed' | git commit -a -F - client1:~/ansible-pull-gpo# push -u origin main
После этого сотруднику оправляется ссылка на видео инструкцию (похожую на эту) и он самостоятельно подключает свой компьютер к нашей системе управления. В дальнейшем, можно создать в проекте новую роль, например - openvpn, добавить ее к плейбуку home-comp.yml и она будет выполнена (в течении 2-х часов или после загрузки) на всех компьютерах, hostname которых мы “прилинковали” к файлу home-comp.yml
Вот такое решение “из подручных материалов”. Мы его активно используем, добавляя, по необходимости, новые роли (в том числе, настройку 1С, установку офиса Р7 и прочее).
Спасибо, что дочитали до конца, буду рад, если кому то пригодится и ответить на вопросы, а, так же, советам в комментариях!
