Fixes
| UNI-35676 |
UFW error issued by the RMS installer script on Debian Linux 12 |
| UNI-35602 |
The SCP server doesn't start on SUSE linux 15 SP5 |
| UNI-35577 |
On Oracle Linux 9 the RMS install script does not recognize the OS as one that supports the SCP server. |
| UNI-35559 |
The log file, generated by the RMS install script, misses the start part. |
| UNI-35525 |
Redundant RMS servers using a cloud leased license don't have a valid license after rebooting the system |
| UNI-35230 |
On Red Hat 9.3 installations, the RMS service and the SCP service (if installed) do not get started automatically after the system reboot. |
UNI-35676 - UFW error issued by the RMS installer script on Debian Linux 12
Solution available in patch(es): 10.4.02-040
Description:
On some Debian systems UFW (Uncomplicated FireWall) might not be installed but still have the directory /etc/ufw. This leads the RMS install script to believe it is installed and it will try to use it to open a port for RMS to use. This will fail.
Environment:
+Uniface Version: 10.x
+Operating System: Debian Linux 12
+Database: DBMS independent
+RMS Version: Version independent
Workaround:
As a workaround you can remove or temporarily rename the /etc/ufw directory prior to running the script. If you already ran the script and installed the RMS server you may need to open the port manually afterwards for RMS to be accessible.
Notes:
This problem is solved.
UNI-35602 - The SCP server doesn't start on SUSE linux 15 SP5
Solution available in patch(es): 10.4.02-040
Description:
The SCP service does not start because the executable sntlcloudps64_unifacebv does not have the executable bit set.
Environment:
+Uniface Version: 10.x
+Operating System: SUSE Linux 15 SP5
+Database: DBMS independent
+RMS Version: Version independent
Workaround:
As a workaround, you can set the executable bit on sntlcloudps64_unifacebv after installing RMS and the SCP servers using the chmod +x command, as root. After that, restart the rms.target service:
systemctl stop rms.target
systemctl start rms.target
The SCP servicve should now start. You can check that it did:
systemctl status scp
Notes:
This problem is solved.
UNI-35577 - On Oracle Linux 9 the RMS install script does not recognize the OS as one that supports the SCP server.
Solution available in patch(es): 10.4.02-040
Description:
Because the script doesn't recognize Oracle Linux 9 as a RedHat compatible system it will warn that cloud licenses are not supported and will not install the SCP server.
Environment:
+Uniface Version: 10.x
+Operating System: Oracle Linux 9
+Database: DBMS independent
+RMS Version: Version independent
Workaround:
Prior to running installrms.sh, edit the script. Find the following line:
TARGET_OS=`uname -s`
and replace it with
TARGET_OS="RedHat"
on your Oracle Linux system.
After that the script will be able to install the SCP server and cloud licenses can be used.
Notes:
This problem is solved.
UNI-35559 - The log file, generated by the RMS install script, misses the start part.
Solution available in patch(es): 10.4.02-040
Description:
The install script starts writing the log file correctly, but at some point in the process it completely overwrites the log instead of appending to it.
Environment:
+Uniface Version: 10.x
+Operating System: Linux
+Database: DBMS independent
+RMS version: Version independent
Workaround:
Prior to running installrms.sh you can edit this script, changing three occurrences of
... > $INSTALLLOG
into
... >> $INSTALLLOG
and one occurrence of
... tee $INSTALLLOG
into
... tee -a $INSTALLLOG
After that the script will produce a complete log file.
Notes:
This problem is solved.
UNI-35525 - Redundant RMS servers using a cloud leased license don't have a valid license after rebooting the system
Solution available in patch(es): 10.4.02-040
Description:
The RMS service and the SCP service are started in the wrong order, causing them to be unable to communicate. This results in the RMS server not having an updated license file.
Environment:
+Uniface Version: 10.x
+Operating System: Linux
+Database: DBMS independent
+RMS version: Version independent
Workaround:
You can reverse the order yourself by modifying the files rms.service and scp.service in /etc/systemd/system.
First stop the services:
systemctl stop rms.target
Then, in rms.service find this line:
Before=scp.service
and replace the keyword Before with After.
Then, in scp.service find this line:
After=rms.service
and replace the keyword After with Before.
Then do:
systemctl daemon-reload
systemctl reset-failed
All of this has to be done as root.
Notes:
This problem is solved.
UNI-35230 - On Red Hat 9.3 installations, the RMS service and the SCP service (if installed) do not get started automatically after the system reboot.
Solution available in patch(es): 10.4.02-040
Description:
Newer Red Hat installations require a link to default.target in order to be started automatically. The service being enabled is not enough.
Environment:
+Uniface Version: 10.x
+Operating System: Red Hat
+Database: DBMS independent
+RMS version: Version independent
Workaround:
As a workaround you can edit the file rms.target in /etc/systemd/system, and add the following lines at the end:
[Install]
WantedBy=default.target
Notes:
This problem is solved.