пятница, 5 февраля 2010 г.

Mercurial сервер

Стоит у меня под столом UltraSPARC5. Машина старая, валялась без дела. А я давний любитель всего экзотического решил приобщить ее для общественной пользы.

Залил туда Gentoo, поставил вебсервер, mediawiki, ejabberd... Хотел поставить Google Wave, но в то время он был еще сырой, и не работал. Да и java на спарк не встает, во всяком случае у Gentoo не встает.

И тут, недавно, меня посетила еще одна мысль. Подниму ка я там scm сервер. Это позволит хранить отдельно всякие вне проектные рабочие разработки. Лишняя копия, как говорится, никогда не бывает лишней. Эта, пусть слабенькая, машинка прекрасно с справится с этой задачей.

Пусть простят меня поклонники Линуса Торвальдса - git мне никогда не нравился, хотя мне приходилось им пользоваться. На данный момент мне нравится Mercurial.

Согласно этой инструкции мы настраиваем пользователя и наслаждаемся репозиторием через ssh.

Борьба с вебмордой неожиданно затянулась. Хоть для меня скорость и не является решающим фактором - я старательно следовал инструкциям по настройке fastcgi, но добился лишь того, что я могу ходить на сервер от корня (от http://.../hg), но попытка ввести что нибудь после /hg неизменно приводит к проблемам. Сервер перенаправляет /hg на /hg.fcgi и других запросов упорно не хочет принимать. Ну не писать же везде /hg.fcgi/blablabla... лишнее.

А поскольку скорость не является для меня решающим фактором - я в конце концов нашел официальную инструкцию по настройке cgi под lighttpd. Она попроще и после нее все работает почти сразу.

Для коммитоов https не нужен, настроим авторизацию на пуш согласно той же официальной инструкции.

Но возникла проблема. htpasswd - является частью апача и в комплект lighttpd не входит. Ну не ставить же апач ради такой фигни? Значит можно выбрать другой метод авторизации. Меня бы устроила встроенная авторизация на основе /etc/passwd, но так lighttpd кажется не умеет. Здесь описаны возможность mod_auth. Генерируем /home/scm/.htdigest с его помощью.
$HTTP["querystring"] =~ "cmd=unbundle" {
        auth.require = (   "" => (
                "method"  => "digest",
                "realm"   => "Mercurial repo",
                "require" => "valid-user"
        ))
}

auth.backend = "htdigest"
auth.backend.htdigest.userfile = "/home/scm/.htdigest"
Но этого недостаточно. Нужно еще в конкретном репозитории разрешить не-ssl пушинг, и прописать юзеров, которые могут это делать.
scm@sparc ~/hg/xap/.hg $ cat hgrc
[web]
push_ssl = false
allow_push = dron

Теперь можно проверить... (я конечно и в процессе неоднократно проверял, сейчас финальный тест)
$ hg clone http://10.4.2.91/hg/xap
...
10 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ cd xap
$ echo "Ридми я до сих пор не написал" > readme.txt
$ hg add readme.txt
$ hg commit -m "Тестовый коммит"
$ hg push
pushing to http://10.4.2.91/hg/xap
searching for changes
http authorization required
realm: Mercurial repo
user: dron@infosec.ru
password:
abort: authorization failed
Тудыть ее... А, забыл lighttpd перезагрузить...
...
user: dron
password:
abort: HTTP Error 500: Internal Server Error
Доступа чтоль не хватает?
$ cd /home/scm/hg; chmod -R g+w *
(Пользователь lighttpd у нас включен в группу scm). А вот и нет... недостаточно... только
$ cd /home/scm/hg; chown -R lighttpd:lighttpd *
спас сервер. Не понятно. Везде для групп стоит rw, для каталогов - rwx. Но установка одной группы в lighttpd не спасает положение.

Теперь мне совсем не ясно - зачем я заводил юзера scm? Хотя может быть для fcgi (с отдельной службой, вероятно работающей от имени scm) это и было нужно. Но пусть пока будет так.

Остались несколько проблем, и https не самая большая из них. Вот самая большая:
$ hg push
...
user: dron@infosec.ru
password:
abort: authorization failed
$ hg push
...
user: dron
password:
adding changesets
add changeset a63be34dcf21
adding manifests
adding file changes
adding readme.txt revisions
added 1 changesets with 1 changes to 1 files
updating the branch cache
Вот так, dron в качестве имени - воспринимает, а dron@infosec.ru - нет. Вероятно проблема где-то mod_auth, потому что не сходится авторизация. И что с этим делать?..

четверг, 21 января 2010 г.

Сбербанк жжет

В принципе, я представляю себе что такое сертификат. Но был вот намедне в сбербанке, где получил следующий чек:


Тогда у меня еще промелькнула мысль, что где-то я это уже видел. Вспомнил! То же самое я наблюдал, когда распечатывал дампы в программе в %u формате, передавая char...

То есть на самом деле сертификат чека должен выглядеть как: 2bdc2fa0ffc1fef883c699b758e9ff45ba43a672.

Только какой же это, нафиг, сертификат?!?

PS: какой-то у меня микроблоггинг пошел. :)

