среда, 25 июля 2012 г.

Upstart hangs workaround

Иногда встречаю проблемы с Upstart скриптами на ubuntu 10.04, когда процесс аварийно завершился, а upstart это пропустил, и процесс висит stop/killed или start/killed с несуществующим pid.
В launcpad есть bug по этому поводу: https://bugs.launchpad.net/upstart/+bug/406397
Где то в середине проскакивает ссылка на скрипт, с решением проблемы. Скрипт весьма брутален- он создает процессы до тех пор, пока не будет создан процесс с зависшим pid. Мне, однако это помогло.
Ссылка на скрипт: http://heh.fi/tmp/workaround-upstart-snafu
На случай, если ссылку удалят...

среда, 11 июля 2012 г.

Git сервер с gitosis и gitweb


С десктопа:
scp ~/.ssh/id_rsa.pub gitserver:~/admin_rsa.pub


С сервера:
sudo apt-get update
sudo apt-get install git-core gitosis gitweb
sudo -H -u gitosis gitosis-init < ~/admin_rsa.pub

Изменить в /etc/gitweb.conf
$projectroot = "/srv/gitosis/repositories";

Веб интерфейс будет доступен по адресу http://gitserver/gitweb

Администрирование через gitosis:
git clone gitosis@gitserver:gitosis-admin.git
cd gitosis-admin
vim gitosis.conf

Добавить:

[group developers]
writable = project1 project2
members = developer1 developer2

project1, project2 - новые репозитории. будут созданы при первом коммите в него
developer1, developer2 - пользователи. необходимо заранее положить .pub ключи (ключи так и должны называться developer1.pub, developer2.pub) в директорию keydir.

git add .
git commit -m 'added projects project1, project2 and users developer1, developer2'
git push

Теперь с компьютера developer1:
mkdir project1
cd project1
git init
touch README
git add .
git commit -m 'initial commit'
git remote add origin gitosis@gitserver:project1
git push origin master

С компьютера developer2:
git clone gitosis@gitserver:project1

пятница, 11 мая 2012 г.

OVPN Server на Mikrotik


Делаем сертификаты с помощью easy-rsa(идет в комплекте с openvpn):
sudo -i
cd /usr/share/doc/openvpn/examples/easy-rsa/2.0
vim vars
. ./vars
./clean-all
./build-ca
./build-key-server mikrotikserver
./build-key clientname

Ключ для микротика конвертим в .pem:
openssl rsa -in keys/mikrotikserver.key -out keys/mikrotikserver.pem

Создаем ip pool:
/ip pool add name=ovpn-pool ranges=192.168.89.10-192.168.89.100

Создаем ppp профиль:
/ppp profile
add name="ovpn-profile" local-address=192.168.89.1 remote-address=ovpn-pool use-mpls=default use-compression=default use-vj-compression=default use-encryption=required only-one=default change-tcp-mss=default

Заливаем ключи на mikrotik через web или ftp. Нам нужны ca.crt, mikrotikserver.crt, mikrotikserver.pem

Импортируем ключи(я делал через web)

Включаем сервис(через web):
ppp -> OVPNServer
Enabled -> ok
Default profile -> ovpn-profile
Certificate -> cert2(тот, который mikrotikserver)

Делаем пользователя(через web):
ppp->secrets
Name ->
Password ->
Service -> ovpn
Profile -> default

Теперь на клиенте:
cd /etc/openvpn
touch mikrotik.conf
mkdir -p mikrotik.d/{certs,keys}
touch miktotik.d/credentials
Кладем клиентские ключи и сертификаты(ca.crt, clientname.crt, clientname.key)в соответствующие директории.

В mikrotik.d/credentials прописываем 2 строчки:
username
userpass

Содержимое mikrotik.conf:
client
dev tun
proto tcp
remote my.mikrotik.tld 1194
resolv-retry infinite
nobind
user nobody
group nogroup
persist-key
persist-tun
ca /etc/openvpn/mikrotik.d/certs/ca.crt
cert /etc/openvpn/mikrotik.d/certs/clientname.crt
key /etc/openvpn/mikrotik.d/keys/clientname.key
ns-cert-type server
#comp-lzo
verb 3
mute 20
cipher AES-256-CBC
auth SHA1
daemon
auth-user-pass /etc/openvpn/mikrotik.d/credentials
route 192.168.88.0 255.255.255.0 vpn_gateway #незнаю как пушить роут от микротика клиенту, поэтому прописываем роут в локальную сеть за микротиком здесь

Всё, можно запускать:
openvpn --conf /etc/openvpn/mikrotik.conf
или
/etc/init.d/openvpn start

четверг, 19 апреля 2012 г.

Чиним поломанный MASTER-MASTER replication на MySQL

Случилось как то у меня сломалась репликация MASTER-MASTER на MySQL - огромное количество duplicate entry. В репликации у меня один сервер основной, второй- бекапный.
Делаем так:
на основном сервере смотрим:
mysql> show master status\G;
*************************** 1. row ***************************
 File: mysql-bin.000184        Position: 154007002    Binlog_Do_DB: databasename
Binlog_Ignore_DB: mysql,information_schema
1 row in set (0.00 sec)
ERROR:
No query specified


Выделенное жирным шрифтом запоминаем.
Делаем бекап на основном сервере:
bash > mysqldump -uroot -p databasename > databasename.sql

Копируем файл на бекапный сервер.
Останавливаем репликацию на бекапном сервере:
Останавливаем master на бекапном сервере(мы же не ходим что бы DROP DATABASE среплицировалась на основной сервер ;) ) - для этого комментим все записи, связанные с binlog в my.cnf

#log-bin=/var/lib/mysql/mysql-bin
#expire_logs_days=3
#binlog-do-db=databasename
#binlog-ignore-db=mysql
#binlog-ignore-db=information_schema
Рестартим mysql.

Останавливаем slave:
mysql> stop slave;
Дропаем базу:
mysql > DROP DATABASE `databasename`;
Заливаем дамп снятый с основного сервера:
bash > mysql -u root -p databasename < databasename.sql
Изменяем место, с которого читать лог(данные берем те, которые сохранили при show master status):
mysql> CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000184';
mysql> CHANGE MASTER TO MASTER_LOG_POS = 154007002;
запускаем slave:
mysql> start slave;
Смотрим как докатывается база :)
Запускаем мастер на бекапном сервере. Для этого обратно раскомментируем записи в my.cnf и рестартим mysql.
Проверяем slave на основном сервере:
mysql> show slave status\G;
Если пишет ошибку про чтение из закрытого файла, то останавливаем slave:
mysql> stop slave\G; 
Изменяем место, с которого читать лог(при рестарте бекапного сервера открывается новый бинлог):
mysql> CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000084';
mysql> CHANGE MASTER TO MASTER_LOG_POS = 0;
Запускаем slave:
mysql> start slave\G;

четверг, 5 апреля 2012 г.

update-alternatives

Для того что бы добавить новую ссылку в update-alternatives:
sudo update-alternatives --install /usr/bin/x-terminal-emulator x-terminal-emulator /usr/bin/terminator.wrapper 50
Для того что бы её активизировать:
sudo update-alternatives --config x-terminal-emulator

четверг, 17 ноября 2011 г.

Сообщение о дублировании репозиториев

В моей десктопной Ubuntu 10.04 с недавнего времени при apt-get update начало выдавать сообщение о дублировании репозиториев:

W: Duplicate sources.list entry http://archive.canonical.com/ubuntu/ lucid/partner Packages (/var/lib/apt/lists/archive.canonical.com_ubuntu_dists_lucid_partner_binary-i386_Packages)
Смотрел в /etc/apt/sources.list несколько раз- все нормально, никакого дублирования. Нашел дубль в /etc/apt/sources.list.d/lucid-partner.list. С какого момента появилась эта директория не в курсе, но теперь надо учитывать её наличие.

вторник, 8 ноября 2011 г.

Медленный заход по SSH

Довольно широко известно, что если на сервер очень долго отвечает на запрос логина по ssh- надо копать в сторону DNS, однако столкнулся с другой проблемой.
пробуем:
ssh -v user@host
  В выводе видим такие строчки:
debug1: Unspecified GSS failure.  Minor code may provide more information
Credentials cache file '/tmp/krb5cc_1000' not found
Идем на сервер в /etc/ssh/sshd_conf, устанавливаем:
# GSSAPI options
GSSAPIAuthentication no
#GSSAPIAuthentication yes
#GSSAPICleanupCredentials yes
#GSSAPICleanupCredentials yes
После этого логин стал происходить значительно быстрее.

upd. можно "GSSAPIAuthentication no" включить и на клиенте, в файле /etc/ssh/ssh_config или ~/.ssh/config