In our lab we are using a lot of different DUTs and most of them are connected via PDUs for the remote power cycle. The biggest part of PDUs are APC 7820B or similar (from APC). APC is controllable via SNMP and everything is so far, so good.

Couple of years ago I have got Keil Systems EnviroBot PDU (not produced anymore) from e-waste, which is 12 ports and quite an interesting device in a sense that it's accessible via HTTP only.

After a few hours of experimenting (yeah, I'm not a ninja in HTML/XML + shell) I have nailed it down to make it accessible via our scripts that in their turn are for users logged via SSH.

So, to show the state of the certain port:

curl -s -L --noproxy '*' -o "<FILE>" "http://<ADDRESS>/power.cgi?mdu=0"
xmllint --xpath "//tr[td/input[@name=\"switch<PORT>\"]]/td[3]/text()" --html "<FILE>" 2>/dev/null

Turning OFF...

curl -s -L --noproxy '*' -o /dev/null -d switch<PORT>="1" -d d12="1" -d B1="Submit" http://<ADDRESS>/out_control.cgi

...and turning ON:

curl -s -L --noproxy '*' -o /dev/null -d switch<PORT>="1" -d d12="0" -d B1="Submit" http://<ADDRESS>/out_control.cgi

Couple of weeks ago, due to some changes, we have ordered another PDU from IntelliNet, which appears a new device also accessible via HTTP-only.

For it it looks slightly different.

State:

curl -s -L --noproxy '*' -o "<FILE>" -u "admin:admin" "http://<ADDRESS>/status.xml"
xmllint --xpath "//outletStat<PORT>/text()" "<FILE>" 2>/dev/null

OFF:

curl -s -L --noproxy '*' -o /dev/null -u admin:admin -X POST "http://<ADDRESS>/control_outlet.htm?op=1&outlet<PORT>=1&submit=Anwenden"

ON:

curl -s -L --noproxy '*' -o /dev/null -u admin:admin -X POST "http://<ADDRESS>/control_outlet.htm?op=0&outlet<PORT>=1&submit=Anwenden"

In all cases:

<ADDRESS>: IP or FQDN address of the PDU

<PORT>: power switch port, usually from 0 to 7

<FILE>: temporary file to cache the results, so one can get info for all ports on per port basis

Historically and due to lack of knowledge about process the ACPI IDs for some devices are abusing the specification. As of today the v6.4 of it [1] says in the chapter 6.1.5 "_HID (Hardware ID)":

A valid ACPI ID must be of the form “NNNN####” where N is an uppercase letter or a digit (‘0’-‘9’) and # is a hex digit. This specification reserves the string “ACPI” for use only with devices defined herein. It further reserves all strings representing 4 HEX digits for exclusive use with PCI-assigned Vendor IDs.

Note that the first part of the ACPI ID is a Vendor ID which has to be in the official registry.

However, we have a lot of IDs, including some of them issued by Intel, that do not follow that.

Recently, while I cleaned up kernel from fake IDs [2] that hardware vendors never ever allocated for their devices (many of them simply don't care), it appears that Siemens on behalf of Seiko Epson was trying to establish yet another fake ID for their RTC discrete component in the Coreboot [3] and Linux kernel [4].

Luckily they have listened to me and actually followed the process, i.e. they have asked Seiko Epson to register themselves in ACPI registry [5], which happens couple of month ago under the 'SECC' vendor (while it’s even better, I dunno why they haven't simply reused their PNP Vendor ID which is in the registry for ages). And they have allocated the proper ID, SECC6110, for their RX6110SA component.

Now the patches for Coreboot (see [6]) and Linux kernel, as commit 8d69f62fddf6 ("rtc: rx6110: add ACPI bindings to I2C"), are accepted.

I really wish that all hardware vendors will follow this, including Intel (for the record, we improved a lot the ACPI ID allocation process and there shouldn’t be new cases).

Funny thing that newly introduced ID for Alibaba abusing the specification due to potential collisions with real PCI IDs ('BABA' can be represented as 0xbaba).

Наконец решил переехать на новомодное, с идеями чучхэЛеннарта Поттеринга (меня тут за чаем коллеги в качестве стёба попросили линки на lurkmore использовать, ну, вот тут уместно), воплощённое во всей красе в F18. То, что это самый тяжкий апгрейд в моей жизни, я понял после двух вечеров, поминая всуе идеи чучхэ, заложенные в основе. На такую глубь ковыряния системы при апгрейде я не опускался давно. Но давайте по порядку.

Вечер первый, или ничто не предвещало беды

Традиционно я обновляю систему через yum. Так же начал и в этот раз, загрузил и установил пакеты fedora-release и fedora-release-notes руками, потом сказал yum update. Yum радостно зашуршал и через какое-то время выдал список ломающих систему зависимостей (самосборные пакеты), после их удаления все зависимости просчитались, и манящий своей перспективой вопрос "Продолжить [д/Н]:" появился на экране. Я, наивный, ответил: "Конечно, да!"

Полчаса на загрузку (да, я отсталый, у меня 10Мбит канал), и приключения начинаются...

Рекурсия - см. Рекурсия. Попытка просчитать транзакцию завершилась печально: rpm не смог найти свою внутреннюю зависимость rpmlib(X-CheckUnifiedSystemdir), и мне предложено было обновить RPM. "Ладно", - думаю я, - "обновлю руками", что сразу и сделал. Перезапускаю yum update, и снова здравствуйте. Картина никак не изменилась, хотя rpm уже 4.10.

Чем дальше в лес... Исходная зависимость требовалась для пакета filesystem - один из базовых пакетов системы. Попробовал установить пакет руками. Ага, идеи чучхэ не дали совершить действие. Я ж совсем забыл, что тут systemd головного мозга во весь рост! /lib, /bin и /sbin - символические ссылки на /usr/lib, /usr/bin и /usr/sbin соответственно. Я прилежно скопировал каталоги и поставил симлинки на их копии, но не подумал, что содержимое каталогов неплохо бы скопировать в соответствующие каталоги в /usr. Тут-то и поджидало меня веселье. Я говорю, хочу filesystem, glibc и ещё каких-то пару пакетов за раз поставить, игнорируя эту внутреннюю зависимость. Установка радостно обламывается, я остаюсь в системе, где у меня в /lib, /bin и /sbin нет никаких базовых утилит (они же в соседние каталоги забэкаплены)! Пришлось вспоминать LD_LIBRARY_PATH, LD_PRELOAD.

Может ли быть хуже? А вот может, после того, что команда ls и подобные заработали снова, я попытался обновить glibc. Я уж не припомню, что там обломалось, но каждый последующий запуск чего угодно заканчивался Segmentation fault. Вот тут пришлось ещё вспомнить и запуск бинарников через ld-linux.so... В процессе борьбы я склонялся к варианту "А ну его к чёрту, может с usb-брелока и по-новому раскатать систему?", но не наш же путь! Кое-как, привёл в чувства, догадался наконец скопировать содержимое /lib и Ко в соответствующие каталоги в /usr и перезапустили yum update, правда уже по частям (пара небольших обновления и пара довольно больших), после чего ушёл спать.

Забыл совсем упомянуть крах базы rpm во время песен и плясок вокруг разломанной системы. rpm --rebuilddb справился вроде бы неплохо, хотя появились дубликаты записей некоторых пакетов. Часть из них я удалил руками, часть (старые пакеты) удалились при обновлении yum'ом.

День следующий
Утром перед работой я перезагрузил систему, чтобы под новое ядро всё запустилось, да и посмотреть на этот самый systemd.

Ага, отвалилась сеть. Ну, ладно, до вечера уж подождёт. Вечером продолжил исследования. Не помню каким бубном и шаманскими танцами, но сеть поднялась (перезагружался для проверки, что автоматом всё тоже сработает). Открыл для себя nm-tool, nmcli и nm-online. Ах, помню, что пришлось сказать systemctl disable network.service - LSB сервис, который по сути кроме красных надписей при загрузке ничего не добавлял (может в этом была причина?).

Следующая проблема - X не стартуют. Долгое копание в заменителях runlevel'ов и файлах настройки systemd выяснил, автор сего чуда - большой любитель символических ссылок. Первое, надо проставить символическую ссылку на необходимую цель (у нас же systemd, помните?), чтобы она была целью по умолчанию. Попытка запуска init 5 ничего не давала. Посмотрел новомодный файл graphics.target, там упоминался display-manager.service. Догадаетесь, что мне было сказано на попытку systemctl start display-manager.service? Правильно "No such file or directory"! Символические ссылки... Эту мантру должен повторять каждый пользователь systemd. systemctl enable gdm.service автоматически (хоть где-то автоматика сработала!) проставил ссылку gdm.service <- default.service.

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

Проблемы с Xfce и их решения.

• systray стал бегать по панели, а не придерживаться её края. Оказывается, раньше tasklist автоматически занимал всю ширину панели. Коммит 080db558 всё испортил. Лечить установкой разделителя перед systray plugin со свойством expandable.


• magnet-link не открывается. Не знаю, что там произошло, исправление здесь.


• и самое нетривиальное, часы на боковой панели стали повёрнутыми вертикально. Вначале потратил время, чтобы найти параметр rotate-vertically, который установили в TRUE по умолчанию (что курили?). Затем выяснил, смена параметров вручную в файле настроек панели ни к чему не приводит, они перезаписываются (может я что-то неправильно там форматировал?), зато православный путь - использование xfconf-query, а именно
  xfconf-query -c xfce4-panel -p /plugins/plugin-18/rotate-vertically -n -t bool -s false, предварительно определив, как называется модуль часов.

Ну, ещё по мелочи, mc перестал нормально отображать цвета в панелях, когда запущен под screen, а терминал 256-цветный. На этот счёт есть запись #902911 в RH Bugzilla.

В остальном пока что полёт нормальный.

Добавил фильтрацию в скрипт gopmlgen, которым я синхронизирую подписки в Google Reader'е.

Добавлена опция --exclude <FILE> или --exclude "STRING", которая принимает список URI для исключения из обработки.

Таким образом можно держать человека во френдах в соответствующей соц. сети, но при этом не аггрегировать его поток в Google Reader.

Исходники проекта: http://github.com/andy-shev/gopmlgen

P.S. Предыдущие записи по теме:
http://andy-shev.livejournal.com/113313.html
http://andy-shev.livejournal.com/81393.html
http://andy-shev.livejournal.com/67256.html

И я тоже увидел эту гадость под названием LJtimes.

Тупо сделал также:
Я использую Google Chrome и дополнение AdBlock. Добавил всего одну строку:

*.livejournal.com##DIV[id="ljtime"][class="b-ljtimes-wrapper"]

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

Теперь скрипт умеет две основные вещи, обновление подписок и сравнение подписок между GR и другим сервисом (таковых сейчас три: YouTube, LiveJournal, PicasaWeb).

Соответственно опция --subfolder носит не только полезную, но и смысловую нагрузку. Иначе в разнице будут присутствовать совсем не те подписки, которые хотелось бы обновить.

Примеры запуска:

$ gopmlgen --service youtube --subfolder 'YouTube' --diff
Removed(1):
        http://gdata.youtube.com/feeds/base/users/0andriy/subscriptions - Videos published by : 0andriy

$ gopmlgen --service youtube --subfolder 'YouTube' --diff --self --update all
Removed(1):
        http://gdata.youtube.com/feeds/base/users/0andriy/subscriptions - Videos published by : 0andriy

Added(1):
        http://gdata.youtube.com/feeds/base/users/0andriy/uploads - Videos published by : 0andriy

Есть однако и ложка дёгтя, заключающаяся в ошибке #391, не позволяющей отправлять запросы со своим Content-Type. Лечится патчем на gdata-python-client.

Значит так, интересовался вопросом монтирования дисков из консоли ранее. Сегодня увидел решение.
Оказывается, сейчас наследник HAL'а по имени DeviceKit содержит замечательную утилиту под названием devkit-disks. Соответственно, пользуясь ей, можно делать с дисками даже больше, чем было доступно в gnome-mount.

Но, самое интересное, что в Rawhide, DeviceKit-disks выкинули и заменили на udisks! Я не знаю, какую траву курят в fdo, RedHat'е, ..., но представляете как разбухает код по поддержке всего этого... Теперь во всех проектах появляется поддержка путей и работы через D-Bus с HAL, DeviceKit-disks, udisks. Что же далее?!

Прикупил на ebay.com новый винчестер для x60s. Захотел увидеть страшное - родную windows xp pro, за которую заплачено. :)
Забэкапил, значит, я раздел под названием Rescue and Recovery, перенёс на новый винчестер, а оно ж не грузится!

( Дальше страшное в деталях! )

Несколько шагов, чтобы читать френдленту ЖЖ в Google Reader. Google Reader поддерживает импорт списка потоков только из OPML. Поэтому для обновления френдленты ЖЖ в нём нужно сделать следующее:
- сгенерировать OPML по ссылке http://www.livejournal.com/tools/opml.bml?user=exampleusername (livejournal убрал ссылку из FAQ!)
- сохранить это в файл
- открыть Google Reader -> Manage Subscriptions
- выбрать фильтр "livejournal" (как правило этого достаточно)
- выбрать все потоки, прошедшие фильтр, и отписаться от них
- перейти во вкладку Import/Export
- загрузить скачанный OPML
- (опционально) выбрать снова фильтр "livejournal" и переместить всех в какую-нибудь папочку.

UPDATE: я написал скриптик для синхронизации, о нём здесь.

На неделе собрал привезенную кровать, предварительно разобрав хозяйскую...

Ikea порадовала документацией по сборке, но при этом удивление вызвал процесс сборки ящичков для всякого постельного белья, задвигаемых в кровать. Там были пластиковые гвозди(?) с резьбой. Вообщем, их надо было как-то забивать, но я просто вдавил. Понравился также шаг номер 2 или 3, где был перечёркнут один человечек, хотя она прекрасно собирается одним человеком. Может, чтобы не придавило?