защита от вандализма. Блокировка изменения настроек. ((вопросы применения ПСПО и Линукс в школах))

[Denjs]

Задача 1. сохранение-восстановление домашнего каталога пользователя.

Велосипед изобретаете.

идея хороша )
но, имхо, это половина решения. предположим, надо предоставить в гостевой учетке набор дополнительных ярлыков или преднастроенные конфиги программ. например почтовый ящик настроенный на учебный почтовый сервер - что бы поднатаскать учеников отсылать - принимать письма - но что бы все было в рамках локальной сети и не в интернет? или ещё что там и как?.

Мне все равно надо будет в подмонтированную tmpfs копировать из ранее созданного архива набор конфигов для тех программ котроые мне нужны. Т.е. мы все равно пришли к задаче 1 пусть и модифицированном виде?
есть идеи?

[/dev/random]

Мне все равно надо будет в подмонтированную tmpfs копировать из ранее созданного архива набор конфигов для тех программ котроые мне нужны.

Ну, для этой проблемы по ссылке решение есть - unionfs.

[Bizdelnick]

Этот велосипед всё равно придётся доизобретать.

Ладно. Вот тут лежит велосипед более совершенной конструкции: http://mirror.yandex.ru/mandriva/official/...10.0.noarch.rpm
Сейчас препарирую. Хотя по идее должен заработать на любом дистре.

Update. Вскрытие показало, что пакет родом из Федоры. На первый взгляд ничего дистрозависимого в нём не наблюдаю. У кого есть подопытный Альт под рукой - может потестить.

[BIgAndy]

Вот сейчас вот добрался до рабочей машинки и просто снял с ~/config/lxpanel/LXDE/panels/panel права (оставил 444), изменил настройки панели. Поработал в LXDE, завершил корректно сеанс, вошел опять - настройки панели первобытные (как до смены прав на коняиг).

Все используемые файлы, как понимаете можно посмотреть lsof'ом..

[BIgAndy]

Update. Вскрытие показало, что пакет родом из Федоры

Э-эм В федоре:

Код: Выделить всё

xguest
Arch       : noarch
Version    : 1.0.7
Release    : 5.fc11
Size       : 44 k
Repo       : updates
Summary    : Creates xguest user as a locked down user
URL        : http://people.fedoraproject.org/~dwalsh/xguest/
License    : GPLv2+
Description: Installing this package sets up the xguest user to be used as a temporary
           : account to switch to or as a kiosk user account. The account is disabled unless
           : SELinux is in enforcing mode. The user is only allowed to log in via gdm.
           : The home and temporary directories of the user will be polyinstantiated and
           : mounted on tmpfs.

[Bizdelnick]

В Мандриве:

unlike Fedora, where the account is disabled unless SELinux is in
enforcing mode and where it's only accessible through gdm/kdm/xdm, it's
accessible from the console too.

[/dev/random]

И что? Если gdm смущает, ...

Лично меня смутило бы это:

The account is disabled unless SELinux is in enforcing mode.

[BIgAndy]

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

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

А я как раз хотел сюда пригласить всех своих коллег с района (порядка 30 человек) - будет пилотная площадка.

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

У вас проблема двоякая. первая - минимизировать телодвижения по администрированию. (здесь я настоятельно рекомендую терминальное решение, скажем того же альта)

Вторая - заморозить все изменения пользователем интерфейса. По второй проблеме читайте, например, мой простой эксперимент с LXDE.

Лично меня смутило бы это:
The account is disabled unless SELinux is in enforcing mode.

Вы много знаете людей, котjрые во внутренних сетях держат селинукс в enforcing,а не в permissive (по умолчанию устанавливается в permissive) mode.

[watashiwa_daredeska]

идея хороша )

Людям и так RAMы не хватает, а вы тут ещё на tmpfs хотите оттяпать.

[/dev/random]

Лично меня смутило бы это:
The account is disabled unless SELinux is in enforcing mode.

Вы много знаете людей, котjрые во внутренних сетях держат селинукс в enforcing,а не в permissive (по умолчанию устанавливается в permissive) mode.

Вот в том-то и дело. Disabled unless (не if!) SELinux is in enforcing mode. Т.е. у большинства этот аккаунт будет отключён.

[Bizdelnick]

Вот в том-то и дело. Disabled unless (не if!) SELinux is in enforcing mode. Т.е. у большинства этот аккаунт будет отключён.

Исправил своё предыдущее сообщение, можете перечитать. Лично у меня никакого SELinux'а нет и не было, а эта штука работает.

