iSCSI Quorum Disk

Вот здесь описано как сделать iSCSI Quorum Disk для двухголового Proxmox’а, но на RH-based Linux, что довольно странно, т.к. сам Proxmox построен на Debian, хотя и с RedHat ядром.
Но у меня реально есть только Дебианы и там не везде есть LVM.
Итак…

dd if=/dev/zero of=/var/proxmox2quorumdisk bs=1024 count=100

И никакого lvm не надо.
Ставим сервер aka target.


apt-get install iscsitarget iscsitarget-dkms
echo "ISCSITARGET_ENABLE=true" > /etc/default/iscsitarget

В /etc/iet/ietd.conf пишем:


Target iqn.2013-02.tld.domain.host:p1qdisk.lun1
IncomingUser rquser rqpass
OutgoingUser
Lun 0 Path=/var/proxmox2quorumdisk,Type=fileio
Alias LUN1
MaxConnections 4

echo "iqn.2013-02.tld.domain.host:p1qdisk.lun1 IP1,IP2,IP3" > /etc/iet/initiators.allow

И… запускаем:

/etc/init.d/iscsitarget start

Теперь может возникнуть желание расшарить этот диск только с определенного IP. Статная обёртка в Debian этого не позволяет. Пропатчить можно так:

echo "ISCSITARGET_OPTIONS='--address=IP'" >> /etc/default/iscsitarget

И правим в /etc/init.d/iscsitarget в функции ietd_start строку:

start-stop-daemon --start --quiet --oknodo --exec $DAEMON -- $ISCSITARGET_OPTIONS

Перезапускаем:

/etc/init.d/iscsitarget restart

Теперь настроим клиента aka initiator.

apt-get install open-iscsi

Правим /etc/iscsi/iscsid.conf:

node.startup = automatic

/etc/init.d/open-iscsi restart

Подключаем диск:


iscsiadm -m discovery -t st -p IP
iscsiadm -m node

iscsiadm -m node --targetname "iqn.2013-02.tld.domain.host:p1qdisk.lun1" --portal "IP:3260" --op=update --name node.session.auth.authmethod --value=CHAP
iscsiadm -m node --targetname "iqn.2013-02.tld.domain.host:p1qdisk.lun1" --portal "IP:3260" --op=update --name node.session.auth.username --value=rquser
iscsiadm -m node --targetname "iqn.2013-02.tld.domain.host:p1qdisk.lun1" --portal "IP:3260" --op=update --name node.session.auth.password --value=rqpass
iscsiadm -m node --targetname "iqn.2013-02.tld.domain.host:p1qdisk.lun1" --portal "IP:3260" --login

По идее после этого должен появиться новый диск. У меня это /dev/sdc

Теперь на нём создадим Quorum Disk:

fdisk /dev/sdc

Далее создаём новый раздел: n, p, 1, w. Ну там для размера Enter понажимаем для подтверждения полного размера.

mkqdisk -c /dev/sdc1 -l p1qdisk

Перезагружаем клиентов на клиентах:

/etc/init.d/open-iscsi restart

А дальше по тексту оригинальной инструкции и всё сработает.

Внезапно: Простоквашино

Уже неделю смотрю с сыном мультики про троих из Простоквашино. Сейчас они воспринимаются по-другому. Матроскин и Шарик постоянно ругаются и спорят, а мамаша Дяди Фёдора вообще злобная истеричка.
Самый добрый из последнего вновь увиденного — «Жил был пёс»

Собственный SMS шлюз

Сначала подготовим сервер. Я ставил это на Fedora 18 и Debian 7, на x86, amd64 и arm в исполнении Raspberry Pi. Разница только в способе установки пакетов.
Сначала инструменты для работы с sms через 3g/4g модемы Huawei, которые создают /dev/ttyUSB* устройства при подключении.

Huawei выбран потому что эти модемы работают очень стабильно в отличие от ZTE. Прочие производители не тестировались ввиду отсутствия в свободной продаже в Самаре.

При подключении 3G модема в USB должны появиться три устройства:


/dev/ttyUSB0
/dev/ttyUSB1
/dev/ttyUSB2

