Компания
197,30
рейтинг
24 апреля 2012 в 13:54

Разное → Система управления авторизацией пользователей на тысячах серверов

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

Одно из главных требований в таких условиях — иметь полное представление о том, что и когда происходит на серверах, находящихся в зоне личной ответственности, но доступ к которым имеют еще как минимум несколько десятков разработчиков.

Сегодня мы поговорим об авторизации пользователей на Linux-серверах с использованием БД MySQL и приложения Puppet.

Требования к системе и возможные решения


Итак, перед нами стояла задача внедрить централизованную систему управления доступом пользователей к серверам.

Безусловно, подобная система у нас уже была, и работала она вполне приемлемо, выполняла возложенные на нее задачи и в целом соответствовала нашим требованиям. Управление также было централизованным.

Но с течением времени стали появляться новые задачи, решать которые в существующих условиях становилось проблематично. И все чаще мы понимали: пора что-то менять в этой схеме. В конечном итоге было решено доработать текущую систему, чтобы она соответствовала нашим запросам.

В результате размышлений сотрудников IT-отдела появилось несколько идей:

  1. Использование директории LDAP в различных вариациях.
  2. Формирование списка пользователей в одном месте, выкладывание этого списка на все сервера (возможное управление доступом на уровне access.conf).
  3. LDAP в паре с Kerberos.
  4. Формирование пакетов (например, rpm) на основе некоего хранилища с дальнейшей установкой (например, как обновление пакета).

У каждой из идей были свои плюсы и минусы. Например, в случае в LDAP (или LDAP плюс Kerberos) нам пришлось бы изучать дополнительные сервисы, решать вопросы оптимизации хранения данных в директории LDAP, устанавливать дополнительные LDAP-proxy для снижения нагрузки на основной сервер (потому как нагрузки у нас действительно большие). При выборе вариантов 2 и 4 мы получили бы тот же инструмент, который, увы, перестал удовлетворять нашим потребностям.

Однажды в понедельник (после основательного отдыха и в силу хорошего настроения) появилась одна интересная мысль: в нашей работе мы используем приложение Puppet, в том числе и для выдачи прав и полномочий пользователям. Так почему же не использовать его как основной инструмент?

Тут и началось самое интересное: готового решения не было, но существовал перечень обязательных требований к нашей системе:
  1. При выборе пользователя получать список доступных ему хостов.
  2. Выдавать пользователю sudo-привилегии, которые могут быть разными в зависимости от хоста.
  3. Немедленный отзыв привилегий и доступа по требованию.
  4. Легкость управления (добавление, удаление, правка).
  5. Отсутствие необходимости создавать новые службы и сервисы, которые впоследствии придется изучать, поддерживать и сопровождать.
  6. Не привязывать сервера к внешним источникам авторизации, т.к. использовать локальную Unix-авторизацию надежнее и уже проверено временем.

И в качестве бонусов хотелось бы получить следующее:
  • поддержка ключей rsa, dsa в неограниченном количестве;
  • отслеживание изменений;
  • поддержка templates для одинаковых задач (далее в статье описано, для чего это нужно);
  • поддержка «регулярных выражений» в поле «Сервера, к которым есть доступ»;
  • поддержка групп;
  • поддержка квот.

В итоге было решено хранить структуры данных в MySQL (хранение в БД нам показалось удобным. Та структура, что есть в ней, может храниться и другими способами.), генерировать puppet-like манифесты «самописным» обработчиком, а также «приделывать» ко всему этому простой WEB UI. Забегая вперед, хочется сказать, что результат превзошёл наши ожидания, т.к. на этапе написания были добавлены важные и интересные моменты.

Реализация идеи


Сразу отметим, что мы имеем несколько географически удаленных площадок, где размещено оборудование; далее обозначим их «Платформа 1», «Платформа 2» и т.д. Обращаем ваше внимание, что приведенная ниже структура хранения данных показана только в качестве примера.

Сервера (узлы) в нашем примере будут иметь следующие обозначения:
  • www — это веб-кластер, который включает в себя все узлы, например www1, www2… wwwN;
  • www134 — это один конкретный узел из группы веб-кластера;
  • www[15-17] — это узлы www15, www16, www17 из группы веб-кластера (используется для того, чтобы не писать их по очереди).

