Installation 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 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 the call . 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 under Troubleshooting 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":

The following screenshot shows: packages are checked

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-2200r8n01/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 Description of the files created or edited by the erpOSPrepare.sh script.
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 Installation Abas.

Information on error messages can be found under Troubleshooting erpOSPrepare.sh.

Possibly missing subdirectories were created and assigned the correct rights in the "abas" directory

No unauthorized access from outside to the Abas server is possible with the users created by the script.  If you want to allow access from outside, you must take additional action and add the required (external) public keys to the respective user under "authorized_keys".

These ssh keys are primarily required for the installation and upgrade. Additionally, they are necessary for administrative scripts (RabbitMQ etc.) as well as for system scripts (e.g., the table of variables reorganization must be able to start and stop RabbitMQ and IceDaemon via a system service).

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.

Default: /var/lib/docker

As this area is too small, Docker must be moved to a larger partition. The guide for this can be found in the Change the Docker root directory section.

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)

It is not sufficient to make an entry in /etc/environment for several commands. You must also enter a proxy server in yum.conf.

If there are still problems accessing the internet, you can also enter the proxy server in the wgetrc file.

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:
.Beachten Sie unten im Code das zusätzliche Komma am Ende von data-root!

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.

In the next chapter, you can find a detailed description of all parameters of erpOSPrepate.sh as well as additional scripts for the creation of users and ssh keys.

Example 1 (standard)

Example 2

Example 3

In addition, call using the parameter REMOVE_PASSWD=1 if the passwords are not to be generated automatically.
The users will not be assigned a password -→ not recommended!!!

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: Create new user
.In das Verzeichnis der Installations-CD oder ins HOMEDIR wechseln.

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

Create ssh key for user "rabbitmq".
.Hier im Beispiel ist der zugehörige Benutzer "s3" und die zugehörige Gruppe "abas". Das muss eventuell geändert werden.