bisko.be - Разработка

Стартиране на Ollama със стари видеокарти на CachyOS

Sat, 28 Feb 2026 00:00:00 GMT

TL;DR;

ollama-cuda на CachyOS идва (към момента) с поддръжка само за compute >= 7.5.

Ако имате по-стари видеокарти с по-ранен compute, ТРЯБВА да направите едно от 2 неща:

Да компилирате ollama-cuda от сорс кода, с поддръжка за по-старите compute цели
Да инсталирате ollama-vulkan

Аз избрах ollama-vulkan и работи чудесно!

Време за история

Днес ме споходи вдъхновението най-накрая да изключа Windows 11 виртуалната си машина и да я мигрирам към Linux.

Изискванията бяха да мога да пускам:

Ollama - за магия с локални модели
Docker - за отдалечена разработка
Steam - за игра на игри
Jellyfin - за архива с домашни видеа

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

В машината има 2 видеокарти:

GTX 1070 - 8GB
GTX 970 - 4GB

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

Така че естествено инсталирах ollama и ollama-cuda, тъй като имам 2 Nvidia видеокарти, очаквайки, че ще работи без проблем, защото само преди няколко минути работеше на Windows.

Стартирах Ollama, заредих qwen3:8b за бърз експеримент и… работеше на процесора 🤔

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

След като се опитах да разбера от логовете, помолих Claude да ми помогне малко и той стигна до доста обезкуражаващото откритие:

The logs tell the story clearly. Both your GPUs are detected but then filtered out because they fail CUDA initialization:

  "filtering device which didn't fully initialize" id=GPU-eb132a13-b9f4-40e3-d85d-60f211dfd21e ... library=CUDA
  "filtering device which didn't fully initialize" id=GPU-550263c8-37e2-2a25-c0b6-10cc7511ed20 ... library=CUDA

  The reason is the CUDA library bundled with Ollama 0.17.4 was compiled for these architectures only:

  CUDA.0.ARCHS=750,800,860,870,880,890,900,1000,1030,1100,1200,1210

  The minimum supported compute capability is 7.5 (Turing / RTX 20xx series). Your GPUs are older than that:

  ┌──────────┬────────────────────┬──────────────┐
  │   GPU    │ Compute Capability │ Architecture │
  ├──────────┼────────────────────┼──────────────┤
  │ GTX 1070 │ 6.1                │ Pascal       │
  ├──────────┼────────────────────┼──────────────┤
  │ GTX 970  │ 5.2                │ Maxwell      │
  └──────────┴────────────────────┴──────────────┘

  Neither is in the supported list, so CUDA initialization fails for both, and Ollama falls back to CPU-only inference.

  Your options:

  1. Downgrade Ollama to an older version that still included Pascal/Maxwell support (pre-0.6.x era had broader arch coverage, but check release notes for specifics).
  2. Build Ollama from source with CUDA_ARCHITECTURES="52;61;75;80;86" to include your GPU architectures.
  3. Upgrade GPUs to at least an RTX 2060 or newer (compute 7.5+).

Това малко ме разочарова, защото искам да използвам видеокартите максимално, преди да мина на нова.

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

Тези карти дори бяха показани като поддържани на сайта на Ollama!

За да скъся дългата история с ровене в Google:

Оказва се, че ollama-cuda идва точно с изискванията, изброени по-горе… а съветът беше да се инсталира ollama-vulkan.

След като го направих, всичко заработи много гладко!

[Linux] Възстановяване на прекъсната сесия на `apt dist-upgrade`

Wed, 23 Oct 2024 00:00:00 GMT

Днес обновявах инсталацията си на Proxmox отдалечено през вградената конзола, но забравих какво правя и затворих таба по средата.

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

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

След кратко ровене попаднах на тема в Serverfault, в която се споменаваше използването на reptyr, за да поемеш терминална сесия през SSH.

Описвам тук какво точно направих, за да си върна сесията и да завърша обновяването:

От този коментар:

git clone https://github.com/nelhage/reptyr
cd reptyr
make install

Това инсталира reptyr на машината.

После потърсих всички отворени сесии с ps ax | grep pts, за да намеря процеса, който ми трябваше.

След това намерих най-горния родителски процес в дървото на извикванията, на който е зададен pts, и се закачих за него чрез неговия PID:

reptyr -T 1390511

И така успях да завърша обновяването! 🎉

[Linux] Syncthing – файлова система само за четене при стартиране като услуга

Wed, 06 Apr 2022 00:00:00 GMT

От няколко месеца използвам Syncthing, за да синхронизирам работното си копие с локален dev сървър.

В началото го стартирах ръчно през CLI след логване. Работеше добре, така че не се замислих, когато реших да го пусна като услуга. Стартира, синхронизира малко данни, всичко беше наред.

Докато не спря да бъде, разбира се! 🙂

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

Мислех, че е бъг и просто показва Out of Sync за папките, но всъщност си синхронизираше. Е, грешах.

След няколко часа дебъгване и без никакви следи във форумите след няколко търсения в Google, попаднах на статия за Syncthing в ArchWiki, която описваше точно моя случай:

read-only file system error on /etc although run as root

Това беше точно моят случай, с тази разлика, че проблемната папка не беше /etc, а /usr/local/src.

Е, след като прочетох какво пише, излезе, че ако стартираш Syncthing (или каквото и да е) през systemd и имаш зададено ProtectSystem на full за услугата, някои директории стават само за четене по подразбиране. /usr е една от тези директории.

За да го поправиш, трябва да добавиш нов ред в конфигурацията на услугата и да я рестартираш (и да изпълниш daemon-reload):

ReadWritePaths=/usr/local/src

След това Syncthing би трябвало да работи нормално.

[Linux] Изпълнение на множество команди на множество сървъри паралелно

Mon, 19 Apr 2021 00:00:00 GMT

Имам клъстер от Raspberry Pi-та вкъщи, на които върви Docker Swarm. За да ги държа в крак, те използват една и съща конфигурация – потребители, версии на Docker и т.н.

Понякога някои от обновленията изискват да се изпълни едно и също нещо на всички възли в клъстера – например – създаване на нова Docker macvlan мрежа.

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

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

Итерация 1: Собствен Python скрипт

Първата ми идея беше да напиша собствен Python скрипт. От една страна, така щях да науча Python малко по-добре, а от друга – не можах да намеря добър начин да изпълнявам команди по по-„роден“ начин.

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

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

Итерация 2: `pssh`

