Euronode

This pages describes the way the euronode mirror works

We are moving to a system where we have geographically specific servers (nodes); we will try to direct users to the node which is appropriate for them. I call this geoMirroring to avoid confusion with our traditional mirrors.

The node for a given server is specified in the hg.conf file; e.g. the machines in California will have the following in their hg.conf file:

browser.node=1

The euronode will have:

browser.node=2

We may add other nodes in the future (e.g. in asia). If this configuration variable is not found, the redirection code is not executed (this will be the case in traditional mirrors).

In the following discussion, hgcentral applies to RR (the relevant table for testing on hgwdev is hgcentraltest). RR will include euronode.cse.ucsc.edu when we activate the euronode.

The table hgcentral.gbNode contains the metadata for each node (e.g. domain, country and description). This is a copy of hgFixed.gbNodeReal (so we can modify on hgwdev).

The table hgcentral.geoIpNode is used to map a user's IP to the appropriate node. If an IP is not found in geoIpNode, the system assumes the user belongs in node 1 (California). hgcentral.geoIpNode is based on hgFixed.geoIpNodeReal, which was built by Galt using a publicly available IP => country mapping database (http://software77.net/geo-ip). The copy in hgcentral may be modified (e.g. to add the IP used by QA team for testing).

Note that the IPs are stored in the tables using a numeric representation (for speed). mysql has a built in function, INET_ATON, which can be used to convert the dotted-quad notation to the numeric form; e.g. to add a new entry to geoIpNode:

hgsql hgcentral -s -e "insert into geoIpNode VALUES (INET_ATON('128.114.49.36'), INET_ATON('128.114.49.36'), 2)"

The built-in function INET_NTOA can be used to convert back from the numeric representation to the dotted-quad notation.

When does redirection happen?

If a european goes to http://genome.ucsc.edu/cgi-bin/hgGateway, they will be redirected to http://euronode.ucsc.edu/cgi-bin/hgGateway. If a non-european goes to http://euronode.ucsc.edu/cgi-bin/hgGateway, they will be redirected to http://genome.ucsc.edu/cgi-bin/hgGateway.

Users are only redirected via hgGateway; e.g. if a european goes directly to http://genome.ucsc.edu/cgi-bin/hgTracks, they will not be redirected back to europe. The rationale for this is that such links may include sessions that are specific to the California mirror.

The first time a user is redirected, they will see a little dialog box at the top of hgGateway that let's them override the redirect (see screenshot below); e.g. if user X is redirected to euronode, they may click on the link in the box to get back to the Californian hgGateway. This manual redirect back to California is remembered with a cookie stored in the user's web browser (the value of the cookie will be redirect=manual). This cookie is not cleared by a cartReset (this is intentional). The user will always be able to switch which mirror they are using via a to-be-designed UI.

An important limitation of the geo-mirrors is that sessions are NOT shared between the different nodes.

How do I test this?

We are putting the IP of hgroaming.cse.ucsc.edu (128.114.49.36) into the geoIpNode table as node == 2. So if you configure your web browser to use the hgroaming proxy, the site will "think" you are coming from europe. You can contact cluster-admin to get an hgroaming account.