[Kroupware] FAQ: flexible administration of multiple kolab servers

[Brad Hards]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, 30 Sep 2002 17:42, Martin Konold wrote:
> On Monday 30 September 2002 09:13 am, you wrote:
> > > For clients like OL/Bynari this is unfortunately non trivial.
> >
> > SLPv2 would be much nicer, except you can't modify the client to support
> > it.
>
> Yes, I agree but will SLP work in non LAN environment like dial up
> internet?
As good as DNS, probably.

> And of course on the other hand I am not so keen on hacking OL to
> understand SLP ;-)
This is why I stopped pushing SLP so hard. Of course, the right abstraction 
should make it transparent as to the service discovery technique. So you can 
just plug in whatever system makes sense.

> Yeah, I am ware of these vocal minorities. Actually they simply can use
> another technique. Basically I want to document a possible solution to the
> problem.
It'd be nice if another technique was easy. But I don't see it. But just allow 
for it with an abstracted function: get_my_imap_server_ip(), rather than hard 
coding in gethostbyname(). Even if it just a wrapper.

> > > Basically we add for every account an A record in DNS which is pointing
> > > to the correct kolab server.
> >
> > A record is not so nice.  You probably wanted to create CNAME records.
> > Otherwise you need to change one A record per user if you have to change
> > the IP on the machine. If you just have CNAMEs for users, you only need
> > to change it once.
>
> This is indeed a vaild point. Which kind of disadvantages do I have to
> expect when using CNAMES? What about SMTP?
I don't think that there will be any. Most people already use CNAMEs to point 
to major servers, including POP3 and SMTP. Your ISP probably does this.
sendmail is probably the worst case. It doesn't like to see CNAMEs on the 
right hand side of a MX record, and may not strip off the right parts. This 
usually leads to mail looping. But presumably you weren't planning to use 
those records for MX anyway, so it won't matter.

> > If you have client support (probably not), you can use SRV records
> > (SRV2052), maybe even in conjunction with PTR records (see
> > http://www.dns-sd.org for an old Internet Draft). This is basically what
> > Apple Rendezvous does.
>
> Yeah, http://files.dns-sd.org/draft-cheshire-dnsext-nias.txt looks
> interesting. Do you know anything about the current status? (The draft did
> already expire)
Apple shipped something like this in OS 10.2. There is some programming stuff 
on their website (http://www.opensource.apple.com - I can't get a better URL 
right now), including the API and some explanation that is a lot clearer than 
the I-D.

> > > 2.  In addition the administrator can much more easily move users to
> > > different servers in a transparent manner.
> >
> > With Dynamic DNS, you can do this automagically from the LDAP server.
>
> Please elaborate.
Presumably you have one or more LDAP attribute for each user that says "this 
user is hosted on this server" (or "the IMAP server for this user is <some 
server>", whatever).
You don't want to have to hand manage all those DNS entries (for a start, the 
zone files will be enormous). Now you could have a routine that runs through 
the LDAP records, extracts the necessary records, and builds the zone files, 
which you then copy across to the DNS server.
But you could just have a LDAP rule (I think, my LDAP is very marginal) that 
says "when this record changes, delete old CNAME, and add new CNAME", using 
dynamic DNS (RFC2136). The command line tool that comes with bind is called 
"nsupdate" (you might need to use expect, since it is normally interactive). 
It's man page has a couple of examples, include one of manipulating a CNAME. 
Is this clearer? If not, I'll try to work up some specific examples (I'll 
need to set up BIND first, so it will take a while...)

Of course, the user->server relationship doesn't need to be in LDAP - any 
database will do. I just imagined LDAP because of the kolab design.

HTH

Brad 
- -- 
http://conf.linux.org.au. 22-25Jan2003. Perth, Aust. Tickets booked.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE9mAr5W6pHgIdAuOMRAs36AJ4jI89UCIjp+Q83dP6P+9Nma1ARrQCePP31
R87i538IjhT7t4NvoVvqcSU=
=EIg1
-----END PGP SIGNATURE-----