mirror of
https://github.com/eclipse-sailing-analytics/sailing-analytics.git
synced 2026-10-08 21:30:57 +00:00
Merge remote-tracking branch 'origin/master' into competitor_filtering
This commit is contained in:
fmittag committed
commit
89cd03dccb
13 files changed
+715
-538
No files matched your search
@@ -1,31 +1,37 @@
|
||||
# Welcome to the SAP Sailing Wiki
|
||||
|
||||
This is the <img src="http://analysis.sapsailing.com/themes/logo.png" height="58" width="200" /> Wiki where useful information regarding this project can be found.
|
||||
|
||||
### The Pitch
|
||||
|
||||
Like businesses, sailors need the latest information to make strategic decisions - but they need it even faster. One wrong tack, a false estimation of the current, or the slightest wind shift can cost the skipper the entire race. As premium sponsor of the Kieler Woche 2011, and co-sponsor of Sailing Team Germany (STG), SAP is showing how innovative IT solutions providing real time data analysis can give teams the competitive edge.
|
||||
|
||||
### Table of Contents
|
||||
|
||||
* [[Information about this Wiki and HowTo|wiki/howto]]
|
||||
* [[General Project Information|wiki/general-information]]
|
||||
* [[OnBoarding Information|wiki/onboarding]]
|
||||
* [[Architecture and Infrastructure|wiki/architecture-and-infrastructure]]
|
||||
* [[Production Environment|wiki/production-environment]]
|
||||
* [[Development Environment|wiki/development-environment]]
|
||||
* [[Server Replication|wiki/server-replication]]
|
||||
* [[Configure Races on Server|wiki/configure-races-on-server]]
|
||||
* [[Cook Book|wiki/cook-book]]
|
||||
* [[Planning|wiki/planning]]
|
||||
* Event Specifica
|
||||
* [[General Planning|wiki/general-event-planning]]
|
||||
* [[Extreme Sailing Series|wiki/extreme-sailing-series]]
|
||||
|
||||
### Internal services (not related to wiki but useful)
|
||||
|
||||
* [Bugzilla Issue Tracking System](http://bugzilla.sapsailing.com/bugzilla/)
|
||||
* [GIT Repository (SAP)](ssh://git.wdf.sap.corp:29418/SAPSail/sapsailingcapture.git)
|
||||
* [Maven Repository Browser](http://maven.sapsailing.com/maven/)
|
||||
* [Main Sailing Website](http://www.sapsailing.com)
|
||||
* [Visitor Statistics](http://analysis.sapsailing.com/)
|
||||
# Welcome to the SAP Sailing Wiki
|
||||
|
||||
This is the <img src="http://analysis.sapsailing.com/themes/logo.png" height="58" width="200" /> Wiki where useful information regarding this project can be found.
|
||||
|
||||
### The Pitch
|
||||
|
||||
Like businesses, sailors need the latest information to make strategic decisions - but they need it even faster. One wrong tack, a false estimation of the current, or the slightest wind shift can cost the skipper the entire race. As premium sponsor of the Kieler Woche 2011, and co-sponsor of Sailing Team Germany (STG), SAP is showing how innovative IT solutions providing real time data analysis can give teams the competitive edge.
|
||||
|
||||
### Table of Contents
|
||||
|
||||
* [[Information about this Wiki and HowTo|wiki/howto]]
|
||||
* [[General Project Information|wiki/general-information]]
|
||||
* Production Environment
|
||||
* [[PIRONET (Hosting Provider, Emergency Procedures)|wiki/prionet-related-information]]
|
||||
* [[Production Environment|wiki/production-environment]]
|
||||
* Information for Developers
|
||||
* [[Cook Book|wiki/cook-book]]
|
||||
* [[OnBoarding Information|wiki/onboarding]]
|
||||
* [[Server Replication|wiki/server-replication]]
|
||||
* [[Configure Races on Server|wiki/configure-races-on-server]]
|
||||
* [[Development Environment|wiki/development-environment]]
|
||||
* General Information
|
||||
* [[Architecture and Infrastructure|wiki/architecture-and-infrastructure]]
|
||||
* [[Sailing Domain Algorithms|wiki/sailing-domain-algorithms]]
|
||||
* [[Inventar|wiki/inventar-liste]]
|
||||
* Planning and Event Information
|
||||
* [[Project Planning (bigger development)|wiki/planning]]
|
||||
* [[General Event Planning|wiki/general-event-planning]]
|
||||
* [[Information about Extreme Sailing Series|wiki/extreme-sailing-series]]
|
||||
|
||||
### Internal services (not related to wiki but useful)
|
||||
|
||||
* [Bugzilla Issue Tracking System](http://bugzilla.sapsailing.com/bugzilla/)
|
||||
* [GIT Repository (SAP)](ssh://git.wdf.sap.corp:29418/SAPSail/sapsailingcapture.git)
|
||||
* [Maven Repository Browser](http://maven.sapsailing.com/maven/)
|
||||
* [Main Sailing Website](http://www.sapsailing.com)
|
||||
* [Visitor Statistics](http://analysis.sapsailing.com/)
|
||||
+7
@@ -71,6 +71,8 @@ import com.sap.sailing.domain.confidence.Weigher;
|
||||
import com.sap.sailing.domain.confidence.impl.HyperbolicTimeDifferenceWeigher;
|
||||
import com.sap.sailing.domain.confidence.impl.PositionAndTimePointWeigher;
|
||||
import com.sap.sailing.domain.racelog.RaceLog;
|
||||
import com.sap.sailing.domain.racelog.analyzing.impl.StartTimeFinder;
|
||||
import com.sap.sailing.domain.racelog.impl.PassAwareRaceLogImpl;
|
||||
import com.sap.sailing.domain.tracking.CourseDesignChangedListener;
|
||||
import com.sap.sailing.domain.tracking.GPSFix;
|
||||
import com.sap.sailing.domain.tracking.GPSFixMoving;
|
||||
@@ -2339,6 +2341,11 @@ public abstract class TrackedRaceImpl implements TrackedRace, CourseListener {
|
||||
public void attachRaceLog(RaceLog raceLog) {
|
||||
this.attachedRaceLog = raceLog;
|
||||
attachedRaceLog.addListener(raceLogListener);
|
||||
// set start time for race, if there is one valid in the log
|
||||
StartTimeFinder startTimeFinder = new StartTimeFinder(PassAwareRaceLogImpl.copy(raceLog));
|
||||
if (startTimeFinder.getStartTime() != null) {
|
||||
setStartTimeReceived(startTimeFinder.getStartTime());
|
||||
}
|
||||
}
|
||||
|
||||
@Override
|
||||
|
||||
+11
-2
@@ -464,7 +464,7 @@ public class TracTracEventManagementPanel extends AbstractEventManagementPanel {
|
||||
this.racesTable.addColumn(raceStartTrackingColumn, this.stringMessages.startTime());
|
||||
this.racesTable.addColumn(raceStatusColumn, this.stringMessages.raceStatusColumn());
|
||||
this.racesTable.addColumnSortHandler(getRaceTableColumnSortHandler(this.raceList.getList(), raceNameColumn,
|
||||
boatClassColumn, raceStartTrackingColumn));
|
||||
boatClassColumn, raceStartTrackingColumn, raceStatusColumn));
|
||||
this.racesTable.setSelectionModel(new MultiSelectionModel<TracTracRaceRecordDTO>());
|
||||
this.racesTable.setWidth("100%");
|
||||
|
||||
@@ -506,7 +506,7 @@ public class TracTracEventManagementPanel extends AbstractEventManagementPanel {
|
||||
|
||||
private ListHandler<TracTracRaceRecordDTO> getRaceTableColumnSortHandler(List<TracTracRaceRecordDTO> raceRecords,
|
||||
Column<TracTracRaceRecordDTO, ?> nameColumn, Column<TracTracRaceRecordDTO, ?> boatClassColumn,
|
||||
Column<TracTracRaceRecordDTO, ?> trackingStartColumn) {
|
||||
Column<TracTracRaceRecordDTO, ?> trackingStartColumn, Column<TracTracRaceRecordDTO, ?> raceStatusColumn) {
|
||||
ListHandler<TracTracRaceRecordDTO> result = new ListHandler<TracTracRaceRecordDTO>(raceRecords);
|
||||
result.setComparator(nameColumn, new Comparator<TracTracRaceRecordDTO>() {
|
||||
@Override
|
||||
@@ -527,6 +527,13 @@ public class TracTracEventManagementPanel extends AbstractEventManagementPanel {
|
||||
.compareTo(o2.trackingStartTime);
|
||||
}
|
||||
});
|
||||
result.setComparator(raceStatusColumn, new Comparator<TracTracRaceRecordDTO>() {
|
||||
@Override
|
||||
public int compare(TracTracRaceRecordDTO o1, TracTracRaceRecordDTO o2) {
|
||||
return o1.raceStatus == null ? -1 : o2.raceStatus == null ? 1 : o1.raceStatus
|
||||
.compareTo(o2.raceStatus);
|
||||
}
|
||||
});
|
||||
return result;
|
||||
}
|
||||
|
||||
@@ -595,11 +602,13 @@ public class TracTracEventManagementPanel extends AbstractEventManagementPanel {
|
||||
sailingService.listTracTracRacesInEvent(jsonURL, listHiddenRaces, new MarkedAsyncCallback<Pair<String, List<TracTracRaceRecordDTO>>>() {
|
||||
@Override
|
||||
public void handleFailure(Throwable caught) {
|
||||
loadingMessageLabel.setText("");
|
||||
reportError("Error trying to list races: " + caught.getMessage());
|
||||
}
|
||||
|
||||
@Override
|
||||
public void handleSuccess(final Pair<String, List<TracTracRaceRecordDTO>> result) {
|
||||
loadingMessageLabel.setText("Building resultset and saving configuration...");
|
||||
TracTracEventManagementPanel.this.availableTracTracRaces.clear();
|
||||
|
||||
final String eventName = result.getA();
|
||||
|
||||
+1
-1
@@ -585,5 +585,5 @@ waypoints=Waypoints
|
||||
disableRaceFilter=Disable filter
|
||||
enableRaceFilter=Enable filter
|
||||
raceStatusColumn=Race Status
|
||||
loading=Loading...
|
||||
loading=Loading (on a slow internet connection this can take some minutes)...
|
||||
showHiddenRaces=Show HIDDEN races
|
||||
@@ -40,7 +40,7 @@
|
||||
Star IDM 2013
|
||||
</li>
|
||||
<li class='raceLocation'>
|
||||
Möhnesee, Germany
|
||||
Möhnesee, Germany
|
||||
</li>
|
||||
</ul>
|
||||
</a>
|
||||
|
||||
@@ -1,26 +1,28 @@
|
||||
# Architecture and Infrastructure
|
||||
|
||||
### Table of Contents
|
||||
|
||||
* [[Runtime Environment|wiki/runtime-environment]]
|
||||
* [[Basic Architectural Principles|wiki/basic-architectural-principles]]
|
||||
* [[Development Environment|wiki/development-environment]]
|
||||
* [[Production Environment|wiki/production-environment]]
|
||||
* [[Typical Development Scenarios|wiki/typical-development-scenarios]]
|
||||
|
||||
## Introduction, Project Background and History
|
||||
|
||||
The SAP Sailing Analytics are a technology show-case demonstrating SAP technologies, concepts, skills and values applied to the domain of regatta sailing. They started as a small tool primarily intended to support a commentator in his job by displaying a live leaderboard for a sailing regatta with data interesting for the commentary. GPS and wind data travel from sensors to the server where the application keeps it in memory. When a request for a leaderboard is received, the data is aggregated on the fly, performing geometric computations including wind projections and involving a virtual "advantage line" orthogonal to the wind direction.
|
||||
|
||||
The live leaderboard started as a web application with a Java back-end responsible for the connectivity with the sensors and providing the geometry engine, and a Python process rendering the Web UI for the client's browser. The Python process issued REST requests to the Java back-end which responded with JSON documents.
|
||||
|
||||
The solution was first shown at Kieler Woche 2011. At the time, it was capable of displaying a single leaderboard that showed a number of tracked races in numerical form, offering columns for overall rank, race rank, rank at a mark, and values for average speed, distance traveled, gap to leader in seconds, velocity made good (VMG), estimated time of arrival at the next mark and current speed over ground. It was prototypical in many regards but regardless was considered an improvement for the commentary. The sailors liked it too because for the first time they could see numerical evidence of their choices of speed over distance.
|
||||
|
||||
After Kieler Woche 2011, the architecture changed. We removed the Python engine and used the Google Web Toolkit instead to render the Web UI directly in the Java process. A first new live leaderboard with this approach was shown at the IDM Travemünde 2011 and later at the MdM Hamburg 2011 events. Over time, the solution learned to manage multiple leaderboards, combining historic race analysis with live tracking. Particularly the accumulation of historic race data will require changes in the architecture in the near future to support this use case better.
|
||||
A Google Map visualization, originally intended primarily for debugging purposes, matured to a useful tool used by commentators and spectators alike, combined with charts showing wind and competitor data, and of course the traditional live leaderboard. The leaderboard itself received various enhancements over time, including data about maneuvers such as tacks, jibes and penalty circles, and additional figures such as the average cross-track error which under shifty wind conditions in some boat classes may be an indicator for the risk taken by a competitor. Some of these figures turned out to be quite expensive to compute. Therefore, in a few cases we deviated from the original approach where everything was computed on the fly upon receiving a request. Instead, the more expensive calculations in live mode now happen asynchronously in the background, and client requests are fulfilled with whatever the most current result for these figures is.
|
||||
|
||||
The REST/JSON APIs offered by the Java back-end have been exploited by at least two additional show-case scenarios. Already in 2011, Business Objects Dashboards displayed data extracted through these interfaces in various analytical views. In 2012, the interfaces started to be used for repeated extraction of data into a HANA database on top of which Experience UI technology is now used for visualization with sophisticated analyses.
|
||||
|
||||
In 2012, a mobile application to support the race committees in their functions has been developed using largely the same architecture. Although the server for this app currently runs in a separate process, it uses largely the same code base, versioning repository and build process. We plan to integrate it with the SAP Sailing Analytics soon. A first loose coupling will allow users of the mobile app to send wind data entered on a mobile device into the SAP Sailing Analytics back-end where it augments the wind-based calculations. Later, we plan to integrate the mobile app even closer so that it supports race officials in laying and moving marks, changing the course layout as well as detecting and announcing disqualifications.
|
||||
|
||||
The remainder of this document explains the key architectural principles on which the SAP Sailing Analytics have been developed. It is to be considered a snapshot of the status quo, as documented by the time stamp in the document's header.
|
||||
# Architecture and Infrastructure
|
||||
|
||||
### Table of Contents
|
||||
|
||||
* [[Runtime Environment|wiki/runtime-environment]]
|
||||
* [[Basic Architectural Principles|wiki/basic-architectural-principles]]
|
||||
* [[Development Environment|wiki/development-environment]]
|
||||
* [[Production Environment|wiki/production-environment]]
|
||||
* [[Typical Development Scenarios|wiki/typical-development-scenarios]]
|
||||
|
||||
## Introduction, Project Background and History
|
||||
|
||||
The SAP Sailing Analytics are a technology show-case demonstrating SAP technologies, concepts, skills and values applied to the domain of regatta sailing. They started as a small tool primarily intended to support a commentator in his job by displaying a live leaderboard for a sailing regatta with data interesting for the commentary. GPS and wind data travel from sensors to the server where the application keeps it in memory. When a request for a leaderboard is received, the data is aggregated on the fly, performing geometric computations including wind projections and involving a virtual "advantage line" orthogonal to the wind direction.
|
||||
|
||||
The live leaderboard started as a web application with a Java back-end responsible for the connectivity with the sensors and providing the geometry engine, and a Python process rendering the Web UI for the client's browser. The Python process issued REST requests to the Java back-end which responded with JSON documents.
|
||||
|
||||
The solution was first shown at Kieler Woche 2011. At the time, it was capable of displaying a single leaderboard that showed a number of tracked races in numerical form, offering columns for overall rank, race rank, rank at a mark, and values for average speed, distance traveled, gap to leader in seconds, velocity made good (VMG), estimated time of arrival at the next mark and current speed over ground. It was prototypical in many regards but regardless was considered an improvement for the commentary. The sailors liked it too because for the first time they could see numerical evidence of their choices of speed over distance.
|
||||
|
||||
After Kieler Woche 2011, the architecture changed. We removed the Python engine and used the Google Web Toolkit instead to render the Web UI directly in the Java process. A first new live leaderboard with this approach was shown at the IDM Travemünde 2011 and later at the MdM Hamburg 2011 events. Over time, the solution learned to manage multiple leaderboards, combining historic race analysis with live tracking. Particularly the accumulation of historic race data will require changes in the architecture in the near future to support this use case better.
|
||||
A Google Map visualization, originally intended primarily for debugging purposes, matured to a useful tool used by commentators and spectators alike, combined with charts showing wind and competitor data, and of course the traditional live leaderboard. The leaderboard itself received various enhancements over time, including data about maneuvers such as tacks, jibes and penalty circles, and additional figures such as the average cross-track error which under shifty wind conditions in some boat classes may be an indicator for the risk taken by a competitor. Some of these figures turned out to be quite expensive to compute. Therefore, in a few cases we deviated from the original approach where everything was computed on the fly upon receiving a request. Instead, the more expensive calculations in live mode now happen asynchronously in the background, and client requests are fulfilled with whatever the most current result for these figures is.
|
||||
|
||||
The REST/JSON APIs offered by the Java back-end have been exploited by at least two additional show-case scenarios. Already in 2011, Business Objects Dashboards displayed data extracted through these interfaces in various analytical views. In 2012, the interfaces started to be used for repeated extraction of data into a HANA database on top of which Experience UI technology is now used for visualization with sophisticated analyses.
|
||||
|
||||
In 2012, a mobile application to support the race committees in their functions has been developed using largely the same architecture. Although the server for this app currently runs in a separate process, it uses largely the same code base, versioning repository and build process. We plan to integrate it with the SAP Sailing Analytics soon. A first loose coupling will allow users of the mobile app to send wind data entered on a mobile device into the SAP Sailing Analytics back-end where it augments the wind-based calculations. Later, we plan to integrate the mobile app even closer so that it supports race officials in laying and moving marks, changing the course layout as well as detecting and announcing disqualifications.
|
||||
|
||||
The remainder of this document explains the key architectural principles on which the SAP Sailing Analytics have been developed. It is to be considered a snapshot of the status quo, as documented by the time stamp in the document's header.
|
||||
|
||||
See also this [[presentation|https://git.wdf.sap.corp:50000/git/?p=SAPSail/sapsailingcapture.git;a=blob;f=doc/SAPSailingAnalyticsArchitecture.pptx;h=f304746a0092410f0bf625292a7ae363d6d05f15;hb=8010ce3ebcd0df0d3fcd1651f87d79724f667377]] that provides an overview of the project's architecture and history.
|
||||
+68
-56
@@ -1,56 +1,68 @@
|
||||
# Cook Book with useful recipes
|
||||
|
||||
[[_TOC_]]
|
||||
|
||||
### Export from MongoDB
|
||||
|
||||
To export data from MongoDB you simply have to use the monogexport command. It will export data to human readable JSON format. Make absolutely sure to use fields backed by an index in your query otherwise it can put MongoDB under heavy load and take ages.
|
||||
|
||||
`/opt/mongodb/bin/mongoexport --port 10202 -d winddb -c WIND_TRACKS -q "{'REGATTA_NAME': 'ESS 2013 Muscat (Extreme40)'}" > tmp/ess2013-muscat-wind.json`
|
||||
|
||||
### Import to MongoDB
|
||||
|
||||
Importing requires data to be in JSON format (as exported by mongoexport). To make sure that old entries just get updated and not overwritten you must use the --upsert parameter.
|
||||
|
||||
`/opt/mongodb/bin/mongoimport --port 10202 -d winddb -c WIND_TRACKS --upsert tmp/ess2013-muscat-wind.json`
|
||||
|
||||
### Hot Deploy Java Packages to a running Server
|
||||
|
||||
Sometimes you need to deploy code to a running OSGi server without restarting the whole process. To ease this process the script buildAndUpdateProduct.sh provides an action called _hot-deploy_. To deploy a changed package you first need to know the fully qualified name. In most cases (for com.sap* packages) this corresponds to the package name (e.g. com.sap.sailing.gwt.ui). To hot-deploy the package _com.sap.sailing.server.gateway_ one can use the following call:
|
||||
|
||||
`buildAndUpdateProduct.sh -n com.sap.sailing.server.gateway hot-deploy`
|
||||
|
||||
This will first check if versions really differ and tell you the versions (installed, to-be-deployed). You can then decide to execute deployment. Deployment will not overwrite the old package but copy the new package to $SERVER_HOME/plugins/deploy. If the OSGi server is reachable on a telnet port (that you can specify with -p parameter) then you don't need to worry about the OSGi reload process it will be performed automagically. If no server can be reached then you'll get detailed instructions on how to install new package. It will then look like this:
|
||||
|
||||
<pre>
|
||||
PROJECT_HOME is /Users/spamies/Projects/sailing/code
|
||||
SERVERS_HOME is /Users/spamies/Projects/sailing/servers
|
||||
OLD bundle is com.sap.sailing.monitoring with version 1.0.0.201303252301
|
||||
NEW bundle is com.sap.sailing.monitoring with version 1.0.0.201303252302
|
||||
|
||||
Do you really want to hot-deploy bundle com.sap.sailing.monitoring to /Users/spamies/Projects/sailing/code/master? (y/N): Continuing
|
||||
Copied com.sap.sailing.monitoring_1.0.0.201303252302.jar to /Users/spamies/Projects/sailing/servers/master/plugins/deploy
|
||||
|
||||
ERROR: Could not find any process running on port . Make sure your server has been started with -console
|
||||
I've already deployed bundle to /Users/spamies/Projects/sailing/servers/master/plugins/deploy/com.sap.sailing.monitoring_1.0.0.201303252302.jar
|
||||
You can now install it yourself by issuing the following commands:
|
||||
|
||||
osgi> ss com.sap.sailing.monitoring
|
||||
21 ACTIVE com.sap.sailing.monitoring_1.0.0.201303252302
|
||||
osgi> stop 21
|
||||
osgi> uninstall 21
|
||||
osgi> install file:///Users/spamies/Projects/sailing/servers/master/plugins/deploy/com.sap.sailing.monitoring_1.0.0.201303252302.jar
|
||||
osgi> ss com.sap.sailing.monitoring
|
||||
71 INSTALLED com.sap.sailing.monitoring_1.0.0.201303252302
|
||||
osgi> start 71
|
||||
</pre>
|
||||
|
||||
### Display Line Endings for File
|
||||
|
||||
Sometimes different line endings get mixed. To display all lin endings for each line of a given file use the following command:
|
||||
|
||||
`perl -p -e 's[\r\n][WIN\n]; s[(?<!WIN)\n][UNIX\n]; s[\r][MAC\n];' <FILE>`
|
||||
|
||||
### Finding Packages for Deployment in Target Platform
|
||||
|
||||
Sometimes you want to add libraries to the target platform but you don't have correctly formatted JAR files. In this case you can find some files here: [Eclipse ORBIT](http://download.eclipse.org/tools/orbit/downloads/drops/R20130118183705/)
|
||||
# Cook Book with useful recipes
|
||||
|
||||
[[_TOC_]]
|
||||
|
||||
### Export from MongoDB
|
||||
|
||||
To export data from MongoDB you simply have to use the monogexport command. It will export data to human readable JSON format. Make absolutely sure to use fields backed by an index in your query otherwise it can put MongoDB under heavy load and take ages.
|
||||
|
||||
#### Wind
|
||||
|
||||
`/opt/mongodb/bin/mongoexport --port 10202 -d winddb -c WIND_TRACKS -q "{'REGATTA_NAME': 'ESS 2013 Muscat (Extreme40)'}" > /tmp/ess2013-muscat-wind.json`
|
||||
|
||||
#### Score Corrections
|
||||
|
||||
`/opt/mongodb/bin/mongoexport --port 10202 -d winddb -c LEADERBOARDS -q "{LEADERBOARD_NAME: 'ESS 2013 Singapore (Extreme40)'}" > /tmp/singapore.json`
|
||||
|
||||
### Import to MongoDB
|
||||
|
||||
Importing requires data to be in JSON format (as exported by mongoexport). To make sure that old entries just get updated and not overwritten you must use the --upsert parameter.
|
||||
|
||||
#### Wind
|
||||
|
||||
`/opt/mongodb/bin/mongoimport --port 10202 -d winddb -c WIND_TRACKS --upsert /tmp/ess2013-muscat-wind.json`
|
||||
|
||||
#### Score Corrections
|
||||
|
||||
`/opt/mongodb/bin/mongoimport --port 10202 -d winddb -c LEADERBOARDS --upsert /tmp/singapore.json`
|
||||
|
||||
### Hot Deploy Java Packages to a running Server
|
||||
|
||||
Sometimes you need to deploy code to a running OSGi server without restarting the whole process. To ease this process the script buildAndUpdateProduct.sh provides an action called _hot-deploy_. To deploy a changed package you first need to know the fully qualified name. In most cases (for com.sap* packages) this corresponds to the package name (e.g. com.sap.sailing.gwt.ui). To hot-deploy the package _com.sap.sailing.server.gateway_ one can use the following call:
|
||||
|
||||
`buildAndUpdateProduct.sh -l telnetPortOfServerInstance -n com.sap.sailing.server.gateway hot-deploy`
|
||||
|
||||
This will first check if versions really differ and tell you the versions (installed, to-be-deployed). You can then decide to execute deployment. Deployment will not overwrite the old package but copy the new package to $SERVER_HOME/plugins/deploy. If the OSGi server is reachable on a telnet port (that you can specify with -p parameter) then you don't need to worry about the OSGi reload process it will be performed automagically. If no server can be reached then you'll get detailed instructions on how to install new package. It will then look like this:
|
||||
|
||||
<pre>
|
||||
PROJECT_HOME is /Users/spamies/Projects/sailing/code
|
||||
SERVERS_HOME is /Users/spamies/Projects/sailing/servers
|
||||
OLD bundle is com.sap.sailing.monitoring with version 1.0.0.201303252301
|
||||
NEW bundle is com.sap.sailing.monitoring with version 1.0.0.201303252302
|
||||
|
||||
Do you really want to hot-deploy bundle com.sap.sailing.monitoring to /Users/spamies/Projects/sailing/code/master? (y/N): Continuing
|
||||
Copied com.sap.sailing.monitoring_1.0.0.201303252302.jar to /Users/spamies/Projects/sailing/servers/master/plugins/deploy
|
||||
|
||||
ERROR: Could not find any process running on port . Make sure your server has been started with -console
|
||||
I've already deployed bundle to /Users/spamies/Projects/sailing/servers/master/plugins/deploy/com.sap.sailing.monitoring_1.0.0.201303252302.jar
|
||||
You can now install it yourself by issuing the following commands:
|
||||
|
||||
osgi> ss com.sap.sailing.monitoring
|
||||
21 ACTIVE com.sap.sailing.monitoring_1.0.0.201303252302
|
||||
osgi> stop 21
|
||||
osgi> uninstall 21
|
||||
osgi> install file:///Users/spamies/Projects/sailing/servers/master/plugins/deploy/com.sap.sailing.monitoring_1.0.0.201303252302.jar
|
||||
osgi> ss com.sap.sailing.monitoring
|
||||
71 INSTALLED com.sap.sailing.monitoring_1.0.0.201303252302
|
||||
osgi> start 71
|
||||
</pre>
|
||||
|
||||
### Display Line Endings for File
|
||||
|
||||
Sometimes different line endings get mixed. To display all lin endings for each line of a given file use the following command:
|
||||
|
||||
`perl -p -e 's[\r\n][WIN\n]; s[(?<!WIN)\n][UNIX\n]; s[\r][MAC\n];' <FILE>`
|
||||
|
||||
### Finding Packages for Deployment in Target Platform
|
||||
|
||||
Sometimes you want to add libraries to the target platform but you don't have correctly formatted JAR files. In this case you can find some files here: [Eclipse ORBIT](http://download.eclipse.org/tools/orbit/downloads/drops/R20130118183705/)
|
||||
+119
-99
@@ -1,100 +1,120 @@
|
||||
# Specifica for the Extreme Sailing Series
|
||||
|
||||
[[_TOC_]]
|
||||
|
||||
The Extreme Sailing Series is a hospitality event that aims to make invitees participate as close as possible at a sailing race. To achieve this goal the races take place in front of a tribune placed directly at the water (called Stadium Racing). Invitees can be assigned to a boat crew and that way be part of a race like it is not possible in any other series.
|
||||
|
||||
Each race has a course that is set that way that spectators can see as much as possible regardless of the wind direction (upwind start not to be implied). The event is set to span a week, racing happens on 4 or 5 days. Every day up to 10 races take place depending on the wind conditions. Race course is defined such that a race lasts (under normal conditions) not longer than 20 minutes.
|
||||
|
||||
Usually not more than 8 competitors race against each other. One of the competitors is always an invitational team from the local spot that is allowed to race.
|
||||
|
||||
## External Links
|
||||
|
||||
* [Extreme Sailing Series Offical Website](http://www.extremesailingseries.com/)
|
||||
* [Official Results](http://www.extremesailingseries.com/results)
|
||||
* [Analytics Homepage](http://ess40-2013.sapsailing.com/)
|
||||
* [Youtube Channel](http://www.youtube.com/user/ExtremeSailingSeries)
|
||||
|
||||
## Notice of Race
|
||||
The current notice of race can be downloaded by using the link below. It is worth to mention that the NOR lacks the information about the fact that the last race breaks tie break.
|
||||
|
||||
Download [[Notice of Race 2013 Final|wiki/uploads/NOR2013_ESS_final.pdf]]
|
||||
|
||||
## Boats
|
||||
To achieve the goal of providing invitees an exciting event a new type of boats have been designed. Capable of reaching speeds usually reserved to motorboats even in medium wind conditions, the Extreme 40 has been designed by Olympic champions Yves Loday and Mitch Booth, with the aim to provide the international sailing arena with a visually stunning and 100% performance-focused multihull.
|
||||
|
||||
<img src="/wiki/images/ESSSAPBoat.jpg" height="325px" width="600px"/>
|
||||
|
||||
Flying a hull in as little as 8 knots of breeze (15 kph), the 40-foot (12m) long carbon speed machine requires coordination, finesse but also sheer muscular power from the crews who battle it out. The generous sail area allows the Extreme 40s to sail faster than the wind, which might seem puzzling at first - in just 15 knots of wind, an Extreme 40 is capable of traveling at over 25 knots
|
||||
|
||||
## Scoring
|
||||
Each race is scored using a high point system where the winner gets 10 points, the second gets 9 and so on (going not further than 3 points). At the end of an event the last race points get doubled (20 for the winner). If there is a tie break between two competitors then the last race sets the winner (breaks tie break). Points from each race are accumulated and result in the overall score for an event.
|
||||
|
||||
In addition to the overall leaderboard specific to an event a global leaderboard is being maintained that denotes positions for all events during a year. This scoring scheme used for the global leaderboard has the same rules as an event specific leaderboard. The winner of an event gets 10 points and so on.
|
||||
|
||||
<img src="/wiki/images/ESSLeaderboardMuscat.jpg"/>
|
||||
|
||||
Scoring can be altered by the race committee using standard rules like DNS (DidNotStart), DNF (DidNotFinish), DNC (DidNotCount) or RDG (RedressGiven). These rules (except the last one) usually lead to a score of 0 for the race.
|
||||
|
||||
## Event Setup
|
||||
The setup for such an event usually consists of the following departments:
|
||||
|
||||
* Race Committee
|
||||
* Boat on the water
|
||||
* On the beach
|
||||
* Commentator
|
||||
* For online streaming and video (beach)
|
||||
* Live (beach)
|
||||
* Video and Television
|
||||
* Cameras (water)
|
||||
* Camera (beach)
|
||||
* Tech team (Controller, Cutter, Streamer)
|
||||
* Visualization
|
||||
* Provider for GPS fixes, course layout and competitor names (TracTrac)
|
||||
* 3D Visualization provider (BeTomorrow)
|
||||
* Wind information (SAP)
|
||||
* Live and official result provider (SAP Sailing Analytics)
|
||||
|
||||
## Technical Architecture
|
||||
For the department of Visualization the technical infrastructure can be divided into three major parts.
|
||||
|
||||
1. The first parts (CLOUD) contains external servers accessible over the internet. The main purpose of these servers is to serve as the endpoint for data sent by various tracking systems. The setup of tracking systems consists of the following three trackers:
|
||||
* A wind tracking system that can transfer information about direction and strength. The transfer is only possible using a publicly accessible IP address.
|
||||
* A system transferring buoy positions (GPS fixes) over TCP. This system also can only be configured to transfer data over a TCP channel identified by an IP address.
|
||||
* A tracker that is attached to each boat and that transfers GPS fixes in an regular interval. For this tracker the same limitation as above regarding the addressable endpoint holds
|
||||
|
||||
2. The second part (ON PREMISE INTERNAL) contains all components that are needed to provide analytics. Data sent by trackers to the cloud is retrieved in this section and being analyzed. The connections to TV streaming and other visualization providers takes place here.
|
||||
|
||||
3. The third part (ON PREMISE PUBLIC) describes all components analytical data are distributed on during an event. This includes private mobile phones, iPads being available for guests, flatscreens displaying leaderboards and tv streaming.
|
||||
|
||||
### Actual (Muscat 2013)
|
||||
The actual setup is depicted in the following image. It is easy to see that all of the components in the ON PREMISE PUBLIC area are heavily dependent on a reliable internet connection. This becomes also problematic when the connection is slow because display of analytics requires some bandwidth.
|
||||
|
||||
<img src="/wiki/images/ESSSetupIST.jpg"/>
|
||||
|
||||
### Target (Singapore 2013?)
|
||||
The following image depicts the setup that is desirable for the next events but not yet implemented. It features a local setup where the dependency on a reliable and fast internet connection is minimized as much as possible.
|
||||
|
||||
The core of this setup is a server that not only hosts a SAP Sailing Analytics but also the TracTrac server. This way the distribution of analytical information is not dependent on the speed and bandwidth of the local internet connection. By adding a DNS server in front of this analytics server local requests can be directed to the local server even when guests use a public internet address (e.g. www.sapsailing.com).
|
||||
|
||||
In case of a problem with the local server requests can be redirected to the external analytics server. This server is constantly fed with data by a replication channel that gets information bits from the local analytics server.
|
||||
|
||||
The main changes to the actual setup are as follows:
|
||||
|
||||
* The SAP Sailing Analytics server that is authoritative for computing the results is no longer in the cloud but installed on premise. That way it is no longer dependent on a replicated TracTrac server but gets data directly from local TracTrac server.
|
||||
* TracTrac Server is integrated with SAP Sailing Analytics on one physical appliance. That eases maintenance and data exchange between SAP and TracTrac services.
|
||||
* Every leaderboard related information is gathered by accessing the local server. That way the dependency from the internet is drastically mitigated. Everyone on site always gets the right information without delay.
|
||||
* A routing server manages the DNS resolution and in case of a local failure is able to transparently redirect data to the cloud.
|
||||
* Score corrections also are not longer dependent on the internet connection but get fed directly into the local server.
|
||||
* Wind information for BeTomorrow can be provided without internet connection.
|
||||
|
||||
Two weak points still remain (highlighted by red dotted lines):
|
||||
|
||||
1. Wind data must be sent to a server that is reachable by a public ip address. This problem could be solved by extending the main router with 3G/4G functionality and putting the SAP Sailing Analytics server into DMZ.
|
||||
2. The same holds for buoy positions.
|
||||
|
||||
<img src="/wiki/images/ESSSetupSOLL.jpg"/>
|
||||
|
||||
To not be dependent on a shaky power source that can be restored by "wiggling pieces a little to fix the generator" it has been decided to introduce UPS that can fed important hardware with power up to half an hour. The following picture depicts a quick shot on how this could look like.
|
||||
|
||||
# Specifica for the Extreme Sailing Series
|
||||
|
||||
[[_TOC_]]
|
||||
|
||||
The Extreme Sailing Series is a hospitality event that aims to make invitees participate as close as possible at a sailing race. To achieve this goal the races take place in front of a tribune placed directly at the water (called Stadium Racing). Invitees can be assigned to a boat crew and that way be part of a race like it is not possible in any other series.
|
||||
|
||||
Each race has a course that is set that way that spectators can see as much as possible regardless of the wind direction (upwind start not to be implied). The event is set to span a week, racing happens on 4 or 5 days. Every day up to 10 races take place depending on the wind conditions. Race course is defined such that a race lasts (under normal conditions) not longer than 20 minutes.
|
||||
|
||||
Usually not more than 8 competitors race against each other. One of the competitors is always an invitational team from the local spot that is allowed to race.
|
||||
|
||||
## External Links
|
||||
|
||||
* [Extreme Sailing Series Offical Website](http://www.extremesailingseries.com/)
|
||||
* [Official Results](http://www.extremesailingseries.com/results)
|
||||
* [Analytics Homepage](http://ess40-2013.sapsailing.com/)
|
||||
* [Youtube Channel](http://www.youtube.com/user/ExtremeSailingSeries)
|
||||
|
||||
## Equipment Needed
|
||||
|
||||
* **From WDF**
|
||||
* 1x Smartphone
|
||||
* 5x SIM Cards
|
||||
* 1x World Adapter
|
||||
* 1x Plug Strip
|
||||
* **In Container**
|
||||
* 1x Toughbook
|
||||
* 2x Samsung Tablet
|
||||
* 1x iPad
|
||||
* Expedition Wind Kit
|
||||
* **In Container (after Qingdao)**
|
||||
* 1x TFT
|
||||
* 1x USB-Keyboard
|
||||
* 1x USB-Mouse
|
||||
* 2x Switch (8 Port)
|
||||
* 1x Router (TP-Link)
|
||||
* 3x CAT6 Network Cable
|
||||
|
||||
## Notice of Race
|
||||
The current notice of race can be downloaded by using the link below. It is worth to mention that the NOR lacks the information about the fact that the last race breaks tie break.
|
||||
|
||||
Download [[Notice of Race 2013 Final|wiki/uploads/NOR2013_ESS_final.pdf]]
|
||||
|
||||
## Boats
|
||||
To achieve the goal of providing invitees an exciting event a new type of boats have been designed. Capable of reaching speeds usually reserved to motorboats even in medium wind conditions, the Extreme 40 has been designed by Olympic champions Yves Loday and Mitch Booth, with the aim to provide the international sailing arena with a visually stunning and 100% performance-focused multihull.
|
||||
|
||||
<img src="/wiki/images/ESSSAPBoat.jpg" height="325px" width="600px"/>
|
||||
|
||||
Flying a hull in as little as 8 knots of breeze (15 kph), the 40-foot (12m) long carbon speed machine requires coordination, finesse but also sheer muscular power from the crews who battle it out. The generous sail area allows the Extreme 40s to sail faster than the wind, which might seem puzzling at first - in just 15 knots of wind, an Extreme 40 is capable of traveling at over 25 knots
|
||||
|
||||
## Scoring
|
||||
Each race is scored using a high point system where the winner gets 10 points, the second gets 9 and so on (going not further than 3 points). At the end of an event the last race points get doubled (20 for the winner). If there is a tie break between two competitors then the last race sets the winner (breaks tie break). Points from each race are accumulated and result in the overall score for an event.
|
||||
|
||||
In addition to the overall leaderboard specific to an event a global leaderboard is being maintained that denotes positions for all events during a year. This scoring scheme used for the global leaderboard has the same rules as an event specific leaderboard. The winner of an event gets 10 points and so on.
|
||||
|
||||
<img src="/wiki/images/ESSLeaderboardMuscat.jpg"/>
|
||||
|
||||
Scoring can be altered by the race committee using standard rules like DNS (DidNotStart), DNF (DidNotFinish), DNC (DidNotCount) or RDG (RedressGiven). These rules (except the last one) usually lead to a score of 0 for the race.
|
||||
|
||||
## Event Setup
|
||||
The setup for such an event usually consists of the following departments:
|
||||
|
||||
* Race Committee
|
||||
* Boat on the water
|
||||
* On the beach
|
||||
* Commentator
|
||||
* For online streaming and video (beach)
|
||||
* Live (beach)
|
||||
* Video and Television
|
||||
* Cameras (water)
|
||||
* Camera (beach)
|
||||
* Tech team (Controller, Cutter, Streamer)
|
||||
* Visualization
|
||||
* Provider for GPS fixes, course layout and competitor names (TracTrac)
|
||||
* 3D Visualization provider (BeTomorrow)
|
||||
* Wind information (SAP)
|
||||
* Live and official result provider (SAP Sailing Analytics)
|
||||
|
||||
## Technical Architecture
|
||||
For the department of Visualization the technical infrastructure can be divided into three major parts.
|
||||
|
||||
1. The first parts (CLOUD) contains external servers accessible over the internet. The main purpose of these servers is to serve as the endpoint for data sent by various tracking systems. The setup of tracking systems consists of the following three trackers:
|
||||
* A wind tracking system that can transfer information about direction and strength. The transfer is only possible using a publicly accessible IP address.
|
||||
* A system transferring buoy positions (GPS fixes) over TCP. This system also can only be configured to transfer data over a TCP channel identified by an IP address.
|
||||
* A tracker that is attached to each boat and that transfers GPS fixes in an regular interval. For this tracker the same limitation as above regarding the addressable endpoint holds
|
||||
|
||||
2. The second part (ON PREMISE INTERNAL) contains all components that are needed to provide analytics. Data sent by trackers to the cloud is retrieved in this section and being analyzed. The connections to TV streaming and other visualization providers takes place here.
|
||||
|
||||
3. The third part (ON PREMISE PUBLIC) describes all components analytical data are distributed on during an event. This includes private mobile phones, iPads being available for guests, flatscreens displaying leaderboards and tv streaming.
|
||||
|
||||
### Actual (Muscat 2013)
|
||||
The actual setup is depicted in the following image. It is easy to see that all of the components in the ON PREMISE PUBLIC area are heavily dependent on a reliable internet connection. This becomes also problematic when the connection is slow because display of analytics requires some bandwidth.
|
||||
|
||||
<img src="/wiki/images/ESSSetupIST.jpg"/>
|
||||
|
||||
### Target (Singapore 2013?)
|
||||
The following image depicts the setup that is desirable for the next events but not yet implemented. It features a local setup where the dependency on a reliable and fast internet connection is minimized as much as possible.
|
||||
|
||||
The core of this setup is a server that not only hosts a SAP Sailing Analytics but also the TracTrac server. This way the distribution of analytical information is not dependent on the speed and bandwidth of the local internet connection. By adding a DNS server in front of this analytics server local requests can be directed to the local server even when guests use a public internet address (e.g. www.sapsailing.com).
|
||||
|
||||
In case of a problem with the local server requests can be redirected to the external analytics server. This server is constantly fed with data by a replication channel that gets information bits from the local analytics server.
|
||||
|
||||
The main changes to the actual setup are as follows:
|
||||
|
||||
* The SAP Sailing Analytics server that is authoritative for computing the results is no longer in the cloud but installed on premise. That way it is no longer dependent on a replicated TracTrac server but gets data directly from local TracTrac server.
|
||||
* TracTrac Server is integrated with SAP Sailing Analytics on one physical appliance. That eases maintenance and data exchange between SAP and TracTrac services.
|
||||
* Every leaderboard related information is gathered by accessing the local server. That way the dependency from the internet is drastically mitigated. Everyone on site always gets the right information without delay.
|
||||
* A routing server manages the DNS resolution and in case of a local failure is able to transparently redirect data to the cloud.
|
||||
* Score corrections also are not longer dependent on the internet connection but get fed directly into the local server.
|
||||
* Wind information for BeTomorrow can be provided without internet connection.
|
||||
|
||||
Two weak points still remain (highlighted by red dotted lines):
|
||||
|
||||
1. Wind data must be sent to a server that is reachable by a public ip address. This problem could be solved by extending the main router with 3G/4G functionality and putting the SAP Sailing Analytics server into DMZ.
|
||||
2. The same holds for buoy positions.
|
||||
|
||||
<img src="/wiki/images/ESSSetupSOLL.jpg"/>
|
||||
|
||||
To not be dependent on a shaky power source that can be restored by "wiggling pieces a little to fix the generator" it has been decided to introduce UPS that can fed important hardware with power up to half an hour. The following picture depicts a quick shot on how this could look like.
|
||||
|
||||
<img src="/wiki/images/ESSSetupUPS.jpg"/>
|
||||
@@ -1,88 +1,88 @@
|
||||
# General Plan for Events
|
||||
|
||||
This document should depict the infrastructure used for upcoming events. The main goal is to make sure that parallel events do not interfere. Please make sure to fill every column.
|
||||
|
||||
<table>
|
||||
<thead>
|
||||
<tr>
|
||||
<th>Name</th>
|
||||
<th>Date</th>
|
||||
<th>Physical Server</th>
|
||||
<th>Java Server</th>
|
||||
<th>Java Backup Server</th>
|
||||
<th>TMUX Session</th>
|
||||
<th>Official URL</th>
|
||||
<th>Provider</th>
|
||||
<th>MongoDB Port Port</th>
|
||||
<th>Wind Port</th>
|
||||
<th>Officer</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>ESS Muscat</th>
|
||||
<th>04.03.2013-09.03.2013</th>
|
||||
<th>http://sapcoe-app01.pironet-ndh.com/ (195.227.10.246)</th>
|
||||
<th>PROD1 (8889)</th>
|
||||
<th>TEST (8887)</th>
|
||||
<th>sailing</th>
|
||||
<th>http://ess40-2013.sapsailing.com</th>
|
||||
<th>TracTrac</th>
|
||||
<th>10202</th>
|
||||
<th>2014</th>
|
||||
<th>Axel</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>ESS Singapore</th>
|
||||
<th>08.04.2013-14.04.2013</th>
|
||||
<th>http://sapcoe-app01.pironet-ndh.com/ (195.227.10.246)</th>
|
||||
<th>PROD1 (8889)</th>
|
||||
<th>TEST (8887)</th>
|
||||
<th>sailing</th>
|
||||
<th>http://ess40-2013.sapsailing.com</th>
|
||||
<th>TracTrac</th>
|
||||
<th>10202</th>
|
||||
<th>2014</th>
|
||||
<th>Simon</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>ESS Qingdao</th>
|
||||
<th>29.04.2013-05.05.2013</th>
|
||||
<th>http://sapcoe-template01.pironet-ndh.com/ (195.227.44.85)</th>
|
||||
<th>PROD1 (8889)</th>
|
||||
<th>TEST (8887)</th>
|
||||
<th>sailing</th>
|
||||
<th>http://ess40-2013.sapsailing.com</th>
|
||||
<th>TracTrac</th>
|
||||
<th>10202</th>
|
||||
<th>2014</th>
|
||||
<th>Simon</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>505 Barbados</th>
|
||||
<th>??</th>
|
||||
<th>??)</th>
|
||||
<th>??</th>
|
||||
<th>??</th>
|
||||
<th>??</th>
|
||||
<th>??</th>
|
||||
<th>??</th>
|
||||
<th>??</th>
|
||||
<th>??</th>
|
||||
<th>Axel</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>Star IDM</th>
|
||||
<th>??</th>
|
||||
<th>??</th>
|
||||
<th>??</th>
|
||||
<th>??</th>
|
||||
<th>??</th>
|
||||
<th>??</th>
|
||||
<th>??</th>
|
||||
<th>??</th>
|
||||
<th>??</th>
|
||||
<th>Frank</th>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
# General Plan for Events
|
||||
|
||||
This document should depict the infrastructure used for upcoming events. The main goal is to make sure that parallel events do not interfere. Please make sure to fill every column.
|
||||
|
||||
<table>
|
||||
<thead>
|
||||
<tr>
|
||||
<th>Name</th>
|
||||
<th>Date</th>
|
||||
<th>Physical Server</th>
|
||||
<th>Java Server</th>
|
||||
<th>Java Backup Server</th>
|
||||
<th>TMUX Session</th>
|
||||
<th>Official URL</th>
|
||||
<th>Provider</th>
|
||||
<th>MongoDB Port Port</th>
|
||||
<th>Wind Port</th>
|
||||
<th>Officer</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody>
|
||||
<tr>
|
||||
<th>ESS Muscat</th>
|
||||
<th>04.03.2013-09.03.2013</th>
|
||||
<th>http://sapcoe-app01.pironet-ndh.com/ (195.227.10.246)</th>
|
||||
<th>PROD2 (8889)</th>
|
||||
<th>TEST (8887)</th>
|
||||
<th>sailing</th>
|
||||
<th>http://ess40-2013.sapsailing.com</th>
|
||||
<th>TracTrac</th>
|
||||
<th>10202</th>
|
||||
<th>2014</th>
|
||||
<th>Axel</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>ESS Singapore</th>
|
||||
<th>08.04.2013-14.04.2013</th>
|
||||
<th>http://sapcoe-app01.pironet-ndh.com/ (195.227.10.246)</th>
|
||||
<th>PROD2 (8889)</th>
|
||||
<th>TEST (8887)</th>
|
||||
<th>sailing</th>
|
||||
<th>http://ess40-2013.sapsailing.com</th>
|
||||
<th>TracTrac</th>
|
||||
<th>10202</th>
|
||||
<th>2014</th>
|
||||
<th>Simon</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>ESS Qingdao</th>
|
||||
<th>29.04.2013-05.05.2013</th>
|
||||
<th>http://sapcoe-template01.pironet-ndh.com/ (195.227.44.85)</th>
|
||||
<th>NEW-PROD2 (8889)</th>
|
||||
<th>NEW-TEST (8887)</th>
|
||||
<th>sailing</th>
|
||||
<th>http://ess40-2013.sapsailing.com</th>
|
||||
<th>TracTrac</th>
|
||||
<th>10202</th>
|
||||
<th>2014</th>
|
||||
<th>Simon</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>505 Barbados</th>
|
||||
<th>24.4.2013-3.5.2013</th>
|
||||
<th>http://sapcoe-app01.pironet-ndh.com (195.227.10.246)</th>
|
||||
<th>PROD2 (8889)</th>
|
||||
<th>TEST (8887)</th>
|
||||
<th>Telnet 14889 / 14887</th>
|
||||
<th>505worlds2013.sapsailing.com</th>
|
||||
<th>TracTrac</th>
|
||||
<th>10202</th>
|
||||
<th>2014</th>
|
||||
<th>Axel</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<th>Star IDM</th>
|
||||
<th>??</th>
|
||||
<th>??</th>
|
||||
<th>??</th>
|
||||
<th>??</th>
|
||||
<th>??</th>
|
||||
<th>??</th>
|
||||
<th>??</th>
|
||||
<th>??</th>
|
||||
<th>??</th>
|
||||
<th>Frank</th>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
@@ -0,0 +1,5 @@
|
||||
# Inventar Liste
|
||||
|
||||
Diese Inventar-Liste wird unter https://docs.google.com/spreadsheet/ccc?key=0AvwMi5dSxETfdDdieDkwY1FyVmRyRVV6TkFkOUNjOWc&usp=sharing gepflegt.
|
||||
|
||||
Sollte jemand keinen Zugriff haben, dann bitte eine E-Mail an spamsch@gmail.com.
|
||||
@@ -0,0 +1,58 @@
|
||||
# PIRONET
|
||||
|
||||
[[_TOC_]]
|
||||
|
||||
The provider for our servers is PIRONET. They are responsible in any case of emergency not related to our technology (like server crash or firewall). Currently they manage two servers that are important for the project.
|
||||
|
||||
- sapcoe-app01 (main server running all services)
|
||||
- sapcoe-template01 (backup server for data and servers)
|
||||
|
||||
You can find additional information here: [[Welcome Guide|wiki/uploads/WGuidePironet.pdf]]
|
||||
|
||||
### 24x7 Bereitschaft (Emergency)
|
||||
|
||||
- Tel. +49 (0) 2203 / 935 30 – 88
|
||||
- 24/7
|
||||
|
||||
You may need to provide the name "Simon Pamies" and the code "7772".
|
||||
|
||||
### Servicemanagement
|
||||
|
||||
- Thomas Engels
|
||||
- Tel. +49 (0) 2203 / 935 30 – 1548
|
||||
- Fax +49 (0) 2203 / 935 30 – 99
|
||||
- tengels@pironet-ndh.com
|
||||
- werktags 09.00 bis 18.00Uhr
|
||||
|
||||
Themenbereiche:
|
||||
- Konzeptionelle Anfragen
|
||||
- Anfragen zu Change Requests
|
||||
- Planung von Projekt- und Servicearbeiten
|
||||
|
||||
### Partner Manager
|
||||
|
||||
- Klaus Novitzky
|
||||
- Tel. +49(0)172 869 6867
|
||||
- knovitzky@pironet-ndh.com
|
||||
- werktags 09.00 bis 18.00Uhr
|
||||
|
||||
Themenbereiche:
|
||||
- Produktberatung
|
||||
- Preisanfragen
|
||||
- Angebotserstellung / Rechnungsprüfung
|
||||
|
||||
### Servicedesk
|
||||

|
||||
Informationen:
|
||||
- Tel. +49 (0) 2203 / 935 30 – 30
|
||||
- Fax +49 (0) 2203 / 935 30 – 90
|
||||
- servicedesk@pironet-ndh.com
|
||||
- werktags 08.00 bis 18.00Uhr
|
||||
|
||||
Themenbereiche:
|
||||
|
||||
- Vorfälle
|
||||
- Anfragen
|
||||
- ASPortal.workspace (CITRIX)
|
||||
- Rückfragen zum Bearbeitungsstand
|
||||
- Systemkritische Störungsmeldungen
|
||||
+239
-234
@@ -1,234 +1,239 @@
|
||||
# Production Environment
|
||||
|
||||
[[_TOC_]]
|
||||
|
||||
## General
|
||||
|
||||
Our current server deployment uses a 64bit Java7 Hotspot virtual machine and runs on a 64bit Linux CentOS distribution. We have a single host (sapsailing.com) which runs a number of Java VMs, some to offer the application in different development stages (dev, test, prod, ...), some to perform specific tasks such as replicating UDP wind data to the various server processes, or a process to store data received from the SwissTiming connector durably while forwarding that data to a server VM requesting it.
|
||||
|
||||
The various processes run in "tmux" sessions to which, once connected to sapsailing.com with an ssh client, users can gain access using the `tmux -2 attach-session -t sailing` command. The tmux environment including is started automagically upon system boot by invoking the script _/home/trac/servers/tmuxManagementConsole.sh_.
|
||||
|
||||
For the OSGi containers by convention we have one directory under _/home/trac/servers/_ per deployable branch (dev, test, prod1, prod2). In those directories we have copies of the "install" script from the git's java/target folder. Running it after a successful product build on the branch corresponding to the current directory will copy the compiled product to the server directory. Running the start script will then launch the respective server instance. A safety check in the install script avoids accidentally overwriting a server directory with a non-matching product version by comparing the directory name with the branch name checked out under _/home/trac/git_.
|
||||
|
||||
## Firewall
|
||||
The current firewall configuration is described in the following table. Firewall is maintained by PIRONET NDH. In order to change the configuration you have to sign a form ([[Click here to open it|wiki/uploads/Firewall-Freischaltungformular-v33-de.doc]]).
|
||||
|
||||
<table>
|
||||
<tr>
|
||||
<th>Source</th>
|
||||
<th>Target</th>
|
||||
<th>Port</th>
|
||||
<th>Type</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>ALL</td>
|
||||
<td>sapcoe-app01</td>
|
||||
<td>80</td>
|
||||
<td>TCP</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>ALL</td>
|
||||
<td>sapcoe-app01</td>
|
||||
<td>443</td>
|
||||
<td>TCP</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>ALL</td>
|
||||
<td>sapcoe-app01</td>
|
||||
<td>22</td>
|
||||
<td>TCP</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>sapcoe-app01</td>
|
||||
<td>ALL</td>
|
||||
<td>123</td>
|
||||
<td>TCP</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>ALL</td>
|
||||
<td>sapcoe-app01</td>
|
||||
<td>2010-1015</td>
|
||||
<td>UDP</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>ALL</td>
|
||||
<td>sapcoe-app01</td>
|
||||
<td>21</td>
|
||||
<td>TCP</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>ALL</td>
|
||||
<td>sapcoe-app01</td>
|
||||
<td>5672</td>
|
||||
<td>TCP</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>sapcoe-app01</td>
|
||||
<td>78.46.86.151</td>
|
||||
<td>ALL</td>
|
||||
<td>TCP+UDP</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>sapcoe-app01</td>
|
||||
<td>46.4.29.12</td>
|
||||
<td>ALL</td>
|
||||
<td>TCP+UDP</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>sapcoe-app01</td>
|
||||
<td>89.233.27.2</td>
|
||||
<td>ALL</td>
|
||||
<td>TCP+UDP</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>sapcoe-app01</td>
|
||||
<td>gps.sportresult.com</td>
|
||||
<td>40300</td>
|
||||
<td>TCP+UDP</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
## Services
|
||||
|
||||
Services are vital for the infrastructure. The following sections describe location of configuration and special behaviour.
|
||||
|
||||
### Java Servers
|
||||
|
||||
To ensure availability and to be able to separate servers holding historical data and live data there are a bunch of preconfigured java servers.
|
||||
|
||||
<table>
|
||||
<tr>
|
||||
<th>Name</th>
|
||||
<th>HTTP</th>
|
||||
<th>MongoDB Port</th>
|
||||
<th>MongoDB Path</th>
|
||||
<th>Replication Channel</th>
|
||||
<th>Expedition UDP Port</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>DEV</td>
|
||||
<td>8886</td>
|
||||
<td>10200</td>
|
||||
<td>/opt/mongodb/data/mongodb-dev</td>
|
||||
<td>sapsailinganalytics-dev</td>
|
||||
<td>2010</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>TEST</td>
|
||||
<td>8887</td>
|
||||
<td>10201</td>
|
||||
<td>/opt/mongodb/data/mongodb-test</td>
|
||||
<td>sapsailinganalytics-test</td>
|
||||
<td>2011</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>PROD1</td>
|
||||
<td>8888</td>
|
||||
<td>10202</td>
|
||||
<td>/opt/mongodb/data/mongodb-prod</td>
|
||||
<td>sapsailinganalytics-prod1</td>
|
||||
<td>2013</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>PROD2</td>
|
||||
<td>8889</td>
|
||||
<td>10202</td>
|
||||
<td>/opt/mongodb/data/mongodb-prod</td>
|
||||
<td>sapsailinganalytics-prod2</td>
|
||||
<td>2014</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
### Apache
|
||||
|
||||
Apache is listening to port 80 and is answering all HTTP requests. There are two configuration files that control the behaviour.
|
||||
|
||||
* The first one, located at /etc/httpd/conf.d/000-events.conf, controls all sbdomains related to sailing events. This file uses macros that are defined in /etc/httpd/conf/macros. Using these macros you can associate a tracked race to a domain very easily. Each handler, for such a domain, is known as a VirtualHost. At /etc/httpd/conf/macros you’ll find basic definitions of such a VirtualHost. These definitions are prepared to be used in a parametrized way. There is no need to write these definitions by yourself. The configuration file /etc/httpd/conf.d/000-events.conf shows how to use these macros. Make sure to never rename this file as the naming is needed to make sure configuration is loaded correctly.
|
||||
If you want to add a new (sub-)domain then you just need to add a new entry to the 000-events.conf file. Such an entry could look like this:
|
||||
Use Spectator-PROD2 49-euros2012.sapsailing.com “49er European 2012”. The current macro definition is prepared for GWT handling and redirects all other URLs directly to the Jetty server without interfering. You need to be aware of the fact, that all POST requests are altered by adding a new Header Cache-Control: no-cache, no-store to the HTTP header section.
|
||||
For new server deployments make sure to adapt the macros file according to the network configuration. It is crucial to at least change the IP address otherwise directives won’t work.
|
||||
|
||||
* The second one, located at /etc/httpd/conf.d/mainurl.conf hosts definitions for all services that are needed. These include Maven and P2 repositories and for instance the bugzilla domain.
|
||||
|
||||
* The third part, located at /etc/httpd/conf/*, contains general configuration. Here you can configure timeouts, ports, default error messages and many other settings. You find these in a file named httpd.conf. For a new server environment it is crucial to at least check the ServerName, NameVirtualHost and ErrorDocument directives. Other directives should not be changed.
|
||||
|
||||
After each change you need to reload apache by using `service httpd reload` from commandline.
|
||||
|
||||
Logfiles are located at /var/log/httpd. Every event and access to www.sapsailing.com goes to access_log. All other services like maven go to services_log file.
|
||||
|
||||
Errorpages for 404 or other errors can be found in /var/www/errorpages.
|
||||
|
||||
### Postfix
|
||||
|
||||
Postfix handles all email traffic. Its configuration can be found in /etc/postfix/main.cf. There should be no need to change this.
|
||||
|
||||
### Gollum
|
||||
|
||||
Gollum is the software behind our Wiki that is currently tied to http://wiki.sapsailing.com. Gollum is not under control of system package manager and therefore requires manual updates.
|
||||
|
||||
This software requires a running Ruby with minimal version 1.8.7. This version is only available by using the following repository:
|
||||
|
||||
<pre>
|
||||
[webtatic]
|
||||
name=Webtatic Repository $releasever - $basearch
|
||||
#baseurl=http://repo.webtatic.com/yum/centos/5/$basearch/
|
||||
mirrorlist=http://repo.webtatic.com/yum/centos/5/$basearch/mirrorlist
|
||||
enabled=1
|
||||
gpgcheck=1
|
||||
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-webtatic-andy
|
||||
</pre>
|
||||
|
||||
Gollum is installed system-wide by using the command `yum install ruby rubygems` followed by a `gem install gollum`. The configuration for gollum can be found in /opt/gollum-ext/ where also additional sourcecode can be found that is needed for authentication.
|
||||
|
||||
<pre>
|
||||
require 'rubygems'
|
||||
require 'yaml'
|
||||
require 'app'
|
||||
App.set(:gollum_path, "/home/trac/git")
|
||||
App.set(:authorized_users, YAML.load_file(File.expand_path('users.yml', __DIR__)))
|
||||
App.set(:wiki_options, {:live_preview, false})
|
||||
App.set(:default_markup, :markdown)
|
||||
run App
|
||||
</pre>
|
||||
|
||||
Authentication can be controlled by editing the file /opt/gollem-ext/users.yml. Passwords are encoded using sha1sum like this `echo -n mypassword | sha1sum`. Copy the generated hexdigest to the configuration file.
|
||||
|
||||
### Bugzilla
|
||||
|
||||
Bugzilla is the main issue management system and its code is located at /usr/share/bugzilla. Its code base is managed by package manager.
|
||||
|
||||
### Piwik
|
||||
|
||||
Piwik is a analytics software to get meaningful values out of log files. It needs a PHP version 5.3 with installed mysql extensions (pdo, mysqli). You also need to preconfigure a MySQL database. The configuration and code for Piwik is located at /var/www/piwik. Users are being stored in mysql database. If you want to add a new user then just login with admin user and create users using the GUI.
|
||||
|
||||
Piwik is not under control of package management. Updates need to be performed manually.
|
||||
|
||||
At /etc/cron.d/piwik you can find the cron job definition for updating data. By default it uses a script located at /opt/piwik-scripts that looks like this:
|
||||
|
||||
<pre>
|
||||
#!/bin/bash
|
||||
|
||||
ACTUAL_LINES=`cat /var/log/httpd/access_log | wc -l`
|
||||
LINE_START=`cat /opt/piwik-scripts/last-line-count`
|
||||
|
||||
if [ $LINE_START -gt $ACTUAL_LINES ]; then
|
||||
echo "Resetting count"
|
||||
LINE_START=0
|
||||
fi
|
||||
|
||||
echo "Line position: $LINE_START / $ACTUAL_LINES"
|
||||
|
||||
/home/web/Python-2.6.6/bin/python2.6 /var/www/piwik/misc/log-analytics/import_logs.py -d --exclude-path-from=/opt/piwik-scripts/EXCLUDE --url=http://analysi
|
||||
s.sapsailing.com --skip=$LINE_START --enable-static --enable-bots --recorders=4 --recorder-max-payload-size=400 --add-sites-new-hosts /var/log/httpd/access_
|
||||
log
|
||||
|
||||
echo $ACTUAL_LINES > /opt/piwik-scripts/last-line-count
|
||||
</pre>
|
||||
|
||||
### MongoDB
|
||||
|
||||
MongoDB configuration can be found in /opt/mongodb/etc. This service is automatically started by the /etc/init.d/sailing script upon startup. Configuration for mongodb is maintained on every branch in the configuration/ directory.
|
||||
|
||||
### MySQL
|
||||
|
||||
MySQL serves as database backend for Piwik and Bugzilla. Configuration can be found in /etc/my.cnf and database files in /var/lib/mysql.
|
||||
# Production Environment
|
||||
|
||||
[[_TOC_]]
|
||||
|
||||
## General
|
||||
|
||||
Our current server deployment uses a 64bit Java7 Hotspot virtual machine and runs on a 64bit Linux CentOS distribution. We have a single host (sapsailing.com) which runs a number of Java VMs, some to offer the application in different development stages (dev, test, prod, ...), some to perform specific tasks such as replicating UDP wind data to the various server processes, or a process to store data received from the SwissTiming connector durably while forwarding that data to a server VM requesting it.
|
||||
|
||||
The various processes run in "tmux" sessions to which, once connected to sapsailing.com with an ssh client, users can gain access using the `tmux -2 attach-session -t sailing` command. The tmux environment including is started automagically upon system boot by invoking the script _/home/trac/servers/tmuxManagementConsole.sh_.
|
||||
|
||||
For the OSGi containers by convention we have one directory under _/home/trac/servers/_ per deployable branch (dev, test, prod1, prod2). In those directories we have copies of the "install" script from the git's java/target folder. Running it after a successful product build on the branch corresponding to the current directory will copy the compiled product to the server directory. Running the start script will then launch the respective server instance. A safety check in the install script avoids accidentally overwriting a server directory with a non-matching product version by comparing the directory name with the branch name checked out under _/home/trac/git_.
|
||||
|
||||
## Firewall
|
||||
The current firewall configuration is described in the following table. Firewall is maintained by PIRONET NDH. In order to change the configuration you have to sign a form ([[Click here to open it|wiki/uploads/Firewall-Freischaltungformular-v33-de.doc]]).
|
||||
|
||||
<table>
|
||||
<tr>
|
||||
<th>Source</th>
|
||||
<th>Target</th>
|
||||
<th>Port</th>
|
||||
<th>Type</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>ALL</td>
|
||||
<td>sapcoe-app01</td>
|
||||
<td>80</td>
|
||||
<td>TCP</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>ALL</td>
|
||||
<td>sapcoe-app01</td>
|
||||
<td>443</td>
|
||||
<td>TCP</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>ALL</td>
|
||||
<td>sapcoe-app01</td>
|
||||
<td>22</td>
|
||||
<td>TCP</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>sapcoe-app01</td>
|
||||
<td>ALL</td>
|
||||
<td>123</td>
|
||||
<td>TCP</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>ALL</td>
|
||||
<td>sapcoe-app01</td>
|
||||
<td>2010-1015</td>
|
||||
<td>UDP</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>ALL</td>
|
||||
<td>sapcoe-app01</td>
|
||||
<td>21</td>
|
||||
<td>TCP</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>ALL</td>
|
||||
<td>sapcoe-app01</td>
|
||||
<td>5672</td>
|
||||
<td>TCP</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>sapcoe-app01</td>
|
||||
<td>78.46.86.151</td>
|
||||
<td>ALL</td>
|
||||
<td>TCP+UDP</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>sapcoe-app01</td>
|
||||
<td>46.4.29.12</td>
|
||||
<td>ALL</td>
|
||||
<td>TCP+UDP</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>sapcoe-app01</td>
|
||||
<td>89.233.27.2</td>
|
||||
<td>ALL</td>
|
||||
<td>TCP+UDP</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>sapcoe-app01</td>
|
||||
<td>gps.sportresult.com</td>
|
||||
<td>40300</td>
|
||||
<td>TCP+UDP</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
## Services
|
||||
|
||||
Services are vital for the infrastructure. The following sections describe location of configuration and special behaviour.
|
||||
|
||||
### Java Servers
|
||||
|
||||
To ensure availability and to be able to separate servers holding historical data and live data there are a bunch of preconfigured java servers.
|
||||
|
||||
<table>
|
||||
<tr>
|
||||
<th>Name</th>
|
||||
<th>HTTP</th>
|
||||
<th>MongoDB Port</th>
|
||||
<th>MongoDB Path</th>
|
||||
<th>Replication Channel</th>
|
||||
<th>Expedition UDP Port</th>
|
||||
<th>OSGi Telnet Port</th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>DEV</td>
|
||||
<td>8886</td>
|
||||
<td>10200</td>
|
||||
<td>/opt/mongodb/data/mongodb-dev</td>
|
||||
<td>sapsailinganalytics-dev</td>
|
||||
<td>2010</td>
|
||||
<td>14886</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>TEST</td>
|
||||
<td>8887</td>
|
||||
<td>10201</td>
|
||||
<td>/opt/mongodb/data/mongodb-test</td>
|
||||
<td>sapsailinganalytics-test</td>
|
||||
<td>2011</td>
|
||||
<td>14887</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>PROD1</td>
|
||||
<td>8888</td>
|
||||
<td>10202</td>
|
||||
<td>/opt/mongodb/data/mongodb-prod</td>
|
||||
<td>sapsailinganalytics-prod1</td>
|
||||
<td>2013</td>
|
||||
<td>14888</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td>PROD2</td>
|
||||
<td>8889</td>
|
||||
<td>10202</td>
|
||||
<td>/opt/mongodb/data/mongodb-prod</td>
|
||||
<td>sapsailinganalytics-prod2</td>
|
||||
<td>2014</td>
|
||||
<td>14889</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
### Apache
|
||||
|
||||
Apache is listening to port 80 and is answering all HTTP requests. There are two configuration files that control the behaviour.
|
||||
|
||||
* The first one, located at /etc/httpd/conf.d/000-events.conf, controls all sbdomains related to sailing events. This file uses macros that are defined in /etc/httpd/conf/macros. Using these macros you can associate a tracked race to a domain very easily. Each handler, for such a domain, is known as a VirtualHost. At /etc/httpd/conf/macros you’ll find basic definitions of such a VirtualHost. These definitions are prepared to be used in a parametrized way. There is no need to write these definitions by yourself. The configuration file /etc/httpd/conf.d/000-events.conf shows how to use these macros. Make sure to never rename this file as the naming is needed to make sure configuration is loaded correctly.
|
||||
If you want to add a new (sub-)domain then you just need to add a new entry to the 000-events.conf file. Such an entry could look like this:
|
||||
Use Spectator-PROD2 49-euros2012.sapsailing.com “49er European 2012”. The current macro definition is prepared for GWT handling and redirects all other URLs directly to the Jetty server without interfering. You need to be aware of the fact, that all POST requests are altered by adding a new Header Cache-Control: no-cache, no-store to the HTTP header section.
|
||||
For new server deployments make sure to adapt the macros file according to the network configuration. It is crucial to at least change the IP address otherwise directives won’t work.
|
||||
|
||||
* The second one, located at /etc/httpd/conf.d/mainurl.conf hosts definitions for all services that are needed. These include Maven and P2 repositories and for instance the bugzilla domain.
|
||||
|
||||
* The third part, located at /etc/httpd/conf/*, contains general configuration. Here you can configure timeouts, ports, default error messages and many other settings. You find these in a file named httpd.conf. For a new server environment it is crucial to at least check the ServerName, NameVirtualHost and ErrorDocument directives. Other directives should not be changed.
|
||||
|
||||
After each change you need to reload apache by using `service httpd reload` from commandline.
|
||||
|
||||
Logfiles are located at /var/log/httpd. Every event and access to www.sapsailing.com goes to access_log. All other services like maven go to services_log file.
|
||||
|
||||
Errorpages for 404 or other errors can be found in /var/www/errorpages.
|
||||
|
||||
### Postfix
|
||||
|
||||
Postfix handles all email traffic. Its configuration can be found in /etc/postfix/main.cf. There should be no need to change this.
|
||||
|
||||
### Gollum
|
||||
|
||||
Gollum is the software behind our Wiki that is currently tied to http://wiki.sapsailing.com. Gollum is not under control of system package manager and therefore requires manual updates.
|
||||
|
||||
This software requires a running Ruby with minimal version 1.8.7. This version is only available by using the following repository:
|
||||
|
||||
<pre>
|
||||
[webtatic]
|
||||
name=Webtatic Repository $releasever - $basearch
|
||||
#baseurl=http://repo.webtatic.com/yum/centos/5/$basearch/
|
||||
mirrorlist=http://repo.webtatic.com/yum/centos/5/$basearch/mirrorlist
|
||||
enabled=1
|
||||
gpgcheck=1
|
||||
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-webtatic-andy
|
||||
</pre>
|
||||
|
||||
Gollum is installed system-wide by using the command `yum install ruby rubygems` followed by a `gem install gollum`. The configuration for gollum can be found in /opt/gollum-ext/ where also additional sourcecode can be found that is needed for authentication.
|
||||
|
||||
<pre>
|
||||
require 'rubygems'
|
||||
require 'yaml'
|
||||
require 'app'
|
||||
App.set(:gollum_path, "/home/trac/git")
|
||||
App.set(:authorized_users, YAML.load_file(File.expand_path('users.yml', __DIR__)))
|
||||
App.set(:wiki_options, {:live_preview, false})
|
||||
App.set(:default_markup, :markdown)
|
||||
run App
|
||||
</pre>
|
||||
|
||||
Authentication can be controlled by editing the file /opt/gollem-ext/users.yml. Passwords are encoded using sha1sum like this `echo -n mypassword | sha1sum`. Copy the generated hexdigest to the configuration file.
|
||||
|
||||
### Bugzilla
|
||||
|
||||
Bugzilla is the main issue management system and its code is located at /usr/share/bugzilla. Its code base is managed by package manager.
|
||||
|
||||
### Piwik
|
||||
|
||||
Piwik is a analytics software to get meaningful values out of log files. It needs a PHP version 5.3 with installed mysql extensions (pdo, mysqli). You also need to preconfigure a MySQL database. The configuration and code for Piwik is located at /var/www/piwik. Users are being stored in mysql database. If you want to add a new user then just login with admin user and create users using the GUI.
|
||||
|
||||
Piwik is not under control of package management. Updates need to be performed manually.
|
||||
|
||||
At /etc/cron.d/piwik you can find the cron job definition for updating data. By default it uses a script located at /opt/piwik-scripts that looks like this:
|
||||
|
||||
<pre>
|
||||
#!/bin/bash
|
||||
|
||||
ACTUAL_LINES=`cat /var/log/httpd/access_log | wc -l`
|
||||
LINE_START=`cat /opt/piwik-scripts/last-line-count`
|
||||
|
||||
if [ $LINE_START -gt $ACTUAL_LINES ]; then
|
||||
echo "Resetting count"
|
||||
LINE_START=0
|
||||
fi
|
||||
|
||||
echo "Line position: $LINE_START / $ACTUAL_LINES"
|
||||
|
||||
/home/web/Python-2.6.6/bin/python2.6 /var/www/piwik/misc/log-analytics/import_logs.py -d --exclude-path-from=/opt/piwik-scripts/EXCLUDE --url=http://analysi
|
||||
s.sapsailing.com --skip=$LINE_START --enable-static --enable-bots --recorders=4 --recorder-max-payload-size=400 --add-sites-new-hosts /var/log/httpd/access_
|
||||
log
|
||||
|
||||
echo $ACTUAL_LINES > /opt/piwik-scripts/last-line-count
|
||||
</pre>
|
||||
|
||||
### MongoDB
|
||||
|
||||
MongoDB configuration can be found in /opt/mongodb/etc. This service is automatically started by the /etc/init.d/sailing script upon startup. Configuration for mongodb is maintained on every branch in the configuration/ directory.
|
||||
|
||||
### MySQL
|
||||
|
||||
MySQL serves as database backend for Piwik and Bugzilla. Configuration can be found in /etc/my.cnf and database files in /var/lib/mysql.
|
||||
@@ -0,0 +1,53 @@
|
||||
# Sailing Domain Algorithms
|
||||
|
||||
Here is a draft description of the algorithms we use for the various non-trivial key figures displayed in our leaderboard.
|
||||
|
||||
All values are based on GPS tracks which are therefore subject to the usual GPS accuracy. Furthermore, all fixes that are considered outliers are not considered for calculations. A fix is considered an outlier if the object tracked would have had to move at a speed of 50 knots or more from the previous or to the next fix to reach the fix. Mark roundings, which define a competitors entry into and exit out of a leg, are currently provided to us by the tracking provider used. Therefore, these time points depend on their algorithms for mark rounding detection. We know that in particular TracTrac currently does not distinguish between lines and gates and for both uses the time point at which the tracked object crosses the line between the two marks as the mark rounding time point. For gates, this is not in full accordance with the ISAF definition of the mark rounding time for gates.
|
||||
|
||||
## Current Speed over Ground (SOG)
|
||||
|
||||
All fixes in the open interval starting 4s before and ending 4s after the query time point are aggregated into a weighted average; the averaging algorithm used is exponential, with the weight of a fix halved every four seconds the fix is further away from the query time point.
|
||||
|
||||
## Distance traveled between two time points
|
||||
|
||||
Aggregates the great circle distance from fix to fix between the time points. For start and end, if the time point does not exactly match a fix, the tracked object's position at the query time point is estimated by linear interpolation between the adjacent fixes.
|
||||
|
||||
## Combined Wind
|
||||
|
||||
We aggregate a number of wind sources into a combined wind reading which is then used for further calculations. Wind sources are equipped with a general level of confidence. The higher the confidence, the higher the wind source's weight in the average computed across the wind sources available. The wind sources supported are: manual entry (confidence 0.9), measured (confidence 0.9), course layout at race start for an upwind start (confidence 0.3), estimation based on GPS-tracked beat angles across the fleet (confidence 0.5). Confidences are further reduced as the time between a measurement and the query time point increases. The confidence reduction is hyperbolic over the time difference, halved every 3s. For the wind estimation based on GPS-tracked beat angles, confidence is further reduced by small fleet sizes on one tack, as well as proximity to mark roundings and major direction changes such as maneuvers. The result is currently determined independently of the location for which the wind is queried.
|
||||
|
||||
##Leg bearing
|
||||
|
||||
For a given time point the position of the leg's start end end waypoint are determined. A gate's or a line's position is assumed to be half the way on the great circle between the two marks forming the gate or the line, respectively. The leg's bearing is the true bearing from the start waypoint's position at query time and the end waypoint's position at query time.
|
||||
|
||||
## Leg type
|
||||
|
||||
For a given time point, the leg type is determined based on the true wind direction at that time and the leg's bearing relative to the true wind direction. Legs whose bearing is pointing windwards within 45 degrees left or right are considered UPWIND legs. Legs pointing leewards within 45 degrees left or right are considered DOWNWIND legs. All other legs are considered REACHING legs.
|
||||
|
||||
##Velocity Made Good (VMG)
|
||||
|
||||
For UPWIND and DOWNWIND legs, the speed over ground is projected onto the combined wind direction to obtain the windward or leeward speed, respectively. For REACHING legs, the speed over ground is projected onto the leg's direction, resulting in the along-track speed. Note that during mark roundings the VMG may be very small or even zero although the speed over ground is positive.
|
||||
|
||||
##Average Cross-Track Error (XTE)
|
||||
|
||||
The arithmetic average across all fixes within a time interval of their distance to their respective leg's course middle line at the fix's time point (the great circle segment connecting the leg's start waypoint's position at the fix's time point with the leg's end waypoint's position at the fix's time point)
|
||||
|
||||
##Estimated Time of Arrival at Next Mark (ETA)
|
||||
|
||||
For UPWIND and DOWNWIND legs, this is the windward or leeward distance to the next mark divided by the VMG. For REACHING legs, this is the along-track distance to the next mark divided by the along-track speed.
|
||||
|
||||
##Gap to Leader (Time)
|
||||
|
||||
For the leader, this is obviously zero. For all other competitors, if the competitor is in the same leg with the leader, in UPWIND, DOWNWIND and REACHING legs, the gap is defined to be the windward, leeward and along-track distance, respectively, to the leader divided by the competitor's VMG at the query time point. If the leader is already in another leg, the competitor's ETA is used to which the time that passed since the leader passed the competitor's next mark is added.
|
||||
|
||||
##Windward Distance to Leader
|
||||
|
||||
For the leader, this is obviously zero. For all other competitors, if the competitor is in the same leg with the leader, in UPWIND, DOWNWIND and REACHING legs, the windward distance to leader is defined to be the windward, leeward and along-track distance, respectively, to the leader. If the leader is already in another leg, the competitor's windward/leeward/along-track distance to the next mark is used to which the windward/leeward/along-track distance of all subsequent legs the leader has already completed are added, plus the windward/leeward/along-track distance the leader has already completed in the leader's current leg.
|
||||
|
||||
##Average Velocity Made Good
|
||||
|
||||
For a given time point, the windward distance a competitor traveled in a leg up to that time point is computed. If the competitor has finished the leg already at that time point, the finishing time point is used instead. The windward distance is then divided by the time interval starting when the competitor entered the leg and ending at the given time point or the time point when the competitor finished the leg, whichever is earlier. Note that this is not the same as computing an arithmetic average of all the VMG values at all time points of a competitor's fixes in the leg. The individual VMG values are all computed based on the combined wind at their respective time point whereas the average is computed based on the wind at the time point specified or the time point the competitor finished the leg, whichever comes first.
|
||||
|
||||
##Maneuver Loss (Distance)
|
||||
|
||||
The maximum speed over ground right before the maneuver begins is extrapolated to the time point after the maneuver when the competitor has again reached maximum speed over ground. The extrapolated position is then compared to the actual position, and the difference vector is projected onto the wind direction for UPWIND and DOWNWIND legs, and onto the leg's bearing for REACHING legs, respectively. The result is the windward/leeward/along-track distance lost by the maneuver.
|
||||
Reference in new issue
Block a user