Структура базы данных


1. Таблица Users — основная таблица, содержащая следующую информацию:
  • логин пользователя;
  • ФИО пользователя;
  • группы, к которым он принадлежит;
  • командный интерпретатор (мы не против, чтобы пользователи использовали то, что им удобно);
  • сервера, к которым пользователь должен иметь доступ;
  • публичные ключи;
  • квота на файловую систему (есть необходимость использовать на некоторых хостах);
  • идентификаторы sudo-шаблонов, привязанных к пользователю.

2. Таблица UsersWithBigUid — аналогична предыдущей, но используется для заведения «пользователей для служебных нужд» (например, существует географически удаленный пользователь, который не должен у нас нигде фигурировать, но ему необходим доступ к конкретному серверу, узлу или узлам).

3. Таблица VpnOnlyUsers:
  • логин пользователя;
  • хосты, доступ к которым должен иметь пользователь через подключение по VPN.

4. Таблица TmplSudoersRules с описанием каждого правила sudo, входящего в тот или иной шаблон.

5. Таблица TmplSudoers, содержащая названия и комментарии к sudo-шаблонам.

6. Таблица SystemUsers — почти аналогична таблице с простыми пользователями, но используется для заведения пользователей с неограниченным правом доступа. В таблице присутствует дополнительное поле с идентификатором платформы на тот случай, если пользователь нужен только на одной из низ.

7. Таблица Sudoers содержит персонализированные правила sudo для пользователей.

8. Таблица Hostaliases состоит из алиасов имен серверов, которые в определенных случаях более удобны, чем имена, например, когда на один сервер возложено несколько ролей. С помощью данного функционала мы получаем еще один уровень абстракции и нам не важно имя узла.

Создание нового пользователя и его веб-интерфейса


1. Заполняем общую информацию о пользователе.


2. Выдаем доступ к серверам.
Примечание. Поля *servers — перечисление имен серверов и (или) групп через запятую. Пример заполнения данных полей:
  • %chars — это группа, например, “www”;
  • %chars%int — это конкретный узел, например, “www89”;
  • %chars[%int-%int] — это диапазон узлов в определенной группе, например, “www[17-29]”.


3. Добавляем один или несколько sshpub-ключей.


4. Добавляем sudo-права пользователю.


После добавления пользователя и указания sudo-прав доступы обновятся на всех серверах в течение нескольких минут. Заведение пользователя на серверах можно ускорить, если в этом есть необходимость.

Давайте посмотрим, что нам нужно сделать для получения ACL для VPN. Все более чем просто:
1. Выбираем пользователя.


2. Открываем вкладку VPN, выбираем «Generate VPN». Получаем правило, которое нужно лишь добавить в RADIUS.


Примечание. Безусловно, данные сами по себе не появляются. В нашем случае обрабатываются поля со списком серверов, к которым пользователь имеет доступ. На основании этих данных и формируется VPN access-list. Здесь тоже предусмотрена определенная гибкость, т.е. мы можем выдать доступ как к 1 узлу в подсети, так и ко всей подсети. Дублирование отсутствует, т.е. если есть доступ в подсеть 10.11.12.0/24, то не имеет смысла добавлять что-либо наподобие “ip:inacl#N=permit ip any host 10.11.12.18”. В нашем примере полученные данные необходимо внести в конфигурацию авторизации VPN вручную (мы предлагаем вам самостоятельно поразмыслить, как это можно сделать — пусть это будет своего рода “домашним заданием”).

Несколько примеров (Задача — Решение)


Задача 1: отозвать весь доступ у пользователя.
Решение: очистить поля с указанием серверов у пользователя, после чего он автоматически удалится на всех серверах (домашняя директория не удаляется).

Задача 2: отозвать доступ к определенному серверу.
Решение: убрать этот хост в общем списке хостов пользователя.

Задача 3: предоставить доступ к определенному серверу (серверам).
Решение: дописать нужный хост(-ы) к разрешенным у пользователя.

