Новый ALT Linux Live

Обновил ALT Linux Live до почти уже вышедшего branch/p8, комплектация немного изменилась:

• altlive-i586.iso
• altlive-i586.tar
• altlive-x86_64.iso
• altlive-x86_64.tar

CD/DVD-носители уже не слишком актуальны, поэтому iso выкладываются главным образом для запуска в виртуальных средах. Архивы tar предназначены для записи образов на USB flash. В каждом образе по прежнему есть 3 варианта загрузки: console, openbox, xfce. Все варианты (включая консольный) теперь используют systemd. После знакомства с аналогами инит-скриптов, появления systemd-networkd и systemd-nspawn / machinectl, а также после выхода RHEL7 и Ubuntu LTS с systemd я наконец проникся.

Образы собираются из нового профиля, т.к. старый оброс различными артефактами и стал слишком сложным. Кроме того, завел наконец вики-страничку с чуть более пространным описанием.

Автозапуск в ALT Linux Live

Снова обновил ALT Linux Live до актуального branch/t7, образов стало чуть больше:

• altlive-console-t7-i586
• altlive-openbox-t7-i586
• altlive-xfce-t7-i586
• altlive-console-t7-x86_64
• altlive-openbox-t7-x86_64
• altlive-xfce-t7-x86_64

В образ с openbox добавлен автозапуск панели tint2 с минимальной конфигурацией (пиктограмма для запуска терминала, список задач, отображение текущей даты/времени) и скриптов из /image/hooks.openbox непосредственно после запуска панели. Аналогичным образом все образы умеют запускать скрипты из /image/hooks.system - но уже с полномочиями суперпользователя (спасибо gns@).

Все это полезно при загрузке корня средствами propagator по NFS или с локального USB-диска - тогда рядом со сжатым корнем можно положить скрипты для дополнительной индивидуальной настройки загружаемой системы. Краткая инструкция по загрузке с NFS и USB внутри образов, код по прежнему в репозитарии m-p-l в бранче autoconf.

Новая сборка ALT Linux Live

Еще раз обновил ALT Linux Live до только что вышедшего branch/t7, снова доступны образы:

• altlive-console-t7-i586
• altlive-xfce-t7-i586
• altlive-console-t7-x86_64
• altlive-xfce-t7-x86_64

Хоть я и обещал, что предыдущая сборка будет последней, перебраться с m-p-l на m-p пока не вышло.

В процессе пришлось определяться с отношением к systemd. Я не готов бежать впереди паровоза RHEL7 и даже на новых серверах пока не планирую его использовать, поэтому на собственном десктопе - тоже. Соответственно, в этих образах по-прежнему используется sysvinit, сменные носители монтируются в /media, ipv6 выключен, сетевые интерфейсы именуются как eth* - что еще нужно ретрограду? :)

Записи в DNS из NetXMS

Отказался от dnsmasq в пользу PowerDNS в качестве внутреннего DNS-сервера. Причина - разнообразие бакендов в PowerDNS, из которых самым полезным для меня оказался Generic PgSQL backend. Теперь внутренние адреса хостов разрешаются в имена и наоборот не из файла /etc/hosts, а из БД внутренней системы мониторинга NetXMS, в которой все важные хосты гарантированно присутствуют.

Подробности в статье на Хабре - нужно же мне было каким-то образом добыть возможность комментировать разные интересные вещи, которые там, бывает, появляются :)

FreeSWITCH users via LDAP

Потребовалось авторизовать пользователей FreeSWITCH через LDAP вместо XML Directory. Оба имевшихся в комплекте модуля оказались со странностями:

• mod_ldap вообще не похож на рабочий, код просто недописан
• mod_xml_ldap пытается быть слишком универсальным и предполагает использование собственной схемы, в которой для одного пользователя предполагается иметь по записи для каждого параметра вместо очевидного, казалось бы, решения - добывать необходимую для авторизации информацию прямо из имеющихся атрибутов записей с objectClass=person

Впрочем, у FreeSWITCH есть универсальное решение для 99% интеграционных задач - mod_xml_curl + внешний HTTP-сервер (или один из поддерживаемых встраиваемых скриптовых языков). Беда в том, что это решение затягивает. Меня затянуло до встраивания LDAP-сервера :).

Затем я пришел в себя и решил все же еще раз вчитаться в код нативных модулей и исправить/переписать тот, который окажется более вменяемым. Все оказалось проще - второй модуль уже почти переписали и, видимо следуя общей традиции поддержки LDAP, таки бросили уже почти на финише.

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

Рок-н-ролл мертв, а Perl еще нет

