Проверка операционных усилителей

Сегодня дошли руки до распаковки набора для сборки лабораторного блока питания 0-30V, 0-3A который продается на каждом углу AliExpress. Операционные усилители, которые шли в наборе, не имеют никакой маркировки

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

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

В интернете нашлась несложная схема для проверки операционного усилителя (YouTube / KiCad)

Собрал ее на макетной плате

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

Все три "безымянных" операционных усилителя прошли тест, но я на всякий случай поставлю их в панельки, чтобы потом не мучиться с выпаиванием.

Решение проблем с GPIO на Raspberry PI 4 в Debian Bullseye arm64

Обновил Raspberry PI 4 с Debian Buster до Debian Bullseye и подключил схему управления оборотами вентилятора чтобы сделать его тише. Для управления PWM я использую GPIO 16.

https://www.raspberrypi.org/documentation/computers/os.html

В прошлый раз я тестировал на OpenELEC с python 2.7, но в Bullseye используется python 3.9.2. Для работы с GPIO в Debian нужно установить пакет python3-rpi.gpio

$ sudo apt-get update
$ sudo apt-get install python3-rpi.gpio

Теперь можно установить сервис для управления оборотами в зависимости от температуры процессора

$ git clone https://github.com/tataranovich/Raspberry-Pi-PWM-fan.git
$ cd ./Raspberry-Pi-PWM-fan/
$ sudo python3 fan.py
Traceback (most recent call last):
  File "/home/andrey/Raspberry-Pi-PWM-fan/fan.py", line 42, in <module>
    GPIO.setup(FAN_PIN, GPIO.OUT, initial=GPIO.LOW)
RuntimeError: Not running on a RPi!

Апгрейд сборочного окружения ARM

Затеял обновление своего сборочного окружения, которое используется для компиляции пакетов для armel, armhf и arm64 архитектур. Сейчас оно построено на Raspberry PI 4 2GB и загружается с SD карточки на 32GB в которой /var/cache/pbuilder/build использует bcache поверх NFS и ram диска (подробности есть тут).

Это прилично ускоряет сборку в pbuilder, но только если размер билда не превысит размер ram диска. Raspberry PI 4 умеет загружаться с USB без плясок с бубном и поэтому самым простым решением для ускорения будет отказ от SD карт. Для этого я прикупил Orico M.2 NVMe SSD enclosure и Kingston A2000 на 256GB.

Midnight Commander 4.8.27

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

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

Задержка ответа DNS до 5 секунд или более в GKE

Изначально эта проблема попала ко мне с описанием "Нестабильная работа Solr на всех окружениях". В админке Drupal сайта тестирование настроек Solr в большинстве случаев завершалось с ошибкой, но сам поиск хоть и очень медленно, но работал.

Сперва выполнил пробный запрос к Solr из одного из контейнеров чтобы подтвердить наличие проблемы - с приличной задержкой, но запрос выполнился. Повторил запрос в цикле и получилось что время выполнения запроса "скачет" от 100 миллисекунд до 12 секунд. Чтобы исключить проблемы с DNS попробовал подключиться к Solr по IP, а не по FQDN - запрос выполняется быстро. Повторяю тест используя IP вместо FQDN в цикле и результат находится в пределах 100 - 150 миллисекунд. Выходит что проблема в DNS, но пока не ясно виноват kube-dns или вышестоящий DNS сервер к которому обращается kube-dns. Попробовал обращаться к другим доменам, например www.google.com - поведение аналогичное. Описание проблемы меняется с "Нестабильная работа Solr на всех окружениях" на "Нестабильная работа DNS в GKE на всех окружениях".

SSH логин в GCP VM по паролю

Чтобы зайти на виртуальную машину через SSH в GCP удобно использовать команду gcloud compute ssh, но по умолчанию используются ключи, которые добавляются на уровень проекта, либо в саму виртуальную машину. Чтобы зайти с авторизацией по паролю нужно указать опцию --plain

