Как изменить комментарии к коммиту?

Вот недавно нарыл на просторах его великого и необъятного следующую штучку:

svn pe svn:log -r 1234 --revprop

Данная команда позволяет изменять комментарии к коммитам (по причине кривости или опечаток). Я, конечно же, сразу захотел её использовать, но репозиторий со мной не согласился:

svn: Repository has not been enabled to accept revision propchanges;
ask the administrator to create a pre-revprop-change hook

Ну лечится это довольно просто: идём в папку /var/spool/svn/имя_репозитория/hooks/ и там cp pre-revprop-change.tmpl pre-revprop-change и chmod +x pre-revprop-change , потом перезапускаем svnserve и вуаля :)

Lighttpd + WebDAV

Ставим пакеты:

apt-get update
apt-get install -y lighttpd
apt-get install -y lighttpd-mod-webdav

Добавляем в конфиг файл

vi /etc/lighttpd/lighttpd.conf

$HTTP["url"] =~ "^/dav($|/)" {
webdav.activate = "enable" # allow module
webdav.is-readonly = "disable" # enable write
webdav.sqlite-db-name = "/var/run/lighttpd/lighttpd.webdav_lock.db" # access to locaks and metadata database
}

Около блока "server.modules" ищем строку "mod_webdav" и убираем знак диеза слева, если он установлен.

После этого нам требуется создать хотя бы одну папку с доступом по WebDAV. Корнем веб сервера устанавливается папка /var/www, если вас устраивает такое положение, можете её так и оставить, в противном случае можете изменить её местоположение в конфиг файле. После этого создаем папку для WebDAV доступа:

mkdir /var/www/dav
chown www-data:www-data /var/www/dav

Ну и напоследок применяем настройки:

/etc/init.d/lighttpd restart

После это можно каким-нить WebDAV клиентом (я использовал nd) попробовать поиграться с папкой http://ваш_сайт/dav

Я использовал версию (в случае же проблем, обновляемся на более новую):
lighttpd-1.4.13 (ssl) - a light and fast webserver
Build-Date: Apr 15 2008 08:23:10

Играемс:
nd -d http://домен.ru:81/dav/suxx.ics --- удаление файла
nd -p wammu.log http://домен.ru:81/dav/suxx.log -- загружаем файл
nd -m http://домен.ru:81/dav/suxx555.log http://домен.ru:81/dav/suxx.log -- перемещаем файл
nd -v http://домен.ru:81/dav/555suxx.log -- запрос свойств объекта
У меня было выдано:

Status: 0
Last-Modified:
Created:
Size:
Content-Type:
Resource-Type:

Зададим новое свойство:
nd -l http://домен.ru:81/dav/suxx555.log -- блокируем объект

Lock: token="opaquelocktoken:aebb8df4-3321-4604-a8aa-cf69429c2725",
scope="exclusive",
owner-href="",
timeout="Second-600"

nd -u -t opaquelocktoken:aebb8df4-3321-4604-a8aa-cf69429c2725 http://домен.ru:81/dav/suxx555.log -- разлочим объект посредством "ключа", выданного нам при блокировке
nd -k http://домен.ru:81/dav/folder1 -- создаем новую папку

А вот далее интереснее:
nd -e test=12345 http://домен.ru:81/dav/suxx555.log
nd -v http://домен.ru:81/dav/suxx555.log

Name: http://домен.ru:81/dav/suxx555.log
Status: 0
Last-Modified:
Created:
Size:
Content-Type:
Resource-Type:

Как видите, вновь заданное свойство не показывается (хотя в sqlite лайта базе данных оно имеется). Это баг nd / lighttpd или же я туплю ? Попробуем другой WebDAV клиент, пожалуй, это будет cadaver.

