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

Этот короткий материал ориентирован на «самых-самых маленьких» пользователей Linux и служит целью показать, насколько легко и просто организовать резервное копирование на сервера Amazon S3.

Бэкапы — это вечная проблема: то объемы данных сумасшедшие, то вообще забываешь про них. В своем предыдущем проекте dvice.ru (он пока закрыт, так что без ссылки) я допустил досадную ошибку в самом начале его запуска. Я написал небольшой крон, который в 12 часов ночи удалял всех неактивированных пользователей, зарегистрировавшихся больше 24 часов назад. Но я ошибся в запросе и потерял данные пользователей, которые зарегистрировались до первого запуска этого запроса. Слава Богу, у меня были все данные в сессиях, поэтому я восстановил всех тех, кто логинился и ставил галку на чекбоксе — запомнить меня. Обидно и глупо, но на ошибках учатся. Поэтому перед запуском своего крайнего проекта — inwhite.ru, я сделал систему бэкапов.

Бэкапы делались и копились, старые удалялись, и все было отлично. Пока внезапно я не понял, что страдаю полной фигней. Бэкапы-то я делаю, а вот забирать — не забираю. Объемы данных, лежащих на моем VPS, не такие большие, но по почте тоже особо не наотправляешься. Покупать еще один VPS и складывать туда все по FTP/SVN/CVS/SSH не особо хочется, хотя тоже вариант интересный.

До вчерашнего дня я был озадачен мыслью: а как все же забирать эти данные? И вот вечером меня осенило.

Несколько позже, чем хотелось, но продолжаем наш разговор о получении текста из разных форматов данных. Мы с вами уже познакомились с тем, как работать с изначально XML-base файлами (docx и odt), прочитали текст из pdf, преобразовали содержимое rtf в plain-text. Теперь перейдём в вкусненькому да сладенькому — формату DOC.

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

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

Я давно ждал этого момента, нет честно, где-то в подкорке я очень-очень хотел такой штуки чтобы было удобно писать на CSS без переписывания похожих стилей по два раза, без выыскивания нужных разделов в собственном коде, в общем хотелось чтобы на CSS можно было работать легко и просто, что-то я затянул…И так встречайте xCSS — php-класс для работы с динамическим CSS.

Наблюдая выводы таких команд, как top, htop, uptime, w и, возможно, других, пользователь наверняка обращал внимание на строку load average:

Введение

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

Цель поста — показать как Perl можно использовать заместо find, grep, awk, sed. В конце поста будет написано зачем это надо.

Я часто вижу ошибки, связанные с созданием индексов в MySQL. Многие разработчики (и не только новички в MySQL) создают много индексов на тех колонках, которые будут использовать в выборках, и считают это оптимальной стратегией. Например, если мне нужно выполнить запрос типа AGE=18 AND STATE='CA', то многие люди просто создадут 2 отдельных индекса на колонках AGE и STATE.

Намного лучшей (здесь и далее прим. переводчика: а обычно и единственной верной) стратегией является создание комбинированного индекса вида (AGE,STATE). Давайте рассмотрим почему это так.

Сегодня был неожиданно удивлен, какие удобные штуки таит в себе MySQL. ;-)

Хочу представить вашему вниманию фичу MySQL — профайлинг.
Появилась она начиная с версии 5.0.37.

Всего парой запросов можно узнать, какими запросами формируется страница (для веб-девелоперов)
и почему она тормозит.

И раньше подобный функционал был доступен, но пользоваться журналом запросов не в пример сложнее.

Итак, как пользоваться:

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

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

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

PHP один из самых широко используемых языков для создания вебсайтов. PHP фреймворки, такие как Zend, CakePHP, CodeIgniter и т.д и open source классы и библиотеки упростили разработку.
Независимо от того, являетесь ли вы опытным разработчиком или новичком, инструменты, которые вы используете, имеют прямое влияние на вашу продуктивность. Здесь собран список действительно полезных утилит и расширений для PHP разработчиков, которые помогут ускорить разработку, и улучшит итоговое качество кода.

Год назад мы с командой решили перейти с SVN на Git. Зачем это было надо — писать не буду, т.к. на эту тему уже и так много написано. А хочу я описать типичные алгоритмы работы, понятные человеку, который долгое время пользовался SVN. Ниже — памятка, написанная для команды год назад, чтобы легче было мигрировать. Надеюсь, кому-нибудь пригодится.

Сисадмины делятся на тех, кто не делает бэкапы, и тех кто, их уже делает =)

Про то как восстанавливать файлы с ext3 / ufs написана не одна статья, так что не буду повторятся и напишу про не самые широко известные способы восстановления конфигов на продакшн сервере.

В сферу моих профессиональных обязанностей входит проведение собеседования для соискателей на должность PHP разработчика. И дальше речь пойдет о собеседовании…