Обычно нулевое устройство — основное для передачи данных. Оно же занимается для подключения по GPRS и производным протоколам. Если модем не используется для этого, то 0 устройство можно использовать для SMS. А вот если используется, что для разных модемов для отправки SMS придётся подбирать экспериментальным путём либо 1 либо 2 устройство.

Приступим.

apt-get install gammu gammu-smsd

В связи с особенностью используемых мной шлюзов хранить всё это будем в /home/sms


mkdir -p /home/sms
cd /home/sms
rm -f /etc/gammu-smsdrc
ln -s /etc/gammu-smsdrc /home/sms/gammu-smsdrc

Конфиг /home/sms/gammu-smsdrc:


[smsd]
Service = files
PIN = 0000
LogFile = syslog
InboxPath = /home/sms/inbox/
OutboxPath = /home/sms/outbox/
SentSMSPath = /home/sms/sent/
ErrorSMSPath = /home/sms/error/

debuglevel = 1
logfile = /home/sms/smsd.log

[gammu]
port = /dev/ttyUSB0
model = at
connection = at19200
synchronizetime = yes
logfile = /home/sms/gammu.log
logformat = textalldate
use_locking = yes
;gammuloc =
;gammucoding = utf8

Файл запуска/перезапуска сервиса /home/sms/restart:


#!/bin/bash

killall -q gammu-smsd && sleep 10

cd /home/sms
>smsd.log
touch smrsh.log
chmod 1660 smsd.log smrsh.log
mkdir -p error inbox outbox sent
chmod 1770 error inbox outbox sent
chgrp mail smsd.log smrsh.log error inbox outbox sent

gammu-smsd -c /home/sms/gammu-smsdrc -d

С учётом того под каким юзером будем запускать этого домена нужно сделать:

chown -R user:group /home/sms

Нужно учесть, что юзер должен принадлежать группе, которая может писать в /dev/ttyUSB0.

Ну и запускаем:

/home/sms/start

Для автоматического запуска в /etc/rc.local вписываем эту же команду.

Проверить работу можно так, заменив телефон на свой:

gammu-smsd-inject -c gammu-smsdrc TEXT "+79020000000" -textutf8 "дата/date `date`" -unicode

Теперь создаём отдельный поддомен для отправки sms через e-mail. В sendmail добавляем его в /etc/mail/local-host-names и прописываем в virtusertable:

@subdomain.domain.tld smsg

а в aliases:

smsg: "|/etc/mail/smrsh/smsg"

smsg может выглядеть так:

#!/bin/bash

LOG=/tmp/smsg
BF=''
SMS=''
MOB=''

date >> $LOG
set >> $LOG
env >> $LOG