суббота, 16 января 2010 г.

На гребне волны...

Дочка Убунту прибежала к Дебиану и, весело смеясь,
поцеловала его в лоб: "С днём рождения, папа!"
Затем она окинула радостным взглядом сидящих за
столом гостей и спросила своим звонким голосом:
— Папа, а где Gentoo, разве он ещё не пришёл?
— Нет, он ещё только собирается.


Я человек, уже, наверное, окончательно потерянный для традиционных систем. Народ мигрирует со скучного debian-stable на "веселую" OpenSuse. В чем счастье, Роман? В Gentoo я могу настроить едва ли не каждую опцию каждого пакетика. И я напрочь лишен этого в пребилденных системах. Мне тесно в их жестких рамках, Я даже не могу заоптимизировать пакетик так как захочу - я должен жить так, как хотят другие... Не хочу я так жить, не хочу.

Я люблю Gentoo. Но последнее время мне кажется, что Gentoo законсервативилось. Стабильная версия не создает почти никаких проблем, не смотря на то, что я ее каждую неделю обновляю. Скучно.

Куда же податься старому linux-экстремалу?

Gentoo приучил меня к тому, что ни один файл в системе не существует просто так, если файл есть, значит он кому нибудь нужен, и я легко могу сказать кому. Это приятное ощущение контроля над системой не может не радовать.

Но для прогрессивного человека есть еще один аспект - стремление к новому. Еженедельно выходят новые версии различного открытого софта. Прежде чем этот софт попадет в репозитории систем и застабилизируется - проходит разное время, от месяца до года.

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

Как сказал один из наших сотрудников, когда мы заговорили о линуксах о всяких: "Если человеку скучно в Gentoo - то это уже не лечится..."

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

Держать две одинаковых системы как-то бессмысленно. Но и достойных альтернатив Gentoo я не вижу, кроме разве что Exherbo.

Exherbo - это почти тот же самый Gentoo. Пакеты там так же гибко настраиваются и так же собираются из исходников. В нем используется другой пакетный мнеджер - Paludis. Вместо одного репозитория он оперирует набором узкоспециальных репозиториев, количество которых в моей системе уже превысило два десятка.

И самое экстремальное то, что система еще на стадии раннего бета тестирования. Стабильных пакетов в Exherbo нету вообще. Пакеты не просто помечены как нестабильные - они действительно самые свежие. Система для настоящих джедаев. Эти программы в debian stable появятся едва ли не через год...

Но сообщество Exherbo значительно меньше Gentoo'шного, развитие системы хотя и идет быстро, но многих программ пока просто нету. Но мы не привыкли отступать, будем писать ебилды, которые здесь называются эксересами. Больше эксересов хороших и разных.

среда, 2 декабря 2009 г.

Игры со временем

Многие начинающие agile команды наверняка испытывают проблемы с планированием. И наша команда тоже через это прошла. Мы долго и упорно пытались планировать время, строить графики сгорания, пока не поняли что смысла не будет. И теперь начинаю понимать - почему...

Не нужно планировать время.

Очень много времени в SCRUM тратится на планирование. Мало того, что мы должны разделить все истории на задачи, мы еще должны, как дураки, оценивать время играя в карты.

Программистам не нужно время. Дайте программисту четко поставленную задачу и не отвлекайте, пока не будет готово.

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

Чтобы программисты могли точно оценивать время - нужен большой опыт. Причем опыт именно в предсказании времени :). Можно прекрасно представлять себе объем работ, но постоянно ошибаться со сроками.

