Опыт применения свободного программного обеспечения для организации серверов удалённой загрузки в образовательной организации (OSEDUCONF-2024) — различия между версиями

Версия 20:42, 29 июля 2024

Докладчик

Перевод процесса обучения студентов на свободное программное обеспечение сталкивается с различными трудностями, в том числе связанными с необходимостью запуска на операционных системах Linux программ, разработанных для других операционных систем. Авторами было осуществлено развёртывание учебного компьютерного класса в режиме «толстого клиента» с загрузкой операционной системы из образа по сети.
Описываются особенности построения лабораторного класса с сетевой загрузкой гетерогенных клиентов, решение некоторых задач, возникающих при запуске на клиентах приложений в wine среде.
Проводится анализ сложностей, возникающих при аутентификации на клиентских машинах.

Видео

Презентация

300px

Thesis

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

При однородном «парке» машин, одним из вариантов является установка и полная настройка необходимого программного обеспечения на одной машине, а затем её «клонирование»^[1]. При наличии высокоскоростной ЛВС более выгодным может стать режим «толстого клиента». В качестве клиентских ОС были выбраны AstraLinux, Ubuntu и «Alt».

Создание PXE-образа толстого клиента и его запуск в точном соответствии с ^[2]^[3] выявили следующую неприятную особенность — Linux-ПО на клиентах запускалось за адекватное время, старт wine-программ выполнялся недопустимо долго — порядка полутора минут.

Пересборка образа для работы в режиме «Тонкий клиент» сократила время запуска до 15 секунд, но при подключении к серверу более трёх клиентов произошло сильное падение производительности.

«Полностью ручное» создание образов через стандартный для Debian-систем debootstrap завершилось у авторов неудачей из-за проблем с драйверами сетевой карты. От использования LTSP-инструментария пришлось отказаться из-за сетевой политики безопасности (частичной блокировки DHCP-трафика).

В итоге, сам образ был сформирован «родным» пакетом, а его «обвязка» написана вручную. Настройка обвязки потребовала ручной правки grub.conf, фрагмент которого принял вид:

menuentry 'Ubuntu 22.04'{
set i_name="Jeley-Fish"
echo "Loading $i_name kernel ..."

linux /jeley-fish/vmlinuzinitrd=ltsp.imginitrd=initrd.img 
      root=/dev/nfsnfsroot=192.168.1.20:/srv/tftp/jeley-fish ltsp.image=jeley.img

echo "Loading initramfs, Please, wait..."
initrd/jeley-fish/ltsp.img /jeley-fish/initrd.img
}

При работе в полученной системе для студентов наиболее непривычным моментом оказался факт, что все окна программ, запускаемых через wine, теряют статус модальных, из-за чего складывается ложное впечатление о зависании программы. Эта особенность наблюдается как для Astra с графической средой Fly, так и для Ubuntu со средой Gnome.

Для администратора особенность работы связана с wine. Wine создан его разработчиками таким образом, что для каждого пользователя Linux-системы он создаёт профиль (при необходимости и несколько профилей) в его домашнем каталоге. Создание для каждого студента отдельной учётной записи очень быстро истощает дисковое пространство сервера, поэтому мы ограничились одной учётной записью для всех студентов.

Ещё одна особенность связана с процессом аутентификации, точнее, с особенностями работы с паролями в Ubuntu и Astra. Просмотр shadow-файлов показал различную длину хэшей и использование разных алгоритмов хэширования с постоянной солью у Ubuntu и динамически изменяемой для Astra. Войти в ОС на клиенте можно только если сервер работает под управлением одноимённой ОС. Ещё одна сложность ожидается при добавлении к набору образов клиентов на основе ОС «Альт», в котором в /etc/shadow записаны строки только системных учётных записей, а для пользовательских аккаунтов создаются индивидуальные shadow-файлы в /etc/tcb.

Возможно, будет использован сервер аутентификации, подобно описанному в ^[4].

Перспективы дальнейшего развития проекта:

выполнить пересборку initramfs-файлов и сократить их цепочку до одного;
обеспечить единообразие хэширования паролей;
создать единый /home–раздел при работе с любым из образов;
организовать единый каталог wine-профилей для всех пользователей;
интегрировать данное решение в образовательную среду с вариантами обучения и оценки знаний.

640px

Примечания и ссылки

↑ Алексеенко С. П., Михайлова А. О., Оптимизация администрирования операционной системы Astra Linux при переходе подразделений ОВД на отечественное программное обеспечение // Охрана, безопасность, связь. 2021. №6—2. С.15—21. [1].
↑ Подготовка инфраструктуры PXE на Astra Linux. [2].
↑ Терминальный сервер LTSP (ltsp-server-standalone) на базе Astra Linux. [3]
↑ Даньшина А. В., Докшин А. Д., Ковцур М. М., Разработка сервера аутентификации на базе операционной системы Astra Linux // Региональная информатика и информационная безопасность. 2020. С.262—265. [4].

[1bs-1] Алексеенко С. П., Михайлова А. О., Оптимизация администрирования операционной системы Astra Linux при переходе подразделений ОВД на отечественное программное обеспечение // Охрана, безопасность, связь. 2021. №6—2. С.15—21. [1].

[2bs-2] Подготовка инфраструктуры PXE на Astra Linux. [2].

[3bs-3] Терминальный сервер LTSP (ltsp-server-standalone) на базе Astra Linux. [3]

[4bs-4] Даньшина А. В., Докшин А. Д., Ковцур М. М., Разработка сервера аутентификации на базе операционной системы Astra Linux // Региональная информатика и информационная безопасность. 2020. С.262—265. [4].

[1]

[2]

[3]

[4]

Материал из 0x1.tv