татко Крокодил

Случва ми се да свърша нещо смислено, за което да блогна от време на време. Тия дни debug-вах една гадост, която си струва да се разкаже.

Ето това е commit-ът, който решава проблема. Задачката, която оригиналният код трябваше да реши, беше следната: Имаме byte stream, който четем на буфери. От него трябва да извадим отделните пакети и да ги сипем към горния layer.

Проблемът на оригиналният код беше, че не взимаше в предвид, че може да е прочел някаква част от пакета от предишния буфер и продължаваше да чете повече, отколкото трябва и да го пише в заделения буфер, който спокойно препълваше. За да го хванем, компилирахме кода с ASAN, който ни закара до правилното място (и на който трябваше да му обясним да ни прави coredump. Интересен факт, ASAN след известно време заделя ужасно много адресно пространство и ставаха 15TB coredump-ове, добре, че има sparse файлове)).

Та в общи линии имахме стандартен heap overflow в сървърен код, trigger-ван от потребителски данни (сравнително лесно). Добре, че това не го ползват особено много хора в production (ако го бяха ползвали, щяха да се ударят в проблема). Дали някой не може да направи курс по примитиви в мрежов C код, който да обяснява как се пишат тия неща ?:)

Моето отношение към ffmpeg може да се опише основно като “love-hate relationship”. Пипал съм по кода му, гледал съм хилядите security проблеми, които излизат в него, дебъгвал съм всякакви мизерни (и много мизерни) проблеми с него, и съм го ползвал за какво ли не.

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

Ако човек си компилира ffmpeg-а с –enable-libzmq и някъде във filtergraph-а сложи zmq, т.е. да речем направи нещо такова:

ffmpeg -re -i ~/20140407ripetest.mp4 -re -i ~/20140508pclapi-lecture.mp4 -i ~/video/transparent-eye.png \
	-filter_complex '[0:v] split [0big][0smp]; [0smp] scale=w=iw/4:h=ih/4 [0sm];
			[1:v] split [1big][1smp]; [1smp] scale=w=iw/4:h=ih/4 [1sm];
			[0big][1big] overlay, zmq [big]; [0sm][1sm] overlay [sm];
			[big][sm]overlay=x=main_w-overlay_w-10:y=main_h-overlay_h-10 [outn];
			[outn][2:v] overlay=x=main_w-overlay_w-10:y=10 [out]; [out] split [outflv][outsdl]' \
	-c:v libx264 -s 1280x720 -profile:v high -level 4.2 -preset ultrafast -g 60 -b:v 2000k -acodec aac \
	-ar 44100 -ac 2 -bsf:a aac_adtstoasc -flags +global_header -strict -2 -threads 2  \
	-f flv -map '[outflv]' rtmp://strm.ludost.net/st/test \
	-f sdl -map '[outsdl]' "SDL Output"

Това в общи линии значи следното:
– вход 0 се цепи на два, 0big и 0smp, вход 1 по същия начин;
– 0smp и 1smp се scale-ват на 1/4;
– Прави се един overlay от 0big и 1big;
– Прави се втори overlay от 0sm и 1sm;
– От първия и втория overlay се прави един друг overlay, т.е. като picture-in-picture;
– В/у този overlay се слага png с финалния overlay;
– Цялото това нещо се encode-ва до h.264;
– Праща се на екрана и на по rtmp до моя тестов setup.

До тук – нищо особено, само дето се вижда само едното видео. ОБАЧЕ, чрез zeromq интерфейса човек може да контролира overlay-ите и да мести overlay-натите неща, като може дори да ги изкарва от картиниата. Ето така може да се сменя видеото в някой от overlay-ите, през zmqshell.py (от tools/ на ffmpeg-а):

lavfi> Parsed_overlay_4 y 900
Sending command:[Parsed_overlay_4 y 900]
Received reply:[0 Success]
lavfi> Parsed_overlay_4 y 0
Sending command:[Parsed_overlay_4 y 0]
Received reply:[0 Success]

Проблемът е, че всичките тия имена на филтри (Parsed_overlay_4 например) се генерират и не може да се кръщават, та човек трябва да си ги налучка първия път. Чудя се дали биха приели patch по въпроса…

Примерната работа на нещото може да се види тук, тествах с две мои видеа и логото на феста.

Миналата седмица беше основно deployment-и.

По един проект завършихме инсталациите, мигрирахме основната част в четвъртък вечер (съвсем прилично, с под час downtime и внимателно действане), а в събота имаше довършително мигриране, на един пощенски сървър (dd if=/dev/xbvda1 bs=1M | nc x.x.x.x. yyyy и от другата страна nc -l -p yyyy | dd of=/dev/sda1 bs=1M, хубаво нещо е българския peering). Изяде ми по-голямата част от седмицата, но днес трябва да завършим съвсем всичко и да се брои за приключено.

За курса по системна администрация тръгнахме да реализираме ето тази схема, с mSTP, като стигнахме почти до никъде (след като открихме, че половината хардуер не поддържа mstp или има някакви странности по въпроса), та ще се продължава следващата събота.
Също около курса, octavo (на което са видео архивите) вече се премести като клиент на ISP-то (допреди това беше в СУ), и помогна да се хванат няколко забавни проблема с тунели и mtu-та, които вероятно ще ги разкажа друг път.

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

п.с. желаещи за посещене на telepoint? Пишете един mail.

Jul 1 02:59:59 marla kernel: [3069423.164970] Clock: inserting leap second 23:59:60 UTC
Jul 1 02:59:59 cassie kernel: [2208647.880820] Clock: inserting leap second 23:59:60 UTC
Jul 1 02:59:59 tyler kernel: [3127496.541511] Clock: inserting leap second 23:59:60 UTC
Jul 1 02:59:59 router kernel: [3848405.967906] Clock: inserting leap second 23:59:60 UTC
Jul 1 02:59:59 alpha kernel: [901347.744564] Clock: inserting leap second 23:59:60 UTC
Jul 1 02:59:59 172.31.190.253 kernel: [2212252.480000] Clock: inserting leap second 23:59:60 UTC
Jul 1 02:59:59 172.31.190.254 kernel: [2212240.380000] Clock: inserting leap second 23:59:60 UTC
Jul 1 02:59:59 OBSHTESTVO kernel: [3159370.768336] Clock: inserting leap second 23:59:60 UTC

и т.н.

Този път (за разлика от предишния) проблеми нямаше.

СПИМИСЕ.

Anyway, седмицата беше пълна с всякакви весели неща:

– Имам си MNT-KROKODIL в RIPE (за което имам да черпя Драго).

– 7-8-9 човека, вързани по тунели, няколко и с BGP (които могат да се видят в моя nagios). Все още хората се добавят на ръка, Мариян е почнал да пише интерфейс (явно му е скучно).

– Пуснахме IPv6 в ISP-то, дооправихме някакви неща, повече – в status report-а. Две бързи интересни неща – IPv6 на alpha-та и nagios-а на ISP-то (user/pass guest/guest).
– По горната тема, трябва да пусна looking glass-ове. Приемам идеи за неща, които поддържат bird, cisco и quagga и не искат да им се прави черна магия, че да тръгнат (тоя от сайта на bird е тотална трагедия).

– Преди година и нещо, след една лекция на Боян Кроснов за инфраструктура, доста хора се заинтересуваха да видят истински datacenter. Два месеца след това бях направил една уговорка с Telepoint, и миналата седмица (никак не се забавих) в четвъртък и петък с групи от по 5-6 човека обиколихме и видяхме как изглежда и какви забавни неща има (например овлажнители на въздуха). По принцип е ориентирано към студенти, та ако има още интересуващи се, пишете ми, за да събера пак една-две групи.
(целим се в сряда като ден за посещение, щото тогава тествали генераторите…)

– Тъкмо привършва HackTUES, на което не можах да отида, заради курса и всичките останали забавления, жалко.

– И идва BurgasConf, следващата седмица. Мразя да пътувам, но съм обещал… Тази година няма да говоря там, имах идея за една лекция, но там ще се иска още много research.

(картинки на цялата мрежа и само на BGP-то)

Бавничко започвам един нов проект – ipv6 тунели в България, за хората, дето искат да ги ползват и не ги радва, че всичко, до което могат да стигнат е извън страната, съответно бавно (и youtube ги мисли за немци).

Текущите потребители сме initLab, аз и един човек, дето в момента си оправя настройките. Услугата е предназначена както за съвсем нормални хора (прост тунел, едно /64, шапка на тояга), така и за по-болни хора (няколко връзки, повече от една мрежа, BGP, пълна routing таблица).

Хората могат да се връзват за момента до два node-а – marla.ludost.net и tyler.ludost.net (като мисля да намеря и още един).

Иначе, TODO-то е голямо, от миграция до BIRD (тва quagga-та е ламята Спаска), до документация, примерни config файлове и по-хубав/красив/видим monitoring (в момента част от нещата ги има в pnag.ludost.net, но не всички).

(а се оказа, че няма функция в pgsql, която да дели някакъв prefix на такива някакъв зададен по-малък размер (например да се разбие /62 на /64-ки) и си я писах сам)

не-Курсът по системна/мрежова администрация води до доста интересни открития.

Cisco IOS 12.2(11)T9 в/у 2600 (последния IOS, който има за тоя device, който мога да събера в моя flash/памет и в който има IPv6) по някаква причина не разпознава BGP peer-ите като directly connected, ако са вързани по някой сериен link и ттрябва да му се казва ebgp-multihop (не съм тествал за другите интерфейси). Отне бая ровичкане, и доста ровене в debug-а.

По default ipip и подобните тунели под linux слагат за TTL на външния пакет TTL-а от вътрешния пакет (“ttl inherit”). Смисълът на това тотално ми се губи, понеже троши traceroute по ужасен начин. Сега разбрах защо всички примери, дето съм виждал по въпроса имат накован в config-а ttl.

И една дреболия, дето драснах днес – прост скрипт за nagios, който се връзва по SNMP до дадено устройство, и проверява дали всички портове, за които има description са UP, и дали всички останали са DOWN. Доста полезно е за следене на switch-ове и подобни, като има малко трески за дялане, но като цяло е бая удобно за по-прости setup-и (където няма нужда да се връзва конкретен порт с нещо друго).

Качих един progress report за ISP курса, в който вероятно съм пропуснал някакви неща, но участниците ще си кажат и ще се допълва.

Тия дни около курса се чудех с какви IPv6 адреси да го правя, и накрая се реших, навих един LIR (благодарности на Драго от delta) да ми request-нат адреси и ASN. По случая вече си имам AS200533 и 2001:67c:21bc::/48, които ще използвам и за курса, и да направя един малък тунелен брокер за IPv6 тунели за желаещи (с дублиране на тунелните, BGP и такива забавни неща), очаквайте подробности по някое време, като успея да се заема сериозно.

Иначе, жив съм – имам си кило занимания около разни проекти, openfest (очаквайте новини), ходих да консултирам студенти във ФМИ по мрежи (трагедия), изпитахме си хората за мрежова сигурност 2 (по-малка трагедия), ходих днес на театър на “Контрабасът” (беше страхотно). Определено трябва да пиша повече, почва да ми се губи какво съм вършил…

И изглежда приключих с upgrade-ите на личните ми машини до jessie. Малко изводи/наблюдения:

