Forum OpenACS Q&A: Checklist for moving an OpenACS site from one host to another

Collapse
1: Checklist for moving an OpenACS site from one host to another
Posted by Joel Aufrecht on 03/18/04 02:32 PM
I'm writing up a migration plan for a client and to be added to the standard docs.  Feedback welcome.  In this example, we are moving the site service0 from oldserver.net to newserver.net.  Its web address is www.myserver.net, the old IP is 10.10.1.1, and the new IP is 192.168.1.1.  The DNS is provided by another party, "dnspeople".

1. Ask the dnspeople what the current TTL is for your DNS entry.  This value is "oldTTL"

2. Set up a new OpenACS environment on newserver.net, with the same database version and aolserver version as on oldserver.net.  Make sure it works by installing a vanilla OpenACS site.

3. Tell the dnspeople to set the TTL as low as they are willing.

4. Wait for "oldTTL" to pass (usually 1 day)

5. Freeze service0 on oldserver (replace it with a "Down for maintenance" page.

6. Back up service0 on oldserver

7. Restore the backup on newserver

8. Verify that service0 on newserver works

9. Verify that the backup plan is in place on newserver

10. Tell dnspeople to change DNS for www.myserver.net from 10.10.1.1 to 192.168.1.1

11. Wait "newTTL" and then try going to "www.myserver.net" from several different hosts on different networks.

12. Tell dnspeople to return TTL to their usual value.

Collapse
2: Re: Checklist for moving an OpenACS site from one host to another (response to 1)
Posted by Tom Jackson on 03/18/04 05:18 PM

I would do 6-9 once, so you can estimate the downtime, and ensure all your bases are covered before freezing the service. Then drop the db on newserver and start at 1. Talk to the dnspeople asap to lower the ttl. You never know how long it will take them to figure out how to do that. Same with changing the ip address. Make sure they have staff around to do the change when you expect to do the move. Also, ensure everyone is available during the switch. Odd issues may show up and you need everyone on board during that time.

If downtime is too long, consider freezing the service to allow reading, but no writing.

Collapse
3: Re: Checklist for moving an OpenACS site from one host to another (response to 1)
Posted by David Cotter on 03/18/04 06:15 PM
I don't know what TTL is so I'm not sure if you have covered one point which caused me quite a problem when I moved from a static html website to openacs on a new server.

All users going to http://mysite.com were OK (no www. subdomain).

A number of users for certain ISPs going to http://www.mysite.com were going to the old website.

The reason was: I never asked the old hosting company to delete their www.mysite.com subdomain in their DNS and for some reason some ISPs were picking up the old record ever though the mysite.com domain was now being handled by the new hosting company and they had a www. subdomain defined. Once I got the old subdomain deleted everything was jake.

Collapse
4: Re: Checklist for moving an OpenACS site from one host to another (response to 1)
Posted by Cathy Sarisky on 03/18/04 09:08 PM
Check the config file for needed changes.  Look out for mailhost, etc, if those services are moving - the IP may be hard-coded.  Also check for any hard-coded directories unless everything is going into an identical file system.

And I agree with Tom about doing 6-9 first as a test run and then testing as much of the functionality as possible before taking the oldserver site offline.

Collapse
5: Re: Checklist for moving an OpenACS site from one host to another (response to 2)
Posted by Randy O'Meara on 03/20/04 01:21 AM
If you redirect requests received at the old site to the new site's IP address you'll have folks hitting your new site much sooner than if you wait for DNS to handle it for you. I have seen examples where clients continue to hit the old IP even after several TTLs have passed. Not everyone plays nicely by the rules...

Redirect should be simple at the topmost level (the maintenance page). A little more difficult would be to rewrite and then redirect deeper requests. I haven't used aolserver's rewrite capability so I can't say what it would look like.

Disclaimer: I haven't actually tried this with aolserver and openacs, but it should work...

Collapse
6: Re: Checklist for moving an OpenACS site from one host to another (response to 5)
Posted by Tom Jackson on 03/20/04 03:21 AM

Good point, it is just a simple filter that does a fully qualified redirect using the IP of the new service, and the path plus query. Unfortunately it only works with one service, if you do virtual hosting, it will not work.

Collapse
7: Re: Checklist for moving an OpenACS site from one host to another (response to 2)
Posted by Randy O'Meara on 10/08/04 02:27 AM
There is another thread, started today, where this same service migration question is asked. That thread cross-referenced this older and more complete discussion.

As I came back here to review this thread, I saw that Tom had mentioned the possibility of placing an oacs instance in read-only mode (no db writes). I like the idea of this especially when doing a maintenance db dump on a running production system. Has anyone developed the procedure to place an instance in read-only mode? If so, would you share?

Or, maybe this really isn't practical or possible?

Collapse
8: Re: Checklist for moving an OpenACS site from one host to another (response to 7)
Posted by Rocael Hernández Rizzardini on 10/08/04 03:39 AM
read-only mode might be achieved adding at the begining of db_dml & db_exec_psql a check against a parameter that you create that allow you to perform the given proc or not, though this is might not be the best solution, has worked for us at Galileo to allow users see classes that are expired but disallowing any change on them.
Here are the lines that does that for us:

#    if { [ad_conn user_id] && ![empty_string_p [dotlrn_community::get_community_id]] } {
#      if { ![dotlrn::admin_p] } {
#          if { [permission::permission_p -party_id [ad_conn user_id] -object_id [ad_conn package_id] -privilege admin] } {
#              set segment_id [dotlrn_community::get_rel_segment_id -community_id [dotlrn_community::get_community_id] -rel_type dotlrn_admin_rel]
#          } else {
#              set segment_id [dotlrn_community::get_rel_segment_id -community_id [dotlrn_community::get_community_id] -rel_type dotlrn_member_rel]
#          }
#          if { [permission::permission_p -party_id $segment_id -object_id [ad_conn package_id] -privilege ges_view] } {
#                ad_return_forbidden  "Permiso denegado"  "<blockquote>
#                  Esta clase ha expirado, la informaci&oacute;n no puede ser modificada.
#                </blockquote>"
#          }
#      }
#    }