Upgrade guide Abas 2024.Q3

In Abas it is possible to log in using only a password and not, as usual, with the combination of user name (or ID) and password. This approach has disadvantages in terms of security and cross-system authentication.

Therefore, be sure to use the system login or SSO login.

In password definitions (see Online Help) you can specify which login you can use to log in.

You should definitely adapt the standard password of the following password definitions with an Abas login:

In the Online Help you will find the following important instructions on how to encrypt specific connections:

Self-signed certificates are not recommended for security reasons and are therefore not supported.

The minimum version for upgrades to Abas 2024.Q3 is Abas 20 (2019r4n20).

The script erpOSPrepare.sh checks the settings of sshd_config upon startup.
It cancels at the end if the StrictModes setting in the file is not set to "no".

Why set "StrictModes no"?
StrictModes is used to check the permissions of the user. As Abas uses the group permissions to a great extent, StrictModes must be set to "no". With "StrictModes yes", the client users have no access to Homedir files, even though they belong to the same group (abas).

The following section describes what the script does after being called . You can call the script without concern. After the call you will receive a monitor display with information to review or ToDos. The script will not actually be run until you actively confirm with "y" (yes). To just see what the script does, you must cancel with "n" (no)!

IMPORTANT:

If the script freezes when checking "wget" and outputs the message "Try to install bootstrap package "wget" …​", cancel the script. Check your internet access. You will find information about this in the Troubleshooting chapter, section problems with access to the Internet (wget, curl, …​).

The /etc/selinux/config file is checked. If selinux is not set to "disabled", you will get this output:

You must do the following, if the above output is displayed:

Note that the server takes some time to restart. Check whether the internet connection still works after the reboot.

Do not yet confirm the entry at the end of the script with "y"! Read the following explanations first!

Important
If you have a "D" in the Docker root dir line, exit the script call using "n".
Edit the Docker root dir as described in the Change Docker root directory section.

In this case, multiple system services are configured in _/etc/services _ on port 6550.
These can be Abas services (EDP) or other system services. The configuration script cannot determine this, as the name of the system service ("EDP" in this case) may have been changed.

The following message is displayed: "WARN: multiple services found in /etc/services!".
Check the ports and system services in /etc/services.
Ensure that there are no competing services on the specified port and change the configuration accordingly (port number in /etc/services and Abas variable).

The following is done by the erpOSPrepare.sh script after you confirm with "y":

Note:

You can only see the following screenshot if you scroll up.

Note on new installation:
All users are always newly created. Already existing users are deleted beforehand (users were previously marked with a *)!

Note on upgrade:
Only the new users are created. For all system users required for operating Abas (here, for example: s3, erp, demo, leer), it is expected that they already exist in the system. These users were previously marked with a *. These users are not newly created.

The passwords for newly created users are recorded in:
/mnt1/tools/abas/CDftp-2200r8n02/Messages/erpOSPrepare.passwd (if you did not deactivate the password assignment using the environment variable REMOVE_PASSWD=1 when calling the script).

A detailed description of which files and services have been executed or edited can be found in the next section Script created or edited the following files.
In the last line of the script output on the monitor, you can find the command for starting the Abas installation or upgrade process. Do not start the installation/upgrade until you have read the following section up to the chapter Upgrade Abas.

During the preparation phase, the server is prepared for the upgrade process. This includes, for example:

During the test phase, the system, the Homedir, and the individual clients are tested. The upgrade carries out tests to ensure that the upgrade can run without problems.
During the test phase, Abas can be used as usual.
Required preparations for Abas can be made any time during operation.
After completing the test phase, the upgrade will stop as planned.

NOTE:

During the upgrade phase, the actual upgrade of the Homedir and individual clients takes place.
The upgrade phase must not be interrupted.

IMPORTANT:
There are sections that are classified as "critical" and must run without errors. If a "critical" section fails, the upgrade is lost in any case. A critical section cannot be repeated!
The upgrade attempts to complete each phase in all clients. Only when the upgrade phase was successful in all clients, the rest phase is started.
For example, if the rest phase fails in C_SECTION=1420 (configuration of AJO interface) in a client, the process is only canceled in this client.
The rest phase is started anyway in all other clients.

How to create a tenant ID is described in this documentation.

If you call the script without options or with --list, you will receive a list of all Abas systemd services.
You can list the system services as the root user or s3 user.

If you were to execute the above call with a different "s3" user, system services would be missing from the output. The system services specified above are not installed for this second "s3" user.

Systemd works with so-called “units”. The names of the system services listed under 2.1 are such “units”. For example, "s3-help-s3.service" or "s3-ice-erp.service"
The status of an Abas system service can be output as the root user or s3 user.

In this example, the system service is loaded and active (running).

To install systemd services, you must be the root user (or a user who has sudo rights)!

To install a systemd service, there must be the necessary .service and/or .socket files. For the EDP and DATMOD system services, the systemServices_admins.sh script can generate these files itself. For all other services, they must be created in a different way and then passed to systemServices_admin.sh as a parameter so that the service can be installed in the operating system.

In order to create EDP and DATMOD services, the HOMEDIR of the installation must be known. This can be an existing installation (then integrate the s3 environment as the root user) or a new installation (then set the future HOMEDIR as a parameter).

To remove systemd services, you must be the root user (or a user who has sudo rights)!
To remove a systemd service, the unit name and type are expected as arguments. The removal is started via --remove and must be forced with the --force option.

In the following, we presume that the erpOSPrepare.sh script has run through and that you want to start the script for a second time.

Note:
If a configuration file erpOSPrepare.cfg is in the bin directory, this cfg is always used. It has precedence over the input of parameters directly in the shell.

Note:
If the script is called with the wrong mount point or without this parameter, it will not help to run the script again with the correct parameters. The generated files and directories must be deleted first (back up beforehand).
It is easiest if you have created a snapshot of the status before calling the script. You can run the script with the new parameters after importing the snapshot.

This message is displayed if StrictModes is not set correctly in the sshd_config file. StictModes must be set to "no"! Follow the instructions under the sshd_config section.

Message: e.g., user s3, rabbitmq cannot be added to group docker.

ToDo:

you must create both the login and the ssh key for the users named. There are two scripts on the installation CD to assist administration:

Run the scripts for the users as follows:

Create user "rabbitmq".
.Hier im Beispiel ist der Name der zugehörigen Gruppe "abas". Das muss evtl. geändert werden.

If you use a user other than "s3", you must change it here! If you use a group other than "abas", you must change it here!

If the error message "Install ice daemon failed" or "Start rabbitMQ failed" is displayed after calling the install-unix.sh script, you can find information on the cause under /mnt1/abas/s3/Messages/ in the corresponding log file.

The following error message is displayed when starting Docker: "Job for docker.service failed because the control process exited with error code. See "systemctl status docker.service" and "journalctl -xe" for details."

Check the docker.service configuration file as described in the above section Message Docker root dir failed.

When changing the Docker root area, there should not be any containers under /var/lib/docker, as it is a new installation.

If there are Docker containers under /var/lib/docker, these must now be shut down and the Docker service ended using "systemctl stop docker". Then copy everything from /var/lib/docker to /mnt1/docker.

Afterward, start Docker so that the change takes effect.

With newer kernels (as of Kernel 3.6), a user can only set a hard link to a file if this file belongs to the user or they have read and write permissions for the file (either through group permissions or the permissions for users other than the owner or owner group).

If you have this type of kernel, there is the file
/proc/sys/fs/protected_hardlinks

The script reports a lack of access to registry.abas.sh (URL registry.abas.sh is only used to test internet access)

Java version 17 is required to operate Abas.

Docker CE (Community Edition) must also be set up so that it is automatically restarted after a reboot.

For call, see:
https://docs.docker.com/install/linux/linux-postinstall/#configure-docker-to-start-on-boot -→ "Configure Docker to start on boot" section.

If you use http/https proxies, you must create an appropriate configuration file.

Follow the guide on the Docker website: https://docs.docker.com/config/daemon/systemd/#httphttps-proxy -→ "HTTP/HTTPS proxy" section.
There, you can find a detailed description of how to create a new directory and a configuration file and which content the configuration file must have.

After entering your proxy server in the configuration file, proceed with the next step:

If there is no output, the proxy entry is not correct or the configuration file is not in the correct location.

