Показаны сообщения с ярлыком telecom. Показать все сообщения
Показаны сообщения с ярлыком telecom. Показать все сообщения

суббота, 1 декабря 2012 г.

FreeSWITCH users via LDAP

Потребовалось авторизовать пользователей FreeSWITCH через LDAP вместо XML Directory. Оба имевшихся в комплекте модуля оказались со странностями:
  • mod_ldap вообще не похож на рабочий, код просто недописан
  • mod_xml_ldap пытается быть слишком универсальным и предполагает использование собственной схемы, в которой для одного пользователя предполагается иметь по записи для каждого параметра вместо очевидного, казалось бы, решения - добывать необходимую для авторизации информацию прямо из имеющихся атрибутов записей с objectClass=person
Впрочем, у FreeSWITCH есть универсальное решение для 99% интеграционных задач - mod_xml_curl + внешний HTTP-сервер (или один из поддерживаемых встраиваемых скриптовых языков). Беда в том, что это решение затягивает. Меня затянуло до встраивания LDAP-сервера :).

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

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

пятница, 22 июня 2012 г.

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

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

Конечно, я надеялся все переписать все на Java/Groovy, однако вовремя остановился - это оказалось слишком дорого и больно. В итоге мы остановились на Perl и это позволило:
  • Постепенно переписывать работающий код по частям и повторно использовать некоторый унаследованный код после минимального рефакторинга
  • Не переучивать коллег - разве что более осознанно подойти к coding conventions
Пришлось, правда, переучиваться самому - плевался поначалу, но втянулся.

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

package MyModule;

sub calculate {
  ...
}

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

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

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

четверг, 10 мая 2012 г.

NetXMS network monitoring system

Собрал в Сизиф и t6/branch систему мониторинга NetXMS, привлекшую к себе внимание даже не столько эффективной архитектурой, сколько в первую очередь своей консолью:

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

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

четверг, 12 августа 2010 г.

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

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

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

четверг, 13 августа 2009 г.

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