You should add these to the firewalls whitelist and/or gray lists of both your server and MySQL server:
127.0.0.1
69.162.68.206
69.162.64.218
172.105.221.146
138.201.125.171
localhost
installatron.com
dal01.installatron.com
nue01.installatron.com
tok01.installatron.com
{YOUR_SERVER_DOMAIN and IP}
{YOUR_USER'S_DOMAINS and IPs}
Your user's PHP configuration (for all versions of PHP available to your users) should have these values, modules, and extensions to minimize errors and provide the greatest application compatibility:
allow-url-fopen ON date-timezone (must be set) disable-functions (recommended OFF) magic-quotes OFF memory-limit 128M open-basedir (recommended OFF) register-globals OFF safe-mode OFF short-open-tag ON upload-max-filesize 128M bcmath curl fileinfo iconv ioncube imap intl mbstring mcrypt mysql (required for PHP < 7.0 only) mysqli openssl pdo_mysql phar session simplexml soap tiny xml xsl zlib zip
And your server must have net-tools installed. This will install net-tools:
yum -y install net-tools
Additionally, if your server uses Imunify360 then it cannot be set log output to session files or it will break the installation of at least PrestaShop. (At the time of writing this -- 2019/07/25 -- we're told that the next version of Imunify360 will fix this problem.)
Continue to the What is Installatron Server? page.
Installatron automatically adds a Crontab or Windows Task Scheduler process to upgrade/update once per day.
To force an upgrade/update, click run Installatron update now in Administration, or follow the steps on the upgrade page.
Continue to the How to: Uninstall/remove Installatron Plugin page.
To edit a backup so that it can be restored to a different location or web hosting account:
Create a new database within the control panel software on the destination web hosting account.
Copy the application backup archive to a second location so in the event something goes wrong this process can be restarted.
Extract the application backup archive to a temporary directory.
Within the temporary directory, edit any application config files (for example, "app/etc/local.xml" for Magento, or "wp-config.php" for WordPress) to replace the old database information with information of the just-created database. Do not modify the table prefix variable.
Within the temporary directory, edit the "APP-META.INI" file. The values within this file need to be updated to the correct values for the new location: owner, url, url-domain, path, db-host, db-name, db-user, and db-pass. Do not edit the db-prefix value.
Copy the edited file from the last step to "/.appdata/backups/" (within the destination web hosting account) and rename the file to any alphanumeric value. For example, renaming the file to "77b88f4b603641f08d147fde90166a2f" or "7ff111004000" would be acceptable.
Add the edited APP-META.INI and any application config file back into the existing application backup archive, and move the application backup archive to the "application_backups" directory of the destination web hosting account (if it's not already located there).
That's it! It should now be possible to restore the backup through the Installatron GUI.
If problems are experienced with the restored application, use phpMyAdmin to search the database for the old install URL. A few applications keep the install URL in their database and this will need to be updated (for example, Magento has a variable named "web/secure/base_url" in the "core_config_data" table).
If there are any questions open a ticket.
The Installatron Locale Translator tool allows anyone to translate lines, and can also be used to generate locale customizations for your server.
The Installatron Application Packaging SDK allows anyone create and maintain applications.
To help streamline the management of individual Installatron Plugin or Installatron Server instances on a large number of servers, both Installatron Plugin and Installatron Server have a Multi-Server tool available from the Administrative UI.
If this isn't sufficient, it's also possible to simply mirror these files between servers using rsync or a product like Puppet:
/usr/local/installatron/etc/settings.ini /root/.appdata/.settings /home/admin/.appdata/.settings /var/installatron/data/admin/.settings /var/installatron/data/root/.settings
To mirror secondary groups and templates, instead of the .settings files, mirror the whole directory:
/root/.appdata/ /home/admin/.appdata/ /var/installatron/data/admin/ /var/installatron/data/root/
Note that depending on the control panel software used some of these files may not exist. Only mirror files that exist.
Installatron Server enables any web hosting control panel or user interface to incorporate Installatron.
To transfer Installatron Plugin to another server and retain all existing installed applications, backups, and administrative settings:
To reinstate administrative settings: After Installatron Plugin is installed on the new server, copy these files and directories from the old server to the new server. Note that depending on the control panel software used some of these files may not exist.
/usr/local/installatron/etc/settings.ini /root/.appdata/ /home/admin/.appdata/ /var/installatron/data/admin/
Finally, execute these commands to rebuild caches:
/usr/local/installatron/installatron --repair --recache /usr/local/installatron/installatron --send-update-report
To transfer Installatron Server to another server and retain all existing installed applications, backups, and administrative settings:
/usr/local/installatron/etc/settings.ini
/var/installatron/data /usr/local/installatron/etc
/var/installatron/data.db
To transfer an Installatron-created application backup to another server:
/usr/local/installatron/installatron --importbackup --user USERNAME --path /application_backups/
Login to your account page and save a new IP value for your license.
Installatron requires a public IP address for licensing. You can view the IP address that Installatron thinks should be the licensed IP address by installing Installatron, if it's not already installed, or by running this command:
/usr/local/installatron/installatron -f --prepair
In either case, read the output to see the IP address that Installatron thinks should be licensed.
However, you can also see what is likely to be the correct IP address by running one of these commands:
ifconfig (or) curl ifconfig.co
And then try this:
echo "BROARDCAST_IP_IN_IFCONFIG" > /usr/local/installatron/mainip rm -f /usr/local/installatron/etc/license.key /usr/local/installatron/repair -f --quick
Where FIRST_IP_IN_IFCONFIG is the 'broadcast' IP address that you'll find in the first part of ifconfig's output.
Additionally, make sure that this works:
curl -v https://data.installatron.com/manifest.md5
If that fails then you might simply have a problem with your firewall configuration.
Finally, if you are using Installatron Plugin with the DirectAdmin then read this DirectAdmin FAQ entry: https://www.directadmin.com/lan.shtml
Specifically, if you know the server's correct public outbound IP address then you might be able to solve any problems by adding this:
lan_ip={the_outbound_ip}
To this DirectAdmin configuration file:
/usr/local/directadmin/conf/directadmin.conf
Automatic Update will automatically create a backup and update installed applications immediately as new versions become available. In the event the update fails, Installatron will automatically restore the created backup.
Automatic Update can be forcibly enabled for every installed application on a server by executing this command from the SSH root command prompt:
/usr/local/installatron/installatron --edit --id='*' --autoup=2
Alternatively, to limit Automatic Update to minor versions and security releases, use this command instead:
/usr/local/installatron/installatron --edit --id='*' --autoup=1
Log into your account and click the renew link for the license you wish to renew. This will create an invoice, email you the details, and take you to the payment page.
Licenses renewed before expiration have the renewal added to the existing expiration. There is no waste when renewing early.
Installatron is able to install and upgrade applications from both a command line interface and HTTP-API. This can be used to pre-populate new hosting accounts with software. Continue to the Automation Guide for more information and usage examples.
You can turn off auto-management of /etc/nginx/nginx.conf by editing this line:
/usr/local/installatron/etc/settings.ini
And then change or add this line to:
services=minimal
Alternatively, you can keep the default value of services=typical and instead add or edit this value in the same file:
accesspath=
Leave it blank to have no URL prefix.
Finally; after making a change to those values you need to run this to rebuild the Nginx config:
/usr/local/installatron/installatron --repair
Installatron Fast Update enables providers to deploy a local Installatron data mirror, enabling Installatron to be installed and updated through the local network instead of through the traditional Internet. In the event a Fast Update server is offline, out of sync, or missing a file, servers will automatically fallback to updating through the Internet. Fast Update saves bandwidth, increases update speed, and is fully redundant. To deploy an Installatron Fast Update server please follow the below instructions.
Two configuration modes are available for Installatron Fast Update: 'mini' which includes the latest files and other files updated within the past year and 'full' which includes all files. A 'mini' Fast Update server currently requires around 20GB disk space and grows at approximately 200MB per month. A 'full' Fast Update server currently requires around 80GB disk space and also grows at approximately 200MB per month.
To setup Installatron Fast Update: provision a small server or VPS with CentOS 6+ (or similar) and 512MB dedicated memory (or more depending on the number of servers using the data mirror). The recommended disk quota is 60GB for 'mini' mode and 160GB for 'full' mode to allow for growth without continually having to increase the quota. This server can be configured to only accept incoming connections from within your network. Note that in general Fast Update servers are extremely lightweight; if only a couple hundred servers will be using the Fast Update server, it's feasible to use an account on an existing shared hosting server instead of a dedicated server/VPS.
Once the bare server is provisioned, no control panel software must be installed, however using control panel software may save some management time in the long run. To set up a Fast Update server on a CentOS server without control panel software, execute the below command from the server's SSH root command prompt. Skip this section if a control panel will be used instead.
yum install httpd
Finally, add the below cronjob to sync Installatron data every hour. If a control panel or shared hosting account was chosen, the cronjob's reference to the /var/www/html directory should be modified to point to the home directory of the control panel account created for Fast Update.
For 'mini' mode:
38 * * * * rsync -rlptDvzW --port 2222 --delete data1.installatron.com::mini/ /var/www/html
For 'full' mode:
38 * * * * rsync -rlptDvzW --port 2222 --delete data1.installatron.com::full/ /var/www/html
Now that the Fast Update server is activated, to configure existing servers to use the server as their primary data source execute this command from the SSH root command prompt on each server:
echo "mirror=installatron.company.com" >> /usr/local/installatron/etc/settings.ini
To provision new servers, execute this command from the SSH root command prompt (replacing controlpanel with the type of control panel):
FASTUPDATE=installatron.company.com rpm -Uvh http://installatron.company.com/installatron-plugin-controlpanel.latest.noarch.rpm
Want a fully-managed Fast Update server?
We provide full management services for Installatron Fast Update servers under certain circumstances. Please contact us for further information.
Executing the below command from the command prompt will reapply installed application branding. Depending on the number of installed applications this command may take some time to complete.
/usr/local/installatron/installatron --rebrand-installs
The Installatron List Builder tool enables a list of applications to be generated. The resulting files (one for each Installatron ACL) can be incorporated into a website.
To display a dynamic page similar to Installatron.com's The Apps page, a flat file database will need to be created using this code:
And then the below PHP code can be pasted into a website PHP file. Make sure to at minimum modify the LB_PATH constant to point to the correct list builder directory.
To change the affiliate ID from the default value, navigate to Installatron Admin >> Interface >> Locale and enter the below line into the Locale Customizations textbox, replacing "2222" with the desired affiliate ID:
_installer_whmcs_licensekeytext_aid=2222
The Amazon AWS S3 backup protocol allows you to backup your applications to an AWS S3 account, as an alternative to using FTP or SSH protocols to backing up to any other location. When you create an AWS S3 account you should be provided with the necessary details to connect-to and backup-to your S3 account, however the values required are not intuitive so here is a little guide on what they mean:
Users can configure an S3 backup location during the install process by opening the Advanced and scrolling down to "Default Backup Location", or you can add an S3 backup location after the app is installed by editing the app from your My Applications tab, then scroll down to "Default Backup Location" to select "Add a new backup location".
Server administrators can add S3 backup locations from Installatron administration » Backups: Locations.
A new ability (at the time of writing) of the Backup Quotas administration tool (Installatron administration » Backups: Quotas) is the ability to apply a quota to more than just permanent backups.
Permantent backups are backups that were instantiated manually or that have been switched to have no expiration. The quota system was designed to specifically prevent these non-expiring backups from getting out of hand, but you can now apply the quota system to other backup channels.
We generally don't advise applying quotas to the other types of backups -- it's best to leave their own expiration systems to handle them if you can so that the appropriate backups are more likely to be there when the user really needs them -- but if disk space is at a premium then you can use quotas to put a hard limit on backups from all sources (or any combination of sources). The sources, or channels, are: