пятница, 18 сентября 2009 г.

Fedora 11 и Palm OS

Последнее время синхронизировал свой палм T3 исключительно посредством дата-кабеля, хотя когда-то активно пользовался беспроводным методом (федора 6-8).
Скажу сразу, в 11 федоре немного накосяцили, убрав конфигурацию демона dund и скрипт его запуска.
Несколько слов о прогрессе. В той же 11 федоре сделано очень много для нормальной поддержки всевозможных блютус устройств. Появился даже очень продвинутый менеджер blueman - http://blueman-project.org, но даже его средсвами "завести" морально устаревший Palm T3 (Palm Zire 72 и наверное почти все новые пальмы также) не удалось. А дело в следующем - пальмы не умеют быть клиентом (PANU) блютусной сети. Могут только с помощью pppd демона, где dund был связующим звеном.
Собственно, что мы получим, выполнив указанные ниже шаги - интернет на пальме, и блютус-синхронизацию.
Приступим-с.
1. Создаем файл с конфигом для pppd
cat /etc/ppp/peers/dun
115200
noipdefault
proxyarp
ktune
192.168.20.54:192.168.20.145 # server : client
ms-dns 192.168.1.1
netmask 255.255.255.0
local
noauth
nodefaultroute
noipx
debug
asyncmap 0
2. Запускаем как суперпользователь dund (можно скрипт написать)
dund --listen --persist -s call dun
В принципе все, можно добавить на пальме соединение к локальной сети через блютус, ввести любые логин и пароль и делать синхронизацию. Чтобы получить доступ к интернету - следующие шаги.

3. Выполняем настройку системы
echo 1 > /proc/sys/net/ipv4/ip_forward
/sbin/iptables -t nat -F
/sbin/iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
4. Советую также посмотреть ресурс http://www.whizoo.com/apps.php#freeware - для блютус-синхронизации есть полезная утилита Net Sync, freeware :).


PS. часть материалов почерпнута здесь:
http://easylinux.ru/node/177
http://znark.com/blog/2005/12/16/bluetooth-hotsync-with-linux
http://silverghost.org.ua/2009/01/07/razdacha-interneta-na-telefon-cherez-bluetooth-part-1/
http://en.opensuse.org/Syncing_Palm_Devices_using_Bluetooth

пятница, 8 мая 2009 г.

SVN + LDAP + HTTPD

Теория. Чтобы управлять доступом к СВН репозиторию, можно пользоваться списками доступа, как это описано практически во всех руководствах по СВН. Текстовый файл, всё просто и ясно. Чтобы не создавать его руками, можно использовать одну из десятка аналогичных найденых на freshmeat.net. Лично я пользовался USVN.
Прошло время, и для авторизации я начал использовать LDAP, но разрешения по-прежнему раздавал USVN. Чтобы пользоваться исключительно LDAP, я создал специальную группу ou=svn,ou=Groups,dc=domain,dc=com и добавил в нее нужных мне людей.
И сразу проблема. Стоит добавить пользователя в эту группу, апач (httpd) отказывается пускать свеже-добавленного пользователя, пока не будет перезапущен. При чем с текстовыми файлами такой проблемы не наблюдалось - как только добавил пользователя в список доступа - он тут же получает доступ. Такой ход событий мне совсем не нравился, и причина была найдена. Кэширование LDAP-записей апачем всему виной. Чтобы решить проблему, пришлось запретить кэширование совсем. Не знаю как это отразиться на крупных инсталяциях httpd+mod_svn_ldap, но я пока ничего страшного не заметил.
Итак, в конфигурацию сервера добавляем строку:
LDAPOpCacheEntries 0
Настройка самого mod_svn, прописанная в конфигурации виртуального хоста может быть следующей:

'<'Location'>'
ErrorDocument 404 default
DAV svn
SVNParentPath /var/svn
SVNListParentPath off

