Для кого предназначена эта статья? Данная статья может быть интересна системным администраторам, перед которыми стоит задача создания сервиса «одноразовых» рабочих станций.
Пролог
В отдел ИТ-поддержки молодой динамично развивающейся компании с небольшой региональной сетью обратились с просьбой организовать «станции самообслуживания» для использования внешними клиентами.Эти станции предполагалось использовать для регистрации на внешних порталах компаний, загрузки данных с внешних устройств и работы с правительственными порталами.
Важным аспектом стало то, что большая часть программного обеспечения «заточена» под MS Windows (например, «Декларация»), и, несмотря на движение в сторону открытых форматов, MS Office остается доминирующим стандартом обмена электронными документами.
Таким образом, мы не смогли отказаться от MS Windows при решении этой задачи.
Основной проблемой была возможность накопления различных данных из пользовательских сессий, что могло привести к их утечке третьим лицам.
Эта ситуация уже подвела МФЦ .
Но в отличие от квазигосударственного (государственного автономного учреждения) МФЦ, негосударственные организации за подобные недостатки будут наказываться гораздо строже.
Следующей по значимости проблемой стало требование работы с внешними носителями информации, которые наверняка содержали кучу вредоносного вредоносного ПО.
Вероятность импорта вредоносного ПО из Интернета считалась менее вероятной из-за ограничений доступа в Интернет с использованием белого списка адресов.
К разработке требований подключились сотрудники других отделов, внося свои требования и пожелания, окончательные требования выглядели так: Требования информационной безопасности
- После использования все пользовательские данные (включая временные файлы и ключи реестра) необходимо удалить.
- Все процессы, запущенные пользователем, должны быть прекращены по завершении работы.
- Доступ в Интернет по белому списку адресов.
- Ограничения на возможность запуска стороннего кода.
- Если сеанс бездействует более 5 минут, сеанс должен автоматически завершиться, и станция должна очиститься.
- Количество клиентских станций в одном филиале – не более 4.
- Минимальное время ожидания готовности системы, от момента, когда вы «сели» до начала работы с клиентским ПО.
- Возможность подключения периферийных устройств (сканеров, флэш-накопителей) непосредственно с места установки «станции самообслуживания».
- Пожелания клиента
- Демонстрация рекламных материалов (фотографий) во время простоя комплекса.
Муки творчества
Наигравшись с Windows livecds, мы пришли к единогласному выводу, что полученное решение не удовлетворяет как минимум 3-м критическим пунктам.Они либо долго загружаются, либо не совсем живые, либо их настройка была связана с дикими болями.
Возможно мы плохо искали, и вы можете порекомендовать набор инструментов, буду благодарен.
Тогда мы стали смотреть в сторону VDI, но для этой задачи большинство решений либо слишком дороги, либо требуют пристального внимания.
Но мне нужен был простой инструмент с минимальным количеством магии, большинство проблем которого можно было бы решить простой перезагрузкой/перезапуском службы.
К счастью, у нас было серверное оборудование бюджетного класса в филиалах из выводимой из эксплуатации службы, которое мы могли использовать для технологической базы.
Что произошло в конце? Но что получилось в итоге не могу сказать, потому что это NDA, но в процессе поиска мы разработали интересную схему, которая хорошо показала себя в лабораторных испытаниях, хотя и не пошла в производство.
Несколько оговорок: автор не утверждает, что предложенное решение полностью решает все поставленные проблемы и делает это добровольно и с песней.
Автор заранее согласен с утверждением, что Sein Englishe sprache — это zehr schlecht. Поскольку решение больше не разрабатывается, на исправление ошибок или изменение функционала рассчитывать не приходится, все в ваших руках.
Автор предполагает, что вы хоть немного знакомы с KVM, читали обзорную статью по протоколу Spice и немного работали с Centos или другим дистрибутивом GNU Linux.
В этой статье я хотел бы проанализировать основу полученного решения, а именно взаимодействие клиента и сервера и суть процессов жизненного цикла виртуальных машин в рамках рассматриваемого решения.
Если статья представляет интерес для общественности, я опишу детали реализации живых образов для создания тонких клиентов на базе Fedora и расскажу о деталях настройки виртуальных машин и KVM-сервера для оптимизации производительности и безопасности.
Если вы возьмете цветную бумагу, Краски, кисти и клей, И еще немного мастерства.
Вы можете заработать сто рублей!
Схема и описание испытательного стенда
Все оборудование находится внутри сети филиала, наружу выходит только интернет-канал.
Исторически прокси-сервер уже существовал; в этом нет ничего экстраординарного.
Но именно на нем, помимо всего прочего, будет происходить фильтрация трафика от виртуальных машин (сокр.
ВМ ниже по тексту).
Ничто не мешает вам разместить эту службу на KVM-сервере; единственное, за чем нужно следить, это как от него меняется нагрузка на дисковую подсистему.
Клиентская станция на самом деле является «станцией самообслуживания», «интерфейсом» нашего сервиса.
Это неттопы Lenovo IdeaCentre. Что хорошего в этом агрегате? Да почти всем, особенно порадовало большое количество USB-разъемов и картридера на передней панели.
В нашей схеме в картридер вставляется SD-карта с включенной аппаратной защитой от записи, на которую записывается модифицированный живой образ Fedora 28. Разумеется, к неттопу подключены монитор, клавиатура и мышь.
Свитч — ничем не примечательный аппаратный коммутатор второго уровня, стоящий в серверной и мигающий лампочками.
Он не подключен ни к каким сетям, кроме сети «станций самообслуживания».
KVM_Server — ядро схемы; в стендовых тестах Core 2 Quad Q9650 с 8 ГБ ОЗУ уверенно поддерживал 3 виртуальные машины с Windows 10. Дисковая подсистема – Adaptec 3405 2 диска Raid 1 + SSD. В полевых тестах Xeon 1220 более серьёзный LSI 9260 + SSD легко поддерживал 5-6 ВМ.
Мы получим серверы от устаревшего сервиса; не будет больших капитальных затрат. На этом сервере(ах) установлена система виртуализации KVM с пулом виртуальных машинpool_Vm. VM — это виртуальная машина, серверная часть нашего сервиса.
Здесь происходит работа пользователя.
Enp5s0 — сетевой интерфейс, обращенный к сети «станций самообслуживания», на нем живут dhcpd, ntpd, httpd, а xinetd слушает «сигнальный» порт. Lo0 — это псевдо-петлевой интерфейс.
Стандарт. Spice_console — Очень интересная вещь, дело в том, что в отличие от классического RDP, при расширении связки протоколов KVM+Spice появляется дополнительная сущность — консольный порт виртуальной машины.
Фактически, подключившись к этому TCP-порту, мы получаем консоль Вм, без необходимости подключения к Вм через его сетевой интерфейс.
Сервер берет на себя все взаимодействие с Vm для передачи сигнала.
Ближайший аналог по функциям – IPKVM. Те.
На этот порт передается изображение монитора ВМ, на него также передаются данные о движении мыши, и (что самое главное) взаимодействие по протоколу Spice позволяет плавно перенаправлять USB-устройства на виртуальную машину, как если бы это устройство было подключено.
к самому ВМ.
Проверено на флешках, сканерах, веб-камерах.
Виртуальные сетевые карты Vnet0, virbr0 и Vm образуют сеть виртуальных машин.
Как это работает?
С клиентской станции
Клиентская станция загружается в графическом режиме из модифицированного живого образа Fedora 28, получает IP-адрес по DHCP из адресного пространства сети 169.254.24.0/24. В процессе загрузки создаются правила брандмауэра, которые разрешают подключения к «сигнальным» и «спайсовым» портам сервера.
После завершения загрузки станция ожидает авторизации пользователя «Клиент».
После авторизации пользователя запускается менеджер рабочего стола «openbox» и от имени авторизованного пользователя выполняется скрипт автозапуска.
Помимо прочего, скрипт автозапуска запускает скрипт Remote.sh. $HOME/.
config/openbox/scripts/remote.sh
#!/bin/sh
server_ip=$(/usr/bin/cat /etc/client.conf |/usr/bin/grep "server_ip" \
|/usr/bin/cut -d "=" -f2)
vdi_signal_port=$(/usr/bin/cat /etc/client.conf |/usr/bin/grep "vdi_signal_port" \
|/usr/bin/cut -d "=" -f2)
vdi_spice_port=$(/usr/bin/cat /etc/client.conf |/usr/bin/grep "vdi_spice_port" \
|/usr/bin/cut -d "=" -f2)
animation_folder=$(/usr/bin/cat /etc/client.conf |/usr/bin/grep "animation_folder" \
|/usr/bin/cut -d "=" -f2)
process=/usr/bin/remote-viewer
while true
do
if [ -z `/usr/bin/pidof feh` ]
then
/usr/bin/echo $animation_folder
/usr/bin/feh -N -x -D1 $animation_folder &
else
/usr/bin/echo
fi
/usr/bin/nc -i 1 $server_ip $vdi_signal_port |while read line
do
if /usr/bin/echo "$line" |/usr/bin/grep "RULE ADDED, CONNECT NOW!"
then
/usr/bin/killall feh
pid_process=$($process " spice://$server_ip:$vdi_spice_port " \
"--spice-disable-audio" "--spice-disable-effects=animation" \
"--spice-preferred-compression=auto-glz" "-k" \
"--kiosk-quit=on-disconnect" | /bin/echo $!)
/usr/bin/wait $pid_process
/usr/bin/killall -u $USER
exit
else
/usr/bin/echo $line >> /var/log/remote.log
fi
done
done
/etc/client.conf server_ip=169.254.24.1
vdi_signal_port=5905
vdi_spice_port=5906
animation_folder=/usr/share/backgrounds/animation
background_folder=/usr/share/backgrounds2/fedora-workstation
Описание переменных файла client.conf
server_ip — адрес KVM_сервера
vdi_signal_port — порт KVM_Server, на котором «сидит» xinetd
vdi_spice_port — сетевой порт KVM_Server, с которого запрос на соединение будет перенаправлен от клиента удаленного просмотра на spice-порт выделенной виртуальной машины (подробности ниже)
анимация_папка - папка, откуда взяты изображения для демонстрации ерундовой анимации
background_folder — папка, из которой берутся изображения для показа презентации в режиме ожидания.
Подробнее об анимации в следующей части статьи.
Скрипт Remote.sh берет настройки из файла конфигурации /etc/client.conf и с помощью nc подключается к порту «vdi_signal_port» KVM-сервера и получает от сервера поток данных, среди которых ожидает строки «RULE ADDED» , ПОДКЛЮЧИТЕСЬ СЕЙЧАС».
Когда требуемая строка получена, процесс удаленного просмотра запускается в режиме киоска, устанавливая соединение с портом сервера «vdi_spice_port».
Выполнение сценария приостанавливается до тех пор, пока средство удаленного просмотра не завершит выполнение.
Remote-viewer, подключающийся к порту «vdi_spice_port», за счет редиректа на стороне сервера попадает на порт «spice_console» интерфейса lo0, т.е.
на консоль виртуальной машины и работа пользователя происходит напрямую.
В ожидании соединения пользователю показывается фигня анимация, в виде слайд-шоу jpeg-файлов, путь к каталогу с картинками определяется значением переменной анимации_folder из конфигурационного файла.
Если соединение с портом «spice_console» виртуальной машины потеряно, что сигнализирует о выключении/перезагрузке виртуальной машины (т.е.
о фактическом завершении сеанса пользователя), все процессы, запущенные от имени авторизованного пользователя, завершаются, что приводит для перезапуска Lightdm и возврата к экрану авторизации.
Со стороны KVM-сервера
На «сигнальном» порту сетевой карты enp5s0 ожидает подключения xinetd. После подключения к «сигнальному» порту xinetd запускает скрипт vm_manager.sh, не передавая ему никаких входных параметров, и перенаправляет результат работы скрипта в nc-сессию Client Station. /etc/xinetd.d/test-server service vdi_signal
{
port
Теги: #*nix #stuff
-
Linux-Серверы: Понимаете Разницу?
19 Dec, 24 -
Прокачиваем Ваши Релизы
19 Dec, 24 -
Прошивка 2.00 Для Ps3 Выйдет 8 Ноября
19 Dec, 24