Админодевелопмент

ALT Linux на OMAP3 BlueShark

2012-01-20T10:52:00.000+03:00

Попала в руки плата Atoll-Deluxe v4 с процессорным модулем OMAP3 BlueShark и LCD-панелью NEC E170632:

На борту уже имелся Ångström Linux, однако захотелось получить более привычное окружение. Имевшаяся в комплекте загрузочная SD-карта была разбита на два раздела:

с U-Boot и ядром
с корневой файловой системой

Поэтому я решил просто отложить родной корень в сторонку и сгенерировать новый традиционным для ALT Linux способом, загрузившись для начала со штатным ядром. Получилось не сразу, но Paul Wolneykien помог решить основную проблему с логином через mini-USB - а дальше дело оказалось в шляпе. Профиль доступен здесь, выложены:

В планах сборка правильного ядра.

Последняя версия ALT Linux Live

2011-11-25T14:32:00.001+03:00

Обновил ALT Linux Live до текущего branch/t6, доступны образы:

И, скорее всего, эта сборка будет последней. У меня не хватает сил самостоятельно поддерживать профиль m-p-l в актуальном состоянии, а тем временем наследник тонущего от переизбытка возможностей и их бессистемного добавления основного профиля m-p-d в лице m-p довольно активно развивается. Поэтому со временем я планирую перебираться на него, чего всем выпиливателям кастомных образов и советую.

Колоночная СУБД MonetDB

2011-08-01T13:28:00.000+03:00

Внезапно дошли руки пощупать настоящую колоночную СУБД в реализации MonetDB, свежая версия которой в честь этого доступна в Сизифе и t6/branch. Тестировал на старой задаче, которая замечательно укладывается в область применения колоночных СУБД - учет объема ip-трафика по различным критериям (периоды, сети, хосты, пропущено/зарезано). Впечатления смешанные. Оно действительно уделывает тщательно тюненный PostgreSQL:

Загрузка данных из текстового файла происходит в 3 раза быстрее
Выборка с GROUP BY и полным сканированием большой таблицы - в 7 раз быстрее
Выборка небольшого набора строк с кучей WHERE - на удивление даже это чуть вышло быстрее, однако в пределах погрешности измерений
Размер БД в 1,5 раза меньше исходного текстового файла

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

Это уже не говоря о значительно более лаконичной по сравнению с PostgreSQL документацией и несравнимо меньшим комьюнити. Поэтому рекомендовать это кому-либо в production я не решаюсь, хотя сам, пожалуй, попробую ;)

Автоинсталляция ALT Linux Live

2011-04-07T15:18:00.000+03:00

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

Для решения задачи на базе фичи fakeinstall была изготовлена фича autoinstall и с ее помощью задача была быстро решена, однако чувства удовлетворенности не появилось. Во-первых, код в фичах дублировался, а во-вторых, практически всю процедуру настройки пришлось оформить отдельным коммитом во внутреннем бранче - там гвозди совсем большие и толстые.

Положение исправил неожиданно проснувшийся интерес других участников ALT Linux Team к моей процедуре [авто]инсталляции. Например, Михаил Пожидаев выпилил пересекающуюся часть упомянутых выше фич в пакет live-install и использовал его в своем проекте специализированного дистрибутива для людей с ограничениями по зрению. Теперь уже мне ничего не оставалось, кроме как задействовать этот пакет и выкинуть из фич ненужный код, а заодно по аналогии с eeelive - сделать пакет и фичу для тонкого подпиливания уже загруженного (в моем случае как правило по сети) образа - и тем самым утащить самые страшные гвозди из профиля в настраиваемые внешние скрипты.

Обновленные образы, собранные на текущем branch/5.1, по традиции можно взять здесь.

Король умер, да здравствует король ...

2010-08-12T16:43:00.000+03:00

CallWeaver медленно, но верно впадает в анабиоз (критерий - количество новых коммитов в SVN), и потому я давно стал приискивать ему такую замену, которая не называется Asterisk.

Остановился в итоге на FreeSWITCH, который соблазнил меня:

Красивой архитектурой с честной модульностью и возможностью масштабироваться от софтфона до софтсвитча
Использованием уже зарекомендовавших себя свободных фреймворков (Apache Portable Runtime для обеспечения переностимости между различными платформами, SofiaSIP в качестве SIP-стека и т.д.)
Конфигурацией в XML (по мне это значительно удобнее ini-файлов) с возможностью перечитывать фрагменты конфигурации с HTTP-сервера в процессе работы

Правда размер дефолтной конфигурации совершенно безумен, да сама она скорее сборник примеров, чем то, от чего можно отталкиваться в процессе настройки системы для промышленной эксплуатации. Поэтому по аналогии с CallWeaver я выпилил для себя минимально работоспособный вариант, который дальше по мере необходимости уже можно наращивать дополнительными возможностями. Хотел было даже подбить текущего майнтейнера FreeSWITCH в ALT Linux сделать этот вариант конфигурации одним из коробочных - да тот оказался слишком несговорчивым :(

Java services with Maven

2010-05-04T09:47:00.005+03:00

Наконец-то я научился использовать maven :) Устанавливаем аналогично Groovy:

# cd /opt
# wget http://www.sai.msu.su/apache/maven/binaries/apache-maven-2.2.1-bin.zip
# unzip apache-maven-2.2.1-bin.zip 
# ln -s apache-maven-2.2.1 maven
# cat > /etc/profile.d/m2home.sh << EOF
> M2_HOME=/opt/maven
> export M2_HOME
> export PATH=$PATH:$M2_HOME/bin
> EOF
# chmod 755 /etc/profile.d/m2home.sh

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

дистрибутивозависимую
кросcплатформенную (примеры ServiceApp, SpringApp, SpringJettyWebApp и SpringJpaApp приблизительно соответствуют тегам logging, spring, web и persistence)

Собираем:

$ git clone git://github.com/enp/service.git
$ cd service/
$ mvn package
$ du -s target/service-0.1*
2.2M    target/service-0.1-dist.zip
8.0K    target/service-0.1.jar
12K     target/service-0.1-src.zip

Запустить можно как приложение:

$ cd target/
$ unzip service-0.1-dist.zip 
$ cd service-0.1
$ java -jar service-0.1.jar

И как сервис:

# apt-get install java-service
# java-service-create myservice
# service myservice start
# service myservice status
# service myservice stop
# java-service-destroy myservice

В пакете java-service в качестве уже скомпилированной реализации сервиса (файл /var/lib/java-service/template.zip) лежит то, что доступно по тегу service. Командой java-service-create myservice архив template.zip разворачивается в /var/lib/java-service/myservice - и вот содержимое этого каталога я уже подменяю моим собственным приложением.

Новые сборки ALT Linux Live Lite c XFCE и KDE3

2010-04-23T16:33:00.019+03:00

Немного доработал десктопную часть mkimage-profile-live и попутно на свежем branch/5.1 собрал livecd с XFCE и KDE3 (только i586) - причем последний по некоторым данным должен быть едва ли не легче первого.

Выглядят они так:

Инструкции по переносу загруженной системы на жесткий диск можно найти в файле /etc/issue и, соответственно, на всех текстовых консолях - впрочем чуть раньше я их уже приводил. Инструкции по изготовлению liveflash из livecd лежат в файле README прямо в корне iso-образов.

Желающие могут воспроизвести результаты следующим образом:

$ git clone git.alt:/people/enp/packages/mkimage-profile-live.git
$ cd mkimage-profile-live
$ git checkout autoconf
$ autoconf
$ ./configure \
  --with-release=5.1 \
  --with-aptconf=/home/enp/apt/apt.conf.M51.i586 \
  --with-kernel=el-smp \
  --with-features=fakeinstall,tools-console,tools-network,xorg,dm-autologin-gdm,de-xfce,apps-firefox,apps-office,apps-mobile,sound 
  --with-timezone=Europe/Moscow 
  --with-locale=ru_RU
  --with-user=user
$ make
$ du -s .work/.out/altlinux-5.1-live.iso 
516M    altlinux-5.1-live.iso

Это сборка образа с XFCE. Образ с KDE3 собирается аналогично, только dm-autologin-gdm,de-xfce нужно заменить на dm-autologin-kdm3,de-kde3.

ALT Linux Live Lite для толстых бездисковых клиентов

2010-01-26T13:05:00.008+02:00

Использовать современные рабочие станции с 1Gb RAM и (зачастую двухъядерными) Atom в минимальной комплектации в качестве тонких бездисковых клиентов кажется слишком расточительным, а найти менее производительное и дорогое (но при этом не б/у) железо чем дальше, тем сложнее. Самый логичный выход из этой ситуации - запуск DE и всех необходимых приложений локально, но с удаленного носителя, как и в случае тонких клиентов. Принципиальное отличие в том, что приложениям потребуется где-то сохранять результаты своей работы - но r/w /home можно держать на NFS, а остальное и потерять не жалко.

Образ для удаленной загрузки легко изготовить на основе профиля mkimage-profile-live.git, в который только что добавлена feature с именем nfshome - она позволяет указать адрес сервера и имя экспортируемого каталога в конфигурации syslinux примерно так:

label remote
  kernel altlinux-live-i586/vmlinuz
  append initrd=altlinux-live-i586/initrd.img root=/dev/nfs ip=dhcp fastboot nfsroot=192.168.100.209:/export/root nfshome=192.168.100.209:/export/home

В зависимости от необходимости авторизации пользователей можно либо использовать автологин и монтировать в /home разные каталоги для разных рабочих станций (и реализовать в nfshome автоподстановку каталога на основе имени рабочей станции), либо использовать LDAP. Поскольку ни то, ни другое пока не работает из коробки, то в нарушение традиции я не буду выкладывать образы - желающие могут собрать и допилить их самостоятельно.

Groovy first steps

2009-12-23T10:15:00.010+02:00

Озаботившись скриптовой обвязкой для очередной инсталляции, где выразительности unix shell явно недостаточно, подумал о том, что поздняк метаться. Perl, Python, Ruby и прочие скриптовые языки хороши каждый по-своему, но от Java мне все равно никуда не деться. В то же время с Groovy я получу примерно тот же уровень комфорта при ad-hook scripting с сохранением всего, что я уже умею и сделал. Ибо код Groovy не просто компилируется в байткод JVM (таких языков много), но максимально синтаксически и семантически похож на Java.

Предварительные требования для Groovy: установленный JDK и прописанный JAVA_HOME (в ALT Linux для этого достаточно сказать apt-get install java-1.6.0-sun-devel tzdata-java). Процесс установки выглядит так:

# cd /opt
# wget http://dist.groovy.codehaus.org/distributions/groovy-binary-1.7.0.zip
# unzip groovy-binary-1.7.0.zip 
# ln -s groovy-1.7.0 groovy
# cat > /etc/profile.d/groovyhome.sh << EOF
> GROOVY_HOME=/opt/groovy
> export GROOVY_HOME
> export PATH=$PATH:$GROOVY_HOME/bin
> EOF
# chmod 755 /etc/profile.d/groovyhome.sh

Причины неиспользования groovy из альтовского репозитария (или JPackage в общем случае) просты - огромный список зависимостей, большая часть которых мне никогда не потребуется, и, как следствие, протухшие версии зависимых пакетов да и самого groovy. Проблема переносимости в случае ad-hook scripting менее актуальна, однако при увеличении размеров проекта она вполне может проявиться.

Теперь перелогинимся и убедимся в том, что Groovy у нас есть:

$ groovy -version
Groovy Version: 1.7.0 JVM: 1.6.0_17

а затем напишем традиционный Hello World:

$ cat > hello.groovy << EOF
> #!/usr/bin/env groovy
>
> def hello(name) {
>     println("Hello $name!")
> }
>
> hello("World")
> EOF
$ chmod 755 hello.groovy
$ ./hello.groovy 
Hello World!

Ну и тормоз же он однако:

$ time ./hello.groovy 
Hello World!
3.18user 0.18system 0:02.22elapsed 151%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (1major+25068minor)pagefaults 0swaps

И даже предварительная компиляция и запуск готового байткода помогает не сильно:

$ groovyc hello.groovy 
$ time java -cp .:$GROOVY_HOME/embeddable/groovy-all-1.7.0.jar hello
Hello World!
1.88user 0.10system 0:01.60elapsed 123%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (1major+15771minor)pagefaults 0swaps

Хотя здесь как раз нет ничего удивительного - скоростью запуска JVM никогда не отличалась. Для разных мелочей эту проблему можно обойти с помощью Groovy Shell:

$ groovysh 
Groovy Shell (1.7.0, JVM: 1.6.0_17)
Type 'help' or '\h' for help.
------------------------------------------------------------------------------------
groovy:000> def hello(name) {      
groovy:001> println("Hello $name!")
groovy:002> }
===> true
groovy:000> hello("World")         
Hello World!
===> null
groovy:000> exit

Для отлаженных скриптов лишних 3 секунд на запуск уже не очень жалко, ну а запускать их (и JVM вообще) слишком часто никто в здравом уме не станет - постоянно запущенный сервис будет работать значительно эффективнее.

Развитие ALT Linux Live Lite

2009-12-09T13:38:00.014+02:00

Давно ожидаемый комбинаторый взрыв возможных конфигураций Live Lite заставил меня задействовать autoconf в одноименном бранче профиля. Выглядит примерно так:

$ autoconf

$ ./configure --help
...
  --with-aptconf=file       custom apt.conf location, e.g '--with-aptconf=/etc/apt/apt.conf'
  --with-release=release    install altlinux-release-* package
  --with-kernel=kernel      install kernel-image-* package
  --with-boot=boot          boot : propagator, nfs, nbd
  --with-features=features  features : see live/features directory ...
  --with-user=user          user : default user name
  --with-locale=locale      locale : en_US, ru_RU, ...
  --with-timezone=timezone  timezone : Europe/London, Europe/Moscow, ...

$ ls live/features
apps-firefox
apps-mobile
apps-office
de-xfce
dm-autologin
dm-autologin-gdm
dm-gdm
fakeinstall
sound
tools-console
tools-network
xorg

Типичная feature выглядит следующим образом:

$ cat live/features/dm-autologin/packages 
autologin

$ cat live/features/dm-autologin/image-scripts.d/01-autologin 
#!/bin/sh -e
cat >> /etc/sysconfig/autologin << EOF
USER=altlive
EXEC=/usr/bin/xinit
EXEC_ARGS=/usr/bin/startx
EOF

И пока для моих инсталляций такой способ формирования образов выглядит удобнее m-p-d.Желающие могут загрузить образы, собранные на текущем branch/5.1 (общая часть --with-release=5.1 --with-kernel=el-smp --with-user=user --with-timezone=Europe/Moscow --with-locale=ru_RU):

i586 --with-features=fakeinstall,tools-console,tools-network
i586 --with-features=fakeinstall,tools-console,tools-network,xorg,dm-autologin-gdm,de-xfce,apps-firefox,apps-office,apps-mobile,sound
x86_64 --with-features=fakeinstall,tools-console,tools-network
x86_64 --with-features=fakeinstall,tools-console,tools-network,xorg,dm-autologin-gdm,de-xfce,apps-firefox,apps-office,apps-mobile,sound

Немного измененная процедура установки выглядит теперь так:

размечаем диск с помощью [c|s]fdisk/mkswap/mkfs.ext4 или parted
вызываем /live/install (диск) (раздел для корня) - при этом загруженная система переносится на корневой раздел, настраивается fstab (туда прописываются корень и все найденные своп-разделы) и lilo
перезагружаемся с жесткого диска
настраиваем FQDN в /etc/sysconfig/network
настраиваем сеть
меняем рутовский пароль и пароль пользователя user - по дефолту они пустые

Сетевая загрузка ALT Linux Live Lite

2009-10-05T13:07:00.007+03:00

Пропагатор позволяет загружать ALT Linux Live Lite не только с локальных устройств, но и по сети, однако при этом образ загружаемой системы размещается в RAM - и это не очень хорошо в тех случаях, когда памяти мало. По аналогии с ALTSP можно монтировать корень загружаемой по сети системы непосредственно по NFS/NBD - профиль можно взять там же - но в бранче netboot.

