Поиск

суббота, 8 декабря 2018 г.

Полезные ссылки для автомобилиста в Беларуси

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

Автоматическая фиксация превышения скорости


Проверить есть ли штраф за превышение скорости, зафиксированный автоматическими камерами, можно тут.


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

Договор обязательного страхования


Проверить наличие действующего договора обязательного страхования можно тут.


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

ГосТехОсмотр


Проверить наличие пройденного техосмотра можно тут.


Пока не могу придумать зачем это может понадобиться, но возможно кому-то пригодится.

Парковки в Минске


Ну и до кучи ссылка на проверку нарушений парковки в Минске.

воскресенье, 25 ноября 2018 г.

WARN src/common.c: unknown chip id! 0xe0042000

Я уже описывал программирование контроллера stm32f103c8t6 в Arduino IDE через stm32duino bootloader. Теперь пробую залить простенький скетч через программатор ST-Link/V2.

Сперва столкнулся с отсутствием прав доступа на usb устройство программатора. Решается одной строкой в правилась UDEV

ATTRS{idProduct}=="3748", ATTRS{idVendor}=="0483", MODE="0660", GROUP="plugdev", ENV{ID_MM_DEVICE_IGNORE}="1", ENV{UDISKS_PRESENTATION_HIDE}="1", ENV{UDISKS_IGNORE}="1"

В еще не распакованную плату скетч залился сразу без проблем, но залить этот же скетч в плату с загрузчиком stm32duino bootloader не получилось

Sketch uses 14300 bytes (21%) of program storage space. Maximum is 65536 bytes.
Global variables use 3088 bytes (15%) of dynamic memory, leaving 17392 bytes for local variables. Maximum is 20480 bytes.
USB Status [unknown]
2018-11-25T17:02:34 INFO src/usb.c: -- exit_dfu_mode
2018-11-25T17:02:34 INFO src/common.c: Loading device parameters....
2018-11-25T17:02:34 WARN src/common.c: unknown chip id! 0xe0042000
USB Status [unknown]
Waiting for tty device  

 should now be available.

Ошибка WARN src/common.c: unknown chip id! 0xe0042000. Погуглил и нашел рецепт как это вылечить.

Нужно установить перемычку BOOT0 в High


и выполнить команду st-flash erase

$ cd .arduino15/packages/stm32duino/tools/stm32tools/2018.11.11/linux/stlink

$ ./st-info --probe
Found 1 stlink programmers
 serial: 483f6f06653f515321402467
openocd: "\x48\x3f\x6f\x06\x65\x3f\x51\x53\x21\x40\x24\x67"
  flash: 65536 (pagesize: 1024)
   sram: 20480
 chipid: 0x0410
  descr: F1 Medium-density device

$ ./st-info --chipid
0x0410

$ ./st-flash erase
2018-11-25T17:09:18 INFO src/common.c: Loading device parameters....
2018-11-25T17:09:18 INFO src/common.c: Device connected is: F1 Medium-density device, id 0x20036410
2018-11-25T17:09:18 INFO src/common.c: SRAM size: 0x5000 bytes (20 KiB), Flash: 0x10000 bytes (64 KiB) in pages of 1024 bytes
Mass erasing

Теперь скетч залился без проблем и во вторую плату.

Sketch uses 14300 bytes (21%) of program storage space. Maximum is 65536 bytes.
Global variables use 3088 bytes (15%) of dynamic memory, leaving 17392 bytes for local variables. Maximum is 20480 bytes.
USB Status [unknown]
2018-11-25T17:26:53 INFO src/usb.c: -- exit_dfu_mode
2018-11-25T17:26:53 INFO src/common.c: Loading device parameters....
2018-11-25T17:26:53 INFO src/common.c: Device connected is: F1 Medium-density device, id 0x20036410
2018-11-25T17:26:53 INFO src/common.c: SRAM size: 0x5000 bytes (20 KiB), Flash: 0x10000 bytes (64 KiB) in pages of 1024 bytes
2018-11-25T17:26:53 INFO src/common.c: Attempting to write 14300 (0x37dc) bytes to stm32 address: 134217728 (0x8000000)

Flash page at addr: 0x08000000 erased
Flash page at addr: 0x08000400 erased
Flash page at addr: 0x08000800 erased
Flash page at addr: 0x08000c00 erased
Flash page at addr: 0x08001000 erased
Flash page at addr: 0x08001400 erased
Flash page at addr: 0x08001800 erased
Flash page at addr: 0x08001c00 erased
Flash page at addr: 0x08002000 erased
Flash page at addr: 0x08002400 erased
Flash page at addr: 0x08002800 erased
Flash page at addr: 0x08002c00 erased
Flash page at addr: 0x08003000 erased2018-11-25T17:26:53 INFO src/common.c: Finished erasing 14 pages of 1024 (0x400) bytes
2018-11-25T17:26:53 INFO src/common.c: Starting Flash write for VL/F0/F3 core id
2018-11-25T17:26:53 INFO src/common.c: Successfully loaded flash loader in sram

Flash page at addr: 0x08003400 erased

  0/13 pages written
  1/13 pages written
  2/13 pages written
  3/13 pages written
  4/13 pages written
  5/13 pages written
  6/13 pages written
  7/13 pages written
  8/13 pages written
  9/13 pages written
 10/13 pages written
 11/13 pages written2018-11-25T17:26:54 INFO src/common.c: Starting verification of write complete

 12/13 pages written
 13/13 pages written2018-11-25T17:26:54 INFO src/common.c: Flash written and verified! jolly good!

USB Status [unknown]
Waiting for tty device

Перенос системы с HDD на SSD меньшего размера

Потребовалось заменить HDD на SSD в ноутбуке. Проблема заключается в том, что на HDD размер разделов превышает объем SSD.

Размер SSD 240G (223G если быть точным)

root@0:~# fdisk -l /dev/sda
Disk /dev/sda: 223.6 GiB, 240057409536 bytes, 468862128 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

а размер HDD 500G, но используется примерно 233G, что на 10G больше емкости SSD диска

 
root@0:~# fdisk -l /dev/sdb
Disk /dev/sdb: 465.8 GiB, 500107862016 bytes, 976773168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x0003bb0b

Device     Boot  Start       End   Sectors   Size Id Type
/dev/sdb1  *      2048    487423    485376   237M 83 Linux
/dev/sdb2       487424 488396799 487909376 232.7G 83 Linux

На HDD используется LVM поверх LUKS и просто изменить размер второго раздела не получится. Сниму образ диска, чтобы уже в нем безопасно изменить размер разделов. Если что-то пойдет не так, то достаточно поставить HDD обратно и продолжить работу.

