New post
AllAccepted answers
Oliver Wilms · Sep 12, 2021

It took a while, but I made some progress. I changed my cube name from iris-for-money to iris4money (no dashes) and then the project compiled with the latest community edition image. zpm behaved a little bit better in later image, but I still had to struggle a lot to get FileCopy to work so I had data to import when installing from zpm.  

I appreciate the help I got from Dmitry Maslennikov when I called ZPM 911 on Discord channel. He pointed out that FileCopy converted filename from export.csv to export.CSV. Eventually I got my zpm testing to complete without errors after I had changed the filename in my repo to export.CSV. Hopefully I will earn ZPM bonus which I have worked so hard for.

Oliver Wilms · Aug 23, 2021

By default, only clients local to the Web Gateway’s hosting computer are allowed access to the Web Gateway Management pages. The browser through which the management forms are accessed must be running on the same machine as the web server and Web Gateway. For example:

http://localhost:<port_no>/csp/bin/Systems/Module.cxw

You can add additional clients to the list of authorized administrators by adding the client IP addresses to the System_Manager parameter in the SYSTEM section in CSP.ini (in install-dir\CSP\bin). The System_Manager parameter represents a comma- or plus-separated list of clients (by IP address) who may access the Web Gateway Management pages. The directive shown below grants access to three remote clients in addition to the default local access.

[SYSTEM]
System_Manager=190.8.7.6, 190.8.7.5, 190.8.7.4
Oliver Wilms · Aug 23, 2021

docker exec -it sam_iris_1 bash
root@IRIS:/tmp# cd /usr/irissys/csp/bin/
root@IRIS:/usr/irissys/csp/bin# ls
CSP.ini  CSP.log  CSPRT.ini  CSPa24.so  CSPa24Sys.so  CSPx.so  libz.so  temp
root@IRIS:/usr/irissys/csp/bin# ls -lt
total 3244
-rw-rw-r-- 1 www-data  www-data     6063 Aug 22 15:56 CSP.log
-rw-rw---- 1 irisuser  irisuser      253 Aug 21 23:57 CSPRT.ini
-rw-rw---- 1 irisuser  irisuser      606 Jun 26  2020 CSP.ini
-rwxrwxr-x 1 irisowner irisowner 1169384 Jun 26  2020 CSPa24.so
-rwxrwxr-x 1 irisowner irisowner  869720 Jun 26  2020 CSPa24Sys.so
-rwxrwxr-x 1 irisowner irisowner 1135208 Jun 26  2020 CSPx.so
-rwxr-xr-x 1 irisowner irisowner  117168 Jun 26  2020 libz.so
dr-xr-x--- 1 irisuser  irisuser     4096 Jun 26  2020 temp

Oliver Wilms · Aug 21, 2021

I need to correct my last response. I did receive WRC response on Friday with this:

After discussing this issue with co-workers:

The message is due to the reassignment of the IP address:

  Yes – the basically the IP address changing underneath the mirror node “changed it’s identity”. This is expected behavior for mirroring.

Possible to setup virtual IP address/or DNS name for each member then in script assign new IP to the member's DNS name

Also not to use ECS but something long these lines found in this link, look it over and see if it applies:

https://medium.com/galvanize/static-ip-applications-on-aws-ecs-c7d411421d4f

Oliver Wilms · Aug 21, 2021

I encountered another challenge this week. I utilized AWS Elastic Container Service (ECS) to deploy two Fargate tasks running IRIS MessageBank Mirror. The first task started on ip-10-xxx-xxx-146. It used failover1 volume which had previously been used by ip-10-xxx-xxx-168. The second task started on ip-10-xxx-xxx-168. The second task ran on failover2 volume. It started MessageBank production and it became Primary. Mirror Service did not start on the first task. In messages.log I saw:

 

Mirroring not started, this instance appears to have been copied. See ^MIRROR

 

I suspect this happened because the randomly assigned IP address for the second task matched the prior IP address of the first task. I opened a support ticket with InterSystems WRC on Tuesday morning and I still wait for their response.