Как правильно управлять парком серверов Unix?

Добрый день, работая windows средой не имею понятия как управлять парком серверов на unix based ос, в частности не понятно каким способом происходит управление по обновлениям, по политике.
например в виндовс есть АД, и групповая политику, всус, + инструменты сервера как DAC, иными словами все управляется через в 2-3 окнах.

вот вопрос
1. как происходит обновление в линукс, если в сети есть разные версии линукса, редхат, дебиан, с разными версиями ядра, по.?
2. каким образом централизовано можно управлять политикой безопасности? я понимаю можно скрипт написать и запустить через ansible, но это думаю костыль.
3. каким образом происходит централизованное управление учетных записей?
только не самба4 и лдап, имитация АД, это костыль.
4. допустим крутиться сервер, выпустили обновление, стоит ли обновлять ядро? ведь при обновлении есть вероятность что не будет работать субд.
как все это мониторится, чтобы знать что на каком то сервере не обновился политика паролей.

ожидаю дружественный ответ.
  • Вопрос задан
  • 3080 просмотров
Решения вопроса 1
igortiunov
@igortiunov
Приветствую.
Прежде всего, не стоит представлять себе решение задачи, как "большую кнопку", т.к. наши представления об управлении инфраструкурой несколько извращены опытом работы с продуктами MS. Интерфейс скрывает от нас стек ПО используемого для достижения цели. Например, WSUS. Под его капотом находится набор служб, каждая из которых играет определенную роль - bits для загрузки на сервер и доставки пакетов на клиента, веб-сервер для управляющих команд, база данных для хранения состояния клиентов и исправлений, .net приложение, обьединяющее все это. Для парка nix машин вам предстоит построить подобную архитектуру самому, выбирая каждый раз инструмент, который будет играть ту или иную роль.
На втором шаге вам нужно посмотреть на задачу. Если у вас десяток инфраструктурных серверов, то Ansible действительно неплохой выбор. Но только не "скрипт". "Скрипт" - это язык, который говорит как достичь результата. Но инструменты управления конфигурацией избавляют вас от этого, с помощью декларативного языка вы описываете сам конечный результат(это ключевой момент) и не задумывайтесь о том, какой дистрибутив (читай менеджер пакетов, расположение конфигурационного файла) установлен на управляемой системе.
Если вам нужно дать доступ большому количеству пользователей к большому количеству машин, то на первом шаге вам нужно выбрать два инструмента:
1. управление конфигурацией.
2. управление sudo.
Первый инструмент с натяжкой может предоставить вам возможность решить пункт 2, т.к. в этом втором пункте вам нужно управлять теми самыми политиками: группе пользователей дать доступ на группу машин и разрешить выполнять группу команд. Здесь в игру вступает Identity Manager и этот вопрос для меня по крайней мере, открыт. Текущие тенденции ведут к развертыванию двух каталогов (MS AD и каталог для парка NIX), но не берусь сказать насколько это правильно. Обойтись без второго каталога можно и, если отбросить шелуху, то ключевой проблемой, в таком случае, является сопоставление идентификаторов безопасности пользователей в MS AD и в nix системах (просто когда один домен, сложнее когда лес, совсем не просто в случае созданных вручную доверительных отношений). Раньше этот вопрос решал winbind с набором библиотек, реализующих тот или иной алгоритм сопоставления, теперь это SSSD, реализующий два алгоритма. Опять же вопрос с выполнением привилегированных команд в такой конфигурации не решается. RedHat предлагает скомпанованные в единый продукт инструменты, которые, якобы эти задачи решают. Поддержкак от этого самого редахата стоит бешеных для нас денег, но вы посмотрите из чего состоят такие решения как Sattelit и IdM, это открытые продукты (FreeIPA, candlepin, pulp, katello, puppet и, наконец, foreman.) которые, возможно вам и нужны.
Ответ написан
Пригласить эксперта
Ответы на вопрос 5
@ProFfeSsoRr
Сис.админ по Linux
Могу только своим опытом поделиться: во-первых избавится от зоопарка дистрибутивов. На каком именно остановится - это уже каждый под себя решает, но главное - выбрать один. Далее локальный репозиторий сделать, если это rolling release дистриб, да даже если и нет, а просто много машин - с локального будет в разы быстрее. Ну а потом уже через Ansible все автоматизировать. Разумеется сначала на тестовой виртуалке тестить обновление, потом уже раскатывать на продакшен. У меня вот, по сути, есть десктоп-линукс (на всех десктопах конторы одинаков, соответственно и у меня на компе виртуалка с точно такой же системой, на которой проверяю обновления), есть базовый серверный шаблон (с которого все виртуалки серверные и создаются), его тоже копия на виртуалке есть и тестирую на ней. Ну а специфичные серверы только клонированием виртуалки и проверкой обновлений на ней.
Таким образом у тебя всегда система везде стоит, про которую ты сам уверен, что она рабочая и нет подводных камней вида "вот тут дистрибутив один, а тут другой". У меня несколько сервисов на php например, вот вышел php 7 - все эти машины склонировал, протестировал, программисты все поправили - я на все машины в продакшене php 7 накатил за 1 раз. И т.д. и т.п.
Учетки через LDAP, Samba-то зачем, когда Линукс? Просто один LDAP и все.
Про политику безопасности - это виндовое понятие, в линуксе по-другому слегка. Конфиг везде через ansible обновил и все, если он где-то вдруг его не смог поменять - он ж напишет об этом. Но если ты вначале позаботился и зоопарк дистрибутивов устранил - все будет четко работать в будущем, без головняков.
Ответ написан
@bankinobi
как происходит обновление в линукс, если в сети есть разные версии линукса, редхат, дебиан, с разными версиями ядра, по.?

