Server fqdn change

[Andrew J. Kopciuch]

>
> I guess the old domain should be kept. Renaming all the users does not
> make too much sense as that also affects the data stored in IMAP. Its
> easier to solve that by using aliases.
>

Not to mention the breakage of the mail itself.  The mail spool is stored on 
disk under the domain.  That would have to be moved, and I have no idea about 
the side-effects of that.

You already mentioned the ACLs stored in IMAP, which would also be broken.  
There's also the sieve and freebusy information that would need to be moved, 
and I'm also not sure about any data changes required there.

To throw another wrench in the mix, imagine multiple slaves?

There are several pieces that are tied to the FQDN, both in LDAP, and on disk.   
It's not a trivial thing to change the FQDN.

Aliases could instantly provide a new email address, but the UID would still 
remain under the previous domain (if you just used the default UID ... which 
I assume most people would).

I realize I am not providing much help here, but my brain is flying in all 
directions thinking about what a FQDN change would require.  Large 
installations would be a massive amount of work.

We all seem to be making points in theory.  I am wondering if there is anyone 
out there who has actually done this before?   They might provide some 
insights.

The only client of mine to go through a domain change, was moving 
co-locations, and rebuilding servers all at the same time, so we just built a 
new server under the new domain, and created aliases for the old domain if 
needed.  So we avoided doing this sort of thing in place.

:S


Andy

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.kolab.org/pipermail/users/attachments/20080929/95bcea49/attachment.sig>