Installation and Configuration - Base
- Richard Wang
- Regaah R
- Emily Debowski
Installing and maintaining Iguana is a simple process, especially if you:
Reviewed the System Requirements to prepare an environment to support your Iguana implementation.
Understand Iguana’s Key Components and deployment best practices to optimize Iguana’s performance and future maintenance.
Follow our Installation Procedures according to the operating system.
System Requirements
With no third-party dependencies and a light footprint, Iguana can be deployed in various environments on modest hardware. Deploy Iguana in the cloud (e.g. Amazon Web Services or Microsoft Azure) or on-premise on a physical or virtual machine.
The following system requirements are dependent on various factors, such as the number of interfaces, the type of data processing, and the expected translation volume. For help in determining your specific requirements, you can refer to:
Tips for calculating load and sizing your Iguana Server
Reference to Iguana Performance Benchmarks
Component | Requirement |
Computer/Processor | 4 core Intel Xeon or equivalent processor |
Memory | 4GB or more recommended |
Hard Disk | Dependent on expected message volume and configured log retention period. |
Operating System | Windows Windows 10, Windows 8, Windows Server 2019, Windows Server 2016 Linux Any Ubuntu versions still supported by Canonical, or RedHat/CentOS 7+ MacOS Mac OS X (Mavericks or newer) Note: 64-bit Linux, macOS, and Windows are supported. 32-bit Ubuntu and Windows are also supported. |
Web Browser | Firefox, Safari, Google Chrome. For best performance we recommend using a modern, standards compliant web browser like Google Chrome or Firefox. |
Iguana’s Key Components
View this article: Iguana Key Components
Installation Procedures
Now that you understand Iguana’s key components and deployment best practices, depending on your objective, you can choose to follow the Windows or Linux/MacOS Install procedures using either one of Iguana’s installation methods: Quick or Manual installation.
Method | Recommended Use | Considerations |
Quick Install | For a trial evaluation or development environment. |
|
Manual Install | For staging and production environments or when you need multiple Iguana instances on one server. |
|
Windows Install
Video Tutorial:
Linux or MacOS Install
Video Tutorial:
Note: For instructions on how to configure the Iguana logs, please refer to Log Configuration and Performance below.
Configuring Iguana
Log Configuration and Performance
Log Configuration Tips:
Log Directory: Configure a separate folder for logs on a designated partition or drive. Ensure this drive has good read/write speeds for low latency.
Maximum Log Age: Logs older than this will be deleted by the daily log purge. The default value is 60 days, however, your ideal purge time may depend on your log sizes and requirements around how long you need to keep messages for troubleshooting.
Log Purge Time: Logs are purged daily at this time, if they are older than the Maximum Log Age. We recommend that logs are purged when the server load is the lowest.
The log directory can be configured during the installation procedure or changed afterwards, using the following procedure:
1. Stop the Iguana service.
2. Use a text editor to open and update the log directory in the Iguana configuration file (located in <configuration-directory>/IguanaConfigurationRepo/IguanaConfiguration.xml)
3. Change the log_directory entry to the location of the directory in which you want Iguana to write its log files. Note: The Iguana service user must have read and write permission for this directory, or Iguana will not run.
4. Save and close IguanaConfiguration.xml.
5. Make a backup copy of the log directory.
6. Move or copy the files from the old log directory to the new log directory.
7. Restart the Iguana service and log back into Iguana.
Log Maintenance and Performance
Backup logs regularly. Back up only the dated log files. Files in the index and meta folders should not be backed up. They get recreated every time Iguana re-starts.
Monitor storage space. One of the most common causes of downtime is when Iguana cannot write to the storage medium because it is out of space.
Avoid locking up log index files. Backup and antivirus processes can block Iguana’s access to the logs/index folder, causing Iguana to shut down. Exclude this folder from these processes.
Ease of future upgrades and maintenance. Separate log directory enables you to avoid having to move the logs during an upgrade.
Enhance log security. Add additional layers of security on your log directly by implementing OS level security restrictions.
Users and Roles
Iguana uses a Role Based permission system which allows enterprises to control user access to different features and actions. In Iguana Settings > Users, Administrators can create and manage Users and Roles, defining what channels and activities a user has access to.
If you are using more than one Iguana instance, and they are the same Iguana version, you can sync users and roles to remote Iguana instances for easier maintenance.
Email & SMS Notifications
Iguana’s alerting system supports two types of notifications to send to user’s email or SMS addresses. You can configure rules for these notifications in Iguana Settings > Monitoring.
Channel inactivity rules. These types of alerts will let you know if Iguana has failed to receive messages during a period of time that you can define.
Standard rules. These alert rules are defined by a matching condition (any keyword, phrase, or regex pattern) in the Logs using Iguana’s standard log messages or custom log messages from your interfaces.
External Repositories
Iguana uses an internal source control repository built upon Git to store all versions of your interfaces in your working directory. In order to import and export channels, external repositories (local or cloud repositories such as Github or Bitbucket) can be configured in Iguana. External repositories can be leveraged to:
Deploy channels between development, staging, and production environments.
Store templates, unused, or test interfaces.
Support disaster recovery schemes.