Борьба с ipv6 продолжается — dhclient

С завидной регулярностью выпадает dhclient, назначенный принимать ipv6 префикс. Запускается он при подняли интерфейса.

/etc/network/interfaces

up dhclient -cf /etc/dhcp/dhclient6.conf  -pf /run/dhclient6.vmbr0.pid -6 -P -v $IFACE

Вылетает с ошибкой dhclient: Impossible condition at dhc6.c:4111. При этом отваливается ipv6 на proxmox хосте и на всех openvz контейнерах.

Установлен пакет isc-dhcp-client_4.2.2.dfsg.1-5+deb70u6_amd64.deb из состава isc-dhcp.

По теме нашлось обсуждение на французском, как раз на форуме online.net. В тексте есть заплатка, вот ссылка на нее на github. Патч для версии 4.3, пришлось аналогичные манипуляции проделать вручную.

Руководство по сборке пакетов в Debian https://wiki.debian.org/BuildingTutorial

Сделал, запустил, пока работает, мониторю.

UPDATE

Увы, не помогло. Прежняя ошибка исчезла, появились новые

dhclient: Cannot renew without an active binding.
...
dhclient: Max retransmission duration exceeded.

ISPmanager и PowerDNS SupеrMaster

Все так же в рамках переезда на новый сервер и обустройства. ISPmanager по-умолчанию считает себя главным NS сервером. В качестве зависимых (внешних) поддерживаются серверы с установленными ISPmanager или DNSmanager. Покупать и, главное, устанавливать и поддерживать эти продукты для такой задачи показалось неразумным, поэтому получился такой конфиг.

1. Главный сервер с ISPmanager, на котором установлен PowerDNS. Тут мог бы быть и BIND, для данной схемы это не важно, но так уж получилось. Этот сервер нигде не светится и напрямую ни один домен не обслуживает. Это наш скрытый супермастер. Он не в курсе, что он супермастер, для себя самого он master, остальное настраивается на слэйвах.

Здесь важны 2 вещи в /etc/powerdns/pdns.conf

master=yes
disable-axfr=no
allow-axfr-ips=212.83.83.83,141.187.161.33

Извещаем сервер, что он мастер, включаем AXFR, указываем адреса slave серверов, которые мастер будет извещать об изменениях в доменных зонах.

2. На отдельных VPS установлены 2 копии того же pdns в режиме slave. Далее нужно известить pdns о наличии супермастера. Для SQL backeng (gmysql в нашем случае) нужно добавить запись в табличку supermasters базы pdns.

insert into supermasters values ('192.168.111.111', 'ns1.example.com', 'internal');

В первой колонке (ip) должен быть адрес супермастера, во второй — имя NS, которое будет передаваться в AXFR, в третьей пользователь (для аутентификации, которая пока не работает). В данном случае ns1.example.com — это не имя супермастера, это имя одного из слейвов.

Если NOTIFY запрос для домена example.com слэйву пришел с адреса IP 192.168.111.111, если в зоне есть NS запись ns1.example.com, то слэйв создает у себя зону для example.com и перетаскивает к себе все записи. Ну и ведет себя в дальнейшем как нормальный slave.

Есть небольшая проблема — удаление зоны. Скрытый супермастер никак не извещает об удалении зоны, не положено. То есть оба slave будут продолжать считать себя ответственными за зоны, которых в них уже не должно быть.

Вот скрипт, который перидически (cron daily) проверяет все свои домены на присутствие у супермастера. Скрипт найден в сети и адаптирован под ответы pdns, они отличаются от bind (см. закомментированные строчки AUTH & if).

#!/bin/bash
# Dependencies:
# bind-utils
# mysql-client
#### Config ################################
DBUSER="pdns"
DBPASS="LKgJHG55K7Jffs"
#### End of Config #########################

MYSQL="mysql -u $DBUSER -p$DBPASS --skip-column-names --silent -e"

check() {
#AUTH=`dig @$1 $2 | grep "status" | awk -F , '{print $2}' | awk -F ': ' '{print $2}'`
AUTH=`dig @$1 $2 | grep "flags" | awk -F : '{print $2}' | awk -F '; ' '{print $1}'|grep -ci 'aa'`
#if [ $AUTH = "REFUSED" ] || [ $AUTH = "NXDOMAIN" ]; then
if [ $AUTH = "0" ]; then
echo "$1 $2: Server not AUTH or SERVfail - removing zone..."
DOMAIN_ID=`$MYSQL "USE pdns; SELECT id FROM domains WHERE name='$2' AND type='SLAVE' AND master='$1' LIMIT 1;"`
$MYSQL "USE pdns; DELETE FROM records WHERE domain_id='$DOMAIN_ID';"
$MYSQL "USE pdns; DELETE FROM domains WHERE id='$DOMAIN_ID';"
fi
}

MASTERS=(`$MYSQL "USE pdns; SELECT DISTINCT ip FROM supermasters;"`)
for m in "${MASTERS[@]}"; do
	NAMES=(`$MYSQL "USE pdns; SELECT name FROM domains WHERE type = 'SLAVE' AND master = '${m}';"`)
