Как переименовать сетевой интерфейс в CentOS 7

Во FreeBSD, когда настраиваешь сетевые параметры, есть очень удобный механизм переименовывания названий сетевых интерфейсов. Можно, к примеру, интерфейс em0 назвать lan0, а xl0 - wan0. Во-первых, это придаёт настройкам всевозможных конфигурационных файлов осмысленности: сразу понятно, какой интерфейс за что отвечает, а во-вторых, в различных конфигурационных файлах можно использовать эти псевдонимы и, в случае замены сетевой карты, нужно всего-лишь поменять одну строчку в rc.conf. Причём, делается такое переименование элементарно - одной строкой в конфиге rc.conf:

ifconfig_em0_name="lan0"
ifconfig_xl0_name="wan0"

И всё! Дальше везде используем только имена lan0 и wan0.


Когда я начал настраивать очередной Linux сервер, был сильно удивлён, что этот, вроде бы, тривиальный механизм в линуксе устроен, мягко говоря, несколько сложнее. Казалось бы, чего проще - добавь в конфигурационный файл сетевого интерфейса параметр NAME и интерфейс сам переименуется. Но нет. Там нужно задействовать какие-то сложные и не до конца понятные механизмы udev. 99% советов сводится к необходимости добавить в конфигурационный файл /etc/udev/rules.d/70-persistent-ipoib.rules строк типа:

SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="90:2b:34:87:d1:7d", ATTR{dev_id}=="0x0", ATTR{type}=="1", NAME="lan0"

Тут с ходу понятно только, что сетевому интерфейсу с соответствующим mac-адресом присваивается имя lan0. Объяснения, зачем нужны остальные параметры, и что они означают, найти весьма непросто.
Но и это ещё не всё. После описанных действий нужно переименовать в каталоге /etc/sysconfig/network-scripts/ файл с именем ifcfg-старое_имя в файл ifcfg-новое_имя и изменить в самом файле все названия интерфейсов со старого на новый. (Написанное выше справедливо для CentOS, в Ubuntu немного по-другому).

В последних дистрибутивах (RHEL7, CentOS 7, Ubuntu 16.04) всё ещё больше запуталось. Там отказались от традиционного для линуксов именования сетевых интерфейсов, типа eth0, eth1 и т.д., и внедрили именование более сложное, основанное на аппаратном расположении интерфейса. Как это теперь работает, можно почитать, к примеру, здесь:
http://val-khmyrov.blogspot.ru/2015/11/blog-post_22.html
Всё понятно? Мне не совсем.
Я же, когда начал копать в сторону решения проблемы наткнулся на следующий мануал:
https://www.freedesktop.org/software/systemd/man/systemd.link.html
Т.е., по идее, с помощью этого механизма можно легко переименовать любой сетевой инерфейс, используя штатное средство systemd.link. Для этого всего-лишь нужно для каждого интерфейса в каталоге /etc/systemd/network/ создать файл, например с именем 10-lan0.link примерно следующего содержания:

[Match]
MACAddress=00:a0:de:63:7a:e6
[Link]
Name=lan0

после чего интерфейс с соответствующим mac-адресом, по идее, должен переименоваться. Но не тут то было! Сделал, как написано - не работает. Начал гуглить и обнаружил, что про это почти нигде ничего не сказано, кроме вышеприведённого мануала.
Хотел уже плюнуть на всё и воспользоваться методом редактирования 70-persistent-ipoib.rules (благо, он в CentOS 7 тоже работает), но случайно попал на основополагающий сайт документации RHEL. Там, вот на этой странице:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Networking_Guide/sec-Disabling_Consistent_Network_Device_Naming.html
увидел совет, как отключить существующую схему именования. А именно нужно сделать симлинк:

ln -s /dev/null /etc/udev/rules.d/80-net-name-slot.rules

Таким образом отключается именование интерфейсов по слотам и включается именование по линкам.
И вот только после этого начинает работать механизм systemd.link. Победа!

