[Kolab-devel] State of the Wiki
Jeroen van Meeuwen (Kolab Systems)
vanmeeuwen at kolabsys.com
Thu Sep 9 13:27:12 CEST 2010
Thomas Arendsen Hein wrote:
> * Jeroen van Meeuwen (Kolab Systems) <vanmeeuwen at kolabsys.com> [20100908
> > > Just tell me the IP, I'll add it to the DNS.
> > 22.214.171.124 should suffice. I propose that if we migrate over the
> > database we also start out directly by using a proper
> > wiki-testing.kolab.org certificate, if that's not too much trouble.
> I think I'll send you a certificate for *.kolab.org, then
> hg.kolab.org, wiki-testing.kolab.org, wiki.kolab.org and whatever
> can co-exist on that machine without wasting IPv4 addresses.
That'd be nice. For a wildcard cert, this same IP address could be used (I had
mistakenly put down 108 while I meant to say 109... freudian typo...)
> > > I can send you the mysql dump and whatever you need.
> > A MySQL dump would be nice to start out with, sure.
> Since wiki.kolab.org was already intended to be administratable by
> external people, I can give you root access to this machine.
> Please send me your public ssh key for this purpose.
Sent to you in private.
> The old wiki.kolab.org will go down that evening. To shorten the
> unavailablility, the new wiki should be up before this. With DNS
> timeout set to e.g. one hour, the downtime will be _much_ shorter
> than 22:15-07:30.
> We could even strip down the downtime further by forwarding ports 80
> and 443 from the old machine to the new, but I think this is not
> needed here.
It's not about negating the downtime; there must be some downtime in which the
migration is performed and edits do not make it from the old to the new
deployment. It seems reasonable to put that downtime right in front of the
downtime that was inherent to the server moving physically and shorten it by
flipping the switch nice and early (e.g. way before 07:30).
> Btw, I if you can make a DNS A record (e.g. kolabwiki.kolabsys.com)
> pointing to 126.96.36.199 with a short timeout, I can replace the A
> record on wiki.kolab.org with a CNAME pointing there, so you have
> full control over the time of switching. After the migration this
> can either be kept (so you can change IPs if needed) or changed
> back into an A record.
A good idea, but I don't actually administer the kolabsys.com DNS myself,
Georg has it registered and maintains it. I've let him know this is going to
be a little problematic and we'll see what we can do about it before Sept.
23rd. To Be Continued.
Jeroen van Meeuwen
Senior Engineer, Kolab Systems AG
e: vanmeeuwen at kolabsys.com
t: +316 42 801 403
pgp: 9342 BF08
More information about the devel