Сегодня расскажу как установить standalone-версию Jira (то есть ту, которая на сайте Jira значится как «Download» версия) на ваш сервер. Выбран Debian из-за того что на FreeBSD сложнее завести самую свежую Java, которая так нужна Jira. Другие дистрибутивы я не рассматривал, просто потому что мне с Debian проще.

Также в качестве СУБД для Jira будет использоваться MySQL. Это обусловлено тем, что потом можно хакать данные жиры, например переименовывать пользователей и т.д. через процедуры, о которых возможно расскажу в другой статье.

В статье рассматривается Jira 5.0.4.

Установка

Установка будет происходить на минимальной сборке свежеустановленного Debian, поэтому буду устанавливать нужный софт типа nano и sudo. А также создадим в домашней директории каталог «Downloads», туда будем класть всякие загрузки:

Теперь добавим репозиторий DotDeb, так как там есть более свежие пакеты:

Теперь скачаем ключ для DotDeb и применим его:

Установим MySQL-сервер версии 5.5 и Nginx:

Выбирите нужную версию Jira на этой странице и скачайте бинарный файл в каталог «~/Downloads».
Так как у меня 32-битная платформа на Linux, я качаю нужный мне бинарник так:

Создадим каталоги для Jira:

Теперь запустим бинарник и приступим к установки самой Jira:

После установки, нам необходим init-скрипт, я создавал небольшой срипт, можете им воспользоваться:

Настройка

Теперь создадим БД и настроим права доступа для Jira:

Отредактируйте «nginx.conf»:

К виду:

Далее, отредактируем конфиг Jira:

Найдите там «Service/Connector» и добавьте туда «proxyName» и «proxyPort»:

Перезагружаем Jira для того чтобы применить новый конфиг:

Теперь пробуем открыть «http://example.org/». Вам предложат настроить Jira, укажите тип хранилища «MySQL» и верные реквизиты доступа, после чего вам предложат настроить учетную запись администратора и т.д.

Установка GreenHopper

Для этого надо просто войти в UPM («http://example.org/plugins/servlet/upm#install») и вбить в поисковую строку «GreenHopper», таким же образом можете установить любые другие плагины доступные в репозитории Jira.

Ещё пару слов

При покупке, лицензионный ключ для Jira надо ввести на странице «http://example.org/secure/admin/ViewLicense!default.jspa», а для GreenHopper в UPM.

Если вы неверно указали «Base URL» (в нашем примере он «http://example.org»), то на странице настроек «http://example.org/secure/admin/ViewApplicationProperties.jspa» можете поменять его.

Продолжаем обсуждение инструментария для git-репозиториев, сегодня расскажу про GitWeb, он представляет из себя простую веб-морду для визуализации репозиториев Git'а, в ней можно будет лицезреть свои проекты, историю и т.д., вообщем всё что необходимо.

Пользователем Mercurial внешний вид уже знаком, так как его предоставлял hgweb:

[web]
# стиль gitweb
style = gitweb

Установка

Собирать буду частично из исходников, так как нам понадобится вменяемый fcgiwrap (в Debian очень старая версия 1.0, которая нам просто не подойдет). Нам понадобится fcgiwrap 1.0.3 для запуска «gitweb/index.cgi».

fcgiwrap выбран потомучто он уже использовался у меня на сервере и я решил найти ему очередное применение. На странице GitWeb на GitHub'е есть инструкция для gunicorn.

Настройка

Я переписал оригинальный (читать старый из Debian) init-скрипт fcgiwrap'a, который можете взять тут.
Скопируйте его в «/etc/init.d».

Без скрипта можете запустить так:

Со скриптом так:

Теперь перейдем к Nginx. Отредактируйте «/etc/nginx/nginx.conf»:

И ваш файл виртуального хоста:

Откройте файл «/etc/gitweb.conf» и укажите путь до репозиториев:

Перезагружаем Nginx и наслаждаемся!

А какже git-instaweb?

Простой обозреватель вашего репозитория на основе GitWeb, но когда репозиториев несколько. Минус у этого решения один — он не преднозначен для запуска на нескольких репозиториях. Точнее вам придется запускать копию для каждого репозитория на разных портах и проксировать на них.

Также вы можете указать в «.gitconfig» нужные настройки для instaweb:

Ещё можно почитать:
Pro Git 4.6 Git on the Server GitWeb
How To: Install and Configure GitWeb

Сегодня расскажу как получить рутовый доступ на ваш LG Optimus One (он же LG P500) с Android 2.3.3 и удалить предустановленные приложения. Будем удалять всякие фейсбуки, вконтакты и одноклассники, а также бесполезные программы от LG.

Статья предназначена для пользователей Linux, но в архиве с ADB имеется и Windows версии.

Для начала качаем ADB и распаковываем:

Войдите в настройки телефона «Приложения» -> «Дополнительные опции» и включите режим «Отладка USB», далее подключите ваш телефон по USB кабелю к компьютеру и выполните:

Отлично, мы успешно подключились, теперь получим рутовый доступ:

Вручную перезагрузите телефон (выключите и снова включите) и снова стартуем shell:

Ура, теперь у нас есть права пользователя root!

Теперь примонтируем «/system» с возможностью записи данных:

После этого мы сможем удалить «нужный» нам софт:

Только не удаляйте «LGHome.apk», как это сделал я по ошибке... Это приложение является рабочим столом и меню вашего телефона, без него смысла в телефоне особого нет, он сможет принимать звонки и сообщения, а также подключаться к сети, больше по сути ничего. В конце статьи я описываю как всетаки восстановил «LGHome.apk».

Оффтопик

Сбросить телефон на изначальное состояние («Factory reset») можно так:

1. Зажать одновременно «Home + VolumeDown + Power» и держать несколько секунд, пока не появится картинка на дисплее «Android с коробочкой».
2. Также можно сбросить телефон на заводские настройки через сервисное меню, для этого наберите номер 3845#*500# и в появившемся меню нажмите на «Factory Reset».

Если вы всётаки удалили LGHome.apk

Казалось всё не так плохо, надо просто скачать из сети это приложение и залить его через ADB, но в моем случае все было намного хуже... Я сделал «Factory Reset», после чего у меня слетел root и сбросился режим «Отладка USB» и я не смог подключится через ADB.

В итоге мне надо было попасть в «Настройки» телефона и включить режим «Отладка USB». Вот как я выкрутился:

1. Сначала залил на свой сайт приложение *.apk (неважно какое);
2. Потом через телефон (благо GPRS/WIFI работали) скачал это приложение (для этого я послал себе ссылку по смс через бесплатный сервис от мтс);
3. После скачивания начал его устанавливать, тогда Android меня предупредил о «неизвестном источнике» и пустил в меню настроек «Приложения» чтобы я указал что «разрешаю установку приложений из неизвестных источников»;
4. Вместо этого я зашёл в «Дополнительные опции» и включил режим «Отладка USB», после чего ADB смог определить мой девайс!

Как только вы смогли включить режим «Отладка USB», то сразу подключаем USB кабель и вводим в консоль:

Ну вот и всё, удачи!

В след за статьёй FreeBSD и Debian. Установка и настройка Gitosis хочу рассказать про Gitolite. Это аналогичный по функциональности инструмент, но дающий чуть больше возможностей, например разграничения прав на ветки и теги, и немного проще в использовании. А ещё, в отличие от Gitosis, он до cих пор поддерживается.

Будем считать, что вы уже создали пользователя и группу «git», а также установил Git на сервере.

Gitolite

Иногда для проектов хочется иметь некие «production»-ветки и «release»-теги, но с ограниченным доступом к ним определенным пользователям. Например разработчики имеют доступ только к ветке «master» и собственным веткам созданным на сервере, а «production» должен быть для них недоступен, чтобы по воле случая они туда ничего не намержили плохого.

Git начал становиться очень популярным в корпоративных средах, где обычно есть дополнительные требования в плане контроля доступа. Gitolite изначально был создан, чтобы посодействовать в выполнении таких требований. Но как оказывается он так же полезен и в мире open source: проект Fedora управляет доступом к своим репозиториям пакетов с помощью gitolite. А ведь этих репозиториев больше 10 000! По видимому это самая большая установка gitolite где бы то ни было.

Gitolite позволяет указать права доступа не только для репозиториев, но и для веток или имён меток внутри каждого репозитория. То есть, вы можете указать, что определённые люди (или группы людей) могут отправлять (push) определённые “ссылки” (ветки или метки), а остальные нет.

Pro Git — Pro Git 4.8 Git на сервере Gitolite

Установка Gitolite

FreeBSD:

Debian:

Из исходников:

Настройка Gitolite

Для начала нам надо создать на локальной машине ключ и скопировать его на сервер:

Теперь добавьте в свой локальный «.ssh/config»:

Далее, надо войти на сервер и проинициализировать gitolite:

Перейдем снова на локальную машину и попробуем подключится:

Если примерно такой ответ, то есть перечислены репозитории и права, то всё окей, продолжаем!

Пользователи, макросы и права с refex

Теперь склонируем репозиторий «gitolite-admin» к себе и отредактируем конфигурационный файл:

В полученном репозитории вы увидите каталог «keydir», в котором хранятся все публичные ключи пользователей имеющих доступ к каким-либо репозиториям. Чтобы добавить пользователя, необходимо чтобы вы поместили сгенерированный им публичный ключ в каталог «keydir».

Также, в «gitolite-admin» находится каталог «conf», в котором присутствует конфигурационный файл «gitolite.conf», со следующим содержимым:

По содержимому понятно как указывать репозитории, права и пользователей. Также есть специальный макрос «@all», который содержит в себе всех пользователей из «keydir».

Вы можете создавать свои макросы и использовать их в дальнейшем:

Возможности прав:

• «R» — только чтение refs;
• «RW» — чтение и запись (в том числе создание новых) refs;
• «RW+» — чтение, запись (с перезаписью существующих) и удаление refs;
• «-» — доступ отсутствует;

Refex это регулярные выражения для удаленных (remote) веток, тегов и файлов:

Если вы не указываете явно префикс "refs/", то gitolite сам дописывает в начале «refs/heads/», поэтому для «- production = @all» будет равносилен «- refs/heads/production = @all».

Права на ветки, теги и файлы

Ну наконец перешли к самому интересному! Для примера сделаем чтобы @leaders имели доступ ко всему, а @developers имели доступ только на чтение к ветке «production» и тегам «rc*» (но не могли создавать такие теги).

Порядок следования правил важен, так как они проверяются последовательно!

Создание репозитория

Чтобы создать новый репозиторий необходимо зайти на сервер и выполнить:

Теперь откроем файл «gitolite-admin/conf/gitolite.conf» и добавим нужный нам репозиторий:

Для того чтобы настройки вступили в силу надо отправить свои изменения на сервер:

Далее, можете получить свой репозиторий:

Это всё. Рекомендую также почитать статью Знакомство с gitolite

Со временем я перешел с Mercurial на Git, почему это произошло я расскажу в другой статье. А сегодня я расскажу как организовать авторизацию и разграничение прав не репозитории при помощи Gitosis.

Установка и настройка Git

В любом случае нам понадобится создать группу и пользователя «git», а также установить Git.

FreeBSD:

Debian:

Установка и настройка Gitosis

В свое время, на работе, мы выбрали Gitosis и не разочаровались. Решение достаточно простое, опирающееся на git-хуки и ssh-ключи, которое обеспечивает нас самым главным — разграничение прав на проекты.

Хранение публичных ключей всех пользователей в authorized_keys для предоставления доступа работает хорошо лишь на время. Когда у вас сотни пользователей это скорее похоже на пытку. Вы должны заходить на сервер каждый раз и нет никакого разграничения доступа — все перечисленные в файле имеют доступ на чтение и на запись к каждому проекту.

На этой стадии вы можете захотеть обратиться к широко используемому ПО под названием Gitosis. Gitosis — это просто набор сценариев (скриптов), который поможет вам управляться с файлом authorized_keys и реализовать простой контроль доступа. Действительно интересно, что интерфейсом для этого инструмента для добавления людей и определения доступа для них является не веб-интерфейс, а специальный git-репозиторий. Вы настраиваете информацию в этом проекте и, когда вы отправляете её в репозиторий, Gitosis исходя из неё перенастраивает сервер, что круто.

Pro Git — Pro Git 4.7 Git на сервере Gitosis

Вообщем авторизация будет по ключам, а gitosis будет контролировать политику прав. Поехали!

Установка Gitosis

FreeBSD:

Debian:

Можно и из исходников, но так как разработка gitosis прекратилась осенью 2009 года, свежее всёравно не будет:

Настройка Gitosis

Для начала нам надо создать на локальной машине ключ и скопировать его на сервер:

Теперь добавьте в свой локальный «.ssh/config»:

Далее, надо войти на сервер и проинициализировать gitosis:

Перейдем снова на локальную машину и попробуем подключится:

Если примерно такой ответ, то все хорошо, продолжаем!

Теперь склонируем репозиторий «gitosis-admin» к себе и отредактируем конфигурационный файл:

В полученном репозитории вы увидите каталог «keydir», в котором хранятся все публичные ключи пользователей имеющих доступ к репозиториям. Чтобы добавить пользователя, необходимо чтобы вы поместили сгенерированный им публичный ключ, а после добавили упоминание этого пользователя в файле «gitosis.conf» секция «members».

Чтобы создать новый репозиторий необходимо зайти на сервер и выполнить:

Далее, добавим в локальный файл «gitosis.conf» что-то наподобие:

Также возможно унаследовать пользователей из другой группы, например:

Вообщем в «members» надо перечислить пользователей, у которых есть доступ к репозиторию «writable». И добавить в «keydir» публичные ключи полученные от пользователей. Это всё что надо!

Для отладки самого gitsis вам может понадобится эта опция:

Gitosis читает файла настроек из этого файла «/home/git/repositories/.gitosis.conf», он симлинк на «/home/git/repositories/gitosis-admin.git/gitosis.conf». Так что вы всегда можете повлиять на конфигурационный файл gitosis'а даже если потеряли доступ к нему из вне отредактировав вручную «/home/git/repositories/.gitosis.conf».

Рекомендую также почитать Gitosis — ArchWiki.

Сегодня начал использовать twitter-bootstrap и решил процессить less не на клиентской стороне, а средствами сервера, просто по приколу. Сразу же вспомнил про статью на хабре Серверный процессинг LESS файлов «на лету» своими руками и решил реализовать то, что там написано.

Принцип работы заключается в том, что все обращения к файлам «*.less» будут проксироваться через Nginx и преобразовываться на лету (можно и nginx-кеш прикрутить, если надо) в css средствами node.js.

Установка

Для начала нам надо установить nginx и node.js:

Скачиваем отсюда последнюю версию less.js и устанавливаем:

Настройка

Добавим в «/etc/hosts» хост «example.loc»:

Отконфигурируем Nginx

Добавим в «/etc/nginx/nginx.conf» апстрим «lessserv»:

Отредакируем ваш server-конфиг для «example.loc» — «/etc/nginx/sites-available/example.conf»:

После чего не забываем добавить в sites-enabled и зарелоадить Nginx:

Теперь перейдем к node.js

В файле «bin/lessserv» вы можете указать нужный вам listen_host и listen_port, по умолчанию:

Запускаем lessserv, который и будет проксировать наши less-файлы:

Проверяем по ссылке: http://example.loc/bootstrap/less/bootstrap.less, если отдается готовый css-файл, то все у вас получилось!

Ествественно, в каталоге «/path/to/example» должен присутствовать распакованный каталог bootstrap.

Далее в html подключать можно так:

P.S. Вообщем статья это «толстый Like» статьи с хабра, хотя более подробная в плане настроек, пофикшены инструкции (proxy_pass, вместо proxy_path), а также немного улучшен «less.js» на GitHub'е :)

Это вторая часть «разделенной» статьи о покупке ThinkPad и настройки SSD на xubuntu. Первая часть находится тут.

Недавно прикупил себе Intel 310 SSD и хочу рассказать о его установке и настройке более детально. В первую очередь его надо физически установить, делается это так: Service Videos, смотрите раздел «FRU Removals/Replacements» > «WWAN Adapter». Вообще на этом сайте есть всё что надо для того чтобы пересобрать ноутбук ThinkPad.

Далее, нам понадобится утилита для анализа активности работы I/O. Мне понравился iotop:

Где:

• -o — only show processes or threads actually doing I/O
• -a — show accumulated I/O instead of bandwidth

Таким образом мы получим агрегированную информацию по процессам которые активно используют наш SSD.

Сразу скажу, что я использовал Ext4 и журналирование НЕ отключал, а swap я разместил на соседнем HDD, который шёл в комплектации. Статья включающая отключение журналирования находится тут. Там же в комментариях говорится о том, что перестанет работать discard (он же TRIM), если вы отключите журналирование!

Проверить скорость работы накопителя можно так:

Настройка fstab и включение TRIM

Будем подключать наш SSD со следующими дополнительными опциями:

noatime — не записывать access-time для файлов, потомучто нам не нужны лишние записи на SSD;
nodiratime — не записывать access-time для каталогов, потомучто нам не нужны лишние записи на SSD;
discard — включение TRIM. TRIM повысит время жизни нашего SSD накопителя.

TRIM — команда, позволяющая операционной системе уведомить твердотельный накопитель о том, какие блоки данных больше не используются и могут быть использованы накопителем для подготовки к записи.
TRIM (команда SSD) — Википедия

Отредактируйте /etc/fstab до вида:

swap можно вообще отключить через команду swapoff (см. также swapon и их параметры, а для полного отключения закоментируйте определение swap в /etc/fstab), если конечно вам позволяет объем вашей ОЗУ. Я бы рекомендовал именно такой подход: не хватает памяти и активно используется swap — купи памяти, а своп только на аварийный случай.

Для применения настроек необходимо перезагрузиться.

Теперь проверим работает ли TRIM

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

Создаем файл:

Копируем begin_LBA и вставляем в следующей команде:

Ага, всё хорошо, данные в секторах есть, теперь удалим файл и узнаем сработает ли TRIM:

Если у вас получились все нули, то TRIM работает,
Если нет, то проверяйте ваш fstab и пиши комментарии, помогу.

Настройка grub

Добавьте в файл «/etc/default/grub» -> «elevator=noop». Эта опция нужна для отмены режима парковки HDD (которая включена по дефолту), так как SSD-накопителю этого не надо делать по физическим причинам? то будем отключать:

Для того чтобы изменения вступили в силу выполните:

Настройка отложенной записи на диск

Так как я не отключаю журналирование, то надо настроить систему так, чтобы она больше копила данных в буфере и скидывала на диск реже информацию. Это более экономично для времени автономной работы ноутбука (так как диск будет простаивать некоторое время) и времени жизни самого SSD. Отредактируйте «/etc/sysctl.conf» до следующего вида:

Насколько я понимаю, то «vm.dirty_writeback_centisecs» это одно и тоже что и «commit» в fstab, если я ошибаюсь — поправьте меня.

Для того чтобы изменения вступили в силу выполните:

Более подробно об этом и много другом в Disks and Filesystems / Tips & Tricks / LessWatts.org.

Настройка SWAP

Сам я не пользуюсь этой настройкой, о причинах я говорил уже выше, но для полноты статьи приведу всётаки. Есть настройка «vm.swappiness», в которой задается некий коэффициент, если он большой, то своп используется активно, если он маленький то будет редко использоваться, более подробно тут What Is the Linux Kernel Parameter vm.swappiness?. Отредактируйте «/etc/sysctl.conf»:

Для того чтобы изменения вступили в силу выполните:

Настройка FireFox

Для того чтобы увеличить жизнь SSD я решил отключить кеш браузера (только на диске, кеша в памяти это не касается), для этого заходим в «about:config» и редактируем следующие опции:

Статистику кеша браузера можно наблюдать если войти в «about:cache», также там будут локейшены до кеша и т.д. Также доступны два параметра для этой статистики:

• «about:cache?device=memory» — список для кеша в памяти;
• «about:cache?device=disk» — список для кеша на диске.

Что ещё почитать про SSD?

• Disks and Filesystems / Tips & Tricks / LessWatts.org
• Оптимизация Ubuntu (и прочих Linux-ов) под SSD / Linux для всех / Хабрахабр
• Оптимизация Ubuntu 11.04 под SSD | ChooseLinux
• Установка Ubuntu Linux на SSD
• Linux optimization » SSD

8 февраля 2011 года президент России Дмитрий Медведев дал поручение правительству об отмене перевода стрелок: после перехода на летнее время 27 марта 2011 года Россия должна жить только по летнему времени, которое опережает поясное (принятое декретом 1919 года) на 1 или 2 часа в зависимости от региона. В соответствии с этим поручением был подготовлен «Закон об исчислении времени», который Государственная дума приняла 20 мая. 3 июня 2011 года президент подписал Закон, и он вступил в силу с 5 августа 2011 года

Летнее время

FreeBSD 8.1 как и многий другой софт не подчинился новому закону Дмитрия Анатольевича, так что будем исправлять ситуацию.

Поставим zoneinfo, оттуда будем брать новую таймзону

Проверим работает ли нужная нам таймзона и текущее время:

Как видим расходится, так что установим новую хорошую таймзону:

Не забудьте перезагрузить «mysqld»:

Не взлетел PHP?

Если PHP не взлетел, то используйте pecl-timezonedb:

и убедитесь что «timezonedb.so» добавился в «/usr/local/etc/php/extensions.ini»:

Синхронизация

Просинхронизируйте ваше время:

Можете настроить «rc.conf» для постоянной синхронизации времени:

Так же можете почитать man page ntpdate и посмотреть какие ещё есть параметры конфигурации для «rc.conf»:

Обновил я на той неделе свою Xubuntu с 11.04 на 11.10, как и опасался оно не взлетело с первого раза.
Симптомы были следующие: gdm стартовал успешно, но авторизоваться под своим пользователем не получалось, вылетало на авторизацию вновь (gdm), при этом новые учетные записи авторизовывало успешно.
Посравнивал свои конфигурационные файлы с другой учетной записью, ничего криминального не нашёл, кроме того что в моём домашнем каталоге были файлы не от моего пользователя.

Решение проблемы

Переключаемся в один из терминалов (например tty1) с помощью Ctrl+Alt+F1 и вводим следующее:

Это решило мои проблемы.

Если вам надоело вводить логин и пароль при подключении по SSH, либо ваше приложение не поддерживает ввод логина и пароля для SSH, а соединиться всётаки надо, то вам просто необходимо использовать авторизацию по ключам!

Для этого надо настроить на стороне клиента и сервера ключи, для клиента будет приватный, а на сервере будет храниться публичный ключ.

Настройка на стороне клиента

Создайте и/или отредактируйте файл «~/.ssh/config»:

Где,

• «Host example» — название хоста, которое вы будете указывать при подключении по SSH (Пример: «ssh example»);
• «User username» — имя вашего пользователя на сервере;
• «Hostname example.com» — имя хоста вашего сервера (в отличии от Host это действительно имя сервера, а не просто имя для соединения);
• «Port 22» — SSH порт;
• «IdentityFile ~/.ssh/username_example» — файл с публичным ключом.

Генерация ключей и передача их на сервер

Далее, сгенерируем ключи.
После чего сразу же перешлём публичный ключ на сервер, а приватный переименуем в «~/.ssh/username_example»:

Теперь должно подключаться по ключу:

Если нет, то пишите камменты :)

Утилита ssh-copy-id

Также есть более быстрый (меньше телодвижений) и правильный (он добавляет ключ в «~/.ssh/authorized_keys» на сервере, а не замещает как «scp») способ передавать публичный ключ на сервер, это утилита ssh-copy-id.

То есть вместо:

надо использовать так:

Ну вот и всё, смотрите также:
WordPress. Обновление движка и плагинов через ssh
Первые меры безопасности во FreeBSD
FreeBSD. Без парольный доступ по SSH с использованием шифрованных ключей
FreeBSD. DenyHosts защитит вас от брутфорса SSH