Борьба с 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.

Починка named.conf в Plesk 11

Это на память и на будущее, не последний раз потребовалось, вероятно.

После установки (наконец-то) всех доступных обновлений на сервер с панелью Plesk 11 случилось неприятность с сервисом named — он сперва отказывался запускаться, а затем потерял половину данных о доменах.

На этот случай у Parallels есть статья в базе знаний и вложенный shell script для починки named.conf
Одна проблема, они забыли о синонимах доменов, которые в табличке domains не хранятся. Поэтому в нашем случае скрипт восстановил не более половины имевшихся зон.

Я посмотрел структуру базы данных psa, нашел синонимы в табличке domainaliases и подправил скрипт. (скачать dns_rebuild.sh.gz).

#!/bin/sh

ADMIN_PASS=`cat /etc/psa/.psa.shadow`
MYSQL_BIN_D=`grep MYSQL_BIN_D /etc/psa/psa.conf | awk '{print $2}'`
PRODUCT_ROOT_D=`grep PRODUCT_ROOT_D /etc/psa/psa.conf | awk '{print $2}'`
mysql="${MYSQL_BIN_D}/mysql -N -uadmin -p${ADMIN_PASS} psa"

query="select name from domains;"
domains=`echo $query | $mysql `

echo "Updating domains"
for i in ${domains}; do
    echo "$i"
    $PRODUCT_ROOT_D/admin/sbin/dnsmng --update $i
done 

query="select name from domainaliases;"
domains=`echo $query | $mysql `

echo "Updating domain aliases"
for i in ${domains}; do
    echo "$i"
    $PRODUCT_ROOT_D/admin/sbin/dnsmng --update $i
done 

Клиенты, подписки, домены в Plesk 10

Есть клиент. У него была подписка с доменом aaa77.ru. Затем в подписку был добавлен еще один домен — bbb77.ru. Через какое-то время aaa77.ru стал не нужен. Задача — удалить из подписки первый домен, оставив второй. Не меняя логин (панель, ftp) клиента.

Первый (aaa77.ru) — это «главный домен» подписки и удалить его нельзя. Но можно переименовать, заодно сменив корневой каталог сайта. Проблема — сменить имя домена на bbb77.ru нельзя, поскольку он уже существует.

Процедура:

1. Делаем резервную копию корневой папки второго домена (bbb77.ru). Это необходимо сделать, иначе на втором пункте все файлы будут удалены. Альтернативно, можно создать новую корневую папку (пустую) и сменить ее для домена bbb77.ru через GUI (Websites & domains → bbb77.ru → Document root).

2. Удаляем домен bbb77.ru. Ахтунг! Папка, на которую указывает Document root тоже будет удалена! Это очень опасная практика, я бы сделал опцию оставить/удалить данные. В HSphere, которую Parallels купили, именно так и было, если память не изменяет.

3. Переименовываем aaa77.ru в bbb77.ru и изменяем для него корневую папку, это там же в «Сайтах и доменах».

Побочные эффекты:

1. Переименуется папка /var/www/vhosts/aaa77.ru/ (корень подписки) в bbb77.ru. Это логично, но может привести к проблемам в настройках CMS и прочих веб-приложений, если где-то используется абсолютный путь.

2. Корневой каталог первого сайта останется, его надо удалять вручную. Загадка — удалит или не удалит данные какая-то операция в Plesk? Бездна логики.

3. Пропадут почтовые ящики на домене bbb77.ru, их надо будет создавать заново. Можно сделать это заранее (я не удосужился).

4. Последнее, но важное — Plesk похерил .htaccess из корневой папки bbb77.ru. Скорее всего — в процессе переименования (см. п.1).

UPDATE Еще не все — опять связано с п.1. Папку Плеск переименовал, а вот open_basedir в php.ini (которые теперь у каждого клиента отдельные) так и остался прежний путь! Симптомы — не работает PHP. Решение — поправить ~/etc/php.ini руками, либо через настройки PHP в GUI надо сменить значение для open_basedir с Default на единственную опцию в выпадушке. Потом можно менять назад, главное чтобы php.ini обновился.