Задача 4: дать возможность перезапуска nginx на машинах в www-кластере группе лиц.
Решение:
a. Заводим новый sudoers-template, даем ему адекватное имя и комментарий.
INSERT INTO `tmplsudoers` (`tmplname`, `comments`)
VALUES
	('suwwwrun', 'su to wwwrun user and restart nginx if needed'); 
Примечание. Данный пример указан в качестве альтернативы нашему веб-интерфейсу.

b. Добавляем правила, характерные для данного шаблона.
INSERT INTO `tmplsudoersrules` (`tmplid`, `hostname`, `runas`, `commands`, `nopasswd`)
VALUES
	(26, 'www[0-9]*', 'ALL', '/bin/su - wwwrun', 1);
INSERT INTO `tmplsudoersrules` (`tmplid`, `hostname`, `runas`, `commands`, `nopasswd`)
VALUES
	(26, 'www[0-9]*', 'ALL', '/etc/init.d/nginx *', 1);

c. Теперь нам достаточно добавить данный шаблон пользователю в интерфейс, после чего у него заработает весь набор правил.
Примечание. Помимо шаблонных правил мы можем задавать уникальные правила отдельным пользователям.

Задача 5: обеспечить безопасное добавление sudo, поскольку в некоторых случаях безобидное, на первый взгляд, sudo может нанести ущерб безопасности (например, на less, mount или rsync). Разрешить службе HelpDesk давать такие права сотрудникам.
Решение: шаблоны составляют опытные системные администраторы, а сотрудники HelpDesk только ставят соответствующие отметки.
Разрешить сотрудникам HelpDesk назначать шаблоны, но запретить их корректировку, а также запретить выдачу уникальных правил определенному пользователю.

Задача 6: сформировать sudoers таким образом, чтобы не нарушить работу сервера(-ов), потому что наличие некорректного синтаксиса и (или) дублирование директив HOSTALIASES может иметь плохие последствия.
Решение:
a. Перед добавлением или изменением sudoers-файла для пользователя производится проверка синтаксиса (в случае наличия ошибки формируется уведомление, файл sudoers для пользователя не изменяется).
Пример функции на Python:
VISUDO ='/usr/sbin/visudo'
def visudoCheck(filename,user):
    visudo_cmd = 'echo -ne "%s "; echo "%s" | %s -c -f -' % (user,filename,VISUDO)
    (visudo_status, visudo_output) = commands.getstatusoutput(visudo_cmd)
    if not visudo_status == 0:
       print "\n"+filename
       sys.stderr.write(visudo_output[:1024])
    return visudo_status


b. Шаблоны составляют опытные системные администраторы, а сотрудники HelpDesk только ставят соответствующие отметки.

c. При формировании строк “Host_Alias” используются следующие правила во избежание дублирования:
  • если это не шаблон, а «specific-rule», то берется такая маска: “STRING%USERNAME%%USERID%”
  • если это шаблон, то берется такая маска: “STRING%USERNAME%%TMPLRULEID%”, где %TMPLRULEID% — id записи правила.

Другие задачи решаются так же просто, ваши вопросы мы можем обсудить в комментариях.

Принцип работы схемы


  1. Ввод и (или) изменение данных происходит через пользовательский веб-интерфейс.
  2. Сron запускает задачу, которая формирует Puppet manifest для нужной нам платформы.
  3. Если на втором этапе появляется изменение в правиле, то делается commit в репозиторий Git, который хранит данные и сообщает обо всех изменениях.
  4. На сервере с Puppet осуществляется проверка git-репозитария, и как только становится понятно, что есть обновления и (или) изменения – выполняется fetch с новым конфигом.

