Разработка под linux

Выбор технологий реализации

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

В зависимости от ситуации администратор может выбрать различные способы организации терминального доступа к серверу. В качестве протокола подключения могут быть использованы XDMCP, VNC, RDP, NX или какие-то другие протоколы. Каждый из них имеет свои преимущества, свою историю развития и своих сторонников. Мы из всего этого многообразия вариантов будем рассматривать именно NX. Этот протокол лёг в основу терминальных решений нашей компании и неплохо зарекомендовал себя во внедрениях на серверах пользователей.

Чем же так хорош NX? Он обеспечивает комфортную работу на терминальном сервере, при этом не предъявляя высоких требований ни к скорости сетевого соединения, ни к его стабильности. NX удобен для подключения удалённых пользователей: сотрудников, работающих из дома, и целых филиалов, находящихся в других точках города или регионах. Решения на базе NX позволяют использовать на сервере локальные пользовательские принтеры, подключать дисковые ресурсы

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

Изначально технология NX была представлена продуктами NX NoMachine — это проект итальянской компании Medialogic S.p.A. Коммерческие версии NX NoMachine ориентированы на корпоративных клиентов, а их стоимость составляет от 700$ до 3500$. Существует свободная версия, известная под названием FreeNX. Именно её чаще всего берут за основу решений, организовывая терминальный Linux-сервер.

Сервер FreeNX входит в состав многих дистрибутивов Linux. Для каких-то задач хватает простой его установки, когда-то приходится настраивать и дорабатывать функционал под свои задачи. Следствием проводимых доработок является регулярное появление патченных версий freenx-server и создание собственных проектов, имеющих в своей основе FreeNX. Одним из таких проектов стал проект компании Etersoft — RX@Etersoft.

RX@Etersoft является решением, основанном на FreeNX. Существовав на первом этапе развития в виде патченного freenx-server, со временем проект преобразован в отдельный продукт, позиционирующийся как самостоятельное решение на базе NX. В числе главных отличий RX от FreeNX можно назвать уверенную работу с локальными принтерами и папками, корректную работу кодировок и удобный rootless-режим (режим одного приложения).

RX@Etersoft распространяется под лицензией GPL, как и его предок, что позволяет получить и использовать решение бесплатно. Наряду с бесплатным продуктом есть и его коммерческая версия — тот же самый RX, только с предоставлением сборок под множество систем и правом воспользоваться технической поддержкой.

Варианты клиентских приложений

Что касается клиентских приложений, то они являются общими и для RX@Etersoft, и для FreeNX, и для коммерческой NX NoMachine. Как правило, клиентские программы пишутся кроссплатформенными, что даёт возможность использовать одного и того же клиента в разных операционных системах.

NXClient. Продукт компании NoMachine, является самым популярным для организации подключения к NX-серверу. Обладает богатыми настройками и высокой надёжностью. Есть сборки под Windows и Linux. Главным недостатком этого клиента является отсутствие развития и закрытость кода программы — в случае возникновения ошибок, обходить их приходится разными, не всегда логичными методами.

OpenNX. NX клиент с открытым кодом, написан на C++ с использованием wxWidgets. Существуют сборки под Linux, Windows и MAC OS. Открытость кода даёт проекту стремительно развиваться, и за последние несколько лет перспективный клиент превратился в одну из самых используемых программ для подключения к NX-серверам.

QtNX. Многообещающий проект, к сожалению, не получивший должного развития. На данный момент OpenNX и NXClient значительно превосходят QtNX и по функционалу, и по стабильности.

Есть и другие проекты, но они пока не могут конкурировать с OpenNX и NXClient. Именно на примере этих двух клиентов мы будем в дальнейшем рассматривать организацию подключения к терминальному серверу.

6b. Optional step to disable NBD compression

• NDB compression is enabled by default in Ubuntu 12.04 to speed up client disk access and boot times, but takes a much longer to generate a compressed image file. During development work is might be easier to disable this feature and re-enable it when the setup of the client image is complete. 
• Open the Terminal Window and enter :

sudo gedit /etc/ltsp/ltsp-update-image.conf

• Add NO_COMP=»-noF -noD -noI -no-exports» line to disable compression. Enable the compressing by adding the # symbol, or delete the line completely
• Make sure the file now looks like this example below and save.

# Configuration file for ltsp-update-image
# Do not compress the client image. Comment out the line below to enable again.
NO_COMP="-noF -noD -noI -no-exports"

Просмотр активных пользователей XRDP

