[K12OSN] Student problem

[Mike Rambo]

RE: [K12OSN] Student problem
From: "Jim Kronebusch" <jim winonacotter org>
To: "'Support list for opensource software in schools.'" <k12osn redhat com>
Subject: RE: [K12OSN] Student problem
Date: Wed, 28 Apr 2004 15:25:08 -0700

Thanks Mike!  This is awesome info.  

Where do you set up access levels?  Or is this just describing theory of
how to set up each user with that type of access level?


Sorry it's taken so long to respond. Our mail server's hard drive died
yesterday. It's back up now but all incoming mail bounced since 4pm
yesterday. Looks like I might not even be subscribed anymore. I copied
this from the list archives.

Yes, I guess this was more a theoretical description of what we do. The
"access levels" are created at your whim to fit whatever access pattern
you want. All access is controlled by a combination of unix permissions
and samba controls (read list - write list). We wanted:

  students: member of users. Has read-only access everywhere except for
            public and other very specific folders (like AR data).

  staff:    building staff like secretaries etc. We use a generic share
            that is no-access for students but full access otherwise.
            It's like public except no student access. This defines
            those users who can access that share.

  teachers: we have one share that it has been decided the students
            need read access to but building secretaries do not need
            at all. Teachers can write lessons to this folder, students
            can read them, secretaries are no access.

  netmgrs:  Tech staff (both global in the tech dept and local building
            "network managers" can write at this level. This is mostly
            used by our dept to install apps to the server.

  sysadmin: These folks can do it all. They are members of root, wheel
            and all the above groups.

I've listed these in order of access level within our structure from
lowest to highest. Any user in a higher group is automatically also
a member of all other lower groups. Different shares are mapped when
the user logs on from the client depending upon their membership in
the various groups.

>From the client end we are still a very windows centric district. Even
though I have a set of scripts that manage user specific mounting of 
server resources at logon time with ltsp we presently do not use them. 
I don't know when (or if) we'll ever be able to move to any client 
other than windows.

I hope some of this helps. I can give you more of our setup but this
is already quite long in this forum. I have developed a script which
fully (or nearly so) configures our PDC's for us. We do the basic
install of the distro of choice and only need to make sure that it
includes samba version 3, dhcpd server, and bind, and that it has
a valid ip address on one interface and a valid hostname. The script
then sets up samba as a PDC (including automatic on-the-fly logon
batch file creation), dhcpd for our network, and bind for dynamic dns
(no zone transfers right now). The scripts may not be useful for you
directly but they may serve to explain how to go about some of this 
if you want to study them. Say so and I can make them available 
somehow.

Mike


-----Original Message-----
From: k12osn-bounces redhat com [mailto:k12osn-bounces redhat com] On
Behalf Of Mike Rambo
Sent: Wednesday, April 28, 2004 12:58 PM
To: Support list for opensource software in schools.
Subject: RE: [K12OSN] Student problem


On Wed, 2004-04-28 at 15:36, Jim Kronebusch wrote:
> I would like to add to the original question #1.  When making the drop

> folder you are only able to specify an owner and a group.  I am a 
> little frustrated with both OS X and Linux in the fact that you are 
> limited to only setting permissions for one additional group.  Problem

> is that I have a folder with the "student" group set to write only, 
> "root" is the owner with full privilege, now I want to give the 
> "teacher" group read/write privileges...oops...too bad...I can only 
> specify one group. Is this truly a limit with Linux or do the gui's 
> limit to only single group privileges.  On Windows I can specify 
> privileges for 15 groups if

Users can be in as many groups as you want. The thinking behind it is a
little different (instead of different groups having access to a folder
think of one group having access to the folder but users being in
multiple groups) but it allows you to accomplish pretty much the same
thing as with windows. Here's how we do it (as an example):

We have five general access levels with each one associated with a
group.

:level::primary group::secondary groups:
sysadminswheeladm,teachers,staff,users
netmgrsadmteachers,staff,users
teachersteachersstaff,users
otherstaffstaffusers
studentsusers-

By making a user a member not only of their primary group but also a
member in all groups below they will have access at their primary level
and below - or put another way...

Group NameUser Names

userjoe,cindy,susan,fred,john
staffcindy,susan,fred,john
teachersusan,fred,john
admfred,john
rootjohn

In the example above the user susan can have access to folders that are
owned by any of three groups. By using secondary group memberships you
can have the finer access control you are looking for. You do then have
the additional task of getting the users into the right groups.

We have come up with a system we call usersync that basically has a
master server downtown running some php scripts against a mysql backend
that generates all the things required to do user management for us on
all the local servers. When we add a system (new server) to usersync all
global users (syadmin,netmgrs and certain others) are automatically
added to the new server. Thereafter users can be added globally to add
them to all existing servers or can be added to just one specific
server. You may or may not need anything that elaborate. We have over 30
elementary buildings all of which are moving to linux pdc's (and some of
the secondary buildings may start moving to linux from win2000 in the
next year too) so we needed something like this. At the time we came up
with this ldap didn't appear to be as viable an option as it has become
more recently. The appearance of ACL's will have a bearing on this in
the future too.