[Kolab-devel] Samba KEP (Re: Enhancing Kolab decision making(re: Is it okay to commit the samba patch to cvs?))

[Richard Bos]

Op Monday 15 September 2008 10:54:10 schreef Bernhard Reiter:
> > it actually takes care that the same password can be
> > used for kolab and samba (MS) logins, providing single sign on, which is
> > a good thing if you ask me.
>
> Usually it is, but using weaker password algorithm on samba would lower
> security and raise requirements for any directory service too to write both
> passwords right? Do all Samba installations requires this NT password or
> could they go without?

With the samba patch, a password strongness check was added as well.  It has 
been moved to its seperate issue, but the samba solution is in this aspect 
better than kolab....

> > Everything else related to samba is AFAIK done with another GUI.
>
> This sounds suboptimal. If I have a web admin which basically is a
> directory service client, why not handle Samba with it as well?

That's true, but this makes it possible to first adapt the server and after 
that adapt the GUI is needed.

> > > Discussing this is not trivial and goes beyond the code itself.
> >
> > You're making me curious, please elaborate.
>
> The next point is one of the target group for Kolab Server users.
> Any IT solution, just like Kolab or a competitor will not conquer the
> market in one go. It better to first target specific markets.
> So the question is: Will adding a feature (like Samba) help us to conquer
> the next market we would want to go for with Kolab and its Server?
> Samba integration seems to be possible so the problem is not keeping
> anybody from "buying" Kolab Server.

But now at least 2 people needs to patch, and patch, and patch kolab to 
provide kolab support.  It shows that there is a desire to have kolab support 
samba.

> > If I get the approval to commit the patch, I'll commit it.  But I need to
> > get the approval first.
>
> Yes, somehow we need to beef up the decision process.
> It also need to help us make up our minds about what do decide first.
> I wrote about the decision process in my other email, this one is about
> Samba.
[............]
> > 1) Implications: the kolab team must support more code.  New ldap schemas
> > are included.  No idea whether that is a problem or not.
>
> Any more code is adding weigth which is bad it inself, the question is
> what we gain from it and how deep it is coupled.

It prevents that at least 2 people need to patch kolab with every new release.  
Is 2 people the top of the iceberg or not?

> > More ldap attibutes are stored in ldap which could be accessed
> > if the ACL is not correct.
> >
> > 2) It provides SSO (single sign on), which is very convenient for users.
> >   Hence making kolab even more attractive for companies :)
>
> How compatible are we with the several ideas of SSO and the applications?
>
> > I hope this is a start to come to a decision about samba support in
> > kolab.
>
> It certainly is, so thanks for progressing it. :)

I don't have the feeling that we are progressing at all with the issue at hand 
(2997).  It looks like that we need to develop a KEP, invite Univention and 
Gonicus to the table to ask for their view on samba integration with kolab.  
While all the folks that are working on issue2997 want to have their code 
integrated into kolab (I think).  I understand that a process is needed, but 
it's not something that I and I think Albrecht are going to setup and 
foster...  Now is the kolab core team going to setup a samba KEP and see if 
it works by e.g. getting Univention and Gonicus to provide information to the 
samba KEP.  I'm afraid that this is going to result in a dead lock situation 
situation, in which the issue2997 attributors must work out a KEP and the 
core team must setup a KEP.  In the end nothing would happen, which would be 
a pity as the current samba patch is quite nice!


-- 
Richard Bos
We are borrowing the world of our children,
It is not inherited from our parents.