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

RIPE SEE-3 ще се проведе следващата седмица в София. Ще има двама български лектори (Венета Донова и аз), публикували са програма, ако искате да дойдете, все още може да се регистрирате.

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

(и определено можеше да е по-добре, не става добре да говоря на конференции, където имам занимания и с организацията)

Single points of failure

[за какво става въпрос]

Single point of failure е единичен компонент от система, при чиито отказ цялата система спира да работи.

В системите, които правим/ползваме и са повече от един сървър, на който ни е всичко (т.е. един гигантски SPOF) такива неща пак се срещат доста често.

[авиационен модел]

Това е мечтания модел, който даже съществува в реалния свят. Това е напълно подсигурена система, при която имате главен компютър с един софтуер и един хардуер, backup компютри с два различни хардуера и един софтуер, който е различен от главния, и система за следене и кворум. В самолета освен това има и двама пилоти и всякакви резервни варианти.

[авиационен модел 2]

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

Също така системите стават твърде усложнени, като пример – A380, който е наистина подсигурена система, има в себе си 530км кабели. Цената да се изгради и да се поддържа такава система не е по силите на някой друг.

[три неща]

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

[Софтуерни]

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

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

[Meatware]

Човешките SPOF-ове са още по-гадна работа. Известни са още като “Bus factor”, т.е. колко човека трябва да ги блъсне автобус, за да спре да работи даден проект (и в много случаи факторът е 1).

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

Метод за омекотяване е писането на документация, което па всички го мразят.

[цена]

Оценката кога си струва да се вложат средства, за да се избегне SPOF не винаги е тривиална и е за друг вид лекция. Има неща като risk assessment, гадаене по черва на гълъби, хвърляне на зарчета и статистически анализи, които се използват за целта, но много често и хората, които ги предлагат ги объркват…
(който се интересува от проблемите на анализа на риска, може да зачете Насим Талеб)

Като едно лично правило, гледам системите да нямат в себе си нещо, което е наистина трудно за дистрибутиране, или ако го има, да е максимално подсигурено (хубав хардуер, monitoring, резервни части, някакъв вариант да се реагира).

[state]

И нека се хванем с основния проблем във всички тези неща – състоянието, или state, както му викаме.

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

Искам да го повторя и да покажа, не съществуват stateless системи.

[примерна не-stateless система]

Ето един често срещан пример – смята се, че ако имаме такава схема, то web сървърите ни са stateless, понеже реално са взаимозаменяеми.

От гледна точка на системата те имат два вида state. По-маловажният са заявките, които се обработват в момента (които не се смятат за важни и съответно дори да се загубят, се смята, че може да се повторят. Важният state е един бит, който казва дали този сървър е активен или не, и дали може да обработва заявки.

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

[решения]

Ето няколкото типа решения на проблема.

[do nothing]

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

[backup plan]

Може да не е толкова безсмислен като тоя от слайда :)
Тук решението е да знаем какво правим, ако нещо се счупи. За някои по-малко важни системи например backup plan-а може да е “машината е в гаранция, ако се счупи нещо, обаждаме се на тия от които сме я взели и така”, или “обаждаме се на другарче”.

[cold spare]

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

Това е и едно от най-често срещаните решения, понеже доста лесно се прави. От друга страна може да предизвика прилично количество donwtime, докато се “стопли” резервата.

(някъде тук на лекцията се оказа, че има хора, които не държат резервни крушки у тях…)

[hot spare]

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

Това много често се изполва в setup-и с бази данни или подобни неща, при които чистото дистрибутиране (за което ще говоря по-нататък) не може да стане заради CAP теоремата.
(ще намразите cap теоремата след малко)

Тук има един специфичен момент, т.нар. fencing – ако втората система поема работата на главната, трябва по някакъв начин да се гарантира, че главната е спряла и не прави нищо, за да не се стигне до омазване на shared state или нещо такова. За целта има няколко типа решения, някои от които просто спират тока на главната :)

[CAP теорема]

И така, преди да си говорим за най-хубавия начин – да имате N на брой машини, те да вършат едновременно работа и хем да се scale-вате, хем да сте защитени от сривове, да кажа защо това е непостижима мечта…

Теоремата е съвсем проста и гласи следното: една дистрибутирана система може да има най-много две от следните три свойства: Консистентна, винаги достъпна, издържаща разделение.

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

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

Издръжливостта на разделение значи, че не може да се достигне т.нар. split brain ситуация – ако системата се раздели на две части, не може двете да мажат в/у данните и да се получи при тях различна версия.

Това например значи, че не може по някакъв елементарен начин да си направите master-master репликация на базата данни.

[дистрибутиране]

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

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

[load ballancers + web]

Това е един доста класически случай за повечето сайтове, на които не им се иска да имат downtime. Слагате отпред два load ballancer-а, които знаят кой от web сървърите отзад работи и балансират м/у тях заявките. Това работи много добре, сравнително стандартизирано е и сглабянето му не отнема особено много време. Достатъчно стандартно е, че amazon да предлагат компонентите му като някакъв service.

При отпадане на компоненти системата го усеща и спира да му подава трафик.

RAID масивите са доста близки като идея до това.

[синхронни бази]

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

[hack-ът за eventual consistency]

И има една добавка, като удобен hack при системи, при които има случаи, в които може да се прочетат стари данни, т.нар. eventual consistency.

В общи линии това представлява система, за която операциите за писане са приключили при запис в X компонента, като обикновено X=N/2 + 1. Тогава имаме inconstent четене, което може да чете от 1 компонент, и ако ни трябва консистентно, четем от N-X+1 компонента. Това се използва основно за системи, при които консистетният read е рядка операция.

[sharding + replication]

Това е текущият метод за репликиране на база данни. В общи линии умножавате факторите за на колко искате да разделите данните (за performance) и за redundancy и получавате колко железа ви трябват (в случая са 2X2).

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

Преди няколко седмици излезе първото издание на “Is Parallel Programming Hard, And, If So, What Can You Do About It?” – книга под creative commons на Paul McKinley (по принцип kernel developer). Полезна е и информацията в нея е доста прясна и точна (а и като гледам, голяма част от нещата там не са се променяли от доста време, и има неща като RCU, memory бариери и т.н.) и я препоръчвам на всички.

Аз разпечатах десетина копия, и в момента има по едно в initLab, VarnaLab, BurgasLab и hackafe, като се планира втори print run, ако има хора, които имат желание да си вземат. Цената ще е около 30лв на копие, ако имате желание, пишете.
(или може да си я четете online или да си я разпечатате сами, не е сложно:) )

Мина RogueConf 2014. Направихме го тоя път в Боровец, в х-л Radina’s way, и си изкарахме доста добре.

(записи)

(има странен момент с името. На разни материали беше объркано и беше Rougeconf (“розова конференция”), та това в един момент стана официалното име. Мисли се догодина да е RoughConf (а ако Стефан реши да е RogeConf, аз няма да ида))

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

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

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

От лекциите мога да препоръчам:

“Storpool – Reinvent all the wheels” на Боян Кроснов (трябва да я направи в два часа);
Общество.бг на Димитър Димитров(lightning talk)
“СофтУни – докъде сме с проекта” на Светлин Наков (голямо шоу);
Maycamp arena на Валентин Михов – невероятно идеен и готин проект, силно препоръчвам;

Разходка през съвременния CPU pipeline на Борислав Станимиров – освен, че беше много добре описано, беше и ултра забавно, страхотна лекция за всички, които искат да разберат как работят модерните процесори;

…и като цяло да разгледате всичките лекции.

А от не-лекциите, Стефан жонглира.

За моята лекция ще пиша отделно (не се получи толкова добре, колкото исках, и ми се иска да кача пооправения текст).

(за “масонския” елемент, т.е. че беше invite only и пак някакви хора се оплакват, че не са поканени – нещастните от това хора могат да си организират собствена и да не ни канят)

Update: Явно много ми се е спяло снощи. Още няколко интересни неща:
Боби трябва да направи някой ден лекция с резултатите от трите мъжки въпроса, които задава;
Титов направи интересен кратък talk за linux fibers, в който за съжаления няма код, но е едно от по-забавните неща, които сме правили в последните няколко месеца;
Аз разказах на хората какво е ИББ и защо трябва да има повече такива събития;

(това може да го приемате и малко като спам)

Тия дни писахме една сравнително хубава обява за работа и я пуснахме в jobs.bg и stackoverflow. До тук няма кандидати, та въпросите ми са:

1) толкова ли е зле обявата?
2) хора ли няма, дето да отговарят?
3) На грешното място ли я пускаме?

Ако 2) е вярно, явно ще трябва да почна да правя деца и да ги уча…

Има много изписано и изговорено на темата за тревата/марихуаната, наказуемост, полезност/вредност и т.н.. В последния проект за НК има някакви малоумия по темата, и понеже не ми се навлиза в спора, искам просто да споделя едно мое лично наблюдение.

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

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

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

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

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

Update: Казаха ми, че все пак си ми личало, че съм бил пушил.

Update 2: Направо не мога да повярвам, българския съд е направил нещо добро по въпроса.

На 26.03 ИББ ще бъде в “Кривото” на НДК (вместо на “Дондуков”), поради ремонт. Ще са ни запазили маси и т.н..

Update: на 26ти МАРТ, не април.

В последните два дни бях на RailsGirls Sofia (Kaladan е качил малко снимки).

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

Иначе, като малко бележки за бъдещи събития там (проведе се в академията на Телерик):

– да са по-разпръснати хората, че на моменти не се дишаше;
– да изберем по-свястно тиксо, че два часа махахме очертаните лабиринти от пода;
– wireless-ът им не издържа, или да добараме достъп да видим дали не може да се направи нещо, или да си носим наш;
– internet-ът им има странни филтрирани портове и много ми се искаше да им се добера до firewall-а с един конзолен кабел;

и извън това

– memento е твърде малко заведение за afterparty-то, освен ако не го запазим цялото. За малко да ме хване клаустрофобията вътре.

Иначе – това е N-тото нещо в последните няколко седмици, в което се набутвам и мисля да разкарам всичките си социални ангажименти за поне една седмица и да поработя на спокойствие.
Уморен съм.

Преди няколко години направих един не-курс по системна администрация, чиято цел беше да даде на участниците опит, достатъчно близък до практическия. Работим по въпроса с Данчо и Леков да направим още един такъв тази година, с още по-забавни задачи (днес обсъждахме част от тях и бях обявен за извратен човек (за пореден път)), въпросът е има ли желаещи и колко ще са?

Ако ви се вижда интересна идеята, пуснете един коментар.

(отдавна се каня да го напиша)

Преди някакво количество години бях решил да пробвам различни уискита (след като Велин поиска за една работа да му се плати с една бутилка Ardbeg, щото му беше станало интересно), бяхме седнали в един бар в студентски град (“Masterpiece”, имат огромна колекция), бяхме отворили wikipedia и гледахме статията за Islay. След като нямаха Laphroaig, ми сипаха един Lagavulin и аз толкова се влюбих в него, че в следващите дни си намерих доставчик на едро, и когато се изнасях от предната квартира открих, че имам около 1 куб. метър кутии от него.

С годините тествах различни неща и открих, че в крайна сметка човек след като мине на пушени уискита, другите не са му интересни. Също така по-трудно се попада на ментета, и от тях глава не боли (а съм изпивал бая…). Ето малко бележки по нещата, които съм пробвал, ако някой иска повече информация, Iain Banks е писал книга по темата – “Raw Spirit” (питали го “не искаш ли да обиколиш Шотландия, да пробваш всичките уискита и да напишеш книга, и той в първия момент си помислил, че се шегуват с него. Всички, на които казал после го питали дали не иска помощ…).

Пушените уискита идват основно от Islay в Шотландия (малък остров с малко хора и много алкохол). Това, което най-лесно може да се намери от там по нашите магазини е Lagavulin и Laphroaig. Аз съм тествал:

Ardbeg – много торфено и доста остро. Някои хора много го обичат, аз не толкова. Имам един Ardbeg Corryvreckan, който е доста по-мек и който е печелил уиски на годината преди 2-3 години, и се хареса доста на последния запой вкъщи.

Laphroaig – Хората се делят на два лагера, има такива, дето го харесват и такива, дето не (аз съм от вторите). Пак е доста остро, малко по-малко от Ardbeg-а.

Lagavulin – първото ми любимо уиски. По-меко от Ardbeg и Laphroaig, много опушено, с истински, пълен вкус. Много хора казват, че им мирише на терпентин/доктор/акварелни боички (за другите какво казват, не ми се ще да мисля), но като цяло за мен то е централния вкус на уискито от тоя остров. Води се май едно от най-опушените уискита там (като изключим някои неща като octomore).

Kilchoman – това е най-новата дистилерия на острова, и определено ми станаха новото любимо питие от там. Kilchoman machir bay има още по-приятен аромат от Lagavulin-а, пак е меко и като цяло се пие с голямо удоволствие.

Octomore е един странен експеримент на дистилерията Bruchladdich, направили са най-опушеното възможно уиски. Има мярка за опушеност, ppm (parts per millon) на фенолите, и Lagavulin е 45ppm, Octomore 3 е 152ppm. Има няколко версии, като моите любими са 3 и Comus (5 горе-долу ставаше, новите – 10 и т.н., вече не стават). Също така са по около 60 градуса и много точно може да усетите първата глътка как си прави път през вас.

Bruchladdich имат още много други различни неща, например едно Cuvee (неопушено), ама те искат още research от моя страна.

Горе-долу това са тези от Islay, които са ми били интересни. От опушените има още едно, което много ми хареса – Glen Els Ember – немско уиски, пушено на дърво, провах го на CCC конгреса миналата година, и което трябва да се намери начин да се внася в България.

Имам и някакво количество не-опушени неща, които държа основно за други хора – основно Cardhu, на което аз викам “дамско уиски”, щото го пият основно девойките, дето не харесват пушеците.

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

И пак имаше концерт на Sativa и Center в JetRock, като миналата година.

Силно размазващо, претовари ми се куфелния мускул. Sativa бяха приятни, Center луди, и накрая имаше половин час импровизация от музикантите от двете групи плюс още някакви (вкл. барабанистът на “Mental Architects”, които определено трябва да чуя). Може би ми е толкова весело, щото ми е разбъркан мозъка все още, но определено трябва това да го правят по-често :)
(миналата година импровизацията беше час и половина, ама нека да не бъдем алчни)

(питах, Sativa имали 4 записани и немиксирани парчета, та може някой ден да изкарат албум)

Това чак не е интересно.

Ровейки един spam, който един приятел е получил, се загледах в DKIM подписите. Оказва се, че DKIM-а се лови от тривиално replay-ване, т.е.:

Правите си account на някое уважавано място (например gmail, в конкретния случай обаче е abv.bg). Пращате си mail до себе си, който ви генерира едни валидни подписи. Взимате цялото съобщение като source, един ваш smtp сървър, и го пращате на който си искате. От гледна точка на хората, уважавания доставчик е минал през вашия сървър и е пратил съвсем валидно писмо…

DKIM-а не знам кой го е мислил, но ето header-ите му:

DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=abv.bg; s=smtp-out;
	t=1393422571; bh=4dLtPPWnymIO/8L0CLbvGZYxlQ5bZYMBimz0R/Li/JY=;
	h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type:DKIM;
	b=RQhl7IakYWwDQb70tpH3nG6V7CFcisAs/AyIO9/g0OpaIFD0jJpm8KbGOZ+UvVpK5
	oeSzu2HLUUFOd6/o+8NHJWHTEwPKf80RZXtnkN4Jp2S/OKKBC5TImFupHy+s1uUgjhD
	9yDf3LZES95JquPBNdYbotBZhc6wd9x1dNTJKCM=

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

Това е толкова тривиално, че чак българските spamer-и го ползват. Чак се чудя дали това с валидния DKIM подпис е нарочно или просто така е станало…

Интересна работа. Имаме SPF (описване на валидни източници) и DKIM (подписване на header-и от валидните източници), и нямаме свястна комбинация от двата протокола, която ДА ВЪРШИ НЯКАКВА РАБОТА.
(и разбира се, ако сте с валиден DKIM подпис, gmail и разни други мърлячи ще показват в получения ви mail картинки от външни линкове. Ето как тривиално спамерите ще видят дали ви е верен/работещ/четен mail-а)

И стандартния post за празнуването на крокодиловден.
(празнувах на 22ри, щото 23ти е неделя и в понеделник никой нямаше да иде на работа)

Събрахме се, пихме, веселихме се, т.е. стандартното. Очаквах, че като ставам на 33 някой ще ми върне жеста и ще ми сковат кръст и т.н., но имаше само един чук и пирони…

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

От останалите неща това, което мога да фокусирам:
Мандолина;
Glenfidich 18, Glenfidich 12 и един Gentlemen Jack;
Един стар Sun сървър;
Един търмък и подобни инструменти за градина/user-и;
Надуваема овца, вазелин и т.н. (познайте от кого);
Тиган за палачинки (с идеята да каня хората, дето ми го подариха и да им готвя, оптимисти);

…и други. Като ми се спи малко по-малко, ще ги допиша.

Весело беше, догодина пак.

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

Проблемът е следният: как да разберем, че не можем да пращаме mail до определено място, като ни дойде bounce от там? Да се parse-ва самото писмо е загубена кауза, понеже няма никакъв ясен формат.

Идеята е сравнително проста: във всеки mail има Return-Path: header, който винаги е първи, и към който се bounce-ва mail-а. Ако всяко съобщение има уникален такъв, може да се познае за кой получател (и може би и за кое съобщение) става въпрос. Самият bounce може да се познае по празният return-path (така че ако някой заблуден spam реши да дойде, да не създаде проблем).
(като всички такива хитрини, и тази е открита от Дан Бернщайн и даже си има нещо като стадарт – Verp)

Има различни начини да се направи, последният вариант, който написахме правеше return-path-а да е във следния формат:
UID_TIMESTAMP_SIGN@bounce.domain.com
където uid беше id-то на потребителя от базата, timestamp си е unix-ки timestamp и sign е sha1 на uid_timestamp_secret, като secret само ние си го знаем и така можем да проверим дали наистина ние сме го генерирали това. За да се избегне един race condition, в който потребителя си е сменил email-а преди ние да получим bounce, може в sign да се включи и оригиналния email адрес, така че bounce просто да не match-не сигнатурата си.
(гледайки сега по стандарта, заради graylist-а може да е добра идея да сменя първото _ с +)

От там нататък просто ви трябва нещо просто, което да засилва цялата поща за @bounce.domain.com към един скрипт, който да прави тривиален анализ на header-ите и да казва “да, тоя mail не е верен”.

Днес е the day we fight back.

(по случая повечето неща при мен вече са с форсирано https, сайта на initlab по същия начин, трябва да погледна по списъка какво следва)

(мяу. т.е. това е много насмукан post)

След ден, в който прегледахме варианти за хотели, обсъдихме rogueconf и ни дойдоха добри идеи, имаме остра нужда от designated протоколичик, който да записва какво сме измислили, че да го пледнем трезви и да се гърнем от ужас.
(Яна не става за тая цел – толкова се е повлияла от нас, че почва да пие по отрано).

Приемаме кандидати, които не искат заплащане, не пият, биха вършили тая работа и все още нямат жълта книжка.
(bonus е кандидатите да могат да ми помогнат да се занеса в леглото след такива писания)
(също така, ако някой ден си взема клавиатура с LED клавиши, ще взема и дрегер към нея, и в пияно състояние backspace ще свети винаги, когато има наблизо думи, които spellchecker-а не харесва.)

Update: Сутринта си видях машината и изобщо не си спомнях, че съм писал тоя post. Оставям го некоригиран…
Update 2: “не пият” да се чете като “не пият много”…

По случая, че ми пристигнаха бутилките Glen els Ember, едно дребно наблюдение:

Ако Steven Moffat и Joss Whedon направят сериал заедно, ще сме ок след това света да свърши.
(в който да участват Sarah Alexander, Morena Baccarin, Alyson Hannigan, Gina Belman, Sarah Michelle Geller, Nathan Fillion, Richard Coyle, и… може и още някакви, от мен да мине)

Днешния ден може да го броим за полезен.

Изнесохме с Митьо и Петко сайтовете на турнето при мен, подкарахме един setup за ruby приложения (продадох се и аз на хипстърската страна на силата), та там нещата са ок. Остава да припалим (почти за идеята) dnssec на it-tour.bg, ама трябва да видя как може да стане номера (register.bg го предлагат, ама domain-а са го регистрирали през superhosting).

На ludost.net вече има wildcard сертификат за всичко, който се приема (и vasil.ludost.net вече пренасочва само към https). Има валидни сертификати на jabber-а, irc-то, пощенските неща и квото-там-намерих. Тия дни ще си направя и TLSA записи.

Подкарахме https и за initlab.org и cassie.initlab.org, но понеже там Петко взе безплатните сертификати от startssl, трябва да почакаме един ден, докато се update-не OCSP-то.

Около това си преписах скрипта, който генерира config-а на apache на marla (за всички сайтове да има https и v6 vhost-ове). Следва да разцепя още малко конфигурациите, за да могат да разделя .ludost.net нещата от другите и да форсирам https за *.ludost.net. Някъде по пътя – tlsa :)

С това може да борим hackaton-а за thedaywefightback.org за приключен.

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

Ходих на “Непознатите истории на социализма I: Забравени или заличени. Лагерите на смъртта”. Представляваше прожекция на кратки неща и разказ от Христо Христов накратко за историята на лагерите.

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

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

След това Христо Христов разказа за разследванията си за лагерите. Спомена доста интересни неща, които трябва да погледна, например:
Спомени на Петър Семерджиев, който е лежал по лагери преди и след 1944;
Книга на Крум Христозов, в която има и рисунки на самите лагери (никъде няма запазени снимки, т.е. вероятно няма никакви);
Самият лагер в Ловеч по някакво счетоводство за няколкото години, в които е работел е изкарал 6м лв, което определено искам да проверя как е станало (Солженицин има много интересни изследвания за неефективността на съветските лагери);
Има поклонение всяка последна събота на март в Ловеч за жертвите в лагера, организира се от хора от самия град;
Планира се да има по-голямо и пълно издание на книгата на Христов за лагерите, с по-пълна и подробна история (това беше въпроса, който се канех да му задам, но той сам си каза);

Във въпросите някой запита защо всички говорят само за съветските и нацистките лагери, а никой не споменава тези, които били организирани в Либия от италианци, или от англичаните в Индия. Аз лично от него разбрах, че е имало такива и вероятно ще се заровя в темата…

(лекцията беше записана, не знам къде ще се появи записът, но ще пусна link, ако чуя нещо по темата.)
(сайтът на Христов е desebg.com, има доста информация за книги и филми по тези въпроси)

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

Чак се замислих дали да не си налея едно.