пятница, 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

четверг, 27 октября 2011 г.

Apache и Reverse DNS в логах

Reverse DNS на каждый запрос это, понятное дело, плохо. Однако обнаружил, что по умолчанию эта опция включена(проверено на CentOS5, Ubuntu 10.04).
Причина - параметр LogFormat, в котором используется опция %h. Необходимо её заменить на %a.

Первоисточник: http://betabug.ch/blogs/ch-athens/933

четверг, 6 октября 2011 г.

Rsyslog в Ubuntu для приема сообщений с удаленных хостов.

 Конфиги для rsyslog найти несложно. пример:
# provides UDP syslog reception
$ModLoad imudp
$UDPServerRun 514

#Custom config:
$template RemoteHost,"/var/log/remote/%HOSTNAME%.log"
$template RemoteFromHost,"/var/log/remote/%FROMHOST%.log"
:fromhost, isequal, "109.170.49.98" ?RemoteFromHost
:fromhost, isequal, "109.170.49.98" ~
:source, isequal, "hostname" ?RemoteHost
:source, isequal, "hostname" ~ 

Взято из: http://dng.kiev.ua/node/21
Теперь хитрости, которых там нет:
В файле /etc/default/rsyslog:
RSYSLOGD_OPTIONS="-c4 -r -x"
Если в логах будут отображаться сообщения вида: rsyslogd: Could not open dynamic file  - discarding message, то:
В файле /etc/rsyslog.conf

$FileOwner syslog
$FileGroup adm
$FileCreateMode 0640
$DirCreateMode 0755
$Umask 0022
$PrivDropToUser syslog
$PrivDropToGroup adm
  Особое внимание обратить на параметр "$PrivDropToGroup" => http://rsyslog-rsyslog-users.1305293.n2.nabble.com/Re-Could-not-open-dynamic-file-discarding-message-td4849016.html

И все равно пришлось делать так:
mkdir /var/log/remote
chown syslog:adm /var/log/remote
 После этого логи пошли нормально.