16 тонн софта :)

понедельник, 18 июня 2012 г.

Почему приватность важна, даже если вам нечего скрывать

Очень часто можно услышать такую фразу по поводу приватности - "Мне нечего прятать. Волноваться нужно, только если вы делаете что-то неправильное, в таком случае вы не заслуживаете права держать это в секрете".

Очень интересная статья на английском о несостоятельности подобной логики и ее перевод.

воскресенье, 10 июня 2012 г.

Очередной раз про взлом паролей

English text is here

Я давно интересуюсь темами IT-безопасности, криптографией и (связанной с ними обеими) парольной безопасностью, даже делал на эту тему блиц-доклад на PerlMova еще в 2010 г. Тем более любопытно, что произошло в этой области в последнее время. А произошло немало - сначала утечка паролей LinkedIn, потом Lastfm / Eharmony. В обоих случаях использовались несоленые хеши (извините, но єто вообще то капец) - sha1 в случае LinkedIn и md5 в случае Lastfm (самих хешей в случае с Lastfm правда предоставлено не было, на факт что за год было вскрыто 95% всех паролей говорит сам за себя).
После всей этой катавасии широко известный в укзих кругах Poul-Henning Kamp, объявил, что созданную им в 1995 году реализацию системы хэширования паролей md5crypt больше нельзя считать безопасной, так как современные брутфорсеры паролей могут перебирать более 1 млрд. MD5 хешей в секунду (порядка 1 млн. md5crypt/сек), что слишком много - простые пароли могут быть быстро взломаны. Желающие могут ознакомиться с занятной презентацией Speeding up GPU-based password cracking, откуда мне понравилась следующая табличка -

То есть 8ми символьные буквенноцифровые пароли уже ненадежны - 2 дня на полный брутфорс - это просто катастрофа с точки зрения безопасности. (кстати, в 2010 году в моем докладе у меня получилось вообще 20 минут - правда брутер был мощнее 2.7 млрд. хешей в секунду, так что возможно в докладе идет речь как раз о md5crypt).
Выход собственно всем уже ясен и понятен - использовать для хранения хешей паролей то, что было придумано для хранения хешей паролей - а именно - bcrypt, scrypt или PBKDF2.
Тут еще можно добавить очень хороший доклад с PHDays по теме хранения паролей от тоже весьма известного в кругах безопасников Александра Песляка aka Solar Designer - только перемотайте на 14:00:00 (слайды к докладу).

понедельник, 9 апреля 2012 г.

Несколько интересных тулзов

English text is here

Парочка интересных вещей - на будущее, на посмотреть - пусть ссылки побудут тут.
1. Logstash - http://logstash.net/ - Могучий обработчик логов. Принимает логи из кучи источников , применяет к ним кучу фильтров и складывает куда надо. "Куда надо" может быть ElasticSearch-кластер, ко всему этому делу есть вебинтерфейс и куча плагинов (для amqp, greylog2, graphite, etc). Похож на Splunk, может не такой крутой, но бесплатный (Цена на Splunk - та еще жесть). Клиент написан на JRuby. :)
2. Книжка по Varnish - "От создателей", как говорится. Скоро обещают PDF и epub форматы.

пятница, 16 марта 2012 г.

Почему сервер тормозит?

English text is here, as usual. :)

Супер.
Очень интересные ссылки обнаружил в блоге разработчиков DTrace -
1. The USE Method - http://dtrace.org/blogs/brendan/2012/02/29/the-use-method/
2. The USE Method: Solaris checklist - http://dtrace.org/blogs/brendan/2012/03/01/the-use-method-solaris-performance-checklist/
3. The USE Method: Linux checklist - http://dtrace.org/blogs/brendan/2012/03/07/the-use-method-linux-performance-checklist/
Вкратце - изложена очень простая, но эффективная методика определения проблем с производительностью сервера - USE (utilization, saturation, errors) метод. То есть для каждого ресурса сервера - CPU, память, диски, сеть и т.д. мы проверяем