В итоге имеем следующее.
Чтобы переименовать, к примеру, сетевой интерфейс ens160 в lan0 в CentOS 7, нужно сначала создать символическую ссылку:

ln -s /dev/null /etc/udev/rules.d/80-net-name-slot.rules

В каталоге /etc/systemd/network/ создаём файл 10-lan0.link следующего содержания:

[Match]
MACAddress=00:a0:de:63:7a:e6
[Link]
Name=lan0

указав реальный mac-адрес интерфейса, который пытаемся переименовать.

После чего, в каталоге /etc/sysconfig/network-scripts/ переименовываем файл ifcfg-ens160 в файл ifcfg-lan0 и в самом файле изменяем параметры NAME и DEVICE на новые. Перегружаемся, наслаждаемся новым именем.

И всё это вместо одной строчки:
ifconfig_ens16_name="lan0"
во FreeBSD.
Архитекторы Linux тут явно перемудрили.

ComminiGate Pro: перенос почты с сервера MS Exchange с помощью MoveIMAPMail

В состав сервера CommuniGate Pro входит утилита для переноса почты со старого сервера на новый посредством IMAP - MoveIMAPMail. У неё есть куча параметров, которые описаны в мануале. Если сервер CGP установлен на Linux, то для удобства переноса большого количества ящиков, проще написать небольшой скрипт:

#!/bin/sh

/opt/CommuniGate/Migration/MoveIMAPMail \
--verbose \
--notimeout \
--noACL \
--fixLongLines 256 \
--renameMailboxList ./rename.txt \
192.168.1.252 $1 "$2" 127.0.0.1 $1 "$3"

и передавать ему в качестве параметров имя пользователя и два пароля - старый и новый.

интерес тут представляет параметр:

--renameMailboxList ./rename.txt

он указывает утилите автоматически переименовывать папки при переносе со старого сервера на новый и брать шаблоны переименований из файла rename.txt. Это удобно, например, чтобы сообщения из папки "Отправленные" на Exchange сразу попали в папку "Sent Items" на CGP и т.п. Проблема тут заключается в том, что MoveIMAPMail не понимает в качестве параметров русские имена папок. Вернее, она их понимает, но в весьма специфическом формате IMAP-UTF-7. Например, папка "Удалённые" в этом формате называется так: "&BCMENAQwBDsENQQ9BD0ESwQ1-".
Ввести русское имя папки в таком формате от руки не представляется возможным. Я написал об этом разработчикам CGP, но они мне ответили, что ничего делать не будут, ибо по стандарту, именно в таком виде все папки, названные не латиницей, хранятся на сервере. Что характерно, в мануале на CGP про это ни слова не сказано, и я убил полдня, пытаясь понять, почему у меня русские имена папок не переименовываются. 

В общем, пришлось заниматься извращениями. Написал ещё один скрипт:

#!/bin/sh

filename="rename.txt"

echo -e "`echo -n 'Отправленные' | /usr/bin/uconv -f utf-8 -t IMAP-mailbox-name`\tSent Items" > $filename

echo -e "`echo -n 'Удаленные' | /usr/bin/uconv -f utf-8 -t IMAP-mailbox-name`\tTrash" >> $filename

echo -e "Deleted Items\tTrash" >> $filename

echo -e "`echo -n 'Черновики' | /usr/bin/uconv -f utf-8 -t IMAP-mailbox-name`\tDrafts" >> $filename

echo -e "`echo -n 'Нежелательная почта' | /usr/bin/uconv -f utf-8 -t IMAP-mailbox-name`\tJunk" >> $filename

echo -e "Junk E-mail\tJunk" >> $filename

echo -e "Notes\tNotes_old" >> $filename

echo -e "Tasks\tTasks_old" >> $filename

Для его функционирования нужно установить из репозитория консольную утилиту uconv, которая умеет преобразовывать тексты из кучи разных форматов и наоборот. В ней этот хитрый формат называется IMAP-mailbox-name.

Результатом работы этого скрипта будет файл rename.txt в нужном формате, который можно передать в качестве параметра MoveIMAPMail.

Ещё один полезный параметр --filter after "31-Dec-2011". Дату в нём нужно писать именно в таком виде - месяц тремя буквами, иначе никаких ошибок не увидите, но работать будет неправильно. С его помощью можно скопировать со старого сервера не всю почту, а только после определённой даты. Это полезно, если квоты на размер ящика на новом сервере меньше, чем на старом.

Установка и первоначальная настройка сервера CentOS 6 и 7

CentOS 6

CentOS 6, если её ставить в минимальной конфигурации, ставится уж очень аскетично. В базовую систему даже не входит пакет man, не говоря уже о многих других полезных утилитах. Поэтому решил написать небольшую шпаргалку, что нужно поставить, чтобы получить работоспособный и минимально-настроенный сервер.

Итак, начинаем установку (всё написанное делалось на CentOS 6.5 x64):

выбираем английский язык

когда просят ввести имя хоста, вводим и нажимаем кнопку "Configure Network"


в настройках адаптера включаем "Connect automatically" и настраиваем параметры IPv4

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

выбираем Minimal install

после окончания установки и первой перезагрузки:
yum update
reboot

ставим минимально-необходимый на сервере набор пакетов:
yum -y install man mc telnet bind-utils bzip2 unzip zip wget psmisc

настраиваем синхронизацию времени:
yum -y install ntp
chkconfig --level 345 ntpd on
service ntpd start

выключаем для начала брендмауэр, чтобы он не мешал настройке всего прочего; потом его можно при  необходимости настроить и включить
chkconfig ip6tables off
chkconfig iptables off
service iptables stop
service ip6tables stop
можно ещё выключить selinux, написав в файле /etc/selinux/config
SELINUX=disabled
он тоже может помешать настройке сервера

Добавляем дополнительные репозитории EPEL и rpmforge:
yum -y install epel-release
rpm --import http://apt.sw.be/RPM-GPG-KEY.dag.txt
yum -y install http://pkgs.repoforge.org/rpmforge-release/rpmforge-release-0.5.3-1.el7.rf.x86_64.rpm

yum updateставим оттуда ещё несколько полезных пакетов
yum install bash-completion htop atop iftop

В принципе, это всё,  но можно ещё для большей секурности добавить пользователя с правами администратора и отключить возможность root-логина через ssh:
useradd administrator
usermod -a -G wheel administrator
или сразу одной командой:
useradd -G wheel administrator

passwd administrator

в файле /etc/sudoers убираем комментарий в строке:
# %wheel        ALL=(ALL)       ALL

в файле /etc/ssh/sshd_config убираем комментарий в строке:
#PermitRootLogin yes
и меняем yes на no

Всё. Теперь по ssh можно зайти только пользователем administrator и админить сервер уже через sudo.
Дальше ставятся все остальные необходимые на сервере сервисы и пакеты, в зависимости от назначения этого сервера.

CentOS 7

В CentOS 7 много чего поменялось, но в плане первоначальной настройки сервера изменения не большие.
Инсталлятор вполне интуитивно-понятный. Главное, как и с 6 не забыть сразу настроить сеть. Хотя, в 7 штатно появилась утилита nmtui, которая позволяет наглядно из консоли настроить все необходимые сетевые параметры, не прибегая к ручной правке конфигурационных файлов.

После инсталляции почти всё, как и с шестёркой:

yum -y update
yum -y install mc telnet bind-utils bzip2 unzip zip wget psmisc

В 7 исчезла команда ifconfig. Вместо неё появилась команда ip. Для элементарного просмотра сетевых настроек нужно ввести ip a. Но если хочется старых команд, то нужно поставить ещё один пакет:
yum -y install net-tools.x86_64

Далее настраиваем синхронизацию времени. Тут есть два варианта:

1. Воспользоваться уже имеющимся в системе новым сервисом. (В Centos 7 вместо старого  ntpd предустановлен и активирован новый сервис chrony).
Проверяем, работает ли chrony:
systemctl status chronyd
если работает, то разрешаем синхронизацию времени:
timedatectl set-ntp yes
проверяем состояние:
chronyc sources

2. Если chrony не работает или хочется установить вместо него ntpd:

yum -y install ntp
systemctl start ntpd
systemctl enable ntpd
отключаем chrony:
systemctl stop chronyd
systemctl disable chronyd

Добавление репозиториев:
yum -y install epel-release
rpm --import http://apt.sw.be/RPM-GPG-KEY.dag.txt
yum -y install http://pkgs.repoforge.org/rpmforge-release/rpmforge-release-0.5.3-1.el7.rf.x86_64.rpm

ставим оттуда полезные утилиты:
yum -y update
yum -y install bash-completion htop atop iftop


Далее можно сделать то же, что и в версии 6 касательно создания пользователя администратор и отключения логина root через ssh.

Также для начала отключаем selinux, написав в файле /etc/selinux/config
SELINUX=disabled

и выключаем firewall.
В CentOS 7 вместо привычных iptables появилась надстройка над ними под названием firewalld. Отключается он так:
systemctl stop firewalld
systemctl disable firewalld
Как его настраивать - отдельная тема. Почитать об этом можно, например, тут:
http://bozza.ru/art-259.html

Если нужно вернуть iptables, то делается это так:
yum -y install iptables-services
systemctl enable iptables

Ну и последнее. Можно ещё отключить в системе ipv6, ибо оно пока непонятно зачем нужно в большинстве случаев.
Во-первых, частично это можно было сделать при инсталляции, когда настраивались сетевые параметры, отключив автоматическую настройку ipv6.
Если этого сделано не было, то уже после установки системы делается это так:
Сначала смотрим, какие службы используют ipv6:
netstat -tulnp
Все строки с названием протокола и 6 в конце или ::: это как раз оно. Как правило, на только что установленном сервере этот протокол используют sshd, ntpd и, возможно, postfix.

Для sshd в /etc/ssh/sshd_config находим строки:
#AddressFamily any
#ListenAddress 0.0.0.0
и меняем их на:
AddressFamily inet
ListenAddress 0.0.0.0

Для ntpd в /etc/ntp.conf добавляем в конце строку:
interface ignore ipv6

И отключаем ipv6 в самой CentOS. Открываем файл /etc/sysctl.conf и добавляем туда строки:
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1

и в файле /etc/sysconfig/network, добавляем:
NETWORKING_IPV6=no
IPV6INIT=no

редактируем файл /etc/default/grub
находим строку GRUB_CMDLINE_LINUX и добавляем в начало ipv6.disable=1, чтобы это выглядело примерно так:
GRUB_CMDLINE_LINUX="ipv6.disable=1 rd.lvm.lv=rootvg/usrlv...
создаём новую конфигурацию grub командой:
grub2-mkconfig -o /boot/grub2/grub.cfg

Для postfix правим файл /etc/postfix/main.cf
Делаем замену
#inet_interfaces = localhost
#inet_protocol = all
на
inet_interfaces = 127.0.0.1
inet_protocol = ipv4


Можно перегружаться и проверить, что ipv6 успешно выключен:
netstat -tulnp
никаких упоминаний об ipv6 там быть не должно.

ComminiGate Pro: установка, настройка, миграция

Первое, что бросается в глаза, когда начинаешь читать документацию по CommuniGate Pro (CGP), это то, что разработчики, кажется, предусмотрели почти всё. Настолько много там всяких разных гибких настроек и вариантов работы во всех компонентах сервера. Ложкой дёгтя в этой цистерне мёда можно считать разве что не очень современный и немного запутанный интерфейс администратора. Некоторые вещи там находятся совсем не там, где предполагаешь сначала. Возможно, это только с непривычки, пока не до конца понял логику системы. И, справедливости ради, нужно заметить, что у некоторых систем и такого интерфейса нет.
Но это так, лирическое отступление. Речь в этой статье пойдёт об установке, первоначальной настройке CGP и миграции со старого почтового сервера.

Для начала о выборе серверной ОС.
CGP, как я уже писал ранее, выпускается под кучу разных ОС, начиная от Windows и Linux, и кончая AIX, HP/UX и IBM OS/2. Можно было поставить его на Windows Server, только непонятно зачем, тем более, что от ОС для функционирования CGP мало что требуется, кроме надёжной и быстрой работы, поэтому выбор пал на Linux, как наиболее простую в эксплуатации и доступную систему. Разработчики посоветовали мне 64 битную версию любого RedHat-совместимого дистрибутива. Я взял последнюю на тот момент версию CentOS - 6.4.

Собственно, процесс установки и первоначальной настройки CGP подробно описан в руководстве и является настолько тривиальным, что рассказывать про него нет никакого смысла. Просто скачал дистрибутив под нужную платформу, запустил инсталляцию и через пару минут сервер уже работает. Нюансы первоначальной настройки зависят от того, будет у вас сервер находиться напрямую в интернете или в локальной сети за брандмауэром, но там тоже всё предельно просто, нужно только предварительно прочитать соответствующие разделы документации.
Кстати, чтобы попробовать в работе CGP перед покупкой тоже ничего особого не нужно. Берёте на сайте бесплатную версию на 5 пользователей, ставите её прямо на свою рабочую станцию и сразу начинаете работать с почтой, IM и телефонией. Единственное, что обязательно нужно серверу CGP для работы - это доменное имя, но для теста вполне сойдёт что-нибудь типа cgp.company.ru в локальной сети. Также в этом случае, чтобы почта ходила из интернета и в интернет понадобится MX запись в DNS и соответствующие настройки брандмауэра на корпоративном шлюзе.

Теперь о миграции с MS Exchange.
В руководстве по CGP описано несколько способов миграции со старой почтовой системы, в том числе и с Exchange с помощью специальной утилиты, которая умеет экспортировать пользователей из одной системы в другую. У меня эта утилита почему-то не заработала. Но не очень то и хотелось.
По ряду причин, мы решили не переносить сразу всех пользователей со старого сервера на новый, а делать это постепенно, сначала оставив работать в сети оба сервера: CGP для уже смигрированных пользователей, а Exchange для тех, кто ждёт своего часа.
Собственно, такой способ тоже описан в руководстве по CGP. Суть его заключается в следующем:
- в настройках DNS и брандмауэра делаем так, чтобы почта приходила на CGP;
- на самом CGP включаем опцию перенаправления почты для неизвестных пользователей домена на старый почтовый сервер (в нашем случае это MS Exchange);
После этих действий все сообщения, приходящие снаружи уже смигрированным пользователям попадают в их ящики на новом сервере, а тем, кто ещё остался на старом, письма уходят на Exchange и тоже попадают куда нужно.
Вроде, всё просто, но у нас это осложнялось одним нюансом. Нам нужно было оставить Exchange со всеми ящиками в неприкосновенности ещё на какое-то время, и чтобы он был доступен пользователям в качестве архива. Это необходимо было потому, что у некоторых сотрудников размер почтовых ящиков на Exchange превышал все мыслимые пределы и не вписывался в квоты на новом сервере. Поэтому было принято решение, таким сотрудникам автоматически переносить на новый сервер почту только за последние два года, а всё остальное они должны забрать со старого сервера сами в пределах установленных квот.
Иными словами ситуация получилась такая:
- очередной пользователь переносится на новый сервер и начинает работать уже на нём;
- его старый почтовый ящик на Exchange продолжает существовать и быть ему доступным;
- при этом вся почта, как снаружи, из сети интернет, так и из локальной сети от всех пользователей должна поступать в его ящик на новом сервере.
Проблема тут заключается в том, что если на Exchange ящик пользователя не удалять, то когда ему будут писать сотрудники в локальной сети, ещё не переведённые на новый сервер, письмо попадёт в ящик на сервере Exchange и до CGP не дойдёт. (Т.к. Exchange будет справедливо считать, что это его пользователь).
Задача была решена следующим образом:
1. На CGP сделали у основного домена company.ru псевдоним cgp.company.ru.
2. В DNS создали запись cgp.company.ru, указывающую на сервер CGP.
3. После перевода пользователя user@company.ru на новый сервер, на сервере Exchange настраивается переадресация всей входящей почты для этого пользователя на адрес user@cgp.company.ru.
После этих действий, сотруднику, переведённому на новый сервер, вся почта начинает поступать куда нужно - на сервер CGP.

