На некотором этапе развития нашей организации было решено перейти на VoIP телефонию. В качестве платформы безоговорочно был выбран Asterisk-PBX. Оконечное оборудование брали бюджетное из доступного — DLink DPH-150.
В результате проделанной работы получилась автоматизированная VoIP система, с управлением через стандартную оснастку MS ActiveDirectory.

Дружим между собой Active Directory, сервер IP телефонии Asterisk и Jabber-сервер OpenFire.

Не буду касаться установки всего по отдельности – все неплохо описано и работает в индивидуальном порядке весьма замечательно. Напишу, как я объединял все это вместе, на что наткнулся и что у меня получилось.

Недавно я переосмыслил процедуру установки нового сервера Puppet с нуля на Ubuntu 12.04, включая все современные свистелки и перделки. В итоге у меня получился этот гайд.

Для начала нам потребуется чистая Ubuntu c работающей сетью и настроенным DNS.

В итоге мы должны получить:

• Установленый везде Puppet 3-й версии
• Конфиги в git репозитории с общим доступом
• Динамические окружения, управляемые r10k
• Поддержку PuppetDB
• Поддержку Hiera

Данное руководство довольно длинное, т.к. все настройки делаются вручную, чтобы впоследствии легко можно было пользоваться результатом и подстраивать его под себя. Единственным исключением является PuppetDB, который проще установливать через собственный модуль от Puppet Labs, а не вручную.

Предполагается, что все команды будут выполнены от пользователя root на сервере Puppet, если не указано иное.

Сегодня мы анонсируем доступность релиза операционной системы CentOS 7 в облаке InfoboxCloud, основанного на пакетной базе Red Hat Enterprise Linux 7 и полностью совместимого с ним. В конце поста ссылка на бесплатное тестирование в облаке.

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

Мы начинаем обзор новой ОС, состоящий из серии теоретических и практических статей. В первой главе обзора будет рассказано о поддержке контейнеров Linux в CentOS 7.



В облаке по умолчанию устанавливается минимальная версия CentOS 7 для обеспечения максимальной безопасности через снижение поверхности атаки. Все необходимые компоненты ОС устанавливаются из стандартных репозиториев.

Ключевые изменения CentOS 7

• Поддержка контейнеров Linux (включая поддержку Docker). Контейнеры расширяют возможности по разработке, доставке и изоляции софта для тестовых и производственных задач. Так же контейнеризация увеличивает безопасность ПО, снижая поверхность атаки;
• Интеграция Active Directory / Identity Management (IdM)
• Использование systemd, стандарта управления процессами, сервисами, безопасностью и другими ресурсами;
• Встроенные профили и инструменты для оптимизации производительности и простого масштабирования;
• Унифицированные инструменты управления и фреймворк управления OpenLMI, являющийся фактически стандартом индустрии для администрирования и настройки системы;
• Техническая предварительная версия технологии установки обновлений ядра без перезагрузки kpatch;

Высокая распространенность баз данных MySQL приводит к её использованию в разнообразных проектах, в том числе, которые требуют безостановочной работы и минимального времени восстановления. Стандартные инструменты, такие как mysqldump неудобен для использования баз данных размер, которых измеряется десятками гигабайт. К сожалению mysqldump вызывает блокировку таблиц, и операция снятия дампа или восстановления базы может занимать далеко не один час, а порой и 5-10 часов.

Благо, к нам на помощь приходит Percona XtraBackup.

В одной из дискуссий недавно, я перечислил основные системы, делающие работу ИТ-компании цивилизованной. Список получился весьма обширный, и я решил оформить его как самостоятельную статью.

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

Всё ниженаписанное касается компаний/отделов, в которых работает работает квалифицированный персонал, то есть курсы «офис для начинающих» им не нужны. Так же как не нужны групповые политики на рабочих станций и специальный админ для перекладывания ярлычков на рабочем столе и установки любимой программы. Другими словами, это бэк-офис айтишников, значительно отличающийся от бэк-офиса остальных отделов.

Краткий спойлер содержимого: VCS, репозиторий исходного кода, code-review, build-сервера, CI, таск-трекер, вики, корпоративный блог, функциональное тестирование, репозиторий для пакетов, система управления конфигурацией, бэкапы, почта/jabber.

Картинка с фрагментом обсуждаемой инфраструктуры:

Часто попадали в ситуацию когда на мобильном обнаруживаешь пропущенный звонок с городского и при попытке перезвонить попадаешь на голосовое меню какой-нибудь фирмы и совершенно непонятно кто тебе звонил? Я часто, а также и клиенты нашей компании каждый день сталкиваются с этим… С этим решено было что-то делать. Все последующие действия актуальны для trixbox v2.8.0.4 (с некоторыми корректировками или, возможно, даже без них можно реализовать и на других системах)

Не большая предыстория

На работе периодически приходится перехватывать вызовы, что в принципе не беда. Но бывает, что необходимо потом перезвонить тому, кто звонил.
Номер соответственно у меня не высветился и обычно приходится лезть в cdr'ки в mysql или подойти к телефону напарника и искать номер телефона.
Можно в принципе попросить напарника включать переадресацию на телефонном аппарате, но уходит он на пару минут, да и мы не ищем легких путей.

Итак, что мы имеем: офисная АТС на Asterisk (версия = 1.8.15.1), реализована функция перехвата вызова и уведомлений о звонке через jabber.

