- Service description
- Using CLI
- Common Commands
- Context Specific Commands
- Login context
- Root context
- Server context
- CLI context
- Listener context
- Listener context (as subcontext of proxy services)
- Listener context (as subcontext of non-proxy services)
- Allow rule context
- SSL control context
- Log context
- Rule context
- SMTP-Incoming context
- SMTP-Outgoing context
- Processing context
- POP3 context
- IMAP context
- WebMail context
- WebAdmin context
- FTP backup context
- DNR context
- Name server context
- Report context
- Filters context (as subcontext of server|domain|folderRcpt|group|list)
- Filters context (as subcontext of account|accountClass)
- ScriptFilter context
- SocketFilter context
- ActiveFilter context
- Domain context
- Domain-Create context
- Domain administration limits context
- Account context
- Account class context
- WebmailData context (as subcontext of account)
- WebmailData context (as subcontext of list)
- Quotas context
- Cluster Context
- Initial Account Settings Context
- Autodiscovery Context
- Certs Context
- Special Contexts
- Troubleshooting CLI
CLI is for Axigen another service, more precisely a TCP service, just like SMTP, IMAP, POP3, etc. The CLI service can be configured in its turn similarly to the other services, either by editing the configuration files or by using the remote configuration tools like CLI and WebAdmin. It has common parameters such as maxErrors, logLevel, etc. and also a list of listeners for configuring incoming connections.
The connection to the service must be authenticated using either the top administrator "admin" username and the password previously set for it, or another delegated administrative user.
CLI is structured in contexts, each of them including a specific set of commands. CLI also uses a common set of commands. Each context provides commands allowing switching to the previous and next context and a
HELP command to view the available commands at that specific location. When connected, the login context is activated and an username and password must be provided; after activation, the root context becomes active. The root context is the only one not having a name in the command prompt.
Commands are not case sensitive, meaning that you can enter
HELP, help, Help, HeLP, it will still mean
HELP. Also, when you need to assign values to parameters of certain commands, these values can be entered in 3 ways:
- double quoted.
This is useful when entering regular expressions and spaces and is very similar to the way the strings are entered in unix bash:
- escaped string: in this form, the string cannot contain not printable characters, and the characters that must be escaped with a backslash are: spaces, quotes and double-quotes.
- quoted string: (e.g.: "something") in this form, the string will preserve the literal value of each character within the quotes. A single quote may not occur between single quotes, even when preceded by a backslash.
- double quoted string: (e.g. "something"): in this form, the string will behave just like in the escaped form, ignoring the backslash before any character. The difference is that all the characters, including non-printables, are accepted and that the spaces and single quotes need not be escaped.
In the escaped and double-quoted form, the backslash character must be escaped in order to have a backslash as a result.
The CLI parent / child contexts follow the structure of the configuration file where some objects are children of other parent objects. In general, a context that uses
COMMIT for saving changes is considered a parent and a context that uses
DONE for saving changes is considered a child. In the same time
COMMIT is usually applying final and persistent changes (stored on the disk) and
DONE is usually applying only transient session-specific changes.
Contexts are, with a few exceptions, associated with configuration objects that appear in the config file.
The notion of key parameter-value pair is related to the primary key concept. It uniquely identifies an object in a list of objects. The key value cannot be changed if the context was created using an
The configuration contexts corresponding config objects (like server, all services, etc.) update only when entering and leaving the respective context and when one of the reset commands is issued. Thus, if anything is changed using another version of CLI or WebAdmin, the change will be present only when leaving and entering the context again or after a reset command is issued.
When leaving the context using
COMMIT and the commit fails, update of the context is NOT performed. This happens because any modifications made before commit would be lost. As a result, invalid settings may appear to exist in config.
If you want to reset the configuration for that context, issue a
CANCEL or a
Any changes made to a TCP service like: CLI, WebMail, WebAdmin, etc. affect only new connections to that service and not the active ones.
The subsections of this chapter contain the following:
- Common commands - commands used in all Axigen contexts;
- Context Specific Commands - a list of all contexts and commands available in CLI you can use for reference to see all the different operations you can perform using CLI;
- Special Contexts - the most important contexts in CLI are explained.
When a filter is created, it is not automatically activated. Each filter can be active or inactive. Inactive filters are not used by the server until activation. The activation of a filter can be performed by adding the filter to the "Active Filter" list. All filters listed there are active and used by the server.