Merge branch 'master' into ubilabs--rcapp--develop

wiki/505-worlds-kiel-2014.md

@@ -35,14 +35,14 @@ 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.
-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.
+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.
 
-When switching from the A server to the B server or vice versa, the replica needs to be re-configured. Before stopping it, connected clients need to be re-directed to the master when they hit 505worlds2014.sapsailing.com. This is achieved by re-configuring the Apache server running on the replica, as user `root`, editing `/etc/apache2/sites-enabled/001-events.conf` and activating the line for `505worlds2014.sapsailing.com` that points to the IP address of the new active server, then invoking `/etc/init.d/apache2 reload`. Once this is done, the running replica should cleanly stop replication (using the `Replication` tab in the AdminConsole), then stopping the instance (as user `sailing` run `/home/sailing/servers/server/stop`). Then, in `env.sh` the `REPLICATE_MASTER_SERVLET_HOST` variable needs to be set to point to the new master. After that, the replica Java instance can be launched using `/home/sailing/servers/server/start`). Before re-activating it is important that the rabbit initial load is done. So please watch eather `/home/sailing/servers/server/logs/sailing0.log.0` or the Rabbit Webinterface on `http://54.246.250.138:15672/#/queues`. Please deleted eventually displayed old queues (be sure not to remove the correct replicating queue!). Re-configure Apache again by editing `/etc/apache2/sites-enabled/001-events.conf` again, re-activating the record that lets 505worlds2014.sapsailing.com point to the replica. From this point on, clients in the lounge and the Cube will instantly be directed to the cube server again when hitting the replica server's Apache with a URL starting with `505worlds2014.sapsailing.com`. You can check this by example checking the load with `htop` or `apachetop`.
+When switching from the A server to the B server or vice versa, the replica needs to be re-configured. Before stopping it, connected clients need to be re-directed to the master when they hit 505worlds2014.sapsailing.com. This is achieved by re-configuring the Apache server running on the replica, as user `root`, editing `/etc/apache2/sites-enabled/001-events.conf` and activating the line for `505worlds2014.sapsailing.com` that points to the IP address of the new active server, then invoking `/etc/init.d/apache2 reload`. Once this is done, the running replica should cleanly stop replication (using the `Replication` tab in the AdminConsole), then stopping the instance (as user `sailing` run `/home/sailing/servers/server/stop`). Then, in `env.sh` the `REPLICATE_MASTER_SERVLET_HOST` variable needs to be set to point to the new master. After that, the replica Java instance can be launched using `/home/sailing/servers/server/start`). Before re-activating it is important that the rabbit initial load is done. So please watch either `/home/sailing/servers/server/logs/sailing0.log.0` or the Rabbit Webinterface on `http://54.246.250.138:15672/#/queues`. Please deleted eventually displayed old queues (be sure not to remove the correct replicating queue!). Re-configure Apache again by editing `/etc/apache2/sites-enabled/001-events.conf` again, re-activating the record that lets 505worlds2014.sapsailing.com point to the replica. From this point on, clients in the lounge and the Cube will instantly be directed to the cube server again when hitting the replica server's Apache with a URL starting with `505worlds2014.sapsailing.com`. You can check this by example checking the load with `htop` or `apachetop`.
 
 ## Switching Servers