Людям и так RAMы не хватает, а вы тут ещё на tmpfs хотите оттяпать.

Это проблема, да. Всё зависит от того, понадобится ли юзеру в домашней папке больше места, чем несколько мегабайт.

[BIgAndy]

Это проблема, да. Всё зависит от того, понадобится ли юзеру в домашней папке больше места, чем несколько мегабайт.

Это не проблема в случае терминального решения. Это решение снимет еще головную боль по администрированию ззопарка разведенных по разным помещениям машин. Плюс возможно поднятие небольшого кластерочка для распределения нагрузки. Хорошие терминальные решения (типа LTSP, альтового, например, ) требуют 20-60 Мб на пользователя. XDMCP -где-то 120-240 при стандартном офисном наборе программ.

[Denjs]

xguest ... SELinux ... Это все хорошо, это все по-уму)))
Я даже могу согласиться что установка пользователя с домашним каталогом настроенный кем-то а не нами самими (как я понимаю предлагается по сути в xguest) - это не так плохо как мне кажется.
(а кажется мне это плохой идеей, потому что набор программ хранящих настройки в домашнем каталоге - может различаться от дистрибутива к дистрибутиву - и попытка подготовки каталога пользователя в пакете - привязывает нас к дистрибутиву, что суть не есть гут)

Даже подозреваю, что использовать SELinux для настройки прав - суть хорошо.

Но теперь скажите - мне - в каких дистрибутивах для школ есть SELinux ?

В ПСПО5легкий я сего чуда кажется не наблюдаю. или скажите мне куда смотреть)

Вы готовы стать сборщиками и поставщиками нового модуля ядра для ряда систем??
(прошу поправить меня - SELinux - оно же как модуль ядра поставляется? в любом случае - нужна поддержка в ядре, как я понял из описаний )

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

Теперь вопрос сообществу - "нафига козе баян"? в чем профит SElinux в сравнении с вариантом блокировки доступа к конфигам через права файловой системы?
именно в нашем случае - когда нам не нужно хитростей типа "несколько ролей на одном пользователе"?

[Bizdelnick]

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

Вот уж набор файлов в zip-архиве заменить точно не проблема.

в каких дистрибутивах для школ есть SELinux ?

Повторяю ещё раз: он не нужен. В мандривовском варианте xguest всё работает без него.

[Denjs]

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

Вот уж набор файлов в zip-архиве заменить точно не проблема.

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

имхо, это очень не хороший вариант.

[Bizdelnick]

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

1,2 - что-то не наблюдаю я такого количества школьных дистрибутивов, это во-первых. Во-вторых, избыточность вполне допустима. В-третьих, поддержкой вполне могут заняться разработчики дистрибутива, если фича окажется востребованной. В-четвёртых, доделывать под конкретную задачу так или иначе во многих случаях придётся на месте...
3 - это разве не к задаче 2 относится? xguest только для первой подходит.

А вообще я Вас что-то перестаю понимать. Вы же это самое и предлагали:

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

[Voral]

Хм... отнюдь. Есть расписание звонков. Посему совершенно точно можно сказать, когда нужно ребутить ПК. Вполне себе адекватный вариант. Надо только составить правильное расписание с возможностью его менять. И что бы было одно, но на сервере. Дабы ПК брали его оттуда дружно. Это можно реализовать?

Конешно, можно. В кроне вполне можно наладить расписание соответствующее школьному. Есть пара подводных камней: часы компьютеров можно синхронизировать с серверами времени в интернет., если звонок кто то включает по наручным сам, то тут несинхронизируешь (хотя предоставить озможность давать звонки компу задача решаемая); например у нас в школе в младших классах звонки идут по своему (уроки короче). Впрочем, я думаю, эти проблемы не на столько критичные.
Как я понимаю нужен ГУИ т.к. скорее всего расписание желательно. чтоб мог поправить "простой" пользователь - преподаватель. С ходу я не нашел. А так же нужен скрипт который раскидает расписание по всем компьютерам. (Хотя тут логичнее другой вариант: каждый комп при включении забирает расписание с определенного сервера)

А я как раз хотел сюда пригласить всех своих коллег с района (порядка 30 человек) - будет пилотная площадка. Теперь вот и не знаю. Хотя, и не факт, что придут.

Ну если они готовы. Фильтровать полезную информацию от бесполезного переругивания. То можно. Но, но намой взгляд, если не ввести жесткого модерирования то просто окончательно "отпугнем" от всей этой затеи. Вот данная тема. Когда будет найдено решение. Кто то с такой же проблеммой зайдет и ему придется рыться в куче бесполезных постов не по делу.

