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.