сначало на тесте, потом на продакшене.
yum update/upgrade
apt-get update/upgrade
допустим крутиться сервер, выпустили обновление, стоит ли обновлять ядро? ведь при обновлении есть вероятность что не будет работать субд.

для этого есть тестовые сервера, на котором проверяются обновления для ОС и СУБД.
лдап, имитация АД, это костыль.

почему считаете, что лдап - это костыль? Потому что не от MSofta?
Тот же 389 Directory Server ведет историю с 1995 года.
Имеет довольно продвинутый web- и cmd-интерфейсы с достаточным функционалом.

А что б получить дружественный ответ, надо задавать дружественный вопрос.
Ответ написан
CityCat4
@CityCat4
Если я чешу в затылке - не беда!
1. как происходит обновление в линукс, если в сети есть разные версии линукса, редхат, дебиан, с разными версиями ядра, по.?


У каждого - своим пакетным менеджером. У дебиана это apt-get, у шляпной линии (Red Hat, CentOS, Fedora) - yum

2. каким образом централизовано можно управлять политикой безопасности? я понимаю можно скрипт написать и запустить через ansible, но это думаю костыль.


Что есть в Вашем понимании "политика безопасности"? GPO Default Domain Policy? Права на файлы? Еще что-то?

3. каким образом происходит централизованное управление учетных записей?
только не самба4 и лдап, имитация АД, это костыль.


Ну щас. Это AD - надстройка над LDAP, с ней прекрасно работают скрипты и программы для LDAP-серверов. Есть альтернативные реализации Directory Server

4. допустим крутиться сервер, выпустили обновление, стоит ли обновлять ядро? ведь при обновлении есть вероятность что не будет работать субд


В винде - да, сплошь и рядом, обновили ядро, отпала СУБД. В линухе такое бывает куда реже. И кроме того, ядро целиком в памяти и даже если заменили физический файл на диске - до перезагрузки используется старое ядро.
Ответ написан
@dyasny
1. во первых не стоит городить зоопарк дистров, надо остановиться на одном и использовать его везде. А дальше для обновлений есть куча варинтов, от yum-updatesd, до ansible yum: name="*" state=latest и до satellite/spacewalk и т.п. Там управление уже не только уровнем апдейтов но и их разновидностями ()безопасность, системное ПО, приложения и т.д.
2. IPA закрывает все эти вопросы.
3. тоже IPA, хотя можно прикрутить любой LDAP или NIS
4. так же как и в винде - проверяемся на тестовом стенде перед запуском апдейтов в продакшен. еще можно снять lvm snapshot, накатить, и откатиться если что, но это потребует даунтайм.
Ответ написан
@rasergiy
"я понимаю можно скрипт написать и запустить через ansible, но это думаю костыль."
"в виндовс ... все управляется через в 2-3 окнах."

Для начала нужно отбросить шаблоны мышления харакетрные для работающих под виндоус - о том что нужно одно мощное окно, которое кликнешь и оно все сделает. В юниксе совершенно другая концепция, и в серверных технологиях юникса основой интерфейса является ТЕКСТ, например тот же самый "скрипт" - логический клей, который связывает в единую, нужную нам логику элементы системы. В юниксе у нас есть готовые "модули" и высокоуровневый програмный интерфейс к этим "модулям", причем язык интерфейса каждый волен выбирать на свой вкус, мне например пайтон нравится. Работающие с виндоус решениями привыкли, что им уже все склеили, продали, остается только открыть окно с парой суперкнопок, и хотят увидеть то же самое привычное суперокно в юниксе. Ээээ. а с чего вдруг? Если вам нравится окошечный интерфейс - пожалуйста, мир виндоус Ваш. Если Вы хотите текстового интерфейса, то для Вас есть мир юникс. Но не надо говорить, что если интерфейс текстовый, то это костыль.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы