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

[Bernhard Reiter]

[This basically is the start of the samba Kolab Enhancement Proposal (KEP)]

On Friday 12 September 2008 21:56, Richard Bos wrote:
> > For Samba, this has traditionally be orthogonal to Kolab Server and was
> > integrated during project, because of the difference needs.
>
> I don't understand what  you want to say.  What do you mean?

Samba integration was done by several parties in the past. Usually as part
of a project for a customer or as integration into a special product,
e.g. Univention's UGS/UCS or Gonicus' Gosa.
Integration mainly meant integration into the directory server.
Kolab Server brings its own directory server, but customers tend to have their
own sometimes, so this again is a typical situation where Kolab Server has to 
be adapted to the existing directory server (may it be OpenLDAP or FDS or 
something else).

So my feeling is that customers may have different technicals needs towards
a directory service or a samba integration. In this case it might be a wise 
thing for Kolab Server not to offer a fixed integration, which might make it 
harder for someone to integrate their own, but offer the hooks only.
(This is what I call orthogonal, you could had or not add a feature to an 
installation, without interference of the Kolab Server (or minimal 
interference)).

This question is hard for me to decide: Am I improve Kolab Server by offering
an "example" Samba integration or am I making life harder for the majority
of users that would do their own integration anyway.
Not being an expert on Samba usage scenarios, this is where I would go 
next to make up my mind.

> > If we add
> > something to Kolab Server (and the Kolab Solution) this should cater
> > almost all reasonable needs and it should not add complexity for
> > non-samba users.
>
> The current patch has a switch that enables or disables samba support.  For
> kolab this means that 2 functions are added and some if statements to
> determine whether samba support is enabled.  If it is enables data is
> written to the ldap database.  The current patch does not add complexity
> for non-samba users, 

Sounds good so far.

> 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?

> 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?

> > 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.

> 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.

> Hopefully Albrecht wants to answers the questions.  Albrecht can you do
> that?

It would be helpful indeed. You could also start a wiki-page or so for the KEP
doing a summary. We can try to find out of Univention and Gosa would be helped 
by the change as well and approaching them with a summary wiki-page
or a comitted KEP would be helpful in doing so.

> From my point of view there are the following answers:
>
> 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.

> 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. :)
Bernhard
  

-- 
Managing Director - Owner: www.intevation.net       (Free Software Company)
Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com.
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.kolab.org/pipermail/devel/attachments/20080915/3edde4b2/attachment.sig>