[BIgAndy]

Как я понимаю нужен ГУИ т.к. скорее всего расписание желательно. чтоб мог поправить "простой" пользователь - преподаватель.

Зачем Гуй?

Код: Выделить всё

crontab -e

не подойдет?

Код: Выделить всё

С ходу я не нашел

есть, например в KDE в systemsettings, но человеку нужно что-то полегковеснее. Однако не вижу причин не использовать crontab -e. Удаленно же не буут лазить через гуй.

[Voral]

Зачем Гуй?

Код: Выделить всё

crontab -e

не подойдет?

Смотря кто будет править. Теоретически возможно это будет тот человек, кто вообще этим расписанием ведает и не факт, что он разберется в конфиге.

Удаленно же не будут лазить через гуй.

На 50 компах менять расписание удовольствие сомнительное. Надо синхронизировать или копировать с одного сервера.

[Denjs]

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

1,2 - что-то не наблюдаю я такого количества школьных дистрибутивов, это во-первых. Во-вторых, избыточность вполне допустима. В-третьих, поддержкой вполне могут заняться разработчики дистрибутива, если фича окажется востребованной. В-четвёртых, доделывать под конкретную задачу так или иначе во многих случаях придётся на месте...

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

3 - это разве не к задаче 2 относится? xguest только для первой подходит.

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

Не надо смешивать идею реализованную в xguest - шаблонный набор конфигов в домашнем каталоге в пакете распространяемом централизованно - и идею задачи 1 - распространяемую централизованно утилиту, которая может сохранять/восстанавливать домашний каталог.
В первом случае создатель пакета пытается думать "за потребителя", что гарантированно даст ошибку при попытке "применения на местах" (не техническую, а логическую - не соответствие цели и потребностям клиента), во втором случае мы можем действовать вне зависимости от дистрибутива и того что мы бакапим - мы поддерживаем практически любые возможные конфиграции домашних каталогов.

моё имхо/резюме таково: На выходе 2-й задачи, мы имеем настроенный и подходящий для пользователя образ домашнего каталога в архиве. Не вижу смысла связываться с xguest или вносить образ домашнего каталога в пакет.
Полезные идеи в xguest - "размещение домашнего каталога в tmpfs" и "механизм восстановления папок потребованию" - не являются подходящими (память все-таки лучше экономить) или существенными (копирование каталогов мы и без него сделаем).
Если же я чего не увидел в xguest - скажите мне.

В общем, имхо, это не тот велосипед который нам нужен. увы...

[minoru-kun]

похоже, что решение 2-й задачи невозможно без модификации программ.

[linuxfresh]

есть такая штука - http://www.webupd8.org/2010/08/ofris-deep-...cation-for.html (как пишется в описании для интернет-кафе), только для убунту (сам не пробовал)

[BIgAndy]

есть такая штука - http://www.webupd8.org/2010/08/ofris-deep-...cation-for.html (как пишется в описании для интернет-кафе), только для убунту (сам не пробовал)

Точно!!!
Ка я забыл! Решения для интернет-кафе - наиболее разумные для такой задачи! Без бубнов!.
В некотрых можно даже сохранять окружение постоянных пользователей. Вот толлько серверы должны быть помощнее.

[Denjs]

есть такая штука - http://www.webupd8.org/2010/08/ofris-deep-...cation-for.html (как пишется в описании для интернет-кафе), только для убунту (сам не пробовал)

Посмотрел.
Это sh скрипт который позволяет делать бакап каталога пользователя (в папку /etc/.ofris/ ) и восстанавливать его при загрузке.
Исходники я брал с http://sourceforge.net/projects/dafturnofris-id/

Это решение Задачи_1, но не полное. Требуется во первых перепривязать на релогон а не на перезагрузку, а во вторых переписать под школьные дистрибутивы (Alt, Mandriva, etc).

В варианте приведенном по ссылке - оно завязано на убунту - для установки автовосстановления каталога при ребуте использщуется скрипт /etc/rc.local , которого например нет в Atl. Исправил (вроде))).

Перевел (кодировка UTF-8) и подправил под ПСПО5/AltLinux. Файл в прикреплении.

Использование текущей версии (проверено под ПСПО5 от PingWin):
* Надо создать файл /etc/rc.d/rc.local которого нет по умолчанию. как тут сказано
* Добавить пользователя имени которого запускается скрипт в /etc/sudoers (полагаю разумнее переписать его чисто для использования от имени root?) - по умолчанию выполнение sudo для пользователей в школьных линуксах запрещено.

