Нова версия на приложението за чистене на линкове

Може да е малко нарцистично, но приложението ми за махане на глупости от URL-и ми влиза в употреба постоянно и му се радвам много. Когато не ми се налага да разкарвам tracking параметрите ръчно, споделянето става по-лесно, което пък увеличава честотата на спама, който пръскам насам-натам. Win-win.

Малко след като пуснах първата версия, в приложението на Instagram (поне при мен) за известно време изчезна опцията за share и остана само “Copy Link”. Оттогава искам да направя нещо по въпроса, но поради една или друга причина това все оставаше на заден план.

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

От Android 6.0 в менюто за избран текст може да се добавят елементи, които да работят с него по някакъв начин. Това става, когато някое Activity дефинира intent filter за PROCESS_TEXT.

Long story short, направих го да ми е по-удобно и вече мога да правя така:

И така:

В зависимост от това дали избраният текст е read-only (EXTRA_PROCESS_TEXT_READONLY) разбирам какво да се покаже при Unwrap менюто (видеото отгоре).

Освен промените по интерфейса оправих и глупав бъг в backend-а на приложението, заради който share-ването на текст от Twitter водеше до MalformedURLException.

Засега ми върши идеална работа, но по-нататък ще го пипна малко. В момента след “unwrap” остава само първият URL. Другият текст изчезва. Освен това се работи и само с първия адрес от избрания текст. За момента не виждам смисъл да си усложнявам живота с обикаляне на неограничен брой адреси, които могат да имат (почти) неограничен брой redirect-и зад себе си.

Друг потенциален проблем е, че няма дискриминация на избрания текст и двете ми менюта (Clean и Unwrap) се показват във всички случаи. Менюто, което само разкарва ненужните параметри и замества текста, е безсмислено в уеб страници, но засега не виждам умен начин да го махна. Потенциално решение е да оставя само едно меню и да добавя опция в настройките, според която да се избира дали само ще се почиства или ще се “разгъва” избраният текст. Засега не ми се усложнява толкова.

И като край – приложенията ми в момента имат между 300 и 500 активни инсталации. Без нито един crash или ANR, откакто са пуснати 🙂

Lab

Както писах преди, от доста време искам да имам физически сървър вкъщи, който да си администрирам и гавря, както реша. В началото на годината по щастливо стечение на обстоятелствата това се случи и в момента се радвам на един HP ProLiant ML350 G5.

Това се оказа несвършващ проект и от януари не съм спирал да си играя и да уча нови неща. От по-важните услуги, които се търкалят засега, са: OpenVPN, HAProxy, Let’s Encrypt, Pi-hole, FreeNAS, Jenkins, Graylog, Transmission и NextCloud.

Сървър

Първо спецификациите на сървъра в текущото му състояние:

CPU Един Intel Xeon E5440 @ 2.83GHz
RAM 32GB FBDIMM ECC (8 по 4GB)
RAID 5 3*250GB
RAID 0 1*2TB

За момента RAID конфигурацията е такава, защото: а) не съм купил дискове за повече и б) нямам caddy-та за останалите два слота. Предстои ми доста интересно приключение, когато реша да разширявам storage-а. Нямам търпение rebuild-а на някой масив да гръмне. Най-вероятно ще трябва да купя още един RAID контролер и да присадя drive cage на мястото на CD-то, за да има къде да сложа всичките дискове, които искам. Шест 4-терабайтови диска в RAID 6 биха били достатъчни за известно време.

На RAID 5 масива се намира ESXi 5.5 (HPE image) заедно с datastore-а за някои виртуални машини. На самотния 2TB диск е storage-а на NAS-а, където има разни важни файлове.

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

Малко след като нарисувах горната графика, lime2 се пенсионира и вече не е backup OpenVPN. Намира се в процес на прехвърляне на всички неща от стария OwnCloud и backup partition към NAS-а. Тази малка машинка беше цялата ми инфраструктура допреди няколко месеца.

Чувството всички (важни) машини да са свързани през гигабитова връзка е прекрасно! Мога да редактирам видео файлове в Premiere Pro, които се намират върху FreeNAS-а, който работи върху една от виртуалните машини, без да усетя някакво забавяне. Няколко клиента спокойно стриймват видео файлове през SMB, nfs и каквото още дойде, без да има никакви проблеми*.

Най-накрая подкарах и Grafana, която да ми харесва и върши работа, а не да е просто eye candy. Повечето данни идват от Telegraf, който ги събира по SNMP и ги пази в InfluxDB.

По-интересните неща, като цената на тока и данните от ESXi, идват от един Python скрипт, който използва SDK-то за ESXi (pyVmomi). Оказа се значително по-лесно така, отколкото с Java SDK-то, което работи директно със SOAP-а на ESXi. Така и не можах да го подкарам.

Цялата работа на скрипта е да се върже за VMware-а, да вземе данните, да scrape-не текущата цена на тока от сайта на Енерго-ПРО и да запише всичко в InfluxDB.