AuthName "svn"
AuthType Basic
AuthBasicProvider ldap
AuthzLDAPAuthoritative on
AuthLDAPUrl ldap://localhost/ou=Users,dc=domain,dc=com?uid
AuthLDAPGroupAttribute memberUid
AuthLDAPGroupAttributeIsDN off
require ldap-group cn=SVN,ou=Groups,dc=domain,dc=com

'<'/Location'>'
Собственно, теперь можно отказаться от услуг "третьих" программ по управлению доступом к SVN репозиторию.

пятница, 17 апреля 2009 г.

модификация Endian Firewall Community 2.2

В свое время мне понадобилось обновить ntop на шлюзе с этой платформой (2.2rc3) до последнего релиза.
Решил этот вопрос разворачиванием под VmWare 2.2rc3 бокса и накатыванием девел-пакетов с http://www.endian.com/en/community/download/updates-and-source/ .
Также пришлось порыться в архиве CentOS 4.6 - http://vault.centos.org/4.6/updates/i386/RPMS/ и http://www.stellarcore.net/downloads/ чтобы доставить недостающих. Собрал ntop, скопировал бинарники на реальную систему и пользовался. Приблизительно в то же время, поставил на шлюз и vnstat - оч удобную утилиту сбора суммарной статистики по трафику.
Но вот вышла новая версия, умеющая делать красивые таблички и графики - http://humdi.net/vnstat/cgidemo/. У меня даже вознилка идея встроить ее в стандартный веб-интерфейс Endian.
Итак:
Разворачиваем исходники vnstat в девел-боксе. Доставляем всё, что нужно для сборки (make all - чтобы собрался vnstati), собираем, архивируем vnstat, vnstati, vnstat.conf и переносим на рабочую машину.
Сетапим vnstat согласно инструкций. Также, если хочется красивых графиков, копируем vnstat.cgi (он в архиве в папке examples) в /home/httpd/cgi-bin и создаем в том же каталоге файл menu-vnstat.pl следующего содержания:

#!/usr/bin/perl
#
#

require '/var/efw/header.pl';
my $item = {
'caption' => _('VnStat Traffic Accounting'),
'enabled' => 1,
'uri' => '/cgi-bin/vnstat.cgi',
'title' => _('Network Traffic Accounting'),
'helpuri' => 'efw.services.html#efw.services.ntop',
};

register_menuitem('04.services', '07.vnstat', $item);

1;
После рефреша разлела Service веб-интерфейса Endian Firewall - https://111.222.333.444:10443/cgi-bin/dhcp.cgi можно будет лицезреть под пунктом Traffic Monitoring новый пункт Network Traffic Accounting, который покажет нам красивые суммарные таблички и графики.

Ах да, чуть не забыл - в файле vnstat.cgi нужно подправить декларацию интерфейсов, которые мы хотим мониторить/показывать.

четверг, 8 января 2009 г.

конфликт двух томкатов

Речь идет о запуске двух независимых процессов tomcat в рамках одного сервера (реального или виртуального - не имеет значения).
Проблема следующая - запускаем первый томкат - полёт нормальный. Запускаем второй - не работает. Перезапускаем второй - неработает ни один, хотя по-отдельности каждый работает.
Суть проблемы - конфликт внутренних портов управления сервером. Файл server.xml, порты 8005 и 8009. Для первого оставляем как есть, а для второго изменяем на любые свободные. Например 8805 и 8809. После перезапуска должно заработать сразу и надолго.
Впервые столкнулся когда поставил VMWare Server 2 на систему с работающим томкатом. Там конфликтовать начала веб-морда работающая под томкатом.
Ссылка с советом на ВМваревском форуме - http://kb.vmware.com/selfservice/microsites/search.do?cmd=displayKC&docType=kc&externalId=117-117272xml&sliceId=&docTypeID=DT_COMMUNITIES_1_1&dialogID=13848989&stateId=1 0 13850899