Блоггг Docent

2016-05-04T08:52:00.002+03:00

Отчаявшись найти в Неаполе англоязычных, решили ускоренными темпами учить итальянский.
Не понту ради, а уж очень хотелось добраться до номера.
В качестве жертвы выбрали пожилую добродушную тетечку, явно из местных.
— Scusa, come arrivare a Via Orazio trentasei (извините, как проехать на Орацио 36?)
— Божи мой, шо ви мучаетесь? Говорите на русском и не морочьте людям голову.
— Ой, а вы говорите по-русски?
— Тут все говорят по-русски, кроме турыстов, которые пытаются шпрехать на италянском. Идемьте, я покажу ваш бус.
— А где билеты брать?
— Ай, вечером все равно никто не проверяет. Заходите спокойно и сидите тихо.
— А если все-таки взять билеты, то где?
— И откуда ж ви такие честные?
— Из Израиля.
— Ой, ви вгоняете меня в депрессию. Таки зайдите в автобус и сидите тихо, не позорьте нацию!

2016-05-04T08:49:00.001+03:00

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

2016-05-04T08:48:00.002+03:00

Сельская дискотека. Стоит девчонка одна - никто с ней не танцует. Вдруг подлетает к ней какой-то амбал и начинает с ней вальсировать.
Она:
- Скажите, Вы из этих мест?
- Ага.
- А чего же я Вас раньше не видела.
- Сидел я, 15 лет.
- Да??? А за что?
- Да жену свою топором убил!
Она поправляет прическу и с улыбкой говорит:
- Значит, Вы не женаты?

2016-05-04T08:45:00.001+03:00

Кафе при зоопарке. Дама, заказав кофе с пирожным, слушает спор, который ведут между собой трое рабочих в синих комбинезонах.
— Да вы чего? — говорит один. — Это сложное слово. А пишется оно так: "хврухт"!
— Ну, нет! — отзывается другой. — Его нужно писать черездва "у": "хвруухт"!
— А по-моему, вы оба путаете, — горячится третий. — Правильное написание такое: "фрухт"...
Дама допивает кофе, доедает пирожное, расплачивается и, проходя мимо столика работяг, строгим голосом бросает:
— Джентельмены! Если вы не поленитесь и посмотрите в любой словарь, вы сможете найти там единственно правильную версию. Это слово пишется "фрукт" и никак иначе!..
— Образованная!.. — произносит ей вслед один рабочий.
— Да-а, грамотная тетка, сразу видно, — соглашается второй.
— И все равно, — возражает третий, — готов спорить на ящик пива, что она ни разу в жизни не слыхала, как пердит слон!

IPTV-стример на базе getstream_a84

2012-04-16T09:53:00.000+03:00

Как бы ни был VLC хорош с его набором модулей и функций, а также утечками памяти и глюками. Нет, я уважаю этот проект, но просто иногда не нужно всех этих плюшек.
Итак, начнем. Все действия производятся на Ubuntu Server 10.04 LTS с 4 DVB-картами Omicom S2 pci rev.3.
Для установки потребуются драйвера (не работают на ядрах 2.6.37 и выше), кстати подойдут ко многим DVB-картам и драйвера для версии ядра 2.6.38-8, и пакеты build-essential subversion linux-libc-dev libssl-dev gettext sysv-rc-conf linux-headers-`uname -r` git-core mercurial ncurses-dev dvb-apps libxml2-dev dialog libevent-dev libglib2.0-dev libncurses5-dev iptraf snmp snmpd monit.
Можно поставить драйвера от Игоря Липлианина, они должны лучше работать с картой, ну и якобы производительней. Но поставить их у меня не получилось, дрова откомпилились, но карта так и не определилась в системе.
Считаем, что карты уже стоят внутри сервера:

sudo aptitude install build-essential subversion linux-libc-dev  libssl-dev gettext sysv-rc-conf linux-headers-`uname -r` git-core  mercurial ncurses-dev dvb-apps libxml2-dev dialog libevent-dev  libglib2.0-dev libncurses5-dev iptraf snmp snmpd rrdtool monit

После установки дополнительных пакетов качаем сами драйвера и устанавливаем:

cd /usr/src
wget http://valiant.pp.ua/files/v4l-omicom-s2.tar.bz2
tar -xjvf v4l-omicom-s2.tar.bz2
cd v4l-omicom-s2/
make KERNELRELEASE=$(uname -r)
make KERNELRELEASE=$(uname -r) install

После компиляции перезагружаем машину и проверяем наличие устройства:

zeleniy@streamer:~$ ls /dev/dvb/

adapter0 adapter1 adapter2 adapter3

Отлично карты определились, можно перейти к настройке.
Создадим файл 11389 и пропишем туда следующие настройки:

S 11389000 H 27500000 AUTO

S или S2 — это DVB-S или DVB-S2
11389000 — частота транспондера в KHZ
H — поляризация
27500000 — символьная скорость
AUTO — коррекция ошибок FEC, может быть AUTO, 3/4, 7/8 и так далее.
Создадим еще один пустой файл куда будут записываться каналы и параметры для них:

touch 11389.ch

Пишем в терминале:

scan -a 0 11389 > 11389.ch

Ключ -a 0 указывает на каком адаптере нужно провести сканирование.
После завершения сканирования в файле 11389.ch появятся следующие записи:

Inter:11389:h:0:27500:257:258:1

NTN:11389:h:0:27500:513:514:2

K1:11389:h:0:27500:769:770:3

MEGA:11389:h:0:27500:1025:1026:4

MTV UA:11389:h:0:27500:1281:1282:5

Enter Film:11389:h:0:27500:1537:1538:6

K2:11389:h:0:27500:1793:1794:7

Enter Music:11389:h:0:27500:2049:2050:8

Inter+:11389:h:0:27500:2305:2306:9

Gamma:11389:h:0:27500:2561:2562:10

Hockey:11389:h:0:27500:2817:2818:11

RTR Planeta:11389:h:0:27500:3073:3074:12

Impact TV:11389:h:0:27500:3329:3330:13

Разберем что есть что, по порядку: название канала, частота приема, поляризация, номер адаптера, символьная скорость, video pid, audio pid, sid. Нам нужно знать только название канала и его sid (последняя цифра).
Теперь перейдем к настройке getstream:

cd /tmp/
wget --no-check-certificate https://cesbo.com/hg/getstream_a84/archive/default.tar.gz
tar -zxvf default.tar.gz
cd getstream_a84-default/
./configure
make
install getstream /usr/bin/getstream

Теперь займемся файлом конфигурации getstream. Создадим файл 11389.conf.
С описанием параметров в файле можно познакомиться здесь. Хочу обратить внимание, что не стоит указывать в секции input параметр epg, т.к. во-первых наблюдаются глюки типа не с первого раза запускается просмотр на компьютере или останавливается канал, пока не передернешь. Ну а во вторых толку с епг в таком виде + лишний трафик, гораздо интересней прикрутить программу телепередач в iptv player.
Создадим скрипт /etc/init.d/getstream11389:

#! /bin/sh
#
# Some things that run always
# 
# Carry out specific functions when asked to by the system
case "$1" in
start)
sleep 10
/usr/bin/getstream -c /home/zeleniy/stream/11389.conf -dd > /var/log/getstream11389.log &
echo "Started."
;;
stop)
kill -9 `cat /var/run/getstream11389.pid`
echo "Stopped."
;;
*)
echo "Usage: /etc/init.d/getstream {start|stop}"
exit 1
;;
esac
exit 0

Отмечу что sleep здесь присутствует потому, что карты инициализируются позже, чем запускается скрипт при перезагрузке сервера.
Сделаем его исполняемым и добавим в автозагрузку:

sudo chmod +x /etc/init.d/getstream11389

sudo update-rc.d gestream11389 defaults

Запускаем:

sudo /etc/init.d/getstream11389 start

Iptraf'ом смотрим что пакеты улетают, и пробуем смотреть на компьютере например VLC.
Ну а теперь настроим monit, он отслеживает работу getstream и при падении перезапускает процесс без участия администратора.
В файле /etc/default/monit выставляем параметр startup=1.
В файле /etc/monit/monitrc выставляем параметры:

set daemon 60 # Время проверки процесса в секундах, т.е. через каждую минуту. Можете поставить #сколько угодно

set logfile syslog facility log_daemon #Путь к логу

## Т.к. у меня 4 адаптера и запущено 4 копии getstream, то

####GETSTREAM 10722#########

check process getstream0 with pidfile /var/run/getstream10722.pid

start program = "/etc/init.d/getstream10722 start"

stop program = "/etc/init.d/getstream10722 stop"

####GETSTREAM 10759#########

check process getstream1 with pidfile /var/run/getstream10759.pid

start program = "/etc/init.d/getstream10759 start"

stop program = "/etc/init.d/getstream10759 stop"

####GETSTREAM 10806#########

check process getstream2 with pidfile /var/run/getstream10806.pid

start program = "/etc/init.d/getstream10806 start"

stop program = "/etc/init.d/getstream10806 stop"

####GETSTREAM 11389#########

check process getstream3 with pidfile /var/run/getstream11389.pid

start program = "/etc/init.d/getstream11389 start"

stop program = "/etc/init.d/getstream11389 stop"

Запускаем:
sudo /etc/init.d/monit start

В итоге, если getstream упадет, то monit через минуту его перезапустит и отпишет в syslog
Дополнительно можно мониторить по snmp, что я и делаю рисую график через rrdtool выходного интерфейса, т.к. графики я смотрю чаще, чем логи на сервере.
Итого:

zeleniy@streamer:~$ uptime 

22:58:16 up 54 days, 23:16, 1 user, load average: 1.74, 2.00, 1.98

Ах да чуть не забыл самое главное — проверить уровень сигнала:

zeleniy@streamer:~$ sudo femon -H -a 0

FE: STV090x Multistandard (DVBS)

Problem retrieving frontend information: Operation not supported

status SCVYL | signal 80% | snr 69% | ber 0 | unc 191 | FE_HAS_LOCK

Ну а теперь особо интересная вещь=)

Счастливые обладатели телевизоров Samsung серий B, C и D с функцией Internet@TV и Smarthub могут смотреть IPTV прямо на телевизоре без всяких глюкавых приставок.
Достаточно получить доступ к файловой системе телевизора и установить виджет. Все подробности здесь.
У меня телевизор серии D, поэтому процесс опишу для него, но по телнету я к нему не смог добраться, т.к. телек был прошит последней прошивкой от самсунга, поэтому не рекомендую обновлять ПО в телевизоре. Мне из всех этих виджетов интересен только nStreamPlayer, поэтому я буду устанавливать его отдельно. Но только для этого нужен веб сервер, думаю что у всех найдется=). Есть оригинал виджета и его мод, мне по душе мод, поэтому качаю его. Хотя можно поставить оба одновременно и выбрать для себя, достаточно добавить в widgetlist.xml параметры второго виджета.
Создадим на веб сервере в корне файл widgetlist.xml:


<rsp stat="ok">
  <list>
    <widget id="nStreamLmod">
      <title>nStreamLmodtitle>
      <compression size="20000" type="zip" />
      <description>description>
      <download>http://yourIP/widget/nStreamLmod.zipdownload>
    widget>
<widget id="nStreamPlayer">
      <title>nStreamPlayertitle>
      <compression size="20000" type="zip" />
      <description>description>
      <download>http://yourIP/widget/nStreamPlayer.zipdownload>
    widget>
list>
rsp>

Теперь положим виджеты сюда:

mkdir -p /var/www/widget
cd /var/www/widget
wget http://ru.16mb.com/nStreamLmod.zip
wget http://kartina.pristavka.de/nktvplayer/nStreamPlayer.zip
chmod -R 755 /var/www/widget/

Установить виджет без доступа по telnet получилось следующим образом:

1. Войти в SmartHub.
2. Нажать красную клавишу А, создать учетную запись с именем пользователя develop и любым паролем, залогинится под ним.
3. Нажать синюю клавишу D, зайти в меню Разработка-->Настройка IP-адреса сервера заходим и ставим IP-адрес своего сервера.
4. Клацаем Назад и выбираем Синхронизация приложений пользователя. Ждем пока виджеты установятся.
5. Закрываем все после установки, выходим из Smarthub, снова заходим и видем наши виджеты.
6. Запускаем например Lmod.

Появляется страница с настройками вводим туда:

Плейлист URL — yourIP/channels.xml вводим адрес, где расположен список каналов в формате xml, можно m3u, подойдет от VLC, но тогда не будет доступен телегид.
Прокси для UDP — вводим адрес прокси, если используете udpxy, чтобы не переделывать ссылки из udp в формат udpxy
Коррекция времени — думаю понятно что тут писать
Начальный размер — ставим 0 16х9
Программка Яндекс — пишем ru или ua, кто где
Код региона — 187 для всей Украины
Форма иконки — форма логотипа канала, может быть 0 — квадрат или 1 — авто
Нажимаем Enter и виджет перезагружается с новыми параметрами.

Посмотреть код региона и id канала для программы можно на сайте Яндекса, код будет написан в адресной строке:

http://m.tv.yandex.ua/187/

Теперь чтобы для каждого канала отображался свой логотип и программа, нужно в списке каналов в тегах description указать id канала на сайте Яндекса, например для Интера это 308:

http://m.tv.yandex.ua/187/?channel=308&when=2&day=15420

Кусок из плейлиста:

<channel>
        <title>Интерtitle>
        <stream_url>stream_url>
        <description>308description>
        channel>

Желаю Всем приятного просмотра!

Zentyal — сервер all-in-one для SMB

2012-04-09T01:48:00.000+03:00

Лет 6 назад, в мою бытность сисадмином в одной конторе, мне приходилось обслуживать несколько серверов на FreeBSD — прокси, почтовик, web-сервер, ftp, ipfw, в общем, все как у всех. Работало все на двух физических серверах, и было у меня желание заиметь какую-нибудь универсальную графическую оболочку для удобства управления всем этим хозяйством. Ну и, конечно же, таковой нигде не было. Были попытки разных умельцев создать свои GUI для управления подсистемами по отдельности: один для squid, другой для sendmail и т. д. Конечно, можно было какую-то часть управления выполнять и в webmin, но это не доставляло никакого удовольствия. Как говорили мне — неправильно работать с *nix-системами через GUI. Нет, естественно работа в командной строке не доставляла неудобства, но хотелось чего-то более универсального. В итоге, я написал несколько скриптов, которые вызывали псевдографику на черном экране, где можно было добавлять/удалять правила, рулить пользователями и т. д., на чем как-то все остановилось, хотя интерес к удобству управления через GUI и не пропал.

Выбор и описание системы

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

На этот раз все было гораздо проще — за это время появилось множество систем, позволяющих управлять теми или иными сервисами. Сначала мой выбор, несмотря на не очень благозвучное для русскоязычного человека название, пал на eBox Platform. И хотя продукт на тот момент казался сыроватым, в принципе отвечал всем требованиям заказчика. Затем интерес к теме снова поутих — работа, другие дела и задачи…

И вдруг опять срочно понадобилась «управлялка всего и вся». За прошедшее время eBox переродился в дистрибутив под названием Zentyal, про который кто-то говорил плохо (памятуя баги из eBox), а кто-то не скрывал удовольствия от использования.

Именно о нем я и хотел рассказать. Забегая вперед скажу, что мне дистрибутив понравился!

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

После входа в систему попадаем на страницу выбора пакетов для установки. Что интересно, можно установить готовые наборы или только необходимые пакеты по-отдельности.

Ставить для теста отдельно пакеты неинтересно, поэтому ставим сразу все!

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

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

После настройки сети, необходимо определиться с тем, в каком режиме будет работать сервер — просто выделенный сервер или как slave (при условии, что уже есть первый — master). Смысл затеи сводится к разнесению служб на разные физические хосты. В дальнейшем, при масштабировании к мастер-серверу можно подключать slave-серверы, которые будут выполнять свою роль/роли в общей ферме.

Настройка первичного почтового домена:

Окно подключения «подписки». Очень интересная вещь!

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

Итак, установка и начальная конфигурация прошли успешно…

… и у нас всё готово для дальнейшей пальпации.

Админ-панель

Панель администрирования. Удобно, красиво, ничего не раздражает. Слева меню модулей, по центру виджеты (кстати их можно перетаскивать мышью и расставлять по своему усмотрению). Тут же видно, что система нашла 18 обновлений. Нажав на это уведомление, мы увидим перечень, из которого можно выбрать устанавливаемые компоненты.

Я отметил все и нажал «Сохранить изменения».

Пошла установка апдейтов.

Описание модулей

Кратко пробегусь по модулям. В меню настройки статуса модулей можно выбрать, что именно должно работать, а какой сервис будет выключен. Поскольку DHCP-сервер, как правило, в сети уже существует, то данную службу не трогаем.

Меню бэкапа. Тут тоже все просто и понятно. Расписание-что-куда-откуда-исключения и прочее…

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

Опция DynDNS — опять же все стандартно.

В окно мониторинга строятся красивые разноцветные графики загрузки системы.

Есть где почитать логи.

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

Firewall — здесь все красиво! Через GUI можно настроить практически любое правило. Рисунки на странице не дадут запутаться при выборе.

…может понадобиться опция перенаправления портов.

Интересной возможностью дистрибутива является создание и запуск виртуальных машин — куда же в наше время без виртуализации? Здесь все просто — создаем виртуальную машину, описываем сеть, добавляем диски и стартуем. В качестве CD/DVD можно использовать предварительно скопированные на сервер образы операционных систем.

Настройки SAMBA тоже не сложные — все как обычно.

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

А теперь самое интересное: инструменты групповой работы. Настройки серверной части просты — включаем почту, заводим пользователей, разрешаем/запрещаем пересылку сообщений.

Кроме всего прочего, можно настроить сервер VoIP.

Пользовательский интерфейс

Итак, настройка сервера завершена. Что же получил в свое распоряжение пользователь? Понятно, что есть сетевые шары, сервер VoIP, шлюз работает, прокси пишет логи. Логинимся на адрес, который был указан после настройки GroupWare:

И после входа получаем…

Ничего не напоминает? Правильно, интерфейс MS Outlook. Не знаю, зачем разработчики сделали похожий интерфейс, наверное, для удобства работы конечного пользователя. Заодно вот окно создания сообщения для сравнения:

Календарь тоже очень похож на творение от MS.

Выводы

Ну, вот и все, в общем-то. Обзор получился не очень-то коротким, но в целом можно составить представление о продукте.

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

Для «взрослых» компаний данный продукт вряд ли подойдет, так как там другие деньги крутятся, а вот для уровня small business — очень даже неплохой выбор.

Взято с хабра

Наконец-то вышел Proxmox VE 2.0 final release

2012-04-09T01:24:00.001+03:00

30 марта 2012 года вышел финальный релиз Proxmox VE 2.0. Первая публичная бета вышла 30 сентября 2011 — ровно 6 месяцев шла заточка напильником. RC1 был опубликован 16 февраля 2012.

Proxmox VE (wiki) — система виртуализации с открытым исходным кодом на базе гипервизоров KVM и OpenVZ, основанная на Debian GNU/Linux.

Версия 2.0 довольно радикально отличается от первой ветки.

Начать можно с того, что изменилась лицензия продукта и добавилась возможность покупки платной поддержки. GPL v2 сменил AGPL v3.

Одной из отличительных черт Proxmox VE является простота установки и дружелюбие интерфейса. В версии 2 интерфейс полностью переработан. В новой версии он базируется на ExtJs 4. Некоторые утверждают, что он стал более запутанным и сложным. В любом случае очевидно, что его внешний вид стал намного приятнее. Разработчики подчеркивают высокую скорость работы (полный AJAX) и удобство пользования новым интерфейсом за счет хорошего поиска.

В новой версии также появились возможности для создания отказоустойчивого кластера. Кластер основан на corosync. Используется собственная файловая система для хранения и синхронизации конфигурационных файлов Proxmox Cluster file system (pmxcfs), поддерживается multi-master и централизованное логирование. В новой версии возможен автоматический старт виртуальных машин на новой ноде при отказе старой.

Наконец-то освежена версия Debian, на основе которой работает VE. Теперь это Squeeze. Ядро обновлено до 2.6.32.

В версии 2.0 добавлен RESTful HTTP API. Так же появилась возможность Backup/Restore через веб-интерфейс, в том числе по расписанию. Напомню, что любые действия в системе можно сделать из без GUI, используя стандартные утилиты командной строки OpenVZ, KVM и собственные утилиты Proxmox. Однако, разработчики делают ставку на простоту. Следовательно основным инструментом админа в данном случае считается GUI. И они его реально пилят напильником по-максимуму.

В новой версии добавлена интеграция с TurnKey (сервис готовых шаблонов для OpenVZ) и возможность скачки шаблонов из собственного комплекта. Теперь поддерживается несколько хранилищ для контейнеров OpenVZ и нет необходимости привязываться к /var/lib/vz (мелочь, а очень приятно в некоторых ситуациях). Добавлена поддержка VSwap.

Смотрите также: полный список изменений, видео-уроки, раздел скачки ISO, мануал по обновлению с 1.9.

Добавлю, что в основе Proxmox лежит виртуализация на базе контейнеров Linux OpenVZ. KVM-гипервизор используется в первую очередь для остальных операционных систем. OpenVZ (как и другие контейнерные системы) работают по принципу общего ядра между гостями и хостом. Это накладывает значительные ограничения на гостевые машины (тоже самое ядро, что и на хосте). Поэтому в некоторых ситуациях даже Linux запускают в KVM, а не OpenVZ. Сама Proxmox VE представлет одинаково удобный GUI для работы с обеими платформами.

Использование Proxmox наиболее актуально для тех пользователей, которые не хотят или не могут лезть в дебри OpenVZ и KVM. Система позиционируется как готовая к использованию. И реально так и есть. Отлично подойдет для начинающих.

Из бесплатных аналогов на рынке Open Source можно отметить Citrix XenServer. Он использует совершенно другую схему виртуализации — паравиртуализацию. В этом случае на каждую гостевую машину будет работать свое xen-совместимое ядро, что значительно ослабляет зависимость требований к гостю от хоста. Для виртуализации систем, отличных от Linux, также используется Xen-HVM (базируется на QEMU). У XenServer дефолтовый клиент работает только под Windows, однако есть сторонние реализации, в том числе и web-based.

Выбор в пользу той или иной платформы зависит от ряда факторов. У каждой из них есть свои преимущества и недостатки. Но в любом случае обе платформы являются серьезными игроками на рынке Open Source-виртуализации.

Взято с хабра

Обновляем FreeBSD до версии 9

2012-01-14T00:45:00.000+02:00

Как всем наверно известно – вышла FreeBSD 9.0. И эта заметка об этом замечательном событии – беглый взгляд на изменения – и способ обновления сFreeBSD 8.2 до FreeBSD 9.0 с помощью freebsd-update ( сам делаю а тут пишу ).

Что поменялось :

Спорный новый модульный BSDInstall. т.е теперь он заменил sysinstall – чему я лично не очень рад, но это мелочи. В базовой системе изменен компилятор был GCC теперьClang, новый программный RAID – graid, обновлена версия файловой системы ZFSv28, Soft Updates журналирование для UFS, изменения в TCP стеке для повышения контроля от перегрузки, введен новый механизм изоляции выполнения приложений Capsicum.

Обновляемся :

Ничего нового в статье описано не будет – все это уже рассматривалось при переходе с freeBSD 8.1 до 8.2, но все равно имеет право быть описанным, надеюсь кому-то будет полезно :

Итак обновляем 8.2 релиз до 9.0 с помощью простого и удобного инструмента freebsd-update

freebsd-update -r 9.0-RELEASE upgrade

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

WARNING: This system is running a “a-lan” kernel, which is not a

kernel configuration distributed as part of FreeBSD 8.2-RELEASE.

This kernel will not be updated: you MUST update the kernel manually

before running “/usr/sbin/freebsd-update install”.

WARNING: This system is running a “a-lan” kernel, which is not akernel configuration distributed as part of FreeBSD 8.2-RELEASE.This kernel will not be updated: you MUST update the kernel manuallybefore running “/usr/sbin/freebsd-update install”.

По окончанию пересобираем ядро (только в том случае если оно у вас не generic )

По окончанию shutdown -r now

После запускаем :

freebsd-update install

После завершение перегружаемся.

и снова запускаем

freebsd-update install

результатом будет Done.

Последняя перезагрузка – и все.

удачи ;)

Взято с http://ifreebsd.org/freebsd/%D0%B2%D1%8B%D1%88%D0%BB%D0%B0-freebsd-%D0%B4%D0%BE-9-0-%D0%BE%D0%B1%D0%BD%D0%BE%D0%B2%D0%BB%D1%8F%D0%B5%D0%BC%D1%81%D1%8F/

Установка htop во FreeBSD

2012-01-14T00:42:00.000+02:00

В Ubuntu есть удобная утилита htop, которая визуально более информативна чем штатный top, а также дает возможность совершать больше действий над запущенными процессами.

Во FreeBSD есть порт htop:

> cd /usr/ports/ && make search name=htop
Port:   htop-0.8.3
Path:   /usr/ports/sysutils/htop
Info:   A better top(1) - interactive process viewer
Maint:  yzlin@FreeBSD.org
B-deps: autoconf-2.62 autoconf-wrapper-20071109 automake-1.9.6_3 automake-wrapper-20071109 libtool-2.2.6b m4-1.4.14_1,1 perl-5.10.1_1 python26-2.6.5
R-deps: lsof-4.84A,5
WWW:    http://htop.sourceforge.net/

Но его установка обычно завершается сообщением об ошибке:

cd /usr/ports/*/htop
/usr/ports/sysutils/htop > make install clean
.....
===>  Configuring for htop-0.8.3
***********************************************************
htop(1) requires linprocfs(5) to be mounted. If you don't
have it mounted already, please add this line to /etc/fstab
and run `mount linproc`:
linproc /compat/linux/proc linprocfs rw 0 0
***********************************************************
*** Error code 1
 
Stop in /usr/ports/sysutils/htop.
*** Error code 1

Подключаем модули linux во FreeBSD:
1.

1	`kldload linux`

2. Чтобы загружался постоянно, добавим в /etc/rc.conf

1	`echo` `"linux_enable=YES"` `>>` `/etc/rc.conf.`

3. Установим linux_base-fc4

cd /usr/ports/emulators/linux_base-fc4
make install clean

4. Подключим псевдофайловую систему

1	`echo` `"linproc /compat/linux/proc linprocfs rw 0 0"` `>>` `/etc/fstab`

5. Смонтируем ее

1	`mount` `linproc`

6. И повторим установку htop из портов:

cd /usr/ports/*/htop
make install clean

7. Обновим кеш шелла и запустим htop

1	`rehash && htop`

Теперь вместо стандартного top запускаем разноцветный htop под FreeBSD

Взято с http://www.ubuntix.ru/2010/06/ustanovka-htop-vo-freebsd/

Мониторинг количества активных хостов в сети

2011-06-23T00:23:00.000+03:00

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

Для решения этой задачи я использовал замечательную утилиту arping.

Arping работает на втором уровне модели OSI и не блокируется файрволом, т.к. компьютер должен отвечать на ARP-запросы, чтобы до него доходили IP-пакеты. Минусом arping по сравнению с ping является то, что arping работает в пределах одной локальной сети и не маршрутизируется. Однако это ограничение можно обойти с помощью проксирования ARP.

Для начала я написал простенький скрипт на PHP (это единственный язык, который я знаю ☺), использующий arping. Задаются сети и маски, и скрипт в цикле пингует каждый IP-адрес в них:

//задаем сети и маски
$subnets = array("192.168.0.0/255.255.255.0", "10.10.8.0/255.255.252.0");

$up = 0; //количество живых хостов
foreach($subnets as $subnet)
{
list($addr, $mask) = explode('/', $subnet);
//вычисляем начальный и конечный адрес
$start = (ip2long($addr) & ip2long($mask)) + 1;
$end = $start + (~ ip2long($mask)) - 1;
//пробегаем все адреса и арпингуем их
for($ip = $start; $ip <= $end; $ip++)
{
$response = shell_exec("arping -c 2 " . long2ip($ip));
if(!strstr($response, '0 packets received')) $up++;
}
}
echo $up . "\r\n";
?>

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

В итоге я переписал скрипт так:

Настройки и адреса сетей считываются из ini-файла.
«Папа»-скрипт запускает экземпляр дочернего скрипта для каждой сети и контролирует его работу.
Дочерний скрипт проверяет все адреса своей сети по кругу и обновляет информацию в Memcached. Помимо количества активных узлов запоминается их mac, dns и netbios имя.
Из memcached эти данные можно посмотреть на веб-странице или в zabbix.

Можно посмотреть список компьютеров в аскетичном веб-интерфейсе:

Также я добавил график в Zabbix (см. начало поста).
Для этого необходимо дописать в файл zabbix_agentd.conf строчку для каждой сети:
UserParameter=network_count.net_name,/usr/local/bin/php /путь до скрипта/get_network_stats.php net_name
На сервере добавить соответствующие item'ы.

И настроить график.
Скрипт get_network_stats.php <имя_сети> выдает количество активных хостов по имени сети. Я думаю, пользователи других систем мониторинга смогут без труда прикрутить к ним этот скрипт.

Исходник приводить не буду, т.к. он большой. Скачайте его — readme прилагается.
Я думаю, кому нужна такая штука, может переписать его под свои нужды: например, можно использовать вместо memcached обычный файл.

Взято http://habrahabr.ru/blogs/sysadm/119112/

LVM — это просто!

2011-04-12T13:43:00.000+03:00

Собственно, хочется просто и доступно рассказать про такую замечательную вещь как Logical Volume Management или Управление Логическими Томами.Поскольку уже давно пользуюсь LVM-ом, расскажу что он значит именно для меня, не подглядывая в мануалы и не выдёргивая цитаты из wiki, своими словами, чтобы было понятно именно тем кто ничего о нем не знает. Постараюсь сразу не рассказывать о всяческих «продвинутых» функциях типа страйпов, снапшотов и т.п.

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

есть 3 уровня абстракции:
1. PV (Physical Volume) — физические тома (это могут быть разделы или целые «неразбитые» диски)
2. VG (Volume Group) — группа томов (объединяем физические тома (PV) в группу, создаём единый диск, который будем дальше разбивать так, как нам хочется)
3. LV (Logical Volume) — логические разделы, собственно раздел нашего нового «единого диска» ака Группы Томов, который мы потом форматируем и используем как обычный раздел, обычного жёсткого диска.
это пожалуй вся теория. :) теперь практика:
для работы нужны пакеты lvm2 и возможность работать с привелегиями root поэтому:
$ sudo bash
# apt-get install lvm2

допустим у нас в компе есть жёсткий диск на 40Гб и нам удалось наскрести немного денег и наконец-то купить себе ТЕРАБАЙТНИК! :))) Система уже стоит и работает, и первый диск разбит одним разделом (/dev/sda1 как / ), второй — самый большой, который мы только подключили — вообще не разбит /dev/sdb…
Предлагаю немножко разгрузить корневой диск, а заодно ускорить (новый диск работает быстрее старого) и «обезопасить» систему с помощью lvm.
Можно делать на втором диске разделы и добавлять их в группы томов (если нам нужно несколько групп томов),
а можно вообще не делать на диске разделы и всё устройство сделать физическим разделом (PV)

