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

[Gunnar Wrobel]

Quoting "Bernhard Reiter" <bernhard at intevation.de>:

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

This sounds a little bit as if the suggested KEP process does not  
distinguish between a structural enhancement and an extension. I see  
that as an important difference.

If a KEP could suggest enhancing the Kolab Server with a specific  
application as an addon (e.g. the Open Ticket Request System (OTRS) or  
Munin as a monitoring tool) then the Kolab Konsortium would always  
have to ask: Does this have significant market value? Do we really  
want to add it? For any additional application additional testing is  
required.

But adding such extensions to the Kolab Server is already possible  
today. An experienced user could build OpenPKG extension packages  
(even if nobody does it yet and I consider this still way too  
complicated - but that is not the point here). So for such extensions  
I don't see the need for a KEP process as anybody could build and  
distribute packages without additional overhead.

But I consider KEPs relevant once we talk about structural changes to  
the core Kolab Server in order to *enable* specific additional  
extensions. This is of course the case for Samba. This is in fact a  
very good example of that. Adding this functionality won't be possible  
without some general hooks in the server that allow such an extension.

Do people agree that we should keep the focus for KEPs like this?

Cheers,

Gunnar

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



-- 
____ http://www.pardus.de _________________ http://gunnarwrobel.de _

E-mail : p at rdus.de                                 Dr. Gunnar Wrobel
Tel.   : +49 700 6245 0000                         Bundesstrasse 29
Fax    : +49 721 1513 52322                        D-20146 Hamburg
--------------------------------------------------------------------
    >> Mail at ease - Rent a kolab groupware server at p at rdus <<
--------------------------------------------------------------------


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.