Тъй като го писах с идеята да го оправя “някой ден”, сега при всяко изпълнение се обръща до сайта на Енерго-ПРО. Това води до интереснa статистикa за последните 24 часа в Pi-hole:

 

Поиграх си доста и с ILO-то. Толкова е старо, че мога да го отворя само през Internet Explorer, защото само този браузър все още поддържа несигурни и стари SSL сертификати.

Когато инсталирах втората партида от 16GB RAM, се сблъсках с друго интересно нещо. Заради изгоряла плочка прекарах няколко часа в дебъгване на проблема. В NVRAM-а на дъното се беше записало, че в дадения слот има изгоряла плочка и докато не го изтрих няколко пъти, не се събуди дори само със здравите плочки.

Мрежа

За основен рутер използвам pfSense, който работи върху един HP thin client. Тънкият клиент се оказа напълно адекватен избор за това.

Външната връзка и WAN интерфейсът на рутера са сами на един VLAN, а на друг VLAN са всички останали устройства.

За първи път настройвах суич през конзолен кабел с истинска цел, а не за упражнение. Прекарах няколко вечери до 3-4 сутринта, докато се стабилизира мрежата. Добре че имаше кой да ми даде акъл.

Някога ще разделя клиентите на VLAN-и според предназначението им. Освен това ще е хубаво и да взема втори управляем суич с пасивно охлаждане. В момента в стаята ми е Zyxel-а, а вторият суич е истински, rack-mountable, 1U. Чувам го през две врати.

За безжичните устройства ползвам два обикновени consumer рутера, които работят в режим AP. Доскоро работеха с едно SSID, за да покрия нявсякъде. Имаха проблеми с някои клиенти с по-стари wi-fi модули и ги разделих на две SSID-та. Някога ще бъдат смемени с UniFi AP-та.

Първият ми тест на мрежата беше да копирам файл от основния компютър към NAS-а. Започваше със 100MB/s и почти веднага падаше на 1-2MB/s и надолу. След недоспиването от борбата с мрежите, вече бях напът да режа кабели, но пък netperf показваше, че мрежата успява да се запълни спокойно до гигабит.

Така пак научих, че върху RAID контролерите съществува кеш (в случая – с неработеща батерия), който при неправилна настройка на read/write съотношението прави писането бавно (изненада!). След като го оправих, нещата се нормализираха и вече bottleneck-а при писане върху NAS-а е само скоростта на дисковете. Тук също се радвам, че имаше кой да ми даде светлина. В момента съотношението е 5/95 за четене/запис.

Това с кеша е от нещата, които се налага да правиш изключително рядко и ако са направени правилно, забравяш, че съществуват. Също като настройването на Nagios. Както често твърдя – Nagios-а е най-стабилното нещо в живота ми.

Услуги

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

Имах много време да мисля какво искам да използвам за NAS софтуер и накрая се спрях на FreeNAS. Минах през всевъзможни варианти много преди да имам физически съврър и FreeNAS върху виртуална машина ми пасна най-добре. Разбира се, има и някои недостатъци на виртуализирането, но досега не съм се сблъсквал със сериозни проблеми.

Ако не друго, то поне охлаждането на процесора е адекватно. Все пак малко хора могат да се похвалят с процесори, които работят на температура под абсолютната нула.

Върху FreeNAS-а работят няколко jail-а. Основните са Transmission и NextCloud. Благодарение на Transmission имам една директория в share-а на NAS-а, която се следи за torrent файлове, които автоматично се добавят за теглене. Изтеглените неща се намират в друга директория, достъпна от всички устройства в мрежата. Така пиратстването свободното споделяне на медия с уредени авторски права е значително по-лесно.

 

NextCloud-а ми служи основно за синхронизиране на файловете от телефона и разни маловажни неща между компютрите. Първо ползвах OwnCloud, който се хостваше върху малкото OLinuXino (Lime2). Доскоро за off-site backup ползвах NextCloud върху единия droplet в DigitalOcean, където добавих 50GB Volume, върху който трябваше да са само най-важните неща. След известни проблеми с rsync реших, че Google Photos ми е достатъчен за off-site въпреки компресирането.

 

pfSense е доста полезен инструмент. Освен стандартните услуги, които трябва да предоставя един рутер (DHCP, DNS, etc.), в момента върху него работят доста неща, като по-интересните са: HAProxy, OpenVPN и plugin, който се грижи за Let’s Encrypt сертификатите.

OpenVPN-ът ми върши идеална работа. Няма много за писане откъм конфигурация, защото интерфейсът на pfSense е достатъчно прост и цялата работа се свежда до нацелване на разни стойности. Предишният VPN, който бях подкарал върху OLinuXino-то, беше по-интересен, защото цялата инсталация беше на ръка с всичките генерирания на сертификати за сървъра и клиента, както и настройването на рутирането и firewall-а. В pfSense всичко е графични интерфейси.

Сега мога да се закача за мрежата вкъщи, където и да съм, и с едно mount nas.miskin.in:/mnt/whatever /mnt/nas/ имам достъп до NAS-а.

Не бях работил с HAProxy преди това. Засега имам 20 frontend-а и 13 backend-а. Фронтендите са разделени под два основни за услугите с и без SSL. В общия случай са огледални – вместо да се реже достъпа без SSL, има frontend, който прави 301 redirect към същия адрес, но с “https://”.

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

Както казах, повечето услуги работят през https. Това става благодарение на Let’s Encrypt. Оказа се малко по-интересна заигравка с HAProxy, за да мога да отговарям правилно на challenge-ите, които идват от Let’s Encrypt при издаване и подновяване на сертификати.

 

Ако не си личи, мразя рекламите с яростта на 1337 слънца. Благодарение на това всички компютри, до които имам достъп, веднага биват снабдени с някакъв AdBlock софтуер. С телефоните това се оказва излишно сложно и неудобно – не искам да ползвам друг браузър, не искам да root-вам телефона и т.н. За спирането на поне част от рекламите върху устройствата в мрежата използвам  Pi-hole. Тъй като все още нямам Raspberry Pi, се наложи да инсталирам Pi-hole върху старото OLinuXino (a.k.a sexy). Не му пречеше особено, че прекара няколко години затворено в кутия и в момента всички DHCP клиенти в мрежата (дори някои от тези с резервирани адреси) го ползват като главен DNS. Получи се доста добре и не усещам никакво забавяне, където и да е. Не помня всички проблеми, които излязоха по време на “инсталацията”. Помня само, че ми се наложи да ровя из инсталационния скрипт, защото имаше допуснати разни предположения за системата, които може и да са верни за Raspberry Pi, но при OLinuXino седят по различен начин. Намерих и полезен скрипт, който събира статистика от Pi-hole в InfluxDB (pi-hole-influx) за ползване в Grafana.

 

Друга основна услуга, която ползвам редовно, е Jenkins. Инсталирането и конфигурирането са тривиални. Забавата тук е при конфигурирането на job-овете.

Разделил съм ги на основно два типа – backend и frontend. Backend job-овете се отнасят до Spring Boot проекти, а другите – Node JS базирани (най-често Vue). Всеки един job се задейства при push в конкретен бранч на конкретен проект. Това става с прост hook в GitLab. Тук идва едно от многото удобства на HAProxy – понеже не исках Jenkins да се вижда извън локалната мрежа, настроих Jenkins frontend-а да приема заявки отвън само от GitLab.

Общо взето за всички проекти правя build и deploy по сходен начин. Java проектите се компилират и пакетират с Gradle. Преди build-а Jenkins се закача за сървърa, на който ще се деплойва, и затрива старите jar-ове. След това се нагласят конфигурационните файлове, с които трябва да работи Docker Image-а (cp log4j2_docker.xml log4j2.xml например) и се започва с Gradle-а. При успешен build готовия jar се копира на целевия сървър и се trigger-ва job-а за redeploy (ако за конкретния проект ми трябва автоматичен redeploy).

Redeploy job-овете са изключително прости. През SSH се закачам към сървъра, където ще се деплойва, правя Docker Image от jar-а, спирам, изтривам и стартирам наново контейнера, в който работи приложението.

При неуспешен build си пращам имейл, за да знам, че нещо се е омазало.

За фронтенд проектите е аналогично. Разликата е основно в това, че вместо gradle build се извикват npm install и npm run build.

 

Споменах, че за Spring приложенията се налага използване на различна конфигурация. Причината за това е, че някои от страничните проекти заживяха интересен живот и се наложи да са достъпни публично. Така приложението се налага да може да работи на три среди – local, dev и prod. Очевидно е какво е local. Dev средата се използва при изпълнение на тестовете по време на Jenkins build-а, а prod е това, което се вижда, когато проектът се достъпи публично.

Засега използвам Graylog за събиране на логовете от всички приложения. Това, обаче, ми излиза скъпо, защото на една машина вървят ElasticSearch, MongoDB и Graylog. На практика излиза, че 10GB RAM са недостатъчни, когато идват над 20 съобщения в секунда и се усеща забавяне. Излиза ми скъпо, защото потреблението на ток на сървъра скача осезаемо, когато се върши някаква работа с Graylog и се хабят изчислителни ресурси нещо, което може да се реши по по-лесен начин.

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

 

Освен всичко описано дотук, по разните виртуални машини вървят всевъзможни други услуги: MySQL, PostgreSQL, RabbitMQ, Redis и още, и още. Все още успявам да се справя с поддръжката на всичко сам и ми е все по-интересно. По-горе писах, че използвам GitLab. Смятам скоро да си пусна една инстанция при мен, за да видя дали все още е толкова лаком за ресурси.

Проблеми

