Теория. Чтобы управлять доступом к СВН репозиторию, можно пользоваться списками доступа, как это описано практически во всех руководствах по СВН. Текстовый файл, всё просто и ясно. Чтобы не создавать его руками, можно использовать одну из десятка аналогичных найденых на 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 репозиторию.
В свое время мне понадобилось обновить ntop на шлюзе с этой платформой (2.2rc3) до последнего релиза.
Решил этот вопрос разворачиванием под VmWare 2.2rc3 бокса и накатыванием девел-пакетов с
http://www.endian.com/en/community/download/updates-and-source/ .
Но вот вышла новая версия, умеющая делать красивые таблички и графики -
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 нужно подправить декларацию интерфейсов, которые мы хотим мониторить/показывать.
Речь идет о запуске двух независимых процессов 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
Каджый, мало-мальски использующий для решения определенных задай
crontab или просто
cron, знаком с сообщениями о "проделанной работе". Конечно, они будут приходить только если корректно настроена почтовая система. У меня именно такой случай, и я регулярно (раз в сутки) получал сводки типа:
Return-Path:
Delivered-To: me@domain.com
Received:
From: root (Cron Daemon)
To: root
Subject: Cron run-parts /etc/cron.daily
/etc/cron.daily/ххх.sh:
А с возрастанием задач, "навешанных" на
крон, количество такий сообщений будет возрастать. А не проще ли, настроив такие задачи, получать не текст о выполнении, а сводку если что-то пойдет не так??
Как это сделать? - сравнивать лог выполнения текущей задачи, с логом выполнения предыдущий раз!
Крон отправляет на почту все сообщения stdout, stderr возникшие в процессе своего выполнения. Следовательно, перенаправив этот вывод в текстовый файл и добавив процедуру сравнения, можно легко избавиться от такой "назойливости"
крона.
Выглядеть скрипт может следующим образом:
!#/bin/sh
# избавляемся от сообщений с ошибками при первом запуске
touch /some/place/old.log
# "документируем" все действия вызываемых программ/скриптов
/usr/local/sbin/....sh &> /some/place/curr.log
или
for ... &>> /some/place/curr.log
# сравниваем что изменилось с прошлого раза
diff /some/place/curr.log /some/place/old.log
# переносим текущий лог действий в лог для сравнения в следующий раз
mv -f /some/place/curr.log /some/place/old.log
Столкнулся с проблемой, когда после обновления БИОС в плате ASUS P5S800-VM система утратила способность самостоятельно перезагрузиться. Пляски с бубном желаемого результата не дали. Настройки БИОС тоже никак не повлияли. Решение нашел на форуме
linuxquestions.org.
Итак. Решение проблемы - параметр для ядра системы
reboot=bios
Сразу прописать в grub.conf.
