Changes in 09239f8: Merge branch 'master' into bug5912

				.github/workflows/merge-main-into-docker-17.yml
			
          @@ -0,0 +1,24 @@

          +name: Merge main branch into docker-17 after successful build

          +on:

          +  workflow_run:

          +    workflows: [release]

          +    types: [completed]

          +    branches: [main]

          +  workflow_dispatch: {}

          +jobs:

          +  merge-main-into-docker-17:

          +    if: ${{ github.event_name == 'workflow_dispatch' || github.event.workflow_run.conclusion == 'success' }}

          +    runs-on: ubuntu-latest

          +    steps:

          +      - name: Checkout

          +        uses: actions/checkout@v4

          +        with:

          +          ref: docker-17

          +          fetch-depth: 0  # fetch the whole thing to make sure the histories merge

          +      - name: Merge main into docker-17

          +        uses: devmasx/merge-branch@master

          +        with:

          +          type: now

          +          from_branch: main

          +          target_branch: docker-17

          +          github_token: ${{ secrets.REPO_TOKEN_FOR_MERGE_AND_PUSH }}

				.pipeline/README
			
          @@ -0,0 +1,7 @@

          +This folder contains an Azure pipeline definition that is used for building our

          +Android companion apps, in particular the Sailing Race Manager app and the

          +Buoy Pinger app. See also the mobile/ folder for their source code. The

          +gradle build that is used at the core of this build pipeline is controlled

          +by the ``build.gradle``and ``gradle.properties`` file in the root folder.

          +A local Android app build can be achieved by running the ``gradlew``

          +wrapper script from the root folder.

				.reuse/README
			
          @@ -0,0 +1,3 @@

          +This folder is used by the workflow defined in ``.github/workflows/reuse-tool-license-updates.yml``

          +and produces machine-readable licensing information for the entire repository into the dep5 file

          +in this same folder.

				Gemfile.lock
			
          @@ -1,7 +1,9 @@

           GEM

             remote: https://rubygems.org/

             specs:

          -    CFPropertyList (3.0.6)

          +    CFPropertyList (3.0.7)

          +      base64

          +      nkf

                 rexml

               addressable (2.8.5)

                 public_suffix (>= 2.0.2, < 6.0)

          @@ -24,6 +26,7 @@ GEM

               aws-sigv4 (1.6.0)

                 aws-eventstream (~> 1, >= 1.0.2)

               babosa (1.0.4)

          +    base64 (0.2.0)

               claide (1.1.0)

               colored (1.2)

               colored2 (3.1.2)

          @@ -161,6 +164,7 @@ GEM

               multipart-post (2.3.0)

               nanaimo (0.3.0)

               naturally (2.2.1)

          +    nkf (0.2.0)

               optparse (0.1.1)

               os (1.1.4)

               plist (3.7.0)

          @@ -171,7 +175,8 @@ GEM

                 trailblazer-option (>= 0.1.1, < 0.2.0)

                 uber (< 0.2.0)

               retriable (3.1.2)

          -    rexml (3.2.7)

          +    rexml (3.2.8)

          +      strscan (>= 3.0.9)

               rouge (2.0.7)

               ruby2_keywords (0.0.5)

               rubyzip (2.3.2)

          @@ -184,6 +189,7 @@ GEM

               simctl (1.6.10)

                 CFPropertyList

                 naturally

          +    strscan (3.1.0)

               terminal-notifier (2.0.0)

               terminal-table (3.0.2)

                 unicode-display_width (>= 1.1.1, < 3)

          @@ -199,7 +205,7 @@ GEM

               unicode-display_width (2.5.0)

               webrick (1.8.1)

               word_wrap (1.0.0)

          -    xcodeproj (1.23.0)

          +    xcodeproj (1.24.0)

                 CFPropertyList (>= 2.3.3, < 4.0)

                 atomos (~> 0.1.3)

                 claide (>= 1.0.2, < 2.0)

				configuration/environments_scripts/central_reverse_proxy/files/var/www/cgi-bin/github.cgi
			
          @@ -5,7 +5,7 @@ BODY=$( cat )

           echo "${BODY}" >/tmp/github-hook-body

           REF=$( echo "${BODY}" | jq -r '.ref' )

           PUSHER=$( echo "${BODY}" | jq -r '.pusher.email' )

          -logger -t github-cgi "ref ia $REF, pusher was $PUSHER"

          +logger -t github-cgi "ref is $REF, pusher was $PUSHER"

           # For testing:

           #if [ "${PUSHER}" = "axel.uhl@sap.com" -a "${REF}" = "refs/heads/translation" ]; then

           if [ "${PUSHER}" = "tmsatsls+github.tools.sap_service-tip-git@sap.com" -a "${REF}" = "refs/heads/translation" ]; then

          @@ -13,7 +13,7 @@ if [ "${PUSHER}" = "tmsatsls+github.tools.sap_service-tip-git@sap.com" -a "${REF

             echo "Fetching translation branch from github.tools.sap and pushing it to ssh://trac@sapsailing.com/home/trac/git"

             logger -t github-cgi "fetching translation branch from github.tools.sap and pushing it to ssh://trac@sapsailing.com/home/trac/git"

             cd /home/wiki/gitwiki

          -  sudo -u wiki git fetch sapsailing translation:translation 2>&1

          +  sudo -u wiki git fetch github translation:translation 2>&1

             sudo -u wiki git push origin translation:translation 2>&1

           else

             echo "Either pusher was not tmsatsls+github.tools.sap_service-tip-git@sap.com or ref was not refs/heads/translation. Not triggering."

				configuration/environments_scripts/central_reverse_proxy/target-group-tag-route53-nfs-elasticIP-setup.sh
			
          @@ -45,10 +45,13 @@ done

           # alter records using batch file.

           sed -i "s/LOGFILES_INTERNAL_IP/$LOCAL_IPV4/" batch-for-route53-dns-record-update.json

           sed -i "s/SMTP_INTERNAL_IP/$LOCAL_IPV4/" batch-for-route53-dns-record-update.json

          +HOSTED_ZONE_ID=$( aws route53 list-hosted-zones | \

          +           jq -r '.HostedZones[] | select(.Name == "sapsailing.com.").Id' | \

          +           sed -e 's|/hostedzone/||' )

           read -n 1  -p "Check the instance has the correct tags and is in the correct target group.

           Furthermore, check the batch file batch-for-route53-dns-record-update.json has been modified correctly.

           Press a key to continue.." key_pressed

          -###### DO NOT ENABLE WHILST TESTING: aws route53 change-resource-record-sets --hosted-zone-id Z2JYWXYWLLRLTE --change-batch file://batch-for-route53-dns-record-update.json

          +###### DO NOT ENABLE WHILST TESTING: aws route53 change-resource-record-sets --hosted-zone-id ${HOSTED_ZONE_ID} --change-batch file://batch-for-route53-dns-record-update.json

           # reload the nfs mountpoints.

           echo "Waiting 60 seconds for records to change. The program will await a key press after this time."

           echo "Please check the route53 DNS records have been correctly updated."

				configuration/environments_scripts/repo/usr/local/bin/syncgit
			
          @@ -1,16 +1,35 @@

           #!/bin/sh

          +# Syncs the necessary branches of a repo at a specified location or, as default,

          +# /home/wiki/gitwiki. The assumed checked-out branch is master and the tracking branch

          +# is assumed to be origin master.

           ADMIN_EMAIL="axel.uhl@sap.com jan.hamann@sapsailing.com"

           if [ $# -eq 0 ]; then

               GIT_PATH="/home/wiki/gitwiki"

           else

          -    GIT_PATH=$1

          +    GIT_PATH="$1"

          +fi

          +cd "$GIT_PATH"

          +git fetch github main:main >/tmp/wiki-git.out 2>/tmp/wiki-git.err

          +if [ "$?" != "0" ]; then

          +  cat /tmp/wiki-git.out /tmp/wiki-git.err | mail -s "Wiki git problem: could not fetch github/main into local main" $ADMIN_EMAIL

          +fi

          +git push origin main:main >/tmp/wiki-git.out 2>/tmp/wiki-git.err

          +if [ "$?" != "0" ]; then

          +  cat /tmp/wiki-git.out /tmp/wiki-git.err | mail -s "Wiki git problem: could not push main into sapsailing/main" $ADMIN_EMAIL

          +fi

          +git pull github main >/tmp/wiki-git.out 2>/tmp/wiki-git.err

          +if [ "$?" != "1" ]; then

          +  cat /tmp/wiki-git.out /tmp/wiki-git.err | mail -s "Wiki git problem: could not merge github/main into sapsailing/master" $ADMIN_EMAIL

           fi

          -cd $GIT_PATH

           git pull >/tmp/wiki-git.out 2>/tmp/wiki-git.err

           if [ "$?" != "0" ]; then

          -  cat /tmp/wiki-git.out /tmp/wiki-git.err | mail -s "Wiki git problem" $ADMIN_EMAIL

          +  cat /tmp/wiki-git.out /tmp/wiki-git.err | mail -s "Wiki git problem: could not pull origin/master" $ADMIN_EMAIL

          +fi

          +git push origin master:main >>/tmp/wiki-git.out 2>/tmp/wiki-git.err

          +if [ "$?" != "0" ]; then

          +  cat /tmp/wiki-git.out /tmp/wiki-git.err | mail -s "Wiki git problem: could not push master to origin/main" $ADMIN_EMAIL

           fi

           git push >>/tmp/wiki-git.out 2>/tmp/wiki-git.err

           if [ "$?" != "0" ]; then

          -  cat /tmp/wiki-git.out /tmp/wiki-git.err | mail -s "Wiki git problem" $ADMIN_EMAIL

          +  cat /tmp/wiki-git.out /tmp/wiki-git.err | mail -s "Wiki git problem: could not push master to origin/master" $ADMIN_EMAIL

           fi

				wiki/howto/development/i18n.md
			
          @@ -58,15 +58,17 @@ The primary repository for the app lives at ``trac@sapsailing.com:/home/trac/sai

           ## Triggering and Integrating Translations

          -We entertain a Git repo clone at ``https://github.tools.sap/SAP-Sailing-Analytics/sapsailing``. When we push new commits to the ``translation`` branch of that repository (see [https://github.tools.sap/SAP-Sailing-Analytics/sapsailing/tree/translation](https://github.tools.sap/SAP-Sailing-Analytics/sapsailing/tree/translation)) then LXLabs will grab these changes in regular intervals (as of this writing typically every Friday evening) and look for changes in files that belong to any message collection.

          +We keep our Git repo at ``https://github.com/SAP/sailing-analytics``. When we push new commits to the ``translation`` branch of that repository (see [https://github.com/SAP/sailing-analytics/tree/translation](https://github.com/SAP/sailing-analytics/tree/translation)) then LXLabs will grab these changes in regular intervals (as of this writing typically every Friday evening) and look for changes in files that belong to any message collection.

          -Message collections are declared in the file ``translation_v2.json`` in the root of our Git workspace. Adding new collections to this file requires us to inform LXLabs (e.g., vyacheslav.sklyarenko@sap.com, called "Slava"). They need to make the corresponding update in the so-called [Translation Enablement Workbench](https://tew.ingress.prod.lp.shoot.live.k8s-hana.ondemand.com/#/param/WzIwMiw1NiwiLyIsInRhc2tRdWV1ZSJd).

          +Message collections are declared in the file ``translation_v2.json`` in the root of our Git workspace. Adding new collections to this file requires us to inform LXLabs (e.g., vyacheslav.sklyarenko@sap.com, called "Slava"). They need to make the corresponding update in the so-called [Translation Enablement Workbench](https://tew.ingress.prod.lp.shoot.live.k8s-hana.ondemand.com/).

           During the translation process, translators may have questions regarding new or changed message strings. This will results in tasks being assigned by the Translation Enablement Workbench, and an e-mail to the assignee will result. Currently, the default assignee for these tasks is axel.uhl@sap.com. We then need to answer these questions as soon as possible to unblock the translation process so that ideally we get the translation in the same sweep as those for other languages, in the same round.

          -When translations are done, they are pushed to the same ``translation`` branch of ``https://github.tools.sap/SAP-Sailing-Analytics/sapsailing`` by LXLabs and then usually contain the translation of all changed or added message strings. LXLabs goes by the default locale ("en") and ignores all we do in the German ("de") locale.

          +When translations are done, they are pushed to the same ``translation`` branch of ``https://github.com/SAP/sailing-analytics`` by LXLabs and then usually contain the translation of all changed or added message strings. LXLabs goes by the default locale ("en") and ignores all we do in the German ("de") locale.

          -We have a Github webhook installed (see [https://github.tools.sap/SAP-Sailing-Analytics/sapsailing/settings/hooks/285417](https://github.tools.sap/SAP-Sailing-Analytics/sapsailing/settings/hooks/285417)) which triggers a CGI-BIN script that is installed on sapsailing.com at ``/var/www/cgi-bin/github.cgi`` and is versioned under ``configuration/httpd/cgi-bin/github.cgi`` to which ``/var/www/cgi-bin/github.cgi`` is a symbolic link, and which reacts to pushes from the user with the e-mail address ``tmsatsls+github.tools.sap_service-tip-git@sap.com``, pushing to branch ``translation``. In this case, the Git workspace installed at ``/home/wiki/gitwiki`` for the user ``wiki`` is used to fetch the latest translations, using the Git remote ``sapsailing`` which is expected to use a Personal Access Token (PAT) that is granted read access to the repository. The changes are then pushed to the ``translation`` branch on ``ssh://trac@sapsailing.com/home/trac/git`` which is expected to trigger the [hudson job for the translation branch](https://hudson.sapsailing.com/job/SAPSailingAnalytics-translation/). This, in turn, will run a full build, and if successful, merge the ``translation`` branch into ``master`` and push it back to ``ssh://trac@sapsailing.com/home/trac/git`` which will then trigger the [master's build job](https://hudson.sapsailing.com/job/SAPSailingAnalytics-master/).

          +We have a Github webhook installed (see [https://github.com/SAP/sailing-analytics/settings/hooks/480929064](https://github.com/SAP/sailing-analytics/settings/hooks/480929064)) which triggers a CGI-BIN script that is installed on sapsailing.com at ``/var/www/cgi-bin/github.cgi`` and is versioned under ``configuration/httpd/cgi-bin/github.cgi`` to which ``/var/www/cgi-bin/github.cgi`` is a symbolic link, and which reacts to pushes from the user with the e-mail address ``tmsatsls+github.tools.sap_service-tip-git@sap.com``, pushing to branch ``translation``. In this case, the Git workspace installed at ``/home/wiki/gitwiki`` for the user ``wiki`` is used to fetch the latest translations, using the Git remote ``sapsailing`` which is expected to use a Personal Access Token (PAT) that is granted read access to the repository. The changes are then pushed to the ``translation`` branch on ``ssh://trac@sapsailing.com/home/trac/git`` which is expected to trigger the [hudson job for the translation branch](https://hudson.sapsailing.com/job/SAPSailingAnalytics-translation/). This, in turn, will run a full build, and if successful, merge the ``translation`` branch into ``master`` and push it back to ``ssh://trac@sapsailing.com/home/trac/git`` which will then trigger the [master's build job](https://hudson.sapsailing.com/job/SAPSailingAnalytics-master/).

          +

          +TODO Github Publication: With the "translation" branch being pushed to github.com, a build for the translation branch will start automatically using Github Actions. If we renamed our "SAPSailingAnalytics-translation" job to just "translation" then the magic should work and we should get a trigger for the "translation" job when the Github Actions build is done.

           First building in a separate job before merging into master partly goes back to the times when LXLabs had issues exporting Java properties file syntax when placeholders and single-quote characters were used in the translations; a common problem in the French translations. However, this has improved massively, and we haven't seen any translation-incurred build errors in a long time. Yet, we stick to the process.

				wiki/info/landscape/amazon-ec2.md
			
          @@ -37,7 +37,7 @@ To improve availability and reliability, we have a disposable environment type a

           The IPs for all reverse proxies will automatically be added to ALB target groups with the tag key `allReverseProxies`, including the `CentralWebServerHTTP-Dyn` target group (in the dynamic ALB in eu-west-1)

           and all the `DDNSMapped-x-HTTP` (in all the DDNSMapped servers). These are the target groups for the default rules and it ensures availability to the ARCHIVE especially.

          -Disposables instances are tagged with `disposableProxy` to indicate it hosts no vital services. `ReverseProxy` also identifies any reverse proxies. The health check for the target groups would change to trigger a script which returns different error codes: healthy/200 if in the same AZ as the archive (or if the failover archive is in use), whilst unhealthy/503 if in different AZs. This will reduce cross-AZ, archive traffic costs, but maintain availability and load balancing.

          +Disposables instances are tagged with `DisposableProxy` to indicate it hosts no vital services. `ReverseProxy` also identifies any reverse proxies. The health check for the target groups would change to trigger a script which returns different error codes: healthy/200 if in the same AZ as the archive (or if the failover archive is in use), whilst unhealthy/503 if in different AZs. This will reduce cross-AZ, archive traffic costs, but maintain availability and load balancing.

           For security groups of the central reverse proxy, we want Webserver, as well as Disposable Reverse Proxy. The disposables just have the latter.

          @@ -102,7 +102,7 @@ The webserver must be tagged with key ``CentralReverseProxy`` where the value is

           The following diagram explains the disposable reverse proxies role a little better. 

          -<img src="wiki/images/orchestration/disposable-reverse-proxy-architecture-from-bug1873.png" />

          +<img src="/wiki/images/orchestration/disposable-reverse-proxy-architecture-from-bug1873.png" />

           ### DNS and Application Load Balancers (ALBs)

				wiki/planning/domain-switchover.md
			
          @@ -0,0 +1,30 @@

          +# Domain Switchover

          +

          +## Locations that reference sapsailing.com

          +

          +- The ChargeBee subscription module used for payment services has a callback method pointing to ``sapsailing.com`` where updates to the users are processed and then replicated across the landscape.

          +

          +- ``SharedLandscapeConsants.DEFAULT_DOMAIN_NAME`` is set to "sapsailing.com" but can be overridden; for things to work, however, we would need to add the deviating domain as a "hosted zone" to our Route53 account so that the DNS-maintaining logic will run without exceptions.

          +

          +- The certificate used in the ALBs is created for \*.sapsailing.com; to run under a different domain name, a certificate matching the domain name will be required. The ALB set-up in AwsLandscapeImpl.createLoadBalancerHttpsListener uses the default certificate domain "\*.sapsailing.com" from a constant; this would need to be made flexible, e.g., through a system property, if we were to use any form of landscape automation under a different domain name.

          +

          +- Shared security configuration as in

          +    env.sh:#ADDITIONAL_JAVA_ARGS="$ADDITIONAL_JAVA_ARGS -Dsecurity.sharedAcrossSubdomainsOf=sapsailing.com -Dsecurity.baseUrlForCrossDomainStorage=https://security-service.sapsailing.com -Dgwt.acceptableCrossDomainStorageRequestOriginRegexp=https?://(.\*\.)?sapsailing\.com(:[0-9]\*)?$"

          +    

          +- The ``target-group-tag-route53-nfs-elasticIP-setup.sh`` script used as the last stage of the setup process of a new central reverse proxy. It queries the Route 53 ID of the "sapsailing.com" hosted zone which would have to become a parameter or would need to be changed in the script.

          +

          +- Mail sending and Amazon SES.

          +

          +- ``REPLICATE_MASTER_SERVLET_HOST`` is sometimes hardcoded.

          +

          +- Igtimi Authentication: the Igtimi REST API and authentication scheme uses a callback URL that we have configured on the igtimi.com web site, pointing to sapsailing.com.

          +

          +- Google Maps API is SAP provided in our current production environment, and a different API token/key is required once SAP stops its support.

          +

          +- A number of bash scripts have sapsailing.com hardcoded, especially the setup scripts and imageupgrade_functions.sh. Ideally we will need to factor out into a constant that all bash scripts can access.

          +

          +- Releases and p2 respository references, where "releases.sapsailing.com" will be replaced over time by Github releases which the ``refreshInstance.sh`` script can then download.

          +

          +- MongoDB references and rabbit references, or any other private IP references in route53. Such references can in particular be found in the ``environments/`` folder on ``releases.sapsailing.com`` for the default parameterization of certain application process types, such as ``security-service-master`` or ``archive-server``.

          +

          +- branch.io is used for "deep linking" for the apps. We have an integration with our Route53 hosted zone "sapsailing.com" for the specific domain names, allowing smart payload transfer through from-scratch installations, e.g., from a QR code. The branch.io account would need to be transferred and would need to have the configuration changed; or a new account would be required. The apps' deep linking capabilities are expressed in their manifests, and hence the apps would need to be adjusted to work with a different domain.

          \ No newline at end of file

...	...	@@ -37,7 +37,7 @@ To improve availability and reliability, we have a disposable environment type a
37	37
38	38	The IPs for all reverse proxies will automatically be added to ALB target groups with the tag key `allReverseProxies`, including the `CentralWebServerHTTP-Dyn` target group (in the dynamic ALB in eu-west-1)
39	39	and all the `DDNSMapped-x-HTTP` (in all the DDNSMapped servers). These are the target groups for the default rules and it ensures availability to the ARCHIVE especially.
40		-Disposables instances are tagged with `disposableProxy` to indicate it hosts no vital services. `ReverseProxy` also identifies any reverse proxies. The health check for the target groups would change to trigger a script which returns different error codes: healthy/200 if in the same AZ as the archive (or if the failover archive is in use), whilst unhealthy/503 if in different AZs. This will reduce cross-AZ, archive traffic costs, but maintain availability and load balancing.
	40	+Disposables instances are tagged with `DisposableProxy` to indicate it hosts no vital services. `ReverseProxy` also identifies any reverse proxies. The health check for the target groups would change to trigger a script which returns different error codes: healthy/200 if in the same AZ as the archive (or if the failover archive is in use), whilst unhealthy/503 if in different AZs. This will reduce cross-AZ, archive traffic costs, but maintain availability and load balancing.
41	41
42	42	For security groups of the central reverse proxy, we want Webserver, as well as Disposable Reverse Proxy. The disposables just have the latter.
43	43
...	...	@@ -102,7 +102,7 @@ The webserver must be tagged with key ``CentralReverseProxy`` where the value is
102	102
103	103	The following diagram explains the disposable reverse proxies role a little better.
104	104
105		-<img src="wiki/images/orchestration/disposable-reverse-proxy-architecture-from-bug1873.png" />
	105	+<img src="/wiki/images/orchestration/disposable-reverse-proxy-architecture-from-bug1873.png" />
106	106
107	107	### DNS and Application Load Balancers (ALBs)
108	108

...	...	@@ -0,0 +1,24 @@
	1	+name: Merge main branch into docker-17 after successful build
	2	+on:
	3	+ workflow_run:
	4	+ workflows: [release]
	5	+ types: [completed]
	6	+ branches: [main]
	7	+ workflow_dispatch: {}
	8	+jobs:
	9	+ merge-main-into-docker-17:
	10	+ if: ${{ github.event_name == 'workflow_dispatch' \|\| github.event.workflow_run.conclusion == 'success' }}
	11	+ runs-on: ubuntu-latest
	12	+ steps:
	13	+ - name: Checkout
	14	+ uses: actions/checkout@v4
	15	+ with:
	16	+ ref: docker-17
	17	+ fetch-depth: 0 # fetch the whole thing to make sure the histories merge
	18	+ - name: Merge main into docker-17
	19	+ uses: devmasx/merge-branch@master
	20	+ with:
	21	+ type: now
	22	+ from_branch: main
	23	+ target_branch: docker-17
	24	+ github_token: ${{ secrets.REPO_TOKEN_FOR_MERGE_AND_PUSH }}

...	...	@@ -0,0 +1,7 @@
	1	+This folder contains an Azure pipeline definition that is used for building our
	2	+Android companion apps, in particular the Sailing Race Manager app and the
	3	+Buoy Pinger app. See also the mobile/ folder for their source code. The
	4	+gradle build that is used at the core of this build pipeline is controlled
	5	+by the ``build.gradle``and ``gradle.properties`` file in the root folder.
	6	+A local Android app build can be achieved by running the ``gradlew``
	7	+wrapper script from the root folder.

...	...	@@ -0,0 +1,3 @@
	1	+This folder is used by the workflow defined in ``.github/workflows/reuse-tool-license-updates.yml``
	2	+and produces machine-readable licensing information for the entire repository into the dep5 file
	3	+in this same folder.

...	...	@@ -1,7 +1,9 @@
1	1	GEM
2	2	remote: https://rubygems.org/
3	3	specs:
4		- CFPropertyList (3.0.6)
	4	+ CFPropertyList (3.0.7)
	5	+ base64
	6	+ nkf
5	7	rexml
6	8	addressable (2.8.5)
7	9	public_suffix (>= 2.0.2, < 6.0)
...	...	@@ -24,6 +26,7 @@ GEM
24	26	aws-sigv4 (1.6.0)
25	27	aws-eventstream (~> 1, >= 1.0.2)
26	28	babosa (1.0.4)
	29	+ base64 (0.2.0)
27	30	claide (1.1.0)
28	31	colored (1.2)
29	32	colored2 (3.1.2)
...	...	@@ -161,6 +164,7 @@ GEM
161	164	multipart-post (2.3.0)
162	165	nanaimo (0.3.0)
163	166	naturally (2.2.1)
	167	+ nkf (0.2.0)
164	168	optparse (0.1.1)
165	169	os (1.1.4)
166	170	plist (3.7.0)
...	...	@@ -171,7 +175,8 @@ GEM
171	175	trailblazer-option (>= 0.1.1, < 0.2.0)
172	176	uber (< 0.2.0)
173	177	retriable (3.1.2)
174		- rexml (3.2.7)
	178	+ rexml (3.2.8)
	179	+ strscan (>= 3.0.9)
175	180	rouge (2.0.7)
176	181	ruby2_keywords (0.0.5)
177	182	rubyzip (2.3.2)
...	...	@@ -184,6 +189,7 @@ GEM
184	189	simctl (1.6.10)
185	190	CFPropertyList
186	191	naturally
	192	+ strscan (3.1.0)
187	193	terminal-notifier (2.0.0)
188	194	terminal-table (3.0.2)
189	195	unicode-display_width (>= 1.1.1, < 3)
...	...	@@ -199,7 +205,7 @@ GEM
199	205	unicode-display_width (2.5.0)
200	206	webrick (1.8.1)
201	207	word_wrap (1.0.0)
202		- xcodeproj (1.23.0)
	208	+ xcodeproj (1.24.0)
203	209	CFPropertyList (>= 2.3.3, < 4.0)
204	210	atomos (~> 0.1.3)
205	211	claide (>= 1.0.2, < 2.0)

...	...	@@ -5,7 +5,7 @@ BODY=$( cat )
5	5	echo "${BODY}" >/tmp/github-hook-body
6	6	REF=$( echo "${BODY}" \| jq -r '.ref' )
7	7	PUSHER=$( echo "${BODY}" \| jq -r '.pusher.email' )
8		-logger -t github-cgi "ref ia $REF, pusher was $PUSHER"
	8	+logger -t github-cgi "ref is $REF, pusher was $PUSHER"
9	9	# For testing:
10	10	#if [ "${PUSHER}" = "axel.uhl@sap.com" -a "${REF}" = "refs/heads/translation" ]; then
11	11	if [ "${PUSHER}" = "tmsatsls+github.tools.sap_service-tip-git@sap.com" -a "${REF}" = "refs/heads/translation" ]; then
...	...	@@ -13,7 +13,7 @@ if [ "${PUSHER}" = "tmsatsls+github.tools.sap_service-tip-git@sap.com" -a "${REF
13	13	echo "Fetching translation branch from github.tools.sap and pushing it to ssh://trac@sapsailing.com/home/trac/git"
14	14	logger -t github-cgi "fetching translation branch from github.tools.sap and pushing it to ssh://trac@sapsailing.com/home/trac/git"
15	15	cd /home/wiki/gitwiki
16		- sudo -u wiki git fetch sapsailing translation:translation 2>&1
	16	+ sudo -u wiki git fetch github translation:translation 2>&1
17	17	sudo -u wiki git push origin translation:translation 2>&1
18	18	else
19	19	echo "Either pusher was not tmsatsls+github.tools.sap_service-tip-git@sap.com or ref was not refs/heads/translation. Not triggering."

...	...	@@ -45,10 +45,13 @@ done
45	45	# alter records using batch file.
46	46	sed -i "s/LOGFILES_INTERNAL_IP/$LOCAL_IPV4/" batch-for-route53-dns-record-update.json
47	47	sed -i "s/SMTP_INTERNAL_IP/$LOCAL_IPV4/" batch-for-route53-dns-record-update.json
	48	+HOSTED_ZONE_ID=$( aws route53 list-hosted-zones \| \
	49	+ jq -r '.HostedZones[] \| select(.Name == "sapsailing.com.").Id' \| \
	50	+ sed -e 's\|/hostedzone/\|\|' )
48	51	read -n 1 -p "Check the instance has the correct tags and is in the correct target group.
49	52	Furthermore, check the batch file batch-for-route53-dns-record-update.json has been modified correctly.
50	53	Press a key to continue.." key_pressed
51		-###### DO NOT ENABLE WHILST TESTING: aws route53 change-resource-record-sets --hosted-zone-id Z2JYWXYWLLRLTE --change-batch file://batch-for-route53-dns-record-update.json
	54	+###### DO NOT ENABLE WHILST TESTING: aws route53 change-resource-record-sets --hosted-zone-id ${HOSTED_ZONE_ID} --change-batch file://batch-for-route53-dns-record-update.json
52	55	# reload the nfs mountpoints.
53	56	echo "Waiting 60 seconds for records to change. The program will await a key press after this time."
54	57	echo "Please check the route53 DNS records have been correctly updated."

...	...	@@ -1,16 +1,35 @@
1	1	#!/bin/sh
	2	+# Syncs the necessary branches of a repo at a specified location or, as default,
	3	+# /home/wiki/gitwiki. The assumed checked-out branch is master and the tracking branch
	4	+# is assumed to be origin master.
2	5	ADMIN_EMAIL="axel.uhl@sap.com jan.hamann@sapsailing.com"
3	6	if [ $# -eq 0 ]; then
4	7	GIT_PATH="/home/wiki/gitwiki"
5	8	else
6		- GIT_PATH=$1
	9	+ GIT_PATH="$1"
	10	+fi
	11	+cd "$GIT_PATH"
	12	+git fetch github main:main >/tmp/wiki-git.out 2>/tmp/wiki-git.err
	13	+if [ "$?" != "0" ]; then
	14	+ cat /tmp/wiki-git.out /tmp/wiki-git.err \| mail -s "Wiki git problem: could not fetch github/main into local main" $ADMIN_EMAIL
	15	+fi
	16	+git push origin main:main >/tmp/wiki-git.out 2>/tmp/wiki-git.err
	17	+if [ "$?" != "0" ]; then
	18	+ cat /tmp/wiki-git.out /tmp/wiki-git.err \| mail -s "Wiki git problem: could not push main into sapsailing/main" $ADMIN_EMAIL
	19	+fi
	20	+git pull github main >/tmp/wiki-git.out 2>/tmp/wiki-git.err
	21	+if [ "$?" != "1" ]; then
	22	+ cat /tmp/wiki-git.out /tmp/wiki-git.err \| mail -s "Wiki git problem: could not merge github/main into sapsailing/master" $ADMIN_EMAIL
7	23	fi
8		-cd $GIT_PATH
9	24	git pull >/tmp/wiki-git.out 2>/tmp/wiki-git.err
10	25	if [ "$?" != "0" ]; then
11		- cat /tmp/wiki-git.out /tmp/wiki-git.err \| mail -s "Wiki git problem" $ADMIN_EMAIL
	26	+ cat /tmp/wiki-git.out /tmp/wiki-git.err \| mail -s "Wiki git problem: could not pull origin/master" $ADMIN_EMAIL
	27	+fi
	28	+git push origin master:main >>/tmp/wiki-git.out 2>/tmp/wiki-git.err
	29	+if [ "$?" != "0" ]; then
	30	+ cat /tmp/wiki-git.out /tmp/wiki-git.err \| mail -s "Wiki git problem: could not push master to origin/main" $ADMIN_EMAIL
12	31	fi
13	32	git push >>/tmp/wiki-git.out 2>/tmp/wiki-git.err
14	33	if [ "$?" != "0" ]; then
15		- cat /tmp/wiki-git.out /tmp/wiki-git.err \| mail -s "Wiki git problem" $ADMIN_EMAIL
	34	+ cat /tmp/wiki-git.out /tmp/wiki-git.err \| mail -s "Wiki git problem: could not push master to origin/master" $ADMIN_EMAIL
16	35	fi

...	...	@@ -58,15 +58,17 @@ The primary repository for the app lives at ``trac@sapsailing.com:/home/trac/sai
58	58
59	59	## Triggering and Integrating Translations
60	60
61		-We entertain a Git repo clone at ``https://github.tools.sap/SAP-Sailing-Analytics/sapsailing``. When we push new commits to the ``translation`` branch of that repository (see [https://github.tools.sap/SAP-Sailing-Analytics/sapsailing/tree/translation](https://github.tools.sap/SAP-Sailing-Analytics/sapsailing/tree/translation)) then LXLabs will grab these changes in regular intervals (as of this writing typically every Friday evening) and look for changes in files that belong to any message collection.
	61	+We keep our Git repo at ``https://github.com/SAP/sailing-analytics``. When we push new commits to the ``translation`` branch of that repository (see [https://github.com/SAP/sailing-analytics/tree/translation](https://github.com/SAP/sailing-analytics/tree/translation)) then LXLabs will grab these changes in regular intervals (as of this writing typically every Friday evening) and look for changes in files that belong to any message collection.
62	62
63		-Message collections are declared in the file ``translation_v2.json`` in the root of our Git workspace. Adding new collections to this file requires us to inform LXLabs (e.g., vyacheslav.sklyarenko@sap.com, called "Slava"). They need to make the corresponding update in the so-called [Translation Enablement Workbench](https://tew.ingress.prod.lp.shoot.live.k8s-hana.ondemand.com/#/param/WzIwMiw1NiwiLyIsInRhc2tRdWV1ZSJd).
	63	+Message collections are declared in the file ``translation_v2.json`` in the root of our Git workspace. Adding new collections to this file requires us to inform LXLabs (e.g., vyacheslav.sklyarenko@sap.com, called "Slava"). They need to make the corresponding update in the so-called [Translation Enablement Workbench](https://tew.ingress.prod.lp.shoot.live.k8s-hana.ondemand.com/).
64	64
65	65	During the translation process, translators may have questions regarding new or changed message strings. This will results in tasks being assigned by the Translation Enablement Workbench, and an e-mail to the assignee will result. Currently, the default assignee for these tasks is axel.uhl@sap.com. We then need to answer these questions as soon as possible to unblock the translation process so that ideally we get the translation in the same sweep as those for other languages, in the same round.
66	66
67		-When translations are done, they are pushed to the same ``translation`` branch of ``https://github.tools.sap/SAP-Sailing-Analytics/sapsailing`` by LXLabs and then usually contain the translation of all changed or added message strings. LXLabs goes by the default locale ("en") and ignores all we do in the German ("de") locale.
	67	+When translations are done, they are pushed to the same ``translation`` branch of ``https://github.com/SAP/sailing-analytics`` by LXLabs and then usually contain the translation of all changed or added message strings. LXLabs goes by the default locale ("en") and ignores all we do in the German ("de") locale.
68	68
69		-We have a Github webhook installed (see [https://github.tools.sap/SAP-Sailing-Analytics/sapsailing/settings/hooks/285417](https://github.tools.sap/SAP-Sailing-Analytics/sapsailing/settings/hooks/285417)) which triggers a CGI-BIN script that is installed on sapsailing.com at ``/var/www/cgi-bin/github.cgi`` and is versioned under ``configuration/httpd/cgi-bin/github.cgi`` to which ``/var/www/cgi-bin/github.cgi`` is a symbolic link, and which reacts to pushes from the user with the e-mail address ``tmsatsls+github.tools.sap_service-tip-git@sap.com``, pushing to branch ``translation``. In this case, the Git workspace installed at ``/home/wiki/gitwiki`` for the user ``wiki`` is used to fetch the latest translations, using the Git remote ``sapsailing`` which is expected to use a Personal Access Token (PAT) that is granted read access to the repository. The changes are then pushed to the ``translation`` branch on ``ssh://trac@sapsailing.com/home/trac/git`` which is expected to trigger the [hudson job for the translation branch](https://hudson.sapsailing.com/job/SAPSailingAnalytics-translation/). This, in turn, will run a full build, and if successful, merge the ``translation`` branch into ``master`` and push it back to ``ssh://trac@sapsailing.com/home/trac/git`` which will then trigger the [master's build job](https://hudson.sapsailing.com/job/SAPSailingAnalytics-master/).
	69	+We have a Github webhook installed (see [https://github.com/SAP/sailing-analytics/settings/hooks/480929064](https://github.com/SAP/sailing-analytics/settings/hooks/480929064)) which triggers a CGI-BIN script that is installed on sapsailing.com at ``/var/www/cgi-bin/github.cgi`` and is versioned under ``configuration/httpd/cgi-bin/github.cgi`` to which ``/var/www/cgi-bin/github.cgi`` is a symbolic link, and which reacts to pushes from the user with the e-mail address ``tmsatsls+github.tools.sap_service-tip-git@sap.com``, pushing to branch ``translation``. In this case, the Git workspace installed at ``/home/wiki/gitwiki`` for the user ``wiki`` is used to fetch the latest translations, using the Git remote ``sapsailing`` which is expected to use a Personal Access Token (PAT) that is granted read access to the repository. The changes are then pushed to the ``translation`` branch on ``ssh://trac@sapsailing.com/home/trac/git`` which is expected to trigger the [hudson job for the translation branch](https://hudson.sapsailing.com/job/SAPSailingAnalytics-translation/). This, in turn, will run a full build, and if successful, merge the ``translation`` branch into ``master`` and push it back to ``ssh://trac@sapsailing.com/home/trac/git`` which will then trigger the [master's build job](https://hudson.sapsailing.com/job/SAPSailingAnalytics-master/).
	70	+
	71	+TODO Github Publication: With the "translation" branch being pushed to github.com, a build for the translation branch will start automatically using Github Actions. If we renamed our "SAPSailingAnalytics-translation" job to just "translation" then the magic should work and we should get a trigger for the "translation" job when the Github Actions build is done.
70	72
71	73	First building in a separate job before merging into master partly goes back to the times when LXLabs had issues exporting Java properties file syntax when placeholders and single-quote characters were used in the translations; a common problem in the French translations. However, this has improved massively, and we haven't seen any translation-incurred build errors in a long time. Yet, we stick to the process.
72	74

...	...	@@ -0,0 +1,30 @@
	1	+# Domain Switchover
	2	+
	3	+## Locations that reference sapsailing.com
	4	+
	5	+- The ChargeBee subscription module used for payment services has a callback method pointing to ``sapsailing.com`` where updates to the users are processed and then replicated across the landscape.
	6	+
	7	+- ``SharedLandscapeConsants.DEFAULT_DOMAIN_NAME`` is set to "sapsailing.com" but can be overridden; for things to work, however, we would need to add the deviating domain as a "hosted zone" to our Route53 account so that the DNS-maintaining logic will run without exceptions.
	8	+
	9	+- The certificate used in the ALBs is created for \.sapsailing.com; to run under a different domain name, a certificate matching the domain name will be required. The ALB set-up in AwsLandscapeImpl.createLoadBalancerHttpsListener uses the default certificate domain "\.sapsailing.com" from a constant; this would need to be made flexible, e.g., through a system property, if we were to use any form of landscape automation under a different domain name.
	10	+
	11	+- Shared security configuration as in
	12	+ env.sh:#ADDITIONAL_JAVA_ARGS="$ADDITIONAL_JAVA_ARGS -Dsecurity.sharedAcrossSubdomainsOf=sapsailing.com -Dsecurity.baseUrlForCrossDomainStorage=https://security-service.sapsailing.com -Dgwt.acceptableCrossDomainStorageRequestOriginRegexp=https?://(.\\.)?sapsailing\.com(:[0-9]\)?$"
	13	+
	14	+- The ``target-group-tag-route53-nfs-elasticIP-setup.sh`` script used as the last stage of the setup process of a new central reverse proxy. It queries the Route 53 ID of the "sapsailing.com" hosted zone which would have to become a parameter or would need to be changed in the script.
	15	+
	16	+- Mail sending and Amazon SES.
	17	+
	18	+- ``REPLICATE_MASTER_SERVLET_HOST`` is sometimes hardcoded.
	19	+
	20	+- Igtimi Authentication: the Igtimi REST API and authentication scheme uses a callback URL that we have configured on the igtimi.com web site, pointing to sapsailing.com.
	21	+
	22	+- Google Maps API is SAP provided in our current production environment, and a different API token/key is required once SAP stops its support.
	23	+
	24	+- A number of bash scripts have sapsailing.com hardcoded, especially the setup scripts and imageupgrade_functions.sh. Ideally we will need to factor out into a constant that all bash scripts can access.
	25	+
	26	+- Releases and p2 respository references, where "releases.sapsailing.com" will be replaced over time by Github releases which the ``refreshInstance.sh`` script can then download.
	27	+
	28	+- MongoDB references and rabbit references, or any other private IP references in route53. Such references can in particular be found in the ``environments/`` folder on ``releases.sapsailing.com`` for the default parameterization of certain application process types, such as ``security-service-master`` or ``archive-server``.
	29	+
	30	+- branch.io is used for "deep linking" for the apps. We have an integration with our Route53 hosted zone "sapsailing.com" for the specific domain names, allowing smart payload transfer through from-scratch installations, e.g., from a QR code. The branch.io account would need to be transferred and would need to have the configuration changed; or a new account would be required. The apps' deep linking capabilities are expressed in their manifests, and hence the apps would need to be adjusted to work with a different domain.
...	...	\ No newline at end of file