Docker stores its data and containers under /var/lib/docker by default.
As this area is too small, the Docker root area must be moved to a larger partition. The erpOSPrepare.sh script cancels the installation if you did not change the Docker root.

For current Docker versions (from 17.x.x), the old configuration of the Docker root environment (in /etc/default/docker or /lib/systemd/system/docker.service) can no longer be recommended. With every Docker upgrade, these files are replaced by the standard Docker values. Individual changes will be lost, which may lead to Docker being moved back to the (too small) standard root partition.

Docker containers may write much log output to the hard disk. To prevent that the hard disk becomes full (Abas may stop completely!!) limiting the logging of Docker is recommended.

Amend the "/etc/docker/daemon.json" file so that it looks like this:

You can find the log files in the following directory:
/path/to/docker/engine/containers/<container-id>
The names are formed as follows:
<container-id>-json.log ⇐== active log file
<container-id>-json.log.1
<container-id>-json.log.2
etc.

Thus, the default logging is set for all containers. Note that every container can be started with individual log options which overwrite this default logging.
See also: https://docs.docker.com/config/daemon/

If you make changes to the Docker configuration (e.g., the daemon.json mentioned above), you have to restart the Docker daemon for the changes to take effect.
First try a "reload" to just read in the configuration again. If you are sure that all Docker containers that are still running belong to the installation you are administering, you can safely execute a "restart" or "stop" and "start".

You don’t need to do anything (the following explanation is for understanding only):

Docker must also run under the user s3. The user s3 will be automatically added to the docker-group by the erpOSPrepare.sh script.
If the user s3 is missing in the docker-group, run the command below.

You can use the parameters below when calling the erpOSPRrepare.sh script. You can keep the standard values or assign custom values to the parameters. The explanation in the right column refers to the entries in the "Values" column. If you use other values, for example, mount point is not /mnt1 but /u, you must adjust the description text to your value.

Example: Call RABBITMQ_CONTAINER_PREFIX=abastest
.erzeugt als Containernamen abastest_abasrabbitmq_1

If you

must rename the following files on the old computer

Otherwise it might happen, when an application program is unintentionally run on the old computer, that data will be written to the new database - which might have really adverse effects. The unintended program start may be caused by a computer with old cache information or because of a start via crond, for example.

This copy command with rsync can be canceled and executed again at any time, if the backup lock is reset or remains set in all clients. The command does not require any shares or NFS mounted directories. The files to be copied are copied very quickly through the ssh tunnel, in the case of GBit networks at full disk speed (e.g., 30 MB/s, the theoretical upper limit is 100 MB/s in a GBit network).

Important points:

D: Beim Upgrade dürfen keine Anwendungen aktiv sein.
E: No client processes allowed during upgrade.

If a runnable copy if the installation is concerned, you should keep denv.* in the HOMEDIR and in all clients. Otherwise you must make sure that no one can log in while the upgrade is being performed. If someone logs in anyway (or starts a cron job), the upgrade usually has to be repeated.

During the upgrade, your individual adjustments to the database screens are compared with the current standard screens. Screen Merger takes on the following tasks:

This procedure ensures that both your customizations and the new standard functions of the current Abas version are available in the screens. This allows you to compare both versions clearly and decide which changes you want to apply.

Screen Merger is executed automatically as part of an Abas upgrade. After a successful upgrade, the database screens are merged and generated and can therefore be used in the Abas GUI without further intervention.

However, customized screens may require manual adjustments to achieve an optimal result. The starting point for this work is the report in which Screen Merger lists the adjustments that have been made for each screen and provides recommendations for the next steps.
This report can be found in $MANDANTDIR/Messages/screen-merger/screenMerger-result-*.txt.

The following steps are required:

To determine it, the IP address of "hostname" is queried and then the computer name for the IP address. In the simplest case this is done via the file /etc/hosts. What is important here is the sequence of the entries: IP address, fully qualified name, host name

The variable HOST_HOMEDIR is set in the homedir.env file. It determines on which computer the database is started. If "hostname" und "HOST_HOMEDIR" differ, an attempt is made to build a connection to "HOST_HOMEDIR" and to start the database there.
However, the local communication between database (datmod) and application (eksanw) using the domain sockets is much faster than using the network. hostname and HOST_HOMEDIR should be the same also for this reason.

Evaluate error messages