на сколько загружен ресурс от максимума (utlization)
как часто ресурс не может обработать все запросы и ставит их в очередь (saturation)
сколько ошибок генерируется при работе с данным ресурсом (errors).

Как правило сначала нужно проверить ошибки, потом утилизацию - а потом уже очереди - хотя и не всегда.
Это очень кратко - всем рекомендую ознакомиться со статьями. Во 2й и 3й части даются конкретные списки команд и рекомендации для проверки Солярки и Линукса по вышеописаному методу.
И кстати, метод волне юзабелен даже и без dtrace - тем более что под Линуксом его и нет, а имеющиеся реализации авторы блога терпеть не могут. :)

воскресенье, 4 марта 2012 г.

Пара ссылок

Нашел пару интересных ссылок -

1. http://www.windley.com/archives/2012/03/asynchronous_http_requests_in_perl_using_anyevent.shtml - небольшое введение в асинхронное программирование на Perl с помощью AnyEvent.

2. Прикольное обьяснение алгоритма Диффи-Хельмана (про безопасный обмен ключами) - все интересно и понятно.

Perl теперь и на Heroku !

English post is here.

К своему удивлению недавно узнал что на облачном хостинге Heroku теперь можно пускать приложения на (почти) любой веб-платформе. Делается это с помощью технологии называемой buldpacks. По идее это сделано чтобы можно было "потюнить" платформу/окружение - использовать новую версию Node.js или Ruby или что нибудь в этом роде. Но народ быстро смекнул в чем дело и нашлепал билдпаков на любой вкус и цвет - для C/Erlang/PHP/Go/Scala/etc - ну и конечно для Perl, причем один из них сделал сам ~~великий и ужасный :)~~ Miyagawa - heroku-buildpack-perl. Им я и воспользовался чтобы перетащить свой Plusfeed.pl на Heroku со Stackato (где уже кончился триал). Теперь он живет на http://perlfeed-pl.herokuapp.com - заодно я пофиксил один неприятный баг из-за которого у сообщения менялся id при добавлении комментария или +1 - соответсвенно оно всплывало в ленте. :(
Вкратце я опишу как это делается.
1. Пишем стандартный Makefile.PL для своего приложения (можно использовать формат Build.PL) - вот мой -

use strict;
use warnings;
use ExtUtils::MakeMaker;
WriteMakefile(
NAME => 'plusfeed.pl',
VERSION => '0.05',
AUTHOR => 'Denis Zhdanov ',
EXE_FILES => ['app.psgi'],
PREREQ_PM => {
'Google::Plus' => '0.004',
'XML::RSS' => '1.49',
'XML::Atom::SimpleFeed' => '0.86',
'Plack::App::Path::Router' => '0',
'Plack::App::File' => '0',
'Plack::Builder' => '0',
'Path::Router' => '0.11',
'CHI' => '0.5',
'Starman' => '0.3',
},
test => {TESTS => 't/*.t'}
);

2. Добавляем свое приложение на сайт с помощью кастомного билдпака -
git init
git add .
git commit -m "Initial version"

heroku create --stack cedar --buildpack \ http://github.com/miyagawa/heroku-buildpack-perl.git
git push heroku master

Вся магия содержится в строке с buildpack. После этого видим что то хохожее -

-----> Heroku receiving push

-----> Fetching custom buildpack... done

-----> Perl/PSGI app detected

-----> Installing dependencies

-----> Installing Starman

Starman is up to date. (0.3000)

-----> Discovering process types

Procfile declares types -> (none)

Default types for Perl/PSGI -> web

-----> Compiled slug size is 6.8MB

-----> Launching... done, v7

http://plusfeed-pl.herokuapp.com deployed to Heroku

(было много строк со сборкой cpanm и всех зависимостей, но только в первый раз, при обновлении этого не требуется).

Все пользуемся приложением и радуемся. :)

понедельник, 6 февраля 2012 г.

Подводные камни Project Voldemort

English post is here

