Случайные числа в Linux(RNG) или как «наполнить» /dev/random и /dev/urandom

Пожалуй всем пользователям Linux  известны такие файлы псевдо-устройств как /dev/random и /dev/urandom. Эти устройства являются интерфейсом к генератору случайных чисел ядра(RNG, random number generator).

Случайные числа(они же — не предсказуемый набор битов) очень важны в криптографии. Они являются базовыми кирпичиками для криптографических протоколов. От качества (неповторимости, не предсказуемости) этих чисел зависит стойкость всевозможных TLS-сертификатов, SSH и GPG ключей, сессионных симметричных TLS-ключей и т.д. Так же случайные числа являются основой для генерации UUID’ов, PID’ов, TCP sequence numbers и многого другого.

RNG генерит случайные числа  на основе данных из пула энтропии(entropy pool) в ядре Linux. Наполнением этого пула так же занимается RNG и делается это на основе случайных событий в системе таких как: тайминги клавиатуры и дисков, движения мыши, прерывания(interrupts), сетевой трафик.

Читать дальше

GELF, rsyslog and custom properties

Для централизованного сбора и обработки логов в нашей команде используется Graylog(v2.2.3).
Отправкой логов занимается rsyslog(7.4.7-12.el7).
Все сообщения со всех серверов отправляются в Graylog следующим правилом:

*.* @;RSYSLOG_SyslogProtocol23Format

Все прекрасно, но вкусив прелести фильтрации логов с помощью stream’ов graylog нам стало не достаточно стандартных полей rsyslog.

Читать дальше

Puppet. classes vs Defined resource types

Как то на днях мой коллега озадачил меня вопросом о разнице между классами puppet и defined resources(или defined types). Я задумался, но дать нормального ответа не смог. На первый взгляд эти сущности очень похожи. И class и defined type описывают внутри себя некую логику и набор ресурсов. И class и defined type могут быть параметризованы. Но, есть существенное различие в том как они вызываются.

Читать дальше

Управление группами серверов с помощью pdsh. pdsh-mod-genders

Если у вас есть группа серверов в которой есть деление по ролям(серверы выполняют различные функции) или например вы используете разные дистрибутивы под разные задачи то эта заметка будет вам очень полезна).
В проекте в котором я работаю, для массового управления группами серверов есть средства собственной разработки. Это очень удобно, когда у тебя например 100 серверов и тебе нужно выполнить какое то действие  на конкретных группах или на всех и ты можешь оперировать именами групп а не длинным списком из имен серверов.
Типичный кейс — запуск puppet-агента на всех серверах. Или например проверка версии некого пакета на всех серверах с CentOS 7.3.

Другая проблема которую решает данное средство — инвентаризация. Хочется иметь некий файл с описанием серверов их ролей и прочих атрибутов позволяющих понять предназначение серверов и управлять ими «массово».
Недавно я попал в среду, где было очень много серверов и совершенно отсутствовали средства их инвентаризации и тем более управления.

Когда нужно было сделать что то на паре серверов люди делали примерно так:

pdsh -w sd01,sd05,sd06 rpm -qa kernel

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

Читать дальше

Воскрешение заскучавшего бложека

