вторник, 14 мая 2013 г.

Установка FTP-сервера для CloudStorage на CentOS 6

Необходимо выкладывать часть файлов на clodo-хранилище. Краткая версия для CentOS 6.

Теория.
Управление файлами и контейнерами в Облачном хранилище можно осуществлять посредством API, различных приложений-клиентов и веб-интерфейса панели Clodo. Чтобы не устанавливать на ваш компьютер дополнительных программ, а управлять файлами в хранилище с помощью обычного FTP-клиента, можно на вашем сервере (или любом другом компьютере) установить FTP-сервер, который будет служить ретранслятором стандартных команд FTP в понятное Облачному хранилищу API.

Практика.
1. Установка пакетов
yum install python-daemon python-setuptools git

2. Скачать и установить библиотеку языка Python для работы с облачным хранилищем; расширение для работы с FTP-серверами/клиентами и сам FTP-сервер.

# Установка python-cloudfiles
git clone git://github.com/ClodoCorp/python-cloudfiles.git
cd python-cloudfiles && python setup.py install && cd ..

# Установка pyftpdlib, версия имеет значение - более новая не запустится
wget http://pyftpdlib.googlecode.com/files/pyftpdlib-0.7.0.tar.gz 
tar xf pyftpdlib-0.7.0.tar.gz
cd pyftpdlib-0.7.0 && python setup.py install && cd ..

# Установка ftp-cloudfs
git clone git://github.com/ClodoCorp/ftp-cloudfs.git

3. Запуск
ftpcloudfs -b 127.0.0.1 -p 2021 -a http://api.clodo.ru -l  /var/log/ftpcloudfs.log --workers=2 --pid-file=/var/run/ftpcloudfs.pid, где

-b 127.0.0.1 указывает IP-адрес, который будет прослушивать сервер
-p 2021 указывает порт, прослушиваемый сервером
-l  /var/log/ftpcloudfs.log путь к лог-файлу FTP-сервера
-a http://api.clodo.ru адрес API
--workers=2 количество рабочих процессов FTP-сервера
--pid-file=/var/run/ftpcloudfs.pid путь к файлу, в котором будет
записан номер главного процесса FTP-сервера

4. Подключение к серверу:
ftp -n 127.0.0.1 2021
> user API_USER_FROM_CLODO_PANEL
> password API_KEY_FROM_CLODO_PANEL

Литература:
http://lib.clodo.ru/cloud-storage/ftp_to_cs.html

четверг, 4 апреля 2013 г.

Backupninja ошибка "Previous backup seems to have failed, regressing destination now"

Пришел отчет от одного из серверов с сообщением об ошибке -
Previous backup seems to have failed, regressing destination now.

В качестве обходного пути нужно удалить на приемнике близкие по дате файлы current_mirror.SOMEDATE в директории rdiff-backup-data.

четверг, 28 марта 2013 г.

OpenX slow page (workaround)

Обратились с проблемой - мол, тормозит OpenX, но не весь, а только несколько страничек. Конкретно, edit-zone.php. Страница открывается, но через минуту ни больше, ни меньше.
В логах самого OpenX наблюдаются такие записи, при попытках перейти на вышеуказанный урл:
"RPC server did not send response before timeout."
Стал разбираться. В логах httpd ничего противозаконного, nginx (frontend) показывает время ответа от httpd (backend) в районе 60 секунд. Возможно, таймаут какой-то. Ищу в php.ini строчки со значением 60:
$ grep 60 /etc/php.ini 
*****
max_input_time = 600
default_socket_timeout = 60
mysql.connect_timeout = 60
;mssql.timeout = 60
apc.ttl=3600
****
Меняю default_socket_timeout на 30, перезапускаю httpd, открываю страницу - теперь 30 секунд задержка. Логи OpenX что-то говорят про XML RPC сервер, который не отвечает на запросы.
Ищу timeout в php-файлах проекта:
grep -ri timeout *
****
OA/XmlRpcClient.php:            ini_set('default_socket_timeout', $old_timeout)
****

Среди огромного вывода замечаю вышеуказанные строки. Открываю файл, немного изучаю - curl пытается отправить запрос на какой-то сервер (что за сервер, что за запрос непонятно).
Пробую выяснить - вношу в код:
file_put_contents('/tmp/123123', curl_getinfo($ch));
Т.е. записываю в файл /tmp/123123 содержимое curl-запроса, верней его часть. Узнаю, что запрос - https://api.pc.openx.com:443/api/public/v200000000000000-1-100Array.
Он не проходит по таймауту, пробую локально, пробую из браузера - не проходит.
Ставлю "грязный" хак - curl_setopt($ch,CURLOPT_CONNECTTIMEOUT, 2);
Данная страничка открывается 2 секунды вместо минуты. Вроде приемлемо. Вот такой поток сознания.

понедельник, 25 марта 2013 г.

Samba и пользователи в ldap

Небольшая заметка для себя, скорее несколько моментов, на которые стоит обратить внимание. Итак, имеется ldap-сервер с логинами/паролями пользователей и прочей информацией. Нужно, чтоб пользователи хранили важные данные на отдельном samba-сервере, причем использовать имеющуюся базу пользователей из ldap.
Сервер с samba на CentOS 6.2 обновлен до версии 6.4, в которой samba уже версии 3.6.

1. Вообщем, ставим или обновляем:
sudo yum install samba nss-pam-ldapd

2. Правим /etc/nsswitch.conf (конфигурационный файл cистемных баз данных и переключателя сервисов имен). Т.е. искать информацию о пользователях/паролях/группах не только в файлах, но и ldap
*****
passwd:     files ldap
shadow:     files ldap
group:      files ldap
*****

3. Правим /etc/nslcd.conf (конфигурационный файл демона, который будет проверять/искать информацию в ldap)

uri ldap://LDAP_SRV_IP
base dc=DOMAIN,dc=local
binddn cn=admin,dc=DOMAIN,dc=local
bindpw SOMEPW
scope sub
base   group  ou=Groups,dc=DOMAIN,dc=local
base   passwd ou=Users,dc=DOMAIN,dc=local
base   shadow ou=Users,dc=DOMAIN,dc=local

# На данном моменте происходит подмена параметра homeDirectory на homeDirectory2 или подстановку известного пути. В моем случае у пользователей в атрибуте homeDirectory хранится путь к почтовой папке (по историческим причинам, конечно). У части пользователей был ранее заведен атрибут homeDirectory2 с путем к домашней samba-директории. Это нужно мне, чтоб изменить путь к домашней директории пользователя (/home/vmail/e-mail -> /samba/homes/uid)
map    passwd homeDirectory    "${homeDirectory2:-/samba/homes/$uid}"

4. Правим /etc/samba/smb.conf. Особо расписывать не буду, должно быть более менее понятно.
*******
        security = user
        passdb backend = ldapsam:ldap://LDAP_SRV_IP
        ldap suffix = dc=DOMAIN,dc=local
        ldap user suffix = ou=Users
        ldap group suffix = ou=Groups
        ldap machine suffix = ou=Computers
        ldap admin dn = "cn=smbadmin,dc=DOMAIN,dc=local"
        ldap delete dn = no
        ldap passwd sync = yes
        ldap ssl = off
# Важный параметр, без него не будет использоваться pam, а значит не будут автоматически создаваться домашние папки пользователей при первом входе.
        obey pam restrictions = yes

[homes]
        comment = Home Directories
        ;path = /samba/homes/%S
        browseable = no
        writable = yes
        valid users = %S
****************

5. Вводим 2 раза пароль пользователя smbadmin
smbpasswd -W

6. Правим /etc/pam.d/samba. Перед session    include      password-auth вставляем
session    required     pam_mkhomedir.so skel=/etc/skel/ umask=0077

7. Запуск/перезапуск сервисов
service nslcd restart
service smb restart
service nmb restart

воскресенье, 24 марта 2013 г.

Установить модуль xt_LOG (Gentoo)

Имеется Gentoo, не хватает модуля для логгирования iptables. Краткая инструкция для себя.
# В данном случае версия ядра 3.5.7
cd /usr/src/linux
make menuconfig

# Установить CONFIG_NETFILTER_XT_TARGET_LOG=m и выйти, сохранив конфиг

# Откомпилировать модуль
make net/netfilter/xt_LOG.ko

# Скопировать в нужный каталог
cp net/netfilter/xt_LOG.ko /lib/modules/3.5.7-gentoo/kernel/net/netfilter/

# Создать файл зависимостей модулей
depmod -a

# Проверить наличие xt_LOG
grep -i xt_log /lib/modules/3.5.7-gentoo/modules.dep

# Получить информацию о модуле
modinfo xt_LOG

# Загрузить модуль
modprobe xt_LOG

# Добавить модуль в автозагрузку в файле /etc/conf.d/modules
modules="xt_LOG"

# Добавить правило в iptables для ограничения числа сообщений о блокировке пакета от
одного хоста-отправителя до 1 раза в минуту
iptables -A INPUT -m hashlimit --hashlimit-upto 1/min --hashlimit-burst 1 
--hashlimit-mode srcip --hashlimit-name lim_log --hashlimit-htable-expire 60000 
-j LOG --log-prefix "IPTABLES: DEF DROP: "

# Сохранить текущий набор правил
iptables-save > /var/lib/iptables/rules-save