Кроме того, можно достаточно легко представить сколько времени займет очередное изменение, но конкретно плавать в оценке сроков задач, которые предстоит сделать под конец итерации, потому что объем предварительных измнений - только в головах...

И это тоже проблема. Поэтому не надо планировать все задачи сразу.

Если вы планируете внедрять SCRUM - послушайте моего совета. На бумажках нельзя писать абстрактные и неконкретные вещи. Каждая бумажка должна представлять из себя конкретную задачу для одного человека. Не получается чтобы по одной бумажке и программист программировал и тестер тестировал. Не пойдет скрам. Бумажки будут мотаться по доске без видимого результата. Еще раз: конкретная задача для одного человека. Взял, сделал, done, без вариантов!

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

Это чем-то перекликается с GTD Дэвида Аллена. Тем, что все запланировать практически нереально, но первое конкретное действие легко определяется почти всегда (Или фичу нужно сразу вернуть оунеру).

Вероятно на этом принципе держится Канбан. MMF - достаточно крупное понятие, и программист должен видеть конкретные действия, которые способны продвинуть задачу вперед. На доске место для них не предусмотрено. И если конкретности вИдения не достает - то канбан не пойдет, встанет.

В SCRUM проще. Мы разбиваем задачу на работы и прикидываем время выполнения этих работ. Только проблема в том, что если работа неконкретная, то и время выполнения получается неконкретное, и следовательно вряд ли оно будет соблюдено.

И получается, что время не играет роли. Если задача и действия по ней конкретные - она будет двигаться вперед, в противном случае мы будем топтаться на месте. А время - чисто статистическая характеристика, нужная, как я уже сказал, только PO.

Но это вовсе не означает что время совершенно не нужно для программистов.

Программирование - процесс творческий. И зачастую связанный с познанием неизведанного. А познание неизведанного - процесс крайне трудно поддающийся планированию. Когда речь идет о неизведанном - разговоры о времени неуместны? Еще как уместны!

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

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

Вот где-то такие мысли у меня по поводу agile. Не SCRUM, не Kanban...

PS: Опять давно ничего не писал, мыслей вроде много, а писать - руки не доходят. Как с этим бороться?

среда, 14 октября 2009 г.

KDE3 is dead?

На прошлой неделе в Gentoo размаскировали KDE-4.3 для платформы amd64. При этом, после окончательной стабилизации KDE4, KDE3 будет удалена из репозитория навсегда.

Двоякое ощущение.

С одной стороны дома я уже давно сижу на KDE4.2, дома у меня больше возможностей и желания для экспериментов. С другой стороны KDE4 расстраивает меня своим уходом в красивости. Да мне пофиг красивости, хотя дочке очень нравятся снежинки.

Но правда открытого софта такова, что старая версия уже никому не нужна. И никто не будет возиться с багами, которых там еще много. Ну будем надеяться, что в kde4 помимо красивых плазмоидов у разработчиков дойдут руки и до полезных и нужных вещей, как то работа с сертификатами, получение адресов из LDAP, почему-то все мои проблемы крутятся в основном вокруг kmail? Нет, в kopete очень слабая поддержка jabber. :)

Короче, переехал на kde-4.3.1. Прошарил свою систему, удалил оттуда все, что зависело от qt3, и теперь у меня чистая qt4 система.

Кроме того, я наконец то нашел решение проблемы ntlmaps, терзавшей меня долгое время. Проблема заключается в том, что в один прекрасный момент он перестал запускаться из init скрипта. С консоли запускается, а из init-скрипта ни в какую. Кроме того я давным давно не могу пустить через него firefox - ntlmaps не проксирует запросы почему-то. А иногда еще и проц жрет почем зря - под 100%.

Обнаружилась вполне достойная альтернатива - cntlm , которая пока правда не входит в репозиторий gentoo, но ebuild можно скачать отсюда, чуть чуть поплясать с бубном и все, настало полнейшее счастье, и причем значительно более шустрое.

Значит жизнь продолжается! :) Что касается сертификатов - Thawte наконец таки перестал раздавать публичные сертификаты. И значит информацию о зарплате отныне будут доводить на наших, внутренних.
Пойду получать новый сертификат Информзащиты.