Многострадальным пользователям программы M.E.Doc посвящается! Обновление 11.01.008

Вчера утром (28.05.19), медок осчастливил пользователей сообщением, о изменении адреса сервера ДФС и необходимости срочно установить обновление 11.01.008 и предоставить доступ к новому ресурсу. К сожалению я скриншот сообщения сделать не догадался, поэтому могу показать только вот такую картинку:

Естественно мною был на шлюзе прописан указанный адрес и установлено обновление. Но меня сегодня утром начала долбить бухгалтерия что у них ничего не обновляется и сервер ДФС недоступен. Используя алгоритм описанный мною здесь получил следующий вывод tcpdump:

Терминальный сервер Linux принудительное обновление групп для пользователя Active directory

Столкнулись с интересным глюком: не подтягиваются новые группы пользователя, добавленные на контроллере AD. Причем в других пользователях данной проблемы нет.
Задача:
Принудительно обновить кеш Winbind для пользователя.
Решение:
на сервере под root выполняем

wbinfo -a user

Вводим 2 раза user password и проверяем результат:
su user

groups

В результате должен вывестись актуальный список групп

Обновление Remmina до последней стабильной версии Lubuntu 16.04

Для экспериментов с удаленным доступом к виртуальным машинам Proxmox VE мне потребовалась поддержка SPICE, которая имеется в последних версиях Remmina.
Для того, чтоб обновиться до последней версии добавим репозиторий:

sudo apt-add-repository ppa:remmina-ppa-team/remmina-next

Обновляемся:

sudo apt update && sudo apt upgrade

Устанавливаем SPICE plugin:

sudo apt install remmina-plugin-spice

Результат:

Новый глюк в новой версии MEDoc 11.01.005

Недавно разработчики MEDoc перешли на разработку с использованием платформы .NET. Очевидна смена платформы повлекла за собой возникновение новых ошибок. Далее речь пойдет об одной из них (подозреваю, что речь идет о не очень качественном воплощении патерна connection factory).

Суть проблемы:

В медке имеются группы пользователей с разными комплектами бланков и разными доступами к ресурсам медка. После разрыва связи (не важно пропадал интернет или сервер ДФС), непривилегированные пользователи не могут осуществлять обмен документами(Сервер СДО не доступен). Клиент подвисает на продолжительное время, иногда вылетает. При этом под администратором все нормально работает (оба сервера тестируются и отправка/получение происходит). Обращаю внимание, что речь идет об уровне доступа именно к ресурсам медка, в системе проверялось с правами администратора.

Возможная причина

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

Решение проблемы:

Вопрос окончательного решения на стороне разработчиков. Мы же решаем выключением всех клиентов и перезапуском через стоп/старт службы ZvitGrp.

P.S. если ситуация повториться добавлю картинок: на этой неделе было 2 раза 1-пропадал интернет, 2-пропадали сервера.

pfSense, OpenVPN server. Linux, Windows, MikroTik клиенты. Часть 1(Настройка сервера)

Тема данного поста - максимально простой способ поднять OpenVPN тунель.

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

Предыстория:

Pfsense - основанная на FreeBSD операционная система для маршрутизаторов (шлюзов, роутеров). Я ей пользуюсь достаточно давно, но до сих пор в плане OpenVPN настраивал ее в качестве клиента. И вот возникла потребность настроить сервер, причем под клиенты на разных OS.

HPE OfficeConnect Switch 1820 и SPF модули (ну что может пойти не так?)

Исходные данные:

Имеются территориально разнесенные площадки, сеть между которыми организована с помощью оптики - кинуто две нитки и на концах стоят 100Mb медиаконверторы. В процессе обновления коммутационного оборудования в обоих местах были установлены гигабитные свитчи HPE OfficeConnect Switch 1820 у которых на борту есть гнезда для установки SFP трансмиттеров (оптических модулей). Возникла абсурдная ситуация, когда гигабитные свитчи соединены 100Mb каналом. И если для конечных устройств такая ситуация терпима, то в данном случае это как минимум странно.

Задача:

Используя имеющийся канал связи соединить площадки гигабитным каналом.

Решение:

Было принято решение, используя WDM модули организовать 2 независимых гигабитных канала (ну что может быть проще и что могло пойти не так?). Было преобретено 2 пары вот таких модулей:

Вставляю их в свитчи индикатор моргает и тухнет, присоединяю оптику - тишина! В логах свитча - никакого движения - он просто игнорирует модуль:

Иду в мануал и с удивлением обнаруживаю, что свитчи HP работают только с SFP модулями Aruba SFP  цена которых выше цены свитча.

Созваниваюсь с продавцом модулей, объясняю ситуацию. Мне отвечают: "Ну что же Вы не сказали что у Вас HP? Везите модули - их надо перепрошить." Забираю модули после прошивки, вставляю и о чудо!

P.S.
Кратко о WDM модулях: за счет использования разных длин волн на прием и передачу, эти модули позволяют по одному волокну организовать дуплексный канал. При покупке пары модулей надо следить чтобы параметр T(передача) одного модуля, совпадал с R(прием) другого (в нашем случае 1310/1550).

Proxmox VE. Восстановление ZFS mirror.

Возникла странная и неприятная ситуация:
Имеется одиночная нода Proxmox VE, система установлена на SSD накопителе /dev/sda, в качестве хранилища используется ZFS mirror, который создавался средствами графического интерфейса.
И вот однажды  утром вижу такую картину: