Mailinglist Archive: opensuse-edu (56 mails)

[Jeff Shantz <jeff.shantz@xxxxxxxxx>]

Hi Lars, James, all,

On Wed, 2009-05-06 at 09:36 +0200, Lars Vogdt wrote:

> I'm sorry, but I don't think we need this. I know that James always  
> "figthing" against our existing patterns (sometimes he tells me he's  
> not seeing them at all ;-) but I think we've covered this area already.

I think we need to come to a consensus on the mandate and aim of this
module.  I apologize in advance that this is going to be a long-winded
post, but I want to put all the cards out on the table.  The discussion
seems to be going all over the place, and everyone has their own ideas
of what this module should be (I have had numerous emails off-list in
addition to your comments, James and Lars).  I want to manage
expectations and try to nail down exactly what people are looking for.

The original goal of the module, as described to me by jdsn (and as
documented on the wiki at http://en.opensuse.org/YaST_Education), was
to:

* Create/edit/delete users and assign them to "edu-groups".  As jdsn
mentions, "what groups are handled as edu-groups is defined in the
edu-users sysconfig file. Only these groups will be displayed, only
users of these groups can be created, edited and deleted."  As noted in
my last post, I believe that one should also be able to create custom
edu-groups from within the Education module.

* Assign Sabayon/Kiosk tool templates to these edu-groups.  The module
does not handle the creation/editing of said templates, but only allows
existing templates to be assigned to edu-groups.

* Configure a transparent proxy and Internet filter, if desired.  As
James pointed out, this should not be forced on the user (since they
might already be doing site-wide filtering), but should be an option.
My plan is to develop another module for configuring
Dansguardian/Squidguard that the parent/teacher could then later use to
configure filtering.

* Configure firewall settings for each group, if desired.  I envision
this as a list of well-known applications where the user can
check/uncheck entire groups (e.g. Chat programs) or specific
applications (e.g. Pidgin).  The module would then handle blocking the
appropriate ports in the SuSE firewall.

Okay.  That was the original aim for the project.  Now, some suggestions
I have received, in no particular order:

* Doug Glenn suggested the ability to import a list of students from a
CSV file, for example.  The module would then create these students,
saving the administrator from the menial task of having to create them
one by one.  I like this idea, and it's simple to implement.

* Doug also suggested the ability to allow non-root users to use the
module.  For instance, if I'm a school administrator, I might want to
give a teacher the ability to control the computers in his/her
classroom, but I might not necessarily want to give him/her root.  This
is certainly a nice to have, but gets a little hairy when we have to
deal with configuring firewall rules as a non-root user, etc.
Nevertheless, there could be a "root" mode to the module, as well as a
"teacher" mode.

* Lars suggested the ability to assign schedules to various groups,
allowing hours of usage to be restricted, and ensure that kids can't use
the computer past their bedtime. :)  I think this is extremely useful,
at least in the home domain.

* Lars also mentioned the ability to send a report to the parent/teacher
stating the web sites that were blocked.  I think this falls under the
Dansguardian module that I would be developing, and would certainly add
that functionality to that module.

* James has suggested that the module should actually install specific
software applications according to pre-defined groups, and should allow
the configuration of desktop software vs. server software.  My feeling
on this is mixed.  On the one hand, I see what Lars is saying.  By
having the module install software, we're infringing on the domain of
sw_single and the software patterns that have been created for the
Education CD.  Furthermore, if sw_single is run in the installation
workflow, and the user selects packages and patterns to install, is it
not then confusing to have the Education module ask again about software
patterns that should be installed?  I would be sitting there thinking,
"I just selected my patterns a few minutes ago, why are you asking me
again about what software should be installed?"

On the other hand, sw_single is not necessarily very user friendly for
users with limited openSUSE knowledge and it would be good to have a
simple wizard that would allow someone to specify, "I want to install
applications appropriate to elementary school students" and those
applications would be automatically installed.  

My feeling here is that this is important to have as a separate module
in the installation workflow, as Lars suggested, but I don't think it
fits with the vision of the Education module (perhaps Education module
is the wrong name?).  I view the module as a "I've installed my system,
made my software choices, and now I want to lock it down" type of module
-- one that runs late in the installation workflow (e.g. after reboot).
I realize this is going to be a point of contention, but let's discuss
this further. 

Lastly, James, you indicate your interest in focusing on the school
first, and home second.  Lars, you feel it should be the other way
around.  I think we're just arguing semantics here.  My feeling is that
we can satisfy both domains with the features I have laid out above.
These domains are, by no means, mutually exclusive. The same basic needs
are there: controlling what applications can be run, what protocols can
be used, and what sites we want our kids to be visiting.  

Alright, sorry for the novel.  Have at it, pick my ideas apart. :)

Jeff

-- 
To unsubscribe, e-mail: opensuse-edu+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-edu+help@xxxxxxxxxxxx