Ровейки в Google, попаднах на [pssh](https://linux.die.net/man/1/pssh), който може да изпълнява неща паралелно през SSH.

Като цяло беше доста лесно да го пусна и да проработи.

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

Оказва се, че е доста лесно, ако попаднеш на правилния коментар в StackOverflow.

Кратката версия е:

stty -echo; printf "Password: "; read PASS; stty echo; echo "${PASS}" | \
pssh -h <HOSTFILE> -o /tmp/output -t 0 -I "`cat ./commands.sh`"

Частта -I "`cat ./commands.sh`" трябва да се напише точно така (заобиколена с кавички и обратни кавички), иначе командите не се изпълняват правилно. Паролата ще бъде изпратена като отделна команда, а не като вход към sudo.

Другата уловка е, че заради начина, по който е направено всичко това, sudo трябва да се изпълнява с параметъра -S, за да приеме правилно паролата от входа.

Разгадаване на числова парола на ZIP файл само с команднолинейни инструменти

Mon, 14 Sep 2020 00:00:00 GMT

Днес получих месечната си фактура от доставчика ми на интернет и нещо ми се стори странно.

Фактурата, съдържаща се в писмото, беше в ZIP файл с парола.

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

Това е рожденият ден на титуляря на сметката във формат YYMMDD.

Направих едно много грубо изчисление наум, докато бях на фитнес, и се оказа, че възможните комбинации са много малко. След като използвах онлайн инструмент за изчисляване на колко дни са минали (тъй като не всички комбинации биха довели до валидна дата) от 1900-01-01, се оказа, че комбинациите са само 44 075 (до 2020-09-14).

Знаейки, че оптимизирани инструменти, използващи GPU мощност за разбиване на хешове, могат да правят догадки в милиони на секунда, исках да видя колко бързо може да се разгадае паролата без да ги използвам, а само с помощта на Linux/macOS CLI (тъй като имах достъп единствено до VPS във фитнеса).

Измислих следния код, който работи на macOS:

echo {1..44000} | xargs -P 16 -n 1 -I{} date -v "-{}d" +"%y%m%d" | xargs -P 16 -I{} sh -c 'unzip -qqoP "{}" 0417160508.zip && echo "{}" && exit 255'

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

echo {1..44000} генерира числата от 1 до 44 000 и ги предава на следващата стъпка.

xargs -P 16 -n 1 -I{} date -v "-{}d" +"%y%m%d" – взема входа от първата стъпка и генерира дати във формат YYMMDD, като използва функционалността на date да „добавя“ към дата определено количество. В случая това би извадило X дни от текущата дата. Където X е числото, генерирано в първата стъпка. По този начин можем да генерираме дати от днес назад до 1900-те.

Третата стъпка е по-интересната, затова ще я разделя на две части:

xargs -P 16 -I{} sh -c '...'

Това взема генерираните дати от стъпка 2 и изпълнява команда за всяка от тези дати. -P 16 тук означава, че това ще се изпълнява в 16 паралелни процеса, за да се ускори пресяването на данните. Същият трик е приложен и в стъпка 2, за да се ускори генерирането на дати.

Втората част е мястото, където се случват догадките:

unzip -qqoP "{}" 0417160508.zip && echo "{}" && exit 255

Това, което прави, е първо да се опита да декомпресира zip файла, използвайки паролата, генерирана в стъпка 2. Ако е успешно, то ще отпечата (echo) познатата парола и след това exit 255 принуждава xargs да спре изпълнението. Не искаме да продължаваме да гадаем, ако паролата вече е намерена.

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

Как да се справим със спагети код в PHP: използване на анонимни функции за извличане на парчета шаблонен код

Sat, 08 Aug 2020 00:00:00 GMT

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

Кодът е WordPress плъгин, написан с много наследен (legacy) подход – бизнес и фронтенд логиката са смесени на едно място. Манипулации на данни, правени по средата на шаблонния код и подобни неща.

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

Случаят, по който работих днес, беше следният – имаш таблица, която показва куп записи. Трябваше да добавим няколко филтъра към таблицата и да я накараме да работи през AJAX, за да се обновява бързо интерфейсът, без да се презарежда цялата страница на WordPress Admin.

Филтрирането на данните беше лесно – един бърз inline array_filter, който да филтрира данните, преди да бъдат подадени към шаблонния код (за да запазим същия стил на кода, и това беше в шаблонния файл 😇).

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

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

Първият начин би бил да обвием HTML-а преди и след таблицата в ОГРОМНИ if конструкции, за да сме сигурни, че той не се рендерира.

Друг начин би бил да извадим шаблона в отделен файл и да го включим в AJAX action-а, който бихме дефинирали в кода на плъгина.

Анонимните функции на помощ!

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

Кодът се изпълнява в метод на клас. В шаблона на таблицата има препратки към $this. Ако не искаме да променяме кода много, трябва да подадем $this като аргумент на функцията. Е, това не работи, защото не можеш да подадеш $this като параметър 🤷‍♂️.

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

Тогава си спомних, че сайтът не работи на PHP 5.2, а на PHP 7, така че анонимните функции се поддържат.

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

$table_function = function() use ( $pages, $current_page, $items ) {
    // ... Table render code
}

Това ще ти позволи директно да използваш $pages или $items в тялото на функцията.

Страхотното тук е, че можеш да подадеш и $this като променлива в обхвата на функцията!

Така успяхме напълно да извадим кода за рендериране на таблицата в отделна функция, която можем да извикаме изолирано по време на AJAX заявката!

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

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

Arduino/ESP32: Изключване на task watchdog-а

Wed, 29 Apr 2020 00:00:00 GMT

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

Използвах AutoConnect, за да поддържам WiFi връзка без да съхранявам паролите в кода и да предоставя OTA ъпдейти през уеб интерфейса.

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

Едната задача да се занимава с API-та, четене на сензори, ъпдейти, WiFi и т.н., а другата да обработва прекъсването и PWM управлението на вентилаторите.

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

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

След като направих всичко това, забелязах, че грешката идва от watchdog-а:

Task watchdog got triggered. The following tasks did not feed the watchdog in time:

IDLE (CPU 1)
Tasks currently running:
CPU 0: ManageTask
CPU 1: ControllerTask

Поразрових се и излиза, че това се задейства от Task Watchdog-а на ESP32, който се грижи всички задачи да получават своя ред за изпълнение на процесора.

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

След известно ровене и пробване на различни неща, излиза, че най-лесният начин да се измъкнеш от тази ситуация е просто да изключиш watchdog-а и да се надяваш нещата да се изпълнят навреме 🙂 Задачата не е критична, така че е нормално да се изчака повече, докато приключи с това, което прави.

За да изключите watchdog-а, трябва да направите две неща:

Първо, включете хедъра esp_task_wdt.h. За целта добавете #include <esp_task_wdt.h> към секцията с include-ите си.

Второ, накарайте watchdog-а да не рестартира контролера и да чака по-дълго. За целта трябва да добавите esp_task_wdt_init(30, false); в началото на кода на вашата задача.

void manage_core_task(void *pv_parameters) {
    esp_task_wdt_init(30, false);
    // .... rest of the code ...
}

Това ще зададе timeout на watchdog-а на 30 СЕКУНДИ и ще изключи рестартирането на контролера, ако се задейства.

Ако искате контролерът все пак да се рестартира след задействане на watchdog-а, сменете втория параметър на извикването на функцията от false на true.

Настройване на YubiKey за подписване на Git комити

Wed, 08 Jan 2020 00:00:00 GMT

Използвам YubiKey като ключ за двуфакторна автентикация и за подписване на Git комитите си. До преди няколко дни използвах YubiKey 4. Тъй като текущият ми компютър няма никакви USB-A портове, последната година мъкнех из раницата си USB-A към USB-C адаптери и използването на ключа беше пълна мъка. Затова реших, че е време да мина на „новия“ си YubiKey 5C и да не жонглирам повече с тези адаптери.

Всъщност ключът си стои у мен от доста време – поръчах го заедно със заместващ YubiKey 4, който получих заради проблема с Infineon TPM, който са открили, но чак сега реших, че е време да премина на новия ключ.

Другата причина да го направя точно сега е, че старите ми GPG ключове изтекоха и трябваше да ги издам наново, така че мога да използвам ключа за подписване на Git комитите си.

GPG лудницата

Ако си се занимавал с GPG ключове в миналото (или се занимаваш в момента), знаеш, че може да е доста трудно да го накараш да работи както трябва и безопасно, ако никога не си го правил. Пазене на главните ключове офлайн, местене на публични ключове, преиздаване на ключове след изтичането им, евентуално подписването им с предишни ключове за верификация, отнемане на ключове… Не е лесно да следваш най-добрите практики дори на теория. Когато стане дума за практиката, нещата стават изключително сложни.

Повечето уроци в мрежата препоръчват да използваш командния ред за генериране на ключовете, да навигираш из менюта с необичаен дизайн и общо взето е болка да ги накараш да заработят. Повечето казват да използваш офлайн машина, например Raspberry PI, и/или да генерираш главните ключове и подключовете офлайн и да държиш главния ключ далеч от компютъра си.

🤯

Занимавам се с това всеки януари вече почти 4 години. Страхувам се от момента, в който получа следната грешка, която ми показва, че подписващите ми ключове са изтекли.

error: gpg failed to sign the data
fatal: failed to write commit object

Тази година реших, че е време да направя процеса много по-лесен и да използвам вграденото генериране на сертификати, за да избегна цялата тази каша с генерирането на GPG ключове и подобни.

Генериране на ключове директно върху YubiKey

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

Първо трябва да настроим картата/устройството.

Настройка на картата/устройството

Изпълни gpg --card-status в терминала и трябва да видиш нещо такова:

Reader ………..: Yubico Yubikey 4 OTP U2F CCID
Application ID …: <Serial number>
Version ……….: 2.1
Manufacturer …..: Yubico
Serial number ….: <Device serial number>
Name of cardholder: unspecified
Language prefs …: en
Sex …………..: unspecified
URL of public key : \[not set\]
Login data …….: <e-mail or nothing>
Signature PIN ….: not forced
Key attributes …: rsa4096 rsa4096 rsa4096
Max. PIN lengths .: 127 127 127
PIN retry counter : 3 0 3
Signature counter : 9

Ако виждаш нещо подобно и няма грешки, можеш спокойно да продължиш.

Изпълни gpg --card-edit

Ще се озовеш в интерфейс в командния ред, който показва същата информация в началото, а най-отдолу има команден промпт gpg/card>.

Напиши admin и натисни Enter.

Сега можеш да напишеш help, за да разбереш как да промениш информацията за собственика и PIN кодовете на картата.

Нещо, което ЗАДЪЛЖИТЕЛНО трябва да направиш, е да смениш PIN кодовете по подразбиране на картата. Те са два. Първият е PIN кодът, с който достъпваш ключовете на картата. Вторият е „Admin“ PIN или PUK (Personal Unblocking Code).

За целта напиши passwd и ще видиш меню:

gpg/card> passwd  
gpg: OpenPGP card no. <Serial number> detected

1 - change PIN  
2 - unblock PIN  
3 - change Admin PIN  
4 - set the Reset Code  
Q - quit

Напиши 1 и следвай указанията, за да смениш PIN кода. PIN кодът по подразбиране е 123456.

След като приключиш с това, избери 3, за да смениш Admin PIN. По подразбиране е 12345678.

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

Командите, които можеш да използваш, са:

name – за смяна на името на собственика на картата
login – за смяна на имейл адреса или логина на собственика на картата

След това можем да преминем към същинското генериране на ключове.

Генериране на ключове

Сега е време наистина да генерираме ключовете.

За целта напиши generate.

Ще бъдеш попитан Make off-card backup of encryption key? (Y/n), но както се споменава в документацията на YubiKey, това е само бекъп „на парче“ и няма да създаде пълен бекъп на тайните ключове, така че няма значение дали ще отговориш Yes, или No. Аз отговарям с No(n).

Ако на картата вече има запазени ключове, ще бъдеш попитан дали искаш да ги замениш:

gpg: Note: keys are already stored on the card!

Replace existing keys? (y/N)

Увери се, че няма да заменяш нещо важно, от което нямаш бекъп, и продължи с Y. Ако има нещо важно, по-добре прекъсни целия процес с Ctrl+C.

Ще бъдеш попитан за PIN кода на картата, който зададе по-рано.

После трябва да избереш за колко време ще са валидни ключовете:

Please specify how long the key should be valid.
        0 = key does not expire
      <n> = key expires in n days
     <n>w = key expires in n weeks
     <n>m = key expires in n months
     <n>y = key expires in n years
 Key is valid for? (0)

Ако искаш ключовете да са валидни само 1 година, напиши 1y.

Ще бъдеш помолен да потвърдиш датата на изтичане. Провери дали всичко е правилно и потвърди.

След това ще трябва да въведеш информация за собственика на ключа:

Is this correct? (y/N) y
GnuPG needs to construct a user ID to identify your key.
Real name: <Your name>
Email address: <Your e-mail>
Comment: <Comment is optional>
 You selected this USER-ID:
     "<Your name> <comment> <your e-mail>
 Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit?

Type `O` to confirm if everything seems correct.

След това ще бъдеш попитан за Admin PIN или PUK. Това е необходимо, защото ще се извърши запис върху картата.

После, ако всичко е наред, YubiKey ще започне да мига и ще продължи да го прави известно време (при мен отнема към пет минути).

Когато приключи, ще видиш следното съобщение:

gpg: key <Short ID> marked as ultimately trusted
gpg: revocation certificate stored as '/Users/bisko/.gnupg/openpgp-revocs.d/<LONG ID>.rev' public and secret key created and signed.

Запиши си <Short ID>, защото ще ни трябва по-късно.

В този момент можеш да излезеш от GPG промпта с quit или Ctrl+C.

Сега е време да запазим публичния ключ, за да можем да го използваме на друг компютър.

За целта изпълни следната команда:

gpg --armor --export <Short ID> > <Short ID>.asc

Това ще експортира публичния ключ във файл с име <Short ID>.asc. Той ще ти трябва в бъдеще, ако искаш да използваш YubiKey на друг компютър или ако изгубиш GPG конфигурацията си.

За да възстановиш публичния ключ във връзката си с ключове (keyring), направи следното:

gpg --import < <Short ID>.asc
gpg: key <Short ID>: public key "Your Name <your@email>" imported
gpg: Total number processed: 1
gpg: imported: 1

Много важна забележка. Ако това е нова инсталация на GPG или друг компютър, GPG няма сам да разпознае ключовете на картата. Трябва да изпълниш gpg --card-status, за да може да прочете картата и да засече ключовете върху нея.

Настройка на Git за подписване

За да настроиш Git да подписва комитите ти, трябва да добавиш следното в ~/.gitconfig.

В секцията [user] трябва да добавиш (или обновиш) следния ред:

signingkey = 0x<Short ID>

После, ако искаш да подписваш всичките си комити, добави следното в края на файла:

[gpg]
  program = /usr/local/bin/gpg
[commit]
  gpgsign = true

Така Git ще подписва всички твои комити.

За да настроиш GitHub, трябва да добавиш публичния си ключ към профила си. За целта отиди на GitHub -> Settings -> SSH and GPG keys -> New GPG key.

Ще видиш текстово поле, в което трябва да поставиш цялото съдържание на файла <Short ID>.asc, който генерирахме по-горе.

Ако искаш да копираш съдържанието на файла (на macOS), можеш да направиш така:

cat <Short ID>.asc | pbcopy

Това ще копира съдържанието на целия файл в клипборда.

Постави го в текстовото поле в GitHub и натисни бутона Add GPG key.

След това можеш да пробваш да направиш комит и push към GitHub и трябва да видиш симпатичния етикет Verified.

Дебъгване

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

Подписване с GPG

Първо опитай да подпишеш нещо с ключа:

gpg -s <file>

Ако това не успее, опитай да разбереш защо, аз не съм експерт, за да помогна с това.

Погледни изхода на GitGIT_TRACE=1 git commit -am “test”

Това ще ти покаже точно какво прави Git, докато се опитва да направи комита и да го подпише. Ще ти даде насока защо подписването може да се проваля.

От него можеш да видиш и че Git изпълнява следната команда:

/usr/local/bin/gpg --status-fd=2 -bsau <Key ID>

Можеш да опиташ да я изпълниш ръчно, за да видиш дали ще ти даде по-добра грешка.

e1000e eth0: Detected Hardware Unit Hang

Wed, 18 Dec 2019 00:00:00 GMT

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

Нямаше да е първият път, в който драйвер причинява зависване на мрежовата връзка. В миналото съм се опарвал от бъгави WiFi драйвери както на Linux, така и на Windows компютри.

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

vmhost kernel: e1000e 0000:00:1f.6 eth0: Detected Hardware Unit Hang:
vmhost kernel: TDH <0>
vmhost kernel: TDT <1>
vmhost kernel: next_to_use <1>
vmhost kernel: next_to_clean <0>
vmhost kernel: buffer_info[next_to_clean]:
vmhost kernel: time_stamp <10fbc2f81>
vmhost kernel: next_to_watch <0>
vmhost kernel: jiffies <10fbc3871>
vmhost kernel: next_to_watch.status <0>
vmhost kernel: MAC Status <40080083>
vmhost kernel: PHY Status <796d>
vmhost kernel: PHY 1000BASE-T Status <7800>
vmhost kernel: PHY Extended Status <3000>
vmhost kernel: PCI Status <10>
vmhost kernel: e1000e 0000:00:1f.6 eth0: Reset adapter unexpectedly
vmhost kernel: vmbr0: port 1(eth0) entered disabled state

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

Търсейки отговори онлайн, попаднах на тази тема в ServerFault.

Причина

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

При мен това обикновено се случваше, когато стриймвам медия от локалния Plex сървър към някое устройство. Заради начина, по който е изградена мрежата, Windows VM-ът, на който върви Plex, трябва да вземе медийния файл от NFS мрежов дял на отделно устройство, да го транскодира във VM-а и после да го изпрати към устройството за възпроизвеждане.

Това се натрупва до много мрежов трафик, обикновено ~40-100 mbit/s, в зависимост от устройството, което пуска файла, и от качеството на оригиналния файл.

Същият проблем се появи и при стриймване на игри през Steam Link към нашия Apple TV. Връзката е кабелна, но не е необичайно мрежата да прекъсне. Мисля, че е свързано със същия проблем, но ще държа под око дали ще се повтори в бъдеще след поправката.

Възможна поправка

Изглежда, че възможна поправка е да се изключат GSO (Generic Segmentation Offload), TSO (TCP Segmentation Offload) и GRO (Generic Receive Offload) на мрежовия интерфейс*:

ethtool -K eth0 gso off gro off tso off

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

Бележки под линия

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

Бележки: Стартиране на локален/частен swarm регистър за Docker образи

Fri, 11 Oct 2019 00:00:00 GMT

Днес се опитвах да генерирам Docker образ от Node.js проект и исках да го разположа на моя локален тестов swarm.

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

Решението е образът да се качи (push) в Docker регистър, от който всички възли в swarm могат да го изтеглят (pull).

Създаване на регистъра

За да стартирате регистър услуга в swarm, изпълнете:

docker service create —name registry —publish 5000:5000 registry:latest

Това ще създаде услугата registry и ще я стартира в swarm, като я направи достъпна за всички възли в swarm.

Качване на образ в регистъра

За да качите образ в регистъра, трябва да направите две неща – да го тагнете и след това да го push-нете.

Ето пример как да build-нете и тагнете образа наведнъж:

docker build . -t localhost.localdomain:5000/:latest

И как да го качите в регистъра:

docker push localhost.localdomain:5000/:latestИзползване на образа в услуга/контейнер/и т.н.

За да използвате образа в услуга или контейнер, посочвате пълния път от по-горе, т.е. localhost.localdomain:5000/<image-name>:latest.

Възлите в swarm ще имат достъп до образа и ще могат да го изтеглят и стартират.

Важна забележка относно адреса на регистъра

В повечето уроци онлайн адресът на регистъра е даден като localhost:5000. За съжаление това не работи и обикновено изтича времето за изчакване, когато се опитате да го ползвате. Ако го смените с localhost.localdomain, ще заработи!

Не знам защо се случва това, при положение че и localhost, и localhost.localdomain се разрешават до 127.0.0.1.

Снипети: Преместване на клавиша Section sign на Apple клавиатурите към back quote ( § към ` )

Wed, 31 Jul 2019 00:00:00 GMT

Използвам клавиатури на Apple от доста време, но когато живееш в Европа, не е лесно да се сдобиеш с американската подредба, на която съм свикнал.

На macOS има „лесен“ начин да пренастроиш клавиатурата само с една команда в терминала:

watch -n1 -x hidutil property -m ’{“ProductID”:592, “VendorID”:1452}’ —set ’{“UserKeyMapping”:[{“HIDKeyboardModifierMappingSrc”:0x700000035,“HIDKeyboardModifierMappingDst”:0x700000064}]}’

Това парче код променя картографирането на клавиша Section ( § ), така че да изписва клавиша backquote/tilde ( `/ ~ ).

Частта watch -n1 -x го изпълнява всяка секунда, защото понякога macOS обича да губи настройката, обикновено когато компютърът заспи или когато клавиатурата бъде изключена и включена отново.

Имай предвид, че на някои версии на macOS инструментът watch не е инсталиран и трябва да се инсталира чрез нещо като Homebrew или MacPorts.

Горният код работи с външната клавиатура на Apple с USB и европейска подредба с български букви. Може да се наложи лека корекция на шестнадесетичните стойности на клавишите за други видове клавиатури.

Вариант на командата работи добре за същия тип клавиатура на самия MacBook Pro. Просто трябва да размените местата на стойностите 0x700000035 и 0x700000064.

Мислех да напиша инструмент, който да го прави автоматично вместо мен, но в момента смятам, че е по-разумно да инвестирам в нова клавиатура с правилната подредба 🙂

Ресетиране/рестартиране на дистанционното на Apple TV

Sun, 17 Feb 2019 00:00:00 GMT

Снощи, докато имахме гости, успях да потопя дистанционното на нашето Apple TV във вода. Липсата на сън и нестабилните чаши водят до инциденти.

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

Решихме, че е свършено, и започнахме да търсим пакета с ориз по шкафовете.

Влязох в интернет най-вече на шега, за да видя дали мога да опитам да го „рестартирам”.

Един полезен наръчник ме насочи да натисна и задържа бутоните за увеличаване на звука (Volume Up) и Menu за 2-3 секунди, за да ресетирам дистанционното и да го вкарам в режим на сдвояване.

Бях наистина изненадан, когато всъщност проработи!

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

TL;DR;

Задръжте Menu + Volume Up за 2-3 секунди
Изчакайте няколко секунди
Опитайте да взаимодействате с Apple TV

bisko.be - Разработка

Стартиране на Ollama със стари видеокарти на CachyOS

TL;DR;

Време за история

[Linux] Възстановяване на прекъсната сесия на `apt dist-upgrade`

[Linux] Syncthing – файлова система само за четене при стартиране като услуга

[Linux] Изпълнение на множество команди на множество сървъри паралелно

Итерация 1: Собствен Python скрипт

Итерация 2: pssh

Кратката версия е:

Разгадаване на числова парола на ZIP файл само с команднолинейни инструменти

Как да се справим със спагети код в PHP: използване на анонимни функции за извличане на парчета шаблонен код

Arduino/ESP32: Изключване на task watchdog-а

Настройване на YubiKey за подписване на Git комити

GPG лудницата

Генериране на ключове директно върху YubiKey

Настройка на картата/устройството

Генериране на ключове

Настройка на Git за подписване

Дебъгване

Подписване с GPG

e1000e eth0: Detected Hardware Unit Hang

Бележки: Стартиране на локален/частен swarm регистър за Docker образи

Снипети: Преместване на клавиша Section sign на Apple клавиатурите към back quote ( § към ` )

Ресетиране/рестартиране на дистанционното на Apple TV

Итерация 2: `pssh`