"Error when reading from SSL socket connection" Dell iDRAC 5 PE2900

1) Find java.security file:

$ sudo find / -name java.security

Password:

/Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/lib/security/java.security

/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home/lib/security/java.security

/Users/jack/Documents/JDK7/Contents/Home/jre/lib/security/java.security

2) Add/Edit line in java.security:

sudo vim /Library/Internet\ Plug-Ins/JavaAppletPlugin.plugin/Contents/Home/lib/security/java.security

jdk.tls.disabledAlgorithms=

OSX: Распаковать JDK в выбранную папку

1) Скачать dmg-файл, например, jdk-7u71-macosx-x64.dmg
2) Кликнуть 2 раза в Finder чтобы примонтировать раздел в папку /Volumes
3) $ pkgutil —-expand  /Volumes/JDK\ 7\ Update\ 71/JDK\ 7\ Update\ 71.pkg JDK7
4) cd JDK7
5) cpio -i < ./jdk17071.pkg/Payload
6) $ mv Contents/Home /tools/jdk-1.7.0_71
7) export JAVA_HOME=/tools/jdk-1.7.0_71

Установка 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

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.

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 секунды вместо минуты. Вроде приемлемо. Вот такой поток сознания.

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

Установить модуль 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
}

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

Странность с 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

Настройка 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/

Установка 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

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

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

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

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

Apache server-status 404

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

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

NameVirtualHost 1.2.3.4:80
<VirtualHost 1.2.3.4:80>

CentOS 6 и KVM. Запуск виртуалки.

Необходимо было запустить виртуалку с Ubuntu на хосте с CentOS6 (64 bit). Собственно, небольшое описание того, что было сделано. Во-первых, хочу отметить, что при настройке надо быть внимательным, иначе получаются весьма забавные вещи. В моем случае, не обратил внимание на вывод команды ip addr show, где было state DOWN для интерфейса в составе моста - из-за чего и было потрачено много времени впустую. Виртуалка была поднята на хосте с Gentoo и переезжала на хост с CentOS ввиду загруженности машины с Gentoo.

1. Проверяем, что процессор поддерживает необходимые инструкции:

egrep '(svm|vmx)' /proc/cpuinfo

2. Проверяем загружены ли необходимые модули:

lsmod | grep kvm

3. Сервер имеет 2 сетевых интерфейса (на самом деле есть еще один, но он отдан под IPMI). Подключаем оба в сеть, копируем /etc/sysconfig/network-scripts/ifcfg-eth0 в /etc/sysconfig/network-scripts/ifcfg-br0. Приводим ifcfg-eth0 к виду (mac-адрес, ip-адрес, маску, шлюз, адрес днс-сервера поменяйте на свои):

DEVICE="eth0"
BRIDGE="br0"
NM_CONTROLLED="no"
ONBOOT=yes
HWADDR=00:25:90:78:74:8C

Файл ifcfg-br0 в таком виде:

DEVICE="br0"
BOOTPROTO="static"
NM_CONTROLLED="no"
ONBOOT=yes
TYPE="Bridge"
DELAY=0
IPV4_FAILURE_FATAL=yes
IPV6INIT=no
NAME="System br0"
IPADDR=192.168.1.XX
NETMASK=255.255.255.0
GATEWAY=192.168.1.Z
DNS1=192.168.1.XY

Файл ifcfg-eth1:

DEVICE="eth1"
BOOTPROTO="static"
NM_CONTROLLED="no"
ONBOOT=yes
TYPE="Ethernet"
UUID="7a455c42-2ceb-4cf2-a13c-a86baf7d42ef"
HWADDR=00:25:90:78:74:8D
PEERDNS=yes
IPV4_FAILURE_FATAL=yes
IPV6INIT=no
NAME="System eth1"
IPADDR=192.168.1.XZ
NETMASK=255.255.255.0

В данном случае eth1 будет использоваться под нужды сервера, eth0 будет входить в состав моста br0 и обслуживать виртуалку(и).

4. Устанавливаем нужные пакеты для работы с мостом и виртуальными TUN/TAP интерфейсами:

sudo yum -y install tunctl bridge-utils

5. Рестартуем сеть командой:
sudo service network restart

6. Проверяем состояние интерфейсов (должны быть в UP):
ip addr show | grep eth | grep state

2: eth0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000

7. Проверяем загружен ли модуль tun:

lsmod | grep tun

Если нет - то:

modprobe tun

Модуль tun - это универсальный TUN/TAP драйвер, позволяющий создавать программные сетевые устройства (программная сетевая карта). TAP симулирует Ethernet устройство и работает на канальном уровне, а TUN работает на сетевом уровне. 

Пакет, посылаемый операционной системой через TUN/TAP устройство, обрабатывается программой, которая контролирует это устройство, в данном случае qemu (см. команду в конце заметки).

Создаем виртуальное устройство tap0:

tunctl -b

8. Поднимаем устройство tap0:

ifconfig tap0 up

9. Проверить/установить параметры в файле sysctl.conf

net.ipv4.ip_forward = 1
net.bridge.bridge-nf-call-ip6tables = 0
net.bridge.bridge-nf-call-iptables = 0
net.bridge.bridge-nf-call-arptables = 0

10. Проверить правила iptables, чтоб не блокировали нужный трафик (в моем случае iptables не использовался). Например, командой:

iptables -I RH-Firewall-1-INPUT -i br0 -j ACCEPT

11. Добавляем интерфейсы в состав моста:

brctl addif br0 eth0

brctl addif br0 tap0

12. Стартуем виртуалку:
/usr/libexec/qemu-kvm -hda /some/path/ubuntu10.04_2.img -m 6144 \
-net nic,macaddr=00:1a:dd:d8:bc:b6 -net tap,ifname=tap0,script=no,downscript=no \
-vnc :0 -name ubuntu -smp 4 -daemonize 

Литература:
http://www.linux-kvm.org/page/Networking
https://wiki.archlinux.org/index.php/QEMU#Networking
https://wiki.archlinux.org/index.php/KVM

Переименовать md-устройство

Увидел такую картину на новом сервере:
[root@proteus ~]# cat /proc/mdstat 
Personalities : [raid1] 
md2 : active raid1 sda2[1] sdb2[2]
      157285304 blocks super 1.2 [2/2] [UU]
      
md127 : active (auto-read-only) raid1 sda3[1] sdb3[0]
      1795714000 blocks super 1.2 [2/2] [UU]
      
md1 : active raid1 sda1[1] sdb1[0]
      511936 blocks [2/2] [UU]
      
unused devices: <none>
[root@proteus ~]# cat /etc/mdadm.conf 
ARRAY /dev/md1 UUID=caa9382c:0099a987:4fbed893:ae34e34e
ARRAY /dev/md/2 metadata=1.2 UUID=68e6b327:6a4816f8:9bbb1e28:6c4a224b name=L146:2

Остановить устройство:

[root@proteus ~]# mdadm --stop /dev/md127 
mdadm: stopped /dev/md127

Собрать заново, используя метаданные на дисках:

[root@proteus ~]# mdadm --assemble /dev/md3 /dev/sda3 /dev/sdb3 --name=3 --update=name
mdadm: /dev/md3 has been started with 2 drives.

Проверка:
[root@proteus ~]# cat /proc/mdstat 
Personalities : [raid1] 
md3 : active raid1 sdb3[0] sda3[1]
      1795714000 blocks super 1.2 [2/2] [UU]
      
md2 : active raid1 sda2[1] sdb2[2]
      157285304 blocks super 1.2 [2/2] [UU]
      
md1 : active raid1 sda1[1] sdb1[0]
      511936 blocks [2/2] [UU]
      
unused devices: <none>

Записать в файл /etc/mdadm.conf:

[root@proteus ~]# mdadm --examine --scan > /etc/mdadm.conf 
[root@proteus ~]# cat /etc/mdadm.conf 
ARRAY /dev/md1 UUID=caa9382c:0099a987:4fbed893:ae34e34e
ARRAY /dev/md/2 metadata=1.2 UUID=68e6b327:6a4816f8:9bbb1e28:6c4a224b name=L146:2
ARRAY /dev/md/3 metadata=1.2 UUID=84bd3509:99237831:c00651e9:04d792ba name=proteus:3

Обновить initramfs:
[root@proteus ~]# cd /boot
[root@proteus ~]# mv initramfs-2.6.32-279.14.1.el6.x86_64.img initramfs-2.6.32-279.14.1.el6.x86_64.img.bak
[root@proteus ~]# dracut /boot/initramfs-2.6.32-279.14.1.el6.x86_64.img $(uname -r)

Контрольная перезагрузка:
[root@proteus ~]# reboot

P.S.: Если вы увидели «active (auto-read-only)» в файле /proc/mdstat, то, возможно, вы просто ничего не записывали в этот массив. Например, после монтирования раздела и любых изменений в примонтированном каталоге, статус автоматически меняется.

The file /boot/grub/stage1 not read correctly.

Сегодня пришлось помучится с установкой нового сервера под ОС CentOS6. На хостинге имелась возможность заказать бесплатную установку ОС. Сервер с 2-мя дисками по 2Т. Разбиение после автоустановки оказалось не подходящим мягко говоря:

# fdisk -l
Диск /dev/sda: 2000.4 ГБ, 2000398934016 байт
******
Устр-во Загр     Начало       Конец       Блоки   Id  Система
/dev/sda1   *         524      243201  1949311035   83  Linux
/dev/sda2               1         523     4200966   82  Linux своп / Solaris
Пункты таблицы разделов расположены не в дисковом порядке

Диск /dev/sdb: 2000.4 ГБ, 2000398934016 байт
*******

Разбил как нужно sdb:
# fdisk -l /dev/sdb
Диск /dev/sdb: 2000.4 ГБ, 2000398934016 байт
******
Устр-во Загр     Начало       Конец       Блоки   Id  Система
/dev/sdb1               1          64      512000   83  Linux
Раздел 1 не заканчивается на границе цилиндра.
/dev/sdb2              64       19646   157286400   83  Linux
Раздел 2 не заканчивается на границе цилиндра.

Создал файловые системы, подмонтировал, скопировал данные с sda.
При попытке установить загрузчик grub на sdb:

# grub-install --recheck --no-floppy /dev/sdb
Probing devices to guess BIOS drives. This may take a long time.
The file /boot/grub/stage1 not read correctly.

Если делать из консоли grub:
# grub
grub> root (hd0,0)
root (hd0,0)
 Filesystem type is ext2fs, partition type 0x83
grub> setup (hd0)
setup (hd0)
 Checking if "/boot/grub/stage1" exists... no
 Checking if "/grub/stage1" exists... no

Error 15t: File not found
grub> root (hd1,0)
root (hd1,0)
 Filesystem type is ext2fs, partition type 0x83
grub> setup (hd1)
setup (hd1)
 Checking if "/boot/grub/stage1" exists... no
 Checking if "/grub/stage1" exists... yes
 Checking if "/grub/stage2" exists... yes
 Checking if "/grub/e2fs_stage1_5" exists... yes
 Running "embed /grub/e2fs_stage1_5 (hd1)"...  27 sectors are embedded.
succeeded
 Running "install /grub/stage1 (hd1) (hd1)1+27 p (hd1,0)/grub/stage2 /grub/grub.conf"... succeeded
Done.

Файл /boot/grub/stage1 находится на диске. Что за хрень?
Оказывается, старый grub не поддерживает 256 битные inode, которые были введены для легкой миграции на ext4.
Проверить размер инод на файловой системе можно так:
# tune2fs -l /dev/sda1 | grep -i 'inode size'
Inode size:               256