root@0:~# mount -t cifs //192.168.1.1/share /mnt -o guest
root@tty1:~# pv -s 240g -S < /dev/sdb > /mnt/hdd_backup.bin bs=1M count=240000
 101GiB 0:44:14 [38.1MiB/s] [==============>                 ] 43% ETA 0:59:07

Для изменения размера разделов буду использовать инструкцию Resizing LVM-on-LUKS из wiki ArchLinux. Уменьшать размер разделов нужно в определенном порядке (файловая система -> логический том LVM -> физический том LVM -> размер данных LUKS -> раздел LUKS). Если изменить порядок или что-то пропустить, то можно превратить данные в кашу.

Устанавливаю в ноутбук SSD, а старый HDD подключаю через USB-SATA адаптер (/dev/sdb). Загружаюсь с LiveCD (Finnix), монтирую по сети домашнюю файлопомойку и делаю образ HDD диска (только размер данных с небольшим запасом)

root@0:~# mount -t cifs //192.168.1.50/share /mnt -o guest
root@0:~# pv -s 250G -S < /dev/sdb > /mnt/hdd_backup.bin

Теперь старый HDD можно отключить и убрать на полку.

root@0:~# eject /dev/sdb

Подключаю файл с образом диска и создаю устройства для каждого раздела

root@0:~# losetup --find --show /mnt/hdd_backup.bin
/dev/loop1

root@0:~# kpartx -a /dev/loop1

Открываю LUKS раздел и проверяю его статус

root@0:~# cryptsetup luksOpen /dev/mapper/loop1p2 loop1_crypt
Enter passphrase for /dev/mapper/loop1p2:

root@0:~# cryptsetup status loop1_crypt
/dev/mapper/loop1_crypt is active.
  type:    LUKS1
  cipher:  aes-xts-plain64
  keysize: 512 bits
  device:  /dev/mapper/loop1p2
  offset:  4096 sectors
  size:    487905280 sectors
  mode:    read/write

Теперь сканирую доступность групп томов LVM

root@0:~# vgscan 
  Reading all physical volumes.  This may take a while...
  Found volume group "steshan" using metadata type lvm2

Искомая группа 'steshan' нашлась - активируем ее

root@0:~# vgchange -ay
  3 logical volume(s) in volume group "steshan" now active

Теперь блочные устройства выглядят правильно и можно приступать к изменению размера

root@0:~# lsblk /dev/loop1 
NAME                 MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
loop1                  7:1    0   240G  0 loop  
├─loop1p1            254:0    0   237M  0 part  
└─loop1p2            254:1    0 232.7G  0 part  
  └─loop1_crypt      254:2    0 232.7G  0 crypt 
    ├─steshan-rootfs 254:3    0    14G  0 lvm   
    ├─steshan-swap   254:4    0     6G  0 lvm   
    └─steshan-home   254:5    0 186.3G  0 lvm

Но сначала нужно проверить файловые системы на наличие ошибок

root@0:~# fsck -Cf /dev/steshan/rootfs 
fsck from util-linux 2.26.2
e2fsck 1.42.13 (17-May-2015)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure                                           
Pass 3: Checking directory connectivity                                        
Pass 4: Checking reference counts
Pass 5: Checking group summary information                                     
/dev/mapper/steshan-rootfs: 212139/915712 files (0.5% non-contiguous), 1989447/3661824 blocks

root@0:~# fsck -Cf /dev/steshan/home 
fsck from util-linux 2.26.2
e2fsck 1.42.13 (17-May-2015)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure                                           
Pass 3: Checking directory connectivity                                        
Pass 4: Checking reference counts
Pass 5: Checking group summary information                                     
/dev/mapper/steshan-home: 106361/12214272 files (2.2% non-contiguous), 24456249/48827392 blocks

Ошибок нет, уменьшаю размер файловой системы /home до 140G

root@0:~# resize2fs -p /dev/steshan/home 140G
resize2fs 1.42.13 (17-May-2015)
Resizing the filesystem on /dev/steshan/home to 36700160 (4k) blocks.
Begin pass 2 (max = 5761427)
Relocating blocks             XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Begin pass 3 (max = 1491)
Scanning inode table          XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Begin pass 4 (max = 8200)
Updating inode references     XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
The filesystem on /dev/steshan/home is now 36700160 (4k) blocks long.

На всякий случай проверю целостность еще раз

root@0:~# fsck -Cf /dev/steshan/home 
fsck from util-linux 2.26.2
e2fsck 1.42.13 (17-May-2015)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure                                           
Pass 3: Checking directory connectivity                                        
Pass 4: Checking reference counts
Pass 5: Checking group summary information                                     
/dev/mapper/steshan-home: 106361/9175040 files (2.3% non-contiguous), 24265588/36700160 blocks

Деактивирую логический том на котором расположена файловая система /home и уменьшаю его размер до 141G (на 1G больше размера файловой системы)

root@0:~# lvchange -an /dev/steshan/home

root@0:~# lvresize -L 141G /dev/steshan/home 
  Size of logical volume steshan/home changed from 186.26 GiB (47683 extents) to 141.00 GiB (36096 extents).
  Logical volume home successfully resized

Теперь можно уменьшить размер физического тома до 162G (с большим запасом)

root@0:~# pvs
  PV                      VG      Fmt  Attr PSize   PFree 
  /dev/mapper/loop1_crypt steshan lvm2 a--  232.65g 71.68g

root@0:~# pvresize --setphysicalvolumesize 162G /dev/mapper/loop1_crypt 
  /dev/mapper/loop1_crypt: cannot resize to 42239 extents as later ones are allocated.
  0 physical volume(s) resized / 1 physical volume(s) not resized

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


root@0:~# pvmove --alloc anywhere /dev/mapper/loop1_crypt:41472-59557
  /dev/mapper/loop1_crypt: Moved: 16.0%
  /dev/mapper/loop1_crypt: Moved: 48.4%
  /dev/mapper/loop1_crypt: Moved: 75.6%
  /dev/mapper/loop1_crypt: Moved: 100.0%

Прошло без ошибок и теперь можно попробовать уменьшить размер физического тома снова.

root@0:~# pvresize --setphysicalvolumesize 162G /dev/mapper/loop1_crypt
  Physical volume "/dev/mapper/loop1_crypt" changed
  1 physical volume(s) resized / 0 physical volume(s) not resized

Физический том уменьшил, а теперь пора изменить размер области, которую использует cryptsetup (163 * 1024 * 1024 * 1024 / 512 = 341835776). Ее итоговый размер должен быть 341835776 сектор.

root@0:~# cryptsetup -b 341835776 resize loop1_crypt

В последнюю очередь уменьшаем размер раздела

root@0:~# parted /dev/loop1
GNU Parted 3.2
Using /dev/loop1
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted)

(parted) unit s

(parted) resizepart 2                                                     
End?  [318359375s]? 341835776s                                            
(parted) print                                                            
Model: Loopback device (loopback)
Disk /dev/loop1: 503316480s
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags: 

Number  Start    End         Size        Type     File system  Flags
 1      2048s    487423s     485376s     primary  ext4         boot
 2      487424s  341835776s  341348353s  primary

(parted)

Изменение размера завершено, теперь можно отключить LVM и закрыть LUKS. Заключительным этапом станет копирование данных из образа на SSD диск.

root@0:~# vgchange -an
  0 logical volume(s) in volume group "steshan" now active

root@0:~# cryptsetup luksClose loop1_crypt

root@0:~# kpartx -d /dev/loop1

root@0:~# pv -s 180g -S < /dev/loop1 > /dev/sda

Загрузка с SSD прошла без ошибок. Аналогично делается изменение в большую сторону чтобы максимально использовать емкость SSD. Но порядок будет обратный.

воскресенье, 21 октября 2018 г.

Немного украсил страницу репозитария

На mozilla.debian.net подсмотрел идею динамической инстукции по настройке APT в зависимости от выбранной версии дистрибутива. Сделал себе такую же.


Теперь достаточно правильно выбрать свою версию дистрибутива и страница выдаст нужную последовательность команд. Новичкам должно стать попроще.

Еще сделал алиас для ubuntu, чтобы в url было разделение на /debian и /ubuntu. Хотя в остальном никакой разницы нет.

воскресенье, 7 октября 2018 г.

Пересобрал пакеты PHP 7.1.20 и 7.2.9 для Debian Stretch

По-умолчанию в Debian Stretch поставляется PHP версии 7.0.30, но свежие версии Laravel требуют как минимум PHP версии 7.1.3. Чтобы решить эту проблему я пересобрал пакеты PHP 7.1.20 и 7.2.9 для Debian Stretch (только amd64). Никаких модицикаций делать не пришлось, только добавил суффикс "~stretch1" к версии пакета.

Найти их можно в секции backports моего репозитария или скачать напрямую (7.1.20 и 7.2.9). Все три версии можно установить одновременно, но для mod_php нужно включать нужную версию явно.

воскресенье, 30 сентября 2018 г.

Решил проблему с медленным запуском jenkins slave на Raspberry PI 3

Продолжение истории с jenkins, предыдущие посты тут и тут.

После отката версии jenkins slave с 3.25 до 3.15 решил запостить баг. Нашел уже существующий JENKINS-53810, который похож по описанию на мою проблему. Попробовал предложенное решение, но мне оно не помогло.

Попутно гуглил об использовании jenkins slave на Raspberry PI и наткнулся на эту статью. В ней использовалась java от Oracle, а не OpenJDK, которая доступна в репозитариях Raspbian.

Пробую установить jdk для arm с сайта Oracle. Скачиваю файл jdk-8u181-linux-arm32-vfp-hflt.tar.gz (Linux ARM 32 Hard Float ABI) и заливаю его на raspberry


Теперь распаковываю архив в домашнюю директорию пользователя jenkins

$ cd /home/jenkins
$ tar -xzf /tmp/jdk-8u181-linux-arm32-vfp-hflt.tar.gz
$ ln -s jdk1.8.0_181 jdk
$ /home/jenkins/jdk/bin/java -version
java version "1.8.0_181"
Java(TM) SE Runtime Environment (build 1.8.0_181-b13)
Java HotSpot(TM) Client VM (build 25.181-b13, mixed mode)

Пробую для начала запустить slave из консоли

$ cat | /home/jenkins/jdk/bin/java -jar remoting.jar -workDir /home/jenkins

Прошло не больше 25 секунд, но slave уже отрапортовал о готовности! Стал разбираться в чем же разница между java от Oracle и OpenJDK. Заметил в выводе упоминание mixed или interpreted mode и различные названия java машин (OpenJDK Zero / HotSpot). Дальнейшее изучение вопроса привело к находке еще одного варианта jvm - JamVM, которая активируется ключем "-jamvm".

Пробую запустить jenkins slave через эту машину

$ cat | java -jamvm -jar remoting.jar -workDir /home/jenkins

Запуск занял примерно 2 минуты 30 секунд. Не так быстро как у HotSpot от Oracle, но и намного быстрее чем OpenJDK Zero.

Сравнение вывода версий OpenJDK Zero, JamVM и HotSpot

OpenJDK Zero
 
$ java -version
openjdk version "1.8.0_40-internal"
OpenJDK Runtime Environment (build 1.8.0_40-internal-b04)
OpenJDK Zero VM (build 25.40-b08, interpreted mode)

JamVM
 
$ java -jamvm -version
openjdk version "1.8.0_40-internal"
OpenJDK Runtime Environment (build 1.8.0_40-internal-b04)
JamVM (build 2.0.0, inline-threaded interpreter with stack-caching)

HotSpot
 
$ /home/jenkins/jdk/bin/java -version
java version "1.8.0_181"
Java(TM) SE Runtime Environment (build 1.8.0_181-b13)
Java HotSpot(TM) Client VM (build 25.181-b13, mixed mode)

Почитать о mixed, compiled, interpreted режимах компилятора jvm и флагах -Xint, -Xcomp, -Xmixed можно тут.

Откатил версию jenkins agent с 3.25 до 3.15 на Raspberry PI

Это продолжение истории с медленным запуском Jenkins агента на Raspberry PI.

Похоже я нашел версию Jenkins агента, которая успевает запуститься на Raspberry PI 3 за три минуты. Все версии агента после 3.15 стартуют дольше 5 минут. Я не мерял сколько стартует каждая из них отдельно, но 3.25 запускается примерно 15 минут.

Я не нашел правильного способа указать версию агента для каждой ноды и просто вставил костыль в виде "wget --no-verbose -O /home/jenkins/remoting.jar https://repo.jenkins-ci.org/public/org/jenkins-ci/main/remoting/3.15/remoting-3.15.jar && " (без кавычек) в параметр Prefix Start Agent Command в настройках ноды.

Теперь старт занимает меньше 3 минут

[09/30/18 12:12:27] [SSH] Checking java version of java
[09/30/18 12:12:28] [SSH] java -version returned 1.8.0_40-internal.
[09/30/18 12:12:28] [SSH] Starting sftp client.
[09/30/18 12:12:28] [SSH] Copying latest remoting.jar...
[09/30/18 12:12:28] [SSH] Copied 776,265 bytes.
Expanded the channel window size to 4MB
[09/30/18 12:12:28] [SSH] Starting agent process: wget -qO /home/jenkins/remoting.jar https://repo.jenkins-ci.org/public/org/jenkins-ci/main/remoting/3.15/remoting-3.15.jar && cd "/home/jenkins" && java  -jar remoting.jar -workDir /home/jenkins
Sep 30, 2018 12:12:45 PM org.jenkinsci.remoting.engine.WorkDirManager initializeWorkDir
INFO: Using /home/jenkins/remoting as a remoting work directory
Both error and output logs will be printed to /home/jenkins/remoting
<===[JENKINS REMOTING CAPACITY]===>channel started
Remoting version: 3.15
This is a Unix agent
Evacuated stdout
Agent successfully connected and online