– прочетете release notes, полезни са (има например как да не си инсталирате systemd);
– инсталирайте си needrestart, който при всеки нов инсталиран/upgrade-нат пакет може да провери какво трябва да се рестартира и да си каже. Това се оказа много полезно около update-ите на openssl и като цяло може само да разбира кой процес кои библиотеки ползва, доста улеснява живота;
– инсталирайте си debian-security-support, казва кога даден пакет вече не се поддържа от security екипа (има някакво количество подобни бози);
– ако имате някакви пакети, които сте компилирали сами, с debootstrap може лесно да си направите един jessie chroot и да си ги приготвите там предварително. Аз така търкалям собствен build на ircd-ratbox (който да поддържа utf8 в nick-овете и имената на каналите, заедно с още една-две добавки) и си пренесох patch-а за нула време;
– postgres се мигрира много лесно до новата версия, има три команди, описани в /usr/share/doc/postgres-нещоси;
– mysql-а па изобщо няма проблеми (ако ползвате системния, не съм гледал ситуацията с percona);
– имах огромен проблем с ejabberd, дотолкова, че накрая се ядосах, пуснах го в някакъв вид и го мигрирах до prosody. Мисля, че проблемът беше, че mnesia базата беше синхронизирана преди между две машини и понеже някои настройки не бяха махнати, разни update-и в/у схемата не са се случвали изобщо;
– погледнете после и направете apt-get autoremove, да почистите нещата, които не ви трябват, или да кажете изрично за нещо, че ви е нужно. Хубаво е да се чистят ненужните неща, да не влачите по 5 версии на разни стари библиотеки;
– Ако като мен ползвате неща, които apache сервира от /home, ще трябва да си пипнете /etc/apache2/apache2.conf, за да си позволите да се чете там (и да дадете AllowOverride, че default-а му е доста зъл). Също така са казали, че всичко,което се include-ва от sites-enabled и conf-enabled (conf.d е разкарано), трябва да завършва на .conf (което наложи малко да пригаждам конфигурацията си към него). Също така access/allow нещата са много променени и ако имате нещо по-сложно, ще трябва да се заровите в документацията;
– GRUB-а в момента по default пуска някакъв страшен видео-режим, който не запали на единия монитор в telepoint. В /etc/default/grub има GRUB_TERMINAL=console, което може да се разкоментира за целта.

В момента част от машините са със systemd, част са без, за да видя каква ще е разликата.

Самият upgrade мина сравнително безболезнено, reboot-а също си мина ОК. Мисля си тия дни да обърна внимание и на koi.obshtestvo.bg, където обаче има lxc контейнери и ще трябва да се действа по-внимателно.

Новия Debian stable (Jessie) се кани да излезе след ден-два, та по случая реших да upgrade-на cassie (router/сървър-a в initLab). Причина за upgrade беше и продължаващия проблем с drop-ване на определени пакети, най-вероятно от интеракция на route cache и двата отделни пътя навън.

Като цяло нещата минаха съвсем спокойно (mysql-а се upgrade-на сам, за postgres-а трябваше да се направи една кратка процедура по upgrade, пак сравнително автоматична), и за няколко неизползвани неща (като varnish) ми каза, че трябва да си пренапиша конфигурацията. Имаше обаче два мрежови проблема (за справка, описанието на мрежовия setup там):

– в последната quagga, която е в jessie, ospf6d е счупен, съответно външната IPv6 свързаност изобщо не захапа. След някакво ровене в changelog-ове намерих следното на сайта на quagga:
“[ospf6d] A large amount of changes has been merged for ospf6d. Careful evaluation prior to deployment is recommended.”
Реших да не го дебъгвам повече и минах нещата на BGP, с което така и така се чувствам по-комфортно (при v6 и quagga изборът не е много голям).

– след 3.6 са махнали routing cache, което води до любопитното поведение, че един tcp connection не може да просъществува дълго, понеже пакетите му почват да се мятат между двете връзки и доста бързо идва един reset. Оказа се, че има хубаво решение с CONNMARK, като връзката в началото се маркира откъде е излязла, след което с policy routing правила се праща през вече определения ѝ път.

Чакам да видя какво още ще се счупи (поне отварянето/отключването на вратата работят, та няма да се наложи да я режем с флекс).

Питаха ме тия дни “как да си говорим без да ни подслушват”, и понеже е просто, ето какво препоръчвам аз (и съм ползвал). Това не включва operational security неща (не говорете близо до други хора, не си качвайте записите някъде, не си давайте компютъра на непознати и т.н.), а само как да си направим setup, който може да се използва правилно. Базиран е на неща, които аз съм правил, т.е. конкретните препоръки са от моята практика.

Идеята е да имате end-to-end криптография (т.е. само крайните точки да могат да декриптират информацията) и forward secrecy (т.е. ако случайно някой ключ изтече, това да не дава възможност да се подслушва бъдещата комуникация). Това се постига с два протокола – OTR и ZRTP.

И двата са близки по идея, като първия се занимава с обмяна на текстови съобщения, втория с предаване на глас.

Като за начало – някакво собствено желязо, с криптиран диск, с debian stable и автоматични security update-и.
Ползвам debian, понеже си е стабилно и security update-ите работят както трябва и не чупят системата.
Криптирания диск е допълнителна мярка за сигурност. Реално на сървъра няма да пазите кой-знае каква важна информация, но си остава добра идея. Това влачи със себе си проблема, че на рестарт някой трябва да въвежда passphrase, но за това има начини да се прави по сравнително сигурен начин.
Виртуалните машини са твърде лесни за атака, че да се разчита на тях. Вариант са, защото при тоя setup данните не са чак толкова важни, но не ги препоръчвам.

Понеже всичката комуникация ще върви по TLS, е добре да си имате правилно подписан сертификат. Всички сме наясно, че сигурността на сертификатите е малко трагична, но помага понякога да се хванат разни MITM атаки. Има сравнително евтини CA-та, като скоро и ще работи това на EFF, което ще е съвсем безплатно.
Ако искате да избегнете всичките възможни атаки, може да си направите собствено CA и да го инсталирате по клиентите, но е по-сложно и доста често не се спазва както трябва и просто се казва на клиента да приема всякакви сертификати, което е лоша идея.

Следващата стъпка е XMPP (Jabber) сървър. Аз лично използвам ejabberd, понеже е сравнително прост за конфигурация, бърз и ако не трябва да дебъгвате S2S, направо идеален.
В него трябва да спрете некриптираните връзки като цяло, и да не включвате S2S (server-to-server) модула, така че да е ясно с кой говорите. Можете да си включите и конференциите, но за тях още няма end-to-end криптография.

Финално, трябват ви open-source клиенти, които да поддържат двата протокола (OTR и ZRTP). По принцип jitsi поддържа и двете и е доста добър избор (въпреки че е доста тежко и писано на java), като работи под всички desktop операционни системи и има alpha за android. За телефони (ios и android) за съобщения има chatsecure (само OTR). Също така аз самия ползвам pidgin с OTR plugin, който обаче няма ZRTP (и като цяло много кофти аудио поддръжка).
(някой може да допълни с още клиенти)

Този setup ви дава възможност да си говорите с end-to-end криптография и да сте много трудни/невъзможни за подслушване (по последните документи от NSA, OTR е нещо, за което не са намерили никакъв вариант да го счупят).

(мразя днешния ден, та да взема поне аз да свърша нещо полезно)

Тия дни около курса по мрежова сигурност си update-нах системата за build-ване на презентации и съответно съм я качил в github. Бая улеснява живота:

– Може да си добавяте картинки както си искате, системата ги resize-ва и следи коя презентация от кои зависи и я rebuild-ва;
– Както и преди, може да си пишете текста на презентацията заедно със слайдовете и се extract-ва автоматично;
– Може да си правите страници със заглавия ( ‘###’ и на следващия ред ‘#### някакво заглавие’ и ще запълни цялата страница с него);
– Вече няма нужда да пишете каквото и да е в Makefile-а, той автоматично захапва всички .pandoc файлове в текущата директория.

Сложил съм и един по-приятен пример, от който може да се гледа. При желание и с малко пипване в Makefile може да не ползвате моята зелена схема (която някои хора не харесват).

Днес получих поредното потвърждение за любимия си израз “Системният администратор се учи на гърба на потребителите”.

Правехме някаква миграция на obshtestvo, и около нея се налагаше няколко пъти да се drop-ват и преналиват едни бази. Хванах се на няколко пъти как съм пуснал DROP DATABASE и чак след това съм погледнал къде съм го пуснал, и не го бях сбъркал нито един път.
(нещото беше малко под пара, иначе гледам да правя нещата по-бавно)

Това не-сбъркване е продукт на МНОГО омазвания преди това, изгубени данни, възстановяване от backup-и и псуване. Трябва да има такива практически, реалистични упражнения и занимания за хората, които се занимават с админстване, просто защото “добрите практики” не стигат, особено като човек бърза, а аз още твърдя, че добър админ се познава по това как се справя като го вдигнат в 4 сутринта с махмурлук…

И по темата, тия дни се каня да си обявя новия не-курс, подробности за това – скоро.

Тия дни приключих с първата редакция на Reverse Engineering for Beginngers на Денис Юричев, и снощи ми е merge-нал последния pull request.

Книгата е много добра за начинаещи не само в reverse engineering-а, но и за хора, които искат да видят как работи отдолу асемблера и какво генерират компилаторите. Пълно е с всякакви интересни факти и като цяло не е много за четене (въпреки че генерираният pdf е около 950 страници). Има вид на подходящ учебник за един нормален едносеместриален курс, та даже някой може да реши да пробва да води по него :) Книгата е под creative commons лиценз, и може да се ползва за всякакви цели.

По принцип source на книгата може да се намери в github, авторът приема смислени редакции. Аз мисля да направя втори пас за редактиране, понеже досега оправях английския да звучи като английски и да е ясен, но може да се направи доста по темата да звучи наистина добре. Ако някой може да помогне с нещо друго (LaTeX-а не е чак толкова сложен), няма лошо да праща :) В todo-то на автора има “MIPS, Objective-C, Visual Basic, anti-debugging tricks, Windows NT kernel debugger, Java, .NET, Oracle RDBMS”, а в самата книга на доста места има “TODO” (например да се опишат в appendix A разни SIMD x86 инструкции).

Някои дреболии, дето изникват тия дни:

Описание как да си настроим ssh-а, така че да е минимално vulnerable към възможните проблеми (дето се мисли, че съществуват след лекцията на Апелбаум)
(мисля, че автора прекалява, ама па параноята е нещо важно в нашата професия)
(събирам желание да си rekey-на сървърите)

Ще има високосна секунда юли месец. Предишния път разни неща се счупиха, не мисля, че и тоя път ще ни се размине без проблеми.

Също така, в initlab ще има лекция/дискусия на тема “Design patterns for web-application scaling”, която даже ще stream-ваме online. Ще е в общи линии админска, но вероятно ще се допускат developer-и, ако не говорят много глупости.
(няма какво да се притеснявате, vloo ни е забранил да ползваме брадвата в тоя студ, а па и земята е твърде замръзнала, че да заравяме някой)

За тестове сме пуснали initLab TV, което в общи линии върти всичките записи, дето има на va.ludost.net.

Всички видеа от 31C3 са качени, ако има достатъчно желаещи, може да организираме гледане на най-добрите.

И довърших една книга, дето май всички трябва да прочетат.

(да, правя опити да пиша по-често)

На разни места още се среща идеята, че трябва да направим възможност за гласуване по internet (не говоря просто за електронно гласуване, с машини вместо бюлетини, което си има отделен набор проблеми).

От чисто теоретична страна има няколко нерешими проблема:

Купуването на гласове става още по-лесно. Ако хората могат да гласуват отдалечено, нищо не пречи на купуващите гласове да си setup-нат едно място за гласуване, където да се изреждат платените хора и да си подават гласовете. За такова нещо защити няма и няма как да има (това със следенето колко се гласува от един IP адрес е тривиално за прескачане, през tor или произволен ботнет). Не казвам, че в момента не е възможно (практиката показва обратното), но с internet-базираното гласуване нещата стават тривиални.

Става много трудно да се гарантира тайната на гласуването. Има две действия в системата – идентификация и подаване на глас, и е твърде лесно да се остави каквото и да е дребно нещо, през което да може да се свърже конкретен човек с конкретен глас. В съществуващата система нещата са достатъчно добре подредени и разделени, че по принцип да може крайния потребител (гласуващия) да види какво се случва и да е по-трудно да се реализира система за следене кой как гласува (и по-лесно за хващане). Аз лично не мога да измисля как в електронна система нещата могат да се разделят достатъчно добре и достатъчно добре доказано, че да е приемливо.
(изобщо няма да коментирам колко зле са ни крайните работни станции и дали няма да проима троянски коне, които да следят тия неща)

Другите проблеми – как се идентифицираш, кой ще пише софтуера, с какво приложение ще се гласува, колко/как ще се тества, дали/как ще се пусне кода – са в общи линии решими, но горните два при съществуващите технологии не виждам как ще се оправят. Аз поне досега колкото решения съм мислил или чувал, все съм намирал как ще се строшат, или в няколко странни случая решенията са твърде сложни за нормални хора (донякъде дори и за мен бяха).

Разбира се, изобщо не отказвам някой да ми обясни колко не съм прав и да даде примерна система, че така и така ми се чупи нещо :)

(алтернативното заглавие беше “мизерии, които правим като нямаме BGP”)

След доста мъки с onlinedirect в initlab си пуснахме втора връзка, през TBC.bg. За да можем да ползваме и двете, се наложи малко бърникане по setup-а и забавни неща, които съм описал по-долу, разделени на v4 и v6.

Преди всичко може да погледнете схемата на мрежата.

За IPv4 имаше два проблема: трафикът, влизащ от един доставчик трябва да излиза пак през него (нормален policy routing), и трябва по някакъв начин да се избира през кой интерфейс да се излиза (чрез gwping).

Policy routing-а е стандартен, описан е на хиляда места и за това без много подробности, идеята е че се прави routing таблица за всеки доставчик, в нея се вкарват пътя до самия доставчик, default през него и пътищата към локалните вътрешни мрежи, след което се слагат правила, че ip адреса от тоя доставчик изходящия трафик ползва определената таблица. Или, погледнато на cassie:

vasil@cassie:~$ cat /etc/iproute2/rt_tables|grep -v #
255     local
254     main
253     default
0       unspec

2       od
3       tbc

vasil@cassie:~$ ip r show table od
default via 93.152.128.1 dev eth0.5
93.152.128.0/17 dev eth0.5  scope link
172.31.190.0/24 dev eth0.2  scope link

vasil@cassie:~$ ip r show table tbc
default via 94.26.100.129 dev eth0.6
94.26.100.128/27 dev eth0.6  scope link
172.31.190.0/24 dev eth0.2  scope link

vasil@cassie:~$ ip rule
0:      from all lookup local
32764:  from 94.26.100.155 iif lo lookup tbc
32765:  from 93.152.143.66 iif lo lookup od
32766:  from all lookup main
32767:  from all lookup default

За изходящия трафик проблемът се решава чрез gwping (който намерих от тук и ми спести час-два писане на нещо такова). Това е прост скрипт, който ping-ва през двете връзки нещо определено (например google) и ако през едната го няма, я маха от routing-а, а иначе държи два default route-а с различна тежест, т.е.

vasil@cassie:~$ ip r
default
        nexthop via 93.152.128.1  dev eth0.5 weight 1
        nexthop via 94.26.100.129  dev eth0.6 weight 2
...

(докато чертаех схемата, едната връзка падна за малко и като гледам никой не го е усетил)

За IPv6 нещата се оказаха малко по-сложни (но по-изчистени), понеже свързаността ни идва от един тунел до моя машина в telepoint (бяхме на HE.net, ама ни омръзна да ни се отваря немския google). От там имаме една наша /64, която се появява във вътрешната мрежа на лаба. За да мога да прекарам тунела да работи и през двете връзки, просто пуснах два отделни тунела от cassie до tyler през двата доставчика, след което в/у тях пуснах с quagga OSPFv3. В него от страната на cassie announce-вам префикса на локалната мрежа, от другата страна – default route. В общи линии в конфигурацията имам следните неща:

cassie (тук вътрешния ми интерфейс е eth0.2):

interface vk-ipv6-od
 ipv6 ospf6 priority 0
!
interface vk-ipv6-tbc
 ipv6 ospf6 priority 0
!
router ospf6
 router-id 255.1.1.1
 redistribute connected route-map internal
 interface vk-ipv6-od area 0.0.0.0
 interface vk-ipv6-tbc area 0.0.0.0
!
route-map internal permit 10
 match interface eth0.2
!
route-map internal deny 20

tyler (тук външния ми интерфейс за IPv6 е eth1, а правя redistribute kernel, понеже default route се вижда като такъв):

interface lab-ipv6-od
 ipv6 ospf6 priority 0
!
interface lab-ipv6-tbc
 ipv6 ospf6 priority 0
!
router ospf6
 router-id 255.1.1.2
 redistribute kernel route-map external
 redistribute connected route-map external
 interface lab-ipv6-od area 0.0.0.0
 interface lab-ipv6-tbc area 0.0.0.0
!
route-map external permit 10
 match interface eth1
!
route-map external deny 20

Учудващо, но работи и даже не успях да си отрежа клона, докато го подкарвах. Има няколко дребни момента, например че OSPFv3 няма auth. на пакетите (или поне го няма реализиран в quagga) и ще му трябва ipsec в един момент, или че може да е по-интересно да вземем от двата доставчика IPv6 адреси, да ги раздаваме на потребителите и те да избират от кой да излизат (което ще е интересно да се тества колко добре работи, ако работи изобщо).

И ето едно описание на малкия ни streaming setup (използван по турнето и на OpenFest в по-малките зали).

Като за начало, ето картинката, по която ще се движим, в pdf и vsd формат.
На картинката имаме следните означения:
– червените линии са безжична връзка;
– светлосините – стерео по кабел;
– тъмнозелените – mono по кабел;
– тъмносините неща са бележки;
– бележката “OPT” значи нещо, без което можем да минем.

В бележките където има отбелязани жакове значат следното:
– 6.35мм, 3.5мм – моно/стерео, големи и малки жакове;
– RCA, известни при нас като чинчове;
– firewire – IEEE1394, още го ползваме да си връзваме камерата.

Компонентите са следните:
– аудио миксер;
– безжични микрофони, брошка и дръжка (AKG и HED в тая схема);
– слушалки (headphones) за наблюдаване и дебъгване;
– лаптоп за encode-ване и пускане на музика (опционално);
– озвучаване на залата (Room PA or speakers);
– камера
– amphony L1500 за безжично пренасяне на звук
– проектор
– лектор, с лаптоп
– мрежа

Идеята на цялото нещо е следната – в аудио-миксера се събира целият звук – лектор, въпроси, лекторски лаптоп, музика, и се пуска към озвучаването на залата и отделно към камерата. Не се използва атмосферния микрофон на камерата, понеже тя много често не е на място, което може да слуша добре звука (последният такъв опит беше първата VarnaConf, където звукът беше толкова зле, че записите в общи линии не стават).

За stream-ване звукът влиза в камерата от пулта, и през firewire се дърпа от encoding лаптопа. Задължително е да има слушалки на камерата, за да може да се прецени как е звукът, който влиза в нея.
Със звука на камерите има следния проблем – доста от тях имат AGC (automatic gain control) и когато е тихо, усилват до невероятна сила фоновия шум (тих брум от миксера или просто шума в залата). За това е важно на всичките камери да се намери къде е и да се спре, и да се настрои нивото на входа.

Setup-ът на лаптопа е доста забавен, и изглежда по следния начин:
Избира се някаква директория, в която ще се записва видеото, и в нея се създава named pipe, който да се казва av.m2t (разширението е донякъде важно). След това в два терминала (note to self – да го направя на един скрипт) се пускат следните неща:

dvgrab –format raw –size 0 – | ttee av.m2t log.`date +%s`.m2t
(ttee може да се свали от github, като там трябва един fix, ако се ползват 32битови машини да се компилира с 64-битов file offset, за да не гърми на 4GB файлове).

avconv -i av.m2t -v:c copy -a:c copy -f mpegts udp://10.99.0.1:2500
(вместо avconv може да се ползва ffmpeg, то реално е същото)

С малко patch-ване може трите да се сложат едно след друго (ако ttee плюе на stdout), но тогава трябва да му се спре output-а на stderr, че терминала се напълва с глупости.
avconf/ffmpeg изпраща stream-а до един централен encoder, който да го encode-не и прати до restreamer-а. Правим го, за да decouple-нем записа от encode-ването (щото записващите лаптопи са слабички, а и като спре stream-а да не се чупи записа), описано е в предишния пост.

На някои лекции трябва да се пуска звук от лаптопа на лектора. За целта този звук трябва да се закара от лаптопа на лектора (който е отпред) до пулта (който най-често е най-отзад в залата). По принцип една опция е да се пусне дълъг кабел (който обаче може да направи проблем с брум и като цяло да няма откъде да мине или да няма такъв), за това ползваме най-често едно Amphony L1500, което може да носи звук цифрово през ефира. То си има малки бъгове (понякога някакви неща на 5ghz му шумят, и също така трябва да има активност, иначе спира да предава и трябва да минат 3-4 секунди със звук, преди да започне да предава пак), но като цяло за тази цел върши много добра работа.
Най-крайният вариант (който много много много избягваме) е лекторът да си сложи микрофона на колонките на лаптопа.

На картинката има няколко опционални неща:
– звукът за лектора (не на всички им трябва);
– мрежата за лектора (пак така, някои са оптимисти и ползват wifi);
– слушалките на пулта – по принцип се чува достатъчно добре от озвучаването в залата.

Setup-ът, въпреки голямото описание е доста прост и отнема половин час за сглобяване и 10-15 минути за събиране. Използвахме го в този му вид за повечето конференции тази година, а подобен на него – за последните 3-4 години.

(мислех да oпиша първо как правим записите и stream-а в малките зали на Interpred, но там ще трябва да чертая схеми и ще ги оставя за по-нататък)

За да можем да гледаме събитието локално и по Internet, тази година направихме следния restream setup:

Навън (в delta.bg) имахме сложена една машина, наречена grendel, която имаше 10gbps порт и достатъчно свързаност, че да може да ни бута трафика (още ме е яд, че не минахме 1gbps, догодина може нарочно да пуснем fullhd 1080p stream само за това). На него имаше пуснат nginx с nginx-rtmp модула, който приемаше stream-а и пускаше на потребителите rtmp и HLS. Имахме също страничка, която можеше да показва видеото директно в browser-а и я показвахме в iframe на сайта на OpenFest.

Графика на трафика на restreamer-а.

Същият restreamer с nginx имахме и на router-а в самия Interpred, и там препращахме потребителите, които искаха да гледат локално (и overflow телевизорите/лаптопите). Препращането ставаше чрез split DNS, т.е. за stream.openfest.org връщах локалният ip адрес вместо този на grendel.
Нямам графика на тоя трафик отделно, в общи линии би трябвало да е разликата между външния интерфейс и вътрешния интерфейс на router-а.

На restreamer-ите нямаше ipv6, понеже така и не успях да накарам някой от моите клиенти да работи по v6 за rtmp и мисля, че щеше само да създаде странни проблеми.

В настройките на nginx-а няма нищо, което да го няма в default-ната конфигурация, та ще ги пропусна. Единственият по-куц момент е, че явно модула не е дописан и на повече от един worker нещата се чупят, т.е. реално трябва да се праща по един stream на всеки worker, което не е ясно как може да се направи, или да се допише така, че м/у worker-ите да може да се дели един stream (което значи да му се добави shared memory и да се пише внимателно).

Самите потоци с видео влизаха на eagle, и от там биваха пуснати до двата сървъра. От по-малките зали пращахме директно по UDP raw HDV потоците, а от зала София, поради възможностите на restreamer-а – RTMP.
Причината за UDP-то (което беше една много добра идея на Петко) е, че така се получава decouple-ване на софтуера, който изпраща и записва от този, който приема, т.е. ако умре restreamer-а в който и да е момент, записващата част няма да има проблем, и ако restreamer-а се върне, ще може директно да продължи да чете потока от мрежата.

За encode-ването използвахме ffmpeg, ето как (с някои дребни промени по url-тата):

ffmpeg -re -i 'udp://@10.3.0.1:2600?overrun_nonfatal=1&buffer_size=81921024&fifo_size=178481' \
	-c:v libx264 -s 1280x720 -profile:v high -level 4.2 -preset ultrafast -filter:v yadif -g 60 \
	-b:v 2000k -acodec aac -ar 44100 -ac 2 -bsf:a aac_adtstoasc \
	-flags +global_header -strict -2 -threads 2 \
	-f tee -map 0:v -map 0:a "[f=flv]rtmp://localhost/of/g1|[f=flv]rtmp://1.2.3.4/of/g1" \
	-c:v libx264 -s 854x480 -profile:v high -level 4.2 -preset ultrafast -filter:v yadif -g 60 \
	-b:v 500k -acodec aac -ar 44100 -ac 2 -bsf:a aac_adtstoasc \
	-flags +global_header -strict -2 -threads 2 \
	-f tee -map 0:v -map 0:a "[f=flv]rtmp://1.2.3.4/of/g1-low|[f=flv]rtmp://localhost/of/g1-low"

Тук има няколко интересни неща:
– Вдигнали сме буферите на UDP-то за приемане на пакети (и имаме същото нещо от другата страна, за изпращане). В първоначалните тестове (по време на setup-а YAPC::EU 2014) открихме, че UDP е наистина unreliable на default-ните буфери (около 256к) за толкова много трафик и губи достатъчно пакети, че картината да се намазва почти постоянно. Съответно след като с тестове се видя, че при TCP проблемът го няма, лесно се стигна до правилния извод и от тогава тия неща ни работят като слънце.
(интересното е, че на VarnaConf правихме тоя setup без да вдигаме буферите и работеше, и едното съмнение беше, че щото е бил прав кабела м/у двете машини и без никакви switch-ове нещата са били ок. По-вероятно ми се вижда просто някой буфер да е бил по default по-голям на тогавашния ни encoder (един лаптоп на Петко), но няма как да го проверим).
(тази опция изисква и да се пипнат едни sysctl-та по kernel-а, имайте го предвид)

– ffmpeg-а може да създава няколко потока от един вход, и да ги пуска на няколко различни места. Така от един поток можехме да пуснем low и high quality потоци и към двата restreamer-а, без да се налага да се слага нещо по пътя, което да копира пакети или потоци. Наложи се да компилирам една последна версия, че да работи добре, но не беше особен проблем.

– “-g 60” е keyframe интервала, което в общи линии определя колко бързо ще се покаже нещо при потребителя, след като събере някакви данни.

– “-flags +global_header” се налагаше, за да може да бълва rtmp като цяло през тия разчеквания. Не помня как го намерих :)

Като цяло, всичкото това ми отне около два-три часа четене.

За зала София се наложи да направим малка добавка – понеже ffmpeg-а не можеше да слуша на rtmp (т.е. за половин час с Guru не можахме да го накараме), засилихме потока от залата директно в локалния restreamer, и с ffmpeg си го взимах от там и го пращах нататък. Така вкарвахме още 20-тина секунди латентност в излъчването, но пък си решихме доста приятно проблема.

Като цяло този setup не направи никакви проблеми и си работи двата дни като слънце, eдинствено в overflow залите в началото пускахме големия stream от зала София (1080p на 5mbps) и това създаваше малко проблеми на декодерите.

(благодаря на Яна за корекциите по текста)

И ето го описанието на мрежата на openfest. Като цяло изглежда като проект за някой студентски курс по мрежи, няма нещо особено сложно или странно в него, описвам го основно за любопитните хора. Аз ще разкажа за жичната мрежа и топологията, Петко за wireless-а (като намери време и му писне да му мрънкам).

Като за начало, ето генералната схема, в pdf и vsd. Правих схемата на visio, понеже съм му свикнал и още не мога да му намеря еквивалент (а се оказва, че libreoffice вече го отваря).

Топологията беше следната: в “ядрото” (никаква идея защо се казва така) на втория етаж в Interpred влизат кабели до всички нужни зали. Там по принцип има switch на mtel/spnet/каквото-е-там, в който влиза връзката навън и самите зали.
Ние си сложихме там сървъра и един гигабитов switch (core-sw, cisco 3750). В него преместихме кабелите до всички нужни зали, а сървъра (който ни играеше и router) свързахме към техния switch за uplink, и към нашия switch по два порта за streaming vlan-а и за клиентите. В залите, където имахме wi-fi access point-и слагахме managed switch, така че да можем да си занесем дотам двата нужни vlan-а (management и този за потребителите), където имахме камери – също.

Имахме следните vlan-и в мрежата:
600 – management (за нашите си устройства), 10.0.0.0/16
601 – wifi, 10.1.0.0/16 и 2a01:288:4000:32::/64
602 – wired (потребителски портове по switch-овете), 10.2.0.0/16 и 2a01:288:4000:33::/64
603 – streaming (наша техника, пускаща суровите потоци с видео), 10.3.0.0/16
604 – TV (overflow-ове – телевизори и т.н.), 10.4.0.0/16

Толкова голяма мрежова маска за ipv4 при rfc1918 адреси е ок, понеже фоновия трафик от сканирания от internet-а го няма, че да бълваме broadcast трафик постоянно. Имаше проблем с друго, който ще опиша по-долу.
Имахме ipv6 само за потребителските мрежи, по мои наблюдения доста от нашата техника има проблем да си говори с тоя протокол все още, а мотото на setup-а беше “минимални рискове”.
Използвахме нормално per-vlan STP, като беше спряно за VLAN-а на wifi-то, а всички портове бяха в portfast (или какъвто-е-там-еквивалента-извън-cisco) режим. Радвам се, че не ни се наложи да борим цикли или каквото и да е, свързано с него…

Адреси се раздаваха по DHCP за ipv4 и по RA за ipv6.

За да намалим натоварването на външната връзка, със split dns заявките за ip адреса на stream.openfest.org им се отговаряше с адреса на локалния сървър, където имаше същите потоци.

Самия restreaming setup изглеждаше по следния начин:

Трите камери/streamer-и изпращаха до сървъра потоци на голям bitrate/разделителна способност – двете по-малки камери директно HDV потока по UDP, 1080p на 25mbps, setup-а от зала София – 1080p на 5mbps, H.264. На сървъра се reencode-ваха до два формата и се пращаха до големия restreamer (който имаше 10gbps порт) и до локалния сървър, от който също можеха да се гледат. За да няма смесване на този трафик с каквото и да е, всичката A/V техника си имаше отделен VLAN, който беше отфилтриран, така че да не може да влиза в него чужд трафик.

Понеже нямах много вяра и на overflow техниката (и е тривиално да се DoS-не raspberry pi) всичките телевизори бяха в собствен VLAN. На практика, имаше firewall който казваше, че трафик от потребителските мрежи може да излиза само от eth0, не можеше да ходи по нашите vlan-и (600,603,604).

Няколко думи за мрежовата ни техника:
core-sw и sof-pocket бяха две гигабитови cisco-та от netissat (любими switch-ове са ми това, работят идеално, ако се ползват правилно);
quanta беше домашният switch на Мариян, 48-портов гигабитов manageable;
reception-sw беше linksys SWR224G4, който заедно с един SRW2016 (двата от Благовест) ми изпили нервите – не му работеше web контрола, менюто, дето се виждаше по telnet не можеше да настройва VLAN-и, и накрая се оказа, че ако човек се логне, натисне ctrl-z и пусне lcli, там се появява едно доста използваемо cisco-подобно cli, от което всичко става лесно (думи не могат да опишат колко съм благодарен на тоя човек);
Няколко switch-а по залите бяха TP-Link SG-3109 (дойдоха от Unex през StorPool), и направо ми спасиха живота – малки 8-портови manageable, със сериен порт, със същото cli като lcli-то на linksys-а, направо песен за подкарване (чак ми се иска ако намеря такива на нормална цена, да купя 5-6, ще са незаменими за някои събития);
още едно 3750 (от Леков), което отиде за една от залите, понеже дойде в последния момент;
един DLink (от Благо), който замести linksys SRW2016 (пак от Благо), като unmanaged switch за стаята на екипа.

Като цяло крайни потребители се закачаха само в стаите за workshop-и и в team стаята, както и лектора в зала G1 (а трябваше и в другите, ще знаем за догодина).

Следват малко картинки, след което ще разкажа как протече работата на мрежата и какво трябва да направим догодина:

grendel (restreamer-а ни, който ни дадоха Delta.bg):
eth9 – сумарен трафик на порта, през който се stream-ваше за света;

router (eagle):
CPU;
eth0, uplink навън;
connection tracking – статистика по типове връзки;
Power – колко мощност е дърпало захранването на сървъра (не е много смислено, но е забавно);

И от два switch-а, понеже за другите не ми остана време да пусна cacti:
core-sw:
Gi1/0/1, вътрешен порт за потребителския трафик;
Gi1/0/2, streaming VLAN;
Gi1/0/3, зала Пловдив;
Gi1/0/4, зала София (джоб);
Gi1/0/6, зала Бургас;
Gi1/0/7, зала G1;
Gi1/0/8, зала G2;
Gi1/0/9, зала G3;
Gi1/0/10, зала Варна;

sof-pocket-sw:
Gi0/2, рецепция на зала София;
Gi0/3, зала София, десен access point (OFAP02);
Gi0/4, зала София, ляв access point (OFAP00);

Уникални MAC адреси:
1 ноември – 557;
2 ноември – 553;
Общо за двата дни – 769;

MAC адреси по производител, първите 10 (благодарение на Точо, който го изсмята):
Apple 121
Samsung 108
Intel 93
LG 75
HTC 49
Murata 38
Sony 38
Hon Hai 32
Motorola 27
Nokia 24

Вдигането на мрежата мина нормално, само с няколко грешки (основно мои, липсващи vlan-и по switch-ове и някакви промени в последния момент). Кабелите бяха пуснати сравнително лесно, като за това помогна, че не ни беше за пръв път (Явор беше опъвал част от тях по същите места в предишните поне две години), а за останалите имахме достатъчно помощници и клещи. Само един switch беше конфигуриран там на място, тоя за зала Бургас, понеже тогава ни го дадоха (Пешо седя в един ъгъл с кратък списък изисквания от мен и го човърка). Въпреки някои забавяния, мисля, че самата мрежа беше съвсем по график и беше пусната най-лесно, въпреки относително многото хамалогия. Единствените неща, което настроих в петък вечерта в заведението, в което ядохме, бяха IPv6 (понеже не беше толкова приоритетно) и да добавя останалите устройства в icinga-та (която така и не гледахме).

Имахме няколко проблема по време на събитието:

Имаше доста broadcast трафик от arp пакети, за клиенти, които са били асоциирани, после са се разкачили и изчезнали от arp cache, но отвън още се опитват да им пратят нещо. Решението, което сглобих, беше да вадя списък на всички изтекли dhcp lease-ове (чрез някакъв perl скрипт, който намерих в github), и за всички тях чрез conntrack tool-а да трия всичкия им съществуващ state. Не съм сигурен доколко помогна, вероятно тоя broadcast не е бил толкова много така или иначе.

Имаше няколко случая на arp spoof, до които не се добрахме (срам);

В един момент решихме да вдигнем worker-ите на nginx-а на restreamer-а и се оказа, че просто rtmp модула не се оправя с повече от един worker. Това е нещо, което трябва да debug-на за в бъдеще.

И най-идиотския проблем – спираше ни ipv6. По някаква причина от време на време просто сървъра и спираше да отговаря на ipv6 пакети, и да ги route-ва, като все още нямам обяснение защо и не е проблем, който съм виждал където и да е другаде, но със сигурност поне 80% от оплакванията, че не работи wireless-а идваха от android телефони, които просто се опитваха да минават по v6. В списъка ми е да го проверя от какво може да е било, обмислям да изтормозя някой от съществуващите ми v6 router-и и да видя дали мога да го репродуцирам.

За следващия път съм си отбелязал следните неща:

Работещ ipv6 :) (Петко предлага да сме само по v6, но това не звучи като добра идея);
Да отделим хора за NOC, които да следят мрежата и да хващат проблеми (arp spoof-ове и т.н.);
По-подробен monitoring (който да го гледа NOC-а);
Никакви switch-ове и подобни, които отнемат над половин час, за да се подкарат;