4. Manager¶
manager is a key Flopsar component, which is responsible for managing the entire Flopsar environment.
4.1. Configuration¶
manager is managed by its configuration file <manager_home>/conf/flopsar.conf.
- server.bind.port
- Port of the TCP server.
- server.bind.ip
- IP address of the TCP server. This option is not mandatory. When the option is either empty or missing, the IP address is read from the license file. If the option value is set to *, the TCP server will bind to all existing IP addresses.
- plugins
- List of enabled plugins. This option contains a comma separated list of full names of the plugins. By default no plugin is enabled. Flopsar manager currently ships with one plugin: LDAP authentication. You can easily replace this plugin with a custom one (see Plugins for details).
4.2. Logging¶
manager has a single log file flopsar.mgr.log. It is stored in manager_home/logs directory. The logging levels are defined in Logging.
You can set the logger level either during the startup procedure or in runtime. For example, to set the fine level during manager startup use the following options:
$ fs2mgr start --loglevel fine <manager_home>
In order to change it in runtime, execute the following command:
$ fs2mgr set --loglevel fine <manager_home>
4.2.1. Logger messages¶
Each logger message entry has the following structure:
DATE [LEVEL][PID] Message content
or
DATE [LEVEL][PID][PLG] Message content
The only difference between these two types is an additional PLG entry. This entry denotes that this particular message comes from a plugin. The rest of the entries denote:
| DATE: | current date. |
|---|---|
| LEVEL: | current logger level. |
| PID: | system process ID number of the logging process. |
| Message content: | |
| is self-explanatory. | |
4.3. Authentication and Authorization¶
manager accepts connections from three types of clients: fdbc, agent and database ones. The explicit authentication is required only for workstation clients. Flopsar supports two types of authentication mechanisms: internal and LDAP.
Regardless of the authentication mechanism, a user must exist in the Flopsar Manager.
4.3.1. Internal Authentication¶
Internal authentication is enabled by default. Users management is done by means of fs2auth executable. The following operations are supported:
Listing users
To list all the stored users execute the following command:
$ fs2auth list --mode users <manager_home>
Adding users
To add a new username user execute the following command:
$ fs2auth add --user username <manager_home>
Setting user password
To set a username user password execute the following command:
$ fs2auth set --user username --password <manager_home>
Deleting users
To delete username user execute the following command:
$ fs2auth delete --user username <manager_home>
Note
Please, refer to fs2auth man page for more.
4.3.2. LDAP Authentication¶
In order to enable the LDAP authentication mechanism you must add the libflopsar-ldap plugin library to the configuration option in the flopsar.conf file, i.e. plugins=libflopsar-ldap. This operation requires manager to be restarted.
Next, copy the /usr/share/flopsar/templates/plugins/flopsar-ldap directory into <manager_home>/conf/ and edit the <manager_home>/conf/ldap.conf file. The file has the following options to set:
- ldap.url
- LDAP service URL.
- ldap.base.dn
- Base DN to be appended to all LDAP requests.
- ldap.bind.dn
- LDAP user binding DN.
- ldap.bind.password
- LDAP user password.
- ldap.auth-type
- LDAP authentication mechanism. Currently, only simple mechanism is supported.
- ldap.user.attr.username
- Username LDAP attribute. Values of the attribute must match the ones given by users during logging to manager.
- ldap.user.search
- LDAP search query to find users in the LDAP service. You can user $ char in the query, which will be replaced with a username.
Flopsar must know which users stored in your LDAP server are allowed to login to manager. That means you must have (or create) a container (group) in your LDAP server. If some user is allowed to login to the database, they must be a member of this container (so-called login group). There are four options you must set in the Flopsar configuration file to set it up.
- ldap.group.name
- The login group name.
- ldap.group.attr.member
- This value must correspond to a username. This username must match the one used by a user to login.
- ldap.group.search.member
- LDAP filter to find a member of the login group.
- ldap.group.search
- LDAP search query to find groups. You can user $ char in the query, which will be replaced with a username.
Below, an example is presented:
ldap.url=ldap.mydomain.com:389 ldap.base.dn=dc=mydomain,dc=com ldap.bind.dn=cn=ruser,dc=mydomain,dc=com ldap.bind.password=secret ldap.auth-type=simple ldap.user.attr.username=uid ldap.user.search=(&(objectClass=person)(uid=$)) ldap.group.attr.name=cn ldap.group.attr.member=memberUid ldap.group.search.member=(&(objectClass=posixGroup)(cn=flopsar)(memberUid=$)) ldap.group.search=(&(objectClass=posixGroup)(cn=$))
Note
There is currently only one LDAP authentication strategy supported by Flopsar, i.e. direct (bind) authentication to the LDAP server. This implies every user must be able to bind to the LDAP server.
4.3.3. Authorization¶
Flopsar authorization mechanism is based on permissions. The authorization process is performed by Flopsar itself.
In order to list all the available permissions, execute the following command:
$ fs2auth list --mode permissions Available permissions: [P2 ] Can configure agents. [P8 ] Can view parameters.
If you want to see which permissions users have, list all the users:
$ fs2auth list --mode users <manager_home> Users list: ----------------------------------- #1 user: User2 Can configure agents ----------------------------------- #2 user: admin Can configure agents Can view parameters ----------------------------------- #3 user: User1 -----------------------------------
If, for example, you want to allow user1 edit agents configurations, just execute the following command:
$ fs2auth add --user user1 --perm P2 <manager_home>
In order to revoke that permission, execute the following command:
$ fs2auth add --user user1 --perm ~P2 <manager_home>
Note
Please, refer to fs2auth man page for more.
4.4. Managing Agents¶
Each agent must be connected to some database in order to send its data. The procedure of attaching agents to databases is performed by manager.
Note
The agent must be connected to the manager before you can attach it to any database.
There is only one special case, when an agent can be attached to the database automatically. This can happen when the following two conditions are fulfilled:
- Agent makes its first connection to the manager, i.e. the manager have not registered the agent yet.
- At least one database connection to the manager exists.
Then, the agent is attached to one of the connected databases automatically. If there are more than one database connection, manager selects a database randomly. In all other cases, agents must be attached to the database manually.
Suppose you have a running myAgent1 agent and want to attach it to a database, which server listens on 172.16.0.12:8000. In order to do it you must execute the following command:
$ fs2mgr set --agent-type java --agent-name myAgent1 --database 172.16.0.12:8000 <manager_home>
This operation will store this change in manager and makes the agent drop its current database connection and connect to a new database.
You can always inspect your agent configurations by executing the following command:
$ fs2mgr get --target agents <manager_home>
As a result you should see something similar:
TYPE ID AGENT DATABASE CONFIGURATION
-------------------------------------------------------------------------------------------------------
JVM | 49132292717FA021 | kona1........................... | 172.16.0.12:8000 | c1
JVM | 9349FF5C62BEEB7C | kona2........................... | 172.16.0.13:8000 | c1
-------------------------------------------------------------------------------------------------------
TOTAL 2
where:
- TYPE
- Type of agent.
- ID
- Agent unique identifier. Identifier is evaluated from agent name and type.
- AGENT
- Agent name.
- DATABASE
- Database address the agent connects to.
- CONFIGURATION
- Configuration the agent is attached to.
4.4.1. Deleting Agent Data¶
If you want to delete an agent of <agent-type> type from the manager, just execute the following command:
$ fs2mgr delete --agent-name myAgent --agent-type <agent-type> <manager_home>
Important
Before you delete an agent, make sure it is not connected to the manager.
4.5. Managing Clients Connections¶
You can always check what clients are currently connected to the manager. You can simply do it by executing:
$ fs2mgr get --target server-stats <manager_home>
This operation will print a list of the connected clients to your console. The result will be similar to the one below:
Fig. 4.1 Manager Server Statistics
where:
- CTYPE
- Client type. There are four types: agent, fdbc, database and unknown. The last one is set when a client is connected but not yet authenticated.
- CID
- Client identifier. This value is useful when you search for this client activity in the manager log files.
- SRC
- Client source socket address.
- CONNID
- Client connection identifier. This value is needed when you want to specify a client connection to drop.
- CONNECTION TIME
- Time at which a client connected to the manager.
- TOTAL RCV
- Total size of data received from a client.
- TOTAL SNT
- Total size of data sent to a client.
If you want to disconnect a client, you need to execute the following command:
$ fs2mgr delete --client CONNID <manager_home>
where CONNID is a connection identifier.
Warning
You will not be asked to confirm whether you really want to drop a client connection. This operation will be executed immediately.