while read L; do
    echo $L >> $LOG
    if [ -z "$L" ]; then
        BF=1
        continue
    fi
    if [ -z "$BF" ]; then
        if [ "${L:0:4}" == "To: " ]; then
            TO=${L:4}
            TO=${TO# *}
            TO=${TO%@*}
            if [ ${#TO} != 10 ] || [ "${TO:0:1}" != "9" ]; then
                echo "BAD TO" >> $LOG
                exit 403
            fi
            MOB="+7"$TO
        fi
    else
        if [ -z "$SMS" ]; then
            SMS=$L
        else
            SMS=$SMS$'\n'$L
        fi
    fi
done

if [ -n "$MOB" ] && [ -n "$SMS" ]; then
    echo "--- SMS ---" >> $LOG
    echo "$MOB" >> $LOG
    echo "$SMS" >> $LOG
    echo "=== === ===" >> $LOG
    gammu-smsd-inject -c /home/sms/gammu-smsdrc TEXT "$MOB" -textutf8 "$SMS" -unicode -len 319  1>>$LOG 2>&1
fi

Upgrade Fedora 19 до 20 x86_64

На днях обновился до Fedora 20.
Сам процесс прошел по банальному сценарию:

export LANG=C
rpm --import https://fedoraproject.org/static/246110C1.txt
yum update yum
yum --releasever=20 distro-sync

Всё прошло без сучка и задоринки. Перезагрузился тоже без проблем.
А вот со входом в систему случилось странное. По привычке ввёл пароль и попал… в Gnome 3, которым не пользуюсь вообще. Да и не было его на моём ноуте до этого. А теперь аж три гуя на выбор: Gnome, MATE, Xfce. После перевхода с принудительным выбором Xfce стало привычно. Но чего-то не хватало, а именно bluetooth аплета. А у меня наушники беспроводные.

Смотрим чего натворил yum:

Jan 28 21:12:34 Erased: PackageKit-device-rebind-0.8.9-6.fc19.x86_64

Jan 28 21:12:40 Erased: mate-bluetooth-libs-1.6.0-5.fc19.x86_64
Jan 28 21:12:40 Erased: mate-bluetooth-1.6.0-5.fc19.x86_64

Jan 28 21:12:42 Erased: gvfs-obexftp-1.16.3-2.fc19.x86_64
Jan 28 21:12:43 Erased: 1:obex-data-server-0.4.6-5.fc19.x86_64
Jan 28 21:13:21 Erased: jpackage-utils-1.7.5-27.fc19.noarch
Jan 28 21:13:30 Erased: systemd-sysv-204-18.fc19.x86_64
Jan 28 21:13:44 Erased: xfce4-icon-theme-4.4.3-8.fc19.noarch

Читаем release note (http://docs.fedoraproject.org/en-US/Fedora/20/html/Release_Notes/sect-Release_Notes-Changes_for_Desktop.html), охреневаем, думаем, чешемся, пробуем замену (yum install -bluedevil),
охреневаем еще больше:

Установить  2 пакета (+33 зависимых)

Объем загрузки: 83 M
Объем изменений: 182 M

Плюём и пользуем консоль:

$ /usr/bin/bluetoothctl
[NEW] Controller C4:85:08:46:3C:E5 ssg-0 [default]
[NEW] Device 00:60:D1:00:55:30 Bluetooth Mouse
[NEW] Device 76:8E:46:66:20:4C ANDROID BT
[NEW] Device 98:6C:F5:7E:6A:5E ZTE_LEO_Q1
[NEW] Device 2C:26:C5:DB:63:87 ZTE V880E
[NEW] Device 00:0D:FD:35:CD:14 Motorola S305
[NEW] Device 00:60:D1:00:17:AA Bluetooth Mouse
[bluetooth]# agent on
Agent registered
[bluetooth]# connect 00:0D:FD:35:CD:14
Attempting to connect to 00:0D:FD:35:CD:14
[CHG] Device 00:0D:FD:35:CD:14 Connected: yes
Connection successful
[bluetooth]# quit

Всё. Наушники работают.

Иногда можно получить ошибку:

Failed to connect: org.bluez.Error.NotReady

Лечится так:

hciconfig hci0 up

Proxmox и IPv6

Время заставляет использовать IPv6. Работать IPv6 под Proxmox удалось настроить только в режиме моста.
Хост под Proxmox настраиваем как обычно:
/etc/network/interfaces:

iface vmbr0 inet6 static
        address 2a00:15f8:C001:3::2
        netmask 64
        gateway 2a00:15f8:c001:3::22

Переподнимаем интерфейс или перезапускаем сеть.

Далее останавливаем контейнер. Добавляем в контейнер «Сетевое оборудование» (например, ipv6). Правим в контейнере файл /etc/network/interfaces.tail:

auto ipv6
iface ipv6 inet6 static
	address 2a00:15f8:C001:3::3
	netmask 64
	gateway 2a00:15f8:c001:3::22
	up route -A inet6 del default dev venet0

Последняя строчка нужна чтобы уничтожить вражеский маршрут добавляемый в /etc/network/interfaces (вот зачем они так сделали?):

iface venet0 inet6 manual
	up route -A inet6 add default dev venet0
	down route -A inet6 del default dev venet0

Запускаем контейнер.

После этого делаем ping6 ipv6.google.com и радуемся.

Подлость от Ростелекома

Минувшие выходные прошли под флагом борьбы за свой оплаченный интернет.
Сначала (в пятницу) соединения начали рваться, а потом вообще пропал всходящий трафик. В общем, под выходные спецы на той стороне что-то намутили.

Проблема номер раз.
Выдают белый внешний IP в стандартной PPPoE сессии. При этом все соединения наружу идут с другого IP. Первым сломался DynDNS. Сначала подумал, что проксируют. Перенастроил соединение добавив в /etc/ppp/peer/rt.fttb строку:
unit 35
Это дало постоянное имя интерфейса ppp35 для этого соединения (у меня несколько внешних pppoe). Затем исправил /etc/ddclient.conf:
use=if, if=ppp35
Технически всё заработало, но по ssh внутрь всё равно снаружи попасть было нельзя — трафик не шел. Справедливости ради стоит заметить, что внутри Ростелекома соединения на этот белый IP шли на ура.
Поскольку аналогичная конфигурация в другой точке города работала по иному, то тщательно сравнил и нашел разницу. Оказалось дело в диапазонах белых IP адресов, которые выдавались.
Оказалось, что на каждой точке есть две железки, которые дают инет:

# pppoe-discovery -I eth1
Access-Concentrator: MX960-1
Got a cookie: 85 3d c1 4b 07 46 95 f6 3c 64 72 08 ab cd 4b f2
--------------------------------------------------
AC-Ethernet-Address: 00:25:9e:80:b5:07
Access-Concentrator: MX960-2
Got a cookie: 85 3d c1 4b 07 46 95 f6 3c 64 72 08 ab cd 4b f2
--------------------------------------------------
AC-Ethernet-Address: 00:25:9e:80:b6:08

Опытным путём выяснилось, что MX960-1 выдаёт нормальные белые адреса, а MX960-2 — недоступные.
Пишем в /etc/ppp/peers/rt.fttb:
plugin rp-pppoe.so rp_pppoe_ac 'MX960-1' eth1
и получаем всегда то что нам надо. Разумеется пока эта самая железка будет доступна. Если она пропадёт, то инета не будет вообще никакого.

Проблема номер два.
Часть сайтов стала недоступна. Закономерностей нет. Протокол значения не имеет. Даже ssh сессии начали рваться. Первая же мысль, которую я почему-то быстро отогнал, была верной — MTU.
Странно, что не провелась параллель между первой проблемой и этой.
Но в результате она решилась очень даже тривиально (хоть и с подсказки):
iptables -t mangle -A FORWARD -p tcp -m tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
Не ожидал такого через два-то с половиной года довольно стабильной работы…

Upgrade Fedora 17 до 18 x86_64

Прошел на редкость удачно по несложному сценарию:

#!/bin/bash -x

rpm --import https://fedoraproject.org/static/DE7F38BD.txt

yum update yum
yum clean all
yum --releasever=18 --disableplugin=presto upgrade "yum*" "rpm*"
yum --releasever=18 --disableplugin=presto distro-sync --skip-broken
yum --releasever=18 --disableplugin=presto distro-sync

rpm --rebuilddb

После чего перестал работать skype:
$ skype
skype: error while loading shared libraries: libQtGui.so.4: cannot open shared object file: No such file or directory

Вылечилось:
yum install qt-x11-4.8.5-6.fc18.1.i686

Любопытное наблюдение…

…как только закрыл iptables’ом 53 tcp порт на всех DNS серверах для всех кроме своих же серверов количество всякого бредового tcp флуда (в т.ч. http) стало почти нулевым…

OpenVZ Debian 7 Wheezy Template

Недавно вышел Debian 7 Wheezy. Среди прочего произошел переход на ядро 3.2 и из-за этого произошел отказ от поддержки OpenVZ. Печально, но Wheezy прекрасно работает на ядре 2.6.32 от Squeeze, а еще лучше работает Proxmox 3. Разумеется под него хочется иметь свою сборку Debian7. Сделать это можно так.

Во-первых, vzctl в Proxmox не содержит в себе конфиги для шаблонов, которые упрощают жизнь. Те, что обычно лежат в /etc/vz/conf и именуются типа ve-basic.conf-sample ve-light.conf-sample ve-unlimited.conf-sample и т.п. Поэтому качаем их из основного дистрибутива:

cd /tmp
wget http://mirror.yandex.ru/debian/pool/main/v/vzctl/vzctl_3.0.30.2-4_amd64.deb
dpkg -x vzctl_3.0.30.2-4_amd64.deb .
cp etc/vz/conf/*sample /etc/vz/conf/

Теперь приступим к сборке почти по стандартной процедуре.
Она содержит три этапа. Первый и третий на хосте, а второй — внутри контейнера.

Первый этап:

Создадим файловую структуру контейнера:

aptitude install debootstrap
debootstrap --arch amd64 wheezy /var/lib/vz/private/777 http://mirror.yandex.ru/debian/

Произведём базовые настройки контейнера:

vzctl set 777 --applyconfig basic --save
echo 'OSTEMPLATE="debian-7.0"' >> /etc/vz/conf/777.conf
vzctl set 777 --ipadd 192.168.35.110 --save
vzctl set 777 --nameserver 8.8.8.8 --nameserver 8.8.4.4 --save
mknod --mode 666 /var/lib/vz/private/777/dev/ptmx c 5 2
mkdir -p /var/lib/vz/root/777

Контейнер подготовлен. Запустим его и залезем внутрь:

vzctl start 777
vzctl enter 777

Теперь мы внутри контейнера.

Второй этап:

Будем патриотически использовать локальное зеркало Debian:

echo "deb http://mirror.yandex.ru/debian wheezy main non-free contrib" > /etc/apt/sources.list
echo "deb http://mirror.yandex.ru/debian/ wheezy-updates main contrib non-free" >> /etc/apt/sources.list
echo "deb http://security.debian.org wheezy/updates main non-free contrib" >> /etc/apt/sources.list

aptitude update
aptitude upgrade

chmod 700 /root

sed -i -e '/getty/d' /etc/inittab
sed -i -e '/^#/d' /etc/inittab
sed -i -e '/^\s*$/d' /etc/inittab
echo "1:2345:respawn:/sbin/getty 38400 tty1" >> /etc/inittab

sed -i -e 's@\([[:space:]]\)\(/var/log/\)@\1-\2@' /etc/*syslog.conf

rm -f /etc/mtab
ln -s /proc/mounts /etc/mtab

rm -f /etc/ssh/ssh_host_*

echo '
#!/bin/sh
### BEGIN INIT INFO
# Provides:          Generates new ssh host keys on first boot
# Required-Start:    $remote_fs $syslog
# Required-Stop:     $remote_fs $syslog
# Default-Start:     2 3 4 5
# Default-Stop:
# Short-Description: Generates new ssh host keys on first boot
# Description:       Generates new ssh host keys on first boot
### END INIT INFO
ssh-keygen -f /etc/ssh/ssh_host_rsa_key -t rsa -N ""
ssh-keygen -f /etc/ssh/ssh_host_dsa_key -t dsa -N ""
insserv -r /etc/init.d/ssh_gen_host_keys
rm -f \$0
' > /etc/init.d/ssh_gen_host_keys

chmod a+x /etc/init.d/ssh_gen_host_keys
insserv /etc/init.d/ssh_gen_host_keys

dpkg-reconfigure tzdata


Удалим лишние пакеты, если знаем какие. 😉 Например:

dpkg --purge modutils ppp pppoeconf pppoe pppconfig module-init-tools

Далее доставляем всё что нужно в этом шаблоне. Например:

aptitude install ssh quota less mc mtr

Очищаем кэш и вылезаем из контейнера.

aptitude --purge clean
exit

Третий этап:

Теперь контейнер надо собрать в шаблон (template):

vzctl set 777 --ipdel all --save
>/var/lib/vz/private/777/etc/resolv.conf
rm -f /var/lib/vz/private/777/etc/hostname
vzctl stop 777
cd /var/lib/vz/private/777
tar --numeric-owner -zcf /var/lib/vz/template/cache/debian-7.0-amd64-custom.tar.gz .

Вот и всё. Теперь у нас есть template для установки Debian 7 Wheezy в контейнер OpenVZ, например, в Proxmox.

Проверим — работает ли:

# vzctl create 888 --ostemplate debian-7.0-amd64-custom --config basic
Creating container private area (debian-7.0-amd64-custom)
Performing postcreate actions
CT configuration saved to /etc/pve/openvz/888.conf
Container private area was created

Теперь можно наши эксперименты удалить (или оставить — по желанию):

# vzctl destroy 777
# vzctl destroy 888

Как иногда собираются серваки

Пару недель назад были закуплены внутренности для нового терминального сервера. На прошлой неделе под него привезли подходящий блок питания. И вот пока все вокруг празднуют первомай и не путаются под ногами решил я всё это собрать. Сборкой серваков я никогда не занимался и единственный 2U сервер собрал лет 10 назад, а то и больше. Конечно, ожидал трудностей, но не таких…

Дано:

Нужно:

  • Собрать сервак.

Распаковал материнку, процы, память. Поставил. Распаковал один кулер. Поставил. Распаковал второй кулер… WTF?!
Проблема номер раз. Второй кулер просто не помещается. А мешает ему первый. Причём сильно — никак не менее полсантиметра.


2cpu_fuckup012cpu_fuckup02

Первой же мыслью было отпилить кусок радиатора. Но ножовки или напильника под рукой не оказалось.
Немного подумав и посмотрев картинки в гугле было решено купить пару оригинальных Intel’овских кулеров. Они-то уж точно должны подойти. Под это дело был послан гонец в магазин.

Тем временем сервак был собран с одним процом и, соответственно, радиатором. Настало времени поставить память. По рекомендации производителя память для одного процессора нужно вставлять в слоты A и B. И тут снова WTF?!
Проблема номер два. Память во B слот не ставится — мешает кулер…


2cpu_fuckup112cpu_fuckup12

Как хорошо, что была куплена материнка Supermicro… Память прекрасно встала в слоты C и D. После некоторых танцев вокруг сервака он запустился и показал наличие одного процессора и двух планок памяти в сумме на 32GB. Если бы это был Gigabyte, то врядли бы всё это заработало. Установленная Fedora 16 загрузилась пости без проблем, если не считать двух потерянных сетевых интерфейсов, которые, впрочем, были ей предъявлены при помощи udev совершенно без проблем.

Теперь хотя бы стало ясно, что за потраченные 50+ килорублей на меня не будут косо смотреть. 😉

К этому времени вернулся гонец. После бодрой установки первого радиатора… WTF?! Имеем копию первого факапа. Теперь есть 4 кулера, которые не ставятся парой, а в результате я стал «счастливым» обладателем двух Intel’овских «пропеллеров» за 1800 руб.

Но соображалку не пропьёшь! Поскольку радиатор пластинчатый, то лопасти первого радиатора можно пропустить между лопостями второго. Разбираем кулеры. Ставим голые радиаторы на процы. Первый раз что-то срастается. 🙂


2cpu_puremetal02cpu_puremetal1

Разумеется, пропеллеры не встают при таком раскладе на радиаторы. После изучения и разбора пропеллеров от крепёжного элемента был отрезан «лишний» кусок.


2cpu_cooler02cpu_cooler12cpu_cooler2

Получилось довольно удачно. Ни одна из четырёх защелок не была повреждена. Оба пластиковых элемента без труда встали в исходное положение. И, что самое важное, после такой модификации пропеллеры хоть и вплотную, но всё же без проблем встали на свои радиаторы. И тут же были прикручены своими же саморезами на место. Стоит уточнить, что вместо четырёх саморезов в оригинальной конструкции теперь у нас только три. Четвертое крепление было срезано, как видно на картинке выше. На устойчивость конструкции это никак не повлияло.

Зато в результате мы получили почти то что было нужно. 😉

2cpu_profit

Теперь терминальный сервере имеет 24 виртуальных ядра и 32 гига оперативки. Юзеры будут довольны. >:E

P.S. качество фоток соответствует качеству китайской пяти мегапиксельной камере…