Полгода непрерывной работы. Более тысячи установок. Добавлено 95 тысяч новых строк. Удалено 84 тысячи. Было сделано 360 комитов. Вышла новая версия.
Я хочу рассказать о наиболее важных изменениях.

Доброго времени суток. Вот и пришло время для публикации второй части так понравившегося многим хабровчанам перевода стайл гайда для языка Python от компании Google, (первая часть бережно хранится хабром). Теперь мы коснемся напрямую форматирования исходного кода на языке программирования Python. Как известно, чистота — залог здоровья, а чистота программного кода — залог уважения коллег и (в идеале) поощрения от кого-нибудь свыше. Вообще, Python сам по себе является хорошо читаемым языком, и даже синтаксис данного языка призывает к порядку в коде (и, как следствие — в голове). Но каждый из нас сам себе документатор и сам себе творец оформления. А как уже говорилось однажды — ко мнению авторитетных товарищей нельзя не прислушиваться. Итак, вторая часть Google Python Style Guide — Python Style Rules ждет Вас под катом. И pdf тут как тут.

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

В этой статье будут описаны различные настройки MySQL, преимущественно те, которые влияют на производительность. Для удобства все переменные разделены по разделам (базовые настройки, ограничения, настройки потоки, кэширование запросов, тайминги, буферы, InnoDB). Сначала уточним имена некоторых переменных, которые изменились в версии 4 MySQL, а в сети продолжают встречаться и старые и новые варианты имен, что вызывает вопросы.

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

В статье будет рассказано о возможном применении xdebug системными администраторами web-серверов. Может показаться, что администратор не должен заниматься диагностикой и отладкой кода, поскольку это – работа программиста. Это так. Но, как, в случае возникновения проблемы, убедить программиста в том, что его код неоптимален (если это действительно так) и нуждается в переработке, если программист все время заявлет: «У нас все хорошо – чините сервер»? Представим, что это программист, с которым нежелательно спорить. Например, наш очень дорогой и возмущенный клиент.

Для начала скажу что я очень большой любитель что-то попатчить и потвикать, даже если для этого нету особой необходимости. И вот недавно рассматривая статистику XCache на своем сервере я подумал что смог бы оптимизировать объем памяти который он тратит на опкеш (opcache) файлов различных фреймворков. Сделать это просто — переписать все используя только один, файлы которого были бы общими для всех сайтов, каких у меня порядка 20-ти, но в большинстве они довольно простенькие и особого труда их переписать мне бы не предоставило. И тут я начал поиск того самого фреймворка, который в идеале имел бы достаточно фич чтобы разработка была простой, и в тоже время был легким и быстрым. Вот те которые мне понравились и мои мысли о них.

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

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

От переводчика:
Многие знают, что ffmpeg — это сила, но не все знают, какая именно. Он многогранен и безграничен, а его man объёмен и местами малопонятен, лишь немногие постигли дао профессиональной работы с ним. И тем не менее, этот инструмент может быть полезен почти всем, кто хоть иногда работает с видео и звуком, даже на бытовом уровне. О некоторых полезных консольных командах ffmpeg и пойдёт речь в статье. В некоторых местах я взял на себя смелость вставить ссылки на поясняющие статьи.

ffmpeg — это кроссплатформенная open-source библиотека для обработки видео- и аудиофайлов. Я собрал 19 полезных и удивительных команд, покрывающих почти все нужды: конвертация видео, извлечение звуковой дорожки, конвертирование для iPod или PSP, и многое другое.

1. Получение информации о видеофайле

ffmpeg -i video.avi

2. Превратить набор картинок в видео

ffmpeg -f image2 -i image%d.jpg video.mpg

Эта команда преобразует все картинки из текущей директории (названные image1.jpg, image2.jpg и т.д.) в видеофайл video.mpg

(примечание переводчика: мне больше нравится такой формат:

ffmpeg -r 12 -y -i "image_%010d.png" output.mpg

здесь задаётся frame rate (12) для видео, формат «image_%010d.png» означает, что картинки будут искаться в виде image_0000000001.png, image_0000000002.png и тд, то есть, в формате printf)

На прошлой неделе коллеги из Sucuri прислали нам модифицированную версию бинарного файла веб-сервера Apache, который перенаправлял некоторые, адресованные к нему запросы, на набор эксплойтов Blackhole Exploit Kit. Проведенный экспертами нашей антивирусной лаборатории анализ показал, что эта Linux-угроза, получившая название Linux/Cdorked.A, предназначена для перенаправления трафика на вредоносные сайты. Информация Sucuri об этом инциденте.

В процессе анализа мы пришли к выводу, что Linux/Cdorked.A представляет из себя наиболее сложный Linux-бэкдор из всех, что мы видели прежде. С помощью нашей облачной технологии ESET Live Grid мы получили статистику о сотнях скомпрометированных веб-серверов. В отличии от других подобных угроз, бэкдор не оставляет каких-либо следов своей деятельности на жестком диске скомпрометированного хоста, что заметно усложняет его обнаружение. Вместо этого, он хранит всю используемую им информацию в памяти, без привлечения жесткого диска. Кроме этого, злоумышленники используют обфусцированные HTTP-запросы для передачи служебной информации вредоносному коду, которые не фиксируются в лог-файле работы Apache. Таким образом следы взаимодействия вредоносного кода с C&C сервером также отсутствуют.

На сайте немало постов о том, какие условия нужно включать в договор на создание сайтов и программ (краткий список ниже), но нет договора в формате, который можно взять за основу для составления своего договора. Мы изучили условия из постов (спасибо авторам), подумали над ними, переработали и учли в предлагаемой на ваш суд форме договора. Так что договор пока можно считать частично «захабренным».

Один из ресурсов, за которым я присматриваю, вдруг стал неожиданно популярным как у хороших пользователей, так и у плохих. Мощное, в общем-то, железо перестало справляться с нагрузкой. Софт на сервере самый обычный — Linux,Nginx,PHP-FPM(+APC),MySQL, версии — самые последние. На сайтах крутится Drupal и phpBB. Оптимизация на уровне софта (memcached, индексы в базе, где их не хватало) чуть помогла, но кардинально проблему не решила. А проблема — большое количество запросов, к статике, динамике и особенно базе. Поставил следующие лимиты в Nginx:

на соединения

limit_conn_zone $binary_remote_addr zone=perip:10m;
limit_conn perip 100;

и скорость запросов на динамику (fastcgi_pass на php-fpm)

limit_req_zone $binary_remote_addr zone=dynamic:10m rate=2r/s;
limit_req zone=dynamic burst=10 nodelay;

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

Но плохиши продолжали долбить, и захотелось их отбрасывать раньше — на уровне фаервола, и надолго.

Сначала сам парсил логи, и особо настырных добавлял через iptables в баню. Потом парсил уже по крону каждые 5 минут. Пробовал fail2ban. Когда понял, что плохишей стало очень много, перенёс их в ipset ip hash.

Почти всё хорошо стало, но есть неприятные моменты:
— парсинг/сортировка логов тоже приличное (процессорное) время отнимает
— сервер тупит, если началась новая волна между соседними разборками (логов)

Нужно было придумать как быстро добавлять нарушителей в черный список. Сначала была идея написать/дописать модуль к Nginx + демон, который будет ipset-ы обновлять. Можно и без демона, но тогда придётся запускать Nginx от рута, что не есть красиво. Написать это реально, но понял, что нет столько времени. Ничего похожего не нашёл (может плохо искал?), и придумал вот такой алгоритм.

При привышении лимита, Nginx выбрасывает 503-юю ошибку Service Temporarily Unavailable. Вот я решил на неё и прицепиться!

Для каждого location создаём свою страничку с ошибкой

error_page 503 =429 @blacklist;

И соответствующий именованный location

location @blacklist {
    fastcgi_pass    localhost:1234;
    fastcgi_param   SCRIPT_FILENAME    /data/web/cgi/blacklist.sh;
    include         fastcgi_params;
}

Дальше интересней.
Нам нужна поддержка CGI-скриптов. Ставим, настраиваем, запускаем spawn-fcgi и fcgiwrap. У меня уже было готовое для collectd.

Сам CGI-скрипт

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

Начал с малого: почитал статей, да подумал мозгом. И в конце концов выстроил для себя некую модель, которая позволила бы, может быть, работать чуть продуктивнее. В общем, не хотелось мне терять деньги, прагматично всё это.

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

Я системный администратор по роду деятельности. Поддерживаю удаленно сервера разных клиентов. Нередко приходится слышать от клиента просьбу дать шелл-доступ на сервер. С одной стороны просьба вполне обоснованная: сервер не мой, да и доступ клиенту нужен, чтоб меня же не дергать по пустякам (скажем, посмотреть, не закончилось ли место на диске или все ли процессы запущены). С другой стороны клиент зачастую практически не имеет опыта работы в unix, и нет никакой гарантии, что я смогу все исправить после того, как клиент по незнанию сотрет что-нибудь с диска или заблочит мне доступ, удалив правила фаервола. Зачастую клиенты и сами это понимают, но настаивают на предоставлении им доступа, не видя другого выхода.

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

Пытаясь найти решение я наткнулся на описание модуля Cmd для Python. Данный модуль позволяет с минимальными затратами написать подобие интерфейса командной строки c необходимым набором команд.

Кто-то вчера шутил, а кто-то занимался реально полезными вещами. Как например болгарский разработчик Мартин Ангелов, опубликовавший впечатляющий обзор JS библиотек:
http://tutorialzine.com/2013/04/50-amazing-jquery-plugins/
Настоятельно рекомендуется к обозрению.
PS Куда-то пропал тип топика «Ссылка» :(

Попробуем это все объединить и сделать себе удобный call-центр.

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

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

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

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

Мне поступила задача организовать отказоустойчивость веб-приложения из двух серверов. Веб-приложение включает в себя статические файлы и данные в СУБД MySQL.
Основное требование заказчика — веб-приложение должно быть всегда доступно и в случае сбоя в течении 5 минут сбой должен быть восстановлен.
2 сервера, территориально разнесенные в разных ЦОДах, должны удовлетворить данное требование.