02.05.2023 07:38
valvalva 2 3300 Источник

Всем привет!

Когда меня спрашивали, есть ли аналог групповых политик Microsoft для Linux систем, долгое время просто отвечал - “Конечно, ведь есть Ansible”! Сегодня хочется подтвердить это практическим примером, использование которого помогает нам управлять множеством Linux систем в сети и за ее пределами. Еще одна причина появления этого решения заключается в том, что некая компания планировала внедрить на нашем предприятии ПО с красивым названием “Система управления конфигурациями” (представьте, как звучала аббревиатура:), но, что-то пошло не так, и после Нового года понадобилось (срочно, как обычно) все сделать самим. Поэтому было решено максимально просто, без программирования, реализовать только тот функционал, который понадобился в первую очередь:

  1. Простой способ инициализации (подключения к нашей системе управления) вводимых в эксплуатацию или уже существующих систем.

  2. Возможность автоматического управления системами, недоступными по сети “напрямую” (за NAT или Firewall).

  3. Возможность поддержки нескольких категорий (профилей) систем.

  4. Возможность предварительного тестирования конфигураций, перед передачей их в “прод”.

Эти требования привели к решению, использующему связку Git и ansible-pull (совершенно случайно узнал про него, и вот как пригодилось:)

Коротко про ansible-pull (будем считать, что с самим ansible аудитория уже знакома, иначе вот) - эта утилита загружает из Git репозитория (GitLab, Gitea, …) копию проекта и выполняет из него плейбук с именем local.yml, либо с именем, которое совпадает с hostname системы. Остается описать в проекте все необходимые роли и “запускать” их из этих плейбуков.

По поводу ролей, рассмотрим описанные в предыдущих статьях (см. ссылки):

  1. Подключение к домену

  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 и прочее).

Спасибо, что дочитали до конца, буду рад, если кому то пригодится и ответить на вопросы, а, так же, советам в комментариях!

Комментарии (2)