Moving sites to new hardware

[Eric Soroos]

> The base domain name had to be changed manually in
> config.manila.prefs. I did a manual search-and-replace
> of the old URLs in manila.root, mainresponder.root,
> config.root, etc. Took about 3 hours.

> I *think* the Uninstall/Install could be automated.
> I'm not sure if the URL replacement in the UserLand
> .roots could be; I think some were found in 'binary'
> objects (though I'm not sure why).

I've done this in the past. 

For manila sites, the uninstall/install can be automated (even if you're going to the same domain name) with the following exceptions:

 it doesn't do config.mainresponder.domains
 some plugins fail (metadata for one)

So I scripted dis/re enabling all the plugins for the various sites (which required a bit of hacking on metadata's install routines, since they require a pta. grr.) 

To do this, you're going to need to have a new manila system set up the way you want it, except for the manila sites, then move it. 

I've also moved frontier systems (non manila) and done an automated search and replace through the roots, scanning tables where I know that there are addresses, filespecs, and strings that represent addresses.  I need to run the scan twice, once before changing the path, then change the path, then run it again. 

> As to changing Manila to use relative paths throughout:
> save your effort. You'd have to change a lot of
> UserLand code.

You'd either need to redesign mainresponder or change kernel code. The former is hard, the latter impossible without cooperation. 

I would have to say that of all the design decisions that have been baked into the kernel, saving absolute paths may be the worst. 

eric