Никогда не предполагал, что окажусь в шкуре Perl-программиста - но это случилось. На новом месте (региональная сеть NGN/IMS) мне досталась в наследство куча перлового кода (предбиллинг, управление подключениями, устройствами, услугами) и полтора программиста, способные значительным усилием воли его читать, а в крайнем случае даже править. Автора этого безобразия большей части кода я уже не застал, хотя до того успел пообщаться с ним, находять по другую сторону баррикад и подключая Asterisk/CallWeaver и FreeSWITCH к операторскому оборудованию.

Конечно, я надеялся все переписать все на Java/Groovy, однако вовремя остановился - это оказалось слишком дорого и больно. В итоге мы остановились на Perl и это позволило:

• Постепенно переписывать работающий код по частям и повторно использовать некоторый унаследованный код после минимального рефакторинга
• Не переучивать коллег - разве что более осознанно подойти к coding conventions

Пришлось, правда, переучиваться самому - плевался поначалу, но втянулся.

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

#!/usr/bin/perl

package MyModule;

sub calculate {
  ...
}

calculate(@ARGV) unless caller();

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

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

• Юниксовые демоны, написанные с использованием Proc::Daemon (Net::Daemon оказался слишком умным) и запускаемые инит-скриптом в стиле SysV (никаких новомодных systemd)
• Web-приложения, использующие PSGI согласно последней моде

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

• Опираясь исключительно на спецификацию - в этом случае разбор URL, параметров и заголовков, возвращение требуемого Content-Type, шаблонизация и многое другое становятся проблемами самого разработчика
• Используя Plack - эталонную реализацию спецификации, которая предлагает стандартизованный способ декомпозиции приложений (в т.ч. выделения Middleware и специального DSL для настройки и склеивания разных приложений в одно), также обросла кучей разных полезных плагинов
• Используя один из полноценных web-фреймворков, хотя на самом деле их, похоже, всего лишь 2 - Dancer и Mojolicious

Я бы рассмотрел всерьез первый или второй вариант, а также запуск приложения под управлением какой-нибудь минимальной реализации на С вроде uwsgi (она приглянулась мне больше evpsgi, патча для nginx и модуля для Apache), если бы у нас были серьезные требования к производительности. Однако к web-интерфейсу не предполагалось публичного доступа, зато требования к простоте разработки очень даже предъявлялись. В итоге был выбран Mojolicious и скорее по иррациональным соображениям - в нашей местности обитают люди, которые очень его любят.

Сейчас весь старый код работает на последнем оставшемся сервере с Slakware 12.2.0 (который поначалу было едва справлялся с нагрузкой а сейчас почти отдыхает) и потихоньку переползает на новые сервера с ALT Linux. В последнем пришлось обновить Mojolicious, Plack и Starman, который используется в качестве самостоятельного web-сервера без всяких фронтендов типа nginx и тем более apache. Я также опакетил evpsgi и начал было перепиливать сборку uwsgi, однако быстро потерял к ним интерес - поэтому до репозитария они не добрались.

NetXMS network monitoring system

Собрал в Сизиф и t6/branch систему мониторинга NetXMS, привлекшую к себе внимание даже не столько эффективной архитектурой, сколько в первую очередь своей консолью:
Она кажется более наглядной и при этом достаточно простой для сменных инженеров по сравнению с любым веб-интерфейсом (ну или как минимум по сравнению со знакомыми мне OpenNMS и Zabbix). Благодаря Eclipse/RAP ее можно запустить не только в качестве кроссплатформенного десктопного приложения, но и через веб тоже - хотя работать с ней таким образом все же менее комфортно.

Да, апстрим добрый и отзывчивый: баги исправляют, фичреквесты реализуют (или, по крайней мере, задумываются), по-русски говорят.

ALT Linux на OMAP3 BlueShark

Попала в руки плата Atoll-Deluxe v4 с процессорным модулем OMAP3 BlueShark и LCD-панелью NEC E170632:
На борту уже имелся Ångström Linux, однако захотелось получить более привычное окружение. Имевшаяся в комплекте загрузочная SD-карта была разбита на два раздела:

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

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

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

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

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

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

• altlive-console-t6-i586
• altlive-xfce-t6-i586
• altlive-console-t6-x86_64
• altlive-xfce-t6-x86_64

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

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

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

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

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

• Нельзя отменить запрос
• Нет эффективной реализации VACUUM

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

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

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

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

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

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

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

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

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

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

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

Java services with Maven

Наконец-то я научился использовать 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

Немного доработал десктопную часть 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 для толстых бездисковых клиентов

Использовать современные рабочие станции с 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

Озаботившись скриптовой обвязкой для очередной инсталляции, где выразительности 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

Давно ожидаемый комбинаторый взрыв возможных конфигураций 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

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

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

ALT Linux Live Lite

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

На 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 не занимается - это следующая задача для другого инструмента.