Больше года прошло с момента как я сменил работу. С тех пор не строчки в бложек…:( И хотя есть куча интересного материала, времени на его публикацию попросту нет.
Писать статейки для samag я уже точно не буду. Это требует огромных временных затрат, да и уровень журнальных публикаций я уже перерос. По этому, будущие посты будут скорее всего краткими, без вылизанных фраз и кучи воды 😉 Тем самым, я надеюсь, смогу регулярно о чем то писать не тратя на это много времени.

Читать дальше

Власть над конфигурацией. Etckeeper и Git

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

Как это работает

В основе всего лежит система контроля версий — Concurrent Versions System (CVS). Так как /etc традиционно используется для хранения конфигурационных файлов, преимущественно текстовых, CVS здесь подходит как нельзя лучше. Но даже учитывая простоту использования современных систем версионного контроля они имеют тот же недостаток, что и резервное копирование конфигов в ручную. Администраторы попросту забывают или ленятся ими пользоваться будучи уверенными, что все пройдет гладко. По этому, я рекомендую поставить себе на вооружение маленькую но полезнейшую утилиту etckeeper которая будет это делать за вас.

Суть утилиты заключается в том, что бы автоматически делать резервное копирование состояния /etc до и после установки любых приложений а так же раз в сутки на всякий случай. В качестве хранилища, могут использоваться на выбор одна из нескольких CVS. Наиболее популярные из них это Bazaar и Git. В Ubuntu обычно по умолчанию используется первая а RHEL-подобных дистрибутивах в основном Git, хотя, это не принципиально.

Читать дальше

ZEN Load balancer — теория и практика балансировки нагрузки

load balancer

Не большой цикл статей посвященный отказоустойчивости сервисов за счет балансировки нагрузки. В работе рассмотрены теоретические основы, используемые техники, их преимущества и недостатки а так же практическая часть на примере балансировщика  с открытым исходным кодом — Zen LB.

Читать дальше

ZEN Load balancer часть №3. Практика

Zen Load Balancer. Все статьи >>

Развертывание

Образ дистрибутива может быть развернут как на физический сервер, так и в качестве виртуальной машины без каких-либо сложностей. Требование дистрибутива к оборудованию, самые демократичные. Подойдет любой Debian-совместимый компьютер или платформа виртуализации. Для работы Zen LB достаточно одного сетевого интерфейса. В идеале, не плохо что бы их было два, один для управления, а второй для приема клиентских подключений.
Установка Zen LB не чем не отличается от таковой процедуры у любого другого дистрибутива Linux. На первом шаге мастер предложит выбрать язык для процесса установки. В списке присутствует русский, что значительно упростит это мероприятие для неопытных специалистов. Единственное чем выделятся дистрибутив, так это тем, что после выбора языка и страны он автоматически подставляет доступные для этой местности часовые пояса. Это, пожалуй логично, но очень не удобно для тех кто говорит по-русски, но проживает не в России. Поэтому, на последнем шаге установщика, необходимо перейти в пункт «Другие» и из полного списка выбрать нужный часовой пояс.
После установки, управление всеми параметрами балансировщика, осуществляется с помощью веб-интерфейса. Который стоит отметить выполнен качественно, приятен глазу и работает быстро и безотказно.

Читать дальше

ZEN Load balancer часть №2. Немного про Zen LB

Zen Load Balancer. Все статьи >>

Почему ZEN

Прежде чем мой выбор остановился на ZEN Load balancer, я опробовал еще несколько кандидатов среди которых был классический HAProxy и не менее известный Linux Virtual Server. Все трое являются проектами с открытым исходным кодом. Касательно функционала они практически равны, по этому я не обращал на это особое внимание. Основными требованиями было легкость настройки и удобство управления. Во время установки и в процессе настройки дистрибутива Zen LB, присутствует чувство целостности, в нем все работает слаженно и предсказуемо. Именно благодаря этому пункту, практически не колеблясь выбор был сделан в пользу него.

Читать дальше

ZEN Load balancer часть №1. Теория и практика балансировки нагрузки

Zen Load Balancer. Все статьи >>

Когда нужна балансировка

Что есть балансировка нагрузки? Фактически, это распределение входящих сетевых подключений между несколькими вычислительными узлами. При этом, использование для этих целей аппаратных или программных решений, а так же применяемый алгоритм распределения сути, совершенно не меняет. Но, благодаря распределению нагрузки можно решить две достаточно серьезные проблемы.
Во-первых, это распределение нагрузки между вычислительными узлами в ситуации, когда ресурсов одного сервера не достаточно и вертикальное наращивание его мощности уже не возможно. В таком случае, необходимо добавление еще одной вычислительной единицы и применение одного из видов балансировки.
Во-вторых — обеспечение доступности. Как известно, отказоустойчивость любой системы, будь то аппаратное решение или программное достигается путем дублирования основных компонентов. К сожалению, не существует абсолютно надежных жестких дисков, RAID-контроллеров и прочего оборудования, а современный уровень программирования не гарантирует отсутствие сбоев в ПО. По этой причине, при построении отказоустойчивых сервисов, дублируется все, сетевые контроллеры, коммутаторы и в конце концов сами вычислительные узлы. Например, нагрузка создаваемая на один сервер может быть не большой, но при этом хочется, что бы выход одного или нескольких узлов не привел к простою сервиса. В этом случае решением снова может стать балансировщик нагрузки.

Читать дальше