This is not a bug, per se, just because it's not probably a normal/common thing to do. I'm just posting this in case someone else decides to migrate their site to a new server doing the same thing.
As you know, one of the problems when moving a site from one server to another is dealing with the ip change. There's always some kind of delay before everyone has the new ip for the website simply because of how DNS works. Reducing the TTL (time to live) at the nameserver is a good method of minimizing downtime, but you don't always have access to the SOA record or the DNS host may not allow you to set very low TTL times.
In combination with the above method (or stand-alone if you can't change the TTL) is to use a reverse proxy. In simple, you tell the webserver on the old box (apache in my case) to continue to answer for example.com, but to ask the new server for the actual pages to serve. This way the site appears to be up for people knowing the new ip and also for people with the old ip address in their DNS. Seamless and beautiful.
This is what an entry might look like in your vhost stanza for example.com:
The thing that makes that impossible looking proxy work, is that you edit /etc/hosts on the old server and make two entries for example.com with the ip of the new server.
This worked perfectly for me on 3 or 4 joomla sites until I hit one site -- a site with CC on its front page: couldn't connect to db. Everything else worked, but not that module. Since I hadn't touched the dns yet, I quickly commented out the proxy and did a graceful reload of apache. Surprise! Still broken in just the same way. Weird.
Finally (some time passed...), I noticed that everything was showing coming from the logging monitor for the old server except the CC request -- that was showing on the logging monitor for the new server. After commenting out the /etc/hosts entries, the site again worked properly on the old server.
So, it seems that perhaps (I really don't know) ChronoConnectivity is doing its own lookup somewhere, which makes proxying impossible using the method described above. Maybe it's not even CC's problem, it may be inherent in how it has to make db connections. I haven't seen such a problem with any other modules or components, but needless to say, nothing else has the functionality that CC does. Then again, it could be something to do with mod_customcontent -- I truly have no idea -- nothing but relative links in anything I typed.
As I said, not a bug per se, just an oddity I'm posting in case someone else runs into the same problem.
Paul
As you know, one of the problems when moving a site from one server to another is dealing with the ip change. There's always some kind of delay before everyone has the new ip for the website simply because of how DNS works. Reducing the TTL (time to live) at the nameserver is a good method of minimizing downtime, but you don't always have access to the SOA record or the DNS host may not allow you to set very low TTL times.
In combination with the above method (or stand-alone if you can't change the TTL) is to use a reverse proxy. In simple, you tell the webserver on the old box (apache in my case) to continue to answer for example.com, but to ask the new server for the actual pages to serve. This way the site appears to be up for people knowing the new ip and also for people with the old ip address in their DNS. Seamless and beautiful.
This is what an entry might look like in your vhost stanza for example.com:
ProxyRequests Off
<Proxy *>
Order deny,allow
Allow from all
</Proxy>
ProxyPass / http://example.com/
ProxyPassReverse / http://example.com/
ProxyPass / http://www.example.com/
ProxyPassReverse / http://www.example.com/
The thing that makes that impossible looking proxy work, is that you edit /etc/hosts on the old server and make two entries for example.com with the ip of the new server.
This worked perfectly for me on 3 or 4 joomla sites until I hit one site -- a site with CC on its front page: couldn't connect to db. Everything else worked, but not that module. Since I hadn't touched the dns yet, I quickly commented out the proxy and did a graceful reload of apache. Surprise! Still broken in just the same way. Weird.
Finally (some time passed...), I noticed that everything was showing coming from the logging monitor for the old server except the CC request -- that was showing on the logging monitor for the new server. After commenting out the /etc/hosts entries, the site again worked properly on the old server.
So, it seems that perhaps (I really don't know) ChronoConnectivity is doing its own lookup somewhere, which makes proxying impossible using the method described above. Maybe it's not even CC's problem, it may be inherent in how it has to make db connections. I haven't seen such a problem with any other modules or components, but needless to say, nothing else has the functionality that CC does. Then again, it could be something to do with mod_customcontent -- I truly have no idea -- nothing but relative links in anything I typed.
As I said, not a bug per se, just an oddity I'm posting in case someone else runs into the same problem.
Paul