Comments 17
Добрый день! На сколько вероятно появление версии под Moodle ?!
Вариант использоват web-клиент ssh не продумывался? Мороки наверное больше, зато универсальнее и не нужно компилировать под каждый вид систем.
Полистал. С душой, копнули во многих местах глубоко. Даже виден перфекционизм в определениях. Поэтому хочу придраться к парочке мелочей
Команда return позволяет задавать возвращаемый функцией целочисленный код завершения
function myfunc {
read -p "Enter a value: " value
echo "adding value"
return $(( $value + 10 ))
}
Тут нужно помнить, что $? это код возврата, и по стандарту это один байт. Поэтому числа больше 255 будут делиться на 256, пока не получится число меньше. При return 256 получите 0, а 257 - 1.
Еще в презентациях много слайдов дублится.
В остальном - очень добротная работа
Возможно, вы ловили себя на мысли, что было бы неплохо провести для коллег-новичков в Linux небольшой курс с практическими задачками.
Мне такая мысль пришла 36 лет назад в 1987 году. Тогда не было Linux, но был Unix, который дал и попспособствовал появлению Linux.
Такой курс мне тогда удалось реализовать рубрике «ИНЖЕНЕР И КОМПЬЮТЕР» во всесоюзном журнале «Техника и наука»:
Первой публикацией в этой рубрике была статья в №7 журнала с названием «Операционные системы: зачем они инженеру».
Наиболее актуальной задачей в те годы было освоение различных редакторов:
В цикле публикаций планируется рассмотреть вопросы, связанные с организацией взаимодействия пользователя с системой, подготовкой документов, созданием информационно-справочным систем, электронной почтой, программированием на языках Фортран, Паскаль и Си. Предполагается также рассмотреть вопрос переноса ранее разработанных вами программ на языках Фортран и Паскаль для ОС ЕС в систему ЮНИКС для дальнейшего их использования.
Сегодня, конечно, другие приоритеты.
Спасибо, интересная статья. Кстати, я бы не сказал, что цель ваших публикаций сильно отличаются, от этого курса. Взаимодействие с ОС, подготовка текстовых документов, программирование - эти цели курсов совпадают. Отличие разве что в том, что раньше автоматизацию писали на компилируемых языках вроде Паскаль, а сейчас задачи стараются автоматизировать скриптовыми языками, вроде Bash.
Bash я тоже использовал и использую. Более того в книге "Мобильная операционная система МОС ЕС", изданной в далёком 1990 году, в разделе 2 "ПРОГРАММИРОВАНИЕ НА ЯЗЫКЕ SHELL" мы даём именно ту рекомендацию, про которую вы пишите — "автоматизировать скриптовыми языками, вроде Bash":
Задумка очень хорошая и, главное, кстати! Но воспользоваться, увы, не смогу. Опишу основные мои претензии как преподавателя, читающего курс по администрированию Linux в местном универе.
Самое интересное - task_checker, так что начал с него. Слегка удивлён, что там сишный код. Ожидал увидеть что-то более высокоуровневое, но да ладно... Во-первых, тест-кейсы задаются прямо в .h файлах - хотелось бы более декларативного описания заданий. Во-вторых, опциональный экспорт в LMS в этом же каталоге - мне кажется, что это всё-таки отдельная сущность. В-третьих, ИМХО, проверка должна быть не интерактивная - проверять сразу всё; не нашёл - проблема студента.
В моём понимании чекер должен быть каким-то docker-образом, куда монтируется каталог студента и проверяются захардкоженные файлы. Я думал сделать на pytest - там можно легко перехватывать stdout и сравнивать с ожиданием. Правда, в моей специфике чекер будет ещё проверять ФИО студента, наличие ssh-ключа и проверку shellcheck.
Спасибо за ваш интерес к курсу и отзыв! Язык C используется, потому что хотелось сделать исполняемый файл, который сразу можно запускать без наличия интерпретаторов, docker'а и прочего. Плюс к этому исполняемый файл не так просто декомпилировать, поэтому студенту проще сдать честно, чем пытаться обмануть проверяющую систему. По поводу опционального экспорта - можно собрать task_checker без интеграции с LMS (если я вас правильно понял). Третий пункт немного спорно, когда я вел курс, некоторые слушатели сказали, что практика сложная и заставляет изрядно понервничать, когда что-то не получается. Если бы подсказок не было, то была бы вообще беда. Но можно добавить переменную окружения, которая позволит собирать версию без подсказок
По поводу чекера в докер-образе в вашей реализации, можно поподробнее? Откуда студент берет образ? Кто монтирует каталог и запускает образ, студент или преподаватель?
Мои студенты сдают зачёт на отдельной купленной VPS. Я там создал кучу пользователей с паролями, собственно, сам её и админю. Так что могу позволить себе собрать образ и позволить запускать его из make. Лично мне так проще - оверхеда ноль и полная переносимость (т.е. тестирую я локально).
К тому же докеру посвящена примерно треть курса: от "что это такое" до cgroups/namespaces/layerfs, так что на одном из занятий планирую чтобы они сами с помощью dive раскопали как происходит проверка. Может, успею пасхалку какую на самозачёт положить, чтобы воспитать дух хакерства :)
Ну, декомпиляцией я ещё на первом курсе занимался, когда крякмишки ломал. SoftICE, IDAPro... В данном случае должно быть не сильно сложно, т.к. строки для проверки вставляются в секцию .data и лежат как plain text.
В этом плане да, но согласитесь декомпилировать все же сложнее чем, открыть скрипт на python, увидеть какую API ручку нужно дергать, и через какой-нибудь постман сдать сразу весь курс
Открытой системе — открытый курс: автоматизированный Linux курс для корпоративного обучения