Midnight Commander 4.8.29

Собрал пакеты Midnight Commander 4.8.29 для Debian/Ubuntu с архитектурами i386, amd64, armel, armhf и arm64. Пакеты для i386 и armel есть только в тех дистрибутивах, где они поддерживаются официально (в Ubuntu есть не все):

• Debian Buster (i386, amd64, armel, armhf, arm64)
• Debian Bullseye (i386, amd64, armel, armhf, arm64)
• Debian Bookworm (i386, amd64, armel, armhf, arm64)
• Debian Sid (i386, amd64, armel, armhf, arm64)
• Ubuntu Trusty (i386, amd64, armhf, arm64)
• Ubuntu Xenial (i386, amd64, armhf, arm64)
• Ubuntu Bionic (i386, amd64, armhf, arm64)
• Ubuntu Focal (amd64, armhf, arm64)
• Ubuntu Jammy (amd64, armhf, arm64)
  

Инструкция по подключению репозитария. Больше информации о бинарных сборках Midnight Commander можно найти на странице https://midnight-commander.org/wiki/Binaries.

По причине отсутствия доступа к серверу ночных сборок (которые не делались с прошлого года), я удалил их поддержку и пока не планирую возвращать ее в ближайшем будущем. Из приятного - добавлена поддержка Debian Bookworm, который уже на стадии заморозки.

P.S. Судя по истории моих правок странички https://midnight-commander.org/wiki/Binaries собирать каждый релиз новый mc я начал больше 11 лет назад.

Тест работает локально, но не работает в CI пайплайне

В процессе прикручивания Continuous Integration (CI) к приложению столкнулся с ситуацией когда end-to-end сценарий тестирования не работает в пайплайне. В то же время он корректно отрабатывает на локальной машине. У окружения CI отстутствует прямой доступ в Internet, но это не должно играть никакой роли т.к. сценарий написан таким образом, что приложение не предполагает ходить за пределы локальной машины.

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

Подключаюсь к Spark UI и вижу что задание обработки данных напрочь отсутвует. Далее смотрю логи компонента, который отвечает за его создание, но там никакого криминала нет. Иду в контейнер Spark Worker и начинаю медитировать на логи, а точнее их практически полное отсутствие.

VBoxManage.exe: error: Details: code E_FAIL (0x80004005), component MachineWrap, interface IMachine

Столкнулся с тем, что Vagrant не может запустить виртуальную машину VirtualBox в headless режиме на Windows 10

==> default: Running 'pre-boot' VM customizations...
==> default: Booting VM...
There was an error while executing `VBoxManage`, a CLI used by Vagrant
for controlling VirtualBox. The command and stderr is shown below.

Command: ["startvm", "df70e47d-8ba3-4103-b826-8bbfadff8794", "--type", "headless"]

Stderr: VBoxManage.exe: error: The virtual machine 'dev-workstation_default_1673686308201_10549' has terminated unexpectedly during startup with exit code -1073741819 (0xc0000005)
VBoxManage.exe: error: Details: code E_FAIL (0x80004005), component MachineWrap, interface IMachine

К Vagrant эта проблема не имеет отношения, т.к. сама команда VBoxManage startvm df70e47d-8ba3-4103-b826-8bbfadff8794 --type headless завершается с такой же ошибкой

C:\Program Files\Oracle\VirtualBox>VBoxManage startvm df70e47d-8ba3-4103-b826-8bbfadff8794 --type headless
Waiting for VM "df70e47d-8ba3-4103-b826-8bbfadff8794" to power on...
VBoxManage.exe: error: The virtual machine 'dev-workstation_default_1673686308201_10549' has terminated unexpectedly during startup with exit code -1073741819 (0xc0000005)
VBoxManage.exe: error: Details: code E_FAIL (0x80004005), component MachineWrap, interface IMachine

Версия VirtualBox 6.1.40 r154048, если запускать виртуальную машину с GUI, то ошибки не вознимает. В качестве решения попробовал перезагрузиться и переустановить VirtualBox, но это не помогло. Сейчас под рукой нет другой Windows 10 чтобы проверить возникает ли проблема там.

На форуме VirtualBox есть тема с похожими симптомами (Unable to headless start and detachable start), но там речь про Windows 11 и я не уверен что это тот же случай.

В баг трекере есть #17679 (Error on trying to run VM in headless mode), которому уже 5 лет. Во всех схожих случаях просят VBoxHardening.log, но никакие логи не появляются при этой ошибке.

В качестве временного решения сконфигурировал Vagrant запускать виртуальную машину с GUI.

Обновлено 15/01/2023: Попробовал запустить виртуальную машину на VirtualBox 7.0.4 - результат аналогичный. И логов все еще не пишет.

[Решено] Не устанавливается Vagrant на Windows

Не получилось установить Vagrant 2.3.4 на машинку с Windows 10 из-за ограничений UAC

Свойства файла выявили отозванный сертификат, которым подписан инсталлятор.

Без особой надежды сообщил о проблеме на форуме Hashicorp где оперативно указали на https://github.com/hashicorp/vagrant/issues/13051.

Выполнил команду certutil -URLCache CRL delete но сертификат все еще значится как отозванный. Попробую подождать до завтра, т.к. в комментариях было упоминание что спустя какое-то время все начинает работать.

Обновлено 12/01/2023

На следующий день проверил состояние сертификата - "This digital signature is OK".

Просто нужно было подождать некоторое время после очистки кэша CRL. После этого UAC не мешал установке Vagrant.

Релиз jtv2xmltv 0.2.2

Выпустил обновление jtv2xmltv 0.2.2 в котором исправил ошибку с неверным разбором названий программ в случае если в NDX файле есть несколько ссылок на одну и ту же запись в PDT файле. Конвертация проходила без ошибок, но часть названий программ не соответствовали расписанию.

Изначально этот конвертер писался для работы с провайдером IPTV, который предоставлял EPG только в формате JTV. Позже стали выкладывать и XMLTV и необходимость в конвертере отпала.

Из других изменений:

• добавил список изменений
  
• поправил тесты
• добавил CI пайплайн
  

Пакет для Debian/Ubuntu - jtv2xmltv_0.2.2-1_all.deb 

GCloud prompt

Много работаю с GCP и зачастую приходится иметь дело с несколькими проектами одновременно и переключаться между ними в течении дня. Случаются досадные ситуации когда команда была выполнена не в том проекте или не в том GKE кластере. Последнее особенно коварно, т.к. в корпоративной среде обычно один и тот же пользователь имеет доступ в разные кластера в разных проектах и переключение профиля gcloud не влияет на kubectl.

Bitnami Sealed Secrets

Чтобы управлять Kubernetes секретами в духе GitOps нужно их шифровать перед фиксацией в Git и расшифровывать на стороне Kubernetes. Для CI я раньше использовал Mozilla SOPS, а для Kubernetes решил попробовать Bitnami Sealed Secrets.

В Sealed Secrets используется ассиметричная криптография и расшифровать секреты без доступа к приватному ключу не получится - можно коммитить даже в публичный репозитарий, хотя я бы не рекомендовал так делать.