Команда для выполнения бэкапа в twrp хорошо описывает жизнь любителей кастомных прошивок.

Чтобы создать резервную копию разделов boot, data и system, нужно выполнить twrp backup bds.

Но если хочется побыстрее, то можно исключить генерацию хэш-сумм, для чего используется ключ m.

И в таком случае команда принимает вид twrp backup bdsm.

На сегодня пока всё.

Кажется я нашёл гимн пароля от google-аккаунта.

https://www.youtube.com/watch?v=xiJW4cfYX0g

Если перейти на сайт sberbankonline.ru, откроется сайт Авиасейлс.

А на сайте onlinesberbank.ru размещены правила безопасности в сети, такой фишинговый сайт наоборот.

lariat

Сегодня мир информационных технологий преподнёс мне очередную загадку.
Я производил некоторые манипуляции с одним из репозиториев на github, затем, чтобы удостовериться, что я ничего не сломал, я выполнил git fetch origin.

Эта команда должна была забрать все изменения из удалённого репозитория в локальный, но что-то пошло не так.

user@host:~/dev/repo$ git fetch origin
remote: git: 'lariat' is not a git command. See 'git --help'.
remote: aborting due to possible repository corruption on the remote side.
fatal: protocol error: bad pack header

Давайте разберём этот сниппет:
Первая строка - это промпт оболочки bash.
Вторая строка самая интересная, к ней вернёмся позже.
Третья строка сообщает о том, что гит прекращает работу из-за возможного повреждения удалённого репозитория.
Четвёртая строка, как я понял, содержит то ли изначальную, то ли более низкоуровневую ошибку, там сообщается о том, что гит получил плохой заголовок так называемого пака, это некая сущность, используемая гитом, но это сейчас не важно.

А теперь давайте вернёмся ко второй строке: remote: git: 'lariat' is not a git command. See 'git --help'..
Что именно означает remote в начале строки я не уверен, либо это указание на то, что событие произошло на удалённой стороне, либо что гит столкнулся с проблемой при работе с удалённой стороной.
А далее гит нам сообщает, что 'lariat' не является командой гита, и не мешало бы покурить мануал по этому поводу.
После получения такого вывода от гита у меня два вопроса: что произошло, и что такое этот ваш lariat?!
Я потратил около получаса на попытки как-то разгуглить эту проблему, и ничего похожего не нашёл.
Но самое главное, это случилось дважды! Я повторно выполнил команду git fetch origin, и снова получил этот же результат!
Только на третий раз коммуникация с github прошла успешно, и больше, сколько не тыкал, ошибка не возникала.

#ОноСломалось

Новая тестовая голосовая рубрика под названием "Оно сломалось".
Планирую творить в ней какую-то весёлую разрушительную дичь, пишите, что думаете о таком формате.

Продолжение истории про lariat

В том, что у гитхаба что-то там в очередной раз навернулось, на самом деле, нет ничего необычного, и кажется к этому все уже привыкли.
Но вот чем именно является этот самый lariat, действительно было интересно, ну по крайней мере мне.

И совсем неожиданно сегодня я получил ответ!

Дело было так:
1. 25 сентября, около 17:30 по МСК, у гитхаба происходит инцидент, из-за которого люди по всему миру начинают получать то самое сообщение про lariat.
2. Пользователь с ником heldrida открывает обсуждение на гитхабе, в котором спрашивает о происходящем.
3. Люди обсуждают проблему, делятся логами и т.п.
4. Примерно через неделю после инцидента в обсуждение приходит пользователь с ником terrorobe.
Он отправляет ссылку на тот самый инцидент, и в его описании идёт речь про какой-то неправильно сработавший скрипт, из-за которого сфейлилось 1.4 млн операций git, и тому подобные вещи.
Но самого главного там не было, там не было описания лариата!

Вроде как вопрос исчерпан, но я решаю спросить этого человека, что же такое этот самый lariat.
И сегодня он ответил следующее:
"lariat is a caching layer that speeds up parallel identical fetches to a repository, e.g. as initiated by CI farms."
Что перевести можно примерно так:
"lariat — это кэширующий слой, который ускоряет параллельное получение идентичных данных из репозитория, например те, которые инициируются скриптами CI."

Т.е. в гитхабе имеется возможность запускать так называемые actions, которые могут делать различную полезную работу прямо на серверах гитхаба.
Например собирать приложения из исходного кода, тестировать их, публиковать в магазинах приложений и т.п.
Такие экшены в первую очередь, как правило, получают файлы репозитория, и их может быть запущено несколько одновременно.
Иначе говоря всё вроде сходится, существовала проблема: множество запущенных параллельно экшенов забирали один и тот же репозиторий, и неразумно тратили ресурсы.
А гитхаб изобрёл механизм кэширования, назвав его lariat, который эту проблему решил.

Но самое интересное в том, что вообще непонятно, что это за человек, который мне ответил.
Сначала я думал, что он имеет какое-то отношение к гитхабу, т.к. подробно описал инцидент.
Я открыл его профиль, ничего подтверждающего эту инфу не увидел, и дальше копать не стал.
Затем я задал этот вопрос, он мне дал ответ, я пошёл писать этот пост, стал проверять инфу и выяснил, что это подробное описание инцидента есть на githubstatus.com.
В итоге получается, что это мог написать кто угодно, но раз ответ мне был дан, видимо тот чел что-то знает.

Продолжение истории про пароль от google-аккаунта

Сначала пароль никуда не был записан, и хранился лишь в голове пользователя, о чём и повествует первая часть.

Ну точнее как хранился... Пытался храниться.

Шли дни, месяцы, годы, но к большому сожалению, в те редкие моменты, когда пароль был действительно, по-настоящему нужен, пользователь вдруг понимал, что совсем забыл его.

Десятки попыток подобрать пароль были тщетны, и каждый раз его ожидал закономерный, печальный финал: сброс, и вечное забвение где-то в бездонных недрах серверов google.

Из раза в раз пароль проходил по этому бессмысленному закольцованному пути. Он рождался, единожды вводился правильно, и застывал в нетерпеливом ожидании на целые месяцы.

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

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

Он долго подыскивал место среди сотен папок и файлов, он вдумчиво выбирал такое расположение, которое точно не забудет, и наконец создал файл, и збросил пароль в последний раз.

Уныло тянулись рабочие будни, выходные мелькали за выходными, зима сменилась весной, а затем и летом.

И в один из ничем не примечательных дней, пользователь стал счастливым обладателем устройства, работавшим под управлением операционной системы Android.

Он немедленно приступил к настройке, встретился с полем ввода пароля от google-аккаунта, и...

https://www.youtube.com/watch?v=1K1SeubVwmk

Новый пост в рубрике "Оно сломалось"!
Получилось, кажется, чересчур затянуто, пожалуй в будущем буду меньше говорить и больше делать. Если что расшифровка будет в комментах.

Bluetooth наушники с агрессивным энергосбережением плюс телефон со скринридером, и на экране быстрых настроек неожиданно появляется нарик.

Пробник факапа

Только что я опрокинул кружку, в которой две минуты назад была кола.
Кружка стояла на столе около компа, а опрокинулась невероятно чётко впритык с телефоном.
Причём впритык к нижнему торцу, на котором Type C и mini-jack.
И если бы там оставалось хотя бы миллилитров 30...

В общем в очередной раз я доказал, в первую очередь самому себе: нехер держать жидкость в открытых ёмкостях на рабочем месте, т.к. рано или поздно происходит неизбежный сценарий, поставил -> отвлёкся -> забыл, что поставил -> смахнул -> понёс пк в ремонт.

Я вот баг нашёл. А вы?
Осторожно! Оно шумное!

Windows из будущего

Ставлю на виртуальную машину windows 11, и на экране выбора ISO файла получаю следующее:

Installer disc image file (iso):
D:\temp\Windows11-24h2.iso
Browse...
Windows Server 2025 detected.

Да, я погуглил и выяснил, что server 2025 действительно существует, и даже можно поставить превьюшку, но тем не менее - это забавно.

Константы

Мне поступил feature request на реализацию ограничений частоты отправки сообщений в чат Snow war.
И я первый раз в жизни использовал константы в bgt.

const int PLAYER_CHAT_MESSAGE_LIMIT_TIME = 1000;
const int VIEWER_CHAT_MESSAGE_LIMIT_TIME = 5000;

Всем спасибо за внимание. Можете устроить холивар в комментах на тему необходимости использования констант.

Это лучший ai-кавер говновоза, который я слышал.
Осторожно, присутствует нецензурная лексика.
https://www.youtube.com/watch?v=3ecfZvFyBf4

