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

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.

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...

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.

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?

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ón no puede ser modificada.
# </blockquote>"
# }
# }
# }