Installation troubleshooting
You can address any installation issues with some basic steps:
- Make sure that you have already properly configured firewall on all servers. This can be cause of errors during installation of some components.
- Make sure that you have performed all steps from the initial Linux Server configuration description. Selinux in running state or incorrect limits can be cause of errors during starting and running some components.
- Make sure there is enough disk space on each server. Limited disk space can cause a failure to install, a failure to upgrade, or problems with running some components. See disk requirements in the system requirements.
- Make sure that you have correct DNS configuration. This can be cause of errors for access to WF Web UI and S3 Emulator. For more details, see the Configure DNS server section.
- In the case of the installation from a non-privileged (non-root) user, all settings described in the Non-root server prerequisites section should be applied. This can cause a failure to install, a failure to upgrade, or problems with running some components.
Ansible installer logs
If something goes wrong, you can find installation logs in the logs directory with the ansible installer.
Logs are named in the following format:
install_flat:{ operation }_%year%month%day%hour%minute
For example:
ls -1 <dir>/logs
install_flat:precheck_1801311305
install_flat:preinstall_1801311306
install_flat:check_1801311327
install_flat:install_1801311307
Using wfmanager to Control Services
There is a small utility called wfmanager that is aimed to facilitate the management of WorkFusion applications. Log in as <wf_user> and run the wfmanager command to use the utility:
# Will show status of all applications
wfmanager status
# Start, stop, restart individual services
wfmanager start nginx
wfmanager restart nginx
wfmanager stop nginx
# Show log tail of an application
wfmanager tail nginx
# Start, stop, restart all at once
wfmanager start all
wfmanager restart all
wfmanager stop all
# Show status and start an interactive console.
# The console enables the user to run all the same commands without typing `wfmanager` every time.
wfmanager
There is a special "fake service" named start-all used purely for autostart applications after (re)boot. There is no need to control it manually.
Checking logs
The logs for each individual application are stored as:
<wf_home>/supervisord/log/<app_name>.out.log<wf_home>/supervisord/log/<app_name>.err.log
for application's stdout and stderr messages respectively.
Enabling cron
note
Follow the instructions below only if some changes appeared in /etc/cron.allow or /etc/cron.deny or in PAM configurations.
Check that the /etc/cron.allow file is empty or that {{ wfuser }} added to /etc/cron.allow. Otherwise, an error like this one can appear:
TASK [logrotate : Ensure logrotate is enabled via cron job] *********************************************************************************************************************************
fatal: [db-local]: FAILED! => {"changed": false, "msg": "You (AP-wfuser.im) are not allowed to use this program (crontab)\nSee crontab(1) for more information\n"}
To allow or deny access to specific users, crontab uses the /etc/cron.allow and /etc/cron.deny files. For example, add the user with the AP-wfuser name to /etc/cron.allow:
$vi /etc/cron.allow
root
+AP-wfuser
Check that {{ wfuser }} isn't restricted through the PAM policies. Otherwise, an error like this one can appear:
[wfuser@rhel-server]$ crontab -e
You (wfuser) are not allowed to access to (crontab) because of pam configuration.
To enable the user to use cron in the login access control table file, use the following entry that allows the wfuser user to run cron jobs:
$vi /etc/security/access.conf
# Allow the coins user to run cron jobs
+: wfuser : cron crond :0
#Ensure it is above the last entry:
# Deny all other users access by any means.
-: ALL : ALL