# Отредактировать в /etc/syslog-ng/syslog-ng.conf
destination iptables { file("/var/log/iptables.log"); };
filter f_iptables {    message("IPTABLES.*") };
log { source(src); filter(f_iptables); destination(iptables); flags(final); };

# Перезапустить syslog-ng
/etc/init.d/syslog-ng reload

# Добавить в /etc/logrotate.d/syslog-ng.conf
/var/log/iptables.log {
    missingok
    notifempty
    rotate 300
    compress
    sharedscripts
    postrotate
        /etc/init.d/syslog-ng reload > /dev/null 2>&1 || true
    endscript
}

четверг, 14 февраля 2013 г.

MySQL Relay log read failure

Если в выводе команды show slave status\G появляется:

*****
Last_SQL_Errno: 1594
Last_SQL_Error: Relay log read failure: Could not parse relay log event entry.
****
Можно воспользоваться следующими шагами для восстановления репликации (может вам НЕ подойти, используйте острожно, делайте бэкапы):
1. Остановить репликацию
mysql> slave stop;
2. Вывести информацию о состоянии репликации и сохранить/запомнить
mysql> show slave status\G
3. Сделать ресет соединения с мастером, т.е. затрется информация о позиции в бинарном логе мастера, при этом параметры соединения (master host, master port, master user, or master password) сохранятся в памяти.
mysql> reset slave;
4. Изменить параметры репликации, вставив значения из ранее сохраненного вывода slave status
mysql> CHANGE MASTER TO MASTER_LOG_FILE='<relay_master_log_file>', MASTER_LOG_POS=<exec_master_log_pos>;
5. Запустить slave
mysql> slave start;

Литература:
http://dev.mysql.com/doc/refman/5.5/en/reset-slave.html
http://www.watters.ws/mediawiki/index.php/Recover_from_mysql_log_read_failure

четверг, 7 февраля 2013 г.

Странность с check_ping

В состав плагинов для nagios входит утилита check_ping. Внезапно стала выдавать:

/usr/lib64/nagios/plugins/check_ping -H dp-hvs01.DOMAIN -w 100.0,20% -c 500.0,60%
CRITICAL - Network Unreachable (dp-hvs01.DOMAIN)

Лечится добавлением ключа -4 в определение команд check_ping и check-host-alive:
command_line    $USER1$/check_ping -H $HOSTADDRESS$ -w $ARG1$ -c $ARG2$ -4 -p 5

среда, 6 февраля 2013 г.

Настройка exim для работы с redmine

Внезапно возникла задача поднять сабж.

1. Установить ruby.
sudo yum install ruby

2. Скопировать скрипт rdm-mailhandler.rb из поставки redmine в /usr/local/bin, сделать исполняемым.
sudo cp rdm-mailhandler.rb /usr/local/bin
sudo chmod +x /usr/local/bin/rdm-mailhandler.rb

3. Настройка exim:
Для роутеров имеет значение порядок:

itdesk_router:
        driver = accept
        domains = +local_domains
        local_parts = it-desk
        transport = itdesk_transport

itdesk_transport:
        driver = pipe
        command = /usr/local/bin/rdm-mailhandler.rb --url http://it-desk.DOMAIN --key SECRET --project tickets --unknown-user create
        delivery_date_add
        envelope_to_add
        return_path_add

Литература:
http://www.redmine.org/projects/redmine/wiki/RusRedmineReceivingEmails

no iKVM64 in java.library.path (SuperMicro IP KVM)

Предыстория: нужно было из дома удаленно перегрузить сервер на базе SuperMicro X9SCi-X9SCA. Поскольку полной уверенности в том, что новое ядро заведется с первого раза не было, нужно было наблюдать за консолью сервера. В сети есть несколько серверов, на которые проброшен SSH, поэтому я, не долго думая, сделал проброс 80-го порта на удаленный хост с помощью:
ssh -p PORT -L 2080:IP:80 USER@HOST, где
PORT - номер внешнего порта, который натится в 22 порт на отдельном сервере
2080 - произвольный порт на локальной машине
IP - IP-адрес интересующего сервера внутри сети, например, 10.1.11.10
80 - порт на интересующем сервере внутри сети. в моем случае 80
USER - имя пользователя
HOST - внешний ip-адрес

Теперь можно зайти в браузере на http://127.0.0.1:2080 и увидеть страницу IP KVM SuperMicro. Залогиниться, нажать Remote Control -> Console Redirection -> Launch Console, на компьютер скачивается launch.jnlp. Запускаем файл и получаем малопонятную ошибку. Открываем файл и замечаем следующие моменты:
1. в файле подразумевается загрузка дополнительного jar-файла для разных ОС (Windows/Linux/Mac) и архитектур (x86/x86_64/amd64)
2. адрес, с которого скачивать файл - https://127.0.0.1:443
3. Секция
   <application-desc main-class="tw.com.aten.ikvm.KVMMain">
     <argument>127.0.0.1</argument>
     <argument>5900</argument>
     *****

Соответственно, нужно пробросить дополнительно порт 443 и 5900:
sudo ssh -p PORT -L 443:IP:443 USER@HOST
ssh -p PORT -L 5900:IP:5900 USER@HOST
Перелогиниться, загрузить файл, запустить и видим такую ошибку JAVA:
"no iKVM64 in java.library.path"
В данном случае помогает изменение файла launch.jnlp:

Найти секцию соответствующую вашей архитектуре и ОС, например:
  <resources os="Linux" arch="x86_64">
    <nativelib href="liblinux_x86_64.jar" download="eager" version="1.0.3"/>
  </resources>

Заменить на:
  <resources os="Linux" arch="x86_64">
    <nativelib href="liblinux_x86_64.jar" download="eager" version="1.0.3"/>
    <property name="jnlp.packEnabled" value="true"/>
    <property name="jnlp.versionEnabled" value="true"/>
  </resources>

Сохранить и запустить заново.
PS: таки не завелось новое ядро с первого раза.

Литература:
http://www.p14nd4.com/blog/2011/09/30/solved-no-ikvm64-in-java-library-path-on-supermicro-ip-kvm/

вторник, 5 февраля 2013 г.

Установка sphinx и pecl-sphinx (Gentoo)


Краткая заметка на память.

# Обновить portage
emerge --sync
emerge portage

# Установить sphinx
USE="debug id64 mysql -postgres stemmer test" emerge app-misc/sphinx

# Скопировать или переименовать конфигурационный файл
cd /etc/sphinx
cp sphinx.conf.dist sphinx.conf

# Настроить разрешения, чтоб группа web могла редактировать конфигурационный файл
chmod 664 /etc/sphinx/*
chown root:web /etc/sphinx/*

# Добавить пользователя и группу sphinx
groupadd -g 494 sphinx
useradd -g sphinx -u 494 -d /var/lib/sphinx -s /bin/bash -c "Sphinx server" sphinx

# Создать папки, где будут храниться логи, pid-файлы и данные
mkdir -p /var/log/sphinx
mkdir -p /var/run/sphinx
mkdir -p /var/lib/sphinx/data

# Настроить правильные разрешения на эти папки
chown sphinx:sphinx /var/log/sphinx
chown -R sphinx:sphinx /var/lib/sphinx
chown sphinx:sphinx /var/run/sphinx

# Добавить в /etc/sudoers что-то типа
%web ALL=NOPASSWD:/etc/init.d/searchd
%web ALL=(sphinx) NOPASSWD:/usr/bin/indexer

# Проверить от пользователя группы web
sudo -u sphinx /usr/bin/indexer
sudo /etc/init.d/searchd restart|stop|start

# Установить расширения php
PHP_TARGETS="php5-4" emerge pecl-sphinx

четверг, 10 января 2013 г.

Cron и переменные окружения

Есть мегаскрипт на php. Ему нужны переменные окружения типа HTTP_HOST для запуска из командной строки по крону. Итого в crontab пользователя:

*/10 * * * * . $HOME/.bashrc; /path/to/script/code.php some_params;


среда, 9 января 2013 г.

mountall: /lib/x86-64-linux-gnu/libc.so.6 version 'GLIBC_2.14' not found (required by /lib/libply.so.2)

Знакомый попросил разобраться. У него вылезло после обновления Ubuntu вот такое сообщение при загрузке:
mountall: /lib/x86-64-linux-gnu/libc.so.6 version 'GLIBC_2.14' not found (required by /lib/libply.so.2)
General error mounting file systems.
A maintenance shell will now be started.
CONTROL-D will terminate this shell and reboot the system


И дальше не грузится. Вылечилось такими действиями:
1. Запретить загрузку plymouth при старте системы (в меню grub2):
добавить в конец строки с linux:
nosplash noplymouth init=/sbin/init -v noplymouth

2. После загрузки:
dpkg-reconfigure -a
Может выдать на экран ошибки. Предложит запустить нижеследующую команду.

Менеджер пакетов постарается разрешить найденные конфликты, предложив удалить или заменить конфликтующие пакеты. Любые действия в этом режиме обязательно требуют подтверждения с вашей стороны (ВНИМАТЕЛЬНО читайте предложенные варианты).
3. apt-get -f install

суббота, 5 января 2013 г.

Apache server-status 404

Для мониторинга необходимо было настроить снятие статуса веб-сервера Apache. Модуль загрузил, настроил - выдает 404 хоть тресни.
Быстрое решение - изменить:

NameVirtualHost *:80
<VirtualHost *:80>
на

NameVirtualHost 1.2.3.4:80
<VirtualHost 1.2.3.4:80>