Используется в одном из наших проектов такая штучка как Project Voldemort. Если вкратце, то это весьма любопытная реализация key-value storage aka NoSQL database. То есть даешь ему ключик и значение, и оно быстро в памяти это хранит/отдает и на диске тоже сохраняет, для персистентности. Оно на Java написано, и вообще больше из Java мира, но обслуживать и тюнить его приходится конечно нам, OPS Team. :)
В общем, столкнулись мы с одной проблемкой при эксплуатации, а именно - при большом трафике на этот Вольдеморт его база начала пухнуть со страшной силой - буквально десятки гигабайт в час - хотя девелоперы уверяли что такого количества данных там быть не должно. Пришлось копаться.
В результате "копаний" выяснилось следующее - в качестве бэкенда этот Вольдеморт использует так называемую BDB JE - Berkeley DB Java Edition, и оказалось что это JE совсем не похожа на обычную Berkeley DB. Оказывается она write only - то есть, основана на том же принципе что и журнализируемые ФС - при любой операции - запись, обновление, удаление - данные ДОЗАПИСЫВАЮТСЯ в файлики на диске и сами по себе они НЕ УДАЛЯЮТСЯ. Специальный cleaner процесс потом ходит и чистит устаревшие данные - проверяет общую утилизацию файлов в БД, и если она меньше bdb.cleaner.minUtilization процентов (по дефолту - 50%) начинает проверять каждый файлик, и если в нем меньше bdb.cleaner.min.file.utilization процентов (5% по дефолту) файлик удаляется, и данные из него переносятся в новый файл.
Хорошо. Вроде бы надо поиграться этими параметрами. Но что то не похоже чтобы утилизация у нас была 50% - уж очень много данных на диске хранится. Проверяем -

# java -jar /usr/local/voldemort/lib/je-4.0.92.jar DbSpace -h /usr/local/voldemort/data/bdb -u

File Size (KB) % Used
-------- --------- ------
00000000 61439 78
00000001 61439 75
00000002 61439 73
00000003 61439 74
...
000013f6 61415 1
000013fd 61392 2
000013fe 61411 3
00001400 61432 2
00001401 61439 1
...
0000186e 61413 100
0000186f 61376 100
00001870 16875 95
TOTALS 112583251 7

Опа-па. Не работает значит чистка. Пытаемся увеличить количество потоков для чистки - играемся с bdb.cleaner.threads (по умолчанию 1) - без пользы. В результате гугления натыкаемся на тред в форуме посвященному BDB JE (как выяснилось, очень полезный форум, если вы в каком либо виде используете BDB JE - обязательно почитайте).

Тред (сорри, сейчас что то найти его не могу) ясно говорит о том, что на очистку может сильно влиять размер кеша BDB. То есть, если кеш маловат - чистка может даже не запускаться, так как при большом количестве ключей желательно чтобы все они влезали в кеш, иначе сильно падает производительность очистки. Желательный размер кеша можно прикинуть используя следующую команду -

# java -jar /usr/local/voldemort/lib/je-4.0.92.jar DbCacheSize -records 1000000 -key 100 -data 300 

Inputs: records=1000000 keySize=100 dataSize=300 nodeMax=128 density=80% overhead=10%

    Cache Size      Btree Size  Description

--------------  --------------  -----------

   177,752,177     159,976,960  Minimum, internal nodes only   208,665,600     187,799,040  Maximum, internal nodes only   586,641,066     527,976,960  Minimum, internal nodes and leaf nodes

   617,554,488     555,799,040  Maximum, internal nodes and leaf nodes

Btree levels: 3

(где key и data - средний размер ключа и данных, в байтах).

То есть, для наших данных, на каждый миллион записей нужно около 200 МБ кеша - а записей у нас был не один миллион. :(

Итого - после выставления адекватных кешей (bdb.cache.size), за сутки утилизация БД выросла с 7% до искомых 50%, соответсвенно размер БД упал В РАЗЫ.

Мораль - изучайте используемую технологию (даже если она используется не напрямую, а опосредовано. :) )

понедельник, 18 июня 2012 г.

воскресенье, 10 июня 2012 г.

понедельник, 9 апреля 2012 г.

пятница, 16 марта 2012 г.

воскресенье, 4 марта 2012 г.

понедельник, 6 февраля 2012 г.