В описании к версии 3.16 на первый взгляд ничего такого, что может тормозить запуск на 10 минут, нету.

суббота, 29 сентября 2018 г.

Professional Cloud Architect

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

Так и получилось с Google Cloud Certified - Professional Cloud Architect.

 

Подготовка заняла около месяца по 3-4 часа вечером, но стоит упомянуть что у меня уже есть два года с Amazon Web Services (AWS) и многие вещи оказались знакомыми. Закончил специализацию Architecting with Google Cloud Platform от Coursera и проштудировал материалы, которые порекомендовали коллеги.

Особенно рекомендую пройти Google Certified Professional Cloud Architect - Part 3 от LinuxAcademy. Первые две части я пропустил, т.к. они пересекаются с Coursera а времени у меня было немного. Практическая часть специализации Coursera реализована через Qwiklabs - на каждую "лабу" дают в раза два-три раза больше времени, чем нужно для ее выполнения и в оставшееся время можно поиграться с GCP (есть ограничение по ресурсам).

Однозначно нужно прочесть Site Reliability Engineering - How Google Runs Production Systems и полистать официальную документацию. Стоит посмотреть сайт gcp.solutions и особенно разделы пересекающиеся с case studies.

четверг, 27 сентября 2018 г.

Обновление BIOS до версии A22 на Dell Latitude E6430

Ноутбук жены изредка чудит. Включается, затем несколько секунд показывает логотип Dell и выключается. После повторного включения все проходит нормально. Если поторопиться, то успеваю зайти в настройки BIOS перед выключением. При таком поведении в логе BIOS появляется запись "Power Off - AFS2 force off". В процессе работы проблем не бывает.

Вчера снова наткнулся на выключение ноутбука и полез на сайт Dell проверить появилась ли новая версия BIOS. Оказывается ее выложили еще в конце апреля:
  • Updated Intel ME Firmware to address security advisories INTEL-SA-00086 (CVE-2017-5711 & CVE-2017-5712) & INTEL-SA-00101(CVE-2017-13077, CVE-2017-13078 & CVE-2017-13080)
  • Updated to the latest CPU microcode to address CVE-2017-5715 and associated Intel Reboot issue.
Добавил эту версию в образ диска с FreeDOS и залил в ноутбук (сейчас в образе есть версии A16, A17, A18, A20, A21 и A22). Заодно сбросил настройки на дефолтные.

Посмотрю как оно дальше будет.

суббота, 22 сентября 2018 г.

Jenkins slave стал запускаться дольше 5 минут на Raspberry PI 3

После обновления плагинов в Jenkins перестал запускаться агент на Raspberry PI 3. Попробовал увеличить таймаут до 5 минут, но это не помогло

[09/22/18 19:23:36] [SSH] Checking java version of java
[09/22/18 19:23:37] [SSH] java -version returned 1.8.0_40-internal.
[09/22/18 19:23:37] [SSH] Starting sftp client.
[09/22/18 19:23:37] [SSH] Copying latest remoting.jar...
[09/22/18 19:23:37] [SSH] Copied 776,265 bytes.
Expanded the channel window size to 4MB
[09/22/18 19:23:37] [SSH] Starting agent process: cd "/home/jenkins" && java  -jar remoting.jar -workDir /home/jenkins
Sep 22, 2018 7:23:53 PM org.jenkinsci.remoting.engine.WorkDirManager initializeWorkDir
INFO: Using /home/jenkins/remoting as a remoting work directory
Both error and output logs will be printed to /home/jenkins/remoting
ERROR: null
java.util.concurrent.CancellationException
 at java.util.concurrent.FutureTask.report(FutureTask.java:121)
 at java.util.concurrent.FutureTask.get(FutureTask.java:192)
 at hudson.plugins.sshslaves.SSHLauncher.launch(SSHLauncher.java:904)
 at hudson.slaves.SlaveComputer$1.call(SlaveComputer.java:294)
 at jenkins.util.ContextResettingExecutorService$2.call(ContextResettingExecutorService.java:46)
 at jenkins.security.ImpersonatingExecutorService$2.call(ImpersonatingExecutorService.java:71)
 at java.util.concurrent.FutureTask.run(FutureTask.java:266)
 at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
 at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
 at java.lang.Thread.run(Thread.java:748)
[09/22/18 19:28:36] Launch failed - cleaning up connection
Slave JVM has not reported exit code. Is it still running?
[09/22/18 19:28:36] [SSH] Connection closed.

Зашел по SSH и прицепился к процессу java через strace