root@ws:~# pvcreate /dev/sdb
Physical volume "/dev/sdb" successfully created

Создаём группу томов с говорящим названием, например по имени машины «ws», чтобы когда мы перетащим данный диск на другую машину небыло конфликтов с именами групп томов:

root@ws:~# vgcreate ws /dev/sdb
Volume group «vg0» successfully created

желательно внести с корневого раздела такие папки как /usr /var /tmp /home, чтобы не дефрагментировать лишний раз корневой раздел и ни в коем случае его не переполнить, поэтому создаём разделы:

root@ws:~# lvcreate -n usr -L10G ws # здесь мы создаём раздел с именем «usr», размером 10Gb
Logical volume «usr» created
по аналогии делаем то же для /var, /tmp, /home:
root@ws:~# lvcreate -n var -L10G ws
root@ws:~# lvcreate -n tmp -L2G ws
root@ws:~# lvcreate -n home -L500G ws
у нас ещё осталось немного свободного места в группе томов (например для будущего раздела под бэкап)
посмотреть сколько именно можно командой:
root@ws:~# vgdisplay
информацию по созданным логическим томам
root@ws:~# lvdisplay
информацию по физическим томам
root@ws:~# pvdisplay

разделы что мы создали появятся в папке /dev/[имя_vg]/, точнее там будут ссылки на файлы,
lrwxrwxrwx 1 root root 22 2009-08-10 18:35 swap -> /dev/mapper/ws-swap
lrwxrwxrwx 1 root root 21 2009-08-10 18:35 tmp -> /dev/mapper/ws-tmp
lrwxrwxrwx 1 root root 21 2009-08-10 18:35 usr -> /dev/mapper/ws-usr
lrwxrwxrwx 1 root root 21 2009-08-10 18:35 var -> /dev/mapper/ws-var
и т.д…

дальше lvm уже почти кончается… форматируем наши разделы в любимые файловые системы:
root@ws:~# mkfs.ext2 -L tmp /dev/ws/tmp
root@ws:~# mkfs.ext4 -L usr /dev/ws/usr
root@ws:~# mkfs.ext4 -L var /dev/ws/var
root@ws:~# mkfs.ext4 -L home /dev/ws/home

кстати, не плохо было бы сделать раздел подкачки:
root@ws:~# lvcreate -n swap -L2G ws
root@ws:~# mkswap -L swap /dev/ws/swap
root@ws:~# swapon /dev/ws/swap

создаём папку и подключая по очереди новообразовавшиеся тома, копируем в них нужное содержимое:
root@ws:~# mkdir /mnt/target
root@ws:~# mount /dev/ws/home /mnt/target
копируем туда всё из папки /home своим любимым файловым менеджером (с сохранением прав доступа), например так ;):
root@ws:~# cp -a /home/* /mnt/target/
root@ws:~# umount /mnt/target/
кстати, для папки temp необходимо только поправить права, копировать туда что-либо необязательно:
root@ws:~# mount /dev/ws/tmp /mnt/target && chmod -R a+rwx /mnt/target && umount /mnt/target/
добавляем нужные строчки в /etc/fstab, например такие:
/dev/mapper/ws-home /home ext4 relatime 0 2
/dev/mapper/ws-tmp /tmp ext2 noatime 0 2
/dev/mapper/ws-swap none swap sw 0 0
и перезагружаемся… (продвинутые господа могут обойтись без перезагрузки ;))

На вкусное, хочу предложить более продвинутую штуку:
допустим у нас есть система с разделом на LVM, а жёсткий диск начал сбоить, тогда мы можем без перезагрузки переместить всю систему на другой жёсткий диск/раздел:

# On-line добавление/удаление жёстких дисков с помощью LVM (пример)

root@ws:~# pvcreate /dev/sda1 # наш эмулятор сбойного диска
Physical volume "/dev/sda1" successfully created

root@ws:~# pvcreate /dev/sdb1 # наш эмулятор спасательного диска
Physical volume "/dev/sdb1" successfully created

root@ws:~# vgcreate vg0 /dev/sda1 # создаю группу томов vg0
Volume group «vg0» successfully created

root@ws:~# lvcreate -n test -L10G vg0 #создаю раздел для «важной» инфы
Logical volume «test» created

root@ws:~# mkfs.ext2 /dev/vg0/test # создаю файловую систему на разделе
root@ws:~# mount /dev/mapper/vg0-test /mnt/tmp/ #монтирую раздел
… # заполняю его информацией, открываю на нем несколько файлов и т.п.

root@ws:~# vgextend vg0 /dev/sdb1 # расширяю нашу групу томов на «спасательный» диск
Volume group «vg0» successfully extended

root@work:~# pvmove /dev/sda1 /dev/sdb1 #передвигаю содержимое с «умирающего» диска на «спасательный»
/dev/sda1: Moved: 0.9%
/dev/sda1: Moved: 1.8%
…
/dev/sda1: Moved: 99.7%
/dev/sda1: Moved: 100.0%

root@work:~# vgreduce vg0 /dev/sda1 # убираю «умирающий» диск из группы томов.
Removed "/dev/sda1" from volume group «vg0»

Итого:
Я создал логический раздел, отформатировал его, примонтировал и заполнил нужными данными, затем переместил его с одного устройства на другое, при этом раздел остался примонтирован и данные всё время оставались доступны!
Подобным образом мне удавалось без перезагрузки перенести всю систему с умирающего диска на рэид-массив. :)

А это моя любимая ссылка по LVM: xgu.ru/wiki/LVM

P.S. Ах, да!!! Самое главное и самый большой минус LVM — он не читается grub'ом
поэтому раздел /boot должен находиться вне LVM на отдельном разделе жёсткого диска,
иначе система не загрузится.

Взято с http://habrahabr.ru/blogs/linux/67283/

Активируем отключенный VT-x

2011-02-07T23:35:00.001+02:00

Написал однажды мне друг с ноутбуком Samsung r60. Процессор в этом ноутбуке поддерживает аппаратную виртуализацию, но по умолчанию она отключена, и пункт включения в биосе отсутствует. Биос — Phoenix. Мы не будем патчить биос, мы будем патчить NVRAM!

Нам понадобятся:
• Samsung's FW Modules Extractor
• Phoenix BIOS Editor
• SYMCMOS — читалка/писалка cmos
• NDISASM — дизассемблер x86 кода
• Загрузочная флешка/дискета с DOS

Ну что ж, приступим!
Качаем прошивку с сайта Samsung. Прошивка идет одним .exe файлом вместе с прошивальщиком, нужно достать сам файл прошивки. Для этого воспользуемся Samsung's FW Modules Extractor

Не все файлы распаковались, но это не важно.

Открываем прошивку в Phoenix BIOS Editor, сворачиваем его и достаем файлы BIOSCOD*.ROM из папки TEMP Phoenix BIOS Editor'а. Он распаковал нашу прошивку. Копируем файлы в другую папку, закрываем Phoenix BIOS Editor.

Начинается самое интересное. Дизассемблируем файлы из прошивки, в моем случае их было 7 (0-6):
$ for i in {0..6}; do ndisasm -a -p intel -b 16 BIOSCOD0$i.ROM > BIOSCOD0$i.dasm; done

Путем гугления выяснилось, что искать нужно команду mov ecx,0x3a:

$ grep 'mov ecx,0x3a' *.dasm

BIOSCOD04.dasm:0000BE99  66B93A000000 mov ecx,0x3a

Отлично, команда найдена в файле BIOSCOD04.dasm!

0000BE99 66B93A000000 mov ecx,0x3a

0000BE9F 0F32  rdmsr

0000BEA1 668BD8 mov ebx,eax

0000BEA4 83E305 and bx,byte  +0x5

0000BEA7 B86F06 mov ax,0x66f

0000BEAA 9A355400F0 call word  0xf000:0x5435

0000BEAF C1E002 shl ax,0x2

0000BEB2 40 inc ax

0000BEB3  38D8 cmp al,bl

0000BEB5 7432 jz 0xbee9

Из кода видно, что в регистр ax записывается значение по адресу 0x66f, выполняются сравнения между al и bl, и если оба значения совпадают — прыгаем на адрес 0xbee9 — адрес отключения виртуализации.

Пришло время SYMCMOS. Создаем загрузочную флешку/дискету, записываем программу на носитель, загружаемся и выполняем
symcmos -v2 -lNVRAM.TXT
Теперь у нас есть файл nvram.txt примерного содержания:

( SYMBOLIC CMOS EDITOR - Version 643710-035 )



CRC =  350F

(0015) [0000]

(0018) [0001]

(001B) [0001]

(0021)  [0000]

(0024) [0001]

(0027) [0001]

(002A) [0000]

(002D)  [0001]

(0030) [0000]

(0036) [0000]

(0039) [0000]

(003F)  [0001]

(0042) [0000]

...

(066F) [0000]

(0672)  [0000]

(0675) [0000]

(0678) [0002]

(067B) [0000]

(067E)  [0000]

(0681) [0002]

Видно, что значение параметра, отвечающего за виртуализацию, установлено в 0. Изменим его прямо в этом файле:
(066F) [0001]
Опять загрузимся в DOS и выполним:
symcmos -v2 -uNVRAM.TXT

Перезагружаемся. Та-дам! Аппаратная виртуализация активирована!

Интересные ссылки:
http://tjworld.net/wiki/Sony/Vaio/FE41Z/HackingBiosNvram — программа для активации VT-x без прошивки CMOS для linux
http://forum.notebookreview.com/acer/465936-acer-laptop-phoenix-bios-enable-virtualization-test-machine-acer-aspire-9420-a.html — С чего все начиналось

Взято с http://habrahabr.ru/blogs/DIY/113223/

MySQL: Slave could not parse relay log event entry

2011-01-08T01:57:00.001+02:00

При использованиии MySQL Master-Slave (или же Master-Master) репликации бывает ситуация что по разным причинам версия слейва ниже чем версия мастера.
Если при этом используется опция binlog_format=MIXED, в результате возможна ситуация когда мастер запишет в свой binlog запись вида:
BINLOG 'XMawShMEAAAARwAAAEp5UwUAAGkAAAAAAAAACHNhblahblahblah'
Которую слейв не сможет выполнить, ибо он ее попросту “еще не умеет”.
Первой ласточкой того, что это произошло станет сообщение “SLAVE DOWN” от мониторинговой системы и запись в MySQL-логе слейва сродни этой:

090917 14:55:51 [ERROR] Error in Log_event::read_log_event(): 'Found invalid event in binary log', data_len: 71, event_type: 19

090917 14:55:51 [ERROR] Error reading relay log event: slave SQL thread aborted because of I/O error

090917 14:55:51 [ERROR] Slave: Could not parse relay log event entry.  The possible reasons are: the master's binary log is corrupted (you can  check this by running 'mysqlbinlog' o

n the binary log), the slave's relay log is corrupted (you can check  this by running 'mysqlbinlog' on the relay log), a network problem, or a  bug in the master's or slave's MySQL

code. If you want to check the master's binary log or slave's relay log,  you will be able to know their names by issuing 'SHOW SLAVE STATUS' on  this slave. Error_code: 0

090917 14:55:51 [ERROR] Error running query, slave SQL thread aborted.  Fix the problem, and restart the slave SQL thread with "SLAVE START". We  stopped at log 'bin-us1.000022' position 17007149

Попытки пропустить неугодные записи старым добрым методом:

slave stop;

set global sql_slave_skip_counter=1;

slave start;

в данном случае не помогают.
Как вариант решения предлагаю:

Останавливаем slave: “SLAVE STOP;”
“Выуживаем” из текста ошибки имя бинлога и позицию, на которой произошла ошибка.
В данном случае это bin-us1.000022 и позиция 17007149
На мастере выполняем запрос “FLUSH LOGS;”
Делаем дамп бинлога начиная с найденной позиции:
mysqlbinlog --start-position=17007149 bin-us1.000022 > bin-us1-from17007149.sql
Загружаем полученный дамп на слейве с ключем “–force”
mysql --force -uuser -ppassword database < bin-us1-from17007149.sql
Выполняем на слейве “FLUSH LOGS;”
В data-директории находим relay-log с максимальным номером и размером около 100 байт (в моем случае это mysqld-relay-bin.000037)
В той же директории в файле relay-log.info
первую строку заменяем на имя только что найденного relay-log-а, во вторую вписываем 0, в третью – следующий после “испорченного” бинлог, в четвертую – 0
Получится что-то вроде:
/var/lib/mysql/mysqld-relay-bin.000037 0 bin-us1.000023 0
Дальше на слейве выполняем:
CHANGE MASTER TO MASTER_LOG_FILE='bin-us1.000023', MASTER_LOG_POS=0; SLAVE START;
Ну и потом чтоб удостоверится что все “завелось”
SHOW SLAVE STATUS\G

Должно работать.
Подозреваю что пункты 4 и 5 можно обьеденить в один, более простой и элегантный.
Но как это сделать – не гуглил.

Оригинал

RabbitMQ: Введение в AMQP

2010-11-30T02:09:00.000+02:00

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

И вот, в один прекрасный день, собрались инженеры с духом, и разработали AMQP — Advanced Message Queuing Protocol. Этот протокол позволяет не задумываться над тем, где находятся получатели сообщения, сколько их, от кого надо ждать сообщение, когда оно будет доставлено получателю. Кроме этого, AMQP снимает с разработчика ещё многие рутинные задачи и позволяет заниматься непосредственной проблемой, а не обслуживанием процесса разработки.

AMQP имеет три базовых понятия:

Обменник (exchange)
Очередь (queue)
Связь, или маршрут (routing key)

Обмен сообщениями осуществляется в пределах одного обменника (есть ещё цепное связывание, но об этом в другой раз), в котором определены связи, являющиеся своеобразными маршрутами, по которым идут сообщения, попавшие в этот обменник. Каждый маршрут связывает обменник с одной или несколькими очередями. Программное обеспечение, реализующее описанные действия, называют AMQP-сервером. Узлы, помещающие сообщения в обменники и получающие их из очередей, называются AMQP-клиентами. Другими словами, AMQP-сервер предоставляет шину обмена данными, а AMQP-клиенты используют эту шину для обмена сообщениями между собой.
Клиенты могут создавать новые обменники (об их типах поговорим позже) и очереди:

Exchange.Declare  TYPE 
Queue.Declare

Процесс помещения данных на шину называется публикацией. Когда AMQP-клиент публикует сообщение на шину, он задаёт имя обменника и имя связи:

Message.Publish  TO  WITH

До этого момента, один из клиентов должен осуществить связку, указав имя обменника, очереди и маршрут, соответствующий ей:

Queue.Bind  TO  WITH

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

Queue.Subscribe  TO

где — идентификатор процесса. Здесь и далее работа с AMQP будет описываться с точки зрения программирования на Erlang, в реализациях клиентов на других языках сообщения вычитываются из очереди явной инструкцией, либо вешаются коллбэки и подписки как таковой нет. После подписки на очередь, все сообщения, попавшие в неё, будут пересылаться подписанному процессу. Если на одну очередьподписано несколько процессов, сообщения будут распределяться по подписчикам методом round-robin.

Для получения ответа, при отправлении запроса в свойствах сообщения заполняется полеReply-To, содержащее, как правило, очередь приватного типа, на которую подписан только отправитель.

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

Оригинал: http://habrahabr.ru/blogs/erlang/64192/

Два твика для ускорения Cydia и iPhone