Основният ми проблем със сървъра е, че като сравнително стара enterprise машина, не е обърнато много внимание на ефективността на потреблението и във всеки един момент дърпа около 256W. Това е при включено само едно от двете 1000W захранвания. При две idle потреблението скача до около 280W. Грубата сметка идва около 40лв. на месец (без ДДС и всички такси: за пренос, загуба, “да има” и др.). Не е най-скъпото удоволствие на света, имайки предвид колко много неща мога да уча благодарение на него, но като знам, че мога да ги постигна с по-малко похабена енергия, ме човърка.

Друг проблем е шумът от вентилаторите. С качването на температурата през последните седмици, все по-често заварвам следната гледка:
Интересно е, че при по-ниска температура навън паметта достига 75-76 градуса без да вдигне осезаемо скоростта на вентилаторите. Въпреки това, суичът си остава по-шумен.

Преди няколко седмици трябваше да изключа всичко, защото имаше профилактика на захранването. Беше забавно, защото чак тогава си дадох сметка колко много неща съм закачил през последните месеци.

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

След включването на всичко, изненадващо, имах само един малък проблем – конфигурацията на суича не се беше запазила и SNMP-то му беше спряно, заради което в Grafana-та не излизаха статистиките за него. Всичко друго заработи без да се оплаква.

Оттук нататък приоритет ми е събирането на дискове за разширяване на storage-а, тъй като той ми умалява най-бързо. Може би и втори процесор, за да няма празни дупки.

Следващото най-важно нещо е да се сдобия с по-съвременна машина, която да не е толкова лакома за ток и да поддържа SSD по-лесно.

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


*Ако не броим нестабилността на sshfs и nfs mount-овете на лаптопа, които решават да потрошат всичко, когато го приспя и събудя. Някой ден ще дойде и неговия ред.

Използване на Java Reflection API за мързелива “документация” на response кодове

В единия от страничните проекти използваме REST за комуникация между фронтенда (Vue) и бекенда (Spring Boot). Приложението е сравнително просто и пиша бекенда сам и за документация на REST-а използвам Swagger. Това значително услеснява имплементацията на фронтенда откъм информация за endpoint-и и кой какво може да очаква като заявка/отговор.

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

Механизмът, на който се спрях за връщане на грешките към потребителския интерфейс, е сравнително прост и не е нищо ново – при грешка в бекенда към клиента се връща DTO с цифров код и пояснителен текст. Пояснителният текст служи само за улеснение на пишещия фронтенда. Локализацията на грешките, ако се наложи да има такава, ще се случва във Vue приложението според цифровия код.

В Spring това се имплементира изключително лесно. При неправилно действие (няма достъп, липсва задължително поле и т.н.) се хвърля Exception (в случая – ErrorResponseException), който се прихваща от @ExceptionHandler и към клиента се връща DTO-то с нужния код и текст. За имплементацията на този механизъм са нужни няколко основни неща:

  • Номенклатура на кодовете на грешки и клас, описващ формата на отговора, който очаква Vue приложението,
  • Някой да прихване Exception-а,
  • Exception за прихващане.

Номенклатурата е обикновено POJO със статични методи за всяка грешка:

import lombok.Data;

@Data
@AllArgsConstructor
public class ErrorResponseDTO {

    private Integer code;
    private String message;

    // 500
    public static ErrorResponseDTO generalError(Throwable t) {
        return new ErrorResponseDTO(500, "I can't even: " + t.getMessage());
    }

    // 1401 - JWT token expired
    public static ErrorResponseDTO tokenExpired() {
        return new ErrorResponseDTO(1401, "Token expired");
    }

    // 1402 - Invalid JWT token
    public static ErrorResponseDTO invalidToken() {
        return new ErrorResponseDTO(1402, "Invalid token");
    }

    // ...
 
    // 1409 - User is not active
    public static ErrorResponseDTO userIsNotActive() {
        return new ErrorResponseDTO(1409, "User is not active");
    }

    // ...
    // Още много статични методи, описващи останалите грешки
    // ...
}

Горното може да се реализира по много начини. Засега това ме устройва. Не смятам, че проектът ще стане достатъчно сложен, за да оправдае разделянето на тази номенклатура от DTO-то или категоризиране на грешките в отделни класове, пакети, Exception-и и т.н.

Прихващането на Exception-а става с @ControllerAdvice и @ExceptionHandler:

@ControllerAdvice
public class RestExceptionHandler {
    // ...
    @ExceptionHandler(ErrorResponseException.class)
    @ResponseStatus(HttpStatus.PRECONDITION_FAILED)
    @ResponseBody
    public ErrorResponseDTO processErrorResponseException(ErrorResponseException 
e) {
        return e.getErrorResponseDTO();
    }
    // ...
    // Други handler-и за други exception-и
    // ...
}

Exception-ът е обикновен наследник на RuntimeException, който съдържа в себе си DTO-то:

public class ErrorResponseException extends RuntimeException {

    private ErrorResponseDTO errorResponseDTO;

    public ErrorResponseException(ErrorResponseDTO errorResponseDTO) {
        this.errorResponseDTO = errorResponseDTO;
    }

    public ErrorResponseDTO getErrorResponseDTO() {
        return errorResponseDTO;
    }
}

С описаното дотук връщането на грешка става просто. Например, в Service-а за генериране на JWT токен има простата проверка дали конкретният потребител е активен. Ако не е, няма смисъл да му генерирам токен:

if (userData.getUserStatus() != UserStatus.ACTIVE) {
    throw new ErrorResponseException(ErrorResponseDTO.userIsNotActive());
}

Така при неактивен потребител към извикващия клиент се връща този JSON:

{
    "code": 1409,
    "message": "User is not active"
}

Логиката за потребителския интерфейс е изцяло в клиентското приложението. Дали ще се покаже директно върнатият текст или според кода на грешката ще се случи нещо, няма значение. Целта е пълно отделяне на логиката по обработване на грешката (ако така се превежда decoupling). Няма значение дали клиентът е Vue, Android или Swing приложение – отговорността е негова.

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

Можеше вместо рефлексия да използвам анотациите, предоставени от Swagger за този случай (@ApiResponses и @ApiResponse) върху всеки метод на всеки контролер в приложението.

Понеже рефлексията ми е интересна, се спрях на вариант с endpoint, който връща JSON с всички възможни грешки, които могат да се върнат към REST клиента. Тъй като всички грешки са дефинирани като статични методи на класа, който ги описва, алгоритъмът е тривиален:

  1. Вземам всички статични методи, декларирани в този клас,
  2. Викам ги един по един,
  3. Записвам резултатите в списък,
  4. Връщам списъка.
@RestController
@Slf4j
public class ErrorListController {

    @GetMapping(path = "/errors-list")
    public List<ErrorResponseDTO> getErrorsList() {
        List<ErrorResponseDTO> result = new ArrayList<>();
        
        // Взимаме всички методи
        Method[] methods = ErrorResponseDTO.class.getMethods();
        for (Method method : methods) {
            try {
                // Искаме само статичните методи
                if (Modifier.isStatic(method.getModifiers())) {
                    Method declaredMethod = ErrorResponseDTO.class.getDeclaredMethod(method.getName());

                    // Викаме метода
                    ErrorResponseDTO invoke = (ErrorResponseDTO) declaredMethod.invoke(null);

                    // Добавяме резултата към отговора
                    result.add(invoke);
                }
            } catch (NoSuchMethodException | InvocationTargetException | IllegalAccessException e) {
                log.debug("Ignoring exception \"{}\": {}", e.getMessage(), e);
            }
        }

        return result;
    }
}

Адресът на този контролер (/errors-list) е разрешен в WebSecurityConfigurerAdapter-а само при определени условия и не се вижда в “продукционната” среда. Отговорът изглежда долу-горе така:

[
  {
    "code": 1401,
    "message": "Token expired"
  },
  {
    "code": 1402,
    "message": "Invalid token"
  },
  {
    "code": ...,
    "message": "..."
  },
  {
    "code": 1409,
    "message": "User is not active"
  }
]

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

NAS

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

Преди десетина години вкъщи се появиха няколко едва работещи компютъра. От тях си харесах единия за “сървър” и му закачих всичките работещи дискове, които намерих. Беше с някакъв Debian, където бях инсталирал стандартните неща, с които си играех тогава – Apache, lighthttpd, MySQL, WordPress и разни други такива. Тогава още нямах рутер и се налагаше нормалният компютър да споделя връзката към другите в къщата. Заради това ми се наложи да науча много неща за мрежи, ReverseProxy-та, красоти около iptables и как да си говорят няколко машини без да се карат. Веднъж отнякъде се появи и работещ RAID контролер – някакъв Adaptec. Не помня дали поддържаше SATA, но дисковете със сигурност бяха вързани с PATA (IDE) кабели. Нямах идея как се работи с това, но пък бях чувал, че е добре да има RAID, затова директно вързах всички дискове към него и създадох масив. Кой да предположи, че това ще затрие всичко по дисковете…

Оттогава започнах да чета и да чакам момента, в който ще си купя някоe 4U съкровище с поне два Xeon-а и няколкостотин гигабайта RAM, ще му сложа ESXi и ще забравя как изглежда светът през деня. През последните години не съм спирал да уча и да се интересувам от админски неща. В един момент бях стигнал до извода, че 40U rack може и да ми стигне, ако махна това-онова. Гледането на /r/homelab, /r/sysadmin и /r/datahoarder изобщо не помага.

Проблемите ми с enterprise сървърите са основно цената и шума. Донякъде и потреблението на ток за определени модели.

Съвременните неща ми идват неоправдано скъпи за играчка.  Миналата година начатках това от сайта на Supermicro:

Едно такова за Коледа, моля

Близо $50 000 чисто щастие – 44 ядра с hyperthreading (т.е. 88 “логически” ядра), 512 GB RAM, 10Gb мрежа и много storage.

Винаги се намират стари сървъри из ebay или olx, но често идват без поддръжка и незнайно колко оставащ живот в тях. Сред най-известните стари и евтини сървъри, които намирам, е PowerEdge R710 на Dell. Звучи така при излитане. При пълен товар не е особено тих.

Друг вариант са работните станции на Dell и Lenovo.

Преди да сглобя текущия си десктоп за малко бях с един T7400 на Dell. Взех го, защото ми хареса колко модулно е всичко вътре, как има два сокета, тунел за охлаждането на процесорите, ECC и други красоти. Преглътнах, че е с DDR2, но това, че рамта работи на 60 градуса без товар, ми дойде в повече и го върнах.

Последното ми решение да имам много storage и виртуализация вкъщи е да оставя текущия ми desktop с някакъв hypervisor или с FreeNAS и да сглобя нов. Към момента се радвам на i7-4790K с 32GB памет и няколко TB дискове. С пуснати няколко виртуални машини, търкалящи всевъзможни неща, не се впечатлява особено. Затова смятам, че ще му е добре да се преквалифицира като хост на FreeNAS или Proxmox. 

За целта започнах да събирам чаркове за новата машина, която ще страда като desktop. Планът беше да е с i7-8086K, но започнах да се колебая дали да не е нещо с Ryzen. И без това има много време, докато стигна до купуване на части за нов компютър, защото идеята ми е да напълня 6-те SATA порта на дъното на стария и да използвам вградения RAID controller за RAID 5. Тъй като не бързам, купувам частите през месец-два. Вероятно е скоро да не сглобя нищо, но поне се движа натам.

След като реша дали ще е с Proxmox или FreeNAS, мисля да пусна всякакви шаренийки. Първо ще преместя transmission-а, който работи върху едно OLinuXino със закачен диск на него, защото е напът да си отиде. След това идва реда на Plex, Nextcloud, Sickrage или Couchpotato и всякакви такива. Ще му пусна и нещо подобно на pi-hole, за да имам ad block на ниво DNS на всички устройства, които се вържат за мрежата тук. Разбира се, всичко това ще трябва да е достъпно по сигурен начин, ще трябва да си играя с потребители, сертификати и една камара други глупости. 

Нямам търпение да видя какви проблеми ще ми създаде това начинание 🙂

Share link decrapifier

Приложението добавя елемент в менюто за споделяне на Android, който копира споделяния текст, премахвайки частите от него, които се използват за допълнително следене. Неща като “utm_source”, “fbclid” и др. изчезват.

Така, например, адресът “https://www.instagram.com/p/BppzKrmneqd/?utm_source=ig_share_sheet&igshid=jywYcSpOs8008“, който генерира Instagram от share бутона си, ще стане “https://www.instagram.com/p/BppzKrmneqd/“.

Може да се свали от Google Play от тук:
Get it on Google Play

Предистория

Не обичам постоянното произволно следене отвсякъде с цел таргетирана реклама. Досадно е. Тъй като не искам да използвам интернет, както го прави Сталман, използвам AdBlock, където мога. Освен това използвам и ралични други похвати, докато използвам интернет, за да се чувствам спокойно и да се залъжа, че профилът ми при всеки рекламиращ отпадък не е плашещо подробен. Смятам скоро* да подкарам pi-hole на OLinuXino-то в нас.

Понякога се сещам да напиша някаква простотия, която се гаври с analytics софтуера на някой сайт. Пример за това е глупавият ми chrome extension, който взема “utm_source” в даден адрес и го променя на нещо по-подходящо за тези хора. Далеч от перфектен, но беше забавна играчка.

Преди време започнах да си играя с Instagram. Дълго време не ъпдейтвах, защото няма случай, в който такова приложение е станало по-добро след ъпдейт. След като се подлъгах да ъпдейтна, се оказа, че са променили начина, по който копират линка към дадена снимка. Преди процесът по копирането беше прост – кликваш на менюто с трите точки -> Copy Share Link… и готово. Сега има “Share”, което изкарва подробно Share меню, в което са изброени всички приложения, заедно с конкретни хора от някои. Това означава, че трябва да чакам да хвърчат една камара Intent-и, докато копирам линк.

Когато най-накрая успея да стигна до “Copy to clipboard” менюто или използвам някое от готовите, линкът, който се копира съдържа информация от вида “/?utm_source=ig_share_sheet&igshid=sittagd5tf01”. Тоест всеки, когото наспамя със снимка на мотор или задник, ще получи линк, чрез който лесно се проследява откъде идва. От там е елементарно да се направят много изводи. Щом този човек е отворил снимка, която е изпратена от човек, който харесва мотори и задници, значи и този конкретен нов човек харесва същото! Нека му рекламираме чорапи за каски и селфита на произволна кака с нарцистично разстройство!

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