$ sudo strace -fF -p 10245
...
[pid 10245] futex(0x76380044, FUTEX_WAIT_BITSET_PRIVATE, 1, {4888, 501190012}, ffffffff) = -1 ETIMEDOUT (Connection timed out)
[pid 10245] futex(0x76380028, FUTEX_WAKE_PRIVATE, 1) = 0
[pid 10245] clock_gettime(CLOCK_MONOTONIC, {4888, 501776999}) = 0
[pid 10245] clock_gettime(CLOCK_MONOTONIC, {4888, 502077571}) = 0
[pid 10245] clock_gettime(CLOCK_MONOTONIC, {4888, 502381685}) = 0
[pid 10245] clock_gettime(CLOCK_MONOTONIC, {4888, 502568039}) = 0
[pid 10245] futex(0x76380044, FUTEX_WAIT_BITSET_PRIVATE, 1, {4888, 552568039}, ffffffff) = -1 ETIMEDOUT (Connection timed out)
[pid 10245] futex(0x76380028, FUTEX_WAKE_PRIVATE, 1) = 0
[pid 10245] clock_gettime(CLOCK_MONOTONIC, {4888, 553154922}) = 0
[pid 10245] clock_gettime(CLOCK_MONOTONIC, {4888, 553459713}) = 0
[pid 10245] clock_gettime(CLOCK_MONOTONIC, {4888, 553807785}) = 0
[pid 10245] clock_gettime(CLOCK_MONOTONIC, {4888, 553995337}) = 0
[pid 10245] futex(0x76380044, FUTEX_WAIT_BITSET_PRIVATE, 1, {4888, 603995337}, ffffffff) = -1 ETIMEDOUT (Connection timed out)
[pid 10245] futex(0x76380028, FUTEX_WAKE_PRIVATE, 1) = 0
[pid 10245] clock_gettime(CLOCK_MONOTONIC, {4888, 604585865}) = 0
[pid 10245] clock_gettime(CLOCK_MONOTONIC, {4888, 604886125}) = 0
[pid 10245] clock_gettime(CLOCK_MONOTONIC, {4888, 605186854}) = 0
[pid 10245] clock_gettime(CLOCK_MONOTONIC, {4888, 605490238}) = 0
[pid 10245] futex(0x76380044, FUTEX_WAIT_BITSET_PRIVATE, 1, {4888, 655490238}, ffffffff) = -1 ETIMEDOUT (Connection timed out)
[pid 10245] futex(0x76380028, FUTEX_WAKE_PRIVATE, 1) = 0
[pid 10245] clock_gettime(CLOCK_MONOTONIC, {4888, 656076704}) = 0
[pid 10245] clock_gettime(CLOCK_MONOTONIC, {4888, 656386131}) = 0
[pid 10245] clock_gettime(CLOCK_MONOTONIC, {4888, 656688214}) = 0
[pid 10245] clock_gettime(CLOCK_MONOTONIC, {4888, 656992067}) = 0
[pid 10245] futex(0x76380044, FUTEX_WAIT_BITSET_PRIVATE, 1, {4888, 706992067}, ffffffff) = -1 ETIMEDOUT (Connection timed out)
[pid 10245] futex(0x76380028, FUTEX_WAKE_PRIVATE, 1) = 0
[pid 10245] clock_gettime(CLOCK_MONOTONIC, {4888, 707577075}) = 0
[pid 10245] clock_gettime(CLOCK_MONOTONIC, {4888, 707885199}) = 0
[pid 10245] clock_gettime(CLOCK_MONOTONIC, {4888, 708183740}) = 0
[pid 10245] clock_gettime(CLOCK_MONOTONIC, {4888, 708487542}) = 0
[pid 10245] futex(0x76380044, FUTEX_WAIT_BITSET_PRIVATE, 1, {4888, 758487542}, ffffffff) = -1 ETIMEDOUT (Connection timed out)
[pid 10245] futex(0x76380028, FUTEX_WAKE_PRIVATE, 1) = 0
[pid 10245] clock_gettime(CLOCK_MONOTONIC, {4888, 759065257}) = 0
[pid 10245] clock_gettime(CLOCK_MONOTONIC, {4888, 759258903}) = 0
[pid 10245] clock_gettime(CLOCK_MONOTONIC, {4888, 759556402}) = 0
[pid 10245] clock_gettime(CLOCK_MONOTONIC, {4888, 759863277}) = 0

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

Попробовал запустить агент из консоли, чтобы посмотреть сколько на самом деле занимает его запуск

$ cat | java -jar agent.jar -workDir /tmp/jenkins 
Sep 22, 2018 7:55:55 PM org.jenkinsci.remoting.engine.WorkDirManager initializeWorkDir
INFO: Using /tmp/jenkins/remoting as a remoting work directory
Both error and output logs will be printed to /tmp/jenkins/remoting
<===[JENKINS REMOTING CAPACITY]===>

Примерно через 15 минут появился маркер готовности от агента. Это слишком много, т.к. раньше агент запускался за минуту-две максимум. Пока выставил таймаут на 30 минут и агент подключился

[09/22/18 20:31:45] [SSH] Checking java version of java
[09/22/18 20:31:45] [SSH] java -version returned 1.8.0_40-internal.
[09/22/18 20:31:45] [SSH] Starting sftp client.
[09/22/18 20:31:45] [SSH] Copying latest remoting.jar...
[09/22/18 20:31:45] [SSH] Copied 776,265 bytes.
Expanded the channel window size to 4MB
[09/22/18 20:31:45] [SSH] Starting agent process: cd "/home/jenkins" && java  -jar remoting.jar -workDir /home/jenkins
Sep 22, 2018 8:32:01 PM org.jenkinsci.remoting.engine.WorkDirManager initializeWorkDir
INFO: Using /home/jenkins/remoting as a remoting work directory
Both error and output logs will be printed to /home/jenkins/remoting
<===[JENKINS REMOTING CAPACITY]===>channel started
Remoting version: 3.25
This is a Unix agent
Evacuated stdout
Agent successfully connected and online

суббота, 25 августа 2018 г.

Сделать файл выполняемым в Git

По-умолчанию Git не сохраняет права доступа на файлы, но есть возможность сделать отдельный файл исполняемым

$ git add script.sh

$ git ls-files --stage script.sh
100644 9f3f770bfcccad3d62d2e2d08b077469ef3722fa 0       script.sh

$ git update-index --chmod=+x script.sh

$ git ls-files --stage script.sh
100755 9f3f770bfcccad3d62d2e2d08b077469ef3722fa 0       script.sh

$ git commit -m 'Executable script'
[master (root-commit) 1cf26b3] Executable script
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100755 script.sh

среда, 22 августа 2018 г.

Монтирование EFS в кластере AWS ECS

Есть несколько способов смонтировать EFS в ECS кластере:
  • монтировать EFS на ноде кластера из cloud-init/puppet/chef/ansible/etc и делать bind mount в контейнер при старте (придется монтировать EFS на каждой ноде кластера где может запуститься контейнер)
  • монтировать EFS внутри контейнера контейнера (требует privileged для контейнера, т.к. монтирование файловой системы зависит от CAP_SYS_ADMIN)
  • использовать EFS в качестве docker volume (вроде появилось начиная с docker api 1.21, но я точно не уверен)
Хочу подробнее остановиться на последнем варианте, т.к. на мой взгляд он наиболее универсальный, но требует относительно свежий docker daemon и ecs-agent.

Нужно описать volume в TaskDefinition используя dockerVolumeConfiguration в секции Volumes[1]

"TaskDefinition": {
  "Type": "AWS::ECS::TaskDefinition",
  "Properties": {
    "Volumes": [
      {
        "name": "efs",
        "dockerVolumeConfiguration": {
          "scope": "task",
          "driver": "local",
          "driverOpts": {
            "type": "nfs",
            "device": ":/",
            "o": "addr=1.2.3.4,nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport"
          }
        }
      }
    ]
  }
}

Проблема заключается в том, что CloudFormation еще не поддерживает[2] параметр dockerVolumeConfiguration в TaskDefinition и попытка обновления стека завершается с ошибкой

18:56:27 UTC+0300UPDATE_FAILEDAWS::ECS::TaskDefinitionTaskDefinitionEncountered unsupported property dockerVolumeConfiguration

Чтоы это обойти можно создать TaskDefinition через консоль и передать ее идентификатор в стек в виде параметра.

  1. https://docs.aws.amazon.com/AmazonECS/latest/developerguide/docker-volumes.html
  2. https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ecs-taskdefinition-volumes.html
  3. https://docs.docker.com/engine/reference/commandline/volume_create/#driver-specific-options

четверг, 9 августа 2018 г.

Сломалась LDAP аутентификация после обновления GitLab

После обновления GitLab с версии 9.5.10 до 10.8.7 столкнулся с ошибкой при входе с использованием LDAP аутентификации

Could not authenticate you from Ldapmain because "Ssl connect returned=1 errno=0 state=error: certificate verify failed".

Чтобы решить эту проблему нужно отредактировать файл /etc/gitlab/gitlab.rb и добавить параметр ca_file в секции настроек LDAP

gitlab_rails['ldap_servers'] = YAML.load <<-'EOS'
  main:
    label: 'LDAP'
    ca_file: '/etc/ssl/certs/ldap-cacert.pem'

Чтобы настройки применились нужно переконфигурировать GitLab

$ sudo gitlab-ctl reconfigure

Помог этот совет с serverfault.com.

вторник, 31 июля 2018 г.

Иконка skype в трее Xfce

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



Я не знаю из-за чего это произошло и проявляется ли в других окружениях, но глаза мозолит и решил исправить.

Нашел на форумах что можно задать значение переменной XDG_CURRENT_DESKTOP равное "Unity" и иконка приходит в норму. Чтобы изменение не потерялось при обновлении пакета skypeforlinux нужно скопировать файл skypeforlinux.desktop в домашнюю директорию и изменить копию

$ skypeforlinux --shutdown
$ mkdir -p ~/.local/share/applications/
$ cp /usr/share/applications/skypeforlinux.desktop ~/.local/share/applications/
$ sed -i -e 's@^Exec=/usr/bin/skypeforlinux %U$@Exec=env XDG_CURRENT_DESKTOP=Unity /usr/bin/skypeforlinux %U@' ~/.local/share/applications/skypeforlinux.desktop
$ xdg-open ~/.local/share/applications/skypeforlinux.desktop

Теперь иконка skype в трее выглядит нормально


четверг, 26 июля 2018 г.

Рекомендуемые настройки SSL от Mozilla

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

Ну и еще раз продублирую ссылку на SSL сканер от Qualys.

суббота, 21 июля 2018 г.

Разблокировка iPod Classic

Дети покопались в настройках и случайно включили режим блокировки iPod


Если под рукой есть компьютер, то снять блокировку очень просто:
  • подключите iPod к компьютеру
  • откройте / смонтируйте его диск
  • если у вас Windows, то включите показ скрытых файлов
  • перейдите в директорию iPod_Control/device/
  • переименуйте файл _locked в unlock
  • отмонтируйте / безопасно извлеките iPod
После этого блокировка отключается.

Опробовано на iPod Video (пятое поколение), но возможно такой способ подходит для всех моделей iPod Classic и Nano.

вторник, 17 июля 2018 г.

Поддержка symlink для shared folders в VirtualBox

Есть виртуальная машина VirtualBox в которой установлен Debian Stretch и проброшена часть системного диска с рабочими файлами в виде Shared Folder которая называется Work. Но вот незадача - VirtualBox не дает создавать symlink'и в этой директории

$ cd /media/sf_Work
$ touch 1
$ ln -s 1 2
ln: failed to create symbolic link '2': Read-only file system

На serverfault нашел решение для этой проблемы

cd %ProgramFiles%\Oracle\VirtualBox

VBoxManage.exe setextradata debian VBoxInternal2/SharedFoldersEnableSymlinksCreate/Work 1

Перезапускаем виртуальную машину и VirtualBox GUI и пробуем создать symlink

$ cd /media/sf_Work
$ touch 1
$ ln -s 1 2
ln: failed to create symbolic link '2': Protocol error

Эта проблема решается запуском VirtualBox с правами администратора (кликая "Run as administrator" в контекстном меню ярлыка или установив это свойство в "Advanced" свойствах).

Теперь symlink'и создаются в shared folder Work без проблем

$ cd /media/sf_Work
$ touch 1
$ ln -s 1 2
$ ls -l 1 2
-rwxrwx--- 1 root vboxsf 0 Jul 17 17:02 1
lrwxrwx--- 1 root vboxsf 0 Jul 17 17:02 2 -> 1

четверг, 3 мая 2018 г.

Минималистичная проверка tcp порта

Частенько приходится проверять доступность того или иного ресурса в сети. Как правило достаточно убедиться что его имя резолвится в ip адрес и получается подключиться на порт. Если на хосте не установлено нету netcat, socat, nmap или telnet, то выручить может bash

$ host ya.ru
ya.ru has address 87.250.250.242
ya.ru has IPv6 address 2a02:6b8::2:242
ya.ru mail is handled by 10 mx.yandex.ru.

$ bash -c 'cat < /dev/null > /dev/tcp/ya.ru/80'

Если bash завершился без ошибок, то порт доступен.

понедельник, 2 апреля 2018 г.

Увеличение размера диска VirtualBox содержащего снапшоты

Столкнулся с нехваткой свободного места на диске при установке довольно объемного справочника на семи DVD дисках в виртуальную машину VirtualBox. Изначальный размер единственного диска виртуальной машины был 40G и я понадеялся на то, что будет устанавливаться только часть данных относящихся к русскому языку. Вместо этого я столкнулся с нехваткой свободного места на предпоследнем диске.

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

$ cd ~/vbox/win7
$ VBoxManage modifyhd win7.vdi --resize 80000
0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%
$ VBoxManage modifyhd Snapshots/\{7bab8995-fe72-4805-8863-8833068098b3\}.vdi --resize 80000
0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%
$ VBoxManage modifyhd Snapshots/\{c3250adc-b14d-433c-86d9-37987ca2a246\}.vdi --resize 80000
0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%

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

Чтобы проверить что подобное увеличение диска и снапшотов ничего не сломало пробую удалить последний снапшот.

$ VBoxManage snapshot win7 delete 37c59b83-2eac-4af8-98fc-c207bf1a4168
0%...
Progress state: NS_ERROR_OUT_OF_MEMORY
VBoxManage: error: Snapshot operation failed
VBoxManage: error: Unable to merge storage '/home/andrey/vbox/win7/win7.vdi'. Not enough free storage space
VBoxManage: error: Details: code NS_ERROR_OUT_OF_MEMORY (0x8007000e), component SessionMachine, interface IMachine
VBoxManage: error: Context: "RTEXITCODE handleSnapshot(HandlerArg*)" at line 533 of file VBoxManageSnapshot.cpp

Ошибка из-за нехватки свободного места на локальном диске. Очистить диск быстро не получится и я перекинул виртуальную машину на сервер и смонтировал директорию через gvfs:

$ gvfs-mount -a //server/share
$ mv ~/vbox/win7{,~}
$ ln -s /run/user/1000/gvfs/smb-share:server=server,share=share/tmp/win7 ~/vbox/win7
$ cd ~/vbox/win7
$ VBoxManage snapshot win7 delete 37c59b83-2eac-4af8-98fc-c207bf1a4168
0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...
Progress state: VBOX_E_FILE_ERROR
VBoxManage: error: Snapshot operation failed
VBoxManage: error: Could not merge the medium '/home/andrey/vbox/win7/Snapshots/{7bab8995-fe72-4805-8863-8833068098b3}.vdi' to '/home/andrey/vbox/win7/Snapshots/{c3250adc-b14d-433c-86d9-37987ca2a246}.vdi'.
VBoxManage: error: VD: error VERR_NET_OPERATION_NOT_SUPPORTED opening image file '/home/andrey/vbox/win7/Snapshots/{c3250adc-b14d-433c-86d9-37987ca2a246}.vdi' (VERR_NET_OPERATION_NOT_SUPPORTED)
VBoxManage: error: Details: code VBOX_E_FILE_ERROR (0x80bb0004), component MediumWrap, interface IMedium
VBoxManage: error: Context: "RTEXITCODE handleSnapshot(HandlerArg*)" at line 533 of file VBoxManageSnapshot.cpp

Тут написано, что проблема в несовместимости VirtualBox и gvfs/libsmbclient. Перемонтировал раздел через mount:

$ gvfs-mount -u smb://server/share
$ rm ~/vbox/win7
$ sudo mount -t cifs //server/share /mnt/tmp -o guest,uid=1000,gid=1000
$ ln -s /mnt/tmp/tmp/win7 ~/vbox/win7
$ VBoxManage snapshot win7 delete b6a1fbf4-b4ba-41da-8ce2-bcd861b4b67b
0%...10%...20%...30%...40%...50%...60%...70%...80%...90%...100%

Остается вернуть файлы виртуальной машины на локальный диск.

среда, 28 марта 2018 г.

Закрывается Digg Reader

Сегодня пришло письмо о том, что закрывается Digg Reader, которым я стал пользоваться после закрытия Google Reader.
Какое-то время назад я перешел на использования News в составе Nextcloud и эта новость воспринимается не так болезненно как в случае с Google Reader.

воскресенье, 11 февраля 2018 г.

XScreenSaver 5.38

Использую Xfce4 и xscreensaver в качестве блокировщика экрана. Настройки питания и энергосбережения через xfce-power-manager. С одной стороны это позволяет иметь различные настройки энергосбережения экрана в зависимости от источника питания (батарея или сеть), а с другой не возиться с настройкой heartbeat'а (xscreensaver-command -deactivate) в различных программах.

Моя проблема заключается в настройке dpmsEnabled в xscreensaver - если она выключена, то xscreensaver полностью отключает поддержку DPMS, а не прекращает управлять ее настройками.

Чтобы отучить xscreensaver трогать настройки DPMS я собираю отдельный пакет с опцией --without-dpms-ext и патчем, который чинит эту опцию

--- a/driver/prefs.h
+++ b/driver/prefs.h
@@ -27,11 +27,13 @@
 extern char *format_hack (Display *, screenhack *, Bool wrap_p);
 char *make_hack_name (Display *, const char *shell_command);

+#ifdef HAVE_DPMS_EXT
 /* From dpms.c */
 extern void sync_server_dpms_settings (Display *, Bool enabled_p,
                                        Bool dpms_quickoff_p,
                                        int standby_secs, int suspend_secs,
                                        int off_secs,
                                        Bool verbose_p);
+#endif

 #endif /* __XSCREENSAVER_PREFS_H__ */

И набор изменений относительно 5.36 из Debian Sid

diff -urNp xscreensaver-5.36/debian/patches/30_hacks_xanalogtv.patch xscreensaver-5.38/debian/patches/30_hacks_xanalogtv.patch
--- xscreensaver-5.36/debian/patches/30_hacks_xanalogtv.patch 2018-02-11 20:19:38.000000000 +0300
+++ xscreensaver-5.38/debian/patches/30_hacks_xanalogtv.patch 2018-02-11 15:11:49.333414388 +0300
@@ -2,10 +2,10 @@
 # logo-50-bad.xpm is a stripped down (64 colors) version
 # Fix for bug #304344
 #
-Index: xscreensaver-5.04/hacks/xanalogtv.c
+Index: xscreensaver-5.38/hacks/xanalogtv.c
 ===================================================================
---- xscreensaver-5.04.orig/hacks/xanalogtv.c 2006-03-31 09:21:41.000000000 +0200
-+++ xscreensaver-5.04/hacks/xanalogtv.c 2007-12-08 17:47:00.000000000 +0100
+--- xscreensaver-5.38.orig/hacks/xanalogtv.c    2018-02-11 15:07:01.202559754 +0300
++++ xscreensaver-5.38/hacks/xanalogtv.c 2018-02-11 15:08:23.705607677 +0300
 @@ -42,7 +42,7 @@
  #include "xpm-pixmap.h"
  #include "analogtv.h"
@@ -15,12 +15,12 @@ Index: xscreensaver-5.04/hacks/xanalogtv
  
  /* #define DEBUG 1 */
  /* #define USE_TEST_PATTERNS */
-@@ -170,7 +170,7 @@
-   ypos += st->ugly_font.char_h*5/2;
+@@ -172,7 +172,7 @@ update_smpte_colorbars(analogtv_input *i
  
-   analogtv_draw_xpm(st->tv, input,
--                    logo_50_xpm, xpos - 100, ypos);
-+                    logo_50_bad_xpm, xpos - 100, ypos);
+   if (! st->colorbars_only_p)
+     analogtv_draw_xpm(st->tv, input,
+-                      logo_50_xpm, xpos - 100, ypos);
++                      logo_50_bad_xpm, xpos - 100, ypos);
  
    ypos += 58;
  
diff -urNp xscreensaver-5.36/debian/xscreensaver.install.stub xscreensaver-5.38/debian/xscreensaver.install.stub
--- xscreensaver-5.36/debian/xscreensaver.install.stub 2018-02-11 20:19:38.000000000 +0300
+++ xscreensaver-5.38/debian/xscreensaver.install.stub 2018-02-11 16:08:35.060847317 +0300
@@ -2,7 +2,6 @@ usr/bin/xscreensaver
 usr/bin/xscreensaver-command
 usr/bin/xscreensaver-demo
 usr/share/applications/xscreensaver-properties.desktop
-usr/share/locale/ca/LC_MESSAGES/xscreensaver.mo
 usr/share/locale/da/LC_MESSAGES/xscreensaver.mo
 usr/share/locale/de/LC_MESSAGES/xscreensaver.mo
 usr/share/locale/es/LC_MESSAGES/xscreensaver.mo
@@ -25,7 +24,6 @@ usr/share/locale/vi/LC_MESSAGES/xscreens
 usr/share/locale/wa/LC_MESSAGES/xscreensaver.mo
 usr/share/locale/zh_CN/LC_MESSAGES/xscreensaver.mo
 usr/share/locale/zh_TW/LC_MESSAGES/xscreensaver.mo
-usr/share/locale/nb/LC_MESSAGES/xscreensaver.mo
 usr/share/man/man1/xscreensaver.1
 usr/share/man/man1/xscreensaver-command.1
 usr/share/man/man1/xscreensaver-demo.1

Забрать пакеты xscreensaver 5.38 для Debian Stretch (amd64) можно в моем репозитарии.

вторник, 6 февраля 2018 г.

Просмотр изображений с расширением HEIC в Linux

Столкнулся с проблемой просмотра фотографий с расширением HEIC. Это новый формат HEIF (High Efficiency Image Format) от Apple, которым они решили заменить JPEG. Перебрал несколько вариантов (display, eog, gimp), но ни одна из программ не знает про этот формат.

Поиск в интернете вывел на tifig. С помощью этой утилиты получилось сконвертировать фотографии в JPEG.

$ find /path/to/photos -type f -iname '*.heic' -exec ~/tmp/tifig -i '{}' -o '{}.JPG' \;
$ rename 's/.HEIC.JPG/.JPG/' *.HEIC.JPG

К слову разница в размере не в пользу JPEG:

$ ls -l IMG_0513.*
-rw-r--r-- 1 andrey andrey 1360434 Feb  6 13:11 IMG_0513.HEIC
-rw-r--r-- 1 andrey andrey 2077232 Feb  6 13:26 IMG_0513.JPG

Качество изображения оценить не могу, т.к. не могу увидеть оригинал в исходном качестве.

суббота, 13 января 2018 г.

Прошивка ESPEasy для ESP8266

Открыл для себя прошивку ESPEasy от Let's Control It для ESP8266. ESPEasy собирается с разным набором модулей и доступна для различных объемов flash памяти. Я буду заливать прошивку в ESP-12S, который купил ранее и мне нужно узнать какой объем flash памяти установлен на моих чипах.

$ ./esptool.py --port /dev/ttyUSB0 --baud 115200 flash_id
Connecting...
Manufacturer: ef
Device: 4016

Согласно информации проекта CoreBoot в модуле установлен чип Winbond W25Q32, содержащий 4MB памяти.

Если проверить модули ESP-01, с которых я начинал знакомство с ESP8266, то выдает следуещее:

$ ./esptool.py --port /dev/ttyUSB0 --baud 115200 flash_id
Connecting...
Manufacturer: c8
Device: 4013

Если верить CoreBoot, то должна быть установлена GigaDevice GD25Q40, и в подтверждение тому на плате стоит GD25Q41BT, имеющая объем flash памяти 4Mb или 512kB.

Скачать прошивку с GitHub можно здесь. Я брал ESP_Easy_v2.0-20180113_test_ESP8266_4096.bin чтобы была поддержка датчика углекислого газа MH-Z19.

Для заливки прошивки можно использовать esptool из Arduino или esptool.py. Я использую первый из них.

$ ~/.arduino15/packages/esp8266/tools/esptool/0.4.8/esptool -vv -cd nodemcu -cb 115200 -cp /dev/ttyUSB0 -ca 0x00000 -cf ~/tmp/ESP_Easy_v2.0-20180113_test_ESP8266_4096.bin
esptool v0.4.8 - (c) 2014 Ch. Klippel
 setting board to nodemcu
 setting baudrate from 115200 to 115200
 setting port from /dev/ttyUSB0 to /dev/ttyUSB0
 setting address from 0x00000000 to 0x00000000
 espcomm_upload_file
 espcomm_upload_mem
opening port /dev/ttyUSB0 at 115200
 tcgetattr
 tcsetattr
 serial open
opening bootloader
resetting board
trying to connect
 setting character timeout 0
 done
 setting character timeout 1
 done
 espcomm_send_command: sending command header
 espcomm_send_command: sending command payload
trying to connect
 setting character timeout 0
 done
 setting character timeout 1
 done
 espcomm_send_command: sending command header
 espcomm_send_command: sending command payload
 espcomm_send_command: receiving 2 bytes of data
 espcomm_send_command: receiving 2 bytes of data
 espcomm_send_command: receiving 2 bytes of data
 espcomm_send_command: receiving 2 bytes of data
 espcomm_send_command: receiving 2 bytes of data
 espcomm_send_command: receiving 2 bytes of data
 espcomm_send_command: receiving 2 bytes of data
 espcomm_send_command: receiving 2 bytes of data
Uploading 566528 bytes from to flash at 0x00000000
 erasing flash
 size: 08a500 address: 000000
 first_sector_index: 0
 total_sector_count: 139
 head_sector_count: 16
 adjusted_sector_count: 123
 erase_size: 07b000
 espcomm_send_command: sending command header
 espcomm_send_command: sending command payload
 setting timeout 15000
 setting character timeout 150
 done
 setting timeout 1
 setting character timeout 1
 done
 espcomm_send_command: receiving 2 bytes of data
 writing flash
..................................................
starting app without reboot
 espcomm_send_command: sending command header
 espcomm_send_command: sending command payload
 espcomm_send_command: receiving 2 bytes of data
closing bootloader

После сброса в сети появится новая точка доступа с именем "ESP_Easy_0" (пароль "configesp"). При подключении к ней телефон определил captivate portal в котором предлагается настроить подключение к WiFi.

К одному из модулей у меня подключены BME280 и MH-Z19, а ко второму SI7021. Оба датчика показывают очень близкие значения температуры и влажности, когда находятся рядом, но BME280 примерно в два раза дороже.

К обоим модулям подключены OLED экраны разрешением 128x64 на базе контроллера SSD1306. Данные передаются по MQTT в Mosquitto из которого Munin забирает их для построения графиков. В дальнейшем хочу перейти на что-то вроде MajorDomo, OpenHAD или Domoticz.


Для защиты от выгорания экран включается на 15 секунд по нажатию на кнопку flash (подключена к gpio-0).


На экран выводятся значения температуры, влажности и концентрации углекислого газа в воздухе.

Основная информация по работе прошивки.


Настройки прошивки: название юнита, настройки WiFi, статическая конфигурация сети (если нужно).


Настройки контроллеров. Я использую MQTT брокер Mosquitto.


Настройки выходов при загрузке.


Конфигурация подключенных датчиков. На этом модуле сконфигурирован экран SSD1306, BME280 и MH-Z19.


Нотификации я не использую, т.к. для этого у меня есть Nagios и Munin.


Раздел с инструментами. Из интересного /log и /json. Оба можно использовать для мониторинга устройства.


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