Дело было в августе, мучал свою клавиатуру и кое-какой софт, в попытках изобрести мониторинг уровня заряда батареи, ибо они разряжаются, как правило, в самый неподходящий момент.
Колупался с этим 3 дня и уже почти бросил, разок намертво повесил донгл клавиатуры, но всё же результат в виде nvda-аддона получил.
И вот сейчас таки выстрелило, пришло оповещение "Keyboard battery level reached 20%", и пока я его не скипну, будет каждую минуту меня долбить, т.е. пропустить его не реально.
А стало быть не зря колупался. Такие вот дела.

Взломал сам себя, ну почти

Имеется значит следующий сетап: мини пк с Home assistant, маршрутизатор и провайдер, дающий серый ip за натом.

Также имеется два сервера с разумеется белыми ip, один из которых в москве.

Из мини пк выходят 2 реверс-туннеля, первый идёт на сервер, который в москве, там для него настроен nginx с блэкджеком и сертификатами, выходит туннель в виртуалку, в которой стоит home assistant.
Этот туннель нужен, чтобы yandex мог как можно быстрее передать команду в home assistant, т.е. чтобы цепочка Алиса -> сервер yandex в москве -> home assistant -> целевое устройство, отрабатывала с минимальными задержками.
Второй реверс-туннель уходит на сервер НЕ в москве, он смотрит на порт ssh хост-системы, т.е. позволяет получать удалённый доступ к машине за натом.

Так вот вчера выяснилось, что Алиса перестала управлять устройствами, небольшое расследование привело к реверс-туннелю в Москву, который перестал подниматься.
А перестал подниматься он потому, что, по какой-то причине, изменились ключи sshd на сервере, который, кстати, мне не принадлежит, мне просто там выделен юзер для туннеля, по дружбе так сказать.
Владелец сервера сказал, что херегознает почему там эти ключи сменились, и что просто надо их дропнуть и зааксептить новые.

Ну полез я в файл known_hosts, а там что-то то ли зашифрованное, то ли закодированное, в общем нельзя так с ходу понять, какая строка за какой хост отвечает.
И что же я сделал? Правильно, rm .ssh/known_hosts, т.е. удалил файл со всеми когда либо встреченными хостами.
Потом сходил по ssh на Московский сервер, принял ключ сервера, убедился, что туннель поднялся и забыл об этой истории.
Прошло около 20 часов, в том числе прошло и 5 часов утра, когда провайдер забрал у меня дефицитный ip и выдал мне новый, т.е. все открытые с внешним миром соединения были безвозвратно разорваны.

И после того, как это всё случилось, я попытался с какой-то целью попасть в мини пк, на что получил:

channel 0: open failed: connect failed: Connection refused
stdio forwarding failed
Connection closed by UNKNOWN port 65535

Что за херня?! Наверное надо просто нажать ещё раз... Но результат не изменился.
Пара минут попыток достучаться хоть куда-то наконец привела меня к следующему выводу: после удаления known_hosts я зааксептил ключ московского сервера, но забыл про другой сервер, через туннель к которому и ходил по ssh.
Туннель для ssh благополучно оставался открытым до смены ip, но после неё попытка реконнекта не удалась, т.к. ключа в known_hosts уже не было.

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

Вот есть у нас мини пк, из него торчит туннель, он приходит в nginx, а из него мы можем попасть в home assistant.
Home assistant стоит внутри qemu, и попадая внутрь, мы попадаем, по факту, в виртуалку, не на хост.
Виртуалка тоже сидит за собственным натом, но, в теории, если постучаться в шлюз, то можно достучаться как раз до хоста, если оно фаерволом не закрыто.
В home assistant установлен аддон для доступа к нему по ssh, вот только толку вроде от этого не очень много, ибо проклятый нат, причём двойной, а в каком-то смысле даже тройной (isp -> router -> vm).
Но изучив панельку аддона я выяснил, что у него имеется веб-интерфейс, т.е. можно получить доступ в виртуалку через веб.
На самом деле не в виртуалку, а в докер-контейнер, но это не сильно важно для моего мува.
И так открыл я этот web ui, разумеется нифига не доступно, но с windows ocr что-то понять можно.
Постучался на ssh по адресу шлюза и о чудо, оно живое! Оно мне ответило!
А дальше всё просто и вполне секьюрно (нет). Вставить из буфера обмена туда не получилось, поэтому раздал приватный ключ на весь интернет, скачал его курлом в вм, зашёл по ssh в хост, зашёл по ssh в туннель, зааксептил хост и туннель восстановился.

Во всей этой истории меня слегка волнует только тот факт, что у qemu-машины по-дефолту есть доступ в хост, конечно виртуалка и sandbox - не одно и тоже, но всё же... В общем надо будет прикрыть это дело.