Не удержался и сделал "ALTSP на коленке" - в настройках pxelinux можно указать параметры nbdswap для сетевого свопа и xdmcp для подключения к удаленному десктопу. Результаты в бранче netboot-xdmcp.

ALT Linux Live Lite

2009-09-23T15:06:00.013+03:00

ALT Linux 4.0 Server Lite умер, да здравствует ALT Linux Live Lite! Как видно из названия, это в первую очередь live-система с минимальным набором необходимых инструментов, однако она также пригодна к установке самой себя на жесткий диск в ручном режиме:

размечаем диск с помощью fdisk/sfdisk/cfdisk
вызываем /live/install (диск) (раздел для корня) (раздел для свопа) - при этом инициализируется своп, создается и заполняется файловая система ext3 на корневом разделе, настраивается fstab и lilo
перезагружаемся с жесткого диска
настраиваем FQDN в /etc/sysconfig/network
настраиваем сеть
удаляем PermitRootLogin yes из /etc/openssh/sshd_config - это удобно для удаленной установки через выключенный по умолчанию ssh, но не очень подходит в production
создаем хотя бы одного пользователя и включаем его в группу wheel - по умолчанию таких пользователей еще нет

Система собрана на текущем Сизифе, ~~доступны iso для архитертур i586 и x86_64~~ iso потеряны а, профиль можно взять здесь.

Telephone eXchange Management Library

2009-08-13T14:31:00.010+03:00

На GitHub отправилась TXMLib (Telephone eXchange Management Library) - небольшая библиотека, предоставляющая унифицированный API к общим операциям различных цифровых АТС. Пока поддерживается только измерение параметров абонентской линии только для АТС типа EWSD, MT-20/25 и DX-200 (а также ее потомка АТСЦ-90), однако дизайн библиотеки позволяет сравнительно легко добавлять поддержку новых типов АТС и новых типов операций.

Для этого потребуется описать наследников классов:

txm.lib.common.core.CommandManager - для выделения ответов на команды из терминала АТС - поддержка чего-то отличного от текстового терминала возможна, но пока детально не проработана
txm.lib.common.core.OperationManager - для перевода унифицированных операций в конкретные команды АТС

Помимо хорошей экономии на общем коде и повышения его читабельности по сравнению с инструментами типа expect мы также получаем дополнительный бонус в виде сформированного графа операций, команд, их результатов и ошибок, готового к сериализации в XML (см. класс txm.lib.examples.OperationExample) или, например, в реляционную БД посредством ORM.

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

Разумеется, диспетчеризацией операций и их передачей по сети TXMLib не занимается - это следующая задача для другого инструмента.

ALT Linux 4.1 Desktop Lite - неофициальная сборка

2009-02-17T13:24:00.015+02:00

Время от времени в community@lists.altlinux.ru спрашивают: а где бы раздобыть ALT Linux 4.1 Desktop Lite, который до релиза, как известно, не дожил :(

Поскольку я собирал для себя нечто подобное, но с другим дизайном и с другими дефолтами, и лучше поздно, чем никогда, выкладываю пересобранные на сегодняшнем branch/4.1 cd-образы:

минимальный - в комплекте только XFCE и Firefox
полный - также включены Thunderbird, Pidgin, OpenOffice, Evince, VLC Player

Инсталлятор от официального не отличается ничем, свежеустановленная система выглядит так:

Если кому-то вдруг захочется это собрать, профиль можно взять здесь. Планы по сборке аналогичного дистрибутива на branch/5.0 есть, но если кто-нибудь меня опередит, я буду только рад :)

Практическое введение в Git

2009-02-15T22:30:00.010+02:00

Возможно, я плохо искал, но простого пошагового введения в Git на русском для тех разработчиков и админов, которые кое-как научились использовать CVS или SVN, до сих пор нет. Много полезных материалов и ссылок можно найти на ALT Linux Wiki, однако значительная их часть содержит альтовскую дистрибутивостроительную специфику или, наоборот, несколько далека от практических задач. Я попытаюсь описать один из типичных сценариев использования Git без привязки к каким-либо задачам и без излишних подробностей - за ними лучше сразу идти в Git User's Manual.

Итак, основная идея Git, как и любой распределенной SCM, заключается в том, что мы имеем дело с локальными коммитами в индивидуальных репозитариях разработчиков и с мехнизмами обмена коммитами между репозитариями. Главное преимущество - гибкость (можно вести локальные бранчи с локальными коммитами, не забивая основной репозитарий результатами неудачных или удачных экспериментов), обратная сторона - некоторое увеличение сложности взаимодействия по сравнению с централизованными SCM.

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

Устанавливаем все необходимое и заводим на сервере центральный репозитарий:

# apt-get install git-core
# mkdir /home/repo/alpha.git
# cd /home/repo/alpha.git
# git init --bare --shared=true

Работать с ним будем по ssh, поэтому создаем для разработчиков учетные записи и добавляем их в группу, во владение которой передаем репозитарий:

# useradd -d /var/empty/ -s /usr/bin/git-shell user1
# useradd -d /var/empty/ -s /usr/bin/git-shell user2
# groupadd alpha
# usermod -G alpha user1
# usermod -G alpha user2
# chown -R root:alpha /home/repo/alpha.git

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

[user1@workstation1 ~]$ mkdir alpha
[user1@workstation1 ~]$ cd alpha
[user1@workstation1 alpha]$ git init
[user1@workstation1 alpha]$ git config user.name 'User 1'
[user1@workstation1 alpha]$ git config user.email 'user1@workstation1'
[user1@workstation1 alpha]$ echo 'line 1' > file
[user1@workstation1 alpha]$ git add .
[user1@workstation1 alpha]$ git commit -a -m 'add line 1'
[user1@workstation1 alpha]$ echo 'line 2' >> file
[user1@workstation1 alpha]$ git commit -a -m 'add line 2'

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

Несколько полезных команд:

git branch - показать список бранчей, выделив текущий, создать, удалить или переименовать бранч
git status - показать текущее состояние рабочей копии (какие новые файлы появились, а какие были удалены, что закоммитили, а что нет, и т.д.)
git log - показать историю коммитов, каждый из которых идентифицируется с помощью хеша sha1
git show - показать подробности последнего коммита или любого коммита по его хешу
git diff - показать разницу между последним коммитом и рабочей копией или между коммитами

Теперь подготовим наш репозитарий к отгрузке коммитов в центральный репозитарий на сервере:

[user1@workstation1 alpha]$ git remote add origin user1@gitserver:/home/repo/alpha.git

И отправим туда коммиты, принадлежащие локальному бранчу master - они попадут в удаленный бранч с таким же именем:

[user1@workstation1 alpha]$ git push origin master

В дальнейшем можно будет ограничиться git push, т.к. origin - дефолтное имя удаленного репозитария, а бранч master в нем уже существует. С другой стороны, ничто не мешает явно указывать URL удаленного репозитария и имена локального и удаленного бранчей:

[user1@workstation1 alpha]$ git push user1@gitserver:/home/repo/alpha.git master:master

Для получения коммитов из центрального репозитария в локальный бранч master его нужно было бы создать с параметром --track, однако бранч уже существует, поэтому просто укажем соответствующий ему удаленный бранч в настройках:

$ cat >> .git/config << EOF
> [branch "master"]
>       remote = origin
>       merge = refs/heads/master
> EOF

Получить новые коммиты из центрального репозитария можно так:

[user1@workstation1 alpha]$ git fetch
[user1@workstation1 alpha]$ git merge origin/master

или просто:

[user1@workstation1 alpha]$ git pull

В случае конфликтующих изменений операция merge не будет завершена коммитом - в этом случае нужно будет выполнить git commit самостоятельно после разрешения конфликта.

Разумеется новые коммиты могут появиться в центральном репозитарии только после того, как другой разработчик клонирует его, внесет туда какие-либо изменения и отправит их обратно - при этом настраивать свой репозитарий для взаимодействия с удаленным ему уже не потребуется:

[user2@workstation2 ~]$ git clone user2@gitserver:/home/repo/alpha.git
[user2@workstation2 ~]$ cd alpha/
[user2@workstation2 alpha]$ git config user.name 'User 1'
[user2@workstation2 alpha]$ git config user.email 'user2@workstation2'
[user2@workstation2 alpha]$ echo 'line 3' >> file
[user2@workstation2 alpha]$ git commit -a -m 'add line 3'
[user2@workstation2 alpha]$ git push

Теперь чуть подробнее о том, ради чего все эти мучения - ведь для выполнения аналогичных операций средствами CVS или SVN потребовалось бы меньше операций. Дело в том, что до тех пор, пока мы не отгрузили коммиты в удаленный репозитарий, мы вольны распоряжаться ими как нам вздумается. Например, заведем для экспериментов новый локальный бранч и сделаем в нем еще пару коммитов:

[user1@workstation1 alpha]$ git-checkout -b experimental
[user1@workstation1 alpha]$ echo 'line 4' >> file
[user1@workstation1 alpha]$ git commit -a -m 'add line 4'
[user1@workstation1 alpha]$ echo 'line 5' >> file
[user1@workstation1 alpha]$ git commit -a -m 'add line 5'

Если какие-то коммиты лучше было бы не делать, можно откатиться к любому заданному коммиту, указав его:

явно в виде sha1 id - их покажет git log
по имени тэга - его можно создать для коммита по его sha1 id с помощью git tag
относительно другого коммита - например, последнему коммиту, на который указывает HEAD, предшествует HEAD^:

[user1@workstation1 alpha]$ git reset --hard HEAD^

Также бывают полезны параметр --soft (откатиться, но сохранить содержимое измененных файлов для последующего редактирования) и параметр --amend команды git commit (включить содержимое старого коммита в новый).

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

[user1@workstation1 alpha]$ git checkout master
[user1@workstation1 alpha]$ subst '/line 1/iline 0' file
[user1@workstation1 alpha]$ git commit -a -m 'add line 0'
[user1@workstation1 alpha]$ git merge experimental

Вместо операции merge, которая создает общий коммит для бранчей, иногда бывает полезно использовать rebase - эта операция переупорядочивает коммиты для того, чтобы сохранить историю линейной. Очень полезно для изучения истории использовать gitk, gitg или qgit - эти инструменты помогут представить описанное более наглядно.

Разумеется, после того, как мы сделали git push, с историей лучше не забавляться - этим мы сильно осложним жизнь тем, кто уже основывает свои новые коммиты на ней. А вот до git push - сколько угодно :)

Redmine quickstart

2009-02-02T10:46:00.019+02:00

Похоже, что изначально не приглянувшийся мне Redmine несколько удобнее Trac:

есть приличная русификация
есть поддержка подпроектов
есть web-интерфейс для управления проектами и правами доступа к ним - прям аж обидно, и зачем я тратил время на Trac appliance?
и самое главное - дефолтный дизайн отлично гармонирует с дизайном моего блога :)

В качестве ложки дегтя пока заметил лишь то, что принимать информацию об авторизации от Apache он не умеет, правда умеет LDAP, который уже можно прикрутить к Apache. И опакетить его, к сожалению, так просто не выйдет (updated: поэтому вышло непросто).

Мне пришлось поставить из тарболла:

# apt-get install ruby-rake ruby-stdlibs ruby-activerecord-sqlite3-adapter rubygems
# useradd -d /opt/redmine -s /dev/null redmine
# su - redmine -s /bin/bash
$ wget http://rubyforge.org/frs/download.php/49319/redmine-0.8.0.tar.gz
$ tar -zxf redmine-0.8.0.tar.gz 
$ cd redmine-0.8.0
$ cat > config/database.yml << EOF
> production:
>   adapter: sqlite3
>   dbfile: db/production.db
> EOF
$ rake db:migrate RAILS_ENV="production"
$ rake redmine:load_default_data RAILS_ENV="production"
$ ruby script/server -e production

Теперь подключаемся к http://server:3000/ и логинимся под именем admin с таким же точно паролем. Несмотря на грозные предупреждения в руководстве по установке с более новыми, нежели указано, версиями ruby и sqlite вроде бы все работает.

Trac appliance

2009-01-29T13:56:00.015+02:00

И все-таки быстрый запуск Trac оказывается не слишком быстрым, а результат - не слишком удобным в сопровождении, особенно когда совместно с Trac предполагается использовать систему управления версиями. Более удобный use case представляется для меня сейчас таким:

N проектов - каждый представляет из себя проект Trac и, возможно, настроенный для использования с ним репозитарий Git или Subversion
M пользователей - каждый имеет полный доступ к некоторым проектам (т.е. может работать в Trac и коммитить в репозитарий), а к некоторым не имеет вовсе.

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

Проблема заключается в выборе технологии авторизации и аутентификации, которые позволили бы реализовать описанную схему. Для standalone версий Trac, Git и Subversion ведение единой базы данных пользователей и прав доступа к проектам невозможно, поэтому придется задействовать Apache и его средства управления доступом - соответственно репозитарии Git и Subversion будут доступны по протоколу WebDAV. При этом никто не мешает при необходимости использовать более гибкие настройки прав доступа внутри проектов средствами самих Trac и Subversion.

Готовое решение доступно в виде основного пакета appliance-trac и дополнительных appliance-trac-scm-git и appliance-trac-scm-svn, собираемых из одноименного репозитария. Устанавливаем требуемое штатным для ALT Linux образом:

trac-scm-git

Создаем проект (указываем имя и тип репозитария - если последним параметром будет что-то отличное от git или svn, то репозитарий просто не будет создан):

# appliance-trac-create alpha git

Средствами Apache создаем пользователя:

# htpasswd2 -b /var/www/appliance-trac/passwd user userpwd

Включаем его в соответствующую группу Apache, имя которой соответствует имени проекта:

# vim /var/www/appliance-trac/group

При необходимости пользователя можно сделать администратором Trac:

# trac-admin /var/www/appliance-trac/env/alpha permission add user TRAC_ADMIN

Теперь пользователь user может работать с проектом через web-интерфейс по ссылке http://server//appliance-trac/env/alpha и напрямую с репозитарием:

$ cat > ~/.netrc << EOF
> machine server
> login user
> password userpwd
> EOF
$ git-clone http://server/appliance-trac/scm/git/alpha.git
$ cd alpha/
$ echo "new line" >> README 
$ git commit -a -m 'new commit'
$ git-http-push http://server/appliance-trac/scm/git/alpha.git heads/master

После того, как проект стал ненужным, его можно удалить:

# appliance-trac-drop alpha git

Trac quickstart

2009-01-10T18:28:00.017+02:00

Вместе с совсем уж примитивными wiki-движками бывают также полезны интегрированные системы с wiki, багтрекером, web-интерфейсом к какой-нибудь системе управления версиями и прочими вкусностями - и среди них, как одну из самых простых в установке и в эксплуатации, можно выделить Trac.

После установки и запуска штатным для ALT Linux образом:

# apt-get install trac
# service trac start

Trac готов к обслуживанию проектов, размещенных в каталоге /var/lib/trac, однако хотя бы один проект еще нужно создать:

# su - trac -s /bin/sh
$ trac-admin alpha initenv alpha sqlite:db/trac.db "" ""
$ vim alpha/conf/trac.ini # edit [header_logo] and [project] sections

После этого проект будет доступен на чтение всем желающим по ссылке http://localhost:8000/alpha. Для создания и редактирования багов и wiki-страниц необходимо авторизоваться, а для этого сначала создать пользователей следующим образом:

$ trac-passwd -u user -p usrpwd >> /etc/trac/passwd

Для полного управления проектом нужно выдать пользователю user соответствующие права:

$ trac-admin alpha permission add user TRAC_ADMIN

Такая схема разграничения прав доступа удобна для свободных проектов. Для проектов, процесс работы над которыми не должен быть публично доступным, необходима другая схема: как минимум, у пользователя anonymous необходимо изъять все права и явно выдать их группе authenticated. В этом случае все авторизовавшиеся пользователи будут иметь доступ ко все проектам, а это тоже не всегда оправдано. Для того, чтобы можно было ограничить права на уровне отдельных проектов, потребуется также изъять все права у группы authenticated, и передать их отдельной группе, а затем включать требуемых пользователей в эту группу:

$ trac-restrict-env alpha developers
$ trac-admin alpha permission add user developers

Конечно, возможна и более тонкая настройка прав доступа - но об этом подробно написано в документации Trac

Lightweight wiki engine

2008-12-30T16:55:00.006+02:00

У всех популярных wiki-движков есть один существенный недостаток - они предлагают редактировать контент с помощью браузера. Этот недостаток давно и успешно лечится, однако осадок остается. Действительно, зачем все эти извращения в тех случаях, когда список авторов ограничен и все они имеют shell-доступ к серверу, на котором и живет wiki engine? Пусть редактируют вволю с помощью своего любимого текстового редактора (заодно и какую-нибудь систему управления версиями можно прикрутить), а wiki engine пусть всего лишь отдает текст, отформатированный в html.

Концепт такого движка в виде автономного http-сервера можно можно посмотреть здесь.

ALTSP inside OpenVZ VE

2008-11-25T12:26:00.024+02:00

Требуется обеспечить всем необходимым (доступ в интернет, почта, офисные приложения и учетное ПО) небольшой офис, в котором имеется один приличный сервер и десяток бездисковых рабочих станций. Задача прекрасно решается средствами ALTSP, однако есть одна проблема - очень уж неудобно держать на одном хосте офис, почтовый сервер, прокси-сервер и т.д. Решение - OpenVZ, возможно, с размазыванием функциональности ALTSP по разным VE.

Первый вопрос, на который следует ответить: будем ли мы использовать venet, veth или вообще проброс физических интерфейсов в VE. Первый вариант, конечно, bit faster and more efficient, но не умеет броадкастов, а потому всю инфраструктуру, необходимую для загрузки бездисковых клиентов придется разместить в HN. В дальнейшем предполагаем, что используется OpenVZ в ALT Linux Lite 4.0 c виртуальной сетью 192.168.0.0/24 и физической сетью 192.168.1.0/24 - в последней и будут размещены бездисковые клиенты.

Настраиваем загрузку клиентов по TFTP:

# apt-get install dnsmasq

# chkconfig dnsmasq on

# cat /dev/null > /etc/sysconfig/dnsmasq

# cat > /etc/dnsmasq.conf <<END
bind-interfaces
interface=lo
interface=lan
resolv-file=/etc/resolv.conf.dnsmasq
strict-order
expand-hosts
domain=local
dhcp-range=192.168.1.10,192.168.1.50
enable-tftp
tftp-root=/diskless/altsp/boot/i586
dhcp-boot=pxelinux.0
END

# cat > /etc/resolv.conf.dnsmasq <<END
nameserver ${NAMESERVER}
END

# cat > /etc/resolv.conf <<END
nameserver 127.0.0.1
search local
END

# mkdir -p /diskless/altsp/boot/i586/pxelinux.cfg

# cat > /diskless/altsp/boot/i586/pxelinux.cfg/default <<END
DEFAULT vmlinuz ro initrd=initrd.img root=/dev/nfs nfsroot=/diskless/altsp/root/i586,udp ip=dhcp
END

# service dnsmasq start

В /diskless/altsp/boot/i586 нужно положить vmlinuz, initrd.img и pxelinux.0 из уже существующей инсталляции ALTSP (см. каталог /var/lib/tftpboot/ltsp/i586/) - увы, автономного инструмента для сборки пока нет :(

Уже на этом этапе загрузка бездисковых клиентов начнется, но остановится на монтировании корневой файловой системы. Настроим раздачу корня по NFS:

# apt-get install unfs3

# chkconfig nfs on
# chkconfig portmap on

# cat > /etc/exports <<END
/diskless/altsp/root/i586 (ro,no_root_squash)
END

# service portmap start
# service nfs start

В /diskless/altsp/root/i586 тоже нужно положить каталог /var/lib/ltsp/i586 из существующей инсталляции ALTSP.

Также включим поддержку сетевого свопа на случай непредвиденного расхода памяти на клиентах:

# apt-get install ltspswapd
# chkconfig ltspswapd on
# service ltspswapd start

Теперь бездисковые клиенты смогут полностью загрузиться и обратиться по XDMCP к тому же серверу, с которого загрузились, но безуспешно: никакого XDMCP там нет и не предполагается. Сначала укажем адрес сервера XDMCP:

# cat >> /diskless/altsp/root/i586/etc/lts.conf <<END
XDM_SERVER=192.168.0.101
END

Затем создадим соответствующий виртуальный сервер с помощью скрипта-обертки, описанного ранее:

# create-ve.sh 101 desktop 4.1 i586

Установим в него все необходимое:

# vzctl start desktop
# vzctl enter desktop

# cat > /etc/sysconfig/i18n <<END
LANG=ru_RU.UTF-8
SUPPORTED=ru_RU
END

# cat > /etc/X11/xinit/Xkbmap <<END
-layout us,ru
-option grp:ctrl_shift_toggle
-variant ,winkeys
END

# apt-get install gdm gdm-theme-altlinux xfce4-minimal xfce-mcs-plugins xfce-settings-simple icon-theme-hicolor xterm Thunar leafpad firefox-ru fonts-ttf-ms

# subst 's/happygnome-list/altlinux/' /etc/X11/gdm/custom.conf
# subst 's/Greeter/RemoteGreeter/' /etc/X11/gdm/custom.conf
# subst '/\[greeter\]/aGraphicalThemedColor=#90a8ca' /etc/X11/gdm/custom.conf
# subst '/\[xdmcp\]/aEnable=true' /etc/X11/gdm/custom.conf
# subst 's/id:3:initdefault:/id:5:initdefault:/' /etc/inittab

# exit

# vzctl restart desktop

И вот теперь бездисковые рабочие станции должны загрузиться и показать приглашение GDM.

OpenVZ в ALT Linux Lite 4.0

2008-11-24T17:48:00.038+02:00

Так сложилось, что даже для инсталляций с OpenVZ мне удобнее использовать ALT Linux 4.0 Server Lite (как раз сегодня пересобрал все iso на свежей пакетной базе branch/4.0) вместо официального ALT Linux 4.0 Server.

Для запуска OpenVZ необходимо и достаточно сказать:

# apt-get install kernel-image-ovz-smp vzctl

После перезагрузки с новым ядром можно создавать виртуальные машины (VE) следующим простым скриптом-оберткой:

#!/bin/sh

# проверяем параметры
if [ -z "$4" ]; then
  echo "Usage : $0 \$VEID \$NAME \$BRANCH \$ARCH"
  exit 1
fi

# определяем переменные
VE_NAMESERVER="192.168.1.1"
VE_DOMAIN="local"
VE_NET="192.168.0."
VE_REPO="/repo"
HN_REPO="/lvm/distrib/free/linux/alt"

# создаем VE
vzctl create $1 --ostemplate altlinux-$3-$4

# задаем дефолтные значения для VE
vzctl set $1 --name $2 --ipadd $VE_NET$1 --hostname $2.$VE_DOMAIN \
  --nameserver $VE_NAMESERVER --searchdomain $VE_DOMAIN --onboot yes --save

# создаем каталог с репозитарием внутри VE
mkdir /var/lib/vz/private/$1/repo

# создаем скрипт, который будет монтировать репозитарий из HN
cat > /etc/vz/conf/$1.mount <<END
#!/bin/sh

. /etc/vz/vz.conf

mount -n -o bind $HN_REPO/$3 \$VE_ROOT/repo
END

# делаем скрипт исполняемым
chmod 700 /etc/vz/conf/$1.mount

# настроиваем apt
cat > /var/lib/vz/private/$1/etc/apt/sources.list <<END
rpm file:///repo/branch/ $4 classic
rpm file:///repo/branch/ noarch classic
END

Многое здесь прибито гвоздями: например, предполагается, что в /lvm/distrib/free/linux/alt находятся копии branch/4.0 и branch/4.1, а в /var/lib/vz/template/cache/ - собранные из бранчей с помощью Hasher шаблоны VE:

altlinux-4.0-i586.tar.gz
altlinux-4.0-x86_64.tar.gz
altlinux-4.1-i586.tar.gz
altlinux-4.1-x86_64.tar.gz

В шаблонах находятся basesystem, apt, sysklogd, etcnet, glibc-nss, glibc-locales, netlist, passwd, su, openssh-server, vim-console, mc, less, man и все, что было вытянуто по зависимостям.

Предполагается, что свежесозданные VE будут запущены с помощью vzctl start и первоначально настроены с помощью vzctl enter (т.е. будут созданы необходимые пользователи и пароли/ключи) - далее с ними можно будет работать обычным образом по ssh, сверяясь по мере надобности с полезными советами.

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

Userspace routing policy

2008-09-17T19:28:00.022+03:00

Задача: построить маршрутизатор, который пропускал бы хосты в некоторую сеть (например, в интернет) на основании т.н. "билетов". В билете указывается максимальный объем входящего трафика, по исчерпании которого билет изымается и доступ запрещается, однако на тот же хост через некоторое время можно выписать новый билет.

Я не сомневаюсь в том, что эту задачу можно решить средствами готовых биллинговых систем - из свободных первым в голову приходит NeTAMS. Но слишком уж все они монсторобразны для такой простой задачи. Попробуем решить ее на коленке с помощью connexion по мотивам следующего примера.

Устанавливаем все необходимое:

# apt-get install python-module-cxnet python-module-MySQLdb MySQL-server
# service mysqld start

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

$ mysql -u root
...
mysql> create database cx;
Query OK, 1 row affected (0.00 sec)
mysql> use cx;
Database changed
mysql> create table tickets (
->         id        serial,
->         host      varchar(50),
->         bytes     bigint,
->         max_bytes bigint,
->         enabled   boolean
-> );
Query OK, 0 rows affected (0.01 sec)
mysql> insert into tickets(host, bytes, max_bytes, enabled) values ('192.168.100.103', 0, 100, true);
Query OK, 1 row affected (0.00 sec)
mysql> select * from tickets;
+----+-----------------+-------+-----------+---------+
| id | host            | bytes | max_bytes | enabled |
+----+-----------------+-------+-----------+---------+
|  1 | 192.168.100.103 |      0|       100 |       1 |
+----+-----------------+-------+-----------+---------+
1 row in set (0.00 sec)

Входящие пакеты для хоста 192.168.100.103 завернем в userspace следующим образом:

# modprobe ip_queue
# iptables -A FORWARD -p icmp -d 192.168.100.103 -j QUEUE

А обрабатывать эти пакеты и решать, пропустить или нет, мы будем следующей программой, использующей один из компонентов connexion - библиотеку cxnet:

#!/usr/bin/python

from cxnet.netlink.ipq import *
from cxnet.ip4 import *
from cxnet.utils import *
import MySQLdb

db = MySQLdb.connect(host="localhost", user="root", passwd="", db="cx")
cursor = db.cursor()

ipqs = ipq_socket()

while True:
  (l,msg) = ipqs.recv()
  header = iphdr.from_address(addressof(msg.data.payload))
  if header.daddr>0:
    host = int_to_dqn(header.daddr)
    size = header.tot_len
    print "packet: %s:%s" % (host,size)
    cursor.execute("update tickets set bytes = bytes+%s where enabled = true and host = %s", (size, host))
    cursor.execute("update tickets set enabled = false where enabled = true and bytes >= max_bytes")
    cursor.execute("select count(*) from tickets where enabled = true and host = %s", host)
    for record in cursor.fetchall():
      print "count: %s" % record[0]
      if record[0] > 0:
        ipqs.verdict(msg.data.packet_id, NF_ACCEPT)
        continue
    ipqs.verdict(msg.data.packet_id, NF_DROP)

Теперь отправляем первый пинг с хоста 192.168.100.103 наружу:

$ ping -c 1 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=1.12 ms

--- 192.168.1.1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 1.121/1.121/1.121/0.000 ms

При этом билет изменится следующим образом:

mysql> select * from tickets;
+----+-----------------+-------+-----------+---------+
| id | host            | bytes | max_bytes | enabled |
+----+-----------------+-------+-----------+---------+
|  1 | 192.168.100.103 |    84 |       100 |       1 |
+----+-----------------+-------+-----------+---------+
1 row in set (0.00 sec)

Отправим следующий пинг:

$ ping -c 1 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.

--- 192.168.1.1 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms

При этом билет будет заблокирован, поскольку число принятых байт превысило лимит:

mysql> select * from tickets;
+----+-----------------+-------+-----------+---------+
| id | host            | bytes | max_bytes | enabled |
+----+-----------------+-------+-----------+---------+
|  1 | 192.168.100.103 |   168 |       100 |       0 |
+----+-----------------+-------+-----------+---------+

1 row in set (0.00 sec)

Работает! Правда, тормозить должно жутко, ибо задавать кучу вопросов СУБД (пусть даже и MySQL с дефолтным хранилищем MyISAM, которое и транзакций-то не умеет) на каждый входящий пакет - удовольствие не дешевое. Но о бенчмарках в следующий раз ...

Новые сборки ALT Linux 4.0 Server Lite

2008-09-17T19:04:00.006+03:00

Обновлены сборки ALT Linux 4.0 Server Lite. В них добавлен connexion - пока (и, возможно, навсегда) все же не по дефолту, а в дополнительный репозитарий. Обратите внимание, что опакеченная документация в данный момент актуальнее той, что предлагается на официальном сайте.

Также сделана специальная сборка без дополнительного репозитария для тех, кому нужен маленький iso. Он получился размером в 184M, можно и еще урезать, выкинув rescue, но мне жалко его выкидывать.

Итого:

для i586
для x86_64
для i586 без дополнительного репозитария
для x86_64 без дополнительного репозитария

Lightweight JEE

2008-08-27T12:10:00.043+03:00

Расскажу о том, каким образом я разрабатываю на Java серверные приложения, у которых, как правило, несложный web-интерфейс и довольно замороченная внутренняя логика, в основном из-за необходимости общаться с внешними, иногда довольно "странными" системами (отрасль - телеком, если это кому-то что-то скажет ;) ). Число активных разработчиков от 1 до 2 :) - таким образом, с одной стороны, можно представить себе масштабы проектов, а с другой стороны - разрушить миф о том, что "для разработки на Java нужно много индусов".

Разумеется, я не использую тяжелые сервера приложений вроде JBoss и тем более WebSphere или WebLogic. Более того, я не использую Tomcat. В моем случае каждое приложение живет в отдельной JVM - примерно так же как OpenFire или XWiki.

Исходный код минимального приложения, которое ничего не делает, а просто пишет в лог сообщения о запуске и о завершении работы, можно взять здесь. Все необходимые для работы приложения библиотеки включены в проект и находятся в каталоге lib, рядом в каталоге lib-build также находятся библиотеки для сборки проекта - у вас должен быть установлен только JDK. В результате сборки получается архив, в который все включено - для запуска приложения вам потребуется только JRE.

Для тех, кому грустно тащить лишние мегабайты jar-ов, на http://enp.itx.ru/java/examples/ рядом с каждым *App.zip лежит *App.NoLib.zip.

IDE для работы в принципе не обязательна, однако без нее навигация по коду будет сильно затрудена. Можно использовать любую IDE с поддержкой Java, XML и JavaScript - я использую Eclipse IDE for Java EE Developers

Для сборки приложения используется Ant, который читает инструкции из файла build.xml. На UNIX сборка запускается с помощью build.sh, на Windows - с помощью build.bat - эти файлы можно переносить из одного проекта в другой без изменений. По умолчанию при сборке выполняется цель all, которая последовательно выполняет цели clean,prepare,compile,jar,dist. Цель можно указать явно как параметр в командной строке. Можно также увидеть список целей с помощью ключа -p.

При сборке генерируются стартовые скрипты statup.sh для запуска на UNIX и statup.bat для запуска на Windows, а также инит-скрипт в стиле SysV для работы приложения в качестве юниксового демона. Для генерации написан специальный ant task - его исходный код здесь. Исходные данные для генерации (краткое и полное имя приложения, имя главного класса) берутся из build.xml.

Главный и единственный класс приложения - startup.ServiceApp. Он имеет стандартную точку входа для запуска в качестве обычного java-приложения - метод main, а кроме этого реализует интерфейс org.apache.commons.daemon.Daemon из библиотеки Jakarta Commons Daemon - и таким образом может быть запущен в качестве сервиса UNIX System V с помощью jsvc и в качестве сервиса Windows c помощью procrun. Для реализации первой возможности и используется автоматически генерируемый при сборке инит-скрипт, который предполагает наличие установленного jsvc (в репозитариях ALT Linux эта утилита находится в одноменном пакете).

Для протоколирования используются библиотеки Commons Logging в качестве фасада и Log4j в качестве реализации.

Пока что все описанное сильно напоминает подъем солнца вручную. Т.е. можно, конечно, на этом остановиться и писать прикладную логику в виде java-классов без задействования всех преимуществ enterprise-технологий. Более того, новичкам я бы даже рекомендовал какое-то время воздержаться от их использования. Например, мы хотим, чтобы наше приложение научилось отвечать на http-запросы. Для этого мы просто задействуем встроенный в Java 1.6 http-сервер - исходный код нового приложения можно взять здесь.

А вот теперь, после некоторой передышки, давайте задействуем Spring Framework. Если честно, я затрудняюсь объяснить в двух словах, зачем он нужен. Он умеет слишком много, но все use cases можно условно свести к двум случаям:

упрощение взаимодействия модулей системы друг с другом с помощью таких техник, как IoC и AOP и перенос взаимодействия в рантайм для повышения гибкости
упрощение работы с JDBC, ORM, JMX, JMS, Web Services и прочими полезными технологиями

Исходный код простого приложения, использующего Spring, можно взять здесь. Главный класс startup.SpringApp инициализирует контекст на основании файла context.xml или других файлов, указанных в командной строке при запуске приложения, и закрывает его при завершении работы приложения. Контекст - это и есть описание модулей (бинов) в формате xml. В нашем случае будут инициализированы бины fakeBookLoader и xmlInputStreamBookLoader, реализующие интерфейс beans.BookLoader (т.е. умеющие каким-либо способом загружать экземпляры класса beans.Book), и главный бин bookManager. Последний при инициализации получит ссылки на экземпляры beans.BookLoader, а после инициализации Spring вызовет его метод displayBooks. Подробности в документации Spring.

Теперь усложним приложение по двум направлениям:

реализуем извлечение экземпляров класса beans.Book из реляционной БД - исходный код приложения берем здесь
реализуем web-интерфейс к фунциональности бина bookManager - а это берем здесь

Первый пример использует 3 способа работы работы с СУБД (и, соответственно, 3 реализации beans.BookLoader, используемые бином bookManager):

JDBC без управления транзакциями (каждая операция выполняется в отдельной транзакции) - для этого в контексте определены бины dataSource (параметры подключения вынесены в отдельный файл db.properties, т.к. они же используются еще и в build.xml для создания таблиц в БД) и jdbcBookLoader
JPA (стандарт ORM для Java) с ручным управлением транзакциями - для этого определены бины entityManagerFactory (фабрика реализаций интерфейса javax.persistence.EntityManager, управляющих сохранением/извлечением объектов в/из БД) и jpaBookLoader
JPA с автоматическим управлением транзакциями - для этого используются бин transactionManager, специальные тэги <tx:advice>, <aop:config> и <context:annotation-config>, а также бин jpaTransactionalBookLoader (для него при вызове каждого метода Spring автоматически создает экземпляр EntityManager, стартует транзакцию и завершает ее после выполненения метода или откатывает в том случае, если при выполнении метода возникло исключение).

Класс beans.Book аннотирован для того, чтобы EntityManager знал, каким образом его экземпляры нужно сохранять/извлекать в/из БД. Кроме того, в файле META-INF/persistence.xml описано, какой провайдер JPA и с какими параметрами будет использоваться. В данном случае используется Hibernate, который помимо стандартного JPA API имеет также собственный API, пример использования можно взять здесь, рядом лежит более простой пример использования Hibernate без Spring, а тут - пример совсем простого приложения для работы с БД без всяких фреймворков с использованием аналога спрингового уровня абстракции над JDBC - Jakarta Commons DbUtils.

Теперь о приложении с web-интерфейсом для бина bookManager. Как правило, такого рода приложения пакуются в WAR и размещаются в одном из сервлет-контейнеров. В случае использования Spring контекст инициализируется и закрывается сервлетом. Такая схема представляется вполне логичной для web-ориентированных приложений, особенно в том случае, когда в одном контейнере предполагается размещать множество web-приложений.

В моем случае это не так: web-часть приложения сравнительно небольшая по сравнению с основной логикой, приложение является единственным на хосте, и мне хочется конфигурировать http-сервер в том же контексте, что и все приложение. Чем, в конце концов, мои бины, бины Spring, бины дополнительных библиотек отличаются от бинов http-сервера?

Если бы мне требовалась загрузка и выгрузка модулей без остановки всего приложения, я, возможно, обратил бы внимание на совсем недавно появившуюся SpringSource Application Platform, которая использует стандарт OSGi, однако пока это не нужно, проще описать бины http-сервера прямо в контексте.

Я не пробовал встраивать Tomcat в контекст Spring, Jetty встраивается без проблем, т.к. его основные классы удовлетворяют спецификации JavaBeans (если бы это и было не так, можно было бы написать небольшую обертку), а для встроенного в Java 1.6 http-сервера такая обертка уже есть.

Приложение интенсивно использует технологию AJAX, которая позволяет отделить клиентскую логику от серверной - взаимодействуют они по протоколу JSON-RPC. Существует единственная полная реализация JSON-RPC для Java - jabsorb, но она использует в качестве транспорта сервлеты, не реализованные во встроенном в Java 1.6 http-сервере. Существует также JSON-lib для сериализации JavaBeans в JSON, транспорта там просто нет, но его можно реализовать по аналогии с описанным здесь способом.

Итак, в контексте приложения определен бин httpServer с двумя http-контекстами:

staticHttpHandler - выдает статические страницы по имени файла
jsonRpcHttpHandler - отвечает на запросы JSON-RPC к бинам, перечисленным в свойстве services

Клиентов целых два: один использует для отрисовки данных стандартные теги html, другой использует библиотеку виджетов ExtJS. Для формирования запросов JSON-RPC оба используют реализацию от jabsorb.

Ну и наконец итоговое приложение BookManager - в нем объединены возможности двух предыдущих: книги сохраняются в БД и извлекаются оттуда, класс tools.JsonRpcHttpHandler переписан и поддерживает базовую http-авторизацию, которая может быть использована двумя способами:

для ограничения доступа определенных групп пользователей к сервисам
для получения методом сервиса информации о пользователе, который его вызвал

На этом все. Некоторые релевантные обсуждения, долго сподвигавшие и таки сподвигнувшие меня написать этот текст, можно найти здесь (там же жалкие попытки оправдать включение библиотек в состав проекта, более настойчивые попытки объяснить, зачем нужен Spring, а также некоторые уже неактуальные вещи вроде Jetty, вместо которого я сейчас использую встроенный в Java 1.6 http-сервер):

Fax/SMTP gateway для CallWeaver

2008-08-27T10:18:00.010+03:00

Задача: отправить факс путем отправки письма с вложенным ps/pdf/tif, принять факс в виде почтового сообщения с вложением. Инструменты - CallWeaver и какой-то враппер для ОGI и Manager API на Python, который я вовремя не опакетил, таская с собой, а теперь уж и забыл, откуда взял (да, я понимаю, что я неправ, но вот только сейчас руки дошли хотя бы до публикации решения). Архив со скриптами можно взять здесь.

Работает оно следующим образом. От локального отправителя письмо с вложением получает MTA и передает его на stdin скрипту fax-send.py. Скрипт делает из файла tiff и с помощью Originate коммутирует вызываемого внешнего абонента (контекст [call-fax-send], если не дозвонились, вызывается fail-fax.py) и факс(контекст [fax-send], о результате прохождения факса отправителю сообщает check-fax.py). Параметры передаются через Variable.

Упомянутые контексты описаны так:

[call-fax-send]
exten => 0,1,NoOp(Calling ${RECIPIENT} for sending fax)
exten => 0,2,Dial(SIP/${RECIPIENT}@${PEER},25)
exten => 0,3,NoOp(${DIALSTATUS})
exten => 0,4,DeadOGI(fail-fax.py)

