Yes, I did. My comments are less about the process (which you covered very well) and more about prevention.
If someone plans ahead, there is no reason for them to ever need to change the project URL. I didn't see where you addressed functions inside a project -- apologies if I missed that. Your information is needed, because no matter how hard one tries, there will always be those who picked a URL, and didn't plan ahead. I think it was CPDN that lost one of their upload servers while there was work with that upload URL in the field. I don't know how they recovered, but it would have been easy if that was a CNAME. -- Lynn Nicolás Alvarez wrote: > Did you look at the wiki page? I even mentioned the case of Docking > switching universities. > > El 12/10/2009, a las 13:42, "Lynn W. Taylor" <[email protected]> escribió: > >> There probably should be guidelines for naming, to avoid exactly this >> kind of a problem. >> >> Since I do DNS on a daily basis.... >> >> It'd be a good idea for every project to have their own domain name. >> Subdomains are okay if they're in a very stable situation. >> >> It's a good idea to name as many functions as possible. Your scheduler >> and your upload server and download server may all be the same server, >> but if you name them "upload.project.tld" and "download.project.tld" and >> "scheduler.download.tld" all pointing to the same IP, you can split them >> later and just change DNS. >> >> I know that one project had a server at a partner University, and that >> server was lost for some reason. Since those work units pointed to that >> school's server for uploading, the project was in for a hassle. If the >> upload URL had been a CNAME, they could have just changed the CNAME. >> >> I know this is far from comprehensive, and I know I don't have all the >> details exactly right. I've not mentioned round-robin DNS or any of the >> load balancing tricks that (mostly) work in DNS, but it's the idea, and >> it's one of those "plan ahead" sort of things that may never be needed. >> >> For my ISP customers, I have different names for my POP3 server and my >> SMTP server, even though they'll likely always be the same box. >> Someday, they might not, and I won't have to change every customer to >> make that happen. >> >> -- Lynn >> >> Slawomir Rzeznicki wrote: >>> I changed the master URL of my project in the past, >>> from my experience I can tell you that it won't cause >>> too much troubles if you leave the old URL working >>> for some time. >>> >>> In my case, I set up the old domain name as an alias >>> (CNAME) for the new one, and I used apache's >>> mod_rewrite combined with mod_proxy to transparently >>> redirect requests from the old domain/path to the new one >>> (probably not required if only the domain is changed). >>> At first I tried simple http redirect (status 301, tried also >>> 302, 303 and 307); for a large number of clients it caused >>> problems reaching the file upload handler and the scheduler. >>> >>> /TJM >>> >>> On Mon, 12 Oct 2009 00:29:42 -0300 >>> Nicolás Alvarez <[email protected]> wrote: >>>> El Lunes 12 Oct 2009 00:16:39 Mark Pottorff escribió: >>>>> So... what about all those volunteers attached to the >>>>> old project URL? With >>>>> results, from the old URL, ready to be returned to the >>>>> project? They will >>>>> be trying to hit the old upload server, and scheduler. >>>> That depends on whether the old URL stops working or not. >>>> It may be configured >>>> to redirect to the new one, in which case clients will be >>>> able to keep >>>> reporting work. Adding such redirection was out of the >>>> scope of my >>>> instructions; but feel free to add it yourself :) >>>> >>>> -- >>>> Nicolas >>>> _______________________________________________ >>>> boinc_dev mailing list >>>> [email protected] >>>> http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev >>>> To unsubscribe, visit the above URL and >>>> (near bottom of page) enter your email address. >>> >>> _______________________________________________ >>> boinc_dev mailing list >>> [email protected] >>> http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev >>> To unsubscribe, visit the above URL and >>> (near bottom of page) enter your email address. >>> >> _______________________________________________ >> boinc_dev mailing list >> [email protected] >> http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev >> To unsubscribe, visit the above URL and >> (near bottom of page) enter your email address. > > ------------------------------------------------------------------------ > > _______________________________________________ > boinc_dev mailing list > [email protected] > http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev > To unsubscribe, visit the above URL and > (near bottom of page) enter your email address.
_______________________________________________ boinc_dev mailing list [email protected] http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
