Re: [GOsa] Netgroups and ACL's
Le Friday 07 May 2010 22:13:18 Cajus Pollmeier, vous avez écrit :
> 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 ;-)
No you are not ;-)
> > 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:
i would add that GOsa² integrate with LTSP5 who is running here in several
> * 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
The dhcp hook is helpfull when you have multihomed network machines and
you want the correct machine / ip / mac to appears in GOsa²
> * 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.
we were discussing those day on irc to create an autofs plugin to use the
classical autofs.schema as there seem to be a demand for it.
> * 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.
We use it at several place to do clusters deployement, desktop deployment,
LTSP5 integration and it works quite well is solid and tested
> 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.
yes the biggest issue today is the documentation, there is an effort
currently going around it.
> > 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
yes, i agree to, i meet some people of the debian-edu / skolelinux last
year and showed them GOsa². Those day i think it's the best software for
> > 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.
i already arranged a meeting for the fusioninventory project at linuxtag
and i put a doodle here, so you can register and we can have a big meeting
around GOsa² at linuxtag ;-) and i can show you we we do with it ..
OpenSides "logiciels libres pour entreprises" : http://www.opensides.eu/
Promouvoir et défendre le Logiciel Libre http://www.april.org/
Contributor to Gosa Project : http://gosa-project.org/