Информации по поводу настройки перехвата вызова, отправки уведомлений c помощью jabber достаточно в просторах интернета, так что сразу опишу о реализации получения уведомления при перехвате вызова.

Нет смысла говорить о том, насколько это актуальный вопрос. Сегодня мы расскажем, как у нас организовано резервное копирование баз данных mysql.
И одно их самых важных – это проверка, а сделался ли бекап? А успешно ли прошел дамп? А были ли ошибки? А знаю ли я о них?

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

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

В этой статье я расскажу вам о сервере службы каталогов 389 Directory Server (он же Fedora Directory Server, он же Redhat Directory Server). Так уж повелось, что для доступа к серверу каталогов используется протокол LDAP. Если вы не работали с LDAP, я очень рекомендую ознакомиться со статьями в Wikipedia (тут про cлужбу каталогов, а тут про протокол LDAP).

Итак, сначала кратко о том, зачем же вообще использовать сервер службы каталогов (далее — LDAP-сервер). LDAP-сервера, в основном, применяются для централизованного хранения учетных записей, и всего, что с ними связано. LDAP-сервер представляет собой иерархическую БД, а значит в нем можно хранить любые данные.

Казалось бы, вполне логичен вопрос: а почему именно LDAP? Что мешает хранить учетные записи в MySQL или PostgreSQL? Ответ очевиден — ничего =)

Но над любой RDBMS служба каталогов обладает целым рядом преимуществ:

• Это стандарт. Многие приложения поддерживают аутентификацию/авторизацию через LDAP;
• Данные хранятся как иерархическое дерево, что позволяет делать эффективные операции поиска, выделив нужную часть дерева;
• Число операций чтения в тысячи раз превышают число операций записи, в связи с этим появляется огромное число плюсов: нет необходимости применения транзакций и rollback'ов, репликация работает без проблем, которые присущи RDBMS;
• Приложение должно видеть одну и ту же информацию на всех серверах службы каталогов, если сервер не хранит информацию, нужную клиентскому приложению, он может сам запросить ее у другого сервера или перенаправить само приложение к другому серверу;
• Из-за описанных выше свойств службы каталогов, этот сервис отлично масштабируется горизонтально.

Выбор сервера службы каталогов пал на 389 Directory Server. История этого LDAP сервера тесно связана с компанией Netscape (если интересно, почитать историю можно тут).

Сейчас наличие нескольких подключений к интернет на одном, в том числе и домашнем сервере — не редкость. Городские локалки, ADSL, 3G модемы… Добавим к этому сети домашние локальные и внешние виртуальные (VPN), и получим ядрёную смесь интерфейсов, между которыми необходимо роутить трафик, балансировать трафик между разными каналами в интернет (когда они есть), и переключаться с нерабочих каналов на рабочие (когда они отваливаются).

Судя по постам в инете, большинство людей, столкнувшихся с этой ситуацией, очень плохо представляет себе, как это настраивается. Надо отметить, что в линухе действительно управление роутингом весьма сложное и запутанное — следствие эволюционного развития и поддержки (частичной) совместимости. Я хочу описать принципы настройки роутинга multihomed серверов на конкретном, достаточно сложном, примере: на сервере три физических сетевых интерфейса (один в домашнюю локалку и два к ADSL-модемам), два ADSL-подключения (ADSL-модемы в режиме bridge, так что pppd поднимает этот же сервер) к разным провайдерам (одно со статическим IP, второе с динамическим), плюс VPN на сервер компании — итого шесть интерфейсов.

Тема достаточно сложная, поэтому для понимания материала потребуется хотя бы минимальное понимание работы роутинга (что такое default route и gateway), файрвола (маркировка пакетов, отслеживание соединений, связь между разными таблицами и цепочками файрвола и роутингом), pppd (скрипты ip-up/ip-down) и протоколов IP и TCP.

С репликацией серверов MySQL я познакомился относительно недавно, и по мере проведения разных опытов с настройкой, записывал, что у меня получалось. Когда материала набралось достаточно много, появилась идея написать эту статью. Я постарался собрать советы и решения по некоторым самым основным вопросам, с которыми я столкнулся. По ходу дела я буду давать ссылки на документацию и другие источники. Не могу претендовать на полноту описания, но надеюсь, что статья будет полезной.

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

Данная статья посвящена настройкe кластера PostgreSQL. С Jelastic Вы можете легко создать кластер с одним или несколькими резервными серверами, готовыми взять на себя основные операции, если основной сервер выйдет из строя. В этом случае основной сервер работает в режиме архивирования, в то время как резервный работает в режиме восстановления, считывая данные с журнала транзакций WAL (Write-Ahead Logging) основного сервера.



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

В сегодняшней статье мы рассмотрим процесс создания репликации базы PostgreSQL на один или несколько резервных серверов. Резервная база данных будет использована только в режиме чтения. Это самый быстрый способ репликации доступный для WAL данных, отправляемых с основного сервера на резервный.

Мы продолжаем серию статей про взаимодействие Linux и Windows.
Теперь мы рассмотрим задачу введения в домен Windows 2008R2 сервера с операционной системой CentOS Linux (версия 6.3). Как и в последних статьях, будем пользоваться штатными средствами, поставляемыми в составе дистрибутива операционной системы. Но, в отличие от наших предыдущих статей, мы расширим задачу. Требуется организовать не только файловое хранилище на сервере под управлением CentOS Linux, но и обеспечить доступ доменных пользователей к командной и графической оболочке.