manager - Configure a manager system
[1] manager ssh [(fingerprint | generate | show | (load | save) (private public) (ftp | sftp | tftp) <file-server> <file-name>)]
[2] manager template [raz | (add <template-id> [(template | gateway) <source-id>] | (del <template-id>)]
[3] manager template [begin conf <template-id>]
[4] manager template [begin exec [<template-id>]]
[5] manager gateway [raz | (add <domain-id> <gateway-id> <gateway-ip>) | (del <gateway-id>)]
[6] manager gateway [begin conf <gateway-id>]
[7] manager gateway [(push | pull) [<domain-id> [<gateway-id>]]]
[8] manager gateway [begin exec (remote | local) [<domain-id> [<gateway-id>]]]
[9] manager template report exec
[10] manager gateway report (push | pull | exec (remote | local))
[11] manager sync [(role [alone | master | slave]) | (peer [<peer-ip> ["<peer-manager-public-ssh-key>"]]) | report]
This command is only available on a system installed as a Manager system (as opposed to a system installed as a Gateway system). A Manager system allows you to configure remote Gateway systems without having to directly connect to them.
A manager uses the SSH protocol to connect to remote gateways. In order to be automatically authenticated by remote gateways, a manger uses SSH private/public key pairs. In this operation mode, the manager’s SSH public key should be exported to remote gateways using the access command on remote gateways. The first [1] usage form allows you to:
• Show the fingerprint of the active public RSA key used to connect to Gateway systems.
• Regenerate that RSA key.
• Show the active RSA key.
• Load or save the managers’ SSH public and private SSH keys.
If you are managing a group of gateways that have almost the same configuration, you will notice that you have to execute the same command as many times as you have gateways in that group. To avoid that, you can use templates. A template is a set of commands forming a generic configuration that you can apply to a group of gateways. This ways, you can quickly configure a group of gateways that differ little by just executing commands that make differences.
Configuring a group of managed gateways with the aid of a template is done in four steps:
• First you create a template identified by a <template-id> and you configure it as if it was a gateway.
• Secondly you enrol (add) remote gateways on the manager and pull their current configuration from remote gateways.
• Then you can configure gateways by applying the template to them. At this step you can optionally make specific configuration for each gateway.
• And finally you can push gateway configurations made on the manager to remote gateways.
Please note that unlike most commands that require an apply to take effect (by using the apply command), the following operations on a manager have an immediate effect:
• Adding and deleting templates and managed gateways.
• Pushing and Pulling gateway configurations.
The second [2] usage form allows you to add a new template, delete (del) and existing template or erase (raz) the list of all existing templates. When adding a new template, you can set its configuration from a source template or gateway. To do so, you should use the keyword template or gateway followed by the source template or gateway identifier (<source-id>). If no source template or gateway is specified, a blank template based on the default factory configuration is created. Without any arguments, this usage form shows the list of all existing templates.
The third [3] usage form allows you to configure a template. To configure a template, you must specify the beginning of the template configuration by using the keywords template begin conf followed by the <template-id> to configure. Then you can use commands that you normally use to configure Gateway systems. When you finished configuring the template, you must use the end keyword to mark the end of the template configuration (and go back to the manager configuration level). Before ending a template configuration, please do not forget to validate it by using the apply command. Otherwise you will not be able to use it to configure a Gateway system.
The fourth [4] usage allows you to execute a set of commands on all templates or an identified template. You can use this usage form to modify settings related to entered commands on all templates without impacting other settings on templates.
Usage forms five to eight allow you to manage Gateway systems. The fifth [5] usage form allows you to enrol new remote gateways and add them to the list of managed gateways. During the gateway enrolment process, the manager should connect to the remote gateway (using the SSH protocol) in order to get some key information that uniquely identifies that remote gateway. To allow this process working, the remote gateway should accept connections from the manager. Please refer to the access command on remote Gateway systems to get information on how to accept connections from a Manager system. To add a gateway to the list of managed gateways, use the keywords gateway add followed by a domain group identifier (<domain-id>), a gateway identifier (<gateway-id>) and the remote gateway IP address. The gateway identifier uniquely identifies a gateway and it must begin with an alpha character and may contains alpha numeric characters as well as the characters "_" and "-". The domain group identifier allows you to place the enrolled gateway in a group identified by an identifier (<domain-id>). You can then apply operations like push or pull (see below) on a group of gateways that belong to a particular group (a group identifier syntax is the same as a gateway identifier syntax). To remove (and definitely forget) a gateway from the list of managed gateways use the keywords gateway del followed by the <gateway-id> to remove. To erase the list of all managed gateways use the keywords gateway raz.
The sixth [6] usage form allows you to make a configuration for an enrolled gateway. To configure a gateway, you must specify the beginning of the gateway configuration by using the keywords gateway begin conf followed by the identifier of the gateway (<gateway-id>) to configure. Then you can use almost all configuration commands to configure the gateway. In addition, you have the possibility to use the conf template <template-id> command to initialise the gateway configuration with settings in the specified template. When you finished configuring the gateway, you must use the end keyword to mark the end of the gateway configuration to go back to the manager configuration level. Before ending a gateway configuration, please do not forget to validate it by using the apply command. Otherwise you will not be able to push that configuration on the remote Gateway system.
The seventh [7] usage form allows you to pull configurations from or push configurations to remote gateways. It should be noted that to push or pull configurations to remote gateways, remote gateways should run the same OS version as the manager. To push a gateway configuration to a remote gateway, use the gateway push keywords followed by the domain and gateway identifiers (<domain-id> <gateway-id>) of that gateway. If no <domain-id> and <gateway-id> are specified, configuration of all gateways are pushed to remote gateways. If only a <domain-id> is specified, configuration of all gateways that belong to that <domain-id> are pushed to remote gateways. During a gateway push operation, the manager performs the following tasks in sequence and in the event of an error, the operation on the gateway in question is stopped.
• The local gateway configuration and all related files to that configuration are pushed to the remote gateway using SFTP.
• The apply force command is executed on the remote gateway (an apply check is automatically executed first).
When pushing a gateway configuration, you also push all files related to the configuration except the following files:
• Private parts of TLS client objects (key, password...).
• All antivirus signatures files.
To pull the running configuration from a remote gateway use the keywords gateway pull followed by the domain and gateway identifiers (<domain-id> <gateway-id>) of that gateway. If no <domain-id> and <gateway-id> are specified, the configuration of all gateways are pulled. If only a <domain-id> is specified, the configuration of all gateways that belong to that <domain-id> are pulled. When pulling a gateway configuration, you also pull all files related to the configuration except the following files:
• URL list files (including domains, urls and expressions)
• All antivirus signatures files.
• The antivirus white list file.
The eighth [8] usage form allows you to execute a set of commands on managed gateways. You have the possibility to directly execute commands on remote gateways (without affecting gateway configurations stored on the Manager system) or execute commands on local gateway configurations stored on the Manager system. To mark the beginning of a remote execution session use the keywords gateway begin exec remote followed by the domain and gateway identifiers (<domain-id> <gateway-id>) of the target gateway. If no <domain-id> and <gateway-id> are specified, commands are executed on all enrolled gateways. If only a <domain-id> is specified, commands are executed on all gateways that belong to that <domain-id>.
Once the beginning of an execution session is marked, you can enter commands (one command per line) to execute on gateways. Entered commands are not executed until you mark the end of the execution session using the end keyword. If for any reasons you decide to do not execute specified commands, you can use the end cancel command (or alternatively press the CTRL+C keys). Please note that:
• A set of commands is executed in background and in parallel on specified remote gateways.
• Commands in a set are executed sequentially on a gateway and in case of an error on a command, following commands are ignored.
• As commands are executed in background, there is no possibility to read from the standard input. Hence, commands that require to read from the standard input return an error.
• Standard and error outputs are redirected to the execution report file (see the ninth usage form).
To execute commands on local gateway configurations stored on the Manager system, replace the remote keyword by the keyword local.
The ninth [9] and tenth [10] usage forms allow you to display a report on the last push, pull or exec operations.
Finally, the eleventh [11] usage form allows you to activate and configure the synchronisation mode between two peer managers. In this mode a peer manager should take the master role while the other should be configured as its slave. If you configure manager as a master manager, the other manager should be configured as a slave manager and vice-versa. When the synchronisation is activated, all modifications on a the master manager are automatically replicated to the slave manager. This way, is case of a failure on the master manager, the slave manager can be used as a backup manager. In order to preserve consistency between a master manager and a slave manger, operations like pulling a configuration from a remote gateways or modifying a template configuration are not allowed on a slave manager. To allow a slave manger to perform those operation its role should be modified to master or alone. However you can use a salve manager to execute commands on remote gateways.
Please note that both master and salves managers should be allowed on managed gateways. Master and slave managers on gateways are respectively referenced as master and backup. Automatic data replications between peer managers use the SSH protocol. That’s why the peer that acts as a slave manager should know the SSH public key of its master. In practice, each peer should know the SSH public key of the other to allow them to quickly swap their roles. It should also be noted that the peering relation between a master and a slave managers can only be established if both run the same OS version.
To activate the synchronisation mode on a peer manager, use the keywords sync role followed by the master or slave keywords. To disable the synchronisation mode use the keywords sync role alone. To allow peers to be synchronised, each peer should know the IP address and the SSH public key of the other. To set them on a peer, use the sync peer keywords followed by the IP address of the remote peer and its SSH public key.
On a master manager you can display a report on the latest synchronisation operation. To do so use the sync report keywords.
Loaded full or update URL list files present on the manager at the time of the push operation are pushed to remote gateways. If URL lists are configured to be automatically updated on the manager, the manager command will always push the latest URL lists alongside other configurations to remote gateways. URL lists files can be full lists as well as updates depending on chosen configuration. Please refer to theurllist command for further information.
Extended antivirus signatures can be loaded on a Manager system and automatically pushed to managed Gateway systems whenever they are updated on the manager. Please note that the automatic push of extended antivirus signatures can only be activated on a commercial installation of a manager system. Please refer to the antivirus command for further information.
access (1) antivirus (1) apply (1) conf (1) end (1) error (1) file (1) information (1) urllist (1) warning (1)
CacheGuard Technologies Ltd <www.cacheguard.com>
Send bug reports or comments to the above author.
Copyright (C) 2009-2024 CacheGuard - All rights reserved