[fax-send]
exten => 0,1,NoOp(Sending file ${FILE} as fax from ${SENDER} to ${RECIPIENT}@${PEER} with NOTIFY=${NOTIFY})
exten => 0,2,GotoIf($[${NOTIFY}=Yes]?3:6)
exten => 0,3,Playback(fax)
exten => 0,4,Playback(beep)
exten => 0,5,Wait(2)
exten => 0,6,Set(LOCALSTATIONID=CallWeaver)
exten => 0,7,Set(LOCALHEADERINFO=CallWeaver Fax)
exten => 0,8,TxFAX(${FILE})
exten => h,1,NoOp(RX: REMOTESTATIONID is ${REMOTESTATIONID})
exten => h,2,NoOp(RX: PHASEESTATUS is ${PHASEESTATUS})
exten => h,3,NoOp(RX: PHASEESTRING is ${PHASEESTRING})
exten => h,4,DeadOGI(check-fax.py)

Локальный же получатель факсов переадресует внешнего отправителя в контекст [fax-receive], там получившийся файл подбирает read-fax.py, он же сообщает о неудаче.

Контекст для приема факсов:

[fax-receive]
exten => _0.,1,Set(SENDER=${CALLERID(num)})
exten => _0.,2,Set(RECIPIENT=${EXTEN:1})
exten => _0.,3,Set(LOCALSTATIONID=Vertol EXPO)
exten => _0.,4,Set(LOCALHEADERINFO=Vertol EXPO Fax)
exten => _0.,5,Set(FILE=/data/callweaver/fax-receive/${UNIQUEID}.tif)
exten => _0.,6,RxFAX(${FILE})
exten => h,1,NoOp(RX: REMOTESTATIONID is ${REMOTESTATIONID})
exten => h,2,NoOp(RX: PHASEESTATUS is ${PHASEESTATUS})
exten => h,3,NoOp(RX: PHASEESTRING is ${PHASEESTRING})
exten => h,4,DeadOGI(read-fax.py)

Отлов исключений сделан только там, где без него совсем грустно (например, MTA лучше не знать, что внутри fax-send.py приключилось что-то нехорошее). В OGI невозможность удалить файл, например, ни к чему плохому не приводит.

Да, о поддержке факсов в CallWeaver читать здесь.

CallWeaver из коробки

2008-08-27T08:44:00.022+03:00

В дополнение к предыдущему сообщению хочу добавить, что ALT Linux 4.0 Server Lite - один из немногих дистрибутивов, в которых CallWeaver работает практически из коробки и не слишком устарел (ну а если вдруг, то я его майнтейнер :) ). После установки достаточно, не вынимая установочного диска, сказать:

# apt-get install callweaver callweaver-sounds freemusic-signate

и прочесть файл /usr/share/doc/callweaver-1.2/QUICKSTART.ru_RU.UTF-8. Процитирую, пожалуй, его содержимое:

Введение
========

CallWeaver - это IP PBX, форк проекта Asterisk, причинами создания которого послужили 
организационные (зависимость от компании Digium, двойное лицензирование) и технические 
(зависимость от zaptel, отсутствие поддержки T.38 и т.д.) проблемы последнего. Подробнее - 
http://www.callweaver.org/wiki/CallWeaver


Описание конфигурации по умолчанию
==================================

CallWeaver реализован в виде загрузчика с минимальной функциональностью и набора модулей 
расположенных в каталоге /usr/lib/callweaver/modules, которые необходимо описать в файле 
modules.conf. В этом файле отключена автозагрузка модулей, а вместо этого явно указаны 
минимально необходимые модули.

Загрузка модуля chan_sip для поддержки протокола SIP по умолчанию закомментирована. 
При загрузке модуль chan_sip читает файл sip.conf, в котором описаны:

* общие настройки в секции [general]
* собственные абоненты в секциях [101] и [102]
* выход во внешний мир - параметры подключения к оператору sipnet.ru в секции [sipnet] 
и параметр register в секции [global] - в качестве {account} и {password} должны быть 
указаны реальные параметры, выданные оператором

Правила коммутации собственных абонентов друг с другом и с внешним миром описаны в файле 
extensions.conf. Правила оформляются в виде контестов, возможно использующих друг друга 
с помощью include. В контексте [local] описан вызов процедуры Hello с проигрыванием 
звукового файла (файлы находятся в пакете callweaver-sounds) при наборе 100 и вызов 
соответствующих внутренних абонентов при наборе 1ХХ (X - любая цифра от 0 до 9). 
Абоненты были предварительно описаны в файле sip.conf, и для них был указан контекст 
[office] - это значит, что им разрешено выполнять действия, описанные в этом контексте, 
т.е. во вложенном в него [local], а также набирать XXX. (. - любое количество любых 
цифр) - при этом вызов будет выполняться c использованием [sipnet] из sip.conf. 
В контекст [incoming] на номер 100 (как указано в параметре register в sip.conf) 
поступают входящие вызова с sipnet.ru

Более сложные примеры настройки доступны в пакете callweaver-docs в каталоге samples.


Как подключиться и начать использовать CallWeaver
=================================================

В ALT Linux есть несколько софтфонов, поддерживающих протокол SIP, с помощью которых 
можно подключиться к CallWeaver - ekiga, twinkle, sflphone. Для подключения необходимо 
сначала раскомментировать загрузку модуля chan_sip в modules.conf и запустить CallWeaver 
с помощью service callweaver start. В софтфонах необходимо создать учетную запись, указав 
в качестве SIP Proxy адрес сервера с запущенным CallWeaver, а в качестве имени и пароля - 
параметры из секций [101] и [102] файла sip.conf. После этого с каждого софтфона можно будет 
набрать 100 и услышать звуковой файл или набрать 101 или 102 и услышать друг друга. Если 
настроено подключение к sipnet.ru, можно позвонить во внешний мир или принять вызов снаружи 
и проиграть для него звуковой файл.

Для наблюдения за работой CallWeaver можно подключится к его консоли с помощью callweaver_cli. 
То, что будет видно на консоли, нельзя протоколировать стандартным образом, но, поскольку 
для подключения к серверу CallWeaver используется UNIX-сокет, можно использовать конструкцию, 
подобную socat -u UNIX-CONNECT:/var/run/callweaver/callweaver.ctl STDOUT

ALT Linux 4.0 Server Lite - неофициальная сборка

2008-08-26T21:19:00.014+03:00

Долгое время, отвечая на вопрос "а что мне лучше поставить на сервер?", я пребывал в некотором замешательстве. С одной стороны, было бы странно мне, как члену ALT Linux Team, советовать что-либо отличное от дистрибутивов ALT Linux. С другой стороны, ни один из официальных и неофициальных дистрибутивов не отвечает (точнее, до сих пор не отвечал) моим собственным представлениям о том, как должен выглядеть серверный дистрибутив общего назначения.

А представления мои таковы: на сервере не должно быть ничего лишнего (т.е. сервисов, которые не будут использоваться). Я не использую Alterator, предпочитая делать все руками и скриптами, и не далеко не на всех серверах использую OpenVZ, поэтому ALT Linux 4.0 Server и тем более ALT Linux 4.0 Office Server практически для всех моих задач требуют основательной чистки после установки.

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

И тут можно вспомнить, что вообще-то ALT Linux - это не дистрибутив, а сундук с инструментами для построения дистрибутивов. Штатным инструментом для сборки специализированных дистрибутивов в настоящее время является mkimage. С его помощью, а также с помощью участников рассылки devel-distro (которые совсем недавно перебрались сюда из devel и devel-conf) и был изготовлен так называемый ALT Linux 4.0 Server Lite.

Собран он на пакетной базе branch/4.0. В свежеустановленной системе отсутствуют alterator и ovz, потушен portmap (т.к. nfs нужен не всем), поднят acpid и загружен модуль button для корректного выключения системы кнопкой power (в официальном ALT Linux 4.0 Server эта фича уже не помню почему отсутствовала).

Доступны iso для архитертур i586 и x86_64.

Шаг выбора дополнительного ПО из инсталлера исключен, дополнительное ПО предлагается устанавливать с помощью apt уже после установки, перечень дополнительного ПО здесь.

Замечания и пожелания по составу ПО принимаются (уже поступила просьба добавить все, что имеет отношение к pppoe).

В дальнейших планах - всерьез посмотреть на connexion/ncsh и, возможно, заменить им дефолтный etcnet.