* Виж Valve time

Локална разработка с отдалечен сървър като хост на контейнери, сървъри, service-и и т.н.

Пак открих топлата вода.

Налага ми се да работя с Macbook. За преживяването ще кажа, че дори след като му сложих Debian, не мога да разбера защо някой може да го ползва доброволно. За 12-те години, в които ползвам Linux, не бях виждал да се ползва swap-а при сериозно натоварване. Тук стигнах 7 GB swap при нормална употреба. Необяснимо за мен е как толкова хвалено нещо работи толкова зле. Говоря чисто като хардуер. Откъм неудобността на интерфейса няма смисъл да коментирам. Толкова с хейта. Най-вероятно има случаи, в които си струва да дадеш близо 6K за лаптоп.

Малко преди екраните да започнат да мигат и да се изключи.

В процеса на работа се налага да пусна няколко docker-ски контейнера с различни услуги. Тъй като не мога да променям конфигурациите без да счупя работата на други хора, услугите на docker-а трябва да работят локално. Това води до повишаване на температурата на процесора от 75 градуса при idle до около 100. 

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

Решението на проблема ми се оказа доста по-просто – SSH с GatewayPorts=yes и изброени портовете, които да се пренасочат. Цялата работа се свежда до това:

ssh \
	-L 3306:localhost:3306 \ # SQL
	-L 5672:localhost:5672 \ # Rabbit
	-L 6379:localhost:6379 \ # Redis
	-L xxxx:localhost:yyyy \ # Друго
	-N -o GatewayPorts=yes mgc@whatever

Така когато се обърна към localhost:3306, например, заявката се обработва от MySQL сървъра, който работи на отсрещната машина (whatever в примера по-горе).

Засега не съм срещал проблеми при този начин на работа. Използвам го както с GCP, така и с DigitalOcean без забележимо забавяне. 

Умна шамандура, част 1

a.k.a. “инж.”, part deux

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

Първият draft на това е от втори януари 🙂

Ghetto-ass шамандура
“Шамандурата”, сглобена върху прототипна платка, две планки и няколко шпилки за закрепване на анемометъра, ветропоказателя, LoRa-та и GPS-а.

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

Първоначалната идея беше следната – едно Arduino следи всички датчици и предава стойностите им безжично по LoRa радио. От другата страна да стои друг LoRa възел, който е свързан към PSoC 4 и приема данните. PSoC-ът ги предава по сериен порт към компютър, на който работи .NET-ско приложение, което ги обработва и ги тика в MS SQL баз от данни някъде. Визуализацията е с много форми, графики и т.н.

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

Тъй катo трябваше да напиша документацията и да направя всичко сравнително бързо, реших да не се затормозявам с излишно сложни неща и разделих работата на три части: “отдалечена станция” (a.k.a шамандура), наземна станция и уеб приложение.

Представено графично изглежда долу-горе така:

Шамандурата използва китайска имитация на Arduino Nano. Микроконтролерът е същият, но и ма малки разлики в пиновете. Когато паметта в един момент се запълни на 99%, контролерът спря да работи и да се разпознава от компютъра. Оказа се, че докато е в “bootloader” режим (или както се нарича, режимът, в който влиза, малко след като му се бутне Reset копчето), може да се програмира. Освен това се оказа, че Serial1.available() връща true, когато на серийния порт няма нищо. Дори когато RX пинът е с pull-down резистор. Благодарение на това се наложи да правя геройства като изчакване на някакви секунди време, когато си говоря с LoRa модула.

Така и не успях да подкарам GPS модула успешно, дори след като го изкарах на терасата и чаках 30 минути да търси сателити с неговия си софтуер. Хардкодването на NMEA данните, които очаквах, ми спести няколко байта и нещото заработи пак.

Тук е моментът да си призная как ме домързя да изградя LoRa мрежа само за едната дипломна работа. Добре, че модулите (RN2483) могат да работят като прости радиа. Цялата безжична комуникация се гради на две команди.
В изпращащата част:
mac pause\r\n
radio tx CAFEBABE\r\n

Където “CAFEBABE” е гениално построеният ми пакет от данни, разделени с точка и запетая, но представен като шестнадесетичните стойности на ASCII кодовете на всеки символ от низа.

Приемащата част прави това постоянно:
mac pause\r\n
radio rx 0\r\n
Втората команда отваря неограничен прозорец за приемане на данни и блокира модула, докато не дойде нещо.

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

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

Като се замисля, че миналата година си играх да чертая схема на Proteus за това, ми става смешно.

В един момент мислех да сложа и LDR, за да следя видимостта и коя част от денонощието е в момента. (наблюдателните ще забележат, че някои букви имат фон, защото ме домързя да експортирам наново и трих фона, който слага Proteus, с GIMP)

Приемащата част на това беше изключително лесна – PSoC 4, който само праща команда за чакане към LoRa-та, приема, каквото дойде и го предава към компютъра. В PSoC Creator това изглежда като два UART блока и малко код за комуникация.

На компютъра работи .NET (C#, разбира се) приложение, което слуша на някой COM порт, обработва данните и ги хвърля към уеб приложението. Изглежда така:

Token-ът е md5 на “suck my dick”.

Първата версия се казваше “Shamandura Control Center” и използваше DevExpress. Имаше няколко екрана за управление на всичките данни, но не ми хареса колко много работа трябва да се свърши, за да изглежда добре и зарязах.

Най-забавната ми част от това е, че BackgroundWorker-а, който се грижи за серийната комуникация, има методи “worker_Suffer” и “worker_Whine”, съответно за DoWork и ProgressChanged. Голямата хитрост тук е, че използвам ProgressChanged метода, за да си пращам съобщения, които да вършат нещо в UI нишката. Това е, за да избегна всички красоти около делегатите и другите C# неща за достъпване на контрол от не-UI нишка.

Така нареченото уеб приложение е Symfony проект с няколко контролера, генерирани с app/console generate:doctrine:crud и един, който се грижи да приеме и обработи заявката от десктоп приложението. Бидейки почти арт директор, намерих готова bootstrap-ска тема и я орязах, докато заприлича на нещо.

След логин излиза това.

Скоро не си бях играл с Google Maps, затова след логин в системата се показва карта с всички шамандури и по тях може да се цъка. В страницата с “детайли” на шамандура има няколко графики и карта с история на местоположението.

Тук скрих sidebar-а.

Това е.

Смятам, че си заслужих шестиците. Заедно с мен шестиците си заслужиха и проекти, които работят само на хартия и такива, на които дизайнът включваше форми, подредени с <br/> и много &nbsp;, както и черен цвят на тъмнозелен фон. Всички сме инженери 🙂

От въпросите, които ми зададоха, ми беше интересен следния: “Добре, де, виждам, че сте използвали всякакви езици: C, C#, PHP, има сайт… Защо не го написахте цялото на C#?”. Това зададено с леко тъп, снизходителен тон.

Bullshit mode: ON.

Както писах, горе – мързел. Използвайки суперсилата ми за празни приказки, “мързел” се превърна в обяснение как няма смисъл да товаря компютрите на хората със зависимостите, които води със себе си сложния .NOT проект. Всички имат браузър => сайт.

Приключвам с училището след близо 18 години. Ако се пречупя, може да изкарам и PhD, но това е прекалено ниско в приоритетите ми засега.

return; return; и обратно към интересните неща.

Основни алгоритми и структури от данни

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

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

Сещам се как, когато се опитваха да ни преподават част от тези неща в университета, имаше хора, които твърдяха, че “това никой не го ползва”.
Може би, ако на “Добре де, това къде ще ми потрябва?” не отговаряха с “На изпита, колега”, някак повече щяха да се знаят тези неща и нямаше да ни се налага постоянно да гледаме неща достойни за награди от govnokod.ru (не че не съм произвеждал (и продължавам) ляйняни програми. Разликата е желанието за намаляване на лайняността).

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

barcodes

В сесия съм и се оказа, че трябва да уча за изпит, който си мислех, че съм освободил.
Та понеже имам да чета доста, реших да си напиша библиотека за генериране на баркодове. В момента не прави нищо особено – може да генерира само Code 128. Като се има предвид колко време отделих за това, не мисля, че е толкова зле.
Качих нещото в GitHub – цък.
Даже телефонът го разпознава.
Мисля като ми минат изпитите да си поиграя още и като свърша с 1D баркодовете, да мина на матрици и после QR.
След това мисля да го пренапиша на Java и да обуча някоя програма да ги разпознава.
Само да минат изпитите.

2013-04-24

В блок 18 на общежитията на ТУ-то има (имитация на) интернет, за който са нужни име и парола да се ползва. Дотук добре, обаче… Маймуните, които са го настройвали, са решили да ограничат достъпа на хората до някои неща (торенти например) и са сложили някакви правила на MikroTik-а, който пуска интернета. Пак добре, обаче тези правила не работят за хора с windows, т.е. те могат да си теглят и виждат всичко. И като реша аз да се закача, интернета веднага пада (i.e. “разлогва” се), защото умните настройки решават, че Linux-ът ми е нещо, което тегли торенти (или прави каквото там е забранено). Нямам торенти и не правя нищо, което би трябвало да е забранено в нормалния свят.
Long story short, написах си това и вече почти мога да ползвам интернет.
Почти, защото някои сайтове изобщо не се зареждат, а на други мога да видя само html-а. Ако имам късмет и са ми останали кеширани стиловете и скриптовете, почти мога да ползвам дадените сайтове.

Хубаво е, че не живея тук. Нямаше да имат секунда спокойствие, докато не го оправят.