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

Интересуясь информационной безопасностью, я часто имею дело с зараженными сайтами, содержащими фреймы на эксплоиты, шифрованный javascript, запутанные редиректы… Для облегчения работы я использую open source программу Malzilla. К сожалению на русских просторах интернета очень мало информации об этой тулзе, поэтому я хочу перевести официальный мануал к ней. Всего в нем 6 частей, ниже следует перевод первой из них.

Привет, хабралюди!

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

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

Моя домашняя сеть разрослась до количества трех компьютеров. В связи с чем началась дележка: кто будет качать первым.
Иногда даже страничка в ФФ открывается по 2-3 минуты, так как на соседнем компе во всю качает торрент.
Советом системных администраторов (то есть мной) было принято решение создать шлюз c шейпером который будет динамически делить канал на всех.
Ну начнем

Регулярные выражения — это арифметика для алгоритмов. Они доступны во многих языках программирования, редакторах и настройках приложений. Как и сложение с умножением они просты в использовании.
Но для правильного и эффективного использования regexp-ов нужно понимание того, как они работают. Я постараюсь описать принцип работы регулярных выражений, покажу в каких случаях бывают проблемы и как их решать.

В продолжение общих советов.

В web-сервер и reverse-proxy nginx встроены очень мощные возможности по кэшированию HTTP-ответов. Однако в ряде случаев документации и примеров не хватает, в результате не все получается так легко и просто, как хотелось бы. Например, мои конфиги nginx-а местами написаны кровью. Этой статьей я попробую немного улучшить ситуацию.

В этой статье: а) подводные камни при полностраничном кэшировании; б) кэширование с ротацией; в) создание динамического «окна» в закэшированной странице.

Я буду предполагать, что вы используете связку nginx+fastcgi_php. Если вы применяете nginx+apache+mod_php, просто замените имена директив с fastcgi_cache* на proxy_cache*

Если выбирать, кэшировать ли страницу на стороне PHP или на стороне nginx, я выбираю nginx. Во-первых, это позволяет отдавать 5-10 тыс. запросов в секунду без каких-либо сложностей и без умных разговоров о «высокой нагрузке». Во-вторых, nginx самостоятельно следит за размером кэша и чистит его как при устаревании, так и при вытеснении нечасто используемых данных.

Кэширование всей страницы целиком

Если на вашем сайте главная страница хоть и генерируется динамически, но меняется достаточно редко, можно сильно снизить нагрузку на сервер, закэшировав ее в nginx. При высокой посещаемости даже кэширование на короткий срок (5 минут и меньше) уже дает огромный прирост в производительности, ведь кэш работает очень быстро. Даже закэшировав страницу всего на 30 секунд, вы все равно добьетесь значительной разгрузки сервера, сохранив при этом динамичность обновления данных (во многих случаях обновления раз в 30 секунд вполне достаточно).

В общем-то идея проста: есть время и желание попрактиковаться в защите Linux/BSD серверов от DDoS и хабраэффектов. Но нету таких серверов. Не атакуют, хоть убейся.
Поэтому если у кого есть ресурсы под нагрузкой/атакой — велком в личку. Попытаюсь помочь.

P.S.: 2admins: а давайте помогать нуждающимся. И себе опыт, и людям хорошо.
P.P.S.: Перенес в «Системное администрирование». Как говорится, пролетарии всех стран… =)

Большой брат в Linux или видеонаблюдение своими руками.

После переезда в новый офис, дабы не расслаблять сотрудников, было решено
установить систему видеонаблюдения. Но, как обычно, основным условием было:
дешево и сердито :) После обдумывания и подсчетов было решено остановиться на
следующем:
IP камеры и компьютер в качестве регистратора.
Для начала попробовали небезызвестный ZoneMinder. Но отчего-то с 9 камерами он
грузил систему нещадно. После некоторой борьбы с ним, было решено отказаться от
него. Поискав на просторах Internet была найдена программка под названием
motion (http://www.lavrsen.dk/twiki/bin/view/Motion/WebHome). Почитав немного
про нее, было решено остановиться на ней.
Итак, у нас были IP камеры, компьютер в качестве регистратора, motion в
качестве софта и желание подружить весь этот колхоз :)

Наверное на многих трекерах есть какой-то список одобренных к использованию torrent-клиентов, а так же запрещённых (клиентов вообще, либо каких-то определённых версий). Под linux есть много разных torrent-клиентов, у каждого свои достоинства и недостатки, но в списках разрешённых они всё равно появляются крайне редко.

Несколько месяцев назад я писал о выходе первой (0.1) версии своего BitTorrent клиента. С тех пор Flush дорос до версии 0.4. Т. к. первую версию, скорее всего, поставить решится далеко не каждый, да и в ней могло не быть каких-либо функций, отсутствие которых помешало бы использовать Flush, я решил, что настало время еще раз напомнить о существовании данного BitTorrent клиента. Я использую его с первой версии и сделал таким, каким, как я считаю, должен быть BitTorrent клиент. Если ваши предпочтения совпадают с моими, то, возможно, он вам придется по душе.

