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

(това съм го написал преди няколко месеца и тотално съм забравил да го кача)

Тази година направихме доста по-сериозен setup за видео-записа. За малко начална информация, може да видите схемите за зала “България”, камерна зала и студио “Музика”.
(или доста по-артистично нарисуваните от Guru схеми за зала “България” и камерната зала)

Изискванията ни тази година бяха доста по-високи от предишните:
– Възможност за гледане на камерата или директно на сигнала от лектора, за всички зали;
– За двете по-големи зали, възможност да се снима задаващия въпроса от публиката;
– Пак за двете по-големи зали, контрол от видео-миксера какво излиза на изхода на проектора;
– Поне 720p разделителна способност на записа;
– Full HD (1080p) stream от зала “България”;
– Стерео-запис и стерео-звук от зала “България” (които не се използваха, защото лекцията, на която се очакваше да трябват отпадна в последния момент);
– Запис на случващото се на сцената (свирещите музиканти) в зала “България”;
– WebM stream (което отпадна, поради липса на време и мощност за encode-ване).

Всичките ни setup-и имат следните общи идеи:
– Всичкият звук се събира в един аудио пулт, от него се изважда звук до озвучаването на залата и до една от камерите (която маркираме като primary камера). Това се прави, за да сме сигурни в синхронизацията на звука и видеото (иначе има шанс да се получи един-два кадъра разсинхронизация на звука и видеото, което е доста дразнещо);
– На primary камерата се държеше memory карта, на която се правеше backup запис;
– В зала “България” през миксера минаваше и intercom-а, чрез който се комуникираше с операторите;
– По принцип в залите разполагахме камера за близък план (да снима лектора), общ план и към публиката (т.е. към задаващите въпроси);
– Всичките видео източници – видео камери, лаптоп на лектора и т.н. – се настройват да изваждат същата разделителна способност на същия refresh rate, и се вкарват в един видео миксер (някакъв ATEM), по SDI или HDMI (за по-близките). За целта камерите се настройват на същото нещо, а за лектора на лаптопа се слага scaler, който да може да приеме различните входове и да сгъне сигнала.
– От видео-миксера се изважда сигнал за запис (основно на atomos ninja или нещо подобно), сигнал за restreaming, в две от залите – сигнал до проектора.
– Streaming-а се изпращаше до един сървър, към който се закачаха reencoder-и, за да изкарват stream-овете с различните качества.

Зала “България” беше на 1080i60 (t.e. 1920×1080, 60Hz), другите две зали на 720p60 (1280×720, 60Hz). Честотата се подбира така, че да не се получава мигане, ако камерата вижда екрана (което миналата година беше сериозен проблем в записите). Разделителната способност беше такава, понеже в двете по-малки зали scaler-а можеше да изважда 1080p или 720p, а видео-миксерите не поддържа 1080p като вход.

Тази година за setup-а имаше доста улеснения, които си направихме по време на подготовката:
– Макари с навити кабели, които лесно да могат да се разпънат (и после съберат);
– Готово dolly за камера, така че сравнително лесно да може да се мести;
– Изтестван и лесен интерком до камерите;

За съжаление имахме доста проблеми при setup-а и се наложи да откараме до около 1:30 на място, за да ги изчистим. Доста от техниката ни пристигна след 9, имаше концерт в камерната зала, имахме на няколко пъти проблеми с тока от различни фази на съседни контакти, и имаше няколко сложни неща, които се наложи да правим (включващи катерене по стълби и инсталация на техника по тавана в едната зала).

Има нов set видеа от openfest 2015, които могат да се намерят в youtube или в нашия архив. Нещата са от първия ден на феста от зала България, като имаме отделно музиката, която се свири в главната зала (youtube или нашия архив).

Остават още 11 лекции, и има проблеми с още 2, за които ще видим дали можем да направим нещо. Извинявам се за забавянето (което си е съвсем по моя вина).

Около CCC се видях с хората от FOSDEM, споменаха ми, че имат нужда от хора за видео екипа, та преди няколко дни се замъкнах там, с Марио, Маги, Любо1 и Любо3 …

FOSDEM е интересно събитие. Името идва от Free and Open-Source Developers’ European Meeting, и си е точно това – събират се огромно количество разработчици на различни проекти и си разказват разни неща. По случая има 25 зали, като повечето от тях са DevRoom-ове, т.е. ориентирани към един проект. Това, комбинирано с мястото – кампусът на ULB, т.е. няколко разпръснати сгради в различна възраст и вид (от такива, каквито може да очакваме в провинциален изпаднал български “университет” до хубави и лъскави такива) създаваше доста проблеми…
(сумарно по една сметка е имало около 618 лекции)

Като цяло, моето преживяване там се състоеше от три дни ранно ставане (6:30 си е гадно даже по CET), носене и дебъгване на техника напред назад (в събота имаше за добавка много дъжд и по едно време якето ми беше повече вода, отколкото яке) и малко писане/дебъгване на други работи. Понеже самите devroom-ове осигуряват някакви хора да се грижат за самото протичане на лекциите и т.н., има идеята те да се занимават с оперативната част на аудио и видео нещата, но нещо не се получаваше.

FOSDEM-ският setup за видео/аудио е доста интересен. Това е схемата на setup-а на една зала, идеята е следната – дават се две кутии (доста приятно изглеждащи, от дърво, рязани на лазер, изглеждат така), като в едната се включва лектора, в другата – камерата. Микрофоните и т.н. озвучаване от залата се включват в камерата, и самата камера на единия си канал вади този сигнал, на другия – звукът от нейния собствен микрофон. Двете кутии по отделно пускаха по 2mbps h.264 stream до централно място и го записваха при себе си, а на края на деня записите от тях се преточваха до централно място. Гледането на stream-а беше гледане на двата паралелно, а записите ще са двата stream-а, смесени по определен начин (вече има някакви качени на сайта).

Проблемите бяха доста:
– софтуерът, който трябваше да контролира кутиите (в тях имаше едно bananapi с linux) се оказа счупен, в петък ремонтираха някакви неща, но записите от събота сутрин поне за момента ги няма, а streaming-а припали в неделя по някое време.
– При 24 зали и 25 камери (една резервна) нямаше как всички да са еднакви, и три от тях бяха доста неприятни. Като цяло имахме 3-4 различни модела, с някакви странности (част от тях си забравяха настройките при падане на тока). Всички бяха вързани на HDMI, което донякъде улесняваше процеса.
– Пак при тия 24 зали нямаше достатъчно информация за хората в тях как да оперират камерите, което и вероятно ще си проличи на записите.
– Звукът се осигуряваше от екипа на университета, и там имаше доста трагични моменти, например всички безжични микрофони в една сграда да са на същата честота. Също така не бяхме успели да изтестваме всички камери директно по залите в петък, и се оказа, че на някои места звукът идва на line, на други – на mic ниво.
– Като цяло видео екипът беше малък – имаше голяма нужда от още хора, ние петимата бяхме половината екип и не ни остана много време да седнем. Не помогна това, че всичко ни беше в една сграда (която е в единия край на кампуса) и трябваше да ходим до останалите всеки път, като се налагаше да се види нещо.

Имаше и разни хубави неща (които може да се опитаме да направим и при нас):
– Имаха много добри walkie-talkie-та, които бяха по tetra – цифрови, без шум, и в общи линии се чуваха спокойно по целия кампус. Имаше малко хардуерни проблеми с някои от тях, но като цяло бяха супер и ми се ще да ги ползваме за следващия openfest (но ме е е страх да проверявам цени).
– Това с опростяването на video setup-а е стъпка в правилната посока, трябва да измислим и ние нещо такова (но малко по-гъвкаво).
– Имат доста хубав setup за encode-ване, а ако бяха подкарали системата за рязане, при която самите стаи си отбелязваха края и началото на лекция, щеше да е страхотно.
– Доста от координацията я правехме с един piratepad, в който се отбелязваше текущия статус, какво кога следва и разни графици. Вършеше добра работа.

(както винаги на събития, на които съм в организацията – не съм гледал нито една лекция)

Update: Снимка от прибирането, банда полузаспали хора.

Кодът, който пиша е грозна работа и пълен с hack-ове. Явно така ми харесва :)

Това е кодът, който контролира лампите по фасадата на лаба. Потрил съм малко от от вътрешната информация в него, като просто исках да се спра на няколко забавни неща в него.

Редове 11-18 се занимават с това да сменят статуса на лампите. Това, което правят е просто да сменят статуса на релетата на netcontrol-а, id-тата са от 13 до 15 включително (което отговаря на релета от 5 до 7, втория set в устройството).

Редове 20-39 се занимават с взимането на текущия state на системата:
– ред 23 взима дали е ден или нощ, от една малко patch-ната версия на sunwait. Сметката е сравнително проста, има я описана на доста места и се оказа един от най-лесните начини. (очаквах да има директно инструмент в debian, дето да ми го каже, но не открих такъв)
– ред 24 взима дали лампите са светнати, като взима статуса на едно от релетата. Това е малко некадърно, понеже поглежда дали е светната само една от лампите, но ме мързи да измисля по-приличен начин, който да лови неконсистентно светнати лампи. Също така това може да се направи доста по-човешко, без cut и awk.
– редове 26-29 питат контрола на входната врата дали е заключена или не (системата е описана във wiki-то на лаба).
– и редове 31-37 проверяват дали trigger-ът за форсиране на светването на лампите е вдигнат (който е един файл в /tmp)

Редове 41-44 са функция за печат на текущия статус, в общи линии за debug-ване.

Редове 47-53 инициализират един пакетен unix domain socket, който е в общи линии нещо като UDP socket – лесен начин за получаване на отделни съобщения. Инициализираме го за получаване, връзваме го във файловата система и го правим nonblocking.

На ред 56 ни започва главния цикъл.

В началото на цикъла се възползваме от socket-а (редове 57-61), като изчакваме или да се появи нещо на socket-а, или 60 секунди, което се случи по-рано. В първоначалната версия socket-ът го нямаше и имаше просто sleep(60), но така се налагаше да се изчака всеки път sleep-а, преди да се промени нещо. Така е възможно когато fauna-та получи информация, че вратата е отключена, да форсира демона да препровери състоянията и да светне лампите.
Тук може четенето от socket-а да се прави, докато не остане нищо в него, за да можем да се предпазим от DoS-ване, заедно с някакъв минимален timeout.

Нататък (редове 63-66) взимаме текущото състояние и dump-ваме малко информация.

На редове 68-70 правим проверка дали спрямо предишното състояние се е променил статусът на ключалката, и ако се е случило, отбелязваме кога. Това ни помага малко по-нататък.

Редове 73-84 хващат моментите, в които лампите са включени:
– Ако е ден и не сме форсирани от trigger-а, гасим лампите;
– Ако е нощ, вратата е заключена, не е вдигнат trigger-а и са минали 15 минути от заключването, гасим лампите. Така човек може да си тръгне спокойно от лаба и да не се пребие в тъмницата, като му угаснат лампите веднага като заключи.

Редове 86-97 обработват ситуацията, когато лампите са изключени:
– Ако trigger-ът е вдигнат, палим лампите;
– Ако е нощ и вратата е отключена (т.е. има хора в лаба), палим лампите.

Системата е кратка, цялата е един hack и работи прекрасно. Интегрира се лесно със съществуващите друг системи в лаба и ни дава още една доста полезна функционалност, и ни спестява да се сещаме да включваме лампите, когато навън е тъмно и railsgirls имат да идват към лаба :)

Човек и добре да живее, трябва да прави интервюта.
(и после почва да живее зле)

Писал съм преди за интервютата, дето правих, но не очаквах нещата да станат по-зле… От известно време в securax си търсим php и js програмисти и QA, в чиито интервюта участвам, и идват всякакви интересни хора.

Процентът хора, кандидатстващи за програмисти и неспособни да напишат fizzbuzz се е увеличил. Освен стандартните грешки в самия код, имаше един-двама човека, които казаха, че “това без internet не могат да го напишат” и един случай, в който седнаха да пишат очаквания output вместо програмата, която да го прави.
(рекордът беше днес, когато след като дадох на един човек задачата, той просто си тръгна с някакво оправдание)

За QA и понякога за програмистите имаме един тривиален тест с няколко математически/логически задачи, да ги видим как/дали мислят и дали разбират английски (което си е доста важно при нас, понеже някаква част от фирмата не говори български). Откриват се всякакви странности, например:
– едната задача е да се сметне ако нещо с ДДС е 600 лв, колко е без (ДДС-то е 20%). Редовният отговор е 480, и имаше два куриоза – 400 и 576.
– друга задача гласи “One brick is one kilogram and half a brick heavy. How much does a brick weight?”. Повечето хора казват или един килограм, или килограм и половина, а много директно не могат да си преведат цялото изречение и си мислят, че им се казва “една тухла тежи един килограм”…
– има няколко глупави въпроса като от обща култура, които нямат голям смисъл, но водят до забавления. Единият е “Who was the first person in space”, на което двата ми любими отговора досега са “Louis Armstrong” и “Adam”.
(и сигурно ще сменя тия задачи, че вече са ми скучни)

В повечето случаи изобщо не се стига до по-сложни въпроси (алгоритми, сложности, някакви практически проблеми, fizzbuzz без if-ове), просто защото не са по силите на човека. Идея си нямам дали само при нас е така, или просто аз помня само ужасяващите случаи, някой има ли наблюдения по въпроса?

Днес свършихме още едно добро дело за initLab – доподкарахме системата за лампите по фасадата.

Цялата работа тръгна от това, че на ул. Рила (на която е лаба) в голяма част няма осветление, което притесняваше хората, които трябваше да идват/да си тръгват по нощите. Преди година-две писахме на общината, отговориха ни, че някой хубав ден ще сложат, прехвърлиха топката към някаква фирма за общински поръчки и нещата така си останаха. В един момент Пешо каза, че те 10-20-30W LED лампите не харчат много ток и светят достатъчно силно, не пречи да сложим ние малко лампи и да осветяваме улицата.

През лятото си взехме стълба, лампи и в рамките на седмица-две монтирахме лампите, заедно с ключове, с които да се светват. Понеже сме мързеливо племе (и в автоматизацията е истината), сложихме на всяка лампа по едно реле, и с един neomontana netcontrol си навързахме управление да си палим автоматично лампите. Днес подкарахме целия проект, който си има страничка във wiki-то, и някой ден може да се навия да кача source на контролиращото нещо (от което за сега има само screenshot, понеже е някаква адска гняс от shell script и php).

(от забавните неща, patch-нах си малко sunwait да ми казва дали е ден или нощ)

ИББ на 20.01.2016 ще бъде в Кривото на НДК (защото ще се прави ремонт в това на “Дондуков” и “Будапеща”), запазени са места от 19:00. Седмицата след това пак сме си в старото.

Добрите хора, дето анализират активните проби на големия китайски firewall са пуснали инструменти за преглеждане на логове – bz2 или директно git clone https://www.bamsoftware.com/git/active-probing.git . Няма лошо да свалите и да тествате дали се намира нещо по вашите логове, ако е много, може да питате researcher-ите дали ще им е полезно :)

За някои типове логове се налага малко пипване, например в grep-garbage-http.py да се пипне regex-а да е

combined_log_re = re.compile(r'^([\w:._-]+) ([\w._-]+) ([\w._-]+|"[\w._-]*") \[(.*) ([+-])(\d\d)(\d\d)\] "(.*)" (\d+) (\d+|-) "(.*)" "(.*)"')

(маха се $ накрая, понеже в моите логове накрая се сипва vhost-а)
За един друг тип логове направих

sed 's/^[a-z0-9:.]* //' 

за да почистя от началото vhost:port (понеже се оказа, че имам и такива)

Едно от нещата, с които се занимавам, е да помагам на Общество.бг с разни админски дейности.

opendata.government.bg е един от техните проекти, който след доста мъки се deploy-на в държавната администрация, и има някакво количество проблеми с хостинга си там (например падаше около DDoS-овете около изборите). Днес в един момент видях някакви аларми на monitoring-а за машината и открих, че ми е доста трудно да се логна, и се зачудих дали няма някой нов DDoS, и на smokeping-а ситуацията изглеждаше зле.

Порових се малко и въпреки сериозното натоварване се оказа, че (учудващо) CKAN-а (който е писан на python) явно удържа на напора и сервира спокойно каквото му искат хората. В крайна сметка бяхме успели да претоварим shaper-а на виртуалката (или знам ли, целия host), което май има шанс да се оправи тия дни.

По-интересното обаче беше причината – за пръв път публикувана и систематизирана на едно място информацията за проверените агенти на ДС. Мен лично ме радва как интересът към това не спада, и че въпреки че се чуват гласове “какво от това”, че данните не са точни, не са пълни и т.н., те са добра стъпка към запомнянето на миналото и историята.

Надявам се да има още такива данни, които да предизвикат интереса на хората :)

И кратка равносметка на 2015:

– Приключих с първия пас на редактирането на Reverse engineering for beginners, и може да помисля за втори в/у новите неща, които са се появили.
– Правихме пак курс по сигурно програмиране, след който заедно с още няколко неща там вече нищо общо не искам да имам с ФМИ.
– Направих нов не-курс, този път си сглобихме малко ISP, като някаква част от setup-а му остана за net-а на initlab.
– Пуснах ipv6 тунелен брокер за разни хора, дето си нямат ipv6 у тях (и вече някои от тях правят странни топологии :) ).
– Направихме доста събития от турнето;
– Случи се openfest 2015, където с Яна бяхме главните координатори. Не беше леко преживяване, и още не съм си подредил мислите по въпроса. (Видео-записите – скоро).
– Почнах пак работа в securax, като още ме е срам да казвам, че се водя мениджмънт (и за да компенсирам, админствам малко неща).
– Направих една лекция, и написах една друга до средата. Мисля, че трябва да отделя малко повече време в писане.
– Пак не блогвах достатъчно.

(мислех да кача малко снимки, дето съм правил на 32c3, но повечето са на бутилки от whisky workshop-а)

И последен ден на конгреса.

(личеше си, че някакво количество хора са си тръгнали, стана по-хладно и имаше повече въздух за дишане. Това 1.2mw топлина не си е работа…)

Почнах с лекцията за searchable encryption, която обаче си беше доста слаба – нямаше нищо ново и като цяло беше представена лошо.

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

Infrastructure review ми е от любимите лекции на тия събития и тая година не ме разочарова – пълно беше с интересни неща за различните части от инфраструктурата, за проблемите, които са имали и трудно може да се предаде с няколко думи, просто я гледайте :)

Закриването ставаше, като цяло нямаше много информация в него (малко статистики, но не казаха къде ще е събитието догодина).

Следват няколко дни почивка в Хамбург и прибиране към София.

Ден трети на 32c3.
(да отбележа, пиша това след whiskey workshop-а по събрани бележки)

Започнах деня с “In)Security of Embedded Devices’ Firmware – Fast and Furious at Large Scale” – лекция, в която се обясняваха методи за събиране и статичен и динамичен анализ на големи количества firmware за различни устройства. Като цяло доста полезно, въпреки че разчита доста, че повечето неща са linux-базирани (което си е така в твърде много от случаите).

Последваха две лекции за TOR. Първата беше по темата hidden/onion services (сменят термина), като най-накрая ще има hidden service на един hop в мрежата – т.е. ако просто се знае кой сте и искате да предоставяте услугата в мрежата, може RP (точките, през които се свързват с вас) да са ви наблизо, а не на 3 hop-а (което доста забързва нещата). Също така сменят малко алгоритми и се очертава .onion адресите да станат доста по-дълги и трудни за помнене.
(в този или следващия talk споменаха за RFC-то за .onion домейна, което си е доста добро постижение за проекта)

В “state of the onion” разказаха за какво се случва в проекта, организацията му и че са пуснали първата си кампания за набиране на средства.

Лекцията за “Gibberish detection” беше доста интересна и даваше следващото средство в arms race (някой да ми намери превода на български) с борбата със спамещи domain-и и подобията им, метод за разпознаване дали дадено име е “смислено” или някаква глупост. Кодът им го има в github, и ще е интересно да се интегрира в wiki-та и подобни системи.

“10 years after “We lost the war”” иска отделен blog post. Гледайте през relive и мислете по въпроса, а аз ако намеря някъде текста, ще го публикувам с коментари. Не просто си заслужава да се чуе (и да се изтърпи, понеже на моменти е бавна), директно си е важна, понеже това е лекция от типа “как да променим света” (от смислените такива).
(също така, note to self, да напиша нещо по темата utilitarian use of power, което е проблем, който аз самия имам)

Не гледах нищо повече от деня, понеже говорих с разни хора по разни теми (например по работа с хора от TOR, дано излезе нещо), последва whiskey workshop-а, на който си харесах разни неща, които съм снимал и ще кача тия дни.

Ден втори на конгреса. Забележителен с това, че пих две кафета и пак ми се спеше.

Начална важна новина, хората от предния ден, които говореха за големия китайски firewall ми писаха обратно и казаха, че тоя тип логове (активните заявки от firewall-а) са им интересни, та който има логове от повечко време на webserver-а и иска да свърши едно добро дело, нека да ми пише да му дам малко pattern-и и в един момент списък адреси, за които да се погледне :)

Започна с “State of the internet censorship”, като описаха накратко различни държави, спряха се на методите за изследване (накратко, инсталирайте си ooniprobe) и че в момента има работна група в IETF, която да реши/специфицира дали както има Security секция в RFC-тата, да има такава за влиянието на протокола в/у неща като човешки права, цензура и т.н..

Следваха lightning talk-ове, в които имаше няколко интересни неща:
holocm, което трябва да разгледам по-внимателно, проста configuration management система;
nfc.wtf, app за android за работа/атака с nfc четци и карти;
Story-based hacking challenge е идея за стандартния тип hacking challenge, но с интересна история, да зарибява повече хората (темата за историите съм я споменавал, това звучи като доста добра идея), и
RobustIRC, интересна идея за irc клъстер, който да не пада и да не се split-ва, трябва да издиря хората и да видя дали не мога да deploy-на нещо такова.

Brain-computer interfaces лекцията не беше особено интересна, в общи линии нищо ново – каза се, че има такива устройства (в общи линии ЕЕГ апарати) и че има OSS разработки за тях.

Лекцията за Apertus Axiom беше интресна, хората разработват open hardware професионална/полупрофесионална видео камера и са стигнали доста далеч, но за момента все още имат само 3 бр., които са за development. Надявам се, че за още една година ще имат нещо съвсем работещо и в някакъв момент ще се намери начин и цената на камерите да слезе в някакви нормални граници (или да ни услужат за тестове около OpenFest…).

Гледах лекциите за Франция и Еквадор, но първата малко я проспах, щото имах работа, втората не беше нещо особено (в общи линии там режимът изглежда малко по-неприятен от българския).

Perl Jam лекцията беше най-смешната на тоя конгрес (не вярвам някой да успее да я стигне). Лекторът показа exploit в тривиален код (който дори е от стандартните примери на CGI.pm) и разни недомислици в езика (като имплицитното вярване на данните от hash-ове и масиви). Леко прегракнах от смях…

Лекцията за атаки в/у VoLTE (Voice over LTE) се оказа интересна, най-вече защото ми запълни някои неясноти около стандарта (по някаква причина си мислех, че е нещо като телефонията при gsm, а то се оказа просто един SIP в/у по-гарантиран канал). Атаките са много близки до това, което е известно от VoIP-а (например можеш директно да си говориш с някой чужд телефон в същата мрежа и да си казваш каквото си искаш caller-id) и като цяло изглежда, че телекомите не са съвсем наясно с IP-то и какво може да се прави с него. Още по-забавно е как за един тест засилили малко повече SIP INVITE-и към IMS-а на един телеком и той леко се шашнал…

И завършихме деня с гледане на “goto fail”, лекцията-обзор на проблемите на TLS (избрано подмножество от тях, за всичките вероятно няма да стигнат няколко дни). Доста полезно за всички, които не са наясно колко трудна е криптографията (не толкова сложна, колкото пълна с доста опасни проблеми) и които не са запознати с това колко трагичен е TLS-а (и как нямаме нещо по-свястно).

Първи ден на 32c3.

(пристигнахме вчера, нямаше проблеми с пътуването, даже си намерихме маса за assembly-то, като ни комбинираха с Balccon хората)

(който е изпуснал нещо, може да го гледа на relive)

Откриването беше леко дървено, с двама човека, четящи от листчета, като най-важната част беше, че е добре да се спазва принципа за 6 часа сън, 2 яденета и 1 душ ВСЕКИ ДЕН.

Keynote беше странен, някаква бежанка говореше някакви неща, но аз издържах 10-20 минути и излязох, понеже нищо от това не ми звучеше релевантно към конгреса или изобщо да ми е интересно.

След това Joana Rutkowska направи една лекция на темата stateless laptop. Като малко background, след като се занимаваше да прави PCI rootkit-ове и да чупи какво ли не, седна с някакви хора да разработва Qubes OS, което е в общи линии сериозно компартаментализирана операционна система с някакво интересно ниво на сигурност. В talk-a обясняваше за проблемите на X86 и като цяло как може да се направи stateless laptop, който да може да се пази от това някой да намаже firmware с нещо неприятно. Има post в блога ѝ с paper-а по темата, и две други интересни неща от лекцията ѝ бяха книгата от intel за какво мислят/могат да правят със ME и че някакви хора работят в/у open-source SSD.

Лекцията за red star OS изтървах, понеже се заговорих с разни хора, та може да пиша за нея по-нататъка.

“How the Great Firewall discovers hidden circumvention servers” беше интересно, като по външни наблюдения как изглежда, че големия китайски firewall намира tor node-ове и т.н.. Нямаше нещо много гениално, но имаха идея как може да се разпознаят връзките от там, които тестват дадена услуга, и дори открих няколко в моите логове (питах ги дали може да са им полезни и им пратих sample). Ако проявят интерес, може да grep-ваме малко. Повече информация има в paper-а им.

“The Great Train Cyber Robbery” беше в някои отношения лекция за влакови ентусиасти. Имаше описание на системите, които се използват за контрол на железопътните мрежи, и стандартното описание на сигурност, от която и преди 15 години щеше да ни е срам. Липса на криптиране, default-ни пароли, buffer overflow-ове и всичките подобни работи.

“Build your own 3G network” беше интересно най-вече от гледната точка колко ужасяващи неща се налага да се допишат, за да има работеща 3g мрежа – купчина протоколи, ужасно усложнени системи, слаба стандартизация, като цяло нормалните телекомски неща. Някой хубав ден може и да пуснем такива мрежи, като вече всичко е минало на LTE:)

Shopshifting лекцията беше съвсем очаквано доста притеснителна. Накратко, протоколите за комуникация м/у терминала и payment processor-а позволяват тривиално да се правиш на друг терминал, или да се пъхаш м/у терминал и каса, като една съвсем проста атака позволява да се направиш на POS терминала на който си искаш и от него да refund-ваш пари в някаква карта. Силно си заслужава да се гледа.

Последната лекция, за Post-quantum cryptography я гледахме от хотела. Генералният ми извод е, че това, което имаме в момента е много далеч от реално приложения, за да замести RSA и DH – огромни ключове, при системата за подписване и са stateful (т.е. части от ключа могат да се ползват само веднъж). Депресираща работа.

p.s. Валяк, взел съм ти тениска.

Забил съм се в една огромна книга (реално web серия, някъде около 4000-5000 печатни страници) и за почивка пиша нещо за нещата, които четох тая година и си струват да бъдат отбелязани.
(това е пълният списък)

Темата за Алан Тюринг ми беше доста интересна, след като ме накараха да гледам силно некадърният филм за него (официалната му биография).

Доста странна беше книгата на Norah Vincent, “Self-made man”, за експериментът ѝ да се облича като мъж и да се представя за такъв. Доста е интересно, и не само защото след това е изпаднала в клинична депресия.

Категорията фентъзита никак не е малка, и учудващо има доста добри неща – серията “Codex Alera” (алтернативен свят, римляни, малко магия) на Jim Butcher (която май са превели в по-голямата си част на български), серията “Belisarius” на David Drake и Eric Flint (алтернативна история с византийския генерал Велизарий), последната книга от Ancillary серията на Ann Leckie, петият Mistborn на Brian Sanderson. Също така в тази категория е и най-тъжното книжно събитие на годината, “The shepherd’s crown”, последната книга на Тери Пратчет.

Комиксите тази година не бяха чак толкова, колкото предишните. Бих могъл донякъде да препоръчам Cerebus на Dave Sim – произведението е монументално, сменя много жанрове и прави какви ли не странно неща, но очевидно нещо се е случило с автора по някое време и последните 4-5 книги са тотално нечетими. Изчетох и целия Fullmetal Alchemist, но не мога да кажа, че е кой-знае какво.

Не трябва да се пропускат “Seveneves” на Стивънсън и “The Martian” на Andy Weir (учудващо добра книга, въпреки всичкия hype около нея), като единствените представители на твърдата фантастика от тая година.

По любимата ми тема за депресията, “Furiously happy” на Jenny Lawson е страхотна книга, освен, че те кара да се замислиш и да погледнеш на хората по друг начин, е и много много весела.

Преиздадоха и “Архипелагът ГУЛАГ” на Солженицин, за който мисля, че съм писал и много си заслужава.

По научно-популярната тема няколко интересни книги бяха “Structures, or why things don’t fall down” на J.E. Gordon и “Ignition!: An informal history of liquid rocket propellants” на John D. Clark. И двете ги четох с голямо удоволствие.

Най-интересна ми беше политическата тема тази година:
– “Swarmwise” на Rick Falvinge (от Пиратската партия) по темата за организиране на хора, чете се много бързо и силно я препоръчвам;
– “Capital in the 21st century” на Thomas Piketty е много добре издържана икономическа книга, която описва доста интересни неща в икономиката и поведението на капитала. Силно я препоръчвам, въпреки че оригиналният ѝ език доста е повлиял на изказа и на моменти дразни;
– И книгата, която най-вече препоръчвам е “Public choice III” на Dennis C. Mueller, учебник, в който е събрана цялата политическа теория от последните 50-100 години – системи за гласуване, организационни форми и какво ли не още. Иска ми се някой ден да направя няколко лекции (или серия blog post-ове) по нея.

Дойде време за 32c3. Все още няма програма, но списъкът лекции може да се види в halfnarp-а, в wiki-то има вече бая workshop-и, и дори съм направил assembly за хората, които им се идва.

(ако някой не знае за събитието, писал съм разни неща за следните предишни такива: 26C3, 28C3, 29C3, 30C3, 31C3)

Пуснати са билети, има къде да спите, и за мързеливите най-вероятно ще има излъчване в initLab (и като цяло online).

Update: За пръв път от няколко години свършиха билетите.

(сигурно има да пиша още за openfest, но това специално ми се мотае в главата от няколко седмици)

(също така, това е мое лично мнение, няма общо с екипа на феста)

Не мога да си обясня дали има проблеми с програмата на openfest. Има оплаквания от разни хора, но понеже не са много, ми е трудно да преценя само по feedback-а.

Опитах се да сравня с предишни години, като се зарових из archive.org и в старите архиви на сайтове, които имаме, и в общи линии не изглежда нивото ни да пада – дори има в някакви отношения подобрение (особено като си спомням някаква част от лекциите преди). Силните технически неща стават все по-интересни, имаме сериозно разнообразие, и като цяло доста по-значими неща спрямо миналите години. От друга страна, самите теми явно вече не са така интересни на хората – преди свободният софтуер беше нещо ново, неясно, отричано, сега е просто факт от живота. Спечелихме войната и минахме на нови неща :)

Та, не мога да преценя колко е интересът за гледането на тези лекции, но интересът за подаването им сериозно пада. По една статистика от тая година по-малко от половината лекции са подадени от нови хора, останалото е обичайните заподозрени и лекции, които екипът е домъкнал по някакъв начин. Програмният комитет трябваше много да се старае, за да сглоби програмата тази година, понеже в един момент ни свършиха лекциите, които наистина ни радваха… Не знам на какво се дължи това, но явно хората нямат желание да говорят по темата какво правят, или просто никой не прави open-source софтуер достатъчно сериозно.

Също така, не е ясно дали не трябват нови потоци, понеже OpenBiz почти никакъв го няма, а OpenArt-а продължава усилено да се крие. Не знам дали самото creative commons движение не е взело да запада, но специално при нас никак не му се чува гласа, и като цяло около нашата общност артистите се губят.

Може би просто трябва да смъкнем лекциите на две зали (или дори само една) и да направим много workshop-и и unconference събития. Тази година хората се утрепаха да запояват, отварят ключалки и всякакви такива неща, може би догодина пак може да има admin lounge и разни други хора да поискат да си направят по-неформални събирания в рамките на феста, тъкмо ще имаме и ние по-малко занимания…

(btw, вероятно по някое време ще има официален call for feedback за самия фест)

Автор: Владимир Витков / zeridon
Дата: 2015.11.16
Контакт: vvitkov@linux-bg.org / jabber: zeridon@jaim.at / irc: zeridon @ marla.ludost.net

Тази година осъзнах, че OpenFest хич няма да е малко събитие. Имайки предвид количествата хардуер, количеството хора и новото място без почти никаква инфраструктура стана ясно, че ни трябва стабилен мониторинг. Тази година това беше моята основна задача, покрай другите неща.

Мониторинг системата имаше 2 цели:
* Събиране на данни за производителността на мрежата/хардуера който бяхме пръснали
* Наблюдение на ключови параметри и известяване за проблеми

Реализацията на системата започна доста рано и улесни работата (поне за мен). За събиране на данни за производителността използвахме комбинация от collectd и graphite. Данните бяха събирани на всеки 10 секунди. Машината, която играеше ролята на колектор беше наблюдавана доста по-сериозно.
Тъй като трябваше да събираме данни за производителността на мрежовото ни оборудване, collectd беше внимателно помолен да събира SNMP данни. Tова се оказа учудващо лесно. Данните събрани (или изпратени) към collectd след това бяха препращани към graphite. Избрахме graphite поради опита който имахме и поради факта, че размерът използвано пространство за съхранение на данните е лесно предвидим. Graphite използва whisper бази, които се преалокират в зависимост от времето за което ще пазите данните.
Данните от wi-fi устройствата бяха събирани локално на самите тях от collectd, който ги препращаше на централния колектор.

В допълнение към данните за производителност трябваше да осъществяваме и наблюдение за достъпност и състояние на услугите. За целта използвахме nagios3, който наблюдаваше суичовете (състояние на портове, натоварване, SNMP traps, телнет), wi-fi устройствата (достъпност, пинг, ssh), излъчването от залите (брой стриймове, състояние на всеки от стриймовете). Голямото “забавление” беше подкарването на SNMP трап-овете. Ако наистина, ама наистина не ви се налага да го правете – недейте. Ако все пак настоявате, погледнете https://github.com/OpenFest/openfest-2015-network/tree/master/monitoring/snmp.

За да представим нещата красиво използвахме tessera, като дори в един момент публично раздадохме линкове към някои от графиките. Конфигурацята на графиките беше от Петко, така че нека той сподели повече.

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

Като цяло забавлението беше на прилично ниво (за догодина – и автоматизирано). Ако някой се интересува от конфигурациите (иска да ми се кара как не се правят неща), може да ги намери на https://github.com/OpenFest/openfest-2015-network/tree/master/monitoring. Документирани са … бегло, но са четими като цяло.

Публикуваме архива на collect базата данни за всички заинтересувани.

Мрежата на тазгодишния openfest беше с един порядък по-сложна от миналогодишната. Как вървят кабелите и в общи линии си личи на плановете на партера (първия етаж) и първи балкон (втори етаж).
(ще говоря за core мрежата само, Петко ще разказва за wireless-а)

Понеже самата зала България няма никаква мрежова инфраструктура, направихме мрежа от няколко свързани кръга (в стила на ISP) с MSTP в/у тях, така че да можем да се спасим от поне един паднал кабел. Решихме, че един гигабит ни стига за backbone и не правихме някакви по-сложни неща, като балансиране м/у няколко връзки.

Самата core мрежа имаше следните “клиенти”:
– router и encoder, при core switch-а;
– wireless мрежата;
– Видео екипите в трите зали;
– Рецепцията;
– switch-овете за крайни потребители в workshop залата, и
– две специално донесени железа от e-card, на които хората се записваха за томбола.

Тази година пак няколко човека ни услужиха с техника – Светла от netissat, Иван Стамов, Стефан Леков донесе един switch, digger даде двата за workshop-ите, и останалото дойде от мен и initLab. Също така настройването не го правих сам – Леков и Петко участваха активно в дизайна (и направиха прилична част от него), а Стоил, Марги и Zeridon – голямата част от конфигурацията на switch-овете.

Имахме 8 core switch-а на различни места, като където се налагаше да има switch в залите, се слагаше нещо по-тихо. Целият core беше от изцяло гигабитови switch-ове (като изключим един, който имаше и 10gbps портове, но не влязоха в употреба, за съжаление). Така можахме да закачим всичко извън тази мрежа на гигабит, включително wireless AP-тата, които тази година бяха изцяло гигабитови. Нямаше грешката от миналата година да се ползват супер-различни switch-ове – бяха 3 TP-Link SG-3210 и останалото леко разнообразни Cisco-та, като STP конфигурация с тях в тоя вид беше тествана още на курса по системна администрация (ето тогавашната схема).

Router ни беше един HP DL380G5, който в общи линии си клатеше краката (до момента, в който пуснахме да encode-ва един stream и на него). Тук нямаше особено много промени от миналата година, просто един linux-ки router с NAT и DNS/DHCP. По-забавните неща там бяха многото monitoring и записвания на данни (за които ще карам да се пише нещо отделно), в общи линии setup с collectd и събиране на каквито данни може да се събират.

Нямам в момента някакви снимки от мрежата, но беше опъната по най-добрия възможен начин за обстоятелствата – кабелите бяха прибрани и увити с велкро, нямаше някакви, през които да минават хора и като цяло не се виждаха особено много. Местат, които не бяха посещавани от хора бяха малко плашещи (например core switch-а, router-а и encoder-а бяха под едни стълби до едно ел. табло и изглеждаха като мрежовия вариант на клошари), но за останалите успяхме да намерим по-скрити и подходящи места (в workshop area-та switch-ът с няколко други неща беше под един роял).

Internet-ът ни беше от Netx (които успяха да реагират в нормални срокове и да опънат оптика около месец преди събитието, за разлика от други, които ще останат неназовани), и тази година 100те mbps нещо почнаха да не ни стигат. Това са графиките от първия и втория ден, като прилична част от изходящия беше streaming-а. Проблемите се виждат на графиката на smokeping-а, и поне според мен за по-спокойно догодина трябва да сме на 200mbps.

Адресният план беше много близък до миналогодишния:
VLAN 50 – външната ни връзка, 46.233.38.137/28 и 2a01:b760:1::/127
VLAN 100 – нашата си management мрежа, 10.100.0.0/24
VLAN 101 – мрежата за хората, свързани на кабел, 10.101.0.0/22, 2a01:b760:abc:2::/64
VLAN 102 – мрежата за хората, свързани на wireless-а, 10.102.0.0/22, 2a01:b760:abc:3::/64
VLAN 103 – мрежата на видео-екипа, 10.103.0.0/24
VLAN 104 – мрежата на overflow телевизорите, 10.104.0.0/24

(нещо, което не трябва да пропускаме за догодина е да раздадем адреси на видео-оборудването предварително, сега те си ги измисляха в последния момент и аз просто разместих раздавания range от dhcp-то)

Firewall-ът беше тривиален, от типа на “тия всичките vlan-и не могат да си говорят помежду си, само с външния” и “25ти порт е забранен”. Не съм голям фен на stateful нещата за такива случаи, а тоя прост setup свърши прекрасна работа.

Пуснали бяхме и още нещо странно – освен филтрацията на broadcast трафика, бяхме включили за потребителските vlan-и (101, 102) proxy_arp_pvlan, което в общи линии е poor man’s forced forwarding – караше router-а да отговаря със себе си за всички arp заявки. Така се избягваше прилично количество broadcast, затрудняваше се arp spoofing-а (с няколкото други неща директно и се убиваше) и като цяло не направи някакъв проблем, освен че може би държеше пълен arp cache на windows машините.

Преди събитието имахме няколко проблема. Един от тяхбеше, че не бяхме предвидили вярно колко кабел ни трябва, и се наложи спешно да се купи още един кашон (300м), но като цяло мрежата изгря без проблеми, може би с една-две грешки по конфигурацията на портовете. Също така един от switch-овете (cisco ws-3550-12G) имаше проблеми с gbic-ите, понеже няколко от медните не работеха, та за това имахме 5м оптика – един от access point-ите беше свързан през single-mode gbic в switch-а и конвертор от другата страна. За дебъгване имаше един вечерта, като закачахме на e-card машините, за които се оказа, че един странно прекъснат кабел прави нещата да не работят, но имаше link (това се усети най-вече по това, че не щяха да закачат на гигабит).

По време на събитието пак имахме проблем с ipv6, този път обаче след нашия router, и понеже нямахме как да го debug-нем/решим, втория ден бяхме ipv4-only. Бяхме правили тестове предишната седмица с връзката, но явно някакви неща не сме успели да ги хванем (или нашия router пак е направил нещо странно). Също така по погрешка бяха извадили тока на един switch (което аз поне изобщо не съм усетил), и заради кофти удължител за малко е паднало едно AP (което е било хванато моментално на monitoring-а).

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

Ще оставя статистиките и другите неща на хората, дето ги събираха :)

(и преди да съм разписал хилядите неща от openfest, нещо, което ми се мотае в главата поне от година, и което Public Choice III ми доизясни)

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

Прост пример за компромис е да имаме някакви пари N и двама човека, A и B. Нека да имаме функция U(P, X), която за P ∈ {A, B} и 0 < X < N може да ни даде някаква “полезност” на свършеното от човека, като целта ни е да максимизираме U(A, X) + U(B, N-X). Безкомпромисните решения са X=N или X=0 (т.е. да дадем всичко само на единия), всичко останало е някакъв компромис м/у тях, за да се получи по-добър резултат.
(моля също така да се консултирате с вица за сферичния кон във вакуум, преди да продължите)

Повечето технически проблеми включват някакъв вид trade-off, за да се решат, дори има стандартен такъв термин, time-memory trade-off за всякакви алгоритми и решения, т.е. принципът, че с повече памет (поне до едно време) може да се спести време. Един сравнително прост пример, който ми хрумва е lookup дали даден IP адрес е блокиран или не – това може да се реализира с:
– прост масив – яде малко памет, търси се линейно и като цяло е бавен;
– хеш – яде повече памет, търси се константно (worst-case – линейно) и е по-бърз;
– дърво – яде още повече памет, търси се логаритмично, и
– bitmap – един масив от 2^26 байта, в който всеки бит отговаря на отделен адрес, който яде много памет и в който lookup-а е константен.

Когато за някой проблем може да се максимизира всичко и да се постигне ситуация “и вълкът сит, и агнето цяло”, техническият термин за решението е “hack” и е любим на всички ни.

Проблемът е, че няма hack за всичко, и реално всички организации, действия и решения, които включват други хора изискват някакъв тип компромис. Живеейки в свят, в който сферичните коне (особено във вакуум) са рядкост, се налага да правим доста такива, за да постигнем каквото и да е. Може да се каже, че цялото ни общество се крепи на компромисите.

А хората не харесват компромиси. Явно някъде ни е заложено, че трябва да стане нашето и хората по принцип дърпат в собствената си посока, като отпускането в чуждата рядко се приема като нещо хубаво, като загуба и отстъпление от собствените принципи. Поради това много компромиси не издържат с времето и се налага или да се преразглеждат, или да се разпаднат.
Никак не помага и това, че няма как да се оцени един компромис, като с функцията по-горе. Тия дни във връзка с openfest ми беше зададен (съвсем хипотетичния) въпрос – дали не е по-добре да се направи една лекция, която е много полезна и информативна, за 50 човека, отколкото една по-малко информативна (с базови неща и т.н.) за 1000 човека. На такъв въпрос смислен отговор няма, начинът да се разбере е да се проведат, да се направи изследване след това м/у хората по някакъв начин (например колко пари биха дали за една такава лекция), да се сумират нещата, да се сравнят, и после да осъзнаем, че принципът на икономистите не води до особено смислени неща и да зарежем упражнението.

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

Та, накратко, life sucks, and then you die. Единственото смислено нещо, което виждам да може да се направи е да се мисли метод, който без да обижда хората да може да оценява компромисите и да може да се смята как точно да се направи един компромис. От друга страна, не мисля, че е особено възможно и се надявам някой да покаже, че не съм прав :)