2010-11-30T01:06:00.000+02:00

Cydia – отличный менеджер пакетов для iPhone, iPod touch и iPad с джейлбрейком. Но по умолчанию программа работает слишком медленно. Сегодня мы покажем как легко можно ускорить Cydia и любой “яблочный” гаджет с джейлбрейком.

Отключение автоматического обновления Cydia

Автоматическое обновление в Cydia – одна из самых надоедливых функций программы. Cydia настойчиво обновляет базу репозиториев при каждой загрузке, и при большом количестве источников это сильно замедляет старт программы.
Далее инструкция по отключению автоматического обновления репозиториев в Cydia:
Шаг 1: Запустите Cydia и в разделе Search найдите и установите утилиту SBSettings.
Шаг 2: Во вкладке Sources добавьте источник http://repo.modyouri.com/.
Шаг 3: Вернитесь в раздел Search, найдите утилиту “NoCyfresh i4″ (или “NoCyfresh i3″, если у вас iPhone 3G или 3GS) и установите ее.
Шаг 4: Откройте SBSettings (по умолчанию свайп по строке статуса iOS). Включите опцию NoCyfresh.
Шаг 5: Не закрывая SBSettings, нажмите кнопку Respring.
Шаг 6: Теперь Cydia будет открываться очень быстро и зависания со строчкой Refresh Database пропадут. Если вам понадобится обновить репозитории, то сделать это можно вручную. Для этого в Cydia в разделе Changes достаточно нажать Refresh.

Отключение баннеров на уровне iOS

При просмотре любого пакета в Cydia подгружаются различные ссылки, описания, баннеры, логотипы и т.д. Это существенно замедляет работу приложения. В одной из прошлых статей мы рассматривали как отключаются баннеры в Cydia через SSH. Однако твик SBAdBlockToggle избавляет от всех этих сложностей. При этом SBAdBlockToggle блокирует баннеры на уровне операционной системы!
Шаг 1: Если вы уже подключили источник http://repo.modyouri.com/ для первого твика, то запустите Cydia и во вкладке Search найдите и установите утилиту SBAdBlockToggle.
Шаг 2: После Respring в SBSettings появится значок Adblock. Нажмите у удерживайте его до перезагрузки своего iPhone, iPod touch или iPad.
Шаг 3: Теперь, при просмотре любого пакета в Cydia вы заметите разницу в скорости его запуска. Как я уже говорил, SBAdBlockToggle отключает баннерную рекламу на уровне iOS. Другими словами баннеров не будет во всех приложениях, загруженных из Cydia, App Store и даже разработанных Apple, например Safari!

Источник: http://www.macdigger.ru/iphone-ipod/dva-tvika-dlya-uskoreniya-cydia-i-iphone-dzhejlbrejk.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+Macdigger+%28MacDigger.ru%29

Играем с BGP в Quagga

2010-11-30T00:57:00.000+02:00

BGP (англ. Border Gateway Protocol, протокол граничного шлюза) — основной протокол динамической маршрутизации в Интернете. Протокол, о котором можно сказать, что на нем держится весь Интернет. Суть его в том, что каждый маршрутизатор сообщает соседям, какие сети он маршрутизирует. В ответ соседи сообщают ему, какие сети доступны через них, через их соседей и т.д. Имея несколько BGP-линков, появляется возможность выбирать тот линк, через который маршрут до какой-либо сети будет короче и т.д.
Но тема этой заметки не о самом протоколе BGP, а о его свободной реализации — quagga. Следует заметить, что quagga также поддерживает OSPF и RIP, но мы рассмотрим только BGP. Я приведу несколько несложных примеров использования quagga с конфигами и логами.

. . .

Quagga состоит из нескольких демонов:

bgpd, ospfd, ripd – занимаются соответствующими протоколами.
watchquagga – следит за демонами и перезапускает их, если они упали.
zebra – основной демон, занимающийся общением с другими демонами и ядром системы. Именно он прописывает маршруты в системе, получая их от других демонов.

Конфиги лежат в каталоге /etc/quagga/. Запишем минимальный конфиг zebra.conf:

hostname zebra
password 123
enable password 456
log file /var/log/zebra.log

Описание опций (с ними вы столкнетесь при настройке любого демона из пакета quagga):

hostname — имя хоста. Опция служит для удобства, видна в консольном интерфейса.
password — пароль для входа в консоль.
enable password — пароль для выполнения административных задач.

После этого демон zebra можно запустить и больше не трогать, менять его настройки мы не будем. Zebra также позволяет настраивать сетевые интерфейсы, но мы будем это делать стандартными сетевыми утилитами системы.
Каждый демон из пакета quagga по умолчанию слушает определенный порт на 127.0.0.1 (2601 для zebra, 2605 для bgpd) и может управляться при помощи telnet. Интерфейс сделан в стиле Cisco.
Теперь опишу несколько примеров использования BGP.

1. Просто анонсировать одну свою подсеть на один аплинк

Конфиг bgpd (/etc/quagga/bgpd.conf):

hostname test
password 123
enable password 456
log file /var/log/bgpd.log
router bgp 12002
 bgp router-id 1.2.3.42
 network 11.22.33.44.0/23
 neighbor 1.2.3.41 remote-as 12001

Описание опций:
router bgp 12002 – указываем, что bgp вообще должен работать; указываем номер нашей AS – 12002.
bgp router-id 1.2.3.42 – тут должен быть указан IP нашего роутера. На самом деле особого значения не имеет, можно указать любой IP. Однако виден вашим соседям, так что стоит указать основной IP роутера.
network 11.22.33.44.0/23 – сеть, которую мы будем анонсировать соседям. Таких записей может быть несколько.
neighbor 1.2.3.41 remote-as 12001 – описание соседа. 1.2.3.41 – IP, по которому доступен сосед; 12001 –AS соседа.
Пример связи двух BGP-роутеров приводить думаю смысла нет, перейдем сразу к более сложным примерам.

2. Цепочка из трех роутеров. Первый и последний прямой связи не имеют

Пример использования – связка: ваш аплинк; вы; ваш клиент, имеющий свою AS и подсеть и физический линк с вами. Привожу конфиг и вывод команды sh ip bgp на каждом из трех роутеров. Команда sh ip bgp показывает таблицу маршрутизации, сформированную bgpd. router-id я указывал левые, что, конечно же, не является хорошим примером.

hostname bgpd1
password 123
enable password 456
router bgp 12101
 bgp router-id 172.16.1.1
 network 192.168.12.0/24
 neighbor 172.18.0.2 remote-as 12102

bgpd1> sh ip bgp
BGP table version is 0, local router ID is 172.16.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, R Removed
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 192.168.12.0     0.0.0.0                  0         32768 i
*> 192.168.13.0     172.18.0.2               0             0 12102 i
*> 192.168.14.0     172.18.0.2                             0 12102 12103 i

Total number of prefixes 3



hostname bgpd2
password 123
enable password 456
router bgp 12102
 bgp router-id 172.16.2.2
 network 192.168.13.0/24
 neighbor 172.18.0.1 remote-as 12101
 neighbor 172.19.0.2 remote-as 12103

bgpd2> sh ip bgp
BGP table version is 0, local router ID is 172.16.2.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, R Removed
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 192.168.12.0     172.18.0.1               0             0 12101 i
*> 192.168.13.0     0.0.0.0                  0         32768 i
*> 192.168.14.0     172.19.0.2               0             0 12103 i

Total number of prefixes 3



hostname bgpd3
password 123
enable password 456
router bgp 12103
 bgp router-id 172.16.3.3
 network 192.168.14.0/24
 neighbor 172.19.0.1 remote-as 12102

bgpd3> sh ip bgp
BGP table version is 0, local router ID is 172.16.3.3
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, R Removed
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 192.168.12.0     172.19.0.1                             0 12102 12101 i
*> 192.168.13.0     172.19.0.1               0             0 12102 i
*> 192.168.14.0     0.0.0.0                  0         32768 i

Total number of prefixes 3

3. Четыре роутера, соединенные ромбиком

Пример использования – у вас два аплинка. А также, в силу того, что пример весьма синтетический, он также демонстрирует отказоустойчивое кольцо: связь между bgpd1 и bgpd4 не потеряется при падении bgpd2 или bgpd3 (но не обоих одновременно).

router bgp 12101
 bgp router-id 172.16.1.1
 network 192.168.12.0/24
 neighbor 172.16.18.2 remote-as 12102
 neighbor 172.16.19.2 remote-as 12103

bgpd1> sh ip bgp
BGP table version is 0, local router ID is 172.16.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, R Removed
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 192.168.12.0     0.0.0.0                  0         32768 i
*  192.168.13.0     172.16.19.2                            0 12103 12104 12102 i
*>                  172.16.18.2              0             0 12102 i
*> 192.168.14.0     172.16.19.2              0             0 12103 i
*  192.168.15.0     172.16.18.2                            0 12102 12104 i
*>                  172.16.19.2                            0 12103 12104 i

Total number of prefixes 4

router bgp 12102
 bgp router-id 172.16.2.2
 network 192.168.13.0/24
 neighbor 172.16.18.1 remote-as 12101
 neighbor 172.16.20.2 remote-as 12104

bgpd2> sh ip bgp
BGP table version is 0, local router ID is 172.16.2.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, R Removed
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 192.168.12.0     172.16.18.1              0             0 12101 i
*> 192.168.13.0     0.0.0.0                  0         32768 i
*  192.168.14.0     172.16.20.2                            0 12104 12103 i
*>                  172.16.18.1                            0 12101 12103 i
*  192.168.15.0     172.16.18.1                            0 12101 12103 12104 i
*>                  172.16.20.2              0             0 12104 i

Total number of prefixes 4

router bgp 12103
 bgp router-id 172.16.3.3
 network 192.168.14.0/24
 neighbor 172.16.19.1 remote-as 12101
 neighbor 172.16.21.2 remote-as 12104

bgpd3> sh ip bgp
BGP table version is 0, local router ID is 172.16.3.3
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, R Removed
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 192.168.12.0     172.16.19.1              0             0 12101 i
*                   172.16.21.2                            0 12104 12102 12101 i
*  192.168.13.0     172.16.19.1                            0 12101 12102 i
*>                  172.16.21.2                            0 12104 12102 i
*> 192.168.14.0     0.0.0.0                  0         32768 i
*> 192.168.15.0     172.16.21.2              0             0 12104 i

Total number of prefixes 4

router bgp 12104
 bgp router-id 172.16.4.4
 network 192.168.15.0/24
 neighbor 172.16.20.1 remote-as 12102
 neighbor 172.16.21.1 remote-as 12103

bgpd4> sh ip bgp
BGP table version is 0, local router ID is 172.16.4.4
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, R Removed
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*  192.168.12.0     172.16.21.1                            0 12103 12101 i
*>                  172.16.20.1                            0 12102 12101 i
*> 192.168.13.0     172.16.20.1              0             0 12102 i
*  192.168.14.0     172.16.20.1                            0 12102 12101 12103 i
*>                  172.16.21.1              0             0 12103 i
*> 192.168.15.0     0.0.0.0                  0         32768 i

Total number of prefixes 4

Эта запись была сделана Ноябрь 27th, 2010 в 15:42:34 от peter и назначена на Linux, Сеть.

1 комментарий

Комментарий от: Andrew A. Sabitov [Посетитель]

Всё карачо, но не рассмотрен самый частый случай: Ваша АС с БГП-раутером + 2-3 аплинка к провайдерам. Всё настроено по варианту 3, всё работает, а потом у одного из провайдеров падает _его_ (единственный!!!) аплинк. Картина маслом...

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

router bgp 25549
bgp router-id 217.70.98.105
network 195.49.168.0/22

!default AS (Electrosvyaz)
neighbor 217.70.98.106 remote-as 16054
neighbor 217.70.98.106 description Sibirtelecom aka Elektrosvyaz
neighbor 217.70.98.106 filter-list 21701 out
neighbor 217.70.98.106 filter-list 21700 in

! ZSTTK AS
neighbor 81.1.255.45 remote-as 21127
neighbor 81.1.255.45 description ZSTTK
neighbor 81.1.255.45 filter-list 8101 out

ip as-path access-list 21701 permit ^$
ip as-path access-list 21701 permit 25549$
ip as-path access-list 21701 deny .*

ip as-path access-list 21700 deny 21127$
ip as-path access-list 21700 deny 20651$
ip as-path access-list 21700 permit .*

ip as-path access-list 8101 permit ^$
ip as-path access-list 8101 permit 25549$
ip as-path access-list 8101 deny .*

Оригинал: http://blog.peter.am/index.php/2010/11/27/bgp-quagga

Linux на службе у провайдера

2010-11-30T00:47:00.000+02:00

Просмотрев большинство тематических постов на хабре был безмерно удивлён тому факту, что крайне скудно освещена тема использования ОС Unix/Linux на службе интернет провайдеров (Internet service provider). Данной статьёй я частично попытаюсь восполнить данный пробел.

Почему в сети интернет наблюдается полное отсутствие таких статей догадаться не сложно — всех кто использует Linux/FreeBSD в ISP сразу же обвиняют в нищебродстве и советуют купить Cisco или уж на совсем крайний случай Juniper. Именно поэтому вторая цель данной статьи показать читателю, что некоторые технические решения на базе ОС Linux по многим показателям на порядки превосходят брэндовые решения от самых известных вендоров.

Шейпинг

Наш первый опыт «нестандартного» использования Linux появился сразу после начала предоставления услуг широкополосного доступа для физических лиц. Необходимо было чем-то «порезать» внешний канал каждого из наших пользователей. Здесь ввиду отсутствия собственных наработок на данную тему пришлось изобретать свой собственный велосипед применяя cbq и собственной обвязки к нему. Данная схема проработала пару месяцев пока мы не осознали всех ее минусов и не упёрлись в производительность машины.

Все дело в том, что система начала «съедать» слишком много soft interrupts даже при не большом трафике, на вскидку при транзитном трафике в 300 мегабит и 30 kpps при 1000 линейных правил cbq (по 2 правила вход/выход на пользователя) на каждом интерфейсе в top si достигал 100%.

Если бы в данный момент перед нами бы встала та же самая задача при тех де самых технических средствах мы бы решали ее с помошью Linux htb tc + хэш фильтры.

NAT

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

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

Для NAT-а было выбрано оборудование Cisco в частности Cisco ASA 5505 — на тот момент ее мощности было достаточно чтобы покрыть потребности наших клиентов.

В то же самое время ВДРУГ появилась информация, что заказанная нами Cisco ASA несколько подзадержится, и собственно встал вопрос чем от NAT-ить 100Мбит/с поток.

«На коленке» был собран тестовый стенд из обычного офисного PC-ка с 2 сетевыми гигабитными адаптерами и выяснилось, что при небольшом тюнинге этот самый обычный «писюк» с самыми обычными реалтеками способен отнатить нужный нам поток.

После замены железа через один из наших NAT серверов в пиках проходило 1800 мбит/с (да, да это не описка, трафик почти 2 гигабита/с) при сравнительно небольшой нагрузке на систему.

NETFLOW

Столкнувшись с проблемой сбора статистики работы домашних пользователей до NAT-а т. е. c «серыми» адресами пришли к простейшей схеме получения статистики NETFLOW.

Собрали схему при которой мы «выгоняем» копию всего трафика пользователей (SPAN PORT) в нужные сетевые порты сервера с ОС Linux на борту, а далее с помощью ipt_NETFLOW формируем поток FLOWS на нужный сервер.

Более подробно вместе с конфигами схема работы приведена здесь.

P.S. Мы в курсе, что большинство оборудования Cisco может лить уже сформированный NETFLOW поток в указанный Netflow коллектор, но в нашей схеме сети на тот момент такого оборудования просто не могло быть :)

