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

Написал однажды мне друг с ноутбуком 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

При использованиии 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;
в данном случае не помогают.
Как вариант решения предлагаю:

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

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

Оригинал

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

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

И вот, в один прекрасный день, собрались инженеры с духом, и разработали 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

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

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 на службе у провайдера

Просмотрев большинство тематических постов на хабре был безмерно удивлён тому факту, что крайне скудно освещена тема использования ОС 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

Вступление

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

1. Версия RabbitMQ-Server — 2.1.0
2. ОС: 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/