Вы отвечаете за стабильность работы веб-проекта на PHP. Нагрузка постоянно растет, добавляются фичи, клиенты довольны. В один прекрасный день начинают появляться загадочные ошибки…

Ошибки серверного софта

… которые программисты не знают как исправить, т.к. «ломается» серверный софт, например связка apache-PHP — а клиент получает в ответ на запрос страницу о регламентных работах. Веб-разработчик часто не обладает глубокими знаниями в программировании на C в unix/linux, а сисадмин нередко, к сожалению, глубже bash в систему не погружается. Настоящий хардкор :-)

Нестабильная работа серверных скриптов

Нередко, определенные страницы веб-проекта начинают сходить с ума. Например выполняться по 15 минут и выяснить, чем же они занимаются, непросто. В прошлом посте на данную тему я описал одну из методик определения, чем занимается PHP-скрипт на боевом сервере, но чувствуется, что нужен более мощный инструмент.

На практике я часто встречаю проекты, которые сталкиваются с подобным классом ошибок «серверного софта», и в команде не всегда знают, что делать. В логе apache часто появляются сообщения о нарушении сегментации (segmentation fault), клиенты получают страницу об ошибке, а веб-разработчик с сисадмином ломают себе голову, играются с разными версиями PHP/apache/прекомпилятора, собирают PHP из исходников с разными опциями снова и снова, пишут о багах, а им доказывают, что это баги не PHP, а их кода и так до бесконечности…

В статье я хочу рассказать как можно просто и быстро найти причину, почему PHP рассыпался на боевом сервере и устранить ее — не погружаясь в прекрасный мир системного программирования на C для unix :-) От вас потребуется желание и одна чашечка кофе.

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

Начать свое присутствие на Хабре мы решили с материала, подготовленного для Конференции уральских веб-разработчиков, в котором описаны проверенные на собственной практике и оказавшиеся вполне успешными методы борьбы с DDoS-атаками. Целевая аудитория данной статьи — это программисты, имеющие в распоряжении vds или dedicated. Статья не претендует на полноценное руководство и многие сисадминские нюансы в ней намеренно опущены. Мы рассматриваем только DDoS типа http flood как наиболее распространенный тип DDoS и наиболее дешевый для заказчика.

Целевая аудитория данной статьи – это программисты, имеющие в распоряжении VDS или Dedicated.

abstract: В статье описаны продвинутые функций OpenSSH, которые позволяют сильно упростить жизнь системным администраторам и программистам, которые не боятся шелла. В отличие от большинства руководств, которые кроме ключей и -L/D/R опций ничего не описывают, я попытался собрать все интересные фичи и удобства, которые с собой несёт ssh.

Предупреждение: пост очень объёмный, но для удобства использования я решил не резать его на части.

Оглавление:

• управление ключами
• копирование файлов через ssh
• Проброс потоков ввода/вывода
• Монтирование удалённой FS через ssh
• Удалённое исполнение кода
• Алиасы и опции для подключений в .ssh/config
• Опции по-умолчанию
• Проброс X-сервера
• ssh в качестве socks-proxy
• Проброс портов — прямой и обратный
• Реверс-сокс-прокси
• туннелирование L2/L3 трафика
• Проброс агента авторизации
• Туннелирование ssh через ssh сквозь недоверенный сервер (с большой вероятностью вы этого не знаете)

Неожиданно поступила задача разобраться почему определенный сайт не работает столь быстро сколь хочется. В основе его CakePHP, в связке с Apache и MySQL. В статье описание процесса поиска узких мест и приведение в порядок на столько, на сколько это возможно.

Название сайта светить не буду — думаю, программисты сами узнают. Скажу лишь, что это приложение для социальной сети нагрузкой 70-150 тысяч посетителей в обычное время. Все усложняется тем, что периодически производится рекламная рассылка, которая привлекает около 200-300 тысяч посетителей за пару часов.

Итак, под катом описание всей борьбы на протяжении 4 дней.

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

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

Я предполагаю, что читатель уже знаком с тем, что такое mod_rewrite, и не буду описывать его основы, которые легко найти в интернете. Также нужно отметить, что в статье освещается работа mod_rewrite при использовании его директив в файле .htaccess. Отличия при работе в контексте <VirtualHost> изложены в конце статьи.

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

Почему так происходит?

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



Тогда понадобился год, чтобы прочитать в десять раз больше бумаги и сделать выборку, которая оказалась неожиданно полезной многим. Вот результаты ещё одного года — ещё N+2 книги для бизнеса, которые реально помогают.

Многие сталкивались с таким явлением как DDoS атака методом HTTP флуда. Нет, это не очередной туториал по настройке nginx, хочу представить свой модуль, работающий как быстрый фильтр между ботами и бэкэндом во время L7 DDoS атаки и позволяющий отсеивать мусорные запросы.

В предыдущей статье я рассказывал про фильтр U32. В этой статье речь пойдёт о так называемых tc actions — действиях, которые можно производить над трафиком. Например, можно построить файерволл без использования iptables/netfilter, или изменять отдельные байты в пакетах, перенаправлять/зеркалировать трафик на другие интерфейсы. Осваивать это будем на примерах. Продолжение под катом.

Так повелось, что фильтр U32 в подсистеме управления трафиком ядра Linux считается простым и понятным, а потому в подробном документировании не нуждается. Например, в LARTC (Linux Advanced Routing and Traffic Control) про него лишь несколько абзацев. Но на самом деле U32 устроен гораздо сложнее и интереснее, но и в использовании он не так прост, как может показаться. Под катом статья по этому фильтру с примерами использования и подробными пояснениями.

Есть у меня серверок (да, да, именно серверок, сервером его назвать сложно). Железо старенькое (2 гига оперативы, AMD Athlon(tm) 64 Processor 3500+, програмный RAID). Админю я его сам, без особых навыков и познаний. Когда-то давным давно (больше года назад) поставил на него Debian 5.0 Lenny (это была вторая в жизни установка linux-системы, до этого ставил только Ubuntu на рабочий ноутбук) и панель управления ISPConfig3 по мануалу. Держу на нем несколько (штук 40) сайтов друзей и клиентов, Redmine, SVN и еще немного по мелочам.
Периодически все это безобразие падает (load average > 20), и приходится на сервере раз в пару часов перегружать apache или высасывать из пальца очередную попытку оптимизации. В общем полный раздрай и разруха. И вот в одну прекрасную субботу я подумал — а почему бы не решить вопрос раз и… И вот в общем.
Под катом — история убитых выходных + предыстория. Интересна в первую очередь мне, чтобы потом легко вспомнить что именно и зачем я ставил. Может быть интересна новичкам в интересном и нелегком (ох, ...) деле серверной оптимизации постепенным(!) переводом сайтов из-под Apache c его ModRewrite под Nginx (кстати, правильно это слово читается «энжинкс»меня поправили, Сысоев на конференциях не раз говорил, что название сервера стоит читать, как «энжин-икс», спасибо bayandin и DorBer ). Возможно, будет интересна более-менее опытным товарищам, оказавшимся в тех же условиях (Debian Lenny, ISPConfig3, слабое железо, несколько хороших, не сильно хороших и разных сайтов). И более опытным может быть интересно зайти, оставить пару комментариев.

Есть несколько идентичных серверов (4 ноды) на Amazon EC2 с Ubuntu. Каждый генерирует и хранит у себя на диске кэш, который хотелось бы синхронизировать. Но простой rsync тут не подойдет — файлов несколько миллиардов, nfs — слишком медлителен, и т. д. Полный список рассмотренных вариантов с пояснениями ниже.

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

После теста нескольких кластерных технологий и файловых систем, по совету старшего товарища, решили использовать тот же rsync, но в связке с inotify. Немного поискав в интернете готовое такое решение, дабы не изобретать велосипед, наткнулся на csyncd, inosync и lsyncd. На хабре уже была статья о csyncd, но он тут не подходит, т.к. хранит список файлов в базе SQLite, которая вряд-ли сможет сносно работать даже с миллионом записей. Да и лишнее звено при таких объемах ни к чему. А вот lsyncd оказался именно тем, что нам и было нужно.

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

Введение

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

Эта статья — не набор “волшебных команд” и рецептов (cookbook, как называют такие наборы по-английски), хотя они тут тоже присутствуют, а, скорее, попытка описать, как общие принципы построения эргономичных интерфейсов можно применить в практике использования Vim, чтобы сделать из него удобную и эффективную среду работы с текстами.

Эта статья также не является tutorial’ом для начинающих пользователей Vim, хотя и им (а также пользователям Emacs) может быть интересна, поскольку некоторые упоминаемые принципы являются достаточно общими и действуют не только в системах редактирования текстов, а вообще везде, где идет речь об использовании компьютера для редактирования чего-либо. Тем не менее, я предполагаю, что читатель знаком с основными концепциями, применяемыми в Vim (режимы, регистры, буфера, команды) и не останавливаюсь на их подробном описании.

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

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

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

Итак, начнём.

Что такое комбинационная логическая цепь?

Это – цепь, способная обрабатывать бинарные электрические сигналы. В каждый момент времени исходящие сигналы комбинационной логической цепи (КЛЦ) зависят исключительно от входящих сигналов. Следовательно, одной и той же комбинации входящих значений соответствует одна и та же комбинация исходящих.

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

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

Началось все с того, что в один прекрасный момент ядро прибило демона mysqld и mysql_safe автоматом его перезапустил и все бы хорошо, да только таблицы в БД использовались MyISAM. В итоге пришлось воспользоваться myisamcheck но это совсем другая история. В процессе проверки и починки индексов пострадала одна таблица и было принято решение восстанавливать из бекапов, хорошо, что раз в сутки делаются.

Исходные данные:

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

Задача:

• сервер должен быть доступен для работы;
• новые данные должны попадать в таблицу;
• восстановить целостность данных.

Ожидаемый результат:
данные в поврежденной таблицы восстановлены без останова базы дынных;
таблица содержит все данные включая текущие.

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

Обзор свободно доступных и бесплатных IP АТС: Asterisk, FreeSWITCH, SipXecs, Yate. Приводятся преимущества и недостатки, сравнительный анализ функциональности и сфер применения. Делается вывод о том, что все продукты можно сочетать друг с другом.

Некоторое время назад ко мне обратился товарищ из «Открытых Систем» и попросил сделать обзор открытых IP АТС. Так как он обратился не только ко мне, а еще и к другим экспертам IP телефонии, то в результате в журнал попала компиляция, в которой мало осталось от моего оригинального обзора. Публикую его целиком на Хабре.

Вначале будет теоретическая вставка, для тех, кто не совсем в теме. Если будет скучно — просто пропустите ее! Приятного чтения! А чтобы лучше читалось, главы сопровождаются музыкальными подарками (настоятельно рекомендую наушники :-)

Поехали!

Теория

PBX (Private Branch Exhange) — английский термин, обозначающий офисную телефонную станцию, которая обеспечивает установление, поддержание и разрыв соединений между аппаратами, то есть коммутацию. PBX позволяет разделять ограниченные ресурсы (городские линии и номера) между неограниченным числом внутренних пользователей, при помощи таких телефонных функций, как внутренний номерной план, перевод звонков, постановка на удержание, и других.

Именно поэтому PBX система необходима любой организации — она позволяет эффективно организовать телефонную связь на предприятии (ну, пока еще нужна ;-)

Все началось, когда я заменил материнскую плату в своем домашнем компьютере. В старой плате был встроенный USB Wi-Fi адаптер на обычном Realtek 8187, который два года исправно работал точкой доступа под Windows. В новой плате Wi-Fi модуля не было, зато у меня появился целый сервер на замечательном Intel Atom 525 с одним маленьким недостатком — в нем было очень мало PCI слотов.

Немного поразмышляв, я решил сделать невинную, как мне сначала казалось вещь — запустить программную Wi-Fi точку доступа на обычном USB адаптере. Если бы меня предупредили что меня ожидает, я бы отказался от идеи с самого начала! Я раздобыл недорогой адаптер и, только в процессе возни с ним, стал осознавать что использование «неправильного» USB на «неправильном» чипсете это настоящее насилие для Linux! Гуру Линукса отказывались от помощи!

Тем не менее, мне удалось подружить Debian 6.0 с чипсетами Ralink 2870/3070 и Atheros 9170, и я готов раскрыть эту страшную тайну всему миру!