ВНИМАНИЕ! это рабочая промежуточная версия для дальнейшей разработки.

TODO: переписать под работу от имени root
TODO: добавить возможность прописывания автовосстановления каталога при логоне. (ещё один пункт меню?)
TODO: добавить автосоздание /etc/rc.local с заданными правами и "содержимым исполняемого скрипта", если его нет
TODO: ?: проверять версию дистрибутива и использовать разные файлы инициации (/etc/rc.local или /etc/rc.d/rc.local или др)

Прошу займитесь у кого есть время? я пока занят - будет время - буду дальше что-то писать.

[Skull]

* Надо создать файл /etc/rc.d/rc.local которого нет по умолчанию. как тут сказано

Может, не будете делать кривые велосипеды, а соберёте пакет и ознакомитесь с более правильными способами запуска?

* Добавить пользователя имени которого запускается скрипт в /etc/sudoers (полагаю разумнее переписать его чисто для использования от имени root?) - по умолчанию выполнение sudo для пользователей в школьных линуксах запрещено.

Не запрещено, а не настроено по умолчанию по соображениям безопасности.

P.S. Некомпетентная активность скорее вредна, чем полезна.

[Denjs]

* Надо создать файл /etc/rc.d/rc.local которого нет по умолчанию. как тут сказано

Может, не будете делать кривые велосипеды, а соберёте пакет и ознакомитесь с более правильными способами запуска?

Вот вы и подскажите?
Увы, я не понимаю как иначе понимать содержимое страницы rc.local вики на официальном сайте Alt-Linux.
А также комментарии внутри файла и последнюю строчку аль-линуксовского /etc/rc.d/init.d/local . В итоге я делаю вывод, что /etc/rc.d/rc.local - это есть прямое соответствие бубунтовскому /etc/rc.local . Я всего-лишь в лоб переписал скрипт предназначенный для бубунты. с сохранением всех авторских механизмов. И описал это в посте.

Есть замечания - мы все тут с удовольствием выслушаем мысли о том, почему логика автора из Индонезии, подходящая для Убунты, не подходит для alt-linux. если расскажите как это "надо делать" в Альте.
А лучше - исправьте и опубликуйте тут новую версию.
Критика должна быть конструктивна.

* Добавить пользователя имени которого запускается скрипт в /etc/sudoers (полагаю разумнее переписать его чисто для использования от имени root?) - по умолчанию выполнение sudo для пользователей в школьных линуксах запрещено.

Не запрещено, а не настроено по умолчанию по соображениям безопасности.
P.S. Некомпетентная активность скорее вредна, чем полезна.

А есть разница в итоге? результат от "запрещена" и от "настроена по умолчанию" - результат один: нельзя делать sudo.

____________________________________________
Господа) прошу, не надо бежать впереди паровоза!
не надо видеть в очередном шаге последний и окончательный шаг!

Там есть надпись -

ВНИМАНИЕ! это рабочая промежуточная версия для дальнейшей разработки.

то что мы тут делаем - это открытый процесс разработки и обсуждения. Каждый делает то что может.
Видите некомпетентность, ошибку ? не надо тыкать и глумиться. Надо рассказать как должно быть, если уж вы считаете себя более компетентным.
Не говоря о том, что все люди ошибаются.

Мы что-то пытаемся делать, а не сидим и ждем с моря погоды.
"Частное, пусть даже полуработающее решение от дилетанта лучше, чем отсутствие решения от аттестованного специалиста"

[sgfault]

TODO: переписать под работу от имени root

Может вместо рута создать отдельного пользователя и запускать от него?

[minoru-kun]

Есть замечания - мы все тут с удовольствием выслушаем мысли о том, почему логика автора из Индонезии, подходящая для Убунты, не подходит для alt-linux. если расскажите как это "надо делать" в Альте.
А лучше - исправьте и опубликуйте тут новую версию.
Критика должна быть конструктивна.

Везде нужно собирать пакеты.

[Denjs]

Успеем пакет собрать. Давайте сначала сделаем нормально скрипт, а потом уже будем пихать его в пакет.

TODO: переписать под работу от имени root

Может вместо рута создать отдельного пользователя и запускать от него?

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

В данной TODO-шке я фактически предлагал отказаться от sudo. а от какого пользователя запускать - от рута или спец-созданного думаю - дело вторичное.

[Bizdelnick]

Давайте сначала сделаем нормально скрипт, а потом уже будем пихать его в пакет.

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

Это как раз средствами rpm проще (и правильнее) всего делать. И если уж создавать отдельного пользователя (что имхо лучше), то можно без sudoers обойтись.