Причины, которые заставили меня написать собственный BitTorrent клиент, я изложил здесь, так что повторяться не буду. Думаю, лучше всего будет привести список изменений по сравнению с Flush 0.1 и скриншоты, которые зачастую могут сказать гораздо больше, чем любой Changelog. :)

Часто бывает так, что на одной площадке размещено однотипное оборудование. И чтобы быстрее обновлять IOS'ы я пользуюсь следующим приемом.

В этой статье я поделюсь собственным опытом построения веб-сервера, работающего на CentOS 5.3.

Что требовалось:

• Полностью избавиться от Apache. Сервер должен был выдерживать хорошую нагрузку, распределяя статику и динамику.
• Нужна была поддержка последней версии libxml, малейшее различие в версиях делало сайт абсолютно нерабочим.
• Нужен был gzip
• И еще некоторые особенности, о которых я расскажу в самой статье

Рано или поздно все мы сталкиваемся с тем, что нам нужно обновить IOS. Если Вы никогда этого не делали, но сделать надо, то этот пост для вас!

Введение

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

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

Наверное, некоторые знают такую штуку, но думаю, далеко не все.

Как мы все знаем, адрес IPv4 представляет собой 32-битное число. Традиционно IP-адрес записывается в виде 4-х октетов, разделенных точкой, в десятичной системе счисления. Например: 77.88.21.8.
Однако существуют и другие, менее распространенные варианты записи.

Во-первых, каждый из 4-х октетов можно записать в восьмеричной или шестнадцатеричной системах счисления:
77.88.21.8 = 0x4d.0x58.0x15.0x8 = 0115.0130.025.010, или даже можно смешивать 77.88.0x15.010.

Во-вторых, адрес можно записывать в виде числа:
77 * 256³ + 88 * 256² + 21 * 256¹ + 8 * 256^О = 1297618184.
Аналогично п.1 это число можно записывать в восьмеричной и шестнадцатеричной системах счисления: 1297618184 = 011526012410 = 0x4D581508.

Честно говоря, не нашел RFC, в котором описываются эти форматы, но это работает везде: в браузере, команде ping и т.д. Попробуйте сами.

В последнее время появилось несколько постов по привлечению внимания к определённым языкам программирования на примере написания некоего несложного «web-сервера». Раз уж пошла такая пьянка perl пока не затронули, то добавлю и свои пять копеек :)
Будем писать несложное серверное приложение, маскирующееся под http-сервер.

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

В последних версиях nginx (начиная с 0.8.11) появилась поддержка асинхронного файлового ввода-вывода. Потенциально, эта фича способна устранить одно из узких мест веб-сервера — полную блокировку процесса при файловом IO.

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

Раньше, эта проблема решалась увеличением количества процессов-воркеров. Теперь есть альтернативное решение. :) Однако, перед тем, как включать файловый AIO, стоит учесть ряд нюансов.

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

Во-вторых, файловый AIO работает только на FreeBSD 4.3 и выше, либо в Linux, с версии ядра 2.6.22 и выше.

В-третьих, AIO во FreeBSD имеет смысл включать только в версиях FreeBSD-6.4 STABLE, FreeBSD 7, или новее. В более ранних версиях, при включении AIO, сетевая подсистема начинает использовать Giant Lock, что означает невозможность одновременного выполнения какого-то другого системного вызова. Другими словами, почти никаких выгод от асинхронности мы не получим.

Ну и наконец, при использовании AIO под Linux надо также включать directio. Также, если я всё понял правильно, в линукс пока невозможно использовать AIO для подгрузки данных для sendfile, поскольку включение directio отключит использование sendfile автоматически.

Если вы по-прежнему считаете, что оно вам нужно, AIO включается очень просто. Для Linux, фрагмент конфига будет выглядеть примерно так:

aio on; # включаем AIO
directio 512; # включаем O_DIRECT для файлов, размером 512 байт или больше
output_buffers 128 512k; # зная размер и примерное количество одновременно отдаваемых файлов, можно подобрать более подходящие значения


Ссылки:
Описание AIO в документации на Nginx
Changelog

Простой способ защиты от HTTP DDoS — включить syn-cookies и заблокировать подонков. Но что делать если атакует 5к-10к хостов да еще и с динамическими IP? Тут нам на помощь придет frontend-backend архитектура c промежуточным кэшированием! Почему с промежуточным кэшированием? А потому что в моем случае от шквала запросов от frontend'а backend умирал унося за собой систему.

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

Скачиванием через cURL не пользовался пусть даже из интереса только ленивый. Будь-то из консоли, либо реализуя код на каком-либо ЯП. Решения блокирующего скачивания одной ссылки валяются на каждом углу сети, к примеру на php.net. Однако, если рассматривать реализации на PHP, то такой подход подчас не подходит ввиду высоких временных затрат на вспомогательные операции ( dns lookup, request waiting и подобные ). Для скачивания большого числа страниц последовательный вариант не приемлем. Если устраивает — дальше можно не читать :)