Скрипт запускается лишь с одним параметром – идентификатором платформы, для которой формируются правила. После выполнения получаем подобный результат:
class virtualusers {
@group { "wwwaccess": gid => 1001, ensure => present }
@user { "petek":
        	 	ensure => $hostname ? {
                                	simplehostname1 => present,
                                	/hostgroup1(\d.*)$/ => present,
                                	/ hostgroup2(\d.*)$/ => present,
                                	/ hostgroup3(\d.*)$/ => present,
                                	…
                                	…
                                	default => absent,
                    	},
        	 	comment => Petek Petkovich',
        	 	gid     => '1001',
        	 	home    => '/home/petek',
        	 	uid     => '1018',
        	 	password 	=> '*',
        	 	shell   => '/bin/bash',
 }  	
	@virtualuser_key { "petek":
        	  	group => '1001',
        	  	name => 'petek',
        	  	key =>"ssh-rsa dqwedqwedqwedqedqwedqwedqwedqwedqewdqwed=",
        	  	require => User["petek"];
	}
@exec { "petek_quota":
        	  	command => "/usr/sbin/setquota -u petek 5242880 5242880 0 0 -a /filesystem/",
        	  	path    	=> "/usr/sbin",
        	  	onlyif  	=> "/usr/bin/test `/usr/sbin/repquota -ua | /usr/bin/egrep '^petek\s*' | /usr/bin/awk {'print \$4'}` -ne \"5242880\"",
        	  	}
@file { "/etc/sudoers.d/1018_petek" :
        	ensure => present,
        	owner => 'root',
        	mode => 0440,
        	content => '';
}
if $hostname =~ /^hostgroup1\d*$/ {
        	realize (Virtualuser_key['petek',’petek2’], File['/etc/sudoers.d/1018_petek', '/etc/sudoers.d/1020_petek2',])
realize (Exec['petek_quota'])
}
}

Для примера и читабельности оставлен только кусок манифеста. По правде говоря, читабельность манифестов нас не сильно интересует, в силу того что сразу после их формирования происходит проверка синтаксиса. Если он в полном порядке, то puppet master способен его прочитать, в таком случае нам незачем вмешиваться в процесс.

Приведем пример проверки синтаксиса:
PUPPET='/usr/bin/puppet'
def puppetparsercheck(filename):
    puppet_cmd = '%s parser validate %s' % (PUPPET, filename)
    (puppetparser_status, puppetparser_output) = commands.getstatusoutput(puppet_cmd)
    print str(puppet_cmd)
    if not puppetparser_status == 0:
       sys.stderr.write(puppetparser_output[:1024])
    return puppetparser_status


Дополнительные плюсы реализации


  1. На каждом отдельном узле действуют только те правила sudo, которые ему соответствуют; посмотреть их можно, набрав sudo -l.
  2. Для удаления пользователей не нужно осуществлять отдельных действий, т.к. если у пользователя нет доступа, то он по умолчанию “ensure => absent” (на языке Puppet).

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

