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

Автор: Владимир Витков / 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. Единственото смислено нещо, което виждам да може да се направи е да се мисли метод, който без да обижда хората да може да оценява компромисите и да може да се смята как точно да се направи един компромис. От друга страна, не мисля, че е особено възможно и се надявам някой да покаже, че не съм прав :)

И малко спомени от openfest 2015…
(ще има подробни неща по темите за мрежата и т.н. по-нататъка)

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

Самата организация беше започнала още около март/април/май месец, когато подписвахме договора със зала “България”. Последваха поне 10 посещения на залата, в които да видим как може да се пусне мрежа, ток, да се наместят камери, да се разположат различни неща и като цяло да се случи събитието. Винаги при смяна на залата има някакви неща за изясняване, а специално там инфраструктура нямаше за нищо (освен за провеждане на концерти, но роялите и контрабасите на нас не ни помагаха:) ).

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

От мисленето и setup-а имам няколко снимки:
Дъската със схемата на мрежата;
Усилени обяснения;
Море от хардуер;
Част от нещата, пакетирани и готови за транспорт.

(в нещата ни за носене имаше маси, мокети, кабели, телевизори и какво ли не още)

От петъкът (6.11) имам следните откъслечни спомени:

– нещата започнаха да пристигат с час и половина по-рано от уговореното;
– изведнъж се оказа, че сметките за дължината на мрежата са грешни и ни трябва още един топ кабел;
– огромните масивни гардероби на зала България бяха преместени без да убием някой;
– екипът логистика успя да достави навреме всичките неща, с много игра на тетрис в няколкото коли, които имаха;
– тотално не си спомням какво ядохме и дали ядохме (трябва да е имало някакви пици, но не съм сигурен);
– мрежата успя да запали към 18, всичкия wireless скоро след това (като гледам, и логовете го потвърждават);
– записахме един концерт, който се проведе в камерната зала;
– за видеото успяхме да приключим към 1:30 и да си тръгнем;
(освен това двамата Пешовци направиха дует в камерната зала, който не знам дали е записан)

Съботата започна весело. Успяхме да довършим някакви неща, открихме конференцията, и setup-а за първия лектор (Арал Балкан) се счупи и не се показваше на проектора. Последва усилено дебъгване и с няколко рестарта нещата тръгнаха, а той успя супер умело да го включи в лекцията си.
(имаше съмнения, че е било направено нарочно така, но реално си имаше проблем).

В откриването имаше включен струнен квартет, който изсвири няколко приятни неща (вкл. “Smoke on the water”), които май зарадваха публиката. В паузите имахме пианист (на който му пригласяше една певица от време на време), като цяло конференцията тази година си имаше и музикално оформление.

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

В събота вечер успяхме да отстраним едни от последните проблеми и след едно спокойно ядене в “Кривото” отидохме да се наспим.

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

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

Последва събиране, изнасяне и разнасяне на мебелировката и техниката, като бяхме готови в рамките на 2 часа, което намирам за невероятно постижение, имайки в предвид колко много неща имаше. Към 8 изгасих последните лампи там и се изнесохме до initLab, където качихме останалата техника и отидохме да пием в mixtape.

Аз лично се напих прилично и бях прибран вкъщи. По свидетелски показания разни хора са пили до 5, други са пуснали по мониторите в mixtape логото на openfest, изобщо – веселба…

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

И малко новини около OpenFest:

До утре вечер може да си запазите тениска;
Имаме програма за лекциите и workshop-ите, както и схема на мястото;
След резултатите от референдума ще имаме и лекция за online гласуването, ето защо;
Сайтът вече има ssl сертификат от letsencrypt.org, благодарение на Петко сме им в beta програмата (и работят като слънце);

Думи не могат да опишат лудницата. Stay tuned :)

И като продукт на submission-ите на много хора, гласуване от hackerspace-овете, нашето търсене на лектори, 5-6 часа спорове в програмния комитет и няколко дни писане на код – почти финалната програма на OpenFest за тая година :)

Опрях до там да имам един текстов файл с какво имам да върша всеки ден, че да мога да си следя всичките задачи. Явно ще трябва в него да слагам и “блогни” от време на време.
(знам, че някакви хора ползват модерни работи като календари, обаче за мен един файл в git, комбиниран с vim, който commit-ва на всеки save се оказва перфектното решение)

Занимавам се с всякакви скучни работи:
– Оправям хартии по фондацията, например писмо до ДАНС, че няма да перем пари и финансираме тероризма (вече не се учудвам какви глупости изисква държавата;
– Разни хора правят мрежата на OpenFest, а аз рисувам картинките;
– Случва ми се да спя;
– Пиша правила за очаквания co-location на initLab (който ще се случва, има само дребни подробности за дооправяне).

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

От по-интересните неща:
– направих банички (за Снежи), след като не ми се беше случвало едно 12-13 години. Станаха прилично :)
– подредихме и направихме по-прилично мрежата на лаба, с Пешо и Марио, та сме на малко от заветната цел да навържем и лампите отвън да се контролират автоматично и да не трябва да се притесняват хората от тъмната уличка;

И за да пропусна групата “ужасни неща”, няма да говоря по работа :)

Понякога отнема над 6 часа на двама човека да стигнат до workaround, колкото и да е грешен.

Мразя perl.

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

Двама човека пишат доста усилено (и смислено) за електронното гласуване – Делян и Божо. Двамата успяха да внесат интересна промяна в моето мнение по въпроса…

От техническа гледна точка има ужасно много, което може да се сгреши. Може реализацията и дизайна да са затворен процес, да го пишат идиоти, да разчита на счупена криптография, да работи само под IE6 и какво ли още не. Може да се изредят хиляди хора да се опитат да си оставят backdoor вътре.

Обаче това не е от такова значение за самия въпрос – трябва ли ей-сега на референдума да подкрепим електронното гласуване.

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

Снощи бяхме на концерт на Уикеда в Маймунарника. По закона на Мърфи валя през повечето време и си беше прилично хладно.

Самият концерт не беше никак лош, като явно бързаха, щото вместо една песен свиреха по 2-3-4 едновременно. Получаваше се доста забавно (особено като вкараха Hava Nagila в средата на нещо) и доста радващо. От друга страна, веднага си пролича силата на класическата музика, като изсвириха “Killing in the name of” и публиката се разскача двойно повече (не само за да се стопли).

(а около парка беше пълно с хора, които се опитваха да се приберат от другия концерт – май Слави Трифонов на стадион “Васил Левски”)

Бях на концерт на Apocalyptica в Пловдив вчера ден.

Бях им чул малко от последния албум и не успях да изслушам изцяло и една песен – тоя им вокалист звучи гадно, а барабаните заглушаваха всичко. Същото това нещо се повтори на концерта, придружено с някакви разминавания в timing-а на музикантите (или на мен главата ми е почнала да възприема с различна скорост различните честоти), като дори старите и добри неща звучаха накъсано и в общи линии май само “Ruska” (ако не се лъжа) и началото на “One” се получиха добре.

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

За сравнение като се прибрахме в хотела пуснах “Inquisition symphony” да я чуе Снежи, и дори на гадните колонки на лаптопа си личеше разликата.

Като цяло, нищо общо с първия им концерт в Пловдив или с тоя им през 2006-та в София.

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

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

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

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

Status update на не-курса.

А на мен ми се спи. Седмицата ми мина основно в meeting-и, и работни, и извън-работни, имам да дочертая едни схеми за OpenFest и май първо ще си отспя и след това.

И дойде време да се обяви зовът за лектори, лекции и всякакви забавни неща за OpenFest 2015. Мястото за подаване на заявки е cfp.openfest.org, имаме същите потоци като миналата година и както обикновено, се радваме на всички подадени заявки за лекции и workshop-и.

Тази година сме в зала “България” (т.е. в Софийската филхармония), където и залите са по-големи, и мястото е повече, та оплакването от миналата година – “аз дойдох на фест, ама трябваше да гледам на телевизор” не трябва да важи :)

Да видим доколко съм адекватен да пиша :)

Направихме VarnaConf 2015, а след това – и Rails Girls Varna 1.0.
(записи – като станат готови, при добър късмет идващата седмица, реалистично – следващите три)

За VarnaConf успяхме в петък да setup-нем двете зали за около 3 часа, с по-сериозните setup-и (ето в общи линии схеми на setup-а на голямата зала (3), малката зала (2) и мрежата, иска ми се да направя една голяма на всичко). Имахме прилично количество проблеми, но големия setup е сравнително отработен, а не-отработения (за малката) се получи доста добре (понеже бях делегирал голямата зала на Марио да вика по хората и се занимавах с нея :) ).
(Варна е ужасяващ град. Излязохме от залата към 9 вечерта, уморени и гладни, и открихме как навън е горещо и МНОГО влажно. Стана ми ясно защо хората излизат само по нощите – през деня там просто не се живее)

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

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

Rails Girls си беше нормално, като изключим това, че токът на залата не понесе 60 лаптопа и другата техника и спира на няколко пъти, докато не пуснахме един удължител от коридора от друг контакт. Трябва да си отбележа да искам подробни схеми на тока на всичките зали, в които правим такива неща…
(също така има някакви записи от обясненията на Митьо (известен като “Релсата” или “Корпоративния хакер от джитхюп”) какво е програмиране и lightning talk-овете от събитието, които е много вероятно да бъдат качени (ако стават за нещо)).

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

Update: Обещаната пълна картинка на нещата.

На 15.08 ще се случи четвъртия VarnaConf. Този път сме upgrade-нати и ще имаме два потока, като във втория сме наслагали малко по-админски теми. Очаква се да е весело (както обикновено)…
(запазване на тениски, fb event)

Има и CCC Camp, от 13 до 17 август, който ще се stream-ва в initlab и в който се очертава да има разни интересни лекции (аз си направих предварителен списък), вероятно и ще пиша тук за някои от тях.

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

Като за начало, на последния CCC конгрес имаше две лекции по темата, за проблемите на internet гласуването в Норвегия и в Естония, полезни са като идея за проблемите, както и предишното нещо, което написах по темата.

Не мисля, че някой изобщо схваща колко ужасяващо е счупен целия ни технологичен стек и колко лесно се атакува, от хардуера, през firmware, през операционните системи, през протоколите до user-facing нещата (особено browser-ите). Всичко подлежи на атакуване и чупене срещу сравнително малко пари (човек може да си купи нужните exploit-и за под $500k и за още $100-200k може да си реализира цялата атака, което е в общи линии под 1/10 от парите за една нормална кампания).

Също така, единствената работила някакво време система за online гласуване е тази в Естония, която се крепи в общи линии на единия човек, който я е писал, заедно с екипа, който е подбрал. За да се намери такъв човек в България, на който хората да вярват и да може да свърши работата ще ни трябва клъстер от Диогеновци, които да ходят и да го търсят със свещ из страната.

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

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

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

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

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

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

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

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

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

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

На 23ти юли Data Science Society организираха лекция на Преслав Наков, “The web as a training set”. Записът е готов, одобрен и може да се свали от тук.

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

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

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

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

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