Posts Tagged ‘работа’

2016-04-22

Friday, April 22nd, 2016

Трябва да пиша по-редовно, да не се получава миш-маш като тоя по-долу.

Както обикновено, ми върви на дебъгване. В последната седмица от по-странните неща се сещам за:
– build на android image (за нещо, правено и писано от (некадърни) китайци);
– Java/groovy;
– Python;
– И нормалното количество VoIP бози.
За да завърша картинката, обмислям да седна да подкарам VAX-а, който виси в initLab.

Тая вечер ходих на концерт на “band H.”, хора, които свирят Tool. Прилично се справиха, въпреки че им куцаше ритъма на моменти (което не е учудващо, Tool са учудващо гадни за свирене).
(по някаква причина в същия ден имаше 3 концерта – band H., Smallman и Irfan, не беше лесен избора)
(random човек ме разпозна на концерта и каза колко се радва на разните проекти като initLab, дето правим)

Седнах да подкарвам най-накрая сертификати от letsencrypt за нещата по marla, и успях да наслагам на половината, преди да ме удари resource limit-а при тях. Следващата седмица ще ги довърша. Разписах нещата с acme-tiny, базирано на нещо, което Петко беше драснал за лаба, оказва се сравнително просто (ако config-а е подреден както трябва) да се parse-ва apache config-а и да се смята какви точно сертификати да се генерират за кого.
(открих кофа неща, които вече не се host-ват при мен и ги почистих)

Събрал съм резултатите от теста на FOSDEM-ската техника (сравнение на запис на stream-а и encode-нат резултат, от нашия и от FOSDEM-ския setup), и като цяло с още малко пипване това може да се окаже достатъчно лесно за по-малки конференции (на които не си влачим 6-7-8 човека от екипа).

На opendata.government.bg тия дни пак качиха нещо интересно (тоя път – целия търговски регистър от 2008ма досега) и пак претовариха нещастната виртуалка (която е един debian в/у microsoft hyper-v). Обмислям някаква магия да може да преживява такива неща по-лесно, щото не се очаква да намалеят интересните данни.

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

И не си спомням нещо друго да ми се е случвало.

Втория BGP workshop

Monday, April 4th, 2016

Направихме и втория BGP workshop, на който още хора откриха колко лесно се подкарва IPv6 :) При достатъчно желаещи ще направим и трети след около месец. Също така може да помислим по въпроса хората да имат отделно устройство за подкарване и да са си сами потребители, понеже една от най-гадните задачки се оказва да убедиш всичките ти приложения на операционната система да се bind-ват на определен ip адрес, когато излизат навън.
(а аз тотално се изложих, понеже мислех да се включа вместо един от участниците, който не дойде, ползвайки pine64, което ми пристигна наскоро, и някъде на средата открих, че kernel-а му няма 802.1q и че трябва да компилирам отнякъде нов… което ще свърша, като си подкарам някаква среда скоро).

От интересните неща, които (пре)открихме беше, че ICMP echo reply от 8.8.8.8 винаги е орязан до 64 байта payload, колкото и голям пакет да се прати. Това води до въпроса “абе, защо нещо някъде ми реже пакетите?”…

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

(а вечерта бяхме на Jimmy Carr, от който лицето още ме боли от смях)

2016-03-31 въпроси за админско интервю

Wednesday, March 30th, 2016

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

Как бихте реализирали система за backup, на която сървъра не може да прочете данните на клиента (т.е. са криптирани подходящо) и compromise на клиента не води до възможност за декриптиране на backup-ите му?

Ако имате 12 диска, кое е по-reliable – 2 raid масива в raid5 от 6 диска или 1 масив от 12те диска в raid6? Кое е по-производително?
(изобщо, какво е raid6?)

Имате дърво с директории и (много) файлове в тях, как ще намерите кои файлове се повтарят?
(задължително трябва да се знае какво е -print0)

Какви са трите типа ssh тунели? Какво е socat?
(ssh трябва да го знаят всички, socat-а почти на всички някога е трябвал)

Пак към ssh-а, защо не трябва да се логваме на чужда машина с agent forwarding и как точно се exploit-ва?
(това е забавна задача за практическо упражнение)

Защо не трябва да се сверява часовникът на машина с ntpdate, който се пуска от cron-а веднъж на ден/час?

При смяна на DNS запис с TTL от 3600 секунди, колко време отнема да се научи от 90% от internet? 95% ? 99% ? 100% ?
(същия въпрос за 60-секунден TTL. Bonus points, ако споменат на БТК/vivacom малоумните resolver-и)

Защо на натоварен linux сървър не трябва да има swap?
(не мисля, че е само за linux, но трябват малко тестове още за останалите)

Какво е rollback plan и кога трябва да имаме такъв?
(bonus points за “винаги”)

Защо не трябва да се смесват различни модели/производители на дискове в един и същи raid масив?

Каква е разликата м/у strace и ltrace?

Какъв е основният протокол за контрол/комуникация с мрежови устройства?

Защо не трябва да се филтрира цялото ICMP?

Как можем да сменим root паролата на linux-ка машина, като имаме достъп до конзолата?
Как можем да направим това трудно/невъзможно?

Защо не се ходи с къси гащи в datacenter?

Предимства и недостатъци на hardware и software raid?

Инструменти за анализ на натоварването на машина, кои в кои случаи се ползват?

2016-01-25 интервюта

Monday, January 25th, 2016

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

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

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

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

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

2016-01-05 разни около opendata.government.bg

Tuesday, January 5th, 2016

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

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

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

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

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

Monitoring-а на OpenFest 2015

Tuesday, November 24th, 2015

Автор: Владимир Витков / 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 базата данни за всички заинтересувани.

2015-11-16 Мрежата на OpenFest

Monday, November 16th, 2015

Мрежата на тазгодишния 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-а).

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

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

2015-10-13

Tuesday, October 13th, 2015

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

Мразя perl.

2015-09-06 buffer management

Sunday, September 6th, 2015

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

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

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

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

2015-07-29 ffmpeg като софтуерен видео миксер

Wednesday, July 29th, 2015

Моето отношение към 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 по въпроса…

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

2015-07-20

Monday, July 20th, 2015

Миналата седмица беше основно 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.

2015-07-01 leap second 2015

Wednesday, July 1st, 2015

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

и т.н.

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

2015-06-28

Sunday, June 28th, 2015

СПИМИСЕ.

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

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

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

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

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

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

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

2015-06-23 тунелираме бавно

Monday, June 22nd, 2015

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

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

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

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

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

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

2015-06-17 разни мрежови

Wednesday, June 17th, 2015

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

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

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

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

2015-06-14 жив съм

Sunday, June 14th, 2015

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

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

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

2015-05-27 upgrade до jessie на останалите ми сървъри

Wednesday, May 27th, 2015

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

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

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

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

2015-04-24 първи upgrade на сървър до jessie

Friday, April 24th, 2015

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

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

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

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

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

2015-04-15 end-to-end криптография за домашна/фирмена употреба

Wednesday, April 15th, 2015

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

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

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

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

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

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

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

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

2015-04-01 presentation build system

Wednesday, April 1st, 2015

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

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

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

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