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

Ссылки сюда (1) →

Короткая ссылка: 20240630F

Докладчик

• Сергей Быковский
• Рустам Халабия

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

Описываются особенности построения лабораторного класса с сетевой загрузкой гетерогенных клиентов, решение некоторых задач, возникающих при запуске на клиентах приложений в wine среде.

Проводится анализ сложностей, возникающих при аутентификации на клиентских машинах.

Видео

on youtube

Презентация

Thesis

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

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

Создание PXE-образа толстого клиента и его запуск в точном соответствии с выявили следующую неприятную особенность — 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.

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

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

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