Server Management
If you are new to Linux, I recommend you visit the Linux Primer page first.
Manage your Server - Start, Stop, Restart and Status
Simple Backup and Restore - Database Only
Off-site Backup and Restore - Database Only
Discussion:- https://linuxconfig.org/getting-started-with-aws-s3cmd-command-by-examples
- How to perform a backup using aws cli (awscli) - an alternative to s3cmd
- To install awscli: sudo apt-get install awscli -y
- To configure awscli: aws configure
- To backup a file in the current directory: aws s3 cp somefile.jar s3://YourBucketName/SubFolderName/
- To download a file in the current directory: aws s3 cp s3://YourBucketName/SubFolderName/somefile.jar ./
Backup All and Restore All - Moving both Binaries and Data
The purpose of this page is to help you manage test servers that are near-exact duplicates of production. Creating and managing test servers (UAT, Test, Dev, etc...) can be tough. Specifically, it is tough to create an exact duplicate of the production system to ensure what you are testing will behave the exact same way in production when released. Here are the steps to create your test system. Note these steps assume you are using Amazon's AWS; however, the concepts are the same for VMWare or Virtualbox.- Create a back on your production server using the below script. It will back up both your iDempiere binaries and database for use below.
- /opt/chuboe/idempiere-installation-script/utils/chuboe_backup_all.sh
- Create an image of your production server
- Launch a new server from that image called test
- ssh to your new TEST server
- Sudo edit the /etc/hosts file to point to the appropriate internal IP address
- Edit the /opt/chuboe/idempiere-installation-script/utils/chuboe.properties
- CHUBOE_PROP_IS_TEST_ENV="Y"
- Make sure the test server has the production server's pem
- Copy the pem to the test server
- Place in /home/idempiere/.ssh/PEMHere.pem
- sudo chown idempiere:idempiere
- sudo chmod 400 PEMHere.pem
- Edit the /opt/chuboe/idempiere-installation-script/utils/chuboe_restore_all.sh script
- TMP_REMOTE_BACKUP_SERVER=SetTheURLOfYourProductionServer
- TMP_SSH_PEM=" -i /home/$CHUBOE_PROP_IDEMPIERE_OS_USER/.ssh/YOUR_PEM_NAME.pem"
- Note that the bottom of chuboe_restore_all.sh includes SQL to disable production only services/settings
- Run the /opt/chuboe/idempiere-installation-script/utils/chuboe_restore_all.sh script from your test server
- Watch the logs to ensure all executed as expected
Connecting to Your Database with phppgadmin and psql
- DBeaver - active eclipse plugin for database admin and query
Disaster Recovery and Prevention
Disk space issues cause 90% of iDempiere failures. Here are linux commands that help you diagnose and resolve disk issues:- "sudo df -h" - tells you if any drive is getting full
- "cd /; sudo du -h > ~/disk_usage.txt; less ~/disk_usage.txt" -
- changes to the root directory;
- creates a file with each directory size;
- shows you the file it created.
- Inside the file browser type "/G^I" to find all directories that are in the GB range. You are looking for iDempiere related files that you realize should not exist or be quite so big. Example: /opt/idempiere-server/logs/
- Type "q" to leave the file viewer.
- Note: this command may take some time to execute.
- If you still cannot get iDempiere up and running, the iDempiere configuration might be corrupted. Perform the following commands to reset the configuration:
- "cd /opt/idempiere-server/; sudo -u idempiere ./console-setup.sh" and press enter at each of the prompts.
- "sudo service idempiere start" to start idempiere
- Keep an offsite database backup using (a) the /opt/chuboe/.../util/chuboe_backup_s3cmd.sh or (b) by maintaining a PostgreSQL read replica, or (c) both. I recommend you run this script before you reboot or perform any change that could alter the state of your server. Doing so is somewhat paranoid; however, it gives you a nearly free pass to get out of trouble.
- The installation script automatically adds the /opt/idempeire.. directory to a mercurial repository by executing the /opt/chuboe/.../util/chuboe_hg_bindir.sh script. You can update the chuboe_hg_bindir.sh script to also push the idempiere directory to a private remote repository. This script should be on a cron job to run every couple of hours. This script has many side benefits including detecting and undoing malicious changes.
- AWS offers a machine imaging service. If you create a new image anytime you modify the system's configuration (add new software, add a new script, etc...), you can always create a replacement clone of the troubled server within moments of issues like the one you are describing. The alternative to AWS imaging is to have a disaster recovery manual that tells you step by step how to rebuild a server from scratch. I prefer this option because (a) it is less expensive than keeping X versions of machine images, (b) when I upgrade a server, I always start from scratch, (c) business continuity (disaster recovery) people love this option because of the built-in documentation.
- Create a new instance from your most recent AWS image. Make sure the new image gets the same internal and external IP address as your old server.
- Perform an hg pull and hg update in your /opt/idempiere-server/ directory to get a bit-for-bit copy of your production idempiere binary. This will include plugins as well.
- Restore your database from your most recent backup.
- Enjoy a great pay raise for saving the day (even though no one will probably know the day was in peril to begin with)
iDempiere Group Permission for Management
The below discussion offers options to make OS level user management easier for larger teams:
https://groups.google.com/g/idempiere/c/G8Y7sloeh14/m/AjlDyW_0BgAJ