Re: [GOsa] Netgroups and ACL's
Am 07.05.10 16:30, schrieb Andreas B. Mundt:
Hello,
(cc debian-edu to allow for comments/discussion/additions)
On Fri, May 07, 2010 at 12:41:26PM +0200, Benoit Mortier wrote:
Le Friday 07 May 2010 12:03:00 Andreas B. Mundt, vous avez écrit :
On Wed, May 05, 2010 at 02:08:00PM +0200, Cajus Pollmeier wrote:
Am Mittwoch 05 Mai 2010 13:55:35 schrieb Gerrard Geldenhuis:
[...]
An email thread in April stated that Netgroups were not supported.
Is that a "not yet" or is the view that you can achieve the same
result by using ACL's.
They are not supported means: if someone has time or wants to start a
payed project, netgroups are "not yet" supported ;-)
[...]
you can find an experimental hack (probably horrible for someone who
knows php) to add "some" support here:
http://lists.debian.org/debian-edu/2010/04/msg00124.html
[...]
- First there will be a GOsa² in squeeze, currently working on it, it will
be 2.6.10 i think
- Second i'am interested in making GOsa² work with skolelinux could you
enter a whislist in the gosa tracker with a you findings and explaning
what should be done
- Third of course you are welcome on the #gosa on freenode to discuss
it ;-)
Hello Benoit,
first, I am really happy about you offering support! (I've seen you are
involved in the debian ldap package aswell: #512360, so that's exactly the
competence we need here :)).
Not beeing Benoit, I hope I'm allowed to answer, too ;-)
Perhaps I start with describing the current situation from my point of
view (others please add/correct what's missing or I got wrong):
In debian-edu lenny we use lwat for administration of the System. Lwat
has been written especially for skolelinux/debian-edu, this means it's
targeted at the basics you need to add/remove users (students and
teachers) (posix-) groups and machines. The machines have to be added
to LDAP to use their (static) IP addresses for access control.
The major advantage of LWAT is it's simplicity: At many schools there
is a teacher who rarely knows about ldap at all and is easily
overwhelmed by hundreds of attributes and features. (The "job" has to
be done often by maths-, or physics- teacher because their colleagues
from history or languages expect them to understand technology best).
So there is no professional sysadmin, and the teacher's standard
workload is reduced by one or two hours per week if reduced at all,
i.e. he cannot spend much time learning how to get the system
started. (And school starts already just after the vacations... ;-) ).
Unfortunately LWAT seems to retire upstream as well as in debian:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=578345.
For sure this can be fixed (again), but I already spent some
amount of time and energy on LWAT and by now prefer to put this time
into something that promises more returned value in the long run.
At this point GOsa² comes into play. So far, I tried to kind of "strip it
down" to the basics needed at school. I did this by simply not
installing plugins or commenting them in gosa.config. I guess user and
group management should work out of box, what's missing compared to
LWAT is the machine management: We can assign netgroups to machines:
For example when a machine is member of the "shutdown-at-nigth"
netgroup, a script halts that machine in the evening. More important
netgroups allow mounting the home directory etc. Currently this is
essential, therefore the hack mentioned above.
The good news is, as pointed out by Petter (
http://lists.debian.org/debian-edu/2010/05/msg00025.html ) that this
might not be needed in the future where we plan to use kerberos.
Of course grouping of machines would be nice, to define
"shutdown-at-nigth" and "fsautoresize"-hosts. (I would expect that
something like that is already somewhere in gosa, but perhaps in
combination with a hundred other features :( ....).
In combination with gosa-si, you can plan shutdown, wakeup, reinstall,
etc. tasks for your workstations and group of workstations.
GOsa allows bare metal installs for FAI and OPSI based installs
(preseed|autoyast|kickstart + puppet comming soon). The "GOsa style"
process is like this:
* Unpack your hardware, place it somewhere and plug it into the network
* Start the machine, configure it for network boot
* Network boot will not work, because the system is not known to GOsa
and will not get anything via tftp (works in combination with fts)
* gosa-si's arp module (or the contributed dhcp hook) detects a new
machine and adds it to ou=incoming in your LDAP as a new system
* GOsa shows it in the system tab. Assign it some IP and a DHCP
section, assign it a FAI or OPSI profile, press OK. It's in DNS
and DHCP now. And it has a deployment profile.
* Reboot the new system and wait some minutes until it is installed
and ready for use.
To be continued:
* The user you're using to log into your new system has some
group membership. This group may "environment" settings,
containing a predefined Desktop profile, startup scripts,
shares to be mounted, Startmenu and Desktop Icon definitions
and printer assignments.
* Log in, wait for some magic and you've a fully configured,
ready to work system.
That's more or less the full story of deployment like we use it for the
LiMux project. You can handle all the stuff differently, but that's
the way it is meant to be.
There's one problem: because things can be done different (and are done
different from usecase to usecase), it is not straight forward to set
this up. I tried to push this on a DVD some time ago, but the stuff on
the DVD is completely outdated.
Many features GOsa² offers are probably not needed, ACLs, References,
Environment, I guess that gets too complicated and confusing. (Can
these tabs be "switched off"?). Our (little) users usually just change
their password :). (I think there is a junior-admin group currently with
limited admin rights, but that's all). As Holger pointed out on IRC a
some days ago: fai might be interesting: install a package on all
machines...
Almost all tabs you can find in GOsa are configurable in your gosa.conf.
So you can remove features there if you want. You cannot remove the
first tab - it is the so call base plugin. It takes care for object
creation and hosts the structural objectclass.
What you can't switch of are References and ACLs. ACLs can be used to
configure what a user is allowed to do - or can see. In order to switch
of complete tabs without editing the gosa.conf, you can just remove the
access rights for that. ACLs also allow you to define different roles
(which you definitively have), like "skilled admin", "not so skilled
admin", student, etc. If you setup ACLs correctly, you can just point
your students to password.php instead of index.php and they're able to
change passwords - i.e.
If you've no permission to edit ACLs, the ACL tab is away - while
references is still visible. It shows the relationship between the
current object and others (i.e. groups).
There are probably some more ideas and thoughts around- please add
them (I am involved with the project for not too long and there are
many with much more experience and knowledge).
Ok, so far; I hope I could draw a picture what's currently needed and
planed. Do you think GOsa² makes sense for us and can be adopted for
our needs?
I'm not directly asked, but it seems fits well into what you want to do.
To finish, a concrete question concerning the various passwords in ldap
(posix, samba, kerberos): How is the synchronization usually done,
with scripts, ldab overlay (smbk5pwd), or can gosa help here too?
GOsa synchronizes posix and samba passwords by default. You can extend
it by adding new password methods. You can add hooks that allow the call
of external password changers or policiy checkers. You can manage krb5
based domains in combination with the gosa-si service.
Hope that is going to answer some of the questions - if not, just let me
know.
I personally like would be happy to see GOsa popping up somewhere in
edu/skole. What I can offer right here would be a GOsa session somewhere
at the linux tag in Berlin where I can show some of the stuff explained
above. And maybe some GOsa 2.7 preview and things some very cool new
features beyond 2.x series.
Cheers,
Cajus
Reply to: