2017-04-10 splitpatch

April 10th, 2017 by Vasil Kolev

Нов ценен tool – splitpatch (има го в debian, нищо, че е на ruby).

Трябваше да вкараме едно парче код (на perl) в главното ни repo, и след code review имаше забележки като за 11 промени. Вкарахме ги, тествах го и открих, че не работи – output-а беше много много различен от този в началото (който си се знаеше, че е верен).

Един вариант беше някой да гледа промените ред по ред и да се разбере какво е объркано. Вместо да се стига до такива крайни мерки, намерих tool, който може да сцепи patch-а на hunk-ове, и след това направих следното:

for i in ptch/* ; do patch -o test TOOL $i ; ./test debug > $i.output ; done

и след това с един прост for и diff видях кои съвпадат и кои се различават, и проблемния commit лъсна…

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

Изводът е, че човек може да дебъгва код на нещо в много случаи и без да знае езика…

2017-04-05 интервюта за админи

April 5th, 2017 by Vasil Kolev

Смених работата, но се оказва, че от интервютата бягане няма. Тоя път са за системни администратори.

За всеки нов вид интервюта си трябва доста време, за да се свикне и измисли хубав метод. Например, нямам fizzbuzz, доста по-трудно е да кажеш “покажи какво си писал”, а срещането на NDA, заради което не може да се говори какво е вършено не е чак толкова рядък случай. Да разбереш дали някой разбира в дълбочина някоя технология не винаги може да стане с 2-3 въпроса. Да не говорим, че докато не видиш как работи човека, няма как да го прецениш дали става…
(най-добрия вариант го правят в automattic, просто един месец ти плащат да работиш с екипа и ти дават задачи и гледат как се справяш. За съжаление не е лесно да се направи на друго място.)

Като за начало съм си сглобил малък админски тест, който да пращам на хората. Има даже дребен състезателен елемент и се чудя дали не мога да го разпъна до нещо escape-room-о-подобно :)

(in other news, бях седнал да си си разписвам escape room за админи, ако се намери достатъчно интерес може да я сглобя в лаба, има всякакви странни неща вътре)

(p.s. ако някой тия задачи са му лесни и си търси работа, лесно се разбира де да си прати CV-то…)

2017-03-30 Alexandra Zerner

March 30th, 2017 by Vasil Kolev

Тия дни Виткур спомена, че се занимава с нов музикален проект – Alexandra Zerner, и един техен запис ми прозвуча добре, та се замъкнах с жената в Joy station да ги чуя на живо.

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

А музиката си беше великолепна. Инструментален метъл, но на коренно различно ниво, интересна, с много техника и много идеи. Някаква представа може да се придобие в youtube, но определено е друго да се чуят на живо. Взех си cd-тата ѝ и ще си ги въртя известно време :)

А как точно свири Александра Зернер е трудно да се обясни. Единствения ми паралел беше Чък Шулдинър…

2017-03-12 апокрифи

March 12th, 2017 by Vasil Kolev

От време на време докато пием се случва да си разказваме разни истории от едно време, кои апокрифни, кои истински, но всички заслужаващи да бъдат записани. Събрал съм няколко от спомени и участия, без имена (да предпазим виновните).

Една от най-любимите ми е за ISP-то (във времената на dial-up-а), на което един от админите по погрешка направил UPDATE на passwd таблицата без WHERE клауза и потрил всички пароли. Нямало backup (разбира се) или начин да се възстановят, за това си patch-нали radius-а ако един потребител три пъти напише същата парола, да я приеме и да я запише в базата. Така успели да възстановят почти всичко.

Един млад хакер една вечер в средно пияно състояние решил, че всичките internet доставчици в града му не струват и за да им отмъсти, написал един троянски кон, който правел безогледен flood по всичките им IP range-ове. В един момент се усетил как сам си е отрязял^Wзапушил клона, ама нямало какво да направи. След около седмица по различни начини (смяна на IP range-ове, филтри, черна магия) flood-ът бил спрян, но поне според някои хора още 10на години след това имало останал такъв трафик.

Администратор на ISP и известен irc сървър към него бил много приличен и мирен човек, който локалните хакери много тормозели. Накрая го пропили, и една вечер така след много пиене го питали “Абе, я си кажи root-ската парола”. Той просто се усмихнал и заспал на масата.

В един hosting имало shell скриптове, викани през sudo-подобна система за добавяне и триене на потребители. Скриптовете не били помислени достатъчно добре и когато един потребител си написал интервал в края на username-а, системата chown-нала ВСИЧКО на неговия потребител. Много неща спрели да работят, хората по навик рестартирали сървъра, и той повече не изгрял…
(тук не съм сигурен дали нямаше подобна случка и с rm при премахване на потребител, отнесло целия сървър)

В една фирма хората от нямане какво да правят си направили etherkiller (от едната страна RJ45, от другата щепсел). Забавлявали се, показвали го на хората, снимали го и го забравили. След няколко месеца се оказало, че щепселът бил останал включен в един контакт и само по чудо не била станала по-голяма беля.

В едно ISP младши админа написал rm /home/somewhere/something/ * (забележете интервала), докато се намирал в /usr/sbin. Понеже това било във времената преди не-ужасяващо-бавния интернет и пакетните системи в linux, отнело някакво време да се намери какво точно се е потрило и да се възстанови, поне една част от него.

В друго ISP на основния Cisco router изгоряло захранването (във времената на бавния интернет, малкото пари и никаквата резервираност). Въпреки знанията на хората по електротехника, не успели да се ориентират къде точно е проблема на захранването, та техни колеги от конкурентно ISP им дали под наем такъв router (НА ЧАС). Седнали с работещото и неработещото захранване отворени едно до друго и проследявали, докато намерят проблема (мотае ми се нещо като 10 часа).

Като си спомня още, ще ги опиша и тях :)

2017-02-22 FizzBuzz 2

February 22nd, 2017 by Vasil Kolev

Понеже идеята ми се мотае в главата от месец-два и тая нощ ми хрумна финалната оптимизация, ето продължението на post-а за fizzbuzz:

int i=0,p;
static void *pos[4]= {&&digit, &&fizz, &&buzz, &&fizzbuzz};
static void *loop[2] = { &&loopst, &&loopend};
int s3[3]={1,0,0},s5[5]={2,0,0,0,0};
char buff[2048];
char dgts[16]={'0','1','2','3','4','5','6','7','8','9','a','b','c','d','e','f'};
int buffpos=0;

loopst:
	i++;
	p= s3[i%3] | s5[i%5]; 
	goto *pos[p];

fizz:
	memcpy(&buff[buffpos],"Fizz", 4);
	buffpos+=4;
	goto end;
buzz:
	memcpy(&buff[buffpos],"Buzz", 4);
	buffpos+=4;
	goto end;
fizzbuzz:
	memcpy(&buff[buffpos],"FizzBuzz", 8);
	buffpos+=8;
	goto end;
digit:
	buff[buffpos++]=dgts[i/16];
	buff[buffpos++]=dgts[i%16];
end:
	buff[buffpos++]='\n';
	goto *loop[i/100];
loopend:
write(1, buff, buffpos);

Известно време се чудех как може цялото нещо да стане без никакъв branch, т.е. и без проверката за край на цикъла. Първоначалната ми идея беше да я карам на асемблер и да използвам като в exploit-ите NOP sled, нещо от типа (извинете ме за калпавия асемблер):

	JMP loopst
	JMP loopend
loopst:
	NOP
	NOP
...
	NOP
	; fizzbuzz implementation
	; i is in RAX
...
	MOV RBX, 0
	SUB RBX, RAX
	SUB RBX, $LENGTH
	SUB EIP, RBX
loopend:

Или, накратко, колкото повече се увеличава i, толкова повече скачам назад с релативния JMP (който съм написал като вадене на нещо от EIP, което най-вероятно изобщо не е валидно), докато не ударя JMP, който ме изхвърля. Като оптимизация бях решил, че мога да shift-вам стойността с 4, така че sled-а да е само 25 броя.

В един момент ми хрумна, че мога да мина и без sled-а, като правя деление (което е отвратителна операция, но спестява кофа nop-ове). Така се получи по-горния вариант на C, който не е съвсем C, а просто някаква странна асемблероподобна гняс.

Иначе, важно е да се отбележи, че на какъвто и да е модерен процесор по-горния код е далеч по-неефективен от простото решение с if-ове, най-вече защото branch prediction и всички други екстри се справят много добре с всякаквите if-ове, но доста по-трудно могат да се сетят тия jmp-ове към таблици базирани на някакви стойности къде точно ще идат, за да се прави спекулативното изпълнение. Не съм си играл да benchmark-вам (въпреки, че имам желание), но като цяло горния код има шанс да се справя по-добре само на неща като 8086 и компания.

И като идея за следващата подобна мизерия, може би може да се оптимизира истински чрез ползване на някое от разширенията за работа с вектори/големи стойности и се unroll-не цикъла, например да се прави на стъпки от по 4 с някаква инструкция, която смята делители (кой-знае какви странни неща има вкарани вече в x86 instruction set-а).

2017-02-21 сънища

February 21st, 2017 by Vasil Kolev

От irc, или какво ни се случва след достатъчно правене на всякакви събития:

(11:07:44) neter: какъв сън… на някаква конференция сме в огромна зала на няколко етажа, аз съм на последния с няколко колеги от работата и сядам да гледам, на сцената излиза Яна с някакви хора и говори нещо, в този момент някаква
(11:07:45) neter: дървена кутия в дъното на етажа, на който съм, започва да дрънчи като стар будилник (явно алармата на телефона ми е звъняла), отивам да я оправям, ама не е ясно каква е тая кутия и какво да я правя, търся бутони, докато не
(11:07:47) neter: виждам, че е свързана към някаква газова бутилка и има вероятност всеки момент да гръмне, Яна се обажда отдолу, че нещо в залата дрънчи, отивам до другата зала да взема нещо, а навсякъде бъкано с народ, едвам се
(11:07:49) neter: разминавам и сякаш не им пука, че онова дрънчи, та мозъкът ти кънти, връщам се при кутията, разглобявам я, откачам газовата бутилка, за да не гръмне и откачам всичко друго, което виждам, но онова не спира да дрънчи, докато
(11:07:51) neter: не идва Мариян, вика дай да пробваме да откачим ей тези жици (които в този момент се чудя как не съм видял), откачам ги, онова най-сетне млъква и седим и се хилим как замалко да си умрем
(11:09:31) lz1irq: :D
(11:09:42) lz1irq: neter: май ти идва повече стреса по конференции :D
(11:10:57) neter: интересно ми е как въобще се стигна до спиране на звъненето в съня – явно е, че е било от алармата на телефона ми, а нея съм я настроил да не спира да звъни, докато аз не я спра, което ше рече, че явно пресягането към онези
(11:10:58) neter: жици в съня, за да ги откача, реално е било пресягане към телефона, за да му спра алармата
(11:11:27) neter: това ми мяза на сомнанбулизъм – едно е да изключа алармата в просъница, друго е докато сънувам да правя такива неща

2017-02-13 сватба

February 13th, 2017 by Vasil Kolev

Ожених се.
(сега погледнете датата в title, че не е първи април, и продължете нататъка)

В петък (10.02, отбелязвам да не забравя в бъдеще) в 13:00 се ожених за (вече госпожа) Елена Дяволова. Понеже ни мързи да си сменяме личните карти, не сме си сменяли имената (иначе се чудех как малкия можем да го кръстим Колев-Дяволов, щото звучи точно като да коли дяволи…). Решихме да не правим голямо тържество, понеже {работа, мързел, бременна Елена, умора}, най-много да избягаме от всички за едно пътешествие.

Снимка с кумовете (и някаква растителност).

2017-02-07 FOSDEM 2017

February 7th, 2017 by Vasil Kolev

И преживяхме FOSDEM 2017.

Бяхме там с Марио, Любо, Маги, neter и zeridon (а Мариян беше там да присъства на конференцията, но се включи към нас) да правим видео/аудио записите и streaming-а. Три дни се ставаше рано и цял ден се дебъгваше (и за доста от хората – тичаше напред-назад, Любо каза, че единия ден е направил 27000 крачки), имаше всякакви странни проблеми и като цяло беше голямо забавление, приключено със ставане в 6:30 в понеделник да си хванем самолета. Като се прибрах спах 12 часа. Справихме се със събитие от 24 зали, два дни, около 600 лекции и 8-9 хиляди посетители (и не знам колко точно дъжд).

Малко снимки има на /pics/201702fosdem/, като на една от тях може да се види колко съм щастлив (това е в петък още, после имах основно уморен вид).
(снимките са от Мариян и Любо, като ще се опитам да намеря и още)

Като статистики не съм събирал кой-знае колко, мога да кажа само че пиковият трафик на restreamer-ите беше 630mbps, далеч под очакванията (това, което бяхме подготвили можеше да издържи спокойно 4gbps и се разширяваше лесно). Някакъв status на видео записите може да се види в review системата, като мога да се похваля, че имахме готови видеа още в събота вечер, а като гледам днес вече са release-нати половината.

И най-интересната част, проблемите, в които се набих (като преди това може да искате да прочетете архитектурата и да видите схема с една зала):

Явно съм забравил какво значи best effort в IP/Ethernet мрежите. При 72та multicast stream-а и при 300pps на всеки в един момент се оказа, че по switch-овете има microburst-ове, които ни ядат пакетите от време на време. Това водеше до примигване на някои stream-ове, до ошашкване на ingest-ващия ffmpeg и вадене на картина с 1fps (като па аудиото си беше добре), артефакти и други гадости.

– Първият опит за решение беше включване на flow control-а. Това доведе до спиране на всичко за 5-10 минути (и липса на stream и видеа в review системата от тоя период, добре, че има записи по кутиите) и желание за по-внимателни fix-ове.
– Последва ровене по switch-овете, забелязване на едни броячи за твърде големи пакети и след това форсиране на 1000 байта горна граница на пакетите във ffmpeg. Не помогна;
– Вдигнахме за всеки случай и MTU-то на switch-овете, пак не помогна;
– Като вариант за pacing на портовете преместихме някакви неща на 100mbps да вкараме изкуствено забавяне, тотално омаза ситуацията;
– В един момент единия от мрежарите откри, че няма контрол в/у буферите на повечето switch-ове и реално ползваме 1/4 от буферите (щото всичкия ни трафик се набива в една опашка от 4те) и че няма свестен начин да използваме и 4те. Само на единия switch бяха пипнати и помогна, но малко;
– Смъкнах и bandwidth-а на входящите stream-ове от 4mbps на 2mbps, не помогна особено.

Решението за догодина е или Reliable Datagram Socket (Мариян обеща да напише support-а за ffmpeg и го държа отговорен), някакъв forward error correction (някакви хора са написали pro-mpeg поддръжка за ffmpeg, но не е merge-ната), или lossless мрежа и по-добри буфери (което казаха, че може и да може да се осигури за догодина). Шегувахме се, че мога да мина на infiniband за видеото.

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

Другите проблеми бяха по-малко интересни – утрепахме тока на сървърното (докато включвахме неща в съвсем друго място), хората не знаеха как да ползват микрофони, гърмя хардуер, валя дъжд (но не в залите), хората тичаха, врати се заключваха (автоматично), за малко neter и Мариян заседнаха в един асансьор и куп други неща, дето вече не помня.

(и за разлика от openfest, тук сървърите не бяха в/у тръбите на парното, а в стаята до него…)

Update: Току-що открих, че push-ването на видео извън мрежата е генерирало ~600GB, а системата, която генерира картинките за преглеждане на контролния интерфейс – ~7.1TB (постоянни 300mbps). Май съм бил най-големия генератор на изходящ трафик на FOSDEM 2017. Чудя се да се радвам ли или да се ужасявам.

2017-01-17 The Baby Owner’s Manual

January 17th, 2017 by Vasil Kolev

Чел съм много неща на Стивън Кинг.

Чел съм за геноцида в Руанда.

Чел съм за психопати: 1, 2, 3.

Чел съм Колимските разкази и Архипелага ГУЛАГ.

Както и по много други теми, заради които съм се депресирал за по седмица-две.

Всичките обаче не са толкова ужасяващи, колкото The Baby Owner’s Manual, след което си извадих една бутилка и си наливах известно време. Ако Стивън Кинг пропише такива книги (или по темата), вероятно ще има много припаднали читатели.

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

2017-01-09 Учредително събрание на ДА България

January 9th, 2017 by Vasil Kolev

Учредителното събрание на ДА България беше по-интересно, отколкото очаквах, и горе-долу толкова тежко, колкото очаквах.

Не е тривиална задача да се съберат на едно място 1500 човека (мисля, че на други места писаха за огромната опашка и препълнената зала, аз ако не бях от техническия екип не е ясно кога щях да успея да вляза). Още по-малко тривиална е с такова количество хора да се учреди политическа партия (законовият минимум за учредителното събрание е 500 човека, но въпреки това в оня ужасяващ студ хората се бяха вдигнали, явно от притеснение, че може да не съберем кворум).
А да се реализира гласуване с вдигане на ръка на целия устав точка по точка, разни хора и управителни органи и това да се събере в един ден си е постижение. Имам някакви спомени как едно време партии са се учредявали по цяла седмица с конгреси и изказвания, определено е имало причина (особено ако едно гласуване отнема половин час да се преброи). Щях да мрънкам на някой защо нямаме електронно гласуване, ама после се усетих, че ще е перфектното нещо да се заядат в съда и да не приемат регистрацията …

Официален запис ще има по-нататък (хората, които снимаха имат отделно материал от всички камери, а и вероятно ще искат да стабилизират някои моменти), но аз преди това съм изрязал от dump-а интересната за мен час – представянето на членовете на националния съвет, около 100 човека с 30 секунди за всеки (които никой не пресрочи). Правих една разбивка по професии (която не е съвсем точна, явно съм пропуснал няколко човека и трябва да намеря време да го гледам пак), изглежда по следния начин:
18 адвокат
10 ИТ
9 предприемач
7 преподавател
5 юрист
4 икономист
3 студент
3 музикант
3 мениджър
3 маркетинг
3 инженер
3 бизнесмен
2 психолог
2 политолог
2 писател
2 оператор
2 неясен
2 лекар
2 журналист
2 дизайнер
1 фотограф
1 фармацевт
1 социолог
1 реклама
1 математик
1 лесовъд
1 издател
1 еколог
1 директор планинска спасителна служба
1 блогър
1 бивш спортист
1 актьор

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

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

p.s. търсят се още хора, които имат желание да се включат, подробности има на сайта, който иска може и да ме пита директно.

2017-01-07 streaming

January 7th, 2017 by Vasil Kolev

Малко наблюдения по stream-ването и платформите.
(днес stream-вах учредителното събрание на Да България (в която вече съм и член). По темата за Да България ще пиша някой друг път)

Facebook имат една от най-малоумните streaming платформи, на които съм попадал. Освен разните изисквания и горна граница на качеството (максимумът е 720p), event-ите им expire-ват доста бързо (т.е. не можеш да си го създадеш от предната вечер, като в youtube), на едно-две прекъсвания приключват и event-а (ако се налага човек да си пипне настройките няколко пъти, трябва да го създава наново) и имат и лимит за продължителността (което е особено дразнещо). Като за капак, човек ако няма flash не може да си пусне stream-а да е live каквото и да прави, та докато си правех тестовете се наложи да си ползвам виртуалката с windows (и тестовия facebook account на жената).

Youtube пък имат едно малко неразбирателство с ffmpeg, че пращат някакъв keepalive по RTMP сесията, който ffmpeg-а го няма за нищо, не го чете и в един момент едни tcp буфери се напълват (говорим за 16-тина байта на минута-две, та отнема няколко часа, че да се прояви) и се троши връзката. Слава богу, не махат event-а толкова бързо, колкото facebook и може да се рестартира.

Моя си streaming server си работеше най-добре (един nginx с mod_nginx_rtmp). Понеже имаше малко проблеми да reencode-вам всичко локално, бълвах на 10mbps директно изхода от хардуерния encoder до marla, от там дърпах с 3 ffmpeg-а и качвах смачкания на 1mbps stream до facebook, youtube и до същия nginx, за да мога да си го гледам.

И да си имам редът за бълване до facebook (понеже ми отне един следобед да го докарам както трябва, най-вече заради борбата с оня flash) – двете важни неща за -g 45 (може и 60), имат изискване за keyframe поне на всеки 2 секунди, и -r 30, понеже изискват 30-кадрово видео. Другото е стандартно – H.264, AAC, 44100hz (и моно звук, понеже такъв ми подаваха). Добавката с -af volume=60d трябва да се махне за всички, на които не им подават звук на ужасяващо ниски нива.

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

ffmpeg -i rtmp://strm.ludost.net/st/XXXXX -r 30 -c:v libx264  -b:v 1000k -s 1280x720 -preset:v veryfast -threads 6 -minrate 1000k -r 30 -g 45 -maxrate 1000k \
	-c:a libfaac -ar 44100 -ac 1 -b:a 128k -af 'volume=60d' -f flv 'rtmp://rtmp-api.facebook.com:80/rtmp/XXXXXX'

Иначе е неприятно, че трябва да живеем на proprietary кодеци. При някакви скорошни тестове около FOSDEM пак се оказа, че VP9 още няма как да се encode-ва в близо до реално време без поне два пъти процесорната мощ, нужна за H.264, има малко поддръжка и никакъв хардуер, който може да го дава.

p.s. Важен факт – за всичко, което се ползва по време на streaming-а трябва да има хубав работещ КАБЕЛЕН internet, и като резерва, 3G, през което да се работи като се чупи локалния wifi (щото той със сигурност ще умре по някое време).

2016-12-31 равносметка

December 31st, 2016 by Vasil Kolev

И време за стандартната годишна равносметка…

– Ще ставам баща. Това мисля, че за всички е доста изненадващо, даже малко и за Елена :)
– Избутахме OpenFest 2016 – много работа, много неща, като цяло изяде сериозна част от времето ми за годината;
– Имах количество занимания около initLab, който още оцелява;
– Направих няколко BGP workshop-а (и може би скоро трябва да направя още един, докато мога);
– Занимавах се с видеото на FOSDEM 2016, и догодина пак (направили сме бая интересен setup, който се интересува може да види в github);
– В общи линии за да тестваме нещата за FOSDEM ходихме да правим видео/аудио записване и streaming на State of the Map 2016;
– Направих една лекция (на PlovdivConf) и планирах и една на тема теоретична политика, която не можах да довърша (като цяло имам вече поне 5 висящи написани до средата лекции);
– Умря Pieter Hintjens;
– Да не повярва човек, не писах повече тая година…

И да стои и да се вижда, ето списъкът висящи ми лекции:
– “Теоретична политика” (системи за гласуване/взимане на решения, компромиси и т.н.);
– Debug workshop;
– VoIP/asterisk workshop (или цял курс);
– Приложение на принципи от системната администрация в реалния живот;
– Представяне на initLab с много картинки;
– Криптография за журналисти;
– Подкарване и поддръжка на собствен mail server;

Мисля, че имах идея и за още някакви. Един хубав ден мога да допиша поне една-две от тях и да ги кача в блога, че време за говорене не се намира :)
(а много ми се иска да систематизирам нещо по темата системи от хора и други неща, но това няма да стане в следващите една-две години)

2016-12-30 новата marla

December 30th, 2016 by Vasil Kolev

Малко информация за upgrade-а на marla:

X10DRi-O дъно (C612 chipset), един Xeon E5-2620v4), 64GB RAM, 4x4TB HGST дискове, LSI megaraid, едно 1TB samsung-sско SSD, приятна 2U кутия.

Има доста още работа по нея, най-вече да навържа monitoring-а на различните хардуерни неща (smartctl не иска да си говори с контролера и да ми дава температурата на дисковете, например), както и генерално да доразчистя някакви неща там (например чак днес си оправих автоматичното подновяване на сертификатите). Има и доста други полезни неща за вършене, например да видя как да направя прилично multi-tenant схема с hhvm и nginx, за да пренеса малко тежки сайтове натам.

Но вече спокойно съм вдигнал 16 виртуалки, на които Велин да изтезава студенти.

2016-12-30 33c3 – останалите лекции

December 30th, 2016 by Vasil Kolev

The Moon and European Space Exploration беше в общи линии рекламна (и бая забавна) лекция на European Space Agency, в която директорът и (на голяма скорост) разказа какви неща са правили и се канят да правят, най-вече база на луната като отправна точка за изследване на други неща из космоса.

Interplanetary Colonization беше в общи линии преглед на съществуващите и вероятните в бъдеще технологии за космически двигатели за дълги разстояния.

Dissecting HDMI (гледах го на запис) беше доста просвещаващо и освен за стандарта и проблемите разказа и за устройството, което правят, което в комбинация с voctomix може да се окаже перфектното решение за stream-ване на конференции – може да успеем да смъкнем setup-а на доста по-малко устройства, конвертори, черни магии за скалиране и т.н.. Хората и раздават хардуер за който иска да дописва по него, много ми се искаше да имах времето за целта…

An Elevator to the Moon (and back) (запис) е пак преглед на технологиите за космически асансьор и за какво можем да го ползваме (имаше огромна Q&A след това). Като цяло в момента имаме технологията да направим такъв на луната или Марс, но за земята още не сме докарали верния материал.

Community на Мич Алтман беше за hackerspace-овете, обществата и като цяло за хакерите, хубава мотивираща лекция.

33C3 Infrastructure Review не беше толкова интересно, колкото предишни години – нямаше много подробности за мрежата, видео екипът не можа да си върже лаптопа (което беше голямо забавление за цялата публика) и като цяло най-интересна беше частта на мрежата за пневматична поща.

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

(и още няма идея къде ще е 34C3)

(мисля да гледам още, особено това, което доктора спомена в коментарите на последния post)

2016-12-29 33c3 – малко лекции

December 29th, 2016 by Vasil Kolev

Тази година гледам 33c3 от вкъщи, и май гледам по-малко лекции. Ето какво съм гледал до тук:
(обработените лекции са на media.ccc.de, ако ги няма тук може да се търсят на relive)

What could possibly go wrong with <insert x86 instruction here>? беше описание и демонстрационен код как може да чрез ползване на кеша (flush-ване, напълване и т.н.) да се комуникира между несвързани процеси или дори виртуални машини, които се schedule-ват на същия процесор (т.е. и между core-ове, които споделят кеш).

How Do I Crack Satellite and Cable Pay TV? беше за reverse-ване на чиповете, които декриптират сателитна телевизия, прилично интересно.

Building a high throughput low-latency PCIe based SDR са хора, които разработват software-defined radio на mini PCIe карта, което може да се използва за всякакви по-сериозни цели (има включително синхронизация на часовника от GPS), като за момента са до средата (не са си постигнали целта за скорост на устройството), и ако постигнат прилична цена, това може да се окаже идеалното устройство за правене на софтуерни GSM/LTE неща.

Shut Up and Take My Money! беше за как са счупили на някакви хора мобилното приложение, което се занимава с потребителски транзакции. Звучеше като да трябва да затворят тия, дето са го мислили/писали.

What’s It Doing Now? беше доста интересна лекция за автопилоти по самолети, как тоя тип автоматика трябва да се следи внимателно и като цяло, че нещата не са толкова автомагически, колкото ни се иска. Лекциите за самолетни проблеми винаги са интересни :)

Nintendo Hacking 2016 описа какво са счупили по разлините nintendo устройства, exploit-и по boot loader-и и всякакви такива неща. Това беше една от лекциите, в която се споменаваше техниката с glitching – да се подаде по-нисък волтаж за малко, така че дадена инструкция да се намаже и да има шанс да се JMP-не някъде в наш код в някакъв момент, така че да можем да dump-нем нещо.

Where in the World Is Carmen Sandiego? беше лекция за чупенето на системите за резервиране на самолетни билети и като цяло пътувания. Силно тъжно, казаха си в началото, че няма много хакване в лекцията, понеже нещата са твърде счупени и лесни за атака. Кратък съвет – не си публикувайте снимка на boarding pass-а.

You can -j REJECT but you can not hide: Global scanning of the IPv6 Internet е разработка с DNS за сравнително лесно сканиране на всички съществуващи IPv6 DNS PTR записи, та да се намерят повечето съществуващи сървъри. Доста идейно и вероятно ще го тествам някъде :)

Tapping into the core описва интересно устройство за дебъгване/слушане на intel-ски процесори през USB и вероятно и мрежа, т.е. дебъгер, който може директно да пипа процесора. Звучи многообещаващо (лекцията гледаше основно на това като начин за правене на rootkit-ове).

Recount 2016: An Uninvited Security Audit of the U.S. Presidential Election беше много празни приказки за изборите в щатите, за пре-преброяване, в което не са открили проблем, и като цяло за счупената им система.

The Untold Story of Edward Snowden’s Escape from Hong Kong разказваше за двете седмици на Edward Snowden в Хонг Конг и бежанците, при които са го крили, преди да отлети, заедно с призив за fundraiser за тях.

State of Internet Censorship 2016 беше нормалното описание, заедно с проектите, чрез които се изследва. В общи линии изводът беше, че вече цензурирането е узаконено почти навсякъде, където се случва и става все по-често явление някоя държава да си спре internet-а за малко, около разни събития.

Million Dollar Dissidents and the Rest of Us описа какви таргетирани методи се използват от различни правителства (и кой им ги продава и учи) за hack-ване и вадене на данни от всякакви устройства на неприятни за тях хора. Нещата са прилично напреднали и е все по-ясно как повечето ни софтуер не става за secure дейности.

On Smart Cities, Smart Energy, And Dumb Security беше за колко са счупени “smart” електромерите и как сигурността на тия неща никой не и обръща сериозно внимание.

Dissecting modern (3G/4G) cellular modems беше интересно описание на съществуващ хардуер, който може да се използва за 3g/4g модем (който се използва в единия iPhone даже), и който накрая се оказа, че търкаля android/linux в себе си (т.е. може спокойно да се каже, че в iPhone 6 (ако не се лъжа) има един linux/adroid).

Тия дни ще догледам още някакви от записи и каквото остава утре и ще пиша пак. Много ми се иска да изгледам повечето неща за random генераторите и лекцията за HDMI.

2016-12-14 upgrade

December 14th, 2016 by Vasil Kolev

Ще сменям хардуер на marla утре вечер, 15 декември, в периода от 7 до 9, може да се очаква някакъв downtime в рамките на 1 час.

(и понеже блогът е на marla, мога спокойно да кажа, че ако не виждате това съобщение, значи сменям машината)

2016-12-01 видео записи от OpenFest 2016

December 1st, 2016 by Vasil Kolev

Ето качените записи от OpenFest 2016. И тази година пак сме извадили музикалните изпълнения, за който се интересува:

Видео архив:
Първи ден, втори ден, пиано почивките.

youtube:

Общ playlist:
Общ playlist, technical track, advanced technical track, civic hacking, OpenBiz, social, education, music pauses, lightning talks.

2016-11-23 Интерком и телефони на OpenFest 2016

November 23rd, 2016 by Vasil Kolev

Интерком

Видео екипът има нужда от начин, по който да си комуникира между операторския пулт и камерите, в общи линии еднопосочно (т.е. режисьора да може да каже "камера 1, мръдни малко в ляво"). Предишни години за целта се употребяваха различни неща, най-често някаква част от комплектите безжични микрофони (един предавател и няколко приемника). Тази година микрофоните ни бяха кът, за това сглобих едно просто решение от ffmpeg и raspberry pi-та:

На контролния лаптоп закачахме какъвто-и-да-е-микрофон (в случая – едни jabra headset-и, които бяха под ръка) и с ffmpeg ги бълвахме по multicast по мрежата:

ffmpeg  \
    -fflags nobuffer \
    -f alsa -i hw:0,0 \
    -acodec aac -tune zerolatency -ac 1 -b:a 128k \
    -f mpegts 'udp://227.0.9.1:9000?pkt_size=128'

Скриптът взима звукът от alsa-та от микрофона (в случая hw:0,0) и ги пуска на 227.0.9.1 с малък размер на пакета, за по-ниска латентност. Ако трябва да се пусне под windows, ‘-f alsa -i hw:0,0’ се сменя с нещо като ‘-f dshow -i audio="Microphone"’ (като "Microphone" трябва да се погледне как точно се казва, понеже windows-а странно кръщава нещата, Любо беше намерил как точно).

На няколкото raspberry pi-та до камерите се пускаше следния скрипт:

while /bin/true; do
ffmpeg  \
    -fflags nobuffer -probesize 32 -i \
'udp://227.0.9.1:9000?timeout=1000000&fifo_size=100&overrun_nonfatal=0' \
    -f alsa hw:0,0
done

Това слуша на multicast-а и play-ва каквото му дойде, като има timeout от 1 секунда без никакви данни, за да гръмне и да се рестартира. Така може да издържи на всякакви мрежови проблеми и в общи линии гарантира възстановяване до 1 секунда, след като се оправи мрежата.

Това като цяло е доста хакаво и сглобено в последния момент. При мрежата, която имахме, за догодина спокойно ffmpeg-а може да бъде заменен с един asterisk с конференция и телефони, които се закачат в нея, така включително ще можем да смъкнем още латентността (на този беше около 300-400ms) и да направим двупосочен интеркома (въпреки че хората не звучаха много въодушевени). Другото, което сравнително лесно трябва да може да се добави е noise reduction, понеже доколкото знам имаше някакъв, или от микрофона и усилването му, или от самите pi-та (като за второто няма да се оправим само софтуерно).

Телефони

Кодът е качен в github, и е съвсем съвсем тривиален:

  • С един php модул (phirehose) се дърпат tweet-ове по признак и се пишат във файлове;
  • Друг скрипт проверява на какъв език са, с espeak ги обръща в говор и ги дава на asterisk-а чрез call file да ги изговори на някого.

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

На самия OpenFest реализацията беше, че имаше наслагани 3 стари черни телефона на различни места, които бяха вързани през grandstream ATA устройства (понеже бяха единствените, които поддържаха импулсно набиране) и когато дойдеше tweet с #openfest2016telefon, asterisk-а звънеше на трите едновременно и който пръв вдигнеше го чуваше.

Архив на всичките неща, дето са казани по телефона може да се намери тук.

2016-11-22 Мрежата на OpenFest 2016

November 22nd, 2016 by Vasil Kolev

Нямахме голяма промяна от миналата година. Разликите бяха следните:

  • Тази година повечето switch-ове в опорната мрежа бяха tplink SG3210, имахме само 2 cisco-та. tplink-овете са по-тихи, по-малки, (буквално) железни и стават за странни deployment-и. Ако имаха и PoE, щяха да са направо невероятни.
  • Имахме още един switch, за NOC-а в мазето (който беше и единствения leaf в мрежата). Тази година стаичката за VOC беше оставена само на видео екипа, а мрежовия се ширеше в едно мазе.
  • Понеже имахме две зали за workshop-и, имахме малко повече user-ски switch-ове, в общи линии от кол и въже;

Ето тазгодишната схема.

С техника ни услужиха пак Светла от netissat (нейния switch вече 3-4 години е в опорната ни мрежа), Стефан Леков (noc switch-а и резервния сървър) и digger (два microtik-а за workshop switch-ове). Останалото беше от мен и initLab.

Голяма част от мрежовия setup беше организирана през github-ски issue-та, та лесно може да видите какво ни се е случвало по време на подготовката.

Тази година имаше повече наши "клиенти" на мрежата – интеркомът на залите беше по IP и имаше пръснати разни странни телефони, които бяха из мрежата. Като цяло wired мрежата не изглежда да се ползва от посетителите, но все повече се оказва полезна за нас.

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

Тази година преизползвахме кабелите от миналата година и взехме един резервен кашон кабел, та нямахме никакви проблеми с изграждането на мрежата.

За uplink тази година ползвахме същата оптика на NetX, но с гигабитови конвертори и 300mbps, та не усетихме никакъв проблем със свързаността.

Използвахме и същия DL380G5 за сървър/router, като тази година Леков пусна още един такъв като backup. Пак го използвахме да encode-ва 1080p stream-а от зала България, въпреки че май тая година нормалния ни encoder щеше да се справи (за една година софтуерът е понапреднал).

Тази година се наложи да променим номерата на VLAN-ите, понеже една част от AP-тата (едни големи linksys-и) не поддържаха VLAN tag-ове над 64. Съответно адресният ни план изглеждаше по следния начин:

IPv4

id  range           name
10  185.108.141.104/30  external
20  10.20.0.0/24        mgmt
21  10.21.0.0/22        wired
22  10.22.0.0/22        wireless
23  10.23.0.0/24        video
24  10.24.0.0/24        overflow

IPv6

10  2a01:b760:1:2::/120
21  2a01:b760:2:4::/62
22  2a01:b760:2:5::/62

По firewall-а и forced forwarding-а нямахме разлика – пак пуснахме proxy_arp_pvlan за потребителските VLAN-и, филтрирахме 25ти порт и не се допускаше трафик до management/video/overflow VLAN-ите от нормални потребители.

Имахме пълна IPv6 поддръжка в потребителските VLAN-и (wired и wireless), като тази година нямахме проблемът с изчезващият IPv6 за random хора – явно най-накрая странният bug е бил ремонтиран.

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

2016-11-21 VoctoMix на OpenFest

November 21st, 2016 by Vasil Kolev

Ситуация

За OpenFest имахме две кутии от тези от FOSDEM, които в общи линии ни даваха възможност да включим почти произволен източник на видео в тях и да го изкараме от мрежата. Те вървят в комплект от две – едната се използва, за да се включи в нея лектора, другата – за камерата. С тези две кутии и малко софтуерно видео миксиране може да се направи много лесно добър setup за видео запис на една зала.

Схемата на setup-а може да се види в github, като лесно може да се види, че е доста по-прост от другите, които използваме. Негов вариант мислим да използваме за FOSDEM 2017 (което може да се наблюдава в repo-тата в github – issue-та, wiki и всякакви работи).

VoctoMix

Липсващият компонент в цялата работа беше софтуерен миксер, който да ползваме. Пробвахме различни – първо един ffmpeg с малко patch-ове (чупи се твърде лесно), после OBS (който leak-ва памет като гламав и не е особено стабилен), и накрая се спряхме на voctomix, който е разработка на CCC и в общи линии е прекрасен хакерски инструмент, който работи по следния начин:

  • Има входове на TCP портове за следните неща:
    • Видео потоци (камери, лекторски лаптоп)
    • Поддържащи потоци (фон, какво да се пуска докато не сме live и т.н.)
    • Команди за разни действия (смяна на картина и т.н.)
  • Изходи, пак по TCP, за
    • Видео поток
    • Аудио поток
    • Копие на всеки входящ stream
    • preview на потоците и изходящата картина

Софтуерът в общи линии просто switch-ва между няколко неща (някоя картина на fullscreen, picture-in-picture в някакви варианти и т.н.) и вади поток, който може да се използва. Има отделно приложение (voctogui) което се закача към него и се използва като конзола – може да показва preview на потоците и да подава команди към основния процес (voctocore).

Как го използвахме

Излъчване от кутиите

Като за начало, изкарването на поток от кутиите става с ffmpeg/avconv, по UDP, по multicast. UDP, понеже е по-издръжливо на някакви random прекъсвания и няма да създаде десинхронизация, multicast, за да може да се гледа от повече от едно място (например за проверка какво точно излиза). Командата изглежда по следния начин:

# these are needed, because the default socket size is too small.
echo 81921024 > /proc/sys/net/core/wmem_max
echo 81921024 > /proc/sys/net/core/wmem_default

echo 81921024 > /proc/sys/net/core/rmem_max
echo 81921024 > /proc/sys/net/core/rmem_default

/usr/local/bin/bmd-streamer -f /usr/lib/firmware -k 1000 -S hdmi -F 0 | \
 ffmpeg -i - -c copy -f mpegts 'udp://227.0.0.1:9000&overrun_nonfatal=1&buffer_size=81921024&fifo_size=178481'

Интересното тук са параметрите на UDP stream-а – гигантски буфери (които и по-горе се казват на kernel-а), така че каквото и да се случва, да не се бави писането в буфера. Като цяло не е проблем да се губят пакети, но е доста лошо да се получава забавяне в целия stream, понеже води до десинхронизация. (да се губят пакети също е лошо, и за целта работя по нещо, което да вкарва forward error correction в тоя поток, един добър човек е написал patch за ffmpeg, реализиращ pro-mpeg, който има точно такава функционалност, надявам се да успеем да го ползваме на FOSDEM)

Приемане във voctomix

Самият voctocore приема потоците точно във видът, в който е конфигуриран (в нашия случай 1280×720, 30fps, audio в pcm_s16le на 44100hz), в MKV контейнер. За целта скриптовете, които го подават изглеждат ето така:

#/bin/sh
confdir="`dirname "$0"`/../"
. $confdir/default-config.sh
if [ -f $confdir/config.sh ]; then
    . $confdir/config.sh
fi


ffmpeg -y -nostdin \
    -i 'udp://227.0.0.1:9000&overrun_nonfatal=1&buffer_size=81921024&fifo_size=178481' \
    -ac 2 \
    -filter_complex "
        [0:v] scale=$WIDTH:$HEIGHT,fps=$FRAMERATE,setdar=16/9,setsar=1 [v] ;
        [0:a] aresample=$AUDIORATE [a]
    " \
    -map "[v]" -map "[a]" \
    -pix_fmt yuv420p \
    -c:v rawvideo \
    -c:a pcm_s16le \
    -f matroska \
    tcp://localhost:10000

Това в общи линии казва "вземи udp stream-а, scale-ни го до колкото искаме, сгъни пикселите и аспекта да са точно каквито ни трябват, и го прати като mkv на порт 10000". Сгъването на пикселите и аспекта (setsar, setdar) се налага основно когато не може да се промени изхода на камерата и идва в нещо странно като 1920×1088, което води до малко по-различна форма на пикселите.

За да работи цялото нещо, имаме два такива скрипта (по един за box), както и един подобен, който просто loop-ва едно PNG, което играе ролята на фон. В оригиналните скриптове хората са използвали видео за фон на picture-in-picture, но това е по-объркващо за гледащите и не го ползваме.

Излъчване и запис при voctomix

Излъчването и записът са в общи линии много подобни скриптове, като ще покажа само този, който праща до restreamer-а:

#/bin/sh
ffmpeg -y -nostdin \
    -i tcp://localhost:15000 \
    -threads:0 0 \
    -aspect 16:9 \
    -c:v libx264 \
    -maxrate:v:0 2000k -bufsize:v:0 8192k \
    -pix_fmt:0 yuv420p -profile:v:0 main -b:v 512k \
    -preset:v:0 ultrafast \
    \
    -ac 1 -c:a libfdk_aac -b:a 96k -ar 44100 \
    -map 0:v \
    -map 0:a -filter:a:0 pan=mono:c0=FL \
    -ac:a:2 2 \
    \
    -y -f flv rtmp://10.23.0.1:1935/st/STREAM

(скриптът е примерен, понеже доработвах след това нещата)

Като цяло, просто се взимат raw данните от порт 15000, encode-ват се до H.264 и се пращат до сървъра. По същият начин може да се обръщат във WEBM и засилват, но той иска много повече процесорно време и не сме стигнали до там, че да го ползваме.

Екстри за voctomix

Нещо, което не включихме на OpenFest, но ще има на FOSDEM е една дребна доработка, която позволява с много малко ресурси хора отдалечено да контролират voctomix-а. По принцип voctogui не е лек процес и има много сериозни мрежови изисквания, ако не се стартира локално (от порядъка на 1Gbps само за него), но позволява всякакви ужасяващи неща с малко дописване. С един прост скрипт, който прави screenshot веднъж в секунда, и съвсем прост друг, който подава команди ще имаме начин определени хора да имат контрол върху излъчването.

Също така нещо, което ползвахме донякъде на OpenFest за monitoring на stream-а е един друг скрипт с mpv, който взима списък URL-та и някакви имена към тях и ги пуска в отделни подредени един до друг прозорци на екрана, като за всеки overlay-ва един bar с нивото на звука, така че да може да се вижда дали е ок (понеже не е практически възможно да се слушат няколко зали едновременно). Проблемът му е, че се иска бая процесорно време, за да се декодират повечето потоци и един T420 с i7 процесор се озорваше с 6те потока от феста. Как изглеждаше екрана може да видите тук.

Опериране

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

  • voctocore
  • voctogui
  • скриптове за приемане от камери (cam1.sh, grab.sh)
  • скрипт за генериране на фон
  • скрипт за stream-ване
  • запис (record.sh)

След което от voctogui при нужда се сменят различните картини. Като цяло е доста по-просто за разбиране от по-големите setup-и с конвертори и т.н., но и с по-малко функционалности.

Доколко добре работи?

Работи прекрасно, въпреки че се опитваме да открием един бъг с забавяне на audio-то, който се появява в някакъв момент. Започвам да си мисля, че има някакъв проблем със самия лаптоп, с който правим миксирането.

Какво още можем да искаме?

Хрумнаха ни няколко екстри, които да добавим, така че да стигнем функционалността на хардуерния setup:

  • Начин да излъчваме екрана за проектора от при нас. Това ще иска някаква доработка, за да смъкнем латентността на цялото нещо под 100ms, понеже иначе ще е доста забележимо (представете си как лектора прави нещо и проекторът се променя след 5 секунди). Единият от вариантите, който ни хрумна е проекторът да е вързан на едно pi и то директно да може да избира кой multicast да гледа (някоя камера, лаптопа на лектора или нещо трето).
  • Overlay надписи по време на лекцията – трябва да видим какво има да се пипне още, мисля, че има някаква такава функционалност (или може да ги сложим във фона).
  • По-добра синхронизация на различните потоци – ако работим с няколко камери, може да се окаже проблем, че едната върви с няколко кадъра след другата и трябва да си поиграем със забавяне.

Като цяло, аз съм много щастлив от voctomix и ако успея да убедя екипа, догодина можем много повече да ползваме него, отколкото чисто хардуерния setup (просто ще ни трябват мощни машини, за да се справят с encode-ването, че засега успяваме да работим само на 720p, без да подпалим лаптопа).