conversation with relay.friend.local[192.168.0.9] timed out while sending message body

Сервер на CentOS 6.8, почта – postfix. С обратной стороны то же самое – письма от друзей висят в очереди (там Ubuntu 15.10+тот же postfix). Как временный workaround, перенаправили почту друг на друга через Интернет, в обход туннеля – почта залетала. Стало быть, postfix работает нормально, проблема где-то в сетевых настройках.

Проблема воспроизвелась при копировании файла через scp. Причем что странно – проблема возникает только при отправке данных, если тянуть их с той стороны – все OK:

[root@relay.we.local ~] scp test.bin relay.friend.local:
FAIL
[root@relay.friend.local ~] scp relay.we.local:test.bin .
SUCCESS

Копаем дальше. У нас много разных серверов на линуксах в нескольких филиалах, где-то ситуация воспроизводится, где-то все работает без проблем. Внутри одного филиала проблема не проявляется, только через VPN-туннели, хотя каналы у нас неплохие – по 50-100 Мбит. Пытаемся найти отличия между проблемными серверами/каналами и теми, где все работает:

Первая версия – вроде как проблема там, где сетевая карта VMXNET3 (у нас все в виртуальной среде). Меняем на E1000 – не помогло (

Внезапно оказывается, что если отключен файрвол (стандартный линуксовый iptables) – то все работает! Однако, на старом почтовике iptables включен, но все хорошо. Понимаем, что соединение рубится файрволом, осталось разобраться почему.

Прослушка трафика с помощью wireshark показала, что при передаче файла идет куча ретрансмиссий, затем в какой-то момент iptables просто перестает пропускать пакеты. Видимо, перестает считать что пакеты принадлежат существующему соединению и соответственно блокирует. Почему оно так себя ведет – остается загадкой.

Ладно, зайдем с другой стороны. На старом почтовике, так же как и на новом, наш любимый CentOS 6.8, вроде бы системы идентичны. Но на старом проблемы нет, а на новом есть. И построчное сравнение конфигов показало наконец заветное отличие! Всего одна строчка в /etc/sysctl.conf:

net.ipv4.tcp_sack = 0

и проблема исчезает.

Казалось бы, опция tcp_sack наоборот должна улучшать производительность  сети на каналах с большим количеством повторных отправок пакетов. Но то ли сами iptables с этим делом плохо работают, то ли сетевое оборудование где-то по пути модифицирует трафик и этим вставляет палки в колеса iptables, но факт остается фактом: если у вас по непонятным причинам рвутся соединения при передаче больших файлов, попробуйте отключить tcp_sack.

Есть на Samba-wiki руководство Migrating a Samba NT4 domain to a Samba AD domain (classic upgrade), которое описывает похожую задачу, но для уже существующего домена на базе Samba 3. А у нас server role = standalone server, все пользователи продублированы в /etc/passwd, /etc/shadow и базе данных Samba, а группы хранятся в /etc/group. Чтобы прошел classic_upgrade, нужно подсунуть самбе что-то похожее на Samba NT4 PDC, что мы в результате и сделаем.

Итак, для начала возьмем новый сервер и сделаем из него будущий контроллер домена Samba 4 Active Directory путем установки дистрибутива Linux, в котором есть умеющая быть контроллером домена Samba. На момент написания статьи таким дистрибутивом оказался Ubuntu 15.10, его и используем в качестве примера. После установки и предварительной настройки останавливаем сервисы samba, если они запущены, и приступаем к переносу пользователей:

На старом сервере:

1) получим список пользователей Samba в формате username:uid

pdbedit -L | cut -d: -f1,2 > user_rid.txt

2) извлечем unix-пользователей из /etc/passwd и /etc/shadow:

sed s/:/:x:/ user_rid.txt | grep -f - /etc/passwd > passwd_delta.txt
sed 's/:.*/:/' user_rid.txt | grep -f - /etc/shadow > shadow_delta.txt

На будущем контроллере домена добавляем содержимое файлов passwd_delta.txt и shadow_delta.txt соответственно в /etc/passwd и /etc/shadow. Таким образом мы перенесли unix-пользователей со старого сервера на новый, теперь займемся группами:

1) сохраняем строки с нужными нам группами из /etc/group на старом сервере в текстовый файл group_delta.txt, и аналогично предыдущему шагу добавляем содержимое этого файла в /etc/group на новом;

2) чтобы classic_upgrade увидел группы и членство пользователей в них, Samba должна знать о соответствии unix-групп группам пользователей в своей базе. Если у нас standalone server, то скорее всего в базе Samba групп нет, так как используются только локальные unix-группы. Проверить это можно командой

net groupmap list

Если список групп пуст, то нужно его создать, запуская для каждой строки файла group_delta.txt команду net groupmap add:

for g in `cat group_delta.txt`; do name=`echo $g | cut -d: -f1`; id=`echo $g | cut -d: -f3`; net groupmap add rid=$id unixgroup=$name ntgroup=_$name; done

Команда выше  создает для каждой группы из файла group_delta.txt NT-группу с таким же именем и unix-GID, но с подчеркиванием в начале. Подчеркивание нужно для того, чтобы избежать возможного совпадения имени группы с именем пользователя (это недопустимо в Windows), ну и потом легче будет выделить импортированные группы в Active Directory.

Следующим шагом копируем на новый сервер бинарные базы данных Samba с нашего старого сервера. Для этого создадим на новом сервере папку dbdir и скопируем в нее со старого сервера файлы:

secrets.tdb
schannel_store.tdb
passdb.tdb
gencache_notrans.tdb
group_mapping.tdb
account_policy.tdb

Расположение файлов может быть разным в зависимости от инсталляции, но обычно их можно найти в папках /var/lib/samba и /var/lib/samba/private. Список файлов взят из вышеупомянутого HowTo, но к примеру в нашем случае нашлось только 5 файлов из 6 перечисленных, и на конечный результат это не повлияло.

Чтобы убедить самбу, что мы обновляемся с PDC, создадим  файл smb.conf.PDC следующего вида:

[global]
workgroup = <короткое имя вашего домена, например CONTOSO>
netbios name = <NetBIOS-имя вашего контроллера домена, например DC1>
security = user
domain master = yes
domain logons = yes
server role = classic primary domain controller
passdb backend = tdbsam
[netlogon]
comment = Network Logon Service
path = /home/samba/netlogon
guest ok = yes
read only = yes
[profiles]
comment = Users profiles
path = /home/samba/profiles
guest ok = no
browseable = no
create mask = 0600
directory mask = 0700

Наконец можно приступать к процедуре апгрейда:

samba-tool domain classicupgrade --dbdir=dbdir/ --use-xattrs=yes --realm=<полное имя вашего домена, например contoso.com> --dns-backend=SAMBA_INTERNAL smb.conf.PDC

Если все было сделано правильно, samba-tool должна отработать без ошибок и сформировать пригодный к употреблению /etc/samba/smb.conf. После запуска сервиса контроллера домена:

systemctl start samba-ad-dc

можно проверить миграцию пользователей и групп командами

samba-tool user list
samba-tool group list

Если все хорошо, можно удалить содержимое файлов passwd_delta.txt, shadow_delta.txt и group_delta.txt из соответствующих системных файлов и перейти к дальнейшей настройке контроллера домена: Samba AD DC HowTo after the provisioning step

1. получаем доступ к устройству по ssh
2. устанавливаем средства разработки
3. скачиваем, собираем и устанавливаем vpnc
4. создаем скрипты для установки/разрыва VPN-соединения и ярлыки для их запуска на рабочем столе

Более подробно о каждом шаге:

Получение доступа к устройству по SSH

Для дальнейших действий понадобится доступ к командной строке – можно использовать встроенный терминал, но гораздо удобнее работать через ssh на нормальной хардварной клавиатуре:

1. включаем в настройках безопасности режим разработчика – смартфон скачает и установит нужные пакеты и, возможно, захочет перезагрузиться; после этого на рабочем столе появляется иконка терминала, запускается sshd
2. там же в настройках появляется список метапакетов для разработки – устанавливаем Utilities, в состав этого пакета входит wget
3. запускаем терминал – по умолчанию все запускается под пользователем user, для получения рутового доступа используем команду devel-su и пароль по умолчанию rootme
4. из-под рута задаем пароль пользователю user, потому что под рутом sshd не пускает
5. командой ip addr узнаем айпишник устройства
6. готово – ssh user@<айпишник> и мы на устройстве с правами пользователя

Установка средств разработки

Чтобы собрать vpnc, нужны как минимум gcc и make, которые изначально на устройстве отсутствуют, плюс пакеты с заголовочными файлами. В предустановленных репозитариях ничего этого нет, поэтому придется подключать дополнительные. Обширный список репозитариев есть на http://forum.allnokia.ru/viewtopic.php?t=82475 (и еще много полезной информации по MeeGo), для наших целей достаточно 2 основных:

1. devel-su (пароль rootme)
2. vi /etc/apt/sources.list.d/nick.list
3. добавляем строчки

   deb http://harmattan-dev.nokia.com/ harmattan/sdk free non-free
   deb http://repo.pub.meego.com/home:/rzr:/harmattan/MeeGo_1.2_Harmattan_Maemo.org_MeeGo_1.2_Harmattan_standard/ ./