$ gcloud compute ssh <instance> --plain --project <gcp-project> --zone <gcp-zone>

Такой подход удобен когда у виртуальных машин нет публичных IP адресов и можно подключаться используя Identity Aware Proxy (IAP) без промежуточных решений вроде AWS Workspace, bastion host или VPN.

Midnight Commander 4.8.26 для Ubuntu Hirsute

Добавил в свой репозитарий поддержку Ubuntu Hirsute (21.04) и собрал пакеты Midnight Commander 4.8.26 для архитектур amd64, armhf и arm64.

Новый GPG ключ для репозитария

Перевел свой репозитарий на новый GPG RSA/4096 ключ:

GPG key ID: 0x776F2A248D76B064
Fingerprint: F6DE 7A3E D638 7B13 0F55  E6FF 776F 2A24 8D76 B064

Если у вас установлен пакет tataranovich-keyring и вы своевременно устанавливаете обновления, то ничего делать не нужно - новый ключ уже должен быть установлен. Чтобы убедиться в этом проверьте что пакет tataranovich-keyring имеет версию 2021.05.17:

$ apt-cache policy tataranovich-keyring | head -n3
tataranovich-keyring:
  Installed: 2021.05.17
  Candidate: 2021.05.17

Установить или обновить пакет tataranovich-keyring:

$ KEYRING_VERSION='2021.05.17'
$ wget http://www.tataranovich.com/debian/pool/sid/main/t/tataranovich-keyring/tataranovich-keyring_${KEYRING_VERSION}_all.deb
$ sudo dpkg -i tataranovich-keyring_${KEYRING_VERSION}_all.deb
$ rm -v tataranovich-keyring_${KEYRING_VERSION}_all.deb

Failed to find a valid digest in the 'integrity' attribute for resource

Сбросили проблему с нерабочим поиском на статическом сайте. В консоли браузера несколько раз появляется ошибка "Failed to find a valid digest in the 'integrity' attribute for resource". В коде страницы для ресурсов используется механизм integrity и если хеш не сходится, то браузер не дает использовать "поддельный" ресурс. Осталось определить где его "подделали"...

Terraform провайдер libvirt в Debian Buster

Давно собирался попробовать управлять виртуалками в libvirt через Terraform. Для этого существует провайдер multain/libvirt. Для начала создам виртуальную машину с двумя дисками.

terraform {
  required_providers {
    libvirt = {
      source = "multani/libvirt"
      version = "0.6.3-1+4"
    }
  }
}

provider "libvirt" {
  uri = "qemu:///system"
}

variable "prefix" {
  description = "Resource name prefix"
  type        = string
  default     = "terraform-"
}

resource "libvirt_volume" "boot" {
  name = "${var.prefix}boot"
  size = 20*1024*1024*1024
}

resource "libvirt_volume" "data" {
  name = "${var.prefix}data"
  size = 20*1024*1024*1024
}

resource "libvirt_domain" "default" {
  name = "${var.prefix}default"
  vcpu = 1
  memory = 2048

  disk {
    file = "/var/lib/libvirt/images/debian-10.9.0-amd64-netinst.iso"
  }

  disk {
    volume_id = libvirt_volume.boot.id
  }

  disk {
    volume_id = libvirt_volume.data.id
  }

  boot_device {
    dev = [ "hd", "cdrom"]
  }

  network_interface {
    bridge = "dmz0"
  }
}

ImageMagick: attempt to perform an operation not allowed by the security policy `PDF'

 При попытке конвертировать набор сканированных страниц в PDF получил такую ошибку

$ convert *.jpg -auto-orient output.pdf  
convert-im6.q16: attempt to perform an operation not allowed by the security policy `PDF' @ error/constitute.c/IsCoderAuthorized/408.

Решение проблемы нашел на stackoverflow

. Мне хватило только закомментировать строку <policy domain="coder" rights="none" pattern="PDF" />

