Опыт установки и настройки Ubuntu сервера был, но давний и не совсем удачный (пришёл более квалифицированный человек и поставил FreeBSD). Поэтому некоторое представление о работе с Astra Linux имеется.
Исходные данные:
Бюджетная организация купила достаточно серьёзный сервер Aquarius Server T40 S35 для бухгалтерии. В связи с планируемым переходом к 2020 году на Astra Linux и отсутствием лицензионного Windows Server-а было принято решение установить Astra Linux. 1С у нас не SQL версия, поэтому базу данных PostgreSQL настраивать не пришлось. Десяток клиентских компьютеров с Windows 7 и XP. Надо организовать удалённую работу по сети с сервером, так как не использовать такую мощную машинку посчитал глупостью. До этого сервер (старый) использовался как файл-сервер (хранил файлы БД 1С).
После получения исходника с установкой 1С проблем не возникло. Хотя даже для файловой 1С нужно устанавливать сервер 1С, что меня несколько удивило. Перенос баз в моём случае простое копирование каталогов и дальнейшее их подключение у клиентов.
Стал вопрос как чем подключать удалённых клиентов. Тут возникли некоторые нюансы, о которых я хочу рассказать.
Мной были опробованы следующие варианты: Vcxsrv, x2go, PuTTY, xRDP.
1. Vcxsrv. Сразу не пошёл. У его лаунчера есть интересная фича -- при двух сетевых картах на клиенте если сервер находится во второстепенной сети (сетевая карта без сетевого шлюза) этот лаунчер может благополучно найти сервер, но не подключается к удалённому рабочему столу. При отключении "лишних" сетевых карт соединение происходило просто замечательно. Мне этот способ не подошёл, так как у некоторых бухгалтеров есть вторая сетевая карта. Сеть проектировал и строил не я. Изменять её я не могу. Приходится работать с тем, что есть.
2. x2go. Мне он понравился -- сервер и клиент есть в репозитарии. Ставятся без проблем. Клиент под Windows тоже есть. На сегодня его версия 4.1.2. Обещают проброс принтеров (не получилось) и локальных дисков (получается сразу). Кроме "поломки" кодировки при копировании через clipboard из удалённой машины на клиента сначала всё было нормально. Начал смотреть, как обойти эту проблему. Сначала поставил более старый клиент версии 4.0.3. В нём кодировка нормальная, но перестаёт работать проброс локальных каталогов. Проблему решил следующим образом.
Установил отдельно x2go и VcxSrv версий 4.1.2. Запустил VcxSrv в многооконном режиме для клиентов (как советуют для PuTTY) с ключами "-dpi 96 -xkblayout us,ru -xkbvariant basic,winkeys -xkboptions grp:ctrl_shift_toggle". Решается вопрос с переключением русской/английской раскладки. В x2go в Установках "X.Org Server settings" поставил "Использовать другой X-Server" и убрал галочку "запускать X-Server при запуске X2Go Client". Исправилась кодировка при копировании из буфера, сохранился проброс локальных каталогов. X2go можно запускать в виде отдельного окна по типу RemouteApp. Всё замечательно, но бухгалтеры стали жаловаться на постоянные "подвисания" и разрывы сессий. Но кризис наступил, когда я задействовал вторую сетевую карту (сетевой интерфейс) у сервера с пробросом пакетов, чтобы оба сегмента сети могли видеть друг друга. Делал я это при подключённых через x2go пользователей. Те, которые были подключены, продолжали работать. При попытке установить новое соединение происходит ошибка. При этом пинги и прочие прелести работают. При сбросе настроик проброса пакетов всё заработало нормально. Кстати, KiTTY (PuTTY) нормально соединяется в обоих случаях. Но проброс пакетов нужен.
Тогда решил поменять транспорт.
3. PuTTY. Вернее KiTTY. Отличается от PuTTY наличием параметра send-to-tray при запуске из командной строки, что позволяет прятать терминальное окно в трей и не пугать пользователей. В связке с Vcxsrv позволяет вызвать отдельное окно 1С для работы. НО в 1С с конфигурацией "Зарплата" странное поведение у окна. Те же ощутимые тормоза. Для Windows XP Vcxsrv есть только старых версий десятилетней давности, в которой с этой (именно этой) конфигурацией перестали работать кнопки сворачивания окна и развёртывания окна на весь экран. И перетаскивание окна в этом сочетании не работает.
Кстати, для себя оставил. Работаю с MC и некоторыми оконными утилитами.
4. xRDP. После всех экспериментов остановился на нём. Пока с ним и работаю.
Плюсы:
- При разрыве соединения происходит восстановление с того же места, что удобно для пользователей. SSH этим похвалиться не может.
- Стабильная без зависаний работа 1С с "зарплатной" конфигурацией.
Минусы:
- Пришлось пользователей пустить на удалённый рабочий стол fly, что для них было несколько непривычно.
- Не смог пробросить локальные ресурсы. Пока пытаюсь разобраться.
- Перестали запускаться окна с командой sudo. Например, "Управление политикой безопасности" не запускается. "Инициализация системы" с правами root (даёт возможность удалить любую сессию) тоже. Только в соединении через RDP от root, где не надо повышать права, всё работает нормально.
После активизации root как пользователя перестало работать из-под PuTTY "su-to-root -X -c fly-admin-smc" -- запуск "Управление политикой безопасности", да и любое X окно с командой sudo. Нашёл решение в Интернете: указать для новой оболочки переменную XAUTHORITY. И запускаю окна следующим образом:
sudo XAUTHORITY=${HOME}/.Xauthority systemdgenie
Мне помогло.
Исходные данные:
Бюджетная организация купила достаточно серьёзный сервер Aquarius Server T40 S35 для бухгалтерии. В связи с планируемым переходом к 2020 году на Astra Linux и отсутствием лицензионного Windows Server-а было принято решение установить Astra Linux. 1С у нас не SQL версия, поэтому базу данных PostgreSQL настраивать не пришлось. Десяток клиентских компьютеров с Windows 7 и XP. Надо организовать удалённую работу по сети с сервером, так как не использовать такую мощную машинку посчитал глупостью. До этого сервер (старый) использовался как файл-сервер (хранил файлы БД 1С).
После получения исходника с установкой 1С проблем не возникло. Хотя даже для файловой 1С нужно устанавливать сервер 1С, что меня несколько удивило. Перенос баз в моём случае простое копирование каталогов и дальнейшее их подключение у клиентов.
Стал вопрос как чем подключать удалённых клиентов. Тут возникли некоторые нюансы, о которых я хочу рассказать.
Мной были опробованы следующие варианты: Vcxsrv, x2go, PuTTY, xRDP.
1. Vcxsrv. Сразу не пошёл. У его лаунчера есть интересная фича -- при двух сетевых картах на клиенте если сервер находится во второстепенной сети (сетевая карта без сетевого шлюза) этот лаунчер может благополучно найти сервер, но не подключается к удалённому рабочему столу. При отключении "лишних" сетевых карт соединение происходило просто замечательно. Мне этот способ не подошёл, так как у некоторых бухгалтеров есть вторая сетевая карта. Сеть проектировал и строил не я. Изменять её я не могу. Приходится работать с тем, что есть.
2. x2go. Мне он понравился -- сервер и клиент есть в репозитарии. Ставятся без проблем. Клиент под Windows тоже есть. На сегодня его версия 4.1.2. Обещают проброс принтеров (не получилось) и локальных дисков (получается сразу). Кроме "поломки" кодировки при копировании через clipboard из удалённой машины на клиента сначала всё было нормально. Начал смотреть, как обойти эту проблему. Сначала поставил более старый клиент версии 4.0.3. В нём кодировка нормальная, но перестаёт работать проброс локальных каталогов. Проблему решил следующим образом.
Установил отдельно x2go и VcxSrv версий 4.1.2. Запустил VcxSrv в многооконном режиме для клиентов (как советуют для PuTTY) с ключами "-dpi 96 -xkblayout us,ru -xkbvariant basic,winkeys -xkboptions grp:ctrl_shift_toggle". Решается вопрос с переключением русской/английской раскладки. В x2go в Установках "X.Org Server settings" поставил "Использовать другой X-Server" и убрал галочку "запускать X-Server при запуске X2Go Client". Исправилась кодировка при копировании из буфера, сохранился проброс локальных каталогов. X2go можно запускать в виде отдельного окна по типу RemouteApp. Всё замечательно, но бухгалтеры стали жаловаться на постоянные "подвисания" и разрывы сессий. Но кризис наступил, когда я задействовал вторую сетевую карту (сетевой интерфейс) у сервера с пробросом пакетов, чтобы оба сегмента сети могли видеть друг друга. Делал я это при подключённых через x2go пользователей. Те, которые были подключены, продолжали работать. При попытке установить новое соединение происходит ошибка. При этом пинги и прочие прелести работают. При сбросе настроик проброса пакетов всё заработало нормально. Кстати, KiTTY (PuTTY) нормально соединяется в обоих случаях. Но проброс пакетов нужен.
Тогда решил поменять транспорт.
3. PuTTY. Вернее KiTTY. Отличается от PuTTY наличием параметра send-to-tray при запуске из командной строки, что позволяет прятать терминальное окно в трей и не пугать пользователей. В связке с Vcxsrv позволяет вызвать отдельное окно 1С для работы. НО в 1С с конфигурацией "Зарплата" странное поведение у окна. Те же ощутимые тормоза. Для Windows XP Vcxsrv есть только старых версий десятилетней давности, в которой с этой (именно этой) конфигурацией перестали работать кнопки сворачивания окна и развёртывания окна на весь экран. И перетаскивание окна в этом сочетании не работает.
Кстати, для себя оставил. Работаю с MC и некоторыми оконными утилитами.
4. xRDP. После всех экспериментов остановился на нём. Пока с ним и работаю.
Плюсы:
- При разрыве соединения происходит восстановление с того же места, что удобно для пользователей. SSH этим похвалиться не может.
- Стабильная без зависаний работа 1С с "зарплатной" конфигурацией.
Минусы:
- Пришлось пользователей пустить на удалённый рабочий стол fly, что для них было несколько непривычно.
- Не смог пробросить локальные ресурсы. Пока пытаюсь разобраться.
- Перестали запускаться окна с командой sudo. Например, "Управление политикой безопасности" не запускается. "Инициализация системы" с правами root (даёт возможность удалить любую сессию) тоже. Только в соединении через RDP от root, где не надо повышать права, всё работает нормально.
После активизации root как пользователя перестало работать из-под PuTTY "su-to-root -X -c fly-admin-smc" -- запуск "Управление политикой безопасности", да и любое X окно с командой sudo. Нашёл решение в Интернете: указать для новой оболочки переменную XAUTHORITY. И запускаю окна следующим образом:
sudo XAUTHORITY=${HOME}/.Xauthority systemdgenie
Мне помогло.
Последнее редактирование: