VirtualBox 4.0 USB

С выпуском четвертой версии виртуальной машины VirtualBox среди прочих изменений в стала доступна возможность подключения USB-устройств в гостевой ОС. Вообще говоря, такая возможность была раньше и в проприетарной версии.

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

Существуют инструкции, в том числе и на официальном сайте VirtualBox, где объясняется как монтировать /proc/bus/usb, чтобы все заработало. Так вот, эта инструкция только для относительно старых ядер, например в openSUSE 11.2 монтировать ничего не нужно.

Для активации поддержки USB следует: во-первых, убедиться что существует группа vboxusers и нужные пользователи включены в неё, во-вторых, открыть /etc/udev/rules.d/60-vboxdrv.rules и активировать там соответствующие настройки:

KERNEL=="vboxdrv", NAME="vboxdrv", OWNER="root", GROUP="root", MODE="0600"
#these two lines give access permission to vboxusers to properly work with usb nodes, this could be security risk (bnc#664520) !!
SUBSYSTEM=="usb_device", ATTR{devnum}=="?*", ATTR{busnum}=="?*",NAME="vboxusb/$attr{busnum}/$attr{devnum}", GROUP="vboxusers"
SUBSYSTEM=="usb", ENV{DEVTYPE}=="usb_device", ATTR{devnum}=="?*", ATTR{busnum}=="?*",NAME="vboxusb/$attr{busnum}/$attr{devnum}", GROUP="vboxusers"

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

python и ленивые(lazy) атрибуты

В интернете куча примеров как сделать ленивые атрибуты для класса, чтобы не искать, оставлю здесь еще один пример:

class lazy(object):
        def __init__(self, function):
                self._function = function

        def __get__(self, instance, owner = None):
                if instance == None:
                        return self
                val = self._function(instance)
                setattr(instance, self._function.func_name, val)
                return val

class line(object):
        def __init__(self, line = None):
                self._line = line

        @lazy
        def items(self):
                return self._line.split()

Объяснение: items, коль скоро он декорируется, становится объектом класса lazy, и начинает восприниматься как дескриптор(descriptor). Поэтому __get__, __set__ и __delete__ могут быть определены у класса lazy. Конкретная реализация __get__ вычисляет значение функции и привязывает объект с результатом в качестве атрибута вместо себя на свое имя. Значит, последующие обращения к items — уже не вызов функции, а просто операции со списком, что вернулся при первом вызове.

boost.python

Для сборки чего-либо с использованием boost.python его авторы рекомендуют использовать bjam, угрожая при этом в документации, что если что-то и отвалится, то исключительно по причине не использования оного.

Если не использовать bjam, то существует подсказка для выбора правильных параметров для компиляции и линковки: идем в ./libs/python/example/quickstart и просим bjam -n (т.е. распечатать команды вместо того, чтобы их запускать)

Кроме того, у меня работал вот такой Makefile:

all: test1.so

test1.so: test1.o
 $(CXX) -shared $< -o $@ -lboost_python

test1.o: test1.cpp
 $(CXX) `python-config --includes` -fPIC $< -c -o $@

Внешние скрипты и Django

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

import os
import sys

# укажем путь к нашему django-сайту
sys.path.append('/var/www/mydjango')

# укажем какие настройки следует использовать
os.environ['DJANGO_SETTINGS_MODULE'] = 'settings'

# импортируем модели
from myapp import models

# используем

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

PYTHONPATH=/var/www/mydjango DJANGO_SETTINGS_MODULE=settings python my-script.py

openSUSE Build Service 2.0.5

Наконец переехал у себя с OBS 1.7 на 2.0. OBS — это, пожалуй, единственное ПО, которое я ставлю из пакета, делаю как в инструкции, и... и все падает с какими-то не информативными странными ошибками.

Начать следует с того, что, насколько я понял, эта штука теперь научилась работать с gpg2, поэтому gpg 1.4.5 со специальным патчем "files_are_digests" можно выкинуть. Не забыв при этом подправить путь к gpg в /etc/sign.conf

Порадовало, что наконец в пакет добавили конфиги для logrotate, теперь логи не вырастают до невиданных размеров.

Теперь более интересное. В связи с тем, что рабочие научились самостоятельно создавать себе образы дисков, в /etc/sysconfig/obs-worker добавлено очень много новых опций. В нем же можно изменить рабочую директорию (теперь по умолчанию /var/cache/obs/worker), размеры образов, количество памяти для виртуальной машины и указать её тип. В нем же мне пришлось обратить пристальное внимание на OBS_VM_KERNEL и OBS_VM_INITRD, у меня ничего не заработало пока я их не исправил:

OBS_VM_KERNEL="/boot/vmlinuz"
OBS_VM_INITRD="/boot/initrd-virtio"

Дело в том, что я предпочитаю использовать build с KVM. И, к сожалению, build не смог самостоятельно найти нужные образы для загрузки без явного указания этих параметров. Кстати, файл /boot/initrd-virtio (initrd с поддержкой virtio) делает сам скрипт build, так что не надо удивляться откуда он взялся.

Обновление на openSUSE 11.3.

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

Kernel Module Packages

Ссылки на существующую документацию, политки и примеры по созданию пакетов с модулями ядра для разных дистрибутивов:

• openSUSE, SLES, SLED:
  
  • Kernel Module Packages Manual for CODE 9 ( http://developer.novell.com/wiki/images/b/bd/Kmpm-code9.pdf)
  • Kernel Module Packages Manual for CODE 10 (http://developer.novell.com/wiki/images/f/fd/Kmpm-code10.pdf)
  • Kernel Module Packages Manual for CODE 11 (http://developer.novell.com/wiki/images/8/80/Kmpm-code11.pdf)
• LinuxFoundation: standard spec (http://www.linuxfoundation.org/en/Sample_KMP_spec_file)
• RedHat, RHEL, CentOS:
  
  • http://driverupdateprogram.com/ (http://driverupdateprogram.com/presentations/DriverUpdateProgramTechnical.pdf)
  • kmod: (http://www.kerneldrivers.org/RedHatKernelModulePackages)
• Fedora kmod (http://fedoraproject.org/wiki/Obsolete/KernelModules)

Комментарии. "Novell Kernel Module Packages Manual for CODE 11" и driverupdateprogram.com от RedHat кажутся оба совместимы с вариантом от LinuxFoundation. Fedora считает что все модули которые нужны, уже есть в ядре и поэтому пакеты с модулями вообще не нужны.