У каждого подключенного пользователя создается одна сессия, их то нам и надо посмотреть выполнив необходимую команду:

ps aux | grep xrdp | grep xorg
= вывод команды =
local      694  3.7  1.9 571540 76992 ?        Sl   22:47   0:29 /usr/lib/xorg/Xorg :10 -auth .Xauthority -config xrdp/xorg.conf -noreset -nolisten tcp -logfile .xorgxrdp.%s.log

Вот мы видим что подключен только один пользователь с логином local и PID 694.

Просто снять этот процесс не достаточно, чтобы полностью завершить работу пользователя на сервере. Выведем список всех процессов сервиса XRDP:

ps aux | grep xrdp
= вывод команды =
root       447  0.0  0.0  13860  3640 ?        S    22:45   0:00 /usr/sbin/xrdp-sesman
xrdp       471  0.0  0.0  12248  2044 ?        S    22:45   0:00 /usr/sbin/xrdp
root       692  0.0  0.0  13616  2300 ?        S    22:47   0:00 /usr/sbin/xrdp-sesman
local      694  3.8  1.9 571540 76992 ?        Sl   22:47   0:36 /usr/lib/xorg/Xorg :10 -auth .Xauthority -config xrdp/xorg.conf -noreset -nolisten tcp -logfile .xorgxrdp.%s.log
local      697  0.0  0.0  99512  3412 ?        Sl   22:47   0:00 /usr/sbin/xrdp-chansrv
xrdp       903  4.1  0.6  40076 28176 ?        S    22:47   0:37 /usr/sbin/xrdp
root       982  0.0  0.0   6224   828 pts/0    S+   23:02   0:00 grep xrdp

Теперь мы можем отключить пользователя указав команду, которая завершит все процессы пользователя:

pkill -9 -u local

Синтаксис некоторых важных и нестандартных параметров[править]

Графикаправить

X_CONF             = /root/xorg_ws01.conf # указать свой xorg.conf
XSERVER            = vesa # явно указать драйвер
X_MODULE_05        = "-dri" # отключить модуль
X_MODULE_10        = "vnc" # включить модуль
XRANDR_DISABLE     = Y # для опций с разрешением и частотой
X_VERTREFRESH      = 60 # частота  
X_MODE_0           = 1024x768 # разрешение
DISABLE_ACCESS_CONTROL = Y # Добавляет опцию "-ac" в строку запуска Xorg

Cледующие две строки используются вместе, modeline получен на «Intel NM10(atom)» командой «cvt 1280 1024 75»

X_MONITOR_MODE     = "Modeline \"1280x1024_75.00\"  138.75  1280 1368 1504 1728  1024 1027 1034 1072 -hsync +vsync"
X_MODE_0           = 1280x1024_75.00

Клавиатура и мышь

XKBLAYOUT          = "ru,us"
XKBVARIANT         = "winkeys,"
XKBOPTIONS         = "grp:alt_shift_toggle,grp_led:scroll"
X_MOUSE_RESOLUTION = 800 # по умолчанию 800 (не проверено )
X_MOUSE_BUTTONS = 2 # по умолчанию 3 ( не проверено )

NXправить

Параметры можно указывать в секциях или, что иногда удобнее, в строке запуска, например:

SCREEN_07 = nx -u user1 -d kde -l adsl -m 128
SCREEN_07 = -s terminal1
SCREEN_07 = --admin

Параметры запуска в строке, соответствующий параметр секции lts.conf

--admin                             # Нет параметров, запуск nxclient в обычном режиме
--client|-c     , NX_CLIENT =       # nxclient|opennx , выбор клиента
--autologin|-a                      # (Нет параметров. Автозапуск сессии для opennx. Указывать после "--client opennx"
--session|-s    , NX_SESSION =      # Файл сессии, если файл в /root/.nx/config/session1.nxs, можно указывать session1
--linux_user|-u , NX_LINUX_USER =   # имя пользователя
--desktop|-d    , NX_DESKTOP =      # gnome|kde|default|rootless-приложение
--link_speed|-l , NX_LINK_SPEED =   # modem|isdn|adsl|wan|lan
--cache_mem|-m  , NX_CACHE_MEM =    # 4|8|16|32|64|128, размер кэша в памяти (MB)
--ssl|-e)       , NX_SSL =          # true|false, для отключения шифрования указать в файле "nxloadconfig"
                                    # EXTERNAL_PROXY_IP="IP интерфейса сервера"
                                    # открыть порты TCP 5000-6000
                , NX_SERVER =       # Если не указан, = $SERVER
                , NX_PORT =         # Если не указан = 22
                , NX_ROOTLESS_XKB = # Раскладка, инструкция в файле chroot/usr/share/ltsp/screen.d/start_nx

Другие подробности смотреть LTSP/NX

VNC в P6править

Необходимо установить в чрут пакет «xorg-extension-vnc» или сделать как для P5

X_MODULE_10        = "vnc" # включить модуль

Настройка VNC с модулем xorg(пакет «xorg-extension-vnc»)

xorg.conf для «VNC over SSH»

Section "Module"
   ...
   Load "vnc"
EndSection
Section "Screen"
       ...
   Option "rfbport" "5900"
   Option "localhost"
   Option  "SecurityTypes" "None"
EndSection

VNC в P5править

В P5 нет модуля /usr/lib/X11/modules/extensions/libvnc.so. Идет в пакете «xorg-extension-vnc»(предоставляется tigervnc).

VNC сервер можно запустить средствами x11vnc(необходимо установить в чрут пакет x11vnc).

в lts.conf добавить

DISABLE_ACCESS_CONTROL = Y

Строку добавить в файл(до while) /usr/share/ltsp/screen.d/xdmcp

с паролем:

x11vnc -bg -usepw -forever -shared -quiet -rfbport 5900 -display :7 -loop

без пароля, VNC over SSH:

x11vnc -bg -localhost -forever -shared -quiet -rfbport 5900 -display :7 -loop

Толстые клиенты

В LTSP v5.x добавлена ​​поддержка тонких клиентов особого типа, известных как «толстые клиенты» (fat clients). С появлением недорогих и при этом довольно мощных компьютеров стало возможным запускать приложения локально на тонком клиенте, и при этом сохранить управляемость такого решения. В случае толстого клиента LTSP, корневая файловая система — это не урезанный chroot, а полная установка Linux как chroot. Толстый клиент использует LDM для аутентификации на сервере LTSP и монтирует домашние каталоги пользователей с помощью SSH и FUSE. Толстые клиенты используют собственный процессор и оперативную память, что даёт некоторые преимущества:

1. сервер LTSP не страдает от пользователей, злоупотребляющих потреблением ресурсов и влияющих на производительность и доступность сервера LTSP для других пользователей;
2. мультимедийные и 3D-приложения работают лучше и меньше нагружают сеть.

LTSP примечателен тем, что предлагает возможность компьютерам монтировать корневую файловую систему по сети, но запускать приложения локально. На платформе Windows, ближайшим аналогом является использование технологий типа Intel vPro для запуска гипервизора на стороне клиента и монтирования образа корневой файловой системы, используя iSCSI.

Принцип работы

Допустим, у вас есть сервер и множество компьютеров (терминальных станций), которые вы раздаете пользователям, чтобы те за ними работали. Терминальные станции эти почти ничем не отличаются от обычных компьютеров, за исключением того, что их размеры обычно достаточно малы, для работы им не нужен жесткий диск и, кроме того, они могут быть довольно слабыми и дешевыми, на работе пользователей это не отражается (в режиме тонкого клиента). Стоит отметить, что в роли терминальной станции может выступать любой компьютер, который умеет загружаться по сети.

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

Теперь о режимах работы:

• тонкий клиент — Приложения выполняются на терминальном сервере и просто выводятся на дисплей терминального клиента.
• толстый клиент — Приложения выполняются непосредственно на терминальном клиенте, а сервер просто предоставляет доступ к пользовательским файлам и программам.

Итак, какой же режим нам выбрать? — все зависит от того, что вы хотите получить. Вы можете немного сэкономить используя на клиентах слабые станции вкупе с мощным сервером в режиме тонких клиентов. Или разгрузить терминальный сервер и локальную сеть, купив терминальные станции помощнее, переложив ответсвенность за выполнение программ на клиентов, заставив их, тем самым, работать в режиме толстого клиента.

Кроме того, режимы можно комбинировать и некоторые приложения можно заставлять работать иначе, чем все остальные. Например запускать «тяжелый» браузер с flash локально на клиентах, а офисные приложения запускать на самом сервере.

Различие Базовой и Проф конфигурации

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

Рассмотрим кратко основные отличия:

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

В практике сталкивался с тем что иногда компания сидит в старой версии программы (например 8.1) и хотят перейти и обновится до новой версии 8.3 но продавец у которого они приобретали продукт говорит что надо покупать новую версию. Какое было у них удивление когда я обновлял и ставил им последнюю версию и показывал как надо обновляться. Конечно я не затрагиваю момент обновление конфигурации с обновлением всех данных хотя и это при грамотном подходе возможно сделать с сохранением всех основных данных.

Оптимальное использование файловой базы данных 1C:Предприятие

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

Существует два варианта улучшения скорости работы в файловой базе данных:

• Использование локальной сети 1 Gbit и диска SSD для базы данных — на какой то момент это улучшит положение но как показала практика не на долго. Очень быстро пользователи привыкают к улучшению скорости и начинаются опять жалобы на зависания в работе.
• Использование терминального сервера — при этом варианте в организацию приобретается один мощный компьютер на котором устанавливается программа и все пользователи удалено подключаются к компьютеру использую свой профиль. Получится что на одном компьютере будет одновременно сидеть несколько пользователей не видя друг друга. По сети передается только картинка а вся работа производится на сервере. Возможно настроить удаленный доступ из интернета и тогда избранные пользователи смогут используя медленный интернет спокойно работать в программе с домашнего компьютера.

LTSP clietn

FAT client

Ubuntu Mate-desktop

apt-get install software-properties-common python-software-properties
apt-add-repository ppa:ubuntu-mate-dev/ppa
apt-add-repository ppa:ubuntu-mate-dev/xenial-mate
apt-get update && apt-get upgrade
apt-get install ubuntu-mate-core ubuntu-mate-desktop --no-install-recommends

Google Chrome

wget -q -O - https://dl-ssl.google.com/linux/linux_signing_key.pub | apt-key add -
echo "deb  http://dl.google.com/linux/chrome/deb/ stable main" >> /etc/apt/sources.list.d/google-chrome.list
apt-get update
apt-get install google-chrome-stable

Антивирус

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

Но эти вирусы могут использовать файловый сервер Samba для распространения от одной Windows системы на другие. Что бы поддерживать наше файловое хранилище в чистоте, мы установим антивирус и настроим автоматическое сканирование.

Установим антивирус ClamAV

$ sudo apt install clamav

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

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

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

$ sudo mkdir /quarantine
$ sudo chmod 600 /quarantine

Попробуем просканировать домашние папки пользователей

$ sudo clamscan -i -r --move=/quarantine /home

После сканирования получим протокол

----------- SCAN SUMMARY -----------
Known viruses: 6278963
Engine version: 0.99.2
Scanned directories: 13
Scanned files: 13
Infected files: 0
Data scanned: 4.79 MB
Data read: 1.59 MB (ratio 3.00:1)
Time: 22.176 sec (0 m 22 s)

Все хорошо, вирусов не обнаружено. Если бы нашлось что-то подозрительное, оно было бы перемещено в папку карантина.

Нам остается настроить автоматическое расписание обновления сигнатур и сканирования домашних папок. Редактируем файл расписания демона cron

$ sudo crontab -e

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

Добавьте две строчки

0 1 * * * freshclam
0 2 * * * clamscan -i -r --move=/quarantine /home

Каждый день в 1:00 ночи будет автоматически запускаться обновление сигнатур, а в 2:00 ночи будет запущено сканирование всех домашних папок пользователей, инфицированные файлы будут перемещены в папку карантина.

6a. Optional step to configure a Fat Client not a Thin Client before build

• This step is only needed if you intend to use your LTSP server for Fat clients, rather than Thin clients or both. For more information between the differences between Thin and Fat clients and configuration see UbuntuLTSPFatClients 
• This step edits the LTSP build client configuration file to install Ubuntu desktop and create LTSP Fat client image. 
• NOTE: only software installed in the Fat client image will be available to the client, and internet access for each client needs to be configured as the clients will not share the server network connection to the internet as is the case with the thin clients.
• Open the Terminal Window and enter :

sudo gedit /etc/ltsp/ltsp-build-client.conf

• Here you can customize your installation image for Fat clients.
• We will only install the standard Ubuntu Desktop system to run on the client side for now. We can install more software to the image later, this is to get a basic Fat client image built.
• Add the following to the file and save.

# ltsp-build-client.conf - many other options available 
# The chroot architecture.
ARCH=i386

# ubuntu-desktop and edubuntu-desktop are tested.
# Ubuntu 12.04 LTS working perfectly with Unity and Unity 2D.
FAT_CLIENT_DESKTOPS="ubuntu-desktop"

Итоги

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

К тому же, благодаря свободной лицензии все это достается вам абсолютно бесплатно.

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

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

Несколько интересных ссылок:

Источник