Решение - отформатировать заново раздел с 128-битными inode.
# mkfs.ext3 -I 128 /dev/sda1

Поскольку данные я скопировал на sdb, форматировал sda спокойно. )

Gentoo и "ImportError: No module named setuptools"

При попытке установить rdiff-backup (emerge rdiff-backup-1.2.8-r1.ebuild) вылезла такая ошибка:
*****

  File "setup.py", line 4, in <module>
    from setuptools import setup, Extension

ImportError: No module named setuptools
****
Полностью вывод ошибки копировать не буду потому как он большой. В глаза бросилась именно вышеуказанное сообщение. В Gentoo я новичок, как и в Python. Пришлось гуглить, пока не нашел действенный рецепт на каком-то точно не гентушном форуме. Запуск команды python-updater, которая находит и перестраивает проблемные пакеты появившиеся после обновления версии Python, решает проблему. Что за обновление Python было не скажу потому как зашел на этот хост первый раз и нужно было срочно установить такой пакет. Собственно, все, заметка для себя - вдруг придется зайти куда-то, где обновили Python и поломались пару пакетов. ))

Разборки с LSI MegaRAID SAS 9240-8i

Собственно, поставили задачу поднять на SuperMicro X9SCI/X9SCA CentOS. Сервер слабенький, но дисков напихано 8 штук по 2 терабайта каждый. В поставку входит рэйд-контроллер LSI MegaRAID SAS 9240-8i. Заходим на сайт производителя и внимательно изучаем документацию. Скачиваем последние версии прошивки, драйверы, утилиты.
Обновление прошивки проходит с помощью утилиты MegaCli из ОС (на выбор DOS, Windows, Linux, FreeBSD, VMware, Solaris). В моем случае я сначала разбил диски на 2 виртуальных диска (2 в "зеркало", остальные в 5-й рэйд) и установил на один из них CentOS 6. Можно и выполнить прошивку рэйд-контроллера до установки, не суть важно. Главное, чтоб не пропало питание во время прошивки.

Установка утилиты тривиальна:
sudo rpm -ivh MegaCli-8.05.06-1.noarch.rpm
cd /opt/MegaRAID/MegaCli/

Сохранить текущую конфигурацию:
./MegaCli64 -CfgSave -f RaidCfgSave -a0

Распаковать прошивку в в папку с утилитой и выполнить прошивку:
./MegaCli64 -adpfwflash -f imr_fw.rom -a0

Цифра после a в предыдущих командах это номер адаптера в системе (в моем случае один адаптер с индексом 0). Узнать количество адаптеров можно командой ./MegaCli64 -adpCount

Перезагрузиться:
sudo reboot

Также на сайте производителя можно скачать пакет с MIBS. Требуется установка net-snmp:
sudo yum -y install net-snmp net-snmp-utils

Установка пакета от LSI
rpm -ivh sas_snmp-12.08-0303.x86_64.rpm

Копирование конфигурационного файла:
sudo mv /etc/snmp/snmpd.conf /etc/snmp/snmpd.conf.def
sudo cp /etc/lsi_mrdsnmp/lsi_mrdsnmpd.conf /etc/snmp/snmpd.conf

Перезапуска служб:
sudo service snmpd restart
sudo service lsi_mrdsnmp restart

Добавить в автозагрузку:
sudo chkconfig snmpd on
sudo chkconfig lsi_mrdsnmpd on

Скопировать MIBS в директорию с другими MIBS:
sudo cp /etc/lsi_mrdsnmp/sas/LSI-AdapterSAS.mib /usr/share/snmp/mibs/LSI-AdapterSAS.mib.txt

Проверка:
snmpwalk -v1 -c public 127.0.0.1 -m LSI-MegaRAID-SAS-MIB .1.3.6.1.4.1.3582