Author Topic: Messages/Events in Zentyal  (Read 2862 times)


  • Zen Apprentice
  • *
  • Posts: 1
  • Karma: +0/-0
    • View Profile
Messages/Events in Zentyal
« on: April 27, 2012, 09:22:50 pm »
Some discussion has been started on the possibility of using Zentyal as the basis for a new Edubuntu server for schools --

I manage the development of SchoolTool, which is a free student information system --

SchoolTool is used in a similar project -- the Critical Links Education Appliance, based on the EdgeBox -- where events in SchoolTool (adding users, creating classes) trigger messages sent to a proprietary integration service which propagates those changes throughout the system (adds the user to the OS level, Moodle, etc).

Does Zentyal have similar event and message handling services?

Of course, there are other ways to handle the problem or parts of it, including using LDAP extensively.


  • Guest
Re: Messages/Events in Zentyal
« Reply #1 on: September 25, 2012, 01:16:48 pm »
Bump on this topic.
The development of Schooltool has come to a point that LDAP integration is possible. This would make Schooltool an easy to integrate solution for a School administration system
More info on the LDAP plugin:

Especially the following excerpt: "...If you have installed Zentyal ( on the same server and configured Users / Groups modules, SchoolTool should be able to pick up LDAP settings automatically..."

Anyone willing to investigate this further? 


  • Zen Hero
  • *****
  • Posts: 795
  • Karma: +28/-16
  • RTFM!
    • View Profile
Re: Messages/Events in Zentyal
« Reply #2 on: September 25, 2012, 01:36:15 pm »
there is the zentyal framwork, that is event driven,  but in any case i would suggest to take a top-down approach if possible..   from my perspective meaning that  you create one master interface that is in controll and adding roles that comply to that structure, 

for example, what would happen if in schooltool you change the suer from groep a to group b for example when  %user%  is a slow learner...    will that also make him being in a diferent  OU (with difeterent GPO's),  a diferent classroom and diferent  default printers.

as zentyal is all about  managing a network,   from samba4 and proxy ranging to   email & jabber ccounts and  logon hour restrictions)...    creating  virtical user managenment could potentially only make things more difficult...   

note that im not a developer, but i would apreaciate mutch,  an approach that resembles some what, how  software like joomla, and wordpress are intergrated with loads of diferent  user management scemes,  from  internal mysql based, via  openID  to  Ldap and Kerberos... 

i would really like to seccond Robb's  bump, to see a discussion on how  the two can work together without  'one' intefering with the other's  'work'   
All tips hints and advices are based on my personal experience.
As I try my best to be as accurate as possible, following my advice is always at your own risk,
I claim absolutely NO responsibility in any way!


  • Guest
Re: Messages/Events in Zentyal
« Reply #3 on: September 25, 2012, 10:38:40 pm »
If I understood the implementation of schooltool.ldap correctly it isn't exactly reading from the LDAP tree directly. When a user in schooltool is logging in with an LDAP account, the account with all permissions etc, will be copied over from the LDAP tree into the user management of schooltool. So I don't think changes in schooltool will change anything for the rest of the network management.

Maybe Tom Hoffman can comment on this?

Just had a small chat in #schooltool and turns out that schooltool.ldap is only available for precise and up... so no ldap integration for zentyal 2.2 (at least, not now)
« Last Edit: September 25, 2012, 10:53:35 pm by robb »


  • Guest
Re: Messages/Events in Zentyal
« Reply #4 on: September 25, 2012, 11:07:54 pm »
I'm always very surprised to notice how all these guys developing solutions see LDAP as a protocol to be used in a private, non shared way, like if you were saying:
"well, I need to resolve names and IP. DNS protocol is perfect but I should deploy my own dedicated instance..."  impressive  >:( >:(


  • Guest
Re: Messages/Events in Zentyal
« Reply #5 on: September 26, 2012, 10:21:29 pm »
In this case (and maybe in many other cases) It might be not that bad to not 'mess around' with the LDAP database of Zentyal. In this case the own user database, as is all other data of the application, is stored in 1 big file called Data.fs (the backend is Zope)
What the plugin does is copying the credentials from LDAP to the own database and syncs it 1 way.

I see some advantages, like not making Zentyal more complex than it is already.

btw, The schooltool guys backported the schooltool.ldap plugin to lucid, so it is now available for Zentyal 2.x too. I did the install this afternoon and it works like a charm!

I will make a short howto on this soon.


  • Guest
Re: Messages/Events in Zentyal
« Reply #6 on: September 26, 2012, 11:01:21 pm »
Sorry if I react strongly, I hope nobody will misunderstand my point.

I never see any advantage in duplicating account repository.
Either your applicaiton can't speak LDAP protocol and then there is no choice, so duplicating is mandatory as a workaround or your application is LDAP aware and  duplicating as much more cons than pros, except perhaps if you rely on really weird LDAP repository that is too much customized and hardly linked to one application.
Look at AD: this can be seen as an LDAP server but its primary purpose is to act as back-end for Microsoft domain and related applications.
From my standpoint, LDAP in Zentyal, although not that proprietary, is quite close of this  :(
And Samba is already following same approach  >:(

Does it still make sense to maintain LDAP server and expose it as an LDAP server. Obviously no as there is very little you can do. In such case, better is to rush toward Kerberos for authentication and maintain your own repository. LDAP or not is your choice but this is a "proprietary" one.

For each application owner perspective, there is always only advantages in maintaining your own repository. Real problem is that is doesn't scale safely as you end up with tons of synchronization processes.