Терминация пользовательских сетей.

Изначально хотелось дать пользователю ip адрес, маску подсети, и шлюз и не грузить его настройками PPPoE, PPTP, VPN что в конечном итоге должно было несколько разгрузить службу технической поддержки (что и произошло на практике), так как настройка сети становилась достаточно тривиальной в любой пользовательской ОС.

Решив применить наш предыдущий опыт использования ОС Linux пришли к следующей схеме, в ключевых местах сети устанавливаются Linux сервера с парой четырех-портовых сетевых адаптеров, один линк «уходит» в сторону ядра сети остальные в сторону «кластеров». В результате на каждом интерфейсе поднимается куча VLAN-ов с несколькими сетями в каждом из них.

Всего у нас на всю сеть было 4 сервера примерно по 10k абонентов на каждом.

Пиковый трафик достигаемый каждым сервером в часы пик стремился к полутора мегапакетам в секунду. Сервера обменивались друг с другом маршрутами по протоколу ospf.

Блокирование доступа пользователям осуществлялось с помошью ipset.

Бордер

Тут бы на этой счастливой ноте и закончить, но хочется написать о еще одном «не стандартном» применении Linux — в качестве бордера. Так получилось, что у нас вышла из строя Cisco ASR выполняющая функции бордера на который приходило 2 full view от двух аплинков.

Здесь следует небольшое лирическое отступление. Компания Cisco на 100% сдержала свои обязательства и выслала замену в течении нескольких часов после заполнения необходимых документов, но как Вы понимаете клиенты не будут ждать сутки пока новое железо прилетит в наши края. Решение было спонтанным.

Со склада взяли сервер установили на него Linux + quagga и благополучно поставили вместо вышедшей из строя Cisco.

В час пик это чудо инженерной мысли «прожевало» входящий поток 1.4Гбит/c, при суммарном kpps на всех интерфейсах порядка 400.

P.S. В ходе работы нами было собрано и протестировано множество RPM пакетов для дистрибутива CentOS 5 вот лишь небольшой их список:

ipset
connlimit
conntrack-tools
ipt_netflow
flow-tools
quagga

Cкачать их можно из данного репозитория.

P.P.S. Если у Вас есть свои собственные наработки или заметки по поводу использования *nix like OS на службе ISP, добро пожаловать.

Оригинал: http://habrahabr.ru/blogs/sysadm/106932/

Процесс запуска RabbitMQ на Linux

2010-11-30T00:45:00.000+02:00

Вступление

Запуск RabbitMQ сервера при более глубоком рассмотрении выглядит весьма запутанным делом. Почему это так и как все все обстоит на самом деле можно прочитать под катом.

Версия RabbitMQ-Server — 2.1.0
ОС: Fedora

Коротко

Внимательно смотрим на PID'ы процессов. Ниже идет объяснение происходящего:

-bash-3.2# /etc/init.d/rabbitmq-server start
root  7732  3834  0 11:54 pts/0    00:00:00 /bin/sh /etc/init.d/rabbitmq-server start
root      7733  7732  0 11:54 pts/0    00:00:00 /bin/sh /usr/sbin/rabbitmq-multi start_all 1
root      7740  7733  0 11:54 pts/0    00:00:00 su rabbitmq -s /bin/sh -c /usr/lib/rabbitmq/bin/rabbitmq-multi  "start_all" "1"
rabbitmq  7741  7740  7 11:54 ?        00:00:00 /usr/lib64/erlang/erts-5.7.5/bin/beam.smp -- -root /usr/lib64/erlang -progname erl -- -home /var/lib/rabbitmq -- -pa /usr/lib/rabbitmq/lib/rabbitmq_server-  2.1.0/sbin/../ebin -noshell -noinput -hidden -K true -sname rabbitmq_multi7741 -s rabbit_multi -extra start_all 1
rabbitmq  7767  7741  0 11:54 ?        00:00:00 inet_gethost 4
rabbitmq  7768  7767  0 11:54 ?        00:00:00 inet_gethost 4
rabbitmq  7769  7741  0 11:54 ?        00:00:00 /bin/sh /usr/lib/rabbitmq/bin/rabbitmq-server -noinput
rabbitmq  7794  7769  0 11:54 ?        00:00:00 /bin/sh /usr/lib/rabbitmq/bin/rabbitmq-server -noinput
rabbitmq  7795  7794  0 11:54 ?        00:00:00 ps -ef
rabbitmq  7796  7794  0 11:54 ?        00:00:00 grep rabbit
-bash-3.2# echo $$
3834

Подробнее

Из shell (PID = 3834) запускается /etc/init.d/rabbitmq-server start;
В init.d скрипте (PID = 7732) происходит подгрузка (source) конф. файла /etc/sysconfig/rabbitmq;
Из init.d скрипта запускается shell скрипт su rabbitmq -s /bin/sh -c /usr/lib/rabbitmq/bin/rabbitmq-multi «start_all» «1» (PID = 7740); Из него подгужается (source) /usr/lib/rabbitmq/bin/rabbitmq-evn, в котором подгужается /etc/rabbimq/rabbitmq.conf
В /usr/lib/rabbitmq/bin/rabbitmq-multi запускается erlang (PID = 7741) с некоторым набором параметром. Наиболее интересным является -s rabbit_multi. Указывающий функцию, которая будет вызвана вместо start (man erl);
Из запущенного erlang приложения запускается shell скрипт /bin/sh /usr/lib/rabbitmq/bin/rabbitmq-server -noinput (PID = 7769), в котором и происходит запуск самого rabbitmq-server.

Вот код из rabbit_mulri.erl, в котором происходит вызов shell скрипта:

220 run_rabbitmq_server() ->
 221     with_os([{unix, fun run_rabbitmq_server_unix/0},
 222              {win32, fun run_rabbitmq_server_win32/0}]).
 223
 224 run_rabbitmq_server_unix() ->
 225     CmdLine = getenv("RABBITMQ_script_HOME") ++ "/rabbitmq-server -noinput",
 226     erlang:open_port({spawn, CmdLine}, [nouse_stdio]).
 227 
 228 run_rabbitmq_server_win32() ->
 229     Cmd = filename:nativename(os:find_executable("cmd")),
 230     CmdLine = "\"" ++ getenv("RABBITMQ_script_HOME")
 231                                          ++ "\\rabbitmq-server.bat\" -noinput",
 232     erlang:open_port({spawn_executable, Cmd},
 233                      [{arg0, Cmd}, {args, ["/q", "/s", "/c", CmdLine]},
 234                       nouse_stdio, hide]).

Настолько нетривиальный процесс запуска явно делается из-за мультиплатформенности самого приложения.

Переменные окружения

Теперь у нас есть понимание того, как происходит процесс запуска rabbitmq-server, но нет понимая того как на него повлиять. Рассмотрим немного подробнее запуск самих erlang приложений.

Запуск лаунчера (rabbit_multi)

exec erl \
   -pa "${RABBITMQ_HOME}/ebin" \
   -noinput \
   -hidden \
   ${RABBITMQ_MULTI_ERL_ARGS} \
   -sname rabbitmq_multi$$ \
   -s rabbit_multi \
   ${RABBITMQ_MULTI_START_ARGS} \
   -extra "$@"

Запуск сервера

exec erl
${RABBITMQ_EBIN_PATH}
   ${RABBITMQ_START_RABBIT}
   -sname ${RABBITMQ_NODENAME}
   -boot ${RABBITMQ_BOOT_FILE}
   ${RABBITMQ_CONFIG_ARG}
   +W w \
   ${RABBITMQ_SERVER_ERL_ARGS} \
   ${RABBITMQ_LISTEN_ARG} \
   -sasl errlog_type error \
   -kernel error_logger '{file,"'${RABBITMQ_LOGS}'"}' \
   -sasl sasl_error_logger '{file,"'${RABBITMQ_SASL_LOGS}'"}' \
   -os_mon start_cpu_sup true \
   -os_mon start_disksup false \
   -os_mon start_memsup false \
   -mnesia dir "\"${RABBITMQ_MNESIA_DIR}\"" \
   ${RABBITMQ_SERVER_START_ARGS} \
   "$@"

Думаю теперь видно какие переменные окружения влияют на каждый из erlang процессов. Изменять данные параметры рекомендуется в /etc/rabbitmq/rabbitmq.conf, который как мы помним подгружается при запуске /usr/lib/rabbitmq/bin/rabbitmq-multi.Вот так выглядит запущенный сервис с параметрами по-умолчанию:

exec erl -noinput -sname rabbit@hostname -boot /var/lib/rabbitmq/mnesia/rabbit@hostname/plugins-scratch/rabbit \    
   -config /etc/rabbitmq/rabbitmq +W w  +K true +A30 +P 1048576 -kernel inet_default_listen_options [{nodelay,true}] \
   -kernel inet_default_connect_options [{nodelay,true}] \
   -sasl errlog_type error -kernel error_logger '{file,'/var/log/rabbitmq/rabbit@hostname.log'}' \
   -sasl sasl_error_logger '{file,'/var/log/rabbitmq/rabbit@hostname-sasl.log'}' \
   -os_mon start_cpu_sup true -os_mon start_disksup false -os_mon start_memsup false -mnesia dir "/var/lib/rabbitmq/mnesia/rabbit@hostname" -noinput

Итог по конф. файлам

В итоге за работу rabbitmq-server отвечают 3 конф. файла:

/etc/sysconfig/rabbitmq; — В нем принято указывать какие-либо низкоуровневые параметры (например ulimit)
/etc/rabbitmq/rabbitmq.conf; — Настраиваются переменные окружения для запуска erlang
/etc/rabbitmq/rabbitmq.config. — Настраивается сам rabbitmq-server

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

Оригинал: http://habrahabr.ru/blogs/linux/105364/

Еще один способ отбиться от небольшого DDOS

2010-11-30T00:42:00.000+02:00

Все нижеописанное относится к GNU/Linux 2.6.x. ДДОС совершенно тупой, разномастный: syn/tcp/udp/icmp flood тупо на все открытые порты, мегабит на 60. UDP срали вообще куда попало. Но основная атака конечно на HTTP. По этому, тушим сервисы и пишем….

Немного sysctl…

vm.min_free_kbytes=70000

net.core.somaxconn=65536

net.ipv4.tcp_tw_reuse=1

net.ipv4.tcp_tw_recycle=1

net.ipv4.ip_local_port_range = 2000 61000

net.ipv4.tcp_fin_timeout = 25

net.ipv4.tcp_keepalive_time = 600

net.ipv4.tcp_window_scaling = 0

net.ipv4.tcp_timestamps = 0

net.core.rmem_max=16777216

net.core.wmem_max=32777216

net.ipv4.tcp_no_metrics_save=0

net.ipv4.tcp_rmem = 4096 87380 16777216

net.ipv4.tcp_wmem = 4096 187380 32777216

net.core.netdev_max_backlog=16384

net.ipv4.tcp_max_syn_backlog=4096

net.ipv4.ip_conntrack_max=600000

net.ipv4.icmp_echo_ignore_all=1

net.ipv4.netfilter.ip_conntrack_max=500000

net.netfilter.nf_conntrack_max=500000

Не забываем перезапустить Network.

Немного iptables….

# Форвард нам нэ нада

iptables -P FORWARD DROP

# BAN – цепочка для помещения туда айпи хостов, ведущих себя не правильно ) Ну типа
# iptables – I BAN -s 123.123.123.123 -j DROP

iptables -N BAN

# TRUSTED – цепочка для помещения туда правильных хостов и хостов откуда мы сидим в шелле. Типа
# iptables -I TRUSTED -s 111.111.111.111 -j ACCEPT

iptables -N TRUSTED

# Стандартный заголовок, eth1 – наш интерфейс внешний

# если есть еще интерфейсы, надо их тоже запрячь правилами разрешения как у lo

iptables -A INPUT -i lo -j ACCEPT

iptables -A INPUT -i eth1 -m state –state ESTABLISHED -j ACCEPT

iptables -A INPUT -i eth1 -m state –state RELATED -j ACCEPT

# Проход по белым и черным цепочкам

iptables -A INPUT -i eth1 -j TRUSTED

iptables -A INPUT -i eth1 -j BAN

# У меня висит только сервис http, по этому здесь такая себе мини защита по данному порту

# Насчет –seconds 10 –hitcount 10, курим маны, экспериментируем, ставим то, что подойдет.

# Режем всех TCP на порту 80, которые за последние 10 секунд сделали 10 попыток открыть соединение

# (кому то может не подойти!)

iptables -A INPUT -p tcp -m tcp –dport 80 -m state –state NEW -m recent –update –seconds 10 –hitcount 10 –name httpd –rsource -j DROP

# А остальных разрешаем

iptables -A INPUT -i eth1 -p tcp -m tcp –dport 80 -j ACCEPT

# Вот по этой теме ддосеры тоже затрахали, по этому был категоричен

iptables -A OUTPUT -p udp -j DROP

iptables -A OUTPUT -p icmp -j DROP

# Здесь добавить разрешения на прочие порты, у меня прочих не было

# …

# Здесь добавить (!!!) свои айпи, с которых сидишь в шелле

iptables -A TRUSTED -s 111.111.111.111 -j ACCEPT

# Хорошо подумаем, покурим, затаим дыхание и напишем….

iptables -P INPUT DROP

# Что означает зарезать все, что не разрешили на INPUT’е

А теперь запускаем nginx/httpd и прочую лабуду. Надеюсь заработает. У меня заработало, как будто ничего и не происходило

Оригинал: http://www.pentarh.com/wp/2010/08/11/%d0%95%d1%89%d0%b5-%d0%be%d0%b4%d0%b8%d0%bd-%d1%81%d0%bf%d0%be%d1%81%d0%be%d0%b1-%d0%be%d1%82%d0%b1%d0%b8%d1%82%d1%8c%d1%81%d1%8f-%d0%be%d1%82-%d0%bd%d0%b5%d0%b1%d0%be%d0%bb%d1%8c%d1%88%d0%be%d0%b3/

Отбил небольшой DDOS ;)

2010-11-30T00:39:00.000+02:00

DDOS на HTTP 20 Мбит входящего. Отбито софтварным костылем
Конфигурация машины: Quad Core Xeon / 4G RAM, CentOS 5.3 x86_64
Сервисы: apache(back) + nginx(front)
Sysctl:

kernel.shmall = 4294967296
vm.min_free_kbytes=70000
net.core.somaxconn=65536
net.ipv4.tcp_tw_reuse=1
net.ipv4.tcp_tw_recycle=1
net.ipv4.ip_local_port_range = 2000 61000
net.ipv4.tcp_fin_timeout = 25
net.ipv4.tcp_keepalive_time = 600
net.ipv4.tcp_window_scaling = 0
net.ipv4.tcp_timestamps = 0
net.core.rmem_max=8388608
net.core.wmem_max=16777216
net.ipv4.tcp_no_metrics_save=0
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 87380 16777216
net.core.netdev_max_backlog=65536
net.ipv4.tcp_max_syn_backlog=4096
net.ipv4.ip_conntrack_max=300000

nginx:

worker_rlimit_nofile 80000;
events {
worker_connections 65536;
use epoll;
}

