gpo_для_linux

This is an old revision of the document!


GPO для Linux из подручных материалов

Всем привет!

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

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

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

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

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

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

Коротко про ansible-pull (будем считать, что с самим ansible аудитория уже знакома, иначе вот) - эта утилита загружает из Git репозитория (GitLab, Gitee, …) копию проекта и выполняет из него плейбук с именем 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 = CORP13.UN
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# cat proxy/files/etc/environment
https_proxy=http://gate.corp13.un:3128
no_proxy=localhost,127.0.0.1,corp13.un
client1:~/ansible-pull-gpo# cat proxy/tasks/main.yml
- name: Copy environment
  copy:
    src: etc/environment
    dest: /etc/environment

Третья роль, обещанная в этой статье, устанавливает ПО и “иконку” для корпоративного аналога TeamViewer

client1:~/ansible-pull-gpo# cat 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 gate.corp13.un:"$ID"'
Terminal=true
Type=Application
Icon=help-browser
Categories=Network
client1:~/ansible-pull-gpo# cat 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

После перезагрузки, должна появиться возможность подключаться любым доменным пользователем, браузер должен работать через proxy, а в разделе “Интернет” должна появиться иконка “Помощь”

Для доступа к этим ролям с других рабочих станциях в сети, разместим все в корпоративном GitLab (если его еще нет, см. 3-й шаг из этой статьи

Создаем публичный проект без readme с названием ansible-pull-gpo (см. 4-й шаг из той же статьи) и выполняем команды из подсказок проекта внутри каталога ansible-pull-gpo, предварительно, установив на рабочую станцию для разработки и тестирования утилиту git

client1:~# apt install git

client1:~# cd ansible-pull-gpo/

...

Для сдачи в эксплуатацию следующей системы достаточно выполнить на ней команды (подразумевается имя GitLab сервера ):

client2:~# apt install git ansible

client2:~# ansible-pull -U http://server.corp13.un/student/ansible-pull-gpo.git

client2:~# reboot

Инструкцию ansible-pull можно прописать в cron, что бы обновления конфигурации загружались автоматически, например, каждые 2 часа, но еще лучше, добавить в проект файлы облегчающие процесс ввода в эксплуатацию новых рабочих станций.

Скрипт start.sh будет устанавливать необходимое ПО и прописывать ansible-pull в cron добавляя возможность указывать (например, тестовую) ветку проекта. Вывод команды 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://server.corp13.un/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://server.corp13.un/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
...

Для упрощения подключения новых рабочих станций можно (прямо в GitLab IDE) добавить в проект файл start.sh, содержащий инструкции из двух предыдущих разделов



, а в readme.md описать способ его запуска, позволяющий инженеру просто скопировать их из браузера сдаваемой в эксплуатацию системы

Старая версия

В отличии от настоящего Microsoft GPO, мы нигде не храним список управляемых машин, фактически, для того, что бы система была под нашим управлением, достаточно в ее Сервис cron добавить (периодически и после перезагрузки) вызов команды ansible-pull, предварительно сформировав инвентарный файл с переменными. Переменные из инвентарного файла определяют, какие задачи и роли Ansible будут выполнены в системе, тем самым определяя ее профиль. Для выполнения этих действий добавили в репозиторий bash срипт, выполняющий все необходимое, в том числе, формирование инвентарного файл с Использование диалоговых окон. Скрипт подразумевает возможность многократного перезапуска для изменения (пункт 3) профиля системы

Используя Подключение через API сделали простой URL, который достаточно открыть оператору в любом браузере (можно даже curl) и скопировать команду в консоль с повышенными привилегиями. Команда позволяет указать другую Git ветку проекта, например тестовую.

Теперь осталось добавлять в проект задачи и роли, определять (при необходимости) соответствующие им инвентарные переменные и учитывать (при необходимости) версию дистрибутива.

Для демонстрации давайте рассмотрим задачи …

gpo_для_linux.1682921446.txt.gz · Last modified: 2023/05/01 09:10 by val