New in patch 6:
FIRE-13597: IRIS Focus could fail to start after a reboot, or after being restarted while Data Manager was unavailable. Startup is now held until Data Manager is actually serving, so the start no longer races the Kubernetes services coming up.
FIRE-13598: When startup did fail, the IRIS Focus process did not exit. The service appeared to be running while serving nothing, which prevented it from being restarted automatically. A failed start now exits properly, so the service is restarted as intended.
FIRE-13651: Each failed Data Manager request leaked a network connection. This had no visible effect in the cases observed, but under a long Data Manager outage it could have exhausted system resources. Connections are now always released.
FIRE-13665: If the Kubernetes control plane became unreachable, requests to Data Manager returned “503 Service Unavailable” even though Data Manager itself was healthy, which made IRIS Focus behave as though Data Manager were down. The Data Manager routes no longer depend on the Kubernetes control plane being reachable. This is applied automatically by the patch script; see section 5.
Together these address the loss of service reported after a Data Manager interruption: IRIS Focus now stays up through more of it, restarts reliably when it does go down, and is less likely to be affected in the first place.
This patch is cumulative. If you have not applied an earlier IRIS Focus 7.5 patch, it also includes the fixes from those patches:
Contact your Vaisala PCS support representative to obtain the iris-focus-7.5-patch-6.tar.gz file containing instructions, software and configuration updates.
Use a secure file transfer method (e.g., SCP, SFTP) to copy the patch file to the
IRIS Focus server. Place the patch file in a temporary directory, such as:
/srv/iris-focus-7.5-patch-6.
Before applying the patch, stop the following IRIS Focus services to prevent any conflicts during the installation process. Use the following command to stop the services:
systemctl stop monit vaisala-radarsw-webapp
Stop only these two services. In particular, leave Kubernetes (microk8s) running: this patch includes a Kubernetes configuration change that is applied while the patch script runs, and that requires a healthy cluster. You can confirm the cluster is up with:
kubectl get nodes
Log in as root (or “sudo -i”) and change to the temporary directory where the patch tar file was stored.
If you used the suggested location, you can use the following commands to switch to the root user and change to the temporary directory:
sudo -i
cd /srv/iris-focus-7.5-patch-6
Next extract and apply the patch using the following commands:
tar xvzf iris-focus-7.5-patch-6.tar.gz
./apply-patch.sh
As well as installing the updated software, apply-patch.sh applies the Kubernetes routing change for FIRE-13665 and restarts the router-service pod. You should see output similar to:
Updating router-service Data Manager routes (FIRE-13665)...
Checking Kubernetes cluster is reachable...
Converting 2 Data Manager route(s) from lb://data-manager-service to http://data-manager-service.vaisala-focus:36000...
Backed up router-service-configmap to /etc/vaisala/radarsw/router-service-configmap.json.before-7.5-patch-6
configmap/router-service-configmap patched
Updated /etc/vaisala/focus/k8s/vaisala-focus.yaml so the change survives a re-apply
Restarting router-service so it picks up the new configuration...
deployment "router-service" successfully rolled out
Verifying Data Manager routes respond through localhost:31000...
/vsp/api/v1/sources/ -> HTTP 200
/focus-dm/api/v2/volume-configurations -> HTTP 200
FIRE-13665: router-service Data Manager routes now use ClusterIP DNS and are serving.
If that step reports a problem, apply-patch.sh finishes the rest of the patch and then prints an ACTION REQUIRED block telling you to re-run it once the cluster is healthy:
sudo ./patch-router-configmap.sh
That script is safe to run more than once; it detects when the change is already in place and does nothing.
The change is made in two places, which is deliberate. The first is the running configuration in Kubernetes, which takes effect immediately. The second is /etc/vaisala/focus/k8s/vaisala-focus.yaml, the copy of the configuration kept on disk and re-applied whenever IRIS Focus is installed or upgraded. Without the second, a later upgrade would silently restore the old routing.
As with the configuration files in section 6, the previous contents of both are kept:
/etc/vaisala/radarsw/router-service-configmap.json.before-7.5-patch-6
/etc/vaisala/focus/k8s/vaisala-focus.yaml.before-7.5-patch-6
The first is outside the patch directory, so it survives the cleanup in section 9. Should you ever need to put the original routing back:
kubectl apply -f /etc/vaisala/radarsw/router-service-configmap.json.before-7.5-patch-6
cp -a /etc/vaisala/focus/k8s/vaisala-focus.yaml.before-7.5-patch-6 /etc/vaisala/focus/k8s/vaisala-focus.yaml
kubectl -n vaisala-focus rollout restart deployment/router-service
The script prints these two commands when it finishes, so you do not need to note them down.
Once the patch is applied, the /usr/vaisala/radarsw/version should show 7.5.6. You can check this with the following command:
cat /usr/vaisala/radarsw/version
If you have already applied an earlier IRIS Focus 7.5 patch, and you completed the configuration steps for it at that time, you can skip this whole section. The fixes in patch 6 require no configuration file edits of your own: the Kubernetes routing change for FIRE-13665 is applied for you in section 5, and the startup change for FIRE-13597 is installed as part of the software.
The rest of this section applies when you are moving to patch 6 from an installation that has not had an earlier 7.5 patch applied.
The application.yaml file required changes for this patch that will require human review and editing. You will need to transfer information from your previous application.yaml file into the appropriate locations in the new application.yaml file. In, in particular:
A backup of your original application.yaml file is included in the patch with the name application.yaml.before-7.5-patch-6. You can use this file to review the settings you had in place before the patch and transfer them to the new application.yaml file.
The way IRIS Focus integrates with LDAP has been replaced. The way LDAP integration is configured is different. You will not be able to directly copy your prior ldap configuration into the new application.yaml file. LDAP configuration uses the same basic parameters but the layout is different and you no longer need to specify a “sudo” LDAP user account (which should make your IT department happier). The new template configuration file has additional comments that should help explain the parameters and how to configure them.
To see the differences between the old and new configuration files, you can use the following command:
cd /etc/vaisala/radarsw/webapp
diff application.yaml application.yaml.before-7.5-patch-6
Please review all differences. You will need to restore your Kafka settings apply your LDAP settings to the new configuration file. You may also have other custom settings that you will need to restore in the new configuration file.
Hint: If you have emacs installed and know how to use ediff, you can use the following command to compare the two files side by side with differences highlighted and the ability to easily copy changes from one file to the other:
emacs -nw application.yaml application.yaml.before-7.5-patch-6
A README-LDAP.md file is included detailing how LDAP integration is done, configured as well as some troubleshooting tips. Please refer to that file for much more information if you have not already received it in an alternative form.
NOTE: This step applies to every installation. The patch installs an updated haproxy.cfg over /etc/haproxy/haproxy.cfg, so you should review it even if you do not intend on upgrading the haproxy package.
It was discovered that the /etc/haproxy/haproxy.cfg created by the IRIS Focus 7.5 installation is not compatible with newer versions of the haproxy package. This can be an issue for installations that have automatic updates enabled for OS packages.
If you upgrade the haproxy package to a newer version, such as 2.8.0 or later, it will refuse to start until you make changes to the haproxy.cfg file that was created at the time IRIS Focus was installed.
The haproxy.cfg file is sometimes tweaked by customers for the particular installation. This patch installs the updated haproxy.cfg and preserves a copy of the one that was on your system beforehand, so that you can restore any customizations you had made.
Compare the two files and re-apply any of your own customizations to /etc/haproxy/haproxy.cfg:
cd /etc/haproxy
diff haproxy.cfg.before-7.5-patch-6 haproxy.cfg
After applying the patches and making any necessary changes to the configuration files, restart the IRIS Focus services using the following command:
systemctl start vaisala-radarsw-webapp monit
If you had to make changes to the haproxy.cfg file, you will also need to restart the haproxy service:
systemctl restart haproxy
First confirm the system came up normally. IRIS Focus takes a little over a minute to start, and with this patch the start now waits for Data Manager, so allow a couple of minutes before concluding anything is wrong.
systemctl status vaisala-radarsw-webapp
This should report “active (running)”. Then confirm it is actually serving, which is the check that matters:
ss -ltnp | grep 24080
This should show a listening socket. Open IRIS Focus in a browser and confirm you can log in and that radar products display as usual.
Note that your browser may still be holding cached files from before the patch. If the page looks wrong after the patch, force a reload (Ctrl-Shift-R in most browsers) before reporting a problem.
Next confirm the Data Manager routing change is in effect. Both of these should report 200:
curl -s -o /dev/null -w '%{http_code}\n' http://localhost:31000/vsp/api/v1/sources/
curl -s -o /dev/null -w '%{http_code}\n' http://localhost:31000/focus-dm/api/v2/volume-configurations
Finally, the most useful confirmation of the startup fix is a reboot, if you are able to schedule one:
systemctl reboot
After the system comes back, check that IRIS Focus started on the first attempt:
systemctl status vaisala-radarsw-webapp
journalctl -u vaisala-radarsw-webapp -b | grep rsw-wait-for-data-manager
The second command shows the startup wait doing its work, for example:
rsw-wait-for-data-manager: waiting for Data Manager at localhost:31000 ...
rsw-wait-for-data-manager: Data Manager ready after 47.2s (24 attempt(s)) - releasing webapp start
A wait of anything from a second or two up to a few minutes is normal and depends on how quickly Kubernetes starts on your hardware. Before this patch, this is the window in which IRIS Focus could fail to start.
If IRIS Focus does not come up, the relevant log is:
/var/log/vaisala/radarsw/webapp/webapp.log
Please include that file, and the output of “journalctl -u vaisala-radarsw-webapp -b”, in any report to Vaisala support.
After the patch has been successfully applied and the services have been restarted, you can remove the patch file and the temporary directory to free up space on the server. If you used the suggested location, use the following command to remove the patch file and temporary directory:
rm -rf /srv/iris-focus-7.5-patch-6