/update/ Статья обновлена по результатам обсуждения. Поправлен код Python (около 40% ускорения), написан код на Perl и Ruby (но меня терзают смутные сомнения, что с ruby я что-то сделал неправитьно), поправлен код на Java (на моей машине корректнее тестировать int, а не long. к тому же int в Java эквивалентен long в C++).

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

После прочтения очередной статьи мне захотелось самому разобраться «здесь и сейчас». Сначала захотелось сравнить Java и C++ (не верил я, что в вычислительных тестах ява может догнать и обогнать cpp). 10 минут и простой код на C++ и яве готов: простой цикл и математические операции. После написания теста подумал и перевёл их на php и python. Позже добавился код на perl и ruby.

По мотивам предыдущей статьи, только в этот раз собираем статистику для веб сервера nginx.

as simple as possible, but not simpler

В 2001, после эпидемии CodeRed, Николас Вивер написал крайне интересную статью про быстрораспространяющихся червей «Warhol Worms: The Potential for Very Fast Internet Plagues», у которой была потом ещё пара сиквелов. Краткое содержание статьи: если к механизму распространения червя добавить ряд оптимизаций, то червь может поразить всю уязвимую популяцию за 15 минут и даже быстрей. Грубо говоря, сломать интернет быстрей, чем админ допьёт кофе. Оптимизации были интересные:

1. hitlist scanning (заранее создать список первых 1000-10.000 жертв, чтобы избежать начальной пологой стадии экспоненциального роста)
2. permutation scan (обнаружив уже заражённую машину, перескочить в списке адресов, поскольку следующие за заражённым адреса уже наверняка просканированы)
3. partitioned scan (родительский червь раздаёт потомкам диапазоны адресов, чтобы совершенно исключить повторное сканирование)
4. subnet scan — очевидное сканирование локальной подсети в первую очередь

Меня тогда очень поразили такие возможности червестроения. Я тогда накатал статью «Modular Worms», что черви будущего будут со сменными насадками, апдейтиться прямо в сети и т.д. Мою статью, как обычно, отклонили, а лет через пять, как обычно, именно такие черви стали использоваться для строительства ботнетов. Сначала был Agobot, а потом дело встало на поток. Даже появился термин «open-source worm».

Реальный же червь Уорхола появился 25 февраля 2003 года. Он назывался SQL Slammer, заражал MS SQL Server. И этот червь не использовал ни единой хитрой оптимизации. Он тупо распространялся по UDP, умещаясь внутри одной-единственной датаграммы. Это было проще, это было дешевле. Ведь все мы знаем, что TCP нужно отправить три пакета только чтобы начать общение. При этом необходимо держать структуры данных в ядре, ждать ответа, ставить таймеры и т.д. и т.п. Напротив, UDP червь мог тупо забивать аплинк датаграммами, сколько уж влезет. А влазит много: 1Mbits это 332 «споры» в секунду, каждая спора 376 байт. Глобальное распространение червя произошло за 10 минут. Может и быстрее, подумал я, ведь моя статистика собиралась с шагом 10 минут. И в одном файле червя не было, а в следующем он уже был. Я проверил таймстампы — да, примерно 10 минут. Зарубежные коллеги тоже сказали 10 минут. Этот рекорд до сих пор не побит.

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

О ssh и системных администраторах:

С давних пор *nix системные администраторы используют ssh для удаленного управления серверами.
Некоторые из них делают себе готовые наборы скриптов для обновлений софта, раскладки из репозитория, и так далее.
До определенных размахов бедствия можно обходить парк машин одну за одной. Однако рано или поздно парк машин вырастет до вполне себе солидных размеров и тогда простейшая раскладка по фронтэндам новых скриптов становится головной болью нескольких часов.

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

Что такое XSS и как от него защитится все уже давно знают, поэтому буду краток. XSS это возможность злоумышленника определенным образом (ссылку на возможные варианты смотрите в конце статьи) интегрировать в страницу сайта-жертвы скрипт, который будет выполнен при ее посещении.

Интересно, что в большинстве случаев, где описывается данная уязвимость, нас пугают следующим кодом:

http://www.site.com/page.php?var=<script>alert('xss');</script>

Как-то не очень страшно :) Чем же действительно может быть опасной данная уязвимость?

Ранее я показал элементарную реализацию алгоритма шинглов, позволяющую определять, являются ли два документа почти дубликатами или нет. В этот раз я поясню реализацию алгоритма, описанную Зеленковым  Ю. Г. и Сегаловичем И.В. в публикации «Сравнительный анализ методов определения нечетких дубликатов для Web-документов».
Этим я начинаю серию из трех теоретических статей, в которых постараюсь доступным языком описать принцип алгоритмов шинглов, супершинглов и мегашинглов для сравнение веб-документов.