И самое главное, пожалуй, то, что с такой системой способен справиться любой сотрудник «первой линии поддержки» (те, кто помогает с простыми просьбами пользователей).
Автор: @Badoo
Badoo
рейтинг 197,30

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

  • –7
    у меня хром виснет на badoo на некоторых запросах, это известная проблема?
    • +7
      Приведённых технических данных недостаточно для того, чтобы вам ответить однозначно.
      Вы можете обратиться в службу поддержки по адресу badoo.com/feedback/

      Комментарии к статье про администрирование серверов — неудачное место для обсуждения таких вопросов. Страница habrahabr.ru/company/badoo/questions/ подходит куда сильнее.
      • –6
        ну это какая-то техническая особенность работы хрома с вашим сайтом, в фф вроде норм, может какая-то перегруженность js, может в хроме какие-то особенные сетевые действия для ускорения загрузки страниц, может только у меня такое, я так просто спросил, может проблема известная и вы с ней уже боритесь
        • 0
          В последней 18-й версии Хрома стали наблюдаться некоторые досадные ошибки (например белый фон под чекбоксами). Остаётся надеятся, что разработчики скоро их исправят. Возможно, вам стоит сообщить об ошибке в Гугл, команде разработчиков браузера.
          • –2
            да, я что-то находил за 2010 год
            • 0
              Подобную ошибку мы наблюдали, причём в разных браузерах, но она не поддаётся воспроизведению.
  • +3
    Мне кажется ldap все-таки лучшее решенее. Репликация, достаточно быстрое хранилище внутренее (можно sql-backend использовать). Ко всем сервисам прикручивается стандартно: SSH/HTTP auth/IMAP/SMTP/Radius
    • +1
      Да, но в статье речь идет в том числе и о том, что у нас было большое желание уйти от поддержки доп. сервисов и служб, которые в том числе требуют дополнительной конфигурации и «клиентских» узлов. В данном случае «клиентский» узел == любой сервер.
      • +2
        К тому же, ssh не умеет брать ключи из ldap. Есть патч, который это позволяет, но хочется использовать версию из репозиториев.
        • 0
          Справедливости ради в RHEL6 патч с AuthorizedKeysCommand (что даёт возможность брать ключи хоть откуда) включён в пакет.

          Однако, для тысяч серверов приведённое решение мне кажется более подходящим хотя бы потому, что вся аутентификация/авторизация происходит локально.
          • +1
            Мы у себя внедрили решение на базе AuthorizedKeysCommand + NIS
            Решение легко внедряется на RHEL/CentOS 5/6
            • 0
              а как с sudoers поступили?
              • 0
                Поскольку существует несколько десятков групп серверов, на каждом сервере руками при инсталляции в sudoers описываются группы пользователей. А дальше, как обычно, NIS.

                Радостная перспектива, конечно, это sudoers держать в Puppet/Chef/CFEngine/etc.
                • 0
                  радостная она только в том случае, если оно уже есть и используется. А вот если принимается решение о том, что вот «пора» и «нужно/модно», то перспектива начинает казаться уже чем-то не очень понятным, отчего уже не такой радостной.
                  На самом деле, плюсов в том, чтобы так поддерживать sudoers(в том числе), больше, нежели минусов от внедрения.
                  • +1
                    На самом деле, я уже раза 3 пытался подойти к puppet, но каждый раз отвлекался на более важные задачи, находил очередные минусы, например, Ruby, очередные отговорки а-ля «Ну вот как напишут ещё больше примеров внедрения». Тем временем инфраструктура разрастается и надо как-то поддерживать актуальную конфигурацию везде, полагаю, puppet ещё успеет появиться на наших серверах. Но это всё о будущем. А сейчас sshd + AuthorizedKeysCommand + NIS + самописная вебморда управления группами/ключами/пользователями.

                    Тем временем, вечер.
                    • +1
                      Не будет у нас puppet, пока не обоснуешь мне смысл его внедрения. Т.е. не «это круто», а расписать, что нам это позволит получить либо сэкономить.
                      • 0
                        Прочитав Ваш коммент на почту почти испугался, подумав о том, что я кому-то что-то обосновать должен.
                        Если не секрет — как много серверов вам приходится поддерживать?
                        Можем в режиме «задача-решение» обосновать вам возможность такого внедрения.
                        • 0
                          Для ясности: freefd — мой коллега. Коммент был направлен ему :)

                          Для простоты можно взять число в 500 серверов.
                          • +2
                            Ну а в рамках «задача» приведете пример чего-либо, что вам приходится делать? неужели нет задачи, по генерации или контроля конфига какого-либо сервиса, того, чтобы он был, например един для некого «кластера», который обрабатывает конкретную задачу?
                            Мне просто довольно сложно представить ситуацию управления 500 серверами без централизации. Или для примера можно взять ситуацию, когда внезапно у нас случилось так, что в кластере, который отдает статику на машинах нагрузка ~30%, в то время как на тех машинах, что обрабатывают динамику в пиках нагрузка вырастает до ~80-90%. Очевидно, что мы можем выдернуть N машин с первого кластера во второй, но в случае ручной конфигурации нам потребуется сильно больше времени, нежели просто назначить нужные классы с конфигами для этих машин…
                            Тоесть решение задачи, при наличии puppet(ну или того инструмента, что по душе — тут предлагали много иного) сводится к тому, что мы просто назначаем нужные классы нашим серверам и получаем прибавку тому кластеру, которому уж очень тяжело.
                            В случае же, если общая конфигурация системы такая, что изменения в нее вносятся крайне редко, а также дополнительные поставки железа редки, то вполне возможно, что тогда та централизация, которую дает puppet — не сильно нужна.
                            Еще как пример — нужно обновить firmware на железе, по причине выхода критичного багфикса от вендора, но обновить не совсем везде, а только на специфичной платформе, ну например HP Proliant G7 P67. При наличии паппета это решится в 5 строк, с гарантией того, что все у вас обновится.
                            Не знаю, что привести еще в пример, думаю, что легче будет рассуждать только если вы немного обрисуете хотябы абстрактно то, чем приходится заниматься в повседневной работе.
                            • 0
                              Наше окружение живёт практически полностью на виртуализации, физически — блейды. Поставки железа заключаются в инсталляции очередного лезвия в шасси, не более. Уровень абстракции таков, что про хардварную часть зачастую можно забыть, ибо машина может свободно мигрировать и кастомизироваться в пределах существующих ресурсов кластера, состоящего из многих лезвий.

                              Лично мне puppet гораздо более интересен как некое хранилище актуальных конфигураций _сервисов_, быстрого развёртывания новых, массовых изменений существующих. Также можно считать поддержку актуальных версий пакетов, хотя некоторые могут и cssh использовать для таких задач. Тут, как говорится, где больше плюсов.
                              • 0
                                В качестве конфигуратора сервисов он тоже используется. Лично я знаю, что с его помощью конфигурируются почтовые машины.
                        • 0
                          Сержик false detected? :)
                      • 0
                        еще из дополнительных «плюшек» — история внесения изменений, возможность их отката, уменьшение «точек входа» для внесения изменений.
                      • –1
                        ТАК!
                      • 0
                        Это мы уж посмотрим в процессе. «Пока не обоснуешь» закончились в 90е.
  • 0
    Скажите, а как вы с помощью puppet удаляете пользователей? Решали аналогичную задачу, от puppet отказались в пользу ldap, так как puppet вроде бы умеет только добавлять юзеров.
    • +3
      Есть замечательное свойство adsent, которое показано в примере. Т.е. получается так, что если юзер принудительно не заведен для конкретного хоста, то он «absent», тоесть происходит его удаление. В итоге получилось так, что ничего дополнительного для этого применять и не нужно. В начале нашего пути мы тоже думали над решением обозначенной вами задачи.
      • 0
        Спасибо! Красивый выход.
  • +1
    А красивые окошки чем рисуются?

    PS: пробовал только тру-консольную версию :-)
    • 0
      это просто «надстройка», которая была нарисована моим коллегой в отделе. PHP+JS.
    • +3
      • 0
        да, это именно то, как мне подсказали.
  • 0
    Еще несколько вопросов:
    • Насколько быстро у вас разъезжаются по всем серверам? (Их ведь тысячи, как вы пишете?). Можно перефразировать — как часто клиенты приходят к puppet-серверу?
    • Они все ходят к одному puppet-серверу?
    • Если да, то как он выдерживает такую нагрузку?
    • Если нет, то как вы разделяете puppet-серверы?
    • +2
      1. время обновления учеток — не более 2х минут. Реализовано дополнительным environment в puppet(только часть, которая касается учеток. Время обработки менее 2х секунд)
      2. все зависит от того, для чего они ходят
      3. говорить о том, что сервер один — не совсем корректно
      4. puppetmaster запускается в режиме нескольких истансов, с помощью unicorn. Делая так получается схема, аналогичная nginx+backend, тоесть часть backend'ов мы можем выносить на сколь угодно большое количество серверов, которые в свою очередь и обслуживаю клиентов, не создавая нагрузки на основной ноде.
    • +1
      и да, их действительно «тысячи» — это не игра слов =)
  • 0
    Кстати, при работе с Opscode Chef достаточно завести соответствующий набор данных (Data Bag), и затем использовать его в рецепте.

    Хотя, конечно, можно проинтегрироваться и с LDAP.
    • 0
      Да, но только сложность для того, кто в конечном итоге этим будет пользоваться значительно выше. Здесь же мы получили интерфейс для anykey фактически, при том, что далее, чем за те рамки, что мы ему выдали — мы его не пустим.
      • 0
        Никто не мешает обернуть набор данных Chef мелким вэб-сайтом для его редактирования.
        • 0
          было бы очень интересно прочитать ваш опыт создания чего-то подобного, с применением Chef+«мелкий вэб-сайт»
          • 0
            Думаю, все вопросы способна разрешить ссылка на Chef Server API.
            • +1
              целью статьи не было сравнение, аля «Puppet vs Chef».
              В любом случае, думаю, что Ваш комментарий будет полезен тем, кто соберется сделать что-то подобное.
              Наличие выбора — это всегда большой "+".
              • 0
                Да, естественно. Я лишь рассказал, как это удобнее всего делать в Chef.

                С Puppet сравнивать не могу, не пользуюсь.
  • 0
    А как насчет Spacewalk, построенном на puppet+cobbler. В нем подобный функционал заложен.
    • 0
      Во-первых он всеголишь «подобный», а мы хотим сильно больше, а во-вторых нам redhat не очень близок
      • 0
        Какие системы вы тогда используете? Debian/Ubuntu? Или BSD-style?
        • +1
          SLES
  • –2
    offtopic
    о, узнал ваш логотип, видел когда рисеч делал.
    document.write(' ')
    CSRF бы пофиксили уже, боян ведь homakov.blogspot.com/2012/03/hacking-skrillformer-moneybookers.html
  • 0
    А как вы узнаете, кто из пользователей когда и куда заходил? С LDAP было бы удобнее, чем с локальными пользователями. Чем агрегируете логи по авторизации?
    • 0
      Splunk для сбора, агрегации логов и построения индексов, на основе которых мы можем видеть все, что нам нужно. Также мы ведем записи того, какой пользователь что именно делает/делал на хосте.
      • 0
        LDAP хорош все же при меньшей на него нагрузке, это тоже провереный факт. Если LDAP в организации используется для чего-то еще, то никто не мешает нам брать данные для генерации манифестов оттуда, а не из MySQL.
  • +1
    появилась мысль — все это дело в модуль, в перспективе выложить на github. Есть ли в этом смысл?
    • 0
      Если с готовыми кнопочками(UI) и примерным описанием, как настраивать — смысл есть.

      Три раза читал статью, прежде чем понял, что у вас не универсальные рецепты написаны, а сделан генератор рецептов. На стандартном синтаксисе приходится какие-то огромные костыли городить, даже чтобы ключики ssh прописывать(много ключей+много пользователей=километр руками написанного конфига)

      Чалма не работает без сковородки(с)Ералаш
      • +1
        речь именно о том, чтобы выложить готовое решение, с описанием того, как оно работает.
        • 0
          Есть ли этот модуль уже на gihub'e? :)
          • 0
            на данный момент нет, потомучто:

            1. оно не совсем как модуль оформленно. А именно:
            — есть скрипт, который на основании данных из БД «пишет манифест»
            — есть бд, описание структуры которой пока только внутри компании
            — есть «веб-морда», которая жестко привязана к той структуре бд, которая есть
            2. нет времени/желания/не знаю чего еще, чтобы сесть и описать, структурировать и наконец-таки выложить
            Но, есть и положительный момент в том, что рано или поздно мы это сделаем. Если у вас есть потребность использовать подобное решение — велком в приват, возможно, что смогу чем-то помочь.
    • 0
      хорошая идея
      • 0
        а в каком плане модуль?
        • +1
          В плане обычного модуля для puppet, со своими объявлениями, например того-же добавления ключа. Это то, что касается той части, которая необходима для работы.
          По поводу UI — нужно подумать, но по-хорошему в этом тоже не должно быть никаких трудностей.
          Единственный минус во всем этом — это то, что представлено оно будет скорее всего в том виде, в котором оно удобно нам. Но с другой стороны — это будет совсем наглядным примером, а внести изменения под конкретную инфраструктуру — дело не сложное.
  • 0
    краткий смысл статьи — badoo ну умеет готовить openldap.
    • 0
      Курс литературы изучали тоже в «кратком изложении»?

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Самое читаемое Разное