Ubuntu 14.10. Проблемы после обновления с 14.04

После обновления до Ubuntu 14.10  у меня возникли две проблемы. Первая, которая уже была описана ранее - ломается gnome ssh askpass, необходимо запустить вручную от пользователя в консоли
eval `gnome-keyring-daemon --start` 

Вторая - ломается VPN в gnome network manager. При попытке подключиться по VPN - тишина, а в логах что-то типа такого:

Nov 21 12:28:01 localhost NetworkManager[1113]: <info> Starting VPN service 'openvpn'...
Nov 21 12:28:01 localhost NetworkManager[1113]: <info> VPN service 'openvpn' started (org.freedesktop.NetworkManager.openvpn), PID 3928
Nov 21 12:28:01 localhost NetworkManager[1113]: <info> VPN service 'openvpn' appeared; activating connections
Nov 21 12:28:01 localhost NetworkManager[1113]: <error> [1416565681.435869] [nm-vpn-connection.c:1374] get_secrets_cb(): Failed to request VPN secrets #2: (6) No agents were available for this request.
Nov 21 12:28:01 localhost NetworkManager[1113]: <info> Policy set 'Wired connection 1' (eth0) as default for IPv4 routing and DNS.
Nov 21 12:28:06 localhost NetworkManager[1113]: <info> VPN service 'openvpn' disappeared

Решение:
Зайти в ~/.gconf/apps/nm-applet/
и удалить %gconf.xml. После чего logout-login, и все начинает работать.

Bonding в RHEL. Новые горизонты :)

В связи с изменениями в оборудовании (пора, пора апгрейдиться ;) ) пришлось менять и схему бондинга.
Мы перешли на HP Proliant 645c G7 (блейды-"половинки") и Flex-10 карты. Особенности такого оборудования - на бокс выделяется две физических сетевушки и шесть виртуальных (всего восемь), между которыми делится скорость в 10+10Gbit. Вполне очевидно, что оптимальная схема включения - две карты по 10Gbit.

В этой связи смысл привязывать свой VLAN к каждой карте ( как это описано в предыдущей статье ) несколько теряется. зато появляется возможность значительно упростить схему подключения, сведя ее к классической "active-backup".

Основная задача все та же - если у нас вылетает один сетефой интефейс (один flex-10), все должно работать :)

Итак, начнем.

Безотказная работа сети (network bonding) в Redhat - реализация(продолжение)

После статьи Обеспечение безотказной работы сети в RedHat Linux (bonding) для нескольких IP сетей прошло достаточно много времени, а тут мне (точнее начальству) приспичило сделать супер безотказную сетку :)

По "свежим следам", пока помню, опишу, т.к. задача была чуть более сложная, чем описано ранее, и как результат, проявились отличия.

Итак, постановка задачи:

• Имеем бокс с четырмя сетевыми картами подключенные к двум свичам


• Имеем две сети (два VLAN'а)


• Задача: пока жив хоть один свич и один порт, все должно работать :)

Собственно, задача ненамного сложнее, чем описанная в предыдущей статье про bonding.
Но есть и различия.

Некоторые результаты тестирования network teaming (bonding)

Когда я реализовал схему резервирования сетевых карт, как описано в предыдущей статье, мне, разумеется стало интересно узнать, как оно работает в реальной жизни.

С помощью нашего нетворк инженера были проведены эксперименты, имитирующие проблемы с оборудованием. Точнее, просто отключали порты на свичах.

Краткие результаты:

• отключение второго порта (standby). Никаких изменений в работе сети, что и следовало ожидать.


• отключение первого порта (active). Сеть недоступна, в течении 30 сек происходит переключение, сеть снова доступна


• включаем первый порт. Никаких изменений (все правильно, драйвер не инструктировали возвращаться назад на основной интерфейс. такой режим возможен, однако не рекомендуется, т.к. из-за глючащего контакта в кабеле можно получить постоянное переключение туда-сюда, что очень нежелательно.


• выключаем второй порт (текущий standby). переключение на основной линк произошло за несколько секунд.

Обеспечение безотказной работы сети в RedHat Linux (bonding) длянескольких IP сетей

Один из важнейших элементов обеспечения бесперебойной работы ответственных серверов ( работающих по схемам 24/7 или 365/24/7 ) это резервирование сетевых интерфейсов. В самом деле, какой смысл в дорогом оборудовании, RAID 1+0, spare disks, если сервер соединен со свичем через один адаптер, один кабель, один порт? Да и свич тоже может выйти из строя.

Пусть мы имеем следующие исходные параметры:

• сервер подключен к свичам через два адаптера


• в нашей сети имеются два диапазона IP адресов - 192.168.1.0/24 и 192.168.2.0/24


• эти сети разделены при помощи VLAN, ID сетей 10 и 20 соответственно


• адреса интерфейсов сервера - 192.168.1.10, 192.168.2.10


• ОС - RedHat 5 или совместимые - CentOS 5, Oracle Linux 5

Хочу обратить внимание. В данном примере (в отличие от классического варианта bonding) нам не нужно удваивать количество сетевых карт - мы будем использовать те, что есть (network teaming). Главное, что карт более одной.

CentOS 5.1 и D-Link Wifi

Столкнулся с серьезной проблемой.

Имеем WiFi: D-link Access Point DWL-2100AP и сетевушку D-Link DWL-G550 PCI на чипе Atheros AR5212

Сама сетевушка завелась без проблем (драйвер ath_pci), а вот коннектиться к точке доступа в упор не захотела. Притащил на работу. проверил на другой машине с AP Netgear - без малейших проблем запускается. С 2100AP - не хочет.

В общем, после танцев с бубнами перешили точку доступа на последнюю прошивку - полегчало, завелось сразу же, WPA2 поднялся без проблем на wpa_supplicant.