Настройка PTR записи на DNS сервере

Понадобилось как-то настроить обратную DNS зону (Reverse DNS) для почтового сервера, так как некоторые сервера не хотели принимать от него почту.

Допустим наш домен mail.example.com находящийся на IP адресе 192.168.1.100, а 192.168.1.1 — сервер интернет провайдера.

Проверить из Windows можно командами (где 192.168.1.100 например адрес нашего почтового сервера, а 192.168.1.1 DNS на который шлем запрос):

nslookup mail.example.com
nslookup 192.168.1.100
nslookup 192.168.1.100 192.168.1.1

В ответ первой команды будет 192.168.1.100, а в ответ второй ничего (должно mail.example.com), так как в DNS не настроена PTR запись.

Из Linux проверять можно так:

dig -x 192.168.1.100

У регистратора доменных имен в DNS добавим дочерний NS-сервер интернет провайдера ns1.example.com 192.168.1.1.

На сервере провайдера (на тесте использую Bind9 на Ubuntu Server) откроем конфигурационный файл DNS сервера например в редакторе nano (CTRL+X для выхода, y/x и Enter для сохранения или отмены изменений):

sudo nano /etc/bind/named.conf

И добавим следующие строки:

zone "1.168.192.in-addr.arpa" {
type master;
file "/etc/bind/1.168.192.in-addr.arpa";
};

Первая строка указывает какой зоной будем управлять, вторая тип — главный (этот DNS и будет ею управлять), третья — в каком файле будет прописана конфигурация для этой зоны.

Откроем новый файл для настроек зоны:

sudo nano /etc/bind/1.168.192.in-addr.arpa

И добавим в него:

$TTL 3600
@          IN SOA ns1.example.com. admin.example.com. (
              2016112301       ; Serial
              21600             ; refresh
              3600              ; retry
              3600000           ; expire
              86400 )           ; minimum

        IN  NS ns1.hosting.com.
        IN  NS ns2.hosting.com.

$ORIGIN 1.168.192.in-addr.arpa.
100      IN PTR  mail.example.com.

admin.example.com — контактный адрес человека отвечающего за зону, символ @ не указывается.
Serial это серийный номер версии файла зоны, должен изменяться в большую сторону при каждом изменении, обычно пишется в виде год месяц число номер изменения, по нему другие DNS определяют что нужно обновить у себя информацию.
Refresh — интервал времени в секундах, через который вторичный сервер будет проверять необходимость обновления информации.
Retry — интервал времени в секундах, через который вторичный сервер будет повторять обращения при неудаче.
Expire — интервал времени в секундах, через который вторичный сервер будет считать имеющуюся у него информацию устаревшей.
Minimum — интервал времени жизни информации на кэширующих серверах.
ns1.hosting.com и ns2.hosting.com это DNS домена.
Цифра 100 в последней строке означает окончание IP адреса 192.168.1, аналогично можно указывать записи для других доменов, например 101 IN PTR … для 192.168.1.101 и т.д.

Перезапустим DNS сервер чтобы применить изменения.
Bind9 можно командой:

sudo /etc/init.d/bind9 restart

Смотрите также:
Настройка Reverse DNS (PTR) в Hetzner

Настройка логов Bind9

По умолчанию логи Bind9 записываются в системный журнал /var/log/syslog и чтобы отделить их, выполним действия которые я укажу ниже.

Читать далее «Настройка логов Bind9»

Настройка Cisco Catalyst 6509-E

На примере настрою Cisco Catalyst 6509-E с прошивкой 12.2(33)SXJ7.
И так, подключимся к консольному порту, стандартная скорость 9600 bps, 8N1.

Пример команд просмотра информации о прошивке и железе:

Читать далее «Настройка Cisco Catalyst 6509-E»

Обновление прошивки iLO 3 на HP серверах

Настраивал однажды iLO на серверах и заметил, что при открытии в браузере интерфейса возникает ошибка SSL, и web-интерфейс iLO не открывается.

Смотрите как временно решить эту ошибку в моей статье — Решение ошибки iLO «HTTP SSL_ERROR_BAD_MAC_ALERT».

Для примера буду использовать HP ProLiant DL380 G7 со старой прошивкой iLO 3 1.10 (Jul 26 2010)

Читать далее «Обновление прошивки iLO 3 на HP серверах»

Решение ошибки iLO «HTTP SSL_ERROR_BAD_MAC_ALERT»

Заметил как-то при открытии в браузере веб-интерфейса iLO следующую ошибку:

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

Читать далее «Решение ошибки iLO «HTTP SSL_ERROR_BAD_MAC_ALERT»»

Решение проблемы при обновлении iLO 3 «98% Receiving Image…»

Обновлял как-то iLO 3 с версии 1.10 на 1.88, на сервере HP ProLiant DL380 G7 и процесс остановился на «98% Receiving Image…»

Так вот, если версия прошивки iLO 3 ниже 1.28, то необходимо выполнить сначала обновление на версию 1.28, а потом уже выше.

Вот и все решение проблемы.

Резервное копирование конфигурации Cisco Catalyst 6500

Для теста набросал скрипт автоматического резервного копирования конфигурации Cisco Catalyst 6509-E.

Собственно сам скрипт:

#!/bin/bash
# Backup CISCO config
(
sleep 5
echo "user"
sleep 4
echo "password"
sleep 4
echo "copy running-config tftp:"
sleep 2
echo "192.168.1.4"
sleep 2
echo "cisco.cfg"
sleep 6

echo "exit"
) | telnet 192.168.1.5
mv /srv/tftp/cisco.cfg /backups/devices/cisco/`date +%Y-%m-%d`_cisco.cfg

find /backups/devices/cisco/ -type f -mtime +30 -exec rm {} \;

Содержимое скрипта добавим например в файл backup_cisco.sh и добавим его в cron, добавив указанную ниже строку в файл /etc/crontab:

0 2 * * * root /backups/scripts/backup_cisco.sh > /dev/null 2>&1

Файл можно открыть например в текстовом редакторе nano (Ctrl+X для выхода, y/n для сохранения или отмены изменений):

sudo nano /etc/crontab

Скрипт выполняет подключение по telnet к 192.168.1.5 и копирует конфигурацию на tftp сервер 192.168.1.4, потом файл перемещается в удобную директорию для хранения.
Последняя строчка в скрипте удаляет файлы старее 30 дней.
Как запустить tftp сервер смотрите в моих статьях: Установка и настройка TFTP сервера в Ubuntu или Запуск TFTP сервера на Windows.
Смотрите также: Использование и настройка CRON.

Сброс пароля iLO через hponcfg на HP серверах

На тесте изменю пароль iLO к стандартному пользователю Administrator на сервере HP ProLiant DL380 G7, пароль у него генерируется случайным образом от производителя и устанавливается в BIOS, его также можно увидеть на ленточке выдвигающейся и прикрепленной к серверу.

По этому чтобы не перезагружать сервер для изменения пароля, создадим файл например с именем reset_password.xml и добавим в него содержимое:

<RIBCL VERSION="2.0">
<LOGIN USER_LOGIN="Administrator" PASSWORD="password">
<USER_INFO MODE="write">
<MOD_USER USER_LOGIN="Administrator">
<PASSWORD value="ПАРОЛЬ"/>
</MOD_USER>
</USER_INFO>
</LOGIN>
</RIBCL>

Где Administrator, это имя пользователя, password — не трогаем, тут может быть любой текст, а только укажем желаемый пароль пользователю вместо ПАРОЛЬ.

Экспортируем файл:

sudo hponcfg -f reset_password.xml

В случае ошибки можно вывести отчет в файл log.txt командой:

sudo hponcfg -f reset_password.xml -l log.txt

Смотрите также:
Настройка iLO через hponcfg

Решение ошибки Minicom «Устройство /dev/ttyS0 заблокировано»

Иногда если теряется связь с Linux из которой выполнено подключение через Minicom, то при следующем запуске Minicom можно было увидеть ошибку:

Устройство /dev/ttyS0 заблокировано.

Имя /dev/ttyS0 может быть другим, в зависимости под каким у вас COM порт.
Чтобы не было такой ошибки, необходимо правильно завершать работу с Minicom клавишами CTRL-A потом клавиша Q.

Решить проблему можно убив процесс от root пользователя командой:

killall -9 minicom

В Ubuntu можно командой:

sudo killall -9 minicom

Либо можно просто удалить файл «LCK..ttyS0» в директории /var/lock/.

После этого ошибка не будет отображаться.