4. сохраняем, выходим, запускаем apt-get update
5. запускаем apt-get gcc make libc-dev libc6-dev libgcrypt-dev libssl-dev (и далее по вкусу)

Если все хорошо, apt-get установит все нужные пакеты. Ни в коем случае нельзя соглашаться с предложениями удалить какой-нибудь пакет – система может потерять работоспособность!

Установка vpnc

Стандартный open-source IPSec VPN-клиент для Linux – vpnc. Странно, что в репозитариях не нашлось уже собранного пакета для MeeGo – есть только для предка этой ОС, Maemo, но эти пакеты не ставятся на MeeGo из-за зависимостей. Поэтому пришлось компилировать vpnc прямо на телефоне:

1. devel-su (если еще не под рутом)
2. wget http://www.unix-ag.uni-kl.de/~massar/vpnc/vpnc-0.5.3.tar.gz
3. tar xzf  vpnc-0.5.3.tar.gz
4. cd vpnc-0.5.3
5. из-за отсутствия нужных модулей perl не получится собрать man-страницы (они нам особо и не нужны), поэтому придется в Makefile закомментировать все, что относится к man
6. make && make install

После выполнения make install, если в Makefile пути не менялись, vpnc окажется в /usr/local/sbin, а его конфиг по умолчанию в /etc/vpnc/default.conf.

Для Maemo (как, впрочем, и для Android) есть стандартный GUI для vpnc – vpnc-gui, но он сделан на GTK, и собрать его под MeeGo весьма проблематично (по крайней мере, я не смог). Поэтому продолжаем пилить дальше.

Скрипты

В принципе, уже на данном этапе можно подключаться к VPN из командной строки, но это не очень удобно в повседневном использовании  :) Поэтому для удобства пользователя делаем следующее:

1. прописываем параметры подключения в /etc/vpnc/default.conf (параметры подробно расписаны в выводе vpnc –long-help)
2. в /usr/bin ложим скрипты vpn-on и vpn-off следующего содержания:

vpn-on:

#!/bin/sh
/bin/develsh -c /usr/local/sbin/vpnc
if [ "$?" = "0" ]; then
 echo "Connected!"
else
 echo "ERROR!"
fi
sleep 3

vpn-off:

#!/bin/sh
/bin/kill `/bin/cat /var/run/vpnc/pid`
if [ "$?" = "0" ]; then
 echo "Disconnected."
else
 echo "ERROR"
fi
sleep 3

Следует обратить внимание, что если запускать vpnc из-под user или root, то у него не хватит прав или на чтение конфига, или на доступ к tun-устройству. Поэтому в скрипте vpn-on запускать его приходится через develsh, которому все это разрешается. Такая вот в Harmattan система безопасности. После успешного запуска PID vpnc записывается в файлик /var/run/vpnc/pid, что мы и используем в vpn-off.

Ярлыки

После выполнения предыдущего шага можно подключаться/отключаться к VPN, набирая в командной строке vpn-on/vpn-off. Но чтобы делать это одним касанием пальца, надо бы создать ярлыки на рабочем столе. Ярлыки в MeeGo лежат в /usr/share/applications, поэтому создадим два файлика:

/usr/share/applications/vpn-on.desktop:

[Desktop Entry]
Encoding=UTF-8
Version=0.1
Type=Application
Name=VPN On
Icon=icon-l-email
Exec=/usr/bin/meego-terminal -e /usr/bin/vpn-on
Categories=Office;X-MeeGo;X-Messages;Email;
OnlyShowIn=X-MeeGo;

/usr/share/applications/vpn-off.desktop:

[Desktop Entry]
Encoding=UTF-8
Version=0.1
Type=Application
Name=VPN Off
Icon=icon-l-email
Exec=/usr/bin/meego-terminal -e /usr/bin/vpn-off
Categories=Office;X-MeeGo;X-Messages;Email;
OnlyShowIn=X-MeeGo;

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

Конечно, в идеале все это надо бы сложить в установочный пакет и выложить в общедоступный репозитарий, но ни времени, ни навыков создания deb-пакетов не было. Здесь лежит архив со всеми скриптами и уже скомпилированным vpnc (надо только сделать make install в папке с исходниками vpnc и разложить скрипты в /usr/bin и /usr/share/applications). Компилировалось на Nokia N9 со всеми обновлениями по состоянию на 21.11.2011.

1. отмонтировать диск
2. lvchange -an <LogicalVolumePath>
3. echo 1 > /sys/block/<имя блочного устройства>/device/delete

Можно отключать диск. После подключения:

1. echo «- – -» > /sys/class/scsi_host/<хостадаптер>/scan
2. если подключили обратно тот же диск, то делаем lvchange -ay <LogicalVolumePath> и можно монтировать, иначе по вкусу.