[Kroupware] Automatic server discovery

Tim Jansen kroupware@mail.kde.org
Wed, 25 Sep 2002 20:10:48 +0200


On Wednesday 25 September 2002 05:03, Brad Hards wrote:
> A suggestion that can probably help reduce admin load (and hence TCO) is
> automatic discovery of the servers (ie the kolab). This would mean that
> when the user first logs in, the kroupware mail client would issue a query
> for "smptd", and would receive the URI.  This could be done again on each
> login, or when the previous gateway fails (eg because the user is on a
> laptop, and moved to a different network).

First of all a service template must be defined for this, which can be quite 
complicated. You can not assume that there is only one SMTP|IMAP|LDAP server 
- in an enterprise may be more than one (for example for departments that use 
different technologies). So just searching for an IMAP server does not help, 
because you may get the wrong one, especially when you take your notebook and 
connect it in another department.
On the other hand, when you need to select a scope or some id like a workgroup 
or domain, it's not zero-config anymore. The only information about the user 
that is available for the query is the user's name. But only with the user 
name you can not retrieve the location of the server - SLP queries will not 
help unless you list the names of all users in the server's atributes (which 
does not scale).

AFAICS there are two ways to find a SMTP|IMAP|LDAP server without requesting 
further information about the user:
- use a server that allows the client to retrieve some workgroup or domain id 
from the username. LDAP could be used for this. The client can use SLP with a 
special service template to find this server, and then use the retrieved 
information for further queries that locate the right SMTP|IMAP server.
- require more information from the user when s/he logs in. Like you need to 
enter your domain when you log in on Windows, the user would then also need 
to enter additional information into kdm or similar login apps. If the user 
logs in using a 'traditional' mechanism, the first kde app that needs the 
extra-info would offer a extra-login prompt. When you use Kerberos, entering 
the domain (realm) of the user would be a good idea anyway.

Personally I would prefer the second solution as global Kerberos 
authentication is already on my todo-list...

bye...