The administration tab is divided into multiple sections covering a variety of administrative actions, as detailed below.
In this section, a new license file can be uploaded when provided by Heimdall, and the current settings and license use can be observed. In Demo mode, up to 4 LB servers can be used, and up to four VDBs with rules (optimizations) can be enabled for 30 days. The used count is only based on VDBs that have received traffic in the last 30 seconds, so will dynamically account for activity. If the used values surpass the allowed values, then a warning will be displayed on the console, but no restriction in features will be enforced. License handling is strictly advisory, i.e. while the system may complain about a license being invalid, it will not restrict what is done, to insure no outages occur as a result of licensing.
Note: When using an AWS paid-for instance, the proxy use on the instance will not count toward license use. Additionally, added paid-for instances can be reconfigured to be a pure proxy instance and will also not count to license use on another management server.
Log File Management
This section is provided to assist in managing log files, and the options should be self explanatory.
This section allows for management of the software. In the first dropdown, you can select a version of code to update to. Release is the normal release train of code, test versions are generally just before a new release, and development are the often daily updates that have completed regression testing. Customers will often be asked to update to the development build if they have encountered a problem and want to apply the fix for it. To apply a particular version, select the version in the dropdown, then click "Update via Repository". Please note, if you have independent proxies running (vla NLB or as a service), you will need to restart them independently as well. To check the version of code each proxy is running, please refer to the status tab.
Note: Any build pushed as a development build have passed all regression testing that any previous version has passed. What may not yet be complete are regression tests for the new changes, which often are developed in parallel with customer testing of the changes. This can result in frequent development builds, but allows for rapid test/fix/deploy cycles during customer POC processes. Once a POC is completed, we will work with customers to schedule a full release build for use in production that has completed full and updated regression testing.
You can also update the version of Heimdall by providing the url link to the zip file, complete this action using Update via URL button.
In the event that you want to update to a particular version of Heimdall that was provided to you as a zip file, you can use the third section for a manual update. Simply select the heimdall zip file, then update via File.
The next option is the Shutdown/Restart Heimdall button, which will not explicitly trigger a restart, but will rely on any restart mechanisms on the server to trigger the actual execution of the server after it terminates.
In the event you need to download the Heimdall driver (say to use as a jdbc driver) the next option "Download Heimdall Driver" can be used.
Following is the release notes link, for the most current release notes.
Note, for command line manual update, please do the following:
1) copy the file into the install directory as heimdall-new.zip 2) cd to install directory 3) execute the following commands:
* sed -i "s/\s*\"modules\/.*\",*//g" config/heimdall.conf * unzip -j heimdall-new.zip
4) kill and restart the heimdallserver.jar process: ps auxw | grep heimdallserver.jar root 4198 0.0 0.0 6100 624 pts/0 S+ 18:03 0:00 grep --color=auto heimdallserver.jar root 26005 30.8 4.0 9679444 638504 ? Sl 17:58 1:25 java -server -XX:+HeapDumpOnOutOfMemoryError -jar /opt/heimdall/heimdallserver.jar
This section provides a list of any alerts that have been dismissed with the check. Any alerts in this list will not be shown in the top of the GUI until cleared.
This provides the login times, account ID and source IP of the recentally recorded GUI logins.
This section allows a cache driver (specifically Hazelcast) to be uploaded for use by Heimdall instead of the built-in driver. This allows the driver to match what may exist in a customer's environment if our version causes a conflict.
These are properties that can control overall Management server behavior, and will be added to over time. Current properties supported.
- Disable Google Analytics: This will disable the external calling to Google analytics to provide metrics on server usage. All such data is anonymous.
- Max Log Age: Sets the maximum age in days of log files and log records
- Reserved Disk Space: Sets the amount of FREE memory to maintain on the log filesystem
- Verbose Debug Mode: On the server, enable verbose debug mode
- Proxy Host: If a proxy is needed to access the Internet for code update notifications and downloads, the host to use for this
- Proxy Port, Proxy User & Proxy Password: Settings to configure the proxy behavior. The port defaults to 3128, no default for the others.
- Minimum free disk space %: configured how much space needs to be free for any configuration saves to occur. Defaults to 1 for 1%. This helps prevent configuration loss if not enough space is available to successfully save the full configuration.
This section allows configuration management filters to be created, which can then be used optionally by users, or enforced on them in the user's tab. The filters insure they can not access or create configuration objects with names that do not meet the specified regular expression. This applies to VDBs, Data Sources, Rules, and Drivers. Analytics and Logs will also be filtered based on the resources they are relevant to by the filters, to prevent data leakage. The dashboard will also be filtered based on this. The two primary use cases are:
- forced segregation of resources on particular users;
- optional enforcement to allow grouping of resources, simplifying the display for groups of resources. This can also be used to help ensure that newly created objects meet naming guidelines implemented by an organization.
When a user is not forced to use a particular filter, then the filters will be available in the upper right-hand corner of each page to allow them to be changed on the fly:
Allows modules to be added or removed as needed. The fewer the modules, the faster a Heimdall node can startup. In particular cache modules that are unused should be deleted as some can add significant load time.
This section allows user to set up requirements that specific user password must meet to be accepted as a new one. Current rules supported:
- minimum/maximum of characters - minimum/maximum number of characters that password must contain (with minimum/maximum parameter tht defines the limit).
- digits requirement - rule defining that password must contain at least one digit
- special marks requirement - rule defining that password must contain at least one special mark
- uppercase character requirement - rule defining that password must contain at least one uppercase character
- custom regex matching - rule that provides a pattern parameter with the regular expression to which password must match
This section allows editing startup
/etc/heimdall.conf configuration file, which can be used to populate environmental variables or cloud environments. The user can set options described below.
|Option Name||Description||Default value|
||Hostname of management server||heimdallmanager|
||Port of the management server, generally 8087 or 8443||8087|
||If the proxy should use HTTPS to connect to the manager||false|
||Login username for the management server, can be admin||admin|
||Login password for the management server||heimdall|
||Any arbitrary options desired to be set||-server -XX:+ExitOnOutOfMemoryError -XX:+IgnoreUnrecognizedVMOptions -XX:-MaxFDLimit -XX:+UnlockExperimentalVMOptions|
||In AWS, use this as the name of an "AWS Secret" to store the configuration, protecting included passwords from being written to disk. To use, proper permissions must be set on the IAM role. This option provides two major benefits. First is that all passwords are stored in AWS Secrets, in an encrypted format. Second is that redeployment of a management server can be done with a configuration pre-populated, so there is no need to backup and restore configurations to account for failures. Simply terminate the old instance and a new instance with the same user-data will be created with the same configuration as the original.|