Comments 61
у меня хром виснет на badoo на некоторых запросах, это известная проблема?
Приведённых технических данных недостаточно для того, чтобы вам ответить однозначно.
Вы можете обратиться в службу поддержки по адресу badoo.com/feedback/
Комментарии к статье про администрирование серверов — неудачное место для обсуждения таких вопросов. Страница habrahabr.ru/company/badoo/questions/ подходит куда сильнее.
Вы можете обратиться в службу поддержки по адресу badoo.com/feedback/
Комментарии к статье про администрирование серверов — неудачное место для обсуждения таких вопросов. Страница habrahabr.ru/company/badoo/questions/ подходит куда сильнее.
ну это какая-то техническая особенность работы хрома с вашим сайтом, в фф вроде норм, может какая-то перегруженность js, может в хроме какие-то особенные сетевые действия для ускорения загрузки страниц, может только у меня такое, я так просто спросил, может проблема известная и вы с ней уже боритесь
UFO just landed and posted this here
да, я что-то находил за 2010 год
Мне кажется ldap все-таки лучшее решенее. Репликация, достаточно быстрое хранилище внутренее (можно sql-backend использовать). Ко всем сервисам прикручивается стандартно: SSH/HTTP auth/IMAP/SMTP/Radius
Да, но в статье речь идет в том числе и о том, что у нас было большое желание уйти от поддержки доп. сервисов и служб, которые в том числе требуют дополнительной конфигурации и «клиентских» узлов. В данном случае «клиентский» узел == любой сервер.
К тому же, ssh не умеет брать ключи из ldap. Есть патч, который это позволяет, но хочется использовать версию из репозиториев.
Справедливости ради в RHEL6 патч с AuthorizedKeysCommand (что даёт возможность брать ключи хоть откуда) включён в пакет.
Однако, для тысяч серверов приведённое решение мне кажется более подходящим хотя бы потому, что вся аутентификация/авторизация происходит локально.
Однако, для тысяч серверов приведённое решение мне кажется более подходящим хотя бы потому, что вся аутентификация/авторизация происходит локально.
Мы у себя внедрили решение на базе AuthorizedKeysCommand + NIS
Решение легко внедряется на RHEL/CentOS 5/6
Решение легко внедряется на RHEL/CentOS 5/6
а как с sudoers поступили?
UFO just landed and posted this here
радостная она только в том случае, если оно уже есть и используется. А вот если принимается решение о том, что вот «пора» и «нужно/модно», то перспектива начинает казаться уже чем-то не очень понятным, отчего уже не такой радостной.
На самом деле, плюсов в том, чтобы так поддерживать sudoers(в том числе), больше, нежели минусов от внедрения.
На самом деле, плюсов в том, чтобы так поддерживать sudoers(в том числе), больше, нежели минусов от внедрения.
UFO just landed and posted this here
Не будет у нас puppet, пока не обоснуешь мне смысл его внедрения. Т.е. не «это круто», а расписать, что нам это позволит получить либо сэкономить.
Прочитав Ваш коммент на почту почти испугался, подумав о том, что я кому-то что-то обосновать должен.
Если не секрет — как много серверов вам приходится поддерживать?
Можем в режиме «задача-решение» обосновать вам возможность такого внедрения.
Если не секрет — как много серверов вам приходится поддерживать?
Можем в режиме «задача-решение» обосновать вам возможность такого внедрения.
Для ясности: freefd — мой коллега. Коммент был направлен ему :)
Для простоты можно взять число в 500 серверов.
Для простоты можно взять число в 500 серверов.
Ну а в рамках «задача» приведете пример чего-либо, что вам приходится делать? неужели нет задачи, по генерации или контроля конфига какого-либо сервиса, того, чтобы он был, например един для некого «кластера», который обрабатывает конкретную задачу?
Мне просто довольно сложно представить ситуацию управления 500 серверами без централизации. Или для примера можно взять ситуацию, когда внезапно у нас случилось так, что в кластере, который отдает статику на машинах нагрузка ~30%, в то время как на тех машинах, что обрабатывают динамику в пиках нагрузка вырастает до ~80-90%. Очевидно, что мы можем выдернуть N машин с первого кластера во второй, но в случае ручной конфигурации нам потребуется сильно больше времени, нежели просто назначить нужные классы с конфигами для этих машин…
Тоесть решение задачи, при наличии puppet(ну или того инструмента, что по душе — тут предлагали много иного) сводится к тому, что мы просто назначаем нужные классы нашим серверам и получаем прибавку тому кластеру, которому уж очень тяжело.
В случае же, если общая конфигурация системы такая, что изменения в нее вносятся крайне редко, а также дополнительные поставки железа редки, то вполне возможно, что тогда та централизация, которую дает puppet — не сильно нужна.
Еще как пример — нужно обновить firmware на железе, по причине выхода критичного багфикса от вендора, но обновить не совсем везде, а только на специфичной платформе, ну например HP Proliant G7 P67. При наличии паппета это решится в 5 строк, с гарантией того, что все у вас обновится.
Не знаю, что привести еще в пример, думаю, что легче будет рассуждать только если вы немного обрисуете хотябы абстрактно то, чем приходится заниматься в повседневной работе.
Мне просто довольно сложно представить ситуацию управления 500 серверами без централизации. Или для примера можно взять ситуацию, когда внезапно у нас случилось так, что в кластере, который отдает статику на машинах нагрузка ~30%, в то время как на тех машинах, что обрабатывают динамику в пиках нагрузка вырастает до ~80-90%. Очевидно, что мы можем выдернуть N машин с первого кластера во второй, но в случае ручной конфигурации нам потребуется сильно больше времени, нежели просто назначить нужные классы с конфигами для этих машин…
Тоесть решение задачи, при наличии puppet(ну или того инструмента, что по душе — тут предлагали много иного) сводится к тому, что мы просто назначаем нужные классы нашим серверам и получаем прибавку тому кластеру, которому уж очень тяжело.
В случае же, если общая конфигурация системы такая, что изменения в нее вносятся крайне редко, а также дополнительные поставки железа редки, то вполне возможно, что тогда та централизация, которую дает puppet — не сильно нужна.
Еще как пример — нужно обновить firmware на железе, по причине выхода критичного багфикса от вендора, но обновить не совсем везде, а только на специфичной платформе, ну например HP Proliant G7 P67. При наличии паппета это решится в 5 строк, с гарантией того, что все у вас обновится.
Не знаю, что привести еще в пример, думаю, что легче будет рассуждать только если вы немного обрисуете хотябы абстрактно то, чем приходится заниматься в повседневной работе.
Сержик false detected? :)
еще из дополнительных «плюшек» — история внесения изменений, возможность их отката, уменьшение «точек входа» для внесения изменений.
ТАК!
UFO just landed and posted this here
Скажите, а как вы с помощью puppet удаляете пользователей? Решали аналогичную задачу, от puppet отказались в пользу ldap, так как puppet вроде бы умеет только добавлять юзеров.
Есть замечательное свойство adsent, которое показано в примере. Т.е. получается так, что если юзер принудительно не заведен для конкретного хоста, то он «absent», тоесть происходит его удаление. В итоге получилось так, что ничего дополнительного для этого применять и не нужно. В начале нашего пути мы тоже думали над решением обозначенной вами задачи.
А красивые окошки чем рисуются?
PS: пробовал только тру-консольную версию :-)
PS: пробовал только тру-консольную версию :-)
Еще несколько вопросов:
- Насколько быстро у вас разъезжаются по всем серверам? (Их ведь тысячи, как вы пишете?). Можно перефразировать — как часто клиенты приходят к puppet-серверу?
- Они все ходят к одному puppet-серверу?
- Если да, то как он выдерживает такую нагрузку?
- Если нет, то как вы разделяете puppet-серверы?
1. время обновления учеток — не более 2х минут. Реализовано дополнительным environment в puppet(только часть, которая касается учеток. Время обработки менее 2х секунд)
2. все зависит от того, для чего они ходят
3. говорить о том, что сервер один — не совсем корректно
4. puppetmaster запускается в режиме нескольких истансов, с помощью unicorn. Делая так получается схема, аналогичная nginx+backend, тоесть часть backend'ов мы можем выносить на сколь угодно большое количество серверов, которые в свою очередь и обслуживаю клиентов, не создавая нагрузки на основной ноде.
2. все зависит от того, для чего они ходят
3. говорить о том, что сервер один — не совсем корректно
4. puppetmaster запускается в режиме нескольких истансов, с помощью unicorn. Делая так получается схема, аналогичная nginx+backend, тоесть часть backend'ов мы можем выносить на сколь угодно большое количество серверов, которые в свою очередь и обслуживаю клиентов, не создавая нагрузки на основной ноде.
и да, их действительно «тысячи» — это не игра слов =)
Кстати, при работе с Opscode Chef достаточно завести соответствующий набор данных (Data Bag), и затем использовать его в рецепте.
Хотя, конечно, можно проинтегрироваться и с LDAP.
Хотя, конечно, можно проинтегрироваться и с LDAP.
Да, но только сложность для того, кто в конечном итоге этим будет пользоваться значительно выше. Здесь же мы получили интерфейс для anykey фактически, при том, что далее, чем за те рамки, что мы ему выдали — мы его не пустим.
Никто не мешает обернуть набор данных Chef мелким вэб-сайтом для его редактирования.
было бы очень интересно прочитать ваш опыт создания чего-то подобного, с применением Chef+«мелкий вэб-сайт»
Думаю, все вопросы способна разрешить ссылка на Chef Server API.
А как насчет Spacewalk, построенном на puppet+cobbler. В нем подобный функционал заложен.
offtopic
о, узнал ваш логотип, видел когда рисеч делал.
document.write(' ')
CSRF бы пофиксили уже, боян ведь homakov.blogspot.com/2012/03/hacking-skrillformer-moneybookers.html
о, узнал ваш логотип, видел когда рисеч делал.
document.write(' ')
CSRF бы пофиксили уже, боян ведь homakov.blogspot.com/2012/03/hacking-skrillformer-moneybookers.html
А как вы узнаете, кто из пользователей когда и куда заходил? С LDAP было бы удобнее, чем с локальными пользователями. Чем агрегируете логи по авторизации?
Splunk для сбора, агрегации логов и построения индексов, на основе которых мы можем видеть все, что нам нужно. Также мы ведем записи того, какой пользователь что именно делает/делал на хосте.
появилась мысль — все это дело в модуль, в перспективе выложить на github. Есть ли в этом смысл?
Если с готовыми кнопочками(UI) и примерным описанием, как настраивать — смысл есть.
Три раза читал статью, прежде чем понял, что у вас не универсальные рецепты написаны, а сделан генератор рецептов. На стандартном синтаксисе приходится какие-то огромные костыли городить, даже чтобы ключики ssh прописывать(много ключей+много пользователей=километр руками написанного конфига)
Чалма не работает без сковородки(с)Ералаш
Три раза читал статью, прежде чем понял, что у вас не универсальные рецепты написаны, а сделан генератор рецептов. На стандартном синтаксисе приходится какие-то огромные костыли городить, даже чтобы ключики ssh прописывать(много ключей+много пользователей=километр руками написанного конфига)
Чалма не работает без сковородки(с)Ералаш
речь именно о том, чтобы выложить готовое решение, с описанием того, как оно работает.
Есть ли этот модуль уже на gihub'e? :)
на данный момент нет, потомучто:
1. оно не совсем как модуль оформленно. А именно:
— есть скрипт, который на основании данных из БД «пишет манифест»
— есть бд, описание структуры которой пока только внутри компании
— есть «веб-морда», которая жестко привязана к той структуре бд, которая есть
2. нет времени/желания/не знаю чего еще, чтобы сесть и описать, структурировать и наконец-таки выложить
Но, есть и положительный момент в том, что рано или поздно мы это сделаем. Если у вас есть потребность использовать подобное решение — велком в приват, возможно, что смогу чем-то помочь.
1. оно не совсем как модуль оформленно. А именно:
— есть скрипт, который на основании данных из БД «пишет манифест»
— есть бд, описание структуры которой пока только внутри компании
— есть «веб-морда», которая жестко привязана к той структуре бд, которая есть
2. нет времени/желания/не знаю чего еще, чтобы сесть и описать, структурировать и наконец-таки выложить
Но, есть и положительный момент в том, что рано или поздно мы это сделаем. Если у вас есть потребность использовать подобное решение — велком в приват, возможно, что смогу чем-то помочь.
хорошая идея
а в каком плане модуль?
В плане обычного модуля для puppet, со своими объявлениями, например того-же добавления ключа. Это то, что касается той части, которая необходима для работы.
По поводу UI — нужно подумать, но по-хорошему в этом тоже не должно быть никаких трудностей.
Единственный минус во всем этом — это то, что представлено оно будет скорее всего в том виде, в котором оно удобно нам. Но с другой стороны — это будет совсем наглядным примером, а внести изменения под конкретную инфраструктуру — дело не сложное.
По поводу UI — нужно подумать, но по-хорошему в этом тоже не должно быть никаких трудностей.
Единственный минус во всем этом — это то, что представлено оно будет скорее всего в том виде, в котором оно удобно нам. Но с другой стороны — это будет совсем наглядным примером, а внести изменения под конкретную инфраструктуру — дело не сложное.
краткий смысл статьи — badoo ну умеет готовить openldap.
FreeIPA и пофиг, что сервис дополнительный.
Sign up to leave a comment.
Система управления авторизацией пользователей на тысячах серверов