More launch --> lounge replacements

This commit is contained in:
Axel Uhl committed 2015-06-16 07:33:12 +00:00
1 parent db44d1bc96
commit 5876415287
1 file changed
+2 -2
+2 -2
View File
@@ -35,9 +35,9 @@ Event Page (newhome): http://505worlds2014.sapsailing.com/gwt/Home.html#EventPla
At this event we operate a replica on our SAP Sail Cube server. The server is physically located behind the ground floor desk. With one of its network adapters it is hooked up to the lounge network, using a radio link from realTV. The second network adapter (Mainboard) is connected to the cube's network, allowing access from studio PCs to the cube server. This adapter is also the default route, providing the cube server, cube showroom and realTV with Internet access. As a backup it is possible to switch the default route to the lounge. See `ip route show`.
The server runs a isc-dhcp-server, which requires all connected routers to NOT deliver a dhcp server. All required subnet config is in `/etc/dhcp/dhcpd.conf`. We have a /22 subnet for cube and a /24 subnet for the launch. BeTomorrow get static ips assigned by the dhcp through MAC-addresses, because their server always needs the same ip address. Futhermore the dhcp deploys our own DNS server here. For further description of the DNS setup read further.
The server runs a isc-dhcp-server, which requires all connected routers to NOT deliver a dhcp server. All required subnet config is in `/etc/dhcp/dhcpd.conf`. We have a /22 subnet for cube and a /24 subnet for the lounge. BeTomorrow get static ips assigned by the dhcp through MAC-addresses, because their server always needs the same ip address. Futhermore the dhcp deploys our own DNS server here. For further description of the DNS setup read further.
The server also runs a bind9 DNS server which is set as the primary DNS for all lounge and cube PCs. All DNS requests are forwarded to a public DNS server except for requests for 505worlds2014.sapsailing.com for which the local DNS server returns the IP address of the cube server for the NIC through which the DNS request was received. For that two DNS zones are introduced, which match by the incoming IP range request. See `/etc/bind/named.conf.zones-cube` and `/etc/bind/named.conf.zones-launch` for definition of zone and forwarding. Take a look at `/etc/bind/zones/505sapsailing.cube.db` and `/etc/bind/zones/505sapsailing.sailing.db` for the nameserver entries for the zone. The result is, that if a request comes from the launch network, the domain is resolved to the ip the cube server has in this subnet and also if the request comes from the cube, it returns the ip in the subnet of the cube.
The server also runs a bind9 DNS server which is set as the primary DNS for all lounge and cube PCs. All DNS requests are forwarded to a public DNS server except for requests for 505worlds2014.sapsailing.com for which the local DNS server returns the IP address of the cube server for the NIC through which the DNS request was received. For that two DNS zones are introduced, which match by the incoming IP range request. See `/etc/bind/named.conf.zones-cube` and `/etc/bind/named.conf.zones-launch` for definition of zone and forwarding. Take a look at `/etc/bind/zones/505sapsailing.cube.db` and `/etc/bind/zones/505sapsailing.sailing.db` for the nameserver entries for the zone. The result is, that if a request comes from the lounge network, the domain is resolved to the ip the cube server has in this subnet and also if the request comes from the cube, it returns the ip in the subnet of the cube.
As described in bug2204 wind data and API are not served through the replica, so BeTomorrow has to go to our main server. For that i introduced a subsubdomain `btmw.505worlds2014.sapsailing.com` which points to `sapsailing.com` and answers with our main active server of the event.
On the cube server we run a replica server instance as user `sailing` under the usual directory set-up (`/home/sailing/servers/server`). The `env.sh` file uses a configuration that lets the server start replicating when launched. The two possible master servers (A / B) are specified in two lines defining `REPLICATE_MASTER_SERVLET_HOST`, one is commented, the other one active.