Сейчас уже сложно сказать, когда именно я начал работу над вестой. Если считать первые скрипты добавления виртуальных хостов в апач, то это был 2007 год. Получается 5 лет тому назад. Помню тогда на работе состоялся примерно такой диалог:
— Ты решил написать свою панель управления?
— Ага, ведь cPanel это ужас, Plesk хоть и лучше, но сильно дорогой. Да и вообще у меня уже почти все готово
— Хм… для того чтобы просто приблизиться к сPanel тебе потребуется минимум 2 года

Не помню, что тогда ответил, но фразу про то, что почти все готово, я повторял еще не раз. Сейчас еще я хочу рассказать что готово в версии 0.9.7

Статический маршрут — первое, с чем сталкивается любой человек при изучении понятия маршрутизации IP пакетов. Считается, что это — наиболее простая тема из всех, в ней всё просто и очевидно. Я же постараюсь показать, что даже настолько примитивная технология может содержать в себе множество нюансов.

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

В общем виде схема выглядит так:
клиент ----> балансировщик ---> бэкенд (сервис)


Готовых балансировщиков под конкретные нужды множество. Например, nginx — отличный балансировщик для веб-приложений, haproxy для tcp-соединений.

Бесконечны лишь Вселенная и глупость человеческая. Хотя насчет первой у меня имеются сомнения. (с) Альберт Эйнштейн

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

Как правило, люди ставят такие задачи с очень серьезным выражением лица. Это хорошо проилюстрировано в следующем гениальном видео, снятого по мотивам не менее гениального рассказа:



Что делать, если вы попали в такую ситуацию? Вариант «уволиться» рассматривать не будем, хотя часто это единственный простой и правильный вариант.

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

При мне менялись технологии и концепции. Тачскрины, голосовое управление, сенсоры движения, тачпэды, не говоря о всяких мышах — все это органично вписывалось в мой мир взаимодействия с приборами, и на этом пути не было ни особых потрясений, ни революций. Я спокойно и естественно считал себя типичным early adopter. Я был в сетях Fido и Compuserve, писал электронные письма до Эпохи интернета, общался в чатах и конференциях годы до появления ICQ, хранил файлы в «облаке» чуть ли не до рождения некоторых нынешних стартаперов в модной области Cloud. У меня даже несколько лет был собственный блог задолго до сегодняшнего блог-сумасшествия и десятков доступных платформ для блоггинга.

И так далее, и тому подобное.

Все это хвастливое вступление необходимо мне для следующего заявления: я не могу разобраться в Фейсбуке. Нет, я прекрасно понимаю что это такое, зачем существует, куда идет и как монетизируется. Я не разбираюсь в его интерфейсе! Я никогда не знаю что мне покажет Фейсбук в любой конкретный момент времени, не соображаю принцип формирования ленты, не понимаю какие фотографии выберутся для поста с альбомом и какие из них будут показаны на мобильном устройстве. Я не имею понятия «лайкаю» ли я пост, фотографию или альбом. Я чувствую себя тупицей в его настройках, особенно настройках приватности и уведомлений. Я не знаю кто прочтет мои посты, а главное, почему он их прочтет. Я не ведаю что происходит с постами, остающимися глубоко внизу. Я не чувствую логики продукта, несмотря на несколько безуспешных попыток и, в общем-то, достаточно живой аккаунт для фоток детей и кота. Меня не покидает ощущение, что фейсбук писали марсиане.

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

Недавно Евгений Касперский опубликовал в своем блоге запись «Призраки вирус-оперы, или Ситхи Ассемблера», посвященную сверхкомпактным и мощным вредоносным приложениям, обнаруженным недавно, но написанным в стиле 15-летней давности. Мой возраст позволяет помнить этих парней и их блестящую работу – речь ведь не обязательно о создателях вирусов, они были лишь частью программистского сообщества, специализировавшегося на «ручном» написании кода и программировании на ассемблере. Это похоже на Джедаев и Ситхов из мира «Звездных войн» – существ, чье оружие, лазерные мечи, было крайне специфическим и, несмотря на это, воспринималось всеми остальными героями как одно из самых мощных (кроме шуток, спросите Йоду). Увы, похоже, людей, которые помнят этих мастеров-программистов, осталось трое (я, Касперский и Билл Гейтс). А если серьезно – в сегодняшнем мире, где драйвер мышки занимает 50 мегабайт, довольно трудно вообразить, на что способен хакер старой школы при совсем небольшом количестве выделенных ресурсов. Поэтому я решил показать, о чем говорит Евгений, на несколько ином примере – а вы уж решайте, насколько плохи новости об «олдскульных» авторах заразы.

Без синхронизаций и т.д., в варианте «есть хостинг» или «файловая помойка» и надо быстро выкатить хранилище пакетов для дистрибутива Linux (так чтобы можно было подключиться к этому репозиторию и поставить оттуда всё необходимое). Иногда обновляться в ручном режиме — копированием по тому же адресу с перезаписью. Раз в полгода или год. Задача типовая и я её опишу в полуавтоматическом режиме.

Классический сценарий

Вы работаете над проектом, где транзакционные данные хранятся в базе данных. Затем вы развёртываете приложение в рабочей среде, и производительность великолепна! Запросы проходят шустро, и задержка при их вводе практически незаметна. Через несколько дней/недель/месяцев база данных становится всё больше и больше, и скорость запросов замедляется.

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

Администратор базы данных (DBA) посмотрит и проследит, чтобы база данных была оптимально настроена. Он предложит добавить определённые индексы, убрать логирование на отдельную партицию, подправить параметры движка базы данных и убедиться, что база данных здорова. Можно также добавить выделенных IOPS (Input/Output Operations Per second) на EBS диске, чтобы увеличить скорость дисковых партиций. Это даст вам выиграть время и даст возможность решить главную проблему.

Рано или поздно вы поймёте, что данные в вашей базе данных являются узким местом (botleneck).
В базах данных многих приложений важность информации уменьшается со временем. Если вы сможете придумать способ избавиться от этой информации, ваши запросы будут проходить быстрее, время создания бэкапов уменьшится, и вы сэкономите кучу места. Вы можете удалить эту информацию, однако тогда она пропадёт безвозвратно. Вы можете послать множество DELETE запросов, вызвав создание тонн логов, и использовать кучу ресурсов движка базы данных. Так как же мы избавимся от старой информации эффективно, но не потеряв её навсегда?
В примерах мы будем использовать PostgreSQL 9.2 на Engine Yard. Вам также нужен git для установки plsh.

С тех пор как число активных пользователей Instagram стало постоянно расти, Postgres оставался нашим надежным фундаментом и неизменным хранилищем данных для большинства данных, создаваемых пользователями. И хотя меньше года назад мы писали о том, как мы храним большое количество данных на Instagram при 90 лайках в секунду, сейчас мы обрабатываем более 10000 лайков в секунду – и наша основная технология хранения данных не изменилась.

За последние два с половиной года, мы поняли несколько вещей и подобрали пару инструментов для масштабирования Postgres и мы хотим ими поделиться – то, что мы хотели бы знать при запуске Instagram. Некоторые из них специфичны для Postgres, другие представлены также и в других базах данных. Чтобы знать, как мы горизонтально масштабируем Postgres, смотрите наш пост Sharding and IDs at Instagram

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

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

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

Покупка заводов в Сибири была стратегически правильным решением для компании “Лифт ми Ам”. После того, как лифты стали ездить не только вверх, но и вниз, дела компании пошли… нет полетели, вверх. Лифты начали разбирать, как горячие пирожки со стола. Название уже не соответствовало действительности и было принято решение о ребрендинге. (На самом деле их замучила судебная тяжба с Моби).
Итак, под крыло ЛинкМиАп планируется взять заводы в Новосибирске, Томске и Брно. Самое время подумать о том, как это хозяйство подключить к имеющейся сети.

Итак, сегодня рассматриваем
1) Возможные варианты подключения, их плюсы и минусы
2) Site-to-Site VPN на основе GRE и IPSec
3) Большая тема: динамическая многоточечная виртуальная сеть (DMVPN) в теории и на практике.

В традиционном видео лишь ёмкая выжимка из статьи, посвящённая работе и настройке DMVPN.

Недавно моя полуторогодовалая дочь участвовала в соревнованиях по бегу. Несколько малышей выходили на дорожки (примерно 4 метра длиной) и, по сигналу судьи, бежали вперёд наперегонки.

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

Некий Питер Коттл (Peter Cottle) сделал интерактивную обучалку по основам ветвления в Git. Есть несколько простых обучающих уровней, где нужно сделать пару коммитов, а затем merge или rebase, есть и сложные уровни, над которыми придется подумать. Можно также сохранять уровни и делиться ими с друзьями.

Хотя сам автор утверждает, что приложение еще сырое, я советую всем, кто интересуется гитом, взглянуть на эту прикольную штуку.

Плагинов для систем мониторинга существует огромное количество. Можно посмотреть и найти нужное в каталогах exchange.nagios и monitoringexchange. При поисках нужного плагина проверять лучше в обоих репозиториях — несмотря на кажущуюся идентичность, их содержимое различается.

Другое дело, что качество и функционал плагинов, даже сходных между собой, сильно разнятся — есть быстро слепленные на коленке хаки, работающие в строго определенных условиях и решающих узкую задачу. После написания автор плагина не стал выбрасывать его в /dev/null, а решил поведать о нём миру. Другие плагины представляют собой добротно сделанные продукты, работающие с целыми семействами устройств и предоставляющих обширную информацию о целевых системах.

Вот о последних и хотелось бы поговорить, тем более, что за время работы с nagios/icinga обнаружилось, что русскоязычной информации по плагинам для систем мониторинга крайне мало.

Данная статья посвящена мониторингу серверов HP Proliant, и автор искренне надеется, что она поможет в работе тем, кто имеет оборудование HP, и хотел бы более полно отслеживать его параметры.

Приветствую вас, Хабражители!

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

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



Помните 7 шагов?

Хочу поделиться с Вами одним из вариантов настройки и использования Postfix’a, когда в нашем распоряжении есть несколько IP с которых можно вести доставку писем.

Задача стояла приблизительно такая. Необходимо настроить на одном сервере с двумя интерфейсами, Postfix с разными очередями для разных внешних IP. Пример на картинке.



Прошу пожаловать под кат, кому эта тема интереса.

В этой статье мы рассматриваем один из вариантов реализации масштабируемой архитектуры большой почтовой системы.

6 декабря 2012 г. Google прекратил регистрацию новых аккаунтов для бесплатной версии Google Apps.

У клиентов нашей компании постоянно возникает потребность в электронной почте, обслуживающей их сайты.
Раньше мы настраивали им Google Apps, но после 6 декабря, изучив предлагаемые на рынке решения, решили, что настала пора строить собственную почтовую систему.

Как известно, аппетит приходит во время еды. Если уж решились строить что-то свое, то тогда стоит сразу закладывать возможности для роста.
Для проектируемой почтовой системы были сформулировали следующие требования:

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

Начали с выбора хранилища под письма...

На самом деле выбор был небольшой:

• dovecot/cyrus с хранением в файловой системе через maildir/mailbox;
• dbmail с хранением в базе данных.

После оценки количества сервисов, предоставляемых «из коробки», а также изучения нюансов использования, нами было решено остановиться на dbmail.
Вот краткий список вкусностей, которые предоставляет dbmail:

• доступ к ящикам через IMAP, POP3;
• sieve-скрипты для сортировки почты;
• прием почты через smtp и lmtp протоколы;
• администрирование через cli и SQL-запросы.

Приветствую.

Так уж сложилось, что по долгу работы мне приходится много времени уделять логам. Это и участие в выработке правил и политик сбора/хранения/использования логов, это и разбор разных инцидентов и обнаружение аномалий. За сутки наши программы, сервисы и серверы генерируют ОЧЕНЬ большое количество логов. И потребность копания в логах растёт постоянно.
Мне довелось поработать с коммерческими лог-менеджмент продуктами типа ArcSight, RSA Envision, Q1 Labs. У этих продуктов есть как плюсы, так и минусы. Но в статье речь пойдёт не о них.
Речь будет о Logstash.

Что же такое Logstash? Зачем он нужен? Что он умеет?

ViMbAdmin

ViMbAdmin проект (vim/-be/-admin/) предоставляет веб-интерфейс администрирования виртуальных
почтовых ящиков, позволяя почтовым администраторам легко управлять доменами, и псевдонимами.
ViMbAdmin является свободным программным обеспечением, вы можете распространять или изменять его в соответствии с условиями GNU General Public License версии 3.

ViMbAdmin был написан на PHP с использованием нашего собственного web application framework, который включает Zend Framework, ORM Doctrina и система шаблонов Smarty с JQuery и Bootstrap.

ViMbAdmin размещается на отдельной странице проекта GitHub, где можно найти документацию,
просмотреть исходный код. GitHub

UPDATE:

yum install dovecot-mysql

Приветствую.

Нет так давно передо мной встала задача пробежаться по старым логам apache. Надо было сделать выборку по нескольким IP адресам, отыскать некоторые аномалии и попытки SQL-injection'ов. Логов было не так много, порядка миллиона строк и можно было спокойно всё сделать стандартным набором grap-awk-uniq-wc итд.

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

Краткое описание основных компонентов системы.

Logstash — бесплатная open-source программа на java для сбора и нормализации логов. Может принимать логи либо с локальных файлов, либо через tcp/udp порты. На момент написания статьи, разных входных (input) фильтров насчитывается 26. Есть даже входной модуль, для сбора сообщений из twitter'а или irc.

Elasticsearch — бесплатный open-source поисковый сервер основанный на Apache Lucene. Быстрый, легко настраиваемый и очень масштабируемый.

Kibana — веб-интерфейс написанный на ruby, для отображения данных из Elasticsearch. Простая настройка, но множество функций — поиск, графики, stream.