for d in "${NAMES[@]}"; do
	check ${m} ${d}
done
done

Несуществующие домены удаляются, вся система остается синхронизированной, все улыбаются.

В этой схеме может быть любое число супермастеров (серверов с ISPmanager). В случае с backend-gmysql то же самое можно было бы сделать посредством mysql, но так правильнее, mysql никак не светится в сети и нет зависимости от pdns на мастере.

Еще немного о powerdns будет в заметке об IPv6.

ISPmanager vs Plesk

Выбор в пользу ISPmanager был обусловлен, прежде всего, наличием в хозяйстве BillManager, изделием той же мануфактуры. Ну, боле лучшая интеграция, вот это все. Но это не в первую очередь, изначально было желание избавиться от Plesk.

Я несколько лет прожил рядом с Plesk 10/11 и готов признать, что это зрелый, хорошо укомплектованный, продуманный и серьезный продукт. Я нечасто сталкивался с CPanel, чуть больше на данный момент вник в ISPmanager, так вот, по большинству направлени Plesk их затмевает. Но не по всем.

Для пользователя, для бизнесмена — да, отличная вещь этот Plesk. Симпатичный, многое умеет, обновляется, развивается, присутствует более-менее вменяемая поддержка. С другой стороны, Plesk диктует что и как вы должны использовать. Поддержка системных сервисов обусловлена лицензией. При установке панель сносит все, что ей не нравится и устанавливает то, что хочет. Она всюду запускает свои щупальца, управляет всем, контролирует все, чему обучена (и что покрыто лицензией). У вас сто серверов, для вас важно единообразие, контроль, быстрое «шаблонное» обучение персонала, оперативное развертывание новых серверов? Plesk вам понравится.

ISPmanager другой. Он проще и понятнее, он оставляет больше свободы выбора, его можно удалить и забыть, в конце концов, практически не повредив работоспособности системы. Это панель, которая больше (чем Plesk) пытается управлять тем, что есть, чем переделать все под себя. Учитывая перечень «возможностей» (это управляемые системой компоненты и сервисы), варианты каждой, настройки, включенные и отключенные кнопки и галочки, можно сказать, что в природе нет двух одинаковых серверов с ISPmanager.

Отдельно скажу про лицензию — она дешевле и тоже проще, без странной необходимости доплачивать за отдельные компоненты.

Изначально, как любитель нового, я остановился на версии ISPmanager 5 lite. Она объективно удобнее и так же объективно беднее схожей по цене версии ISPmanager 4 pro. Тут выяснилось, что версии 5 pro нет и неизвестно когда будет. Также стало понятно, что несмотря на статус товарного продукта, далеко не все приемлемо работает. Накопленные коллективным разумом знания по «четверке» неприменимы, каждый вопрос нужно адресовать поддержке, что тоже не гарантия быстрого разрешения проблемы.

Один пример — установил ISPmanager 5 lite, связал с Billmanager, завел клиента. В ISPmanager попал только клиент (пользователь), при этом домен не создался, www-домен не создался, почтовый домен не создался.

Короче, обменял лицензию 5 Lite на 4 Pro. Тоже не подарок, надо сказать. Несколько попыток установки «по инструкции» в полной или рекомендованной конфигурации прошли неудачно. Каждый раз все заканчивалось на этапе «Checking www …». Несколько раз восстанавливал «виртуалку» из девственно пустого образа и начинал заново. В итоге догадался установить минимальную конфигурацию, в которую затем по-очереди добавлял компоненты (возможности), попутно вычитывая логи и устраняя затыки. Это несложно, но муторно — 6 часов ушло.

Перенос имеющихся клиентов, их доменов, сайтов, почты занял куда больше. Встроенным в ISPmanager импортом из архивов, сделанных в Plesk, я пользоваться не стал по нескольким причинам. Первое, этот импорт глючит, как многое в ISPmanager, разнообразно и непредсказуемо, тем более, что официально он не поддерживает Plesk 11. Второе и самое важное — импорт через ISPmanager не дает в итоге никакой связи с биллингом, туда этих клиентов придется привязывать руками.

В итоге процесс выглядел так:

  • Установка ISPmanager, создание шаблонов (будущих тарифов)
  • Привязка Billmanager-ISPmanager, создание новых тарифов, полностью копирующих старые, до окончания переноса с нулевой ценой.
  • Переименование пользователя и домена в старой услуге типа «хостинг» у клиента. Создать вторую услугу с одинаковыми именеи и доменом не получится, к сожалению, что очень неудобно.
  • Заведение новой услуги хостинга на новом сервере с новым тарифом и прежними данными.
  • Ручной перенос баз данных, настроек доменов, почтовых ящиков, сайтов на новый сервер.
  • Проверка работоспособности сайтов на новом месте, изменение записей в DNS на прежнем месте.
  • Повторить по числу клиентов.

В ходе переноса пришлось понизить версию PHP с 5.4 до 5.3, поскольку старинные сайты иначе пришлось бы существенно править. На прежнем месте была 5.2, так что выбран некий компромиссный вариант. Инструкция нашлась здесь, почти пошаговая, разве что версия другая и пакетов пришлось устанавливать больше.

Коротко

$ apt-get remove --purge `dpkg -l | grep php | grep -w 5.4 | awk '{print $2}' | xargs`
 
$ VERSION="5.3.3-7+squeeze17"
$ apt-get install php5=$VERSION php5-cli=$VERSION php5-common=$VERSION libapache2-mod-php5=$VERSION  php5-cgi=$VERSION php5-gd=$VERSION 
$ echo php5 hold| dpkg --set-selections
$ echo php5-cli hold| dpkg --set-selections
$ echo php5-common hold| dpkg --set-selections

Для переноса баз данных сделал небольшой скрипт mysqldump/mysql, которому нужно было только дать название базы. Ее, правда, для начала приходилось руками заводить в панели.

Почту переносил вручную, благо, мало кто ей пользуется. Все логины и пароли Plesk хранит в открытом виде, то есть их запросто можно узнать. Дальше простыня как раз на эту тему. Собрано из разных источников и наспех адатировано, так что все это неидеально, но вполне работает.

*** BASIC QUERY PLESK ***

mysql -uadmin -p` cat /etc/psa/.psa.shadow` -Dpsa -e"XXX"


*** DATABASES AND DATABASE USERS ***

SELECT domains.name AS domain_name,
data_bases.name AS database_name, db_users.login, accounts.password
FROM data_bases, db_users, domains, accounts
WHERE data_bases.dom_id = domains.id
AND db_users.db_id = data_bases.id
AND db_users.account_id = accounts.id
ORDER BY domain_name;


*** MAIL USERS AND REDIRECTS AND ALIASES ***

select mail.id, mail_name,name,password, address, GROUP_CONCAT( mail_aliases.alias SEPARATOR ',') as aliases
from mail 
left join domains on mail.dom_id = domains.id
left join accounts on mail.account_id = accounts.id
left join mail_redir on mail.id = mail_redir.mn_id
left join mail_aliases on mail.id = mail_aliases.mn_id
group by mail.id
order by name


*** FTP USERS ***

select REPLACE(sys_users.home,'/var/www/vhosts/','') AS domain,
sys_users.login,accounts.password, smb_users.contactname, smb_users.email, smb_users.companyname, smb_users.phone, smb_users.address
 FROM sys_users
left join accounts on sys_users.account_id=accounts.id
left join smb_users on smb_users.login = sys_users.login
order by sys_users.home ASC;

*** DOMAINS AND ALIASES***

select clients.login, domains.name, GROUP_CONCAT( DISTINCT CONCAT(domainaliases.name, ' (', domainaliases.mail,')' ) SEPARATOR ', ') as aliases,
GROUP_CONCAT( DISTINCT domainaliases.displayname SEPARATOR ', ') as aliasesdsp
,
GROUP_CONCAT( CONCAT(dns_recs.type, ' ', dns_recs.val ) SEPARATOR '\n') as dns

from domains 
left join clients on clients.id = domains.cl_id
left join dns_recs on dns_recs.dns_zone_id = domains.dns_zone_id
left join sys_users on sys_users.login = clients.login
left join domainaliases on domains.id = domainaliases.dom_id
group by domains.id
order by clients.login

С такими средствами малой механизации на перенос одного клиента уходило примерно 15-20 минут. В некоторых случаях приходилось донастраивать по месту CMS, в основном из-за использования абсолютных путей (/var/www//data/www/domain.ru вместо /var/www/vhosts/domain.ru/httpdocs) и /tmp папки, которая в ISPmanager не входит в open_basedir, в отличие от Plesk.

Отличная дурная работа, которая особо не нагружает мозг, но при этом создает полное ощущение всепоглощающей занятости.

Последние 5 копеек про ISPmanager. О поддержке. Точнее, о форуме поддержки. Много раз замечено, что русские форумы обладают особым шармом. Пренебрежение, снисходительность, немного грубости и хамства — все это есть, все такое родное и знакомое. Есть и исключения, редкие, от того неожиданные и особо приятные.

А, нет, еще 2 копейки. ISPmanager — продукт, созданный программистами. Он структурирован по логике тех, кто понимает, что за каждой кнопкой стоит вон тот компонент или вот этот сервис. Терминология подогнана под существующую структуру. Объясните среднему клиенту про домены, www-домены и почтовые домены, про их взаимосвязь и отличия. Или про «Авто поддомены в отдельной директории». А он должен это знать, по идее. И ему предлагают справку, помощь, видео-уроки. Много вы знаете людей, готовых инвестировать свое время в изучение хотя бы основ панели управления хостингом? Да и вообще способных это дело осилить. Гораздо больше тех, кто начинает чувствовать себя умственно неполноценным, раздражается, злится. Ну или спешит обратиться в поддержку, что серьезно снижает полезность панели управления для хостера.