Ну и о переносе почты со старого сервера на новый.
Разработчики CGP предоставляют для этого специальную консольную утилиту MoveIMAPMail, которая умеет копировать письма указанного аккаунта с одного сервера IMAP на другой. Описание этой утилиты и параметров её запуска есть в руководстве по CGP. К сожалению, работает это не так гладко, как хотелось бы. Во-первых, утилита иногда "спотыкается" о некоторые папки IMAP и прекращает дальнейшую работу. Например, это происходит, если со старым сервером пользователь поработал посредством программы Mail из Mac OS X. Что уж она там такого неправильного создаёт, я не знаю, но эффект налицо. А во-вторых, утилита по умолчанию пытается скопировать все имеющиеся у пользователя папки IMAP (даже общие папки, не принадлежащие пользователю), что не всегда нужно, а параметры, задающие исключения у меня не заработали с русскими именами папок.
Но и тут выход был найден. У утилиты есть параметр, позволяющий копировать только "подписанные" папки IMAP. Поэтому берём любой почтовый клиент, умеющий работать с IMAP, подключаемся с его помощью к ящику пользователя на старом сервере и подписываемся там только на те папки, которые нужно перенести. После этого запускаем утилиту, и вся нужная почта копируется на новый сервер.

В заключении хотелось бы ещё раз обратить внимание на то, что документация, идущая с Communigate Pro, достаточно подробная, чтобы не прибегать ни к каким другим руководствам по установке и настройке, но всё же я дам одну ссылку на текст, из которого можно кое-что почерпнуть тем, кто впервые  устанавливает и настраивает сервер CGP:
http://wiki.rsu.edu.ru/wiki/Communigate_Pro
Кроме того, там есть описание, как "прикрутить" к серверу CGP бесплатные SpamAssassin и антивирус ClamAV.
Также кое-какие сведения можно получить из официального русскоязычного списка рассылки:
http://mx.ru/Lists/CGatePro/List.html
Ну и, если вы приобрели продукт легально, то не стоит пренебрегать поддержкой от производителя. Адрес электронной почты службы поддержки и ссылка на риал-тайм чат есть на русском сайте Communigate Pro в разделе поддержка. Отвечают там на вопросы быстро и достаточно подробно.

Ошибка "No wubildr" при установки Linux из под Windows 7

Описание проблемы:

Если Ubuntu Linux (Linux Mint) ставить непосредственно из под Windows 7 через wubi (mint4win), то при первой перезагрузке появляется сообщение "Try(hd 0,0):NTFS5: No wubildr". Секунд через 40 система продолжает грузиться.

Причина:

У Windows 7 или Vista есть скрытый раздел, зарезервированный системой. Загрузчик Linux его видит и пытается сначала найти wubildr там.

Решение:

Нужно, загрузившись Windows, зайти в "Управление компьютером" "Управление дисками" и там этому скрытому разделу присвоить какую-нибудь букву. После этого этот раздел станет доступен в проводнике. Необходимо из папки, куда установился Ubuntu Linux (Linux Mint) скопировать файл wubildr в корень этого раздела, зарезервированного системой. Проделав эти манипуляции, букву с раздела можно убирать, сделав его снова скрытым для проводника.