nrg@dell:~$ cadaver
dav:!> open http://домен.ru:81/dav
dav:/dav/> propset suxx555.log suxx 777
dav:/dav/> propget suxx555.log suxx
Fetching properties for `suxx555.log':
Value of suxx is: 777

Таки выходит, глюк nd. Ну вот и все, осталось только придумать, для чего использовать такой замечательный протокол :)

Офсайт lighttpd.

This document describes how to establish yourself as a root certificate authority (root CA) using the OpenSSL toolset

Снова ссылка, ибо по чистой случайности наткнулся на готовое решение моей проблемы: ссылка

Документация по Subversion

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

Статья -- сравнение систем контроля версий между собой, здесь расписываются сильные и слабые стороны популярных VCS: RCS, CVS, SVN, Git, Bazaar, Aegis, Monotone.

Большая статья про Subversion:
Первая часть, вторая.

Практическое использование Subversion линк.

Блин, такими темпами скоро не про что писать будет :)

Снова стоит ряд практических задач

1) Во-первых требуется набрать оптимальную софтово-хардварную конфигурацию для относительно недорогого сервера бэкапов (сторадж 1-2 терабайта с рейдом 1+0 или 5)
2) Требуется продумать схему, по которой сервер бэкапов будет максимально универсален и безопасен (в данный момент предполагается использовать rsync поверх ssh). Требуется довольно немного -- механизм инкрементальных (те при обновлении файла тянем только изменившуюся часть, не изменившиеся файлы не трогаем) копий и возможность отката (с точностью до дня / часа) на месяц другой в прошлое.
3) Нужно как-то собирать логи (много-много-много логов!) с нескольких серверов, причем почти все они представляют собой обычные текстовые файлы и о таких вещах как syslog не слышали. Может есть какие централизованные системы сбора логов?
4) Вот ещё такой интересный вопрос -- все отлично знают, что легкие сервера по типу lighttpd и nginx очень хороши для раздачи статики и проксирования FastCGI / http серверов. А вот как будут они себя вести при раздаче очень больших файлов (такая своего рода "мегастатика")? Эдак очередь человек на 200 и раздача файлов по 1-2 гб. Вот если верить тестам на домашней странице Лайта http://www.lighttpd.net/benchmark , то он очень неплох при раздаче. Надо будет на досуге сравнить его с nginx при раздаче таких файлов.
5) А на каком веб сервере работает Akamai ? Пожалуй, это самый просто вопрос. Точно помню, что ATI раздает через них свои дрова, так сейчас и проверим :)

telnet a248.e.akamai.net 80
Trying 217.212.246.104...
Connected to a248.e.akamai.net.
Escape character is '^]'.
HEAD / HTTP/1.0

HTTP/1.0 400 Bad Request
Server: AkamaiGHost
Mime-Version: 1.0
Content-Type: text/html
Content-Length: 216
Expires: Tue, 24 Jun 2008 14:19:44 GMT
Date: Tue, 24 Jun 2008 14:19:44 GMT
Connection: close

Один вопрос решили, осталось узнать, что это за сервер такой (навряд ли открытый, но все же).
6) А я ведь думал, что когда говорили про kernel-based httpd, то это был стеб, казывается нет, прошу по ссылке: http://dir.filewatcher.com/d/Fedora/ppc64/System%20Environment/Daemons/tux-3.2.18-4.ppc64.rpm.88721.html

По этому же поводу довольно интересное обсуждение в apache-talk: http://www.lexa.ru/apache-talk/msg04850.html . Сам я довольно скептически отношусь к такого рода затеям как эта (вставлять в ядро типичный userspace демон! экий страх!), в первую очередь из-за вопроса безопасности (ну вопрос стабильности тут тоже не на последнем месте -- получить kernel panic посреди рабочего дня -- довольно интересно). Но с другой стороны можно сделать специальный сервер для раздачи и отделить его от основных серверов фаервольной стенкой, так как бы он стоял снаружи :) Если даже и взломают, то ничего ценного кроме конфига указанного сервер они не получат.

KLone: каркас для web-программирования на языке C.

Вот довольно давно отрыл вот такую вот весьма извращенную вещь: KLone: каркас для web-программирования на языке C.

Может кому пригодится, у самого пока руки не дошли попробовать.

Списочек легких HTTPD

Вот списочком:

• fnord
• Cthulhu, a non-forking high performance web server
  
• thttpd
  
• my diet libc
  
• lighttpd
• gatling

Сам пока не придумал, для чего их можно использовать... но вот последний умеет CGI, так что можно какую-нить админку на нём довольно легко налабать :)

Пара интересных веб сайтов -- хостинг на Nginx и rss2email

Сегодняшний день оказался довольно плодотворным по части поиска интересных сайтов.
Первый из них вот этот -- http://hosting.dekoda.net/index.html, как я понял из рекламных текстов, они занимаются хостингом на Nginx + MySQL + PHP (через PHP-FPM /* http://php-fpm.anight.org/about.html */ ) + Perl, первые три пункта у меня вопросов не вызвали, танцами и бубнами их можно заставить работать вместе... ну а Перл-то как они прикрутили? Обычный Перл как CGI прикрутить к Нджинксу без бэкэнда можно сказать нереально, остаётся единственный вариант -- подключение его как FastCGI, но тут вылазит куча проблем да и, вообще говоря, данная связка будет потреблять море ресурсов, что в конце-концов приведет к тому, что кто-нибудь из клиентов поест все ресурсы. Хотя с другой стороны предполагаю, что Перл написан на сайте ошибочно, но ради восстановления справедливости все же напишу в техподдержку как заинтересованный клиент :)

Второй сайт -- http://www.rss2email.ru/ представляет из себя типичный (никогда бы не подумал, что так скажу) WEB 2.0 проект. По сути в нём ничего необычного и выделяющегося нету -- просто сайт, где можно заказать перенаправление rss фидов на электронную почту. Но с другой стороны их "интерфейс настройки" ( http://www.rss2email.ru/ ) с моей точки зрения представляет собой идеал интерфейсостроения, ибо там лишь два поля, одно из них адрес -- rss фида, второе -- электронная почта, на которую слать его. Никаких тупых регистраций, никаких CAPTCHA, никаких лицензионных соглашений и прочих гадостей, одно слово -- идеал!

Ну вот, пожалуй, хватит на сегодня о сайтах, что нового найду -- обязательно напишу :)
А в ближайшее время постараюсь расковырять и найти применение встроенному в Нджинкс Перлу (да что интриговать, я его уже нашел -- озвученная в предыдущем посте централизованная авторизация) и попутно выложить аннотации к моим новым модулям на CPAN.

Nginx + HTTP Basic Authentication

Ну тема довольно простая и почти полностью описана в документации (http://sysoev.ru/nginx/docs/http/ngx_http_auth_basic_module.html), но все же опишу некоторые моменты.

Для начала открываем файл nginx.conf и ищем там следующие строки:

location / {
root   html;
index  index.html index.htm;
}

И заменяем их на следующее:

location / {
auth_basic            "closed site";
auth_basic_user_file  htpasswd;

root   html;
index  index.html index.htm;
}

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

Файл паролей положим в папку conf -- conf/htpasswd, его формат таков:

# комментарий
имя1:пароль1
имя2:пароль2:комментарий
имя3:пароль3

Пароли генерируются функцией crypt, также для их создания можно воспользоваться утилитой от веб сервера Apache -- htpasswd, ей мы и воспользуемся.

sudo htpasswd -cbd htpasswd nrg 12345

"-d" -- выбираем криптофункцию "crypt"
"-b" -- указываем считывание имени файла с паролями с командной строки
"-c" -- указываем создать новый файл
htpasswd -- имя вновь создаваемого файла
nrg -- имя добавляемого туда пользователя
12345 -- пароль пользователя

В итоге получаем файлик следующего содержания:

nrg:G8XDed1YWlwlM

И рестартим Нджинкс, после этого при попытке открыть главную страницу сайта должна выскакивать страница авторизации :)

Хм, а вот интересно, можно ли подружить Nginx c PAM или LDAP? А-то держать полтора десятка баз пользователей никакого удовольствия, а так можно было бы все сложить в одну базу. Если у кого есть мысли на этот счет, буду благодарен, если оставите их в комментах (:

Установка nginx из исходников

Вот после долгого затишья я снова тружусь на благо телекома :)
Сегодня мы будем заниматься легким веб сервером nginx (http://sysoev.ru), который мне понадобился для раздачи небольшого количества статики.

Сама установка выглядит довольно тривиально: сливаем дистрибутив 0.6й ветки вот отсюда: http://sysoev.ru/nginx/download.html и ставим тривиальным набором команд :

mkdir -p ~/nginx
cd ~/nginx
wget http://sysoev.ru/nginx/nginx-0.6.31.tar.gz
tar -xf nginx*
cd nginx*
./configure --prefix=/opt/nginx
make
sudo make install

Довольно стандартная схема без всяких сложностей... ну разве configure скрипт попросит вас поставить zlib и pcre, но относить это к сложностям как-то несерьёзно :) Как Вы могли заметить, мы ставим nginx не в саму систему, а в папку /opt/nginx, так как захламлять рабочую систему кучей хлама у меня лично нету никакого настроения.

Ну а теперь стоит вопрос, как нам все это дело удобно использовать (ну не каждый же день руками делать /opt/nginx/sbin/nginx), а в связи с тем, что в поставке nginx я не обнаружил готового скрипта для init.d, то нам придётся его писать или найти готовый (полагаю, второй вариант намного предпочтительнее) :)

Конечно же, я нашел готовый и его немного модифицировал, оригинал же взят отсюда: http://ssh3.livejournal.com/29252.html?thread=32836 , за что большое спасибо автору.

Скрипт управления сервером nginx:

#!/bin/bash

# v.0.0.3
# nginx - This shell script takes care of starting and stopping nginx.
# chkconfig: 345 20 80
# author site: nginx.net, sysoev.ru
# description: nginx [engine x] is light http web/proxy server
#              that answers incoming ftp service requests.
# processname: nginx
# config: /opt/nginx/conf/nginx.conf
# 
# Исходная версия: http://ssh3.livejournal.com/29252.html?thread=32836
# Изменённая версия: nrg [ at ] cpan [ dot ] org ( http://phpsuxx.blogspot.com/ ) 
#

# Source function library.
. /etc/rc.d/init.d/functions

# Source networking configuration.
. /etc/sysconfig/network

# Check that networking is up.
[ ${NETWORKING} = "no" ] && exit 0

RETVAL=0
NGINX=/opt/nginx
CONFIG=$NGINX/conf/nginx.conf
EXEC=$NGINX/sbin/nginx
PID=$NGINX/logs/nginx.pid
PROG=nginx

[ -x $EXEC ] || exit 0

start() {

echo -n $"Starting NGINX: "
# Start daemons.
if [ -e $CONFIG ] ; then
$EXEC -t -c $CONFIG 2> /dev/null
[ $? -eq 0 ] && $EXEC -c $CONFIG &
RETVAL=$?
else
RETVAL=1
fi

if [ $RETVAL -eq 0 ] ; then
echo_success
else
echo_failure
fi

echo

return $RETVAL
}

stop() {
# Stop daemons.
if [ -e $PID ] ; then
echo -n "Shutting down $PROG: "
kill -QUIT `cat $PID`
RETVAL=$?
else
echo -n "Nginx not runned."
RETVAL=1
fi

if [ $RETVAL -eq 0 ] ; then
echo_success
else
echo_failure
fi

echo

return $RETVAL
}


restart() {
# Reload daemons.
if [ -e $PID ] ; then
echo -n "Reload $PROG: "
kill -HUP `cat $PID`
RETVAL=$?
else
echo -n "Nginx not runned."
RETVAL=1
fi

if [ $RETVAL -eq 0 ] ; then
echo_success
else
echo_failure
fi

echo

return $RETVAL
}
# See how we were called.
case "$1" in
start)
start
;;
stop)
stop
;;
restart)
restart
;;
reconfigure)
restart
;;
status)
status $NAME
RETVAL=$?
;;
*)
echo $"Usage: $0 {start|stop|restart|reconfigure|status}"
exit 1
esac

exit $RETVAL

Теперь остаётся добавить скрипт в систему и все заработает,
как это сделать я описывать отдельно не буду, ssh3 отлично описал этот пункт,
поэтому позволю себе немного плагиата :)

Для автоматического страрта при загрузке системы достаточно скопировать
стартовый скрипт nginx в каталог /etc/init.d и выполнить следующие
команды:

#chkconfig --add nginx
#chkconfig --level 345 nginx on


Проверить статус можно командой:
#chkconfig --list | grep nginx
nginx 0:off 1:off 2:off 3:on 4:on 5:on 6:off


Ну вот, вроде, и все, в идеале, конечно, из этого стоило бы собрать deb / rpm пэкадж, но это уже дело каждого.

Подсветка синтаксиса VIM

В один прекрасный момент осознал, что стандартная подсветка синтаксиса (с белым фоном! о ужас!) в моём любимом vim'е меня категорически не устраивает и хочется чего-то чёрного и более приятного для глаз.

Ну что же, недолго побродив по vim.org я нашёл целую кучу цветовых схем, вот наиболее понравившаяся мне wombat

Ссылочка на скачку: http://www.vim.org/scripts/script.php?script_id=1778

Теперь будем перекрашивать гном :)
Вот и Гном перекрашен вот в это: http://gnome-look.org/content/show.php/Murrina-Black?content=46287

А для полного счастья вот и css для моей любимой пастилки http://php.suxx.us/s/paste.org.ru.css :)

ПЫСЫ: тырнет свёл на нет все преимущества тёмного стиля, т.к. постоянное чередование сайтов с белым и чёрным фонами очень сильно убивает зрение, в итоге поставлено было вот это.

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

Довольно часто при тестировании и отладке приходится рестартить апача для рекомпиляции приложения на mod_perl (тому, кто скажет, как от этого избавится или делать без рестарта Апача, буду несказанно благодарен), для чего приходилось использовать либо su, либо sudo.

Сегодня после небольшого ликбеза по sudo перелез на него с su. Но тут незадача -- если набивать sudo apache2ct<ТАБ>, то автодополнение НЕ сработает и придётся набивать название команды ручками, что жутко нервирует, когда кол-во таких "набивов" приближается к сотне за день.

Решений как всегда в линуксе несколько:

1) Прописать в ~/.bashrc

# включаем автодополнение для sudo
complete -cf sudo

2) Либо поступить более кОмплексно и поставить пакет bash-completion, который к указанной фиче предоставит ещё ряд вкусностей, про которые можете прочитать на http://www.debian-administration.org/articles/316

Попутно мне понадобилось внести коррективы в переменную среды PATH, т.к. в моей Сусе по соображениям безопасности в PATH для простых юзеров не включаются директории бинариков */sbin.

Фиксится это одной строкой в указанно ~/.bash_rc:

# добавим sbin в юзерский патч
PATH=/sbin:/usr/sbin:/usr/local/sbin:$PATH

Первая идея была взята с: ссылко

Скачиваем видео с Youtybe посредством wget, sed и linux :)

Вот решил скачать для локального использования давно полюбившийся мне клип группы Леон "Метро 2033".
Искать "ещё один супер пупер качальщик с Ютуба" категорически не хотелось, поэтому довольно быстро было найдено решение, прямо-таки по Unix-way, а именно скрипт на Shell, который скачивает flv и ложит в текущую папку его :)

Скрипт вот:

RAW=`wget -O - $1 | grep 'fullscreenUrl' | sed 's/^.*video_id=//'`
TITLE=`echo $RAW | sed 's/^.*title=//' | sed 's/[^a-zA-Z0-9]//g'`
ID=`echo $RAW |sed 's/&fs.*$//'`
wget -O $TITLE.flv "http://www.youtube.com/get_video.php?hl=en&video_id=$ID"

Взято: http://linux.byexamples.com/archives/302/how-to-wget-flv-from-youtube/#comment-18455


После того, как был слит клип в flv ещё и оказалось, что он отлично играется моим любимым плеером vlc :)

Решение проблемы с Apache2::ModSSL OpenSuse 10.3

При установке данного модуля высыпается несколько проблем -- первая из них, идёт много ругани на отсутствие mod_perl.h, но если путь с этим файликом жёстко прописать в Makefile.PL (который был предварительно сгенерирован посредством perl Makefile.PL, все файлы лежат по пути ~/.cpan/build/Apache2-ModSSL-0.03-некоторые_символы):

INC = -I/usr/include/apache2 -I/usr/include/apache2/modules/perl

То высыпется ещё целая прорва ошибок сборки, которая решается прописыванием путей к заголовочным файлам библиотеки apr:

INC = -I/usr/include/apache2 -I/usr/include/apache2/modules/perl -I/usr/include/apr-1

Ну и конечно же, devel версии пакетов Apache2 и mod_perl должны стоят в системе :)

Немного о CPAN

Как удалить модуль с хранилища модулей (локального, конечно же) CPAN?

В общем случае никак (?), но бывают исключения. В конфигурационном файле CPAN (/usr/lib/perl5/5.8.8/CPAN/Config.pm) есть переменная ('build_dir'), отвечающая за расположение папки для временного хранения модулей перед установкой. Как можно понять, в этой папке хранятся инсталяцонные файлы модулей, которые представляют из себя стандартный комплект -- Makefile.PL / Build.pl и обычно уже созданный Makefile (т.к. данные модули уже были установлены Вами), который и устанавливает модуль в хранилище. А у Данного Make файла присутствует цель uninstall, т.е. можно выполнить make uninstall и либо удалить модуль сразу, либо получить рекомендации для удаления.

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


Конфигурирование CPAN.

CPAN при запуске очень любит доставать вопросами о конфигурации. Чтобы отучить его заниматься сим противным занятием давайте напрямую отредактируем конфиг файл /usr/lib/perl5/5.8.8/CPAN/Config.pm
(его расположение меняется от дистрибутива к дистрибутиву, так что если что проявите смекалку и отыщите его). Ниже привожу свой конфиг файл.


# This is CPAN.pm's systemwide configuration file. This file provides
# defaults for users, and the values can be changed in a per-user
# configuration file. The user-config file is being looked for as
# ~/.cpan/CPAN/MyConfig.pm.

$CPAN::Config = {
'build_cache' => q[100],
'build_dir' => q[/home/nrg/.cpan/build],
'cache_metadata' => q[1],
'cpan_home' => q[/home/nrg/.cpan],
'cpan_version_check' => q[1],
'dontload_hash' => { },
'ftp' => q[/usr/bin/ftp],
'ftp_proxy' => q[],
'getcwd' => q[cwd],
'gpg' => q[/usr/bin/gpg],
'gzip' => q[/bin/gzip],
'histfile' => q[/home/nrg/.cpan/histfile],
'histsize' => q[100],
'http_proxy' => q[],
'inactivity_timeout' => q[0],
'index_expire' => q[1],
'inhibit_startup_message' => q[0],
'keep_source_where' => q[/home/nrg/.cpan/sources],
'lynx' => q[],
'make' => q[/usr/bin/make],
'make_arg' => q[],
'make_install_arg' => q[],
'makepl_arg' => q[INSTALLDIRS=site],
'ncftp' => q[],
'ncftpget' => q[],
'no_proxy' => q[],
'pager' => q[/usr/bin/less],
'prerequisites_policy' => q[follow],
'scan_cache' => q[atstart],
'shell' => q[/bin/bash],
'tar' => q[/bin/tar],
'term_is_latin' => q[1],
'unzip' => q[/usr/bin/unzip],
'urllist' => [q[ftp://cpan.makeperl.org/pub/CPAN], q[ftp://cpan.nx1.ru/], q[ftp://cpan.rinet.ru/pub/mirror/CPAN/], q[ftp://ftp.aha.ru/CPAN/], q[ftp://ftp.chg.ru/pub/lang/perl/CPAN/], q[ftp://ftp.spbu.ru/CPAN/], q[http://ftp.silvernet.ru/CPAN/], q[http://mirror.rol.ru/CPAN/]],
'wget' => q[/usr/bin/wget],
};
1;
__END__


Вот примерно такой вид должен иметь наш конфиг файл, но в случае проблем при его использовании придётся переконфигурировать Цпан вручную, это делается довольно просто -- удаляем указанный конфиг файл Цпана и запускаем сам cpan :)

А вот для пользователей убунту данный конфиг стоит искать по адресу: /etc/perl/CPAN/Config.pm

Как бороться с ошибками вида: "Has already been unwrapped into directory /root/.cpan/build/ИМЯ_модуля-некая_уникальная_последовательность" ?

Такое бывает, когда сваливаются тесты модуля или Вы любите поэксперементировать с Цпаном. Это решается в лоб: rm -r /root/.cpan/build/ИМЯ_модуля-*