http {
gzip off; #
keepalive_timeout 0;
server_tokens off;
reset_timedout_connection on;

server {
listen x.x.x.x default deferred;
log_format IP $remote_addr;
location / {
proxy_pass http://127.0.0.1/;
….
access_log /var/log/nginx/ipban IP;
apache: ServerLimit и MaxClients установить так, чтобы не засрало более чем 80% памяти. (В top’е можно глянуть сколько памяти потребляет каждый процесс).
Собсно скрипт. Запускается по крону раз в минуту и банит нах айпи, которые за эту минуту обратились к скриптовой части более 20 раз.

#!/usr/bin/perl

system(‘mv /var/log/nginx/ipban /var/log/nginx/ipban.proc’);
system(‘touch /var/log/nginx/ipban’);
system(«/etc/init.d/nginx reload»);
open $f,’/var/log/nginx/ipban.proc’;
%h=();
while(<$f>) {
chomp;
if (/\d+\.\d+\.\d+\.\d+/) {
unless ($h{$_}) {
$h{$_}=1;
} else {
$h{$_}++;
}
}
}
close $f;
foreach $k (keys(%h)) {
if ($h{$k} > 20) {
system(«iptables -I INPUT -s $k -j DROP»);
print «$k banned\n»;
}
}
20 -число вычисленное в ходе проб и ошибок применительно к этому серверу и location’у nginx. После того как скрипт беспощадно побанил 2к хостов, сервер начал подавать внешние признаки жизни, после 3к забаненых зомби начала грузицца морда.
В процессе работы мой рабочий комп был дважды забанен в ходе экспериментов ))
Более серъезный DDOS конечно будет трудно отбивать тупой банилкой.
АПДЕЙТ. Время шло, таблица бана росла, ддосеры не унимались.
Поставил вот эту хрень http://www.configserver.com/cp/csf.html
Софтина умеет вообще много чего. Но практически все что она умеет бесполезно. Кроме temporary ban ip address.
В конфигах отключил практически все, ибо оно (все) мешало. Мне надо было от этой проги только то, чтобы она банила айпи с TTL. Т.е. на время. И крон стал пускать раз в 5 минут.
Соответственно, в кроновом скрипте поменял

if ($h{$k} > 20) {
system(«iptables -I INPUT -s $k -j DROP»);

На

if ($h{$k} > 60) {
system(«/usr/sbin/csf –tempdeny $k 28800″);

Так же цель атаки – страницу, сделал статичной. ДДОС просел, сайт ожил.

Оригинал http://www.pentarh.com/wp/2009/05/02/%d0%9e%d1%82%d0%b1%d0%b8%d0%bb-%d0%bd%d0%b5%d0%b1%d0%be%d0%bb%d1%8c%d1%88%d0%be%d0%b9-ddos/

IPoE, а также Client-VLAN и DHCP Option 82

2010-11-26T00:23:00.000+02:00

В этой статье я опишу что из себя представляет технология доступа в Интернет IPoE, которой на самом деле не существует. А также расскажу про схему Client-VLAN и про опцию 82 DHCP (DHCP Option 82), которые стали неотъемлемой частью этой несуществующей технологии. Все это, конечно же, с технической точки зрения и с примерами конфигов.

Существует множество технологий доступа в Интернет для конечных абонентов. В России особенно популярны две: PPTP и PPPoE. В обоих случаях создается PPP-туннель, производится аутентификация, и внутри туннеля ходит абонентский IP-трафик. Основное отличие этих протоколов – они работают на разных уровнях сетевой модели OSI. PPPoE работает на втором (канальном) уровне, добавляя специальные теги, идентифицирующие конкретный туннель, в Ethernet-фреймы. PPTP работает на третьем (сетевом) уровне, упаковывая IP-пакеты в GRE.

IPoE

IPoE принципиально отличается от PPTP и PPPoE. Вообще этой технологии не существует. Нет RFC, нет никаких стандартов ее описывающих. Сам термин придуман, скорее всего, в России и является абстрактным. Означает он следующее: IP over Ethernet. Смысл именно такой, как и расшифровка – IP-трафик поверх Ethernet, грубо говоря, обычная локалка. Абоненту выдается в лучшем случае статический или динамический белый IP-адрес, в худшем случае серый IP с NAT. Контроль доступа в данном случае может осуществляется при помощи привязок IP-MAC на коммутаторах доступа или на BRAS или выделения VLAN на каждого абонента (так называемый Client-VLAN).

Client-VLAN

При использовании технологии Client-VLAN возникает проблема: как сэкономить IP-адреса? Ведь, если подумать, каждому клиенту надо выделять /30 подсеть. На самом деле проблема легко решаема. Привожу пример для маршрутизатора на базе Linux:

ip route add unreachable 192.0.2.0/24
ip addr add 192.0.2.1/32 dev lo

vconfig add eth0 101
ip link set eth0.101 up
ip route add 192.0.2.101/32 dev eth0.101 src 192.0.2.1

Подсеть 192.0.2.0/24 рекомендована IANA для использования в примерах.

Это классический Cisco'вский ip unnumbered в Linux'овой реализации. IP шлюза (192.0.2.1) вешается на loopback-интерфейс, делается unreachable для всей подсети, чтобы пакеты ходили только на хосты, для которых прописан роутинг. Далее поднимается VLAN и прописывается роутинг на конкретный хост (маска /32) с src шлюза. А можно сделать немного иначе (это лишний раз демонстрирует гибкость Linux):

ip route add unreachable 192.0.2.0/24

vconfig add eth0 101
ip link set eth0.101 up
ip addr add 192.0.2.1/32 dev eth0.101
ip route add 192.0.2.101/32 dev eth0.101

Или так:

ip route add unreachable 192.0.2.0/24

vconfig add eth0 101
ip link set eth0.101 up
ip addr add 192.0.2.1/24 dev eth0.101
ip route del 192.0.2.0/24 dev eth0.101
ip route add 192.0.2.101/32 dev eth0.101

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

Proxy_arp

Еще одна проблема, с которой вы можете столкнуться – нет связи между абонентами в разных VLAN и с IP из одной подсети. Действительно, система абонента видит, что IP-адрес назначения в одной подсети с ней, и шлет ARP-запросы, чтобы определить MAC, но из этого ничего не выходит, т.к. они в разных VLAN. Для решения этой проблемы служит технология proxy_arp. Суть ее в том, что маршрутизатор при получении ARP-запросов с интерфейса будет проверять есть ли у него запрашиваемый IP на других интерфейсах. Если есть, то в ответ на ARP-запрос выдаст свой MAC. Таким образом, пакеты будут отправляться на маршрутизатор, который позаботится об их доставке. Включается proxy_arp для конкретного интерфейса следующим образом:

sysctl net.ipv4.conf.eth0/101.proxy_arp=1

или

echo 1 > /proc/sys/net/ipv4/conf/eth0.101/proxy_arp

DHCP Option 82

При использовании IPoE DHCP упростит настройку сети на стороне абонента до нуля. Воткнул патчкорд и ты в сети. Только возникает вопрос: как DHCP узнает кому какой адрес выдавать? Можно определять по MAC, особенно если вы уже используете привязки IP-MAC. Но привязки MAC чреваты частыми звонками в поддержку, т.к. абоненты иногда меняют оборудование. Справиться с этой проблемой поможет расширение протокола DHCP – Option 82. Опция 82 содержит два поля:

Agent Circuit ID – номер порта DHCP-релэя, на который пришел DHCP-запрос.
Agent Remote ID – некий идентификатор самого DHCP-релэя.

В качестве DHCP-релэев при этом обычно выступают коммутаторы доступа, к которым непосредственно подключаются абоненты. В качестве Agent Remote ID обычно используется MAC коммутатора (по умолчанию в D-Link). Опция 82 поддерживается широким диапазоном оборудования, в том числе типичными у российских провайдеров D-Link DES-3526/3028/3200.
На коммутаторах D-Link есть два режима DHCP-релэя: dhcp_relay и dhcp_local_relay. dhcp_relay работает глобально, для всех портов и VLAN, при этом добавляется опция 82 и запрос передается уже не бродкастом, а непосредственно на DHCP-сервер, т.е. это полноценный DHCP-релэй. dhcp_local_relay работает для конкретных VLAN, но запрос по сути не релэится, а в него просто добавляется опция 82.
Базовые настройки dhcp_relay на D-Link'ах:

enable dhcp_relay
config dhcp_relay option_82 state enable
config dhcp_relay add ipif System 192.168.0.1

192.168.0.1 – IP-адрес DHCP-сервера, доступного в управляющем VLAN.
Базовые настройки dhcp_local_relay:

enable dhcp_local_relay
config dhcp_local_relay vlan 101 state enable

И наконец приведу базовый конфиг для ISC's DHCP с комментариями:

# пишем в лог
log(info, "***");
if exists agent.circuit-id {
 # присутствует опция 82
 # пишем в лог выданный IP-адрес, Agent Remote ID, Agent Circuit ID
 log( info,concat("*Leased ",binary-to-ascii(10,8,".",leased-address)," (with opt82)") );
 log( info,concat("*Remote-ID: ",binary-to-ascii(16,8,":",substring(option agent.remote-id,2,6))) );
 log( info,concat("*Port: ",binary-to-ascii(10,8,"",suffix(option agent.circuit-id,1))) );
} else {
 # опции 82 нет
 # пишем в лог выданный IP-адрес
 log( info,concat("*Leased ",binary-to-ascii(10,8,".",leased-address)," (without opt82)") );
}
log(info, "***");


# в данном примере 192.0.2.101/24 - IP абонента, подключенного к коммутатору с MAC 0:c:29:ec:23:64, на порт 1
# MAC-адрес левый, взят с виртуалки VMWare
# 192.168.0.0/24 - подсеть управления коммутаторами, с адресов в этой подсети будут приходить DHCP-запросы
# эти две подсети следует объединить в одну shared-network для корректной работы

shared-network test {

subnet 192.0.2.0 netmask 255.255.255.0 {

 # определяем класс

 class "v101" {

  # определяем условия соответствия классу:
  # Agent Circuit ID = 1, Agent Remote ID = 0:c:29:ec:23:64
  # обратите внимание - ведущие нули в Agent Remote ID не пишутся (т.е. c вместо 0c и т.д.)

  match if (binary-to-ascii(10,8,"",suffix(option agent.circuit-id,1)) = "1") and
   (binary-to-ascii(16,8,":",substring(option agent.remote-id,2,6)) = "0:c:29:ec:23:64");
 }

 # собственно выдаем IP классу

 pool {
  range 192.0.2.101;
  allow members of "v101";
 }
}

subnet 192.168.0.0 netmask 255.255.255.0 {
}

Источник: http://habrahabr.ru/blogs/sysadm/108453/

Шейпирование трафика в Linux. Часть 2

2010-11-26T00:21:00.002+02:00

Вторая часть статьи об управлении трафиком в Linux. В статье приведены примеры приоретизации трафика (QoS) и рассказано об использовании hash таблиц при фильтрации трафика (fast hash tables), использование которых позволяет существенно увеличить производительность.
В первой части мы остановились на генерации конфигов средней сложность для htbinit. Сегодня мы поговорим о приоретизации трафика и использовании хэш таблиц в фильтрах. Я подразумеваю, что Вы прочитали первую часть статьи .
Предположим, что нам надоели замечания пользователей о высоком пинге, надоели постоянные детские вопли на форуме о том, что в counter-strike играть невозможно: «лаги страшные», или «у меня странички медленно грузятся, вконтакте открывался 10 минут», а писать что все замеры нужно производить при отключенном «торренте» уже нету сил.
Посему тто бы наша совесть была чиста, и мы могли не кривя душой сказать: «проблема на стороне провайдера предоставляющего данный сервис»~~(обозначить направление движения в сторону южного полюса)~~ — озаботимся приоретизацией трафика.

Приоритеты выставим в таком порядке:
1. icmp
2. udp
3. tcp port 80
4. bulk traffic

Рассмотрим ограничение полосы на внутреннем интерфейсе, управлять будем «скоростью скачивания».
Напомню.
В простом варианте изложения алгоритм нарезки трафика выглядит так:
1. Создаем корневую дисциплину для интерфейса и указываем класс куда будет попадать не классифицированный трафик.
2. Создаем корневой класс и определяем ширину канала.
3. Создаем дочерний класс для шейпирования абонента.
4. Создаем дисциплину шейпирования для класса абонента.
5. Создаем фильтра позволяющие классифицировать трафик абонента.

Пример

#!/bin/bash #"Очищаем" интерфейс eht1 /sbin/tc qdisc del dev eth1 root handle 1: htb default 15 #Создаем заново дисциплину и указываем дефолтный класс /sbin/tc qdisc add dev eth1 root handle 1: htb default 15 #Создаем общий для клиентов класс /sbin/tc class add dev eth1 parent 1: classid 1:1 htb rate 10Mbit ceil 10Mbit #Создаем корневой класс клиента /sbin/tc class add dev eth1 parent 1:1 classid 1:10 htb rate 512kbit ceil 512kbit #Создаем 4 подкласса для каждого из видов трафика /sbin/tc class add dev eth1 parent 1:10 classid 1:11 htb rate 1kbit ceil 512kbit prio 1 /sbin/tc class add dev eth1 parent 1:10 classid 1:12 htb rate 1kbit ceil 512kbit prio 2 /sbin/tc class add dev eth1 parent 1:10 classid 1:13 htb rate 1kbit ceil 512kbit prio 3 /sbin/tc class add dev eth1 parent 1:10 classid 1:14 htb rate 1kbit ceil 512kbit prio 4 #Создаем дисциплины шейпирования для конечных классов /sbin/tc qdisc add dev eth1 parent 1:11 handle 11: sfq perturb 10 /sbin/tc qdisc add dev eth1 parent 1:12 handle 12: sfq perturb 10 /sbin/tc qdisc add dev eth1 parent 1:13 handle 13: sfq perturb 10 /sbin/tc qdisc add dev eth1 parent 1:14 handle 14: sfq perturb 10 Создаем 4 фильтра, для каждого из видов трафика /sbin/tc filter add dev eth1 parent 1:0 protocol ip prio 1 u32 match ip dst 192.168.2.2/32 match ip protocol 1 0xff flowid 1:11 /sbin/tc filter add dev eth1 parent 1:0 protocol ip prio 2 u32 match ip dst 192.168.2.2/32 match ip protocol 17 0xff flowid 1:12 /sbin/tc filter add dev eth1 parent 1:0 protocol ip prio 3 u32 match ip dst 192.168.2.2/32 match ip protocol 6 0xff match ip sport 80 0xffff flowid 1:13 /sbin/tc filter add dev eth1 parent 1:0 protocol ip prio 4 u32 match ip dst 192.168.2.2/32 flowid 1:14 * This source code was highlighted with Source Code Highlighter.

Думаю из примера видно, что для реализации приоретизиции трафика мы создали для каждого отдельный класс. Далее создаем фильтры, причем чем меньше prio, тем больше у трафика приоритет. Вообще правила обрабатываются согласно тому как их добавляли, в случае с приоритетами — первыми обслуживаются правила, имеющие наивысший приоритет.
Так же вы можете каждому из классов обзначить RATE равный одной четвертой от RATE корневого класса клиента, что бы уже наверняка.
Хочу обратить внимание, на то что нам пришлось создать 4 фильтра, для оного ип, а если ип 3-4 тысячи, то получим огромный линейный список правил — в итоге производительность упадет ниже плинтуса.
Что бы этого избежать воспользуемся «быстрыми» хэш таблицами.
О том, что такое хэш таблицы Вы можете посмотреть на Википедии.
Создадим 4 таблицы по 256 ячеек, каждая из таблиц будет оценивать один из октетов ип адреса.
И в конечном итоге, вместо поиска по всему списку, как это было бы в классическом варианте, мы уменьшим количество проверок и значительно снизим нагрузку.
Пример.

#Создаем корневой фильтр /sbin/tc filter add dev eth1 parent 1:0 protocol ip u32 #Создаем 4 хеш таблицы для каждого октета /sbin/tc filter add dev eth1 parent 1:0 handle 10: protocol ip u32 divisor 256 /sbin/tc filter add dev eth1 parent 1:0 handle 11: protocol ip u32 divisor 256 /sbin/tc filter add dev eth1 parent 1:0 handle 12: protocol ip u32 divisor 256 /sbin/tc filter add dev eth1 parent 1:0 handle 13: protocol ip u32 divisor 256 #Создаем фильтр направлящий весь трафик в хеш таблицу с ID 10 /sbin/tc filter add dev eth1 parent 1:0 protocol ip u32 ht 801:: match ip dst 0.0.0.0/0 hashkey mask 0xff000000 at 16 link 10: #Добавляем правило в 10 хеш таблицу, если первый октет равен 192, то оправляем пакет в 11 хеш таблицу /sbin/tc filter add dev eth1 parent 1:0 protocol ip u32 ht 10:c0: match ip dst 192.0.0.0/8 hashkey mask 0xff0000 at 16 link 11: #Добавляем правило в 11 хеш таблицу, если второй октет равен 168, то оправляем пакет в 12 хеш таблицу /sbin/tc filter add dev eth1 parent 1:0 protocol ip u32 ht 11:a8: match ip dst 192.168.0.0/16 hashkey mask 0xff00 at 16 link 12: #Добавляем правило в 12 хеш таблицу, если третий октет равен 2, то оправляем пакет в 13 хеш таблицу /sbin/tc filter add dev eth1 parent 1:0 protocol ip u32 ht 12:2: match ip dst 192.168.2.0/24 hashkey mask 0xff at 16 link 13: #Добавляем правила в 13 хеш таблицу, оцениваем 4 октет и направляем в необходимый класс, в зависимости от вида трафика /sbin/tc filter add dev eth1 parent 1:0 protocol ip prio 1 u32 ht 13:2: match ip dst 192.168.2.2/32 match ip protocol 1 0xff flowid 1:11 /sbin/tc filter add dev eth1 parent 1:0 protocol ip prio 2 u32 ht 13:2: match ip dst 192.168.2.2/32 match ip protocol 17 0xff flowid 1:12 /sbin/tc filter add dev eth1 parent 1:0 protocol ip prio 3 u32 ht 13:2: match ip dst 192.168.2.2/32 match ip protocol 6 0xff match ip sport 80 0xffff flowid 1:13 /sbin/tc filter add dev eth1 parent 1:0 protocol ip prio 4 u32 ht 13:2: match ip dst 192.168.2.2/32 flowid 1:14 * This source code was highlighted with Source Code Highlighter.

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

#!/bin/bash mysql="mysql -ppass -u user -h host" #создаем корневуй дсциплину, класс, корневой фильтр и тиблицы хешей для внешних интерфейсов echo "select ext_iface from system.shaper_view group by ext_iface;"|$mysql|sed 1d| awk '{ print "/sbin/tc qdisc del dev "$1" root handle 1: htb default 15"; print "/sbin/tc qdisc add dev "$1" root handle 1: htb default 15"; print "/sbin/tc class add dev "$1" parent 1: classid 1:1 htb rate 10Mbit ceil 10Mbit"; print "/sbin/tc filter add dev "$1" parent 1:1 prio 10 protocol ip u32"; print "/sbin/tc filter add dev "$1" parent 1:0 protocol ip u32"; print "/sbin/tc filter add dev "$1" parent 1:0 handle 10: protocol ip u32 divisor 256"; print "/sbin/tc filter add dev "$1" parent 1:0 handle 11: protocol ip u32 divisor 256"; print "/sbin/tc filter add dev "$1" parent 1:0 handle 12: protocol ip u32 divisor 256"; print "/sbin/tc filter add dev "$1" parent 1:0 handle 13: protocol ip u32 divisor 256"; print "/sbin/tc filter add dev "$1" parent 1:0 protocol ip u32 ht 801:: match ip dst 0.0.0.0/0 hashkey mask 0xff000000 at 16 link 10:"; }' #создаем корневуй дсциплину, класс, корневой фильтр и тиблицы хешей для внутренних интерфейсов echo "select int_iface from system.shaper_view group by int_iface;"|$mysql|sed 1d| awk '{ print "/sbin/tc qdisc del dev "$1" root handle 1: htb default 15"; print "/sbin/tc qdisc add dev "$1" root handle 1: htb default 15"; print "/sbin/tc class add dev "$1" parent 1: classid 1:1 htb rate 10Mbit ceil 10Mbit"; print "/sbin/tc filter add dev "$1" parent 1:1 prio 10 protocol ip u32"; print "/sbin/tc filter add dev "$1" parent 1:0 protocol ip u32"; print "/sbin/tc filter add dev "$1" parent 1:0 handle 10: protocol ip u32 divisor 256"; print "/sbin/tc filter add dev "$1" parent 1:0 handle 11: protocol ip u32 divisor 256"; print "/sbin/tc filter add dev "$1" parent 1:0 handle 12: protocol ip u32 divisor 256"; print "/sbin/tc filter add dev "$1" parent 1:0 handle 13: protocol ip u32 divisor 256"; print "/sbin/tc filter add dev "$1" parent 1:0 protocol ip u32 ht 801:: match ip src 0.0.0.0/0 hashkey mask 0xff000000 at 12 link 10:"; }' #создаем классы, фильтры,дисциплины и при необходимости заполняем таблицы хешей echo "select user_id,ip,speed,int_iface,ext_iface from system.shaper_view order by user_id;"|$mysql|sed 1d| awk ' BEGIN{ buf=0; class_id=255; tc_class="/sbin/tc class add dev"; tc_qdisc="/sbin/tc qdisc add dev"; tc_filter="/sbin/tc filter add dev"; } { if(buf!=$1) { printf "%s%x%s\n", "# ",class_id," "class_id" "$2; client_speed=$3*128; printf "%s%x%s\n",tc_class" "$4" parent 1:1 classid 1:",++class_id," htb rate "client_speed"bps ceil "client_speed"bps"; printf "%s%x%s\n",tc_class" "$5" parent 1:1 classid 1:",class_id," htb rate "client_speed"bps ceil "client_speed"bps"; client_class=class_id; printf "%s%x%s%x%s\n",tc_class" "$4" parent 1:",client_class," classid 1:",++class_id," htb rate 1024bps ceil "client_speed"bps prio 1"; printf "%s%x%s%x%s\n",tc_class" "$5" parent 1:",client_class," classid 1:",class_id," htb rate 1024bps ceil "client_speed"bps prio 1"; printf "%s%x%s%x%s\n",tc_qdisc" "$4" parent 1:",class_id," handle ",class_id,": sfq perturb 10"; printf "%s%x%s%x%s\n",tc_qdisc" "$5" parent 1:",class_id," handle ",class_id,": sfq perturb 10"; printf "%s%x%s%x%s\n",tc_class" "$4" parent 1:",client_class," classid 1:",++class_id," htb rate 1024bps ceil "client_speed"bps prio 2"; printf "%s%x%s%x%s\n",tc_class" "$5" parent 1:",client_class," classid 1:",class_id," htb rate 1024bps ceil "client_speed"bps prio 2"; printf "%s%x%s%x%s\n",tc_qdisc" "$4" parent 1:",class_id," handle ",class_id,": sfq perturb 10"; printf "%s%x%s%x%s\n",tc_qdisc" "$5" parent 1:",class_id," handle ",class_id,": sfq perturb 10"; printf "%s%x%s%x%s\n",tc_class" "$4" parent 1:",client_class," classid 1:",++class_id," htb rate 1024bps ceil "client_speed"bps prio 3"; printf "%s%x%s%x%s\n",tc_class" "$5" parent 1:",client_class," classid 1:",class_id," htb rate 1024bps ceil "client_speed"bps prio 3"; printf "%s%x%s%x%s\n",tc_qdisc" "$4" parent 1:",class_id," handle ",class_id,": sfq perturb 10"; printf "%s%x%s%x%s\n",tc_qdisc" "$5" parent 1:",class_id," handle ",class_id,": sfq perturb 10"; printf "%s%x%s%x%s\n",tc_class" "$4" parent 1:",client_class," classid 1:",++class_id," htb rate 1024bps ceil "client_speed"bps prio 4"; printf "%s%x%s%x%s\n",tc_class" "$5" parent 1:",client_class," classid 1:",class_id," htb rate 1024bps ceil "client_speed"bps prio 4"; printf "%s%x%s%x%s\n",tc_qdisc" "$4" parent 1:",class_id," handle ",class_id,": sfq perturb 10"; printf "%s%x%s%x%s\n",tc_qdisc" "$5" parent 1:",class_id," handle ",class_id,": sfq perturb 10"; } split($2,ip,"."); if (ht_1[ip[1]]!=1) { printf "%s%x%s\n",tc_filter" "$4" parent 1:0 protocol ip u32 ht 10:",ip[1],": match ip dst "ip[1]".0.0.0/8 hashkey mask 0xff0000 at 16 link 11:"; printf "%s%x%s\n",tc_filter" "$5" parent 1:0 protocol ip u32 ht 10:",ip[1],": match ip src "ip[1]".0.0.0/8 hashkey mask 0xff0000 at 12 link 11:"; ht_1[ip[1]]=1; } if (ht_2[ip[2]]!=1) { printf "%s%x%s\n",tc_filter" "$4" parent 1:0 protocol ip u32 ht 11:",ip[2],": match ip dst "ip[1]"."ip[2]".0.0/16 hashkey mask 0xff00 at 16 link 12:"; printf "%s%x%s\n",tc_filter" "$5" parent 1:0 protocol ip u32 ht 11:",ip[2],": match ip src "ip[1]"."ip[2]".0.0/16 hashkey mask 0xff00 at 12 link 12:"; ht_2[ip[2]]=1; } if (ht_3[ip[3]]!=1) { printf "%s%x%s\n",tc_filter" "$4" parent 1:0 protocol ip u32 ht 12:",ip[3],": match ip dst "ip[1]"."ip[2]"."ip[3]".0/24 hashkey mask 0xff at 16 link 13:"; printf "%s%x%s\n",tc_filter" "$5" parent 1:0 protocol ip u32 ht 12:",ip[3],": match ip src "ip[1]"."ip[2]"."ip[3]".0/24 hashkey mask 0xff at 12 link 13:"; ht_3[ip[3]]=1; } printf "%s%x%s%x\n",tc_filter" "$4" parent 1:0 protocol ip prio 1 u32 ht 13:",ip[4],": match ip dst "$2"/32 hashkey mask 0x0 at 16 match ip protocol 1 0xff flowid 1:",client_class printf "%s%x%s%x\n",tc_filter" "$5" parent 1:0 protocol ip prio 1 u32 ht 13:",ip[4],": match ip src "$2"/32 hashkey mask 0x0 at 12 match ip protocol 1 0xff flowid 1:",client_class printf "%s%x%s%x\n",tc_filter" "$4" parent 1:0 protocol ip prio 2 u32 ht 13:",ip[4],": match ip dst "$2"/32 hashkey mask 0x0 at 16 match ip protocol 17 0xff flowid 1:",++client_class printf "%s%x%s%x\n",tc_filter" "$5" parent 1:0 protocol ip prio 2 u32 ht 13:",ip[4],": match ip src "$2"/32 hashkey mask 0x0 at 12 match ip protocol 17 0xff flowid 1:",client_class printf "%s%x%s%x\n",tc_filter" "$4" parent 1:0 protocol ip prio 3 u32 ht 13:",ip[4],": match ip dst "$2"/32 hashkey mask 0x0 at 16 match ip protocol 6 0xff match ip sport 80 0xffff flowid 1:",++client_class printf "%s%x%s%x\n",tc_filter" "$5" parent 1:0 protocol ip prio 3 u32 ht 13:",ip[4],": match ip src "$2"/32 hashkey mask 0x0 at 12 match ip protocol 6 0xff match ip dport 80 0xffff flowid 1:",client_class printf "%s%x%s%x\n",tc_filter" "$4" parent 1:0 protocol ip prio 4 u32 ht 13:",ip[4],": match ip dst "$2"/32 hashkey mask 0x0 at 16 flowid 1:",++client_class printf "%s%x%s%x\n",tc_filter" "$5" parent 1:0 protocol ip prio 4 u32 ht 13:",ip[4],": match ip src "$2"/32 hashkey mask 0x0 at 12 flowid 1:",client_class buf=$1; }' * This source code was highlighted with Source Code Highlighter.

Надеюсь данный опус помог Вам вникнуть в основы управления трафиком в Linux.

Источник: http://habrahabr.ru/blogs/sysadm/89002/

Шейпирование трафика в Linux

2010-11-26T00:20:00.000+02:00

Под катом описано как шейпировать трафик в Linux и что для этого нужно знать.
Осуществлять шейпирование трафика будем посредством утилиты tc из пакета iproute2.
Знания без которых нельзя осознать всю полноту управления трафиком в Linux:
Шейпировать можно только исходящий из интерфейса трафик. (в связи с чем возникает проблема с nat, о ней мы поговорим позже). Предположим, что имеется роутер между «интернетом» и абонентом. В роутер воткнуто две сетевые карты: eth0 смотрит на абонента, а eth1 в мир. Для ограничения «скорости скачивания» правила шейпирования описываем на eth0, для ограничения «отдачи» — на eth1.
Необходимо понимать разницу между rate и ceil. Rate — гарантированная полоса пропуская, Ceil — максимальная полоса которую может получить данный класс, rate не может быть больше ceil
Параметры rate и ceil для корневого класса должны совпадать. Таким образом мы определяем общую полосу пропускания.
Сумма Rate'ов классов-потомков, не должна превышать Rate родительского класса. Конечно можно не выполнять этот пункт, но тогда могут возникнуть проблемы с предоставлением «гарантированной полосы пропускания».
Идентификаторы классов указаны в шестнадцатеричной системе, и должны находиться в пределах от 2 до 2^16
Для промежуточных классов необязательно создавать дисциплины и фильтры.
Идентификаторы классов в пределах интерфейса должны быть уникальны.

В простом варианте изложения алгоритм нарезки трафика выглядит так:
1. Создаем корневую дисциплину для интерфейса и указываем класс куда будет попадать не классифицированный трафик.
2. Создаем корневой класс и определяем ширину канала.
3. Создаем дочерний класс для шейпирования абонента.
4. Создаем дисциплину шейпирования для класса абонента.
5. Создаем фильтра позволяющие классифицировать трафик абонента.

В принципе все просто, но в реальной жизни придется потратить много нервов, что бы добиться желаемого результата.
Один из способов добиться результата не тратя много нервов — использовать скрипт htbinit (взять его можно с sourceforge.net/projects/htbinit/). Синтаксис конфигов простой, создание классов тоже просто.
Для построения конфигураций средней сложность вполне достаточно.
Пример.
Имеется локальная сеть, средних размеров. Вам необходимо ограничивать скорость абонентов согласно прейскуранту, трансляция адресов (NAT) происходит на другом сервере.

Получение htbinit

debian:~# wget downloads.sourceforge.net/project/htbinit/HTB.init/0.8.5/htb.init-v0.8.5?use_mirror=surfnet

debian:~#  mv htb.init-v0.8.5 /usr/local/sbin/

debian:~# cd  /usr/local/sbin/

debian:/usr/local/sbin# mv htb.init-v0.8.5  htb.init

debian:/usr/local/sbin# chmod +x htb.init

По умолчанию htbinit хранит конфиги в папке /etc/sysconfig/htb.
debian:~# mkdir -p /etc/sysconfig/htb
Создаем коневую дисциплину для интерфейса eth0 (интерфейс смотрит в локальную сеть, «на абонента»)
debian:~# touch /etc/sysconfig/htb/eth0
Указываем в какой класс будет попадать трафик не попавший ни в один из фильтров

debian:~# mcedit  /etc/sysconfig/htb/eth0

DEFAULT=42

Создаем корневой класс

debian:~# touch /etc/sysconfig/htb/eth0-2.root

debian:~#  mcedit /etc/sysconfig/htb/eth0-2.root

RATE=100Mbit

Можно не указывать CEIL, тогда он автоматом будет равен RATE.

Создаем класс для не классифицированного трафика

debian:~# touch  /etc/sysconfig/htb/eth0-2:42.root

debian:~# mcedit  /etc/sysconfig/htb/eth0-2:42.root

RATE=4Kbit

Создаем общий клиентский класс. Пускай его ID будет равно «D» и всего для абонентов мы выделим 10 Мбит.

debian:~# touch  /etc/sysconfig/htb/eth0-2:D.sumamry_cilents_class

debian:~# mcedit  /etc/sysconfig/htb/eth0-2:D.sumamry_cilents_class

RATE=10Mbit

Теперь можно заняться абонентами.
Что бы ограничить скорость скачивания в 512 КБит абоненту Василию нужно:
Создать класс для абонента Василия. Пускай ID клиентов будут начинаться с 255. Весьма полезно, если потребуется создать какой либо «системный» класс.
debian:~# touch /etc/sysconfig/htb/eth0-2:D:100.client_login
Интерфейс, идентификатор класса и родительские классы описываются в названии конфига.
Запись eth0-2:D:100.client_login означает что
eth0- Данный класс принадлежит к интерфейсу eth0
2 Корневой класс
D Родительский класс (В нашем случае общий клиентский класс)
100 Идентификатор класса клента
client_login Мнемоническая составляющая названия файла, несет смысловую нагрузку, в генерации классов не используется

Название файла генерируется таким образом:
1. Интерфейс к которому принадлежит класс.
2. Разделитель "-"(минус)
3. ID корневого класса
4. Разделитель ":"(двоеточие)
5. ID родительского класса
6. Разделитель ":"(двоеточие)
7. ID клиентского класса
8. Разделитель "."(точка)
9. Мнемоническая составляющая названия файла
Пункты 5 и 6 могут отсутствовать, в зависимость от выбранной Вами стратегии шейпирования.

debian:~#  mcedit  /etc/sysconfig/htb/eth0-2:D:100.client_login

RATE=512Kbit

LEAF=sfq

RULE=0.0.0.0/0,client_ip/32

По минимуму в конфиге должно быть 3 строки.
RATE — полоса предоставляемая абоненту.
LEAF — указатель на то, что класс конечный и для него необходимо создать создать дисциплину, в нашем случае sfq («псевдочестное» распределение полосы)
RULE — определяем что попадает в класс.Фильтровать можно по ип адресам, подсетям ип адресов, портам. Количество записей RULE может быть более одной.

Если нам нужно шейпировать трафик и натить на том же руотере, то вместо RULE нужно использовать MARK. Единственное придется маркировать пакеты.
Пример скрипта генерирующего конфиги для htbinit в конфигурации с NATом.
#!/bin/bash
#определяем переменные

declare -a  rules

inif="eth0"

outif="eth1"

vlan="10"

workdir="/home/netup"

vardir="${workdir}/var"

htb_dir="/etc/sysconfig/htb"

mysql="/usr/bin/mysql  -h host -u user -ppassword -D  base"

ipt="/usr/local/sbin/iptables"

IPT_UNLIM="UNLIM_"${vlan}

utm_rules="${vardir}/htb_rules_htb"

htb_rules="${vardir}/htb_rules_utm"

#подготавливаем конфиги при первом запуске
[ -e ${htb_rules} ] || touch ${htb_rules}
#полная регенерация конфигов

if [ "${1}" =  "zopa" ];then

echo ""> ${htb_rules};

fi

#получаем данные (id в шестнадцатиричной системе)
echo "select id,ip,mask,speed from view_shaper order by id;"|$mysql|sed '1d' > ${utm_rules};
#если достучались к базе и есть разница с текущим конфигом

exp="${utm_rules}  ${htb_rules}"

[ -s ${utm_rules} ] && if [ -n "`diff ${exp}`"  ]

then

#удаляем конфиги надобность в которых отпала

for i  in `diff ${exp}|awk '{if (NF==5)print $2}'|sort  -n|uniq`

do

inshaper=${htb_dir}/${inif}-2:${i}.rule_${i};

[ -e  ${inshaper} ] && rm  ${inshaper};

outshaper=${htb_dir}/${outif}-2:${i}.rule_${i};

[ -e  ${outshaper} ] && rm ${outshaper};

done;

#формируем новые конфиги

rules=(`diff ${exp}|grep "<"|awk '{if (NF==5)print  $2,$3,$4,$5}'`)

for i in `seq 1 4  ${#rules[@]}`;

do

id=${rules[$i-1]};

ip=${rules[$i]};

mask=${rules[$i+1]};

rate=${rules[$i+2]};

#Формируем названия конфигов

inshaper=${htb_dir}"/"${inif}-2:${id}.rule_${id};

outshaper=${htb_dir}/${outif}-2:${id}.rule_${id};

#Рассчитываем марки для пакетов

inmark="0x"`echo "obase=16;  $((0x${id}*2))"|bc`

outmark="0x"`echo "obase=16;  $((0x${id}*2+1))"|bc`

#Удаляем «старые» правила маркировки
${ipt} -t mangle -S ${IPT_UNLIM}|grep -w ${ip}|awk -v ipt=${ipt} '{$1="-D";system(ipt" -t mangle "$0)}';
#Создаем конфиг и правила на внутреннем интерфейсе

if [ -e ${inshaper} ]; then

#echo  "RULE="0.0.0.0/0,"${ip}"/"${mask}">> ${inshaper}

${ipt} -t mangle -A  ${IPT_UNLIM} -s ${ip} -j MARK --set-mark ${inmark}

else

echo  "RATE=4096bit" > ${inshaper}

echo "CEIL="$((${rate}*1024))"bit"  >>${inshaper}

echo "LEAF=sfq" >> ${inshaper}

#echo  "RULE=0.0.0.0/0,"${ip}"/"${mask}>> ${inshaper};

echo  "MARK="${inmark}>> ${inshaper};

${ipt} -t mangle -A ${IPT_UNLIM} -d  ${ip}/${mask} -j MARK --set-mark ${inmark}

fi

#Создаем конфиг и правила на внутреннем интерфейсе

if [ -e $outshaper ]; then

#echo  "RULE="${ip}"/"${mask}",0.0.0.0/0" >> ${outshaper}

${ipt} -t mangle -A  ${IPT_UNLIM} -s ${ip}/${mask} -j MARK --set-mark ${outmark}

else

echo  "RATE=4096bit" > ${outshaper}

echo "CEIL="$((${rate}*1024))"bit" >>  ${outshaper}

echo "LEAF=sfq" >> ${outshaper}

#echo  "RULE="${ip}"/"${mask}",0.0.0.0/0" >> ${outshaper}

echo  "MARK="${outmark}>> $outshaper;

${ipt} -t mangle -A ${IPT_UNLIM} -s  ${ip}/${mask} -j MARK --set-mark ${outmark}

fi

echo $ip

done;

cp  ${exp}

[ -e /var/cache/htb.init ] && rm  /var/cache/htb.init

/usr/local/sbin/htb.init restart

fi

Для конфигураций до 1000-1500 фильтров такой вариант подойдет. Для более крупных уже нужно использовать быстрые хэш фильтры, о ни и о приоретизации трафика я расскажу в следующей статье.

Источник: http://habrahabr.ru/blogs/sysadm/88624/

Повышение производительности netfilter, использование ipset

2010-11-26T00:19:00.000+02:00

iptables — интерфейс к файрволу Linux (netfilter). При большом количестве правил iptables нагрузка может быть достаточно высокой и создавать проблемы. В этой заметке я постараюсь описать, что влияет на производительность iptables и как ее повысить.

Основная причина нагрузки

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

На схеме видно через какие цепочки пройдет тот или иной пакет и можно оценить нагрузку. Возьмем одно простейшее правило:

-A INPUT -s 10.1.1.1/32 -p tcp --dport 25 -j DROP

Это правило указывает файрволлу отбрасывать все пакеты с IP-адреса 10.1.1.1 на порт 25 локальной машины. Таблицу (-t) я не указываю, поэтому будет использоваться дефолтная (-t filter), что нам и нужно. Понятно, что действие DROP выполняется далеко не всегда. Однако, сравнение IP-адреса источника будет проходить любой входящий на локальную машину пакет. А если таких правил тысяча?

Что делать?

Теперь подумаем, как можно ускорить работу файрволла. Первый ответ очевиден — сокращать количество правил. Но вряд ли удастся серьезно оптимизировать записи, особенно если они изначально составлялись грамотно. Где-то вместо правил на несколько IP-адресов можно написать одно правило на подсеть. Где-то вместо правил на несколько портов можно использовать -m multiport и --dports/--sports a,b,c (a,b,c — номера портов). И так далее.

Ветвление правил, дополнительные цепочки

А есть еще второй вариант — использование ветвлений правил. Суть его в том, что однотипные правила группируются в отдельную цепочку, а в основной цепочке остается одно правило, которое перенаправляет пакет в отдельную цепочку в зависимости от какого-то общего признака пакетов. Приведу пример. Имеются три правила:

-A  INPUT -s 10.1.1.1/32 -p icmp -j ACCEPT

-A INPUT -s 10.1.1.2/32 -p icmp -j  ACCEPT

-A INPUT -s 10.1.1.3/32 -p icmp -j ACCEPT

Что объединяет эти правила? Одинаковый протокол — icmp. Вот по этому признаку и стоит сгруппировать правила. Вообще в данном случае эффективнее использовать ipset, но об этом дальше. Для группировки необходимо создать новую цепочку, а затем создать правило, которое будет отправлять пакеты в эту цепочку.
Создать цепочку PROT_ICMP:

iptables -N PROT_ICMP

Определить правила в этой цепочке:

-A  PROT_ICMP -s 10.1.1.1/32 -j ACCEPT

-A PROT_ICMP -s 10.1.1.2/32 -j  ACCEPT

-A PROT_ICMP -s 10.1.1.3/32 -j ACCEPT

Как видите, протокол (-p) в этой цепочке мы уже не проверяем, т.к. отправлять в эту цепочку будем только ICMP пакеты. И наконец отправить все пакеты ICMP в эту цепочку:

-A INPUT -p icmp -g PROT_ICMP

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

ipset

А теперь предположим следующую ситуацию:

-A INPUT  -s 10.1.1.1/32 -j DROP

-A INPUT -s 10.1.1.2/32 -j DROP

-A INPUT -s  10.1.1.3/32 -j DROP

Несколько однотипных правил, но сгруппировать их или сделать дополнительную цепочку не представляется возможным. В таких случаях, когда необходимо делать проверку по большому количеству IP-адресов и/или портов, на помощь приходит ipset. ipset представляет из себя модуль ядра ip_set, ряд вспомогательных библиотек и утилиту ipset для задания параметров. Наверняка есть в репозиториях вашего дистрибутива, так что с установкой не должно быть проблем.
Используется следующим образом:
* Создается список:

ipset -N dropips iphash
dropips — название списка, iphash — тип списка. Типы списков можно посмотреть в man ipset, они есть на любой вкус — для работы с ip-адресами, подсетями, портами, mac-адресами. iphash служит для хранения IP-адресов, использование хэширования предотвращает добавление в список дублирующих IP-адресов.
* Добавляется IP-адрес в список:

ipset -A dropips 10.1.1.1

* Создается правило для использования списка:

iptables -A INPUT -m set --set dropips src -j DROP
-m set указывает на использование модуля ipset, --set dropips указывает список IP-адресов, src указывает на то, что сверять нужно только IP-источника. Таким образом, будут отбрасываться все пакеты с IP-адресов, указанных в списке dropips.

В статье я не стал описывать тюнинг сетевых параметров ядра, а сделал упор на рациональную организацию правил файрволла. Информации о тюнинге очень много можно найти в сети, это различные net.*mem*, в случае большого количества соединений и использования conntrack — параметры net.netfilter.nf_conntrack_max, net.netfilter.nf_conntrack*timeout и т.д.

Источник http://habrahabr.ru/blogs/sysadm/108691/

Срезаем пики с RRD графиков на примере Munin

2010-05-16T22:47:00.000+03:00

Любой linux администратор наверняка наблюдал аномальные пики на RRD графиках. Пики появляются вследствие нарушения процесса сбора отслеживаемой величины и портят картину на графике. Это нормальное явление для RRD.

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

При появлении пиков необходимо удалить аномальные значения из базы RRD, чтобы график снова стал информативен. Это можно сделать с помощью утилиты rrdtool:
а) в ручную
rrdtool dump -> xml (находим и удаляем пики) -> rrdtool restore

б) или запустив скрипт removespikes.pl, в нем происходит тоже самое, но без вашего участия.

Я использую removespikes.pl. Процесс срезания пиков занимает не более 1 минуты.
На моих серверах установлен мониторинг Munin, поэтому примеры приведены с использованием этого мониторинга. Метод будет работать с любым мониторингов на основе RRD.

Срезаем пики с графиков eth0 трафика

## переключаем пользователя (подробнее см. «Подводные  камни»)

su – munin



## утасновка скрипта removespikes.pl на  сервере

wget oss.oetiker.ch/rrdtool/pub/contrib/removespikes-20080226-mkn.tar.gz

tar  xvzf removespikes-20080226-mkn.tar.gz

rm  removespikes-20080226-mkn.tar.gz



## Корректировка rrd файлов

##  Указываем маску только тех файлов в которых необходимо срезать пики и не трогаем  бекапы *.rrd.old при повторных запусках.

for f in `find ~/localdomain/ -name  "localhost.localdomain-if_eth0*.rrd"` 

do 

## я использую  removespikes.pl-orig. 

## в removespikes.pl добавлен новый функционал и  изменен метод среза пиков так, что можно запороть всю RRD базу. (подробнее см.  «Подводные камни»)

~/removespikes/removespikes.pl-orig  $f;

done;

После запуска скрипта вы должны увидеть что-то вроде

Chopping peak at 

Chopping peak at

Графики Munin eth0 traffic после removespikes.pl

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

Камень №1
Внимание: запускайте скрипт removespikes.pl под пользователем вашего мониторинга или проверяйте права на rdd файлы созданные скриптом, иначе сбор данных станет не возможен!

На графике выше отмечен разрыв, который произошел, вследствие того что я запускал removespikes.pl из под root. Исправленные rrd файлы были созданы с владельцем root и munin не мог записывать в них данные.

Камень №2
В архиве removespikes-20080226-mkn.tar.gz две модификации скрипта: оригинальная (removespikes.pl-orig) и с доп. функциями (removespikes.pl).

Корректность работы removespikes.pl-orig неоднократно мною проверена на разных серверах.

А вот запустив removespikes.pl я получил неожиданный результат. График как утюгом разгладило :(.

В скрипте есть параметр removespikes.pl
# Threshhold for cutting. Exponents above it will be chopped – срезаются все точки выше этого значения.
my $THRESH=10000;, что соответствует примерно 140Мбит/с.
Мой трафик был больше 140 и попал под это ограничение.
Если у вас обычные 100Мбит/с то это ограничение не окажет влияния на конечный результат.

Заключение

Скрипт автоматически создает бекап файлы с именами *.rrd.old, так что всегда можно вернутся к исходному состоянию. Главное правильно создать шаблон поиска файлов для прохода removespikes.pl в цикле for… in.

Источники

howto-remove-spikes-from-rrd-graphs
rrdtool doc