Tue, Jan 22, 2013
Matwey Kornilov
posted at
13:33
udev и camsource
(Пере)запускалка camsource (программы для показывания картинок с веб-камер) с помощью udev:
Запускается на старте (когда udev обнаруживается usb-устройства), и перезапускается при их перетыкании (или перетыкивании).
Можно было бы сделать более красиво, т.е. использовать события "add" и "remove" и переменную DEVICE. Однако этому мешает, во-первых, использование нескольких источников в моей конфигурации (и camsource -k выключил бы сразу все), во-вторых какой-то встроенный глюк в самой программе. Дело в том, что запускаясь, процесс почему-то уходит в состояние зомби, и в /proc/NNNNN/fd оказывается пустота. А при использовании параметра [device] код ищет процесс именно по файловым дескрипторам. Иначе говоря, этот параметр вообще не работает.
Применив фантазию к udev, можно например включать трансляцию видео-потока. Что даже удобнее, чем вписывание не комплектуемых init.d-скриптам запуска camsource, ffserver и т.п. во всякие странные места типа /etc/init.d/boot.local.
SUBSYSTEM=="video4linux", ACTION=="add", RUN+="/usr/bin/camsource -r /etc/camsource.conf"
Запускается на старте (когда udev обнаруживается usb-устройства), и перезапускается при их перетыкании (или перетыкивании).
Можно было бы сделать более красиво, т.е. использовать события "add" и "remove" и переменную DEVICE. Однако этому мешает, во-первых, использование нескольких источников в моей конфигурации (и camsource -k выключил бы сразу все), во-вторых какой-то встроенный глюк в самой программе. Дело в том, что запускаясь, процесс почему-то уходит в состояние зомби, и в /proc/NNNNN/fd оказывается пустота. А при использовании параметра [device] код ищет процесс именно по файловым дескрипторам. Иначе говоря, этот параметр вообще не работает.
Применив фантазию к udev, можно например включать трансляцию видео-потока. Что даже удобнее, чем вписывание не комплектуемых init.d-скриптам запуска camsource, ffserver и т.п. во всякие странные места типа /etc/init.d/boot.local.
Sat, Jan 19, 2013
Matwey Kornilov
posted at
11:55
OBS tar_scm: versionformat
Сервис для OBS под названием tar_scm позволяет автоматически создавать архивы из указанных репозиториев систем контроля версий исходных кодов. Естественно, имеет много параметров, описание которых не так просто найти. На головном web-интерфейсе взаимодействие с сервисами куда-то с недавних пор вообще пропало, там хоть какие-то подсказки содержались.
versionformat — один из самых любопытных параметров, позволяющих хоть как-то оформить название архива, для последующего действия сервиса set_version.
versionformat — один из самых любопытных параметров, позволяющих хоть как-то оформить название архива, для последующего действия сервиса set_version.
- Для git в это поле можно указать:
- @PARENT_TAG@ — bash любезно заменит на ближайший тег
- поля из --pretty=format для последнего по времени коммита — полный список внизу, какой-то смысл в данной ситуации имеют %ct %cd %h (UNIX таймштамп, дата YYYYMMDD, короткий хэш коммита), причем дефисы будут любезно удалены по дороге sed'ом (даты будут получается в духе 20121221).
- Для mercurial (hg):
- поля из --template для последнего по времени коммита — полный список внизу. Огромное богатство для фантазии, есть встроенная опция для latesttag. Во время написания этого текста, не было способа выдать дату в виде YYYYMMDD, без дефисов. Сейчас все дефисы удаляются sed'ом, однако последняя версия tar_scm может быть еще не загружена на головной сервис.
- svn понимает только %r — номер ревизии
Sun, Dec 16, 2012
Matwey Kornilov
posted at
10:52
pwdutils RIP
Широко анонсированный конец света начал потихоньку наступать. Спустя пару месяцев с момента написания моего предыдущего поста shadow-utils vs. pwdutils, основной разработчик pwdutils Торсен Кукук (Thorsten Kukuk) взял и «тихо и незаметно» выпилил pwdutils из следующего релиза openSUSE 12.3 в пользу shadow (Вероятно восклицая в этот момент «Стой и не шевелись! Я тебя породил, я тебя и убью!»).
Репортаж с места события:
Возрадуемся же необходимости оборачивать свои spec-файлы очередными несвежими условными операторами, впрочем я уже давно и так это делаю:
p.s. Неужели pam_unix2.so будет следующей жертвой унификации?
Репортаж с места события:
- https://features.opensuse.org/314473
- README.changes-pwdutils (самый полный список различий смотрите тут)
- http://lists.opensuse.org/archive/opensuse-packaging/2012-11/msg00096.html — первые поломки не заставили себя долго ждать
Возрадуемся же необходимости оборачивать свои spec-файлы очередными несвежими условными операторами, впрочем я уже давно и так это делаю:
%if 0%{?fedora} || 0%{?rhel_version} || 0%{?centos_version}
%define usermod_A /usr/sbin/usermod -a -G
%else
%define usermod_A /usr/sbin/usermod -A
%endifp.s. Неужели pam_unix2.so будет следующей жертвой унификации?
Sat, Oct 20, 2012
Matwey Kornilov
posted at
09:27
OBS submit request top
There was a discussion on submit requests. Adrian Schröter and Jos Poortvliet suggested to use OBS api to generate some kind of reports on pending times. Here is a test (I will publish this python script on github or something like that). I've filtered out all "home:" projects and built following table. To my surprise, there are only a little stalled requests.
Generated at: 2013-04-13 05:27:41.044818
Sat, Oct 06, 2012
Matwey Kornilov
posted at
14:30
shadow-utils vs. pwdutils
Существуют два пакета утилит: shadow-utils и pwdutils (применяется в SUSE). Служат они для одной цели — редактирования групп и пользователей, но при этом значения набора параметров отличаются. Среди шестерки утилит user{add,mod,del} и group{add,mod,del}, к счастью, наблюдается некоторая систематика.
В shadow-utils следующие параметры имеют всегда одинаковое значение (в pwdutils отсутствуют, если явно не указано обратное):
При этом ключи pwdutils другое (в shadow-utils отсутствуют, если явно не указано обратное):
Кроме этого, для каждой команды присутствуют индивидуальные особенности. Их условно можно поделить на три группы: ключ означает разные вещи; ключ отсутствует в одной из реализаций; ключ присутствует, значение совпадает, но это не отражено в документации.
С проблемами первой условной группы можно было бы бороться используя явные длинные названия. Это делает скрипт более длинным, но и более явным. Однако, для -e длинные варианты отличаются: --expiredate и --expire.
В shadow-utils следующие параметры имеют всегда одинаковое значение (в pwdutils отсутствуют, если явно не указано обратное):
| Ключ | Значение |
|---|---|
| -D | изменяет значения по умолчанию |
| -K | key=value для значений по умолчанию |
| -R | запускать в chroot |
| -Z | пользователь SELinux |
При этом ключи pwdutils другое (в shadow-utils отсутствуют, если явно не указано обратное):
| Ключ | Значение |
|---|---|
| -D | DN для LDAP |
| -P | путь к /etc/passwd и /etc/shadow |
Кроме этого, для каждой команды присутствуют индивидуальные особенности. Их условно можно поделить на три группы: ключ означает разные вещи; ключ отсутствует в одной из реализаций; ключ присутствует, значение совпадает, но это не отражено в документации.
С проблемами первой условной группы можно было бы бороться используя явные длинные названия. Это делает скрипт более длинным, но и более явным. Однако, для -e длинные варианты отличаются: --expiredate и --expire.
useradd
| Ключ | Shadow | Pwd |
|---|---|---|
| -M | не создавать /home | нет |
| -N | не создавать группу пользователю | нет |
| -U | создать пользователю одноименную группу | маска umask для домашней директории |
| -b | базовый каталог, вместо /home | нет |
| -l | не добавлять в lastlog | нет |
usermod
| Ключ | Shadow | Pwd |
|---|---|---|
| -A | нет | добавить в группу (аналог -a -G) |
| -R | запускать в chroot | удалить из группы |
| -a | (вместе с -G) добавить в группу | недокументированный |
groupadd
| Ключ | Shadow | Pwd |
|---|---|---|
| -f | не ругаться, если группа уже есть | недокументированный |
groupmod
| Ключ | Shadow | Pwd |
|---|---|---|
| -A | нет | добавить пользователя в группу |
| -R | запускать в chroot | удалить пользователя из группы |
| -n | переименовать | недокументированный |
Tue, Jun 12, 2012
Matwey Kornilov
posted at
14:37
Mercurial
Минимальная инфраструктура для работы с распределенной системой контроля версий Mercurial настраивается следующим образом.
Во-первых, нужно где-то разместить репозитории. Поскольку никаких других рекомендаций не поступало, по аналогии с cvs и svn будем класть все в /srv/hg/repos. Во-вторых, нужно обеспечить теперь доступ разным пользователям, которые счастливо существуют на компьютере и что-то там делают. Основная инструкция тут: http://mercurial.selenic.com/wiki/MultipleCommitters. Краткая инструкция: по аналогии с cvs и svn, создаем системную группу hg, системного пользователя hg, добавляем всех пользователей в группу hg.
Схема создания нового репозитория выглядит следующим образом:
Mercurial >1.0 сам, о чудо, разбирается с правами доступа и делает так, чтобы все кому надо могли туда писать. Вообще говоря, данный подход (пулить всем вместе в один репозиторий) полностью противоречит идеологии hg.
В-третьих, никак не обойтись без веб-интерфейса. В /usr/share/doc/packages/mercurial живет пример под названием hgweb.cgi. Кладем его в /srv/hg/bin/hgweb.fcgi и меняем примерно следующим образом (чтобы через FastCGI работал):
Конфигурация для lighttpd (обычно кладется куда-нибудь в /etc/lighttpd/vhosts.d/hgweb.conf):
Что писать в /srv/hg/config подсказывают в hg help hgweb:
Последняя строчка для того, чтобы пользователям было не обидно, там они хранят свои личные репозитории. Вот только . Поля "Description" и "Contact" настраиваются в .hg/hgrc персонально для каждого репозитория. Кроме того, теперь через http возможно анонимное клонирование.
Во-первых, нужно где-то разместить репозитории. Поскольку никаких других рекомендаций не поступало, по аналогии с cvs и svn будем класть все в /srv/hg/repos. Во-вторых, нужно обеспечить теперь доступ разным пользователям, которые счастливо существуют на компьютере и что-то там делают. Основная инструкция тут: http://mercurial.selenic.com/wiki/MultipleCommitters. Краткая инструкция: по аналогии с cvs и svn, создаем системную группу hg, системного пользователя hg, добавляем всех пользователей в группу hg.
Схема создания нового репозитория выглядит следующим образом:
cd repos/
mkdir test
chown -R hg:hg test
cd test/
hg init
chown -R hg:hg .hg
chmod -R g+w .hg
chmod g+s .hg .hg/store .hg/store/data
Mercurial >1.0 сам, о чудо, разбирается с правами доступа и делает так, чтобы все кому надо могли туда писать. Вообще говоря, данный подход (пулить всем вместе в один репозиторий) полностью противоречит идеологии hg.
В-третьих, никак не обойтись без веб-интерфейса. В /usr/share/doc/packages/mercurial живет пример под названием hgweb.cgi. Кладем его в /srv/hg/bin/hgweb.fcgi и меняем примерно следующим образом (чтобы через FastCGI работал):
#!/usr/bin/python
config = "/srv/hg/config"
from mercurial import demandimport; demandimport.enable()
from mercurial.hgweb import hgweb, wsgicgi
from flup.server import fcgi
application = hgweb(config)
fcgi.WSGIServer(application).run()
Конфигурация для lighttpd (обычно кладется куда-нибудь в /etc/lighttpd/vhosts.d/hgweb.conf):
fastcgi.server += (
"/hg" => ((
"bin-path" => "/srv/hg/bin/hgweb.fcgi",
"socket" => socket_dir + "/hgweb.sock",
"max-procs" => 1,
"check-local" => "disable",
"fix-root-scriptname" => "enable",
))
)
Что писать в /srv/hg/config подсказывают в hg help hgweb:
[paths]
/ = /srv/hg/repos/*
/home/user = /home/user/hg/**
Последняя строчка для того, чтобы пользователям было не обидно, там они хранят свои личные репозитории. Вот только . Поля "Description" и "Contact" настраиваются в .hg/hgrc персонально для каждого репозитория. Кроме того, теперь через http возможно анонимное клонирование.
Matwey Kornilov
posted at
10:59
В openSUSE перерабатывают страницу software.
В openSUSE перерабатывают страницу software.opensuse.org и придумали полезную вещь, встраиваемый в веб-страницы виджет с информацией о пакетах; инструкция здесь.
Выглядит примерно так:
Выглядит примерно так:
Tue, Apr 03, 2012
Valery Gornih
posted at
16:47
Установка opensuse 12.1 с флешки для пользователей Windows
Так получилось, что в ходе экспериментов весь мой зоопарк операционных систем рухнул, и пришлось (о стыд!) переустанавливать систему (главную, из под которой загружается все остальное) из-под Виндовс. И тут всплыли несколько особенностей, о которых знает мало кто из пользователей моей любимой операционной ситемы — потому что они не пользуются надстройкой над dos другими системами или очень редко (как и я, впрочем).
Главное, чего не написано в описании процесса создания установочной флешки — программа требует образ в формате raw, вернее, файл с таким расширением. И в прошлый раз (при попытке установить любимую систему другу-виндузятнегу) на этом у меня получилась большая заминка, а точнее — установку не получилось сделать. В этот раз, так как деваться было некуда, интуиция подсказала мне просто переименовать гибридный образ (который был сделать точно по описанию из документации, смотрите на портале opensuse) — было изменено расширение с iso на raw. И все прошло успешно, система установлена.
Небольшое добавление к предыдущей статье — перед созданием флешки через imagewriter образ (установочный) был переделан в гибридный, и поэтому все прошло нормально. Перед этим были попытки записать обычный скачанный образ на флешку, но умная программа отказывалась это делать. Теперь все в порядке
Thu, Mar 15, 2012
Matwey Kornilov
posted at
06:39
postifx в SuSEconfig
В openSUSE 12.1 postfix был откручен(750685) от SuSEconfig, поэтому запускать тот самый волшебный скрипт теперь надо так:
MD5DIR=/var/adm/SuSEconfig/md5 /usr/sbin/SuSEconfig.postfix
Все остальное работает как раньше: /etc/sysconfig/postfix, /etc/sysconfig/mail остаются в силе. Базы алиасов пересобираются сами при rcpostfix restart.
Valery Gornih
posted at
05:46
Установка openSUSE 12.1 c флешки
Недавно попробовал установить новую версию моего любимого дистрибютива с флешки.
Так как свободной флешки больше 4 гигабайт в наличии не оказалось, установку делал с образа LiveKDE 12.1 — с планами доустановить необходимый софт позже через интернет.
В версии 11.4 весь необходимый софт ( openSUSe studio и все прилагающиеся необходимые пакеты) были установлены, запись дистрибютива на флешку прошел без сучка и задоринки. И сама установка прошла как по маслу, тем более что с флешки установка идёт быстрее, чем с СД или ДВД. Установил, настроил, добавил необходимые русификационные пакеты — и вот, всё работает, все замечательно. Новая версия пока у меня нареканий не вызвала, правда, в ней я работаю не часто