| 3 | | Changing a project master URL is not a trivial task. It's recommended that |
| 4 | | projects avoid keeping things prone to change in their project URLs, like |
| 5 | | using an IP address, or even putting the university they are in as part of |
| 6 | | the hostname (Docking@Home had to change the URL twice or so because they |
| 7 | | changed university / organization / department / something). Thus, the best |
| 8 | | way is having a domain name just for that project. Good URLs don't change. |
| | 3 | Changing a project master URL is not a trivial task. |
| | 4 | It's recommended that projects avoid keeping things prone to change in their project URLs, |
| | 5 | like using an IP address, |
| | 6 | or even putting the university they are in as part of the hostname |
| | 7 | (Docking@Home had to change the URL twice or so |
| | 8 | because they changed university / organization / department / something). |
| | 9 | Thus, the best way is having a domain name just for that project. |
| | 10 | Good URLs don't change. |
| 10 | | Even having multiple projects as boinc.example.org/project1 and |
| 11 | | boinc.example.org/project2 may be problematic if you eventually decide you |
| 12 | | want to move project2 to a different server. It's best to have |
| 13 | | project1.example.org and project2.example.org so they can (now or in the |
| 14 | | future) have different IP addresses. |
| | 12 | Even having multiple projects as |
| | 13 | boinc.example.org/project1 and boinc.example.org/project2 |
| | 14 | may be problematic if you eventually decide |
| | 15 | you want to move project2 to a different server. |
| | 16 | It's best to have project1.example.org and project2.example.org |
| | 17 | so they can (now or in the future) have different IP addresses. |
| 19 | | 1. Pick a *good* new URL according to the above recommendations, so that you |
| 20 | | will never need to change it again. |
| 21 | | 2. If the project was ever public, post news to let users now the URL will |
| 22 | | change. |
| 23 | | 3. If you have any tasks in progress or waiting to be sent, it's recommended |
| 24 | | you wait until they are all done before changing the URL. And/or abort the |
| 25 | | unsent tasks. You *could* edit the database to fix URLs for input files, to |
| 26 | | make the unsent workunits work once the URL is changed; but if users already |
| 27 | | have workunits on their computers, they will still have old URLs and you |
| 28 | | can't edit that. |
| | 22 | 1. Pick a *good* new URL according to the above recommendations, |
| | 23 | so that you will never need to change it again. |
| | 24 | 2. If the project was ever public, |
| | 25 | post news to let users now the URL will change. |
| | 26 | 3. If you have any tasks in progress or waiting to be sent, |
| | 27 | it's recommended you wait until they are all done before changing the URL. |
| | 28 | And/or abort the unsent tasks. |
| | 29 | You ''could'' edit the database to fix URLs for input files, |
| | 30 | to make the unsent workunits work once the URL is changed; |
| | 31 | but if users already have workunits on their computers, |
| | 32 | they will still have old URLs and you can't edit that. |
| 31 | | 6. Replace scheduler URL in html/users/schedulers.txt. Prefix should match the |
| 32 | | URL in <cgi_url> in config.xml. |
| 33 | | 7. If you have project-wide files, like logos for the simple GUI, replace |
| 34 | | download URLs in project_files.xml |
| 35 | | 8. Delete everything in html/cache, since cached pages may have links to the |
| 36 | | old URL, and users would get broken links for an hour or so. Don't delete the |
| 37 | | cache folder itself. rm -rf html/cache/* |
| 38 | | 9. Either create new application versions, or update the app_version table to |
| 39 | | have the new URLs: |
| 40 | | UPDATE app_version SET xml_doc = |
| 41 | | REPLACE(xml_doc, "http://old.example.com/", "http://new.example.org/"); |
| 42 | | 10. If you have forums, you may want to do a similar replacement on forum |
| 43 | | contents, in case users posted links to workunits / users / computers / |
| 44 | | something. |
| 45 | | 11. Start the project, send some test workunits, and hope it works. Keep a |
| 46 | | copy of "Murphy's Law - and other reasons why things go wrong" handy. |
| 47 | | |
| | 35 | 6. Replace scheduler URL in html/users/schedulers.txt. |
| | 36 | Prefix should match the URL in <cgi_url> in config.xml. |
| | 37 | 7. If you have project-wide files, |
| | 38 | like logos for the simple GUI, |
| | 39 | replace download URLs in project_files.xml |
| | 40 | 8. Delete everything in html/cache, |
| | 41 | since cached pages may have links to the old URL, |
| | 42 | and users would get broken links for an hour or so. |
| | 43 | Don't delete the cache folder itself. |
| | 44 | rm -rf html/cache/* |
| | 45 | 9. Either create new application versions, |
| | 46 | or update the app_version table to have the new URLs: |
| | 47 | {{{ |
| | 48 | UPDATE app_version SET xml_doc = REPLACE(xml_doc, "http://old.example.com/", "http://new.example.org/"); |
| | 49 | }}} |
| | 50 | 10. If you have forums, |
| | 51 | you may want to do a similar replacement on forum contents, |
| | 52 | in case users posted links to workunits / users / computers / something. |
| | 53 | 11. Start the project, send some test workunits, and hope it works. |
| | 54 | Keep a copy of "Murphy's Law - and other reasons why things go wrong" handy. |