$ sudo etckeeper vcs diff /etc/ImageMagick-6/policy.xml
diff --git a/ImageMagick-6/policy.xml b/ImageMagick-6/policy.xml
index 82a3d0b..73b8384 100644
--- a/ImageMagick-6/policy.xml
+++ b/ImageMagick-6/policy.xml
@@ -91,6 +91,8 @@
   <policy domain="coder" rights="none" pattern="PS2" />
   <policy domain="coder" rights="none" pattern="PS3" />
   <policy domain="coder" rights="none" pattern="EPS" />
+  <!-- Fix for: attempt to perform an operation not allowed by the security policy `PDF'
   <policy domain="coder" rights="none" pattern="PDF" />
+  -->
   <policy domain="coder" rights="none" pattern="XPS" />
 </policymap>

После этого набор картинок преобразовался без ошибок.

Nextcloud 21: Module php-imagick in this instance has no SVG support.

После обновления до Nextcloud 21 в разделе "Security & setup warnings" появилось сообщение, что расширение php-imagick не поддерживает SVG (Module php-imagick in this instance has no SVG support. For better compatibility it is recommended to install it.)

Чтобы исправить это предупреждение в Debian нужно установить пакет libmagickcore-6.q16-6-extra

sudo apt update
sudo apt install libmagickcore-6.q16-6-extra

После этого предупреждение пропало

 

Kodi не воспроизводит файлы после обновления ядра NFS сервера до 5.10.13

Уже прошло больше недели как я обновил ядро на домашнем сервере с linux-image-5.9.0-0.bpo.5-amd64 (5.9.15-1~bpo10+1) до linux-image-5.10.0-0.bpo.3-amd64 (5.10.13-1~bpo10+1), но перезагрузку сервера сделал только вечером прошлого воскресенья. В понедельник меня ждали жалобы от домочадцев что Kodi, который в основе всех домашних HTPC, больше не проигрывает ни музыку, ни записи с сервера.

Бегло проверил что проблема затрагивает все установки Kodi и поскольку ничего не менялось кроме перезагрузки сервера, то начал вспоминать что менялось на самом сервере. Вспомнил про обновление ядра среди недели. Поменял параметры grub, чтобы загрузилось предыдущее ядро

GRUB_DEFAULT="Advanced options for Debian GNU/Linux>Debian GNU/Linux, with Linux 5.9.0-0.bpo.5-amd64"

После update-grub и перезагрузки проблема с Kodi решилась, но осталось разобраться что не так с ядром 5.10.13.

Отключение IBus в Debian/Ubuntu

Супруге приходится пользоваться Zoom и с ним в систему притянуло IBus (Intelligent Input Bus). Это фреймворк для методов ввода и наверное тем кто использует иероглифы он полезен, но для меня он не решает никаких проблем, а лишь добавляет глюки с переключением языка ввода (используется переключение по Caps Lock).

Чтобы отключить IBus нужно добавить "отклонение" через dpkg-divert

sudo dpkg-divert --package im-config --rename /usr/bin/ibus-daemon

Включить обратно можно командой

sudo dpkg-divert --package im-config --rename --remove /usr/bin/ibus-daemon

После перезагрузки системы IBus больше не запускается.

Самодельный шунт для амперметра

Еще до праздников купил модуль амперметра 91C16 шкала которого размечена для измерения постоянного тока до 5А. Встроенный шунт отсутствует, а какой нужен для этого модуля в описании не было указано.

Чтобы подобрать шунт нужно знать ток при котором стрелка отклоняется в крайнее положение. Для этого ставлю на лабораторном блоке питания напряжение 1В и подключаю модуль последовательно с резистором 10кОм. В этом случае ток не превысит 100мкА и очень маловероятно что чувствительность этого модуля лучше. В результате стрелка не отклонилась вовсе - меняю сопротивление на 1кОм и стрелка немного отклоняется. Ставлю вместо постоянного резистора многооборотный подстроечник такого же номинала и подбираю положение когда стрелка отклоняется до крайней отметки.