Ce contenu n'est pas disponible dans la langue sélectionnée.
6.3. Editing JBoss ON Server Configuration in rhq-server.properties
JBoss ON server configuration properties are stored either in the
rhq-server.properties configuration file in the serverRoot/jon-server-3.3.0.GA/bin directory or in the JBoss ON database. The configuration file contains most of the basic information about the JBoss ON server, such as the TCP/IP ports it listens on and its hostname or IP address.
The JBoss ON server configuration is loaded from the
rhq-server.properties file when the server starts. The initial configuration is defined by the installer when the JBoss ON program is set up.
Note
Because the configuration properties are loaded from
rhq-server.properties when the JBoss ON server starts up, you have to restart the JBoss ON server after making any changes to that configuration file so the new settings are loaded.
6.3.1. Properties Set at Installation
The defining server properties — such as the server name, port, and the database to use — are set when the server instance is configured.
Changing the database properties is covered in Chapter 8, Managing Databases Associated with JBoss ON.
title
- Database Type
- This sets the type or vendor of the database that is used by the JBoss ON server. This is either PostgreSQL or Oracle.
- Database Connection URL
- This gives the JDBC URL that the JBoss ON server uses when connecting to the database, such as jdbc:postgresql://localhost:5432/rhq or jdbc:oracle:oci:@localhost:1521:orcl.
- Database JDBC Driver Class
- This gives the fully qualified class name of the JDBC driver that the JBoss ON server uses to communicate with the database, such as oracle.jdbc.driver.OracleDriver.
- Database XA DataSource Class
- This gives the fully qualified class name of the JDBC driver that the JBoss ON server uses to communicate with the database, such as org.postgresql.xa.PGXADataSource or oracle.jdbc.xa.client.OracleXADatasource.
- Database User Name
- This gives the name of the user that the JBoss ON server uses when logging into the database. This user must already exist in the database; according to the basic installation instructions, this is a specially-created rhqadmin user (not related to the super user in JBoss ON).
- Database Password
- This gives the password of the database user that is used by the JBoss ON server when logging into the database. This password is stored in a hash in the
rhq-server.propertiesfile. When the password is changed in the database, then the password must be manually hashed and copied into therhq-server.propertiesfile. This is described in Section 8.2, “Changing Database Passwords”. - Server Name
- This sets a unique name for the JBoss ON server. The default is the system's hostname, but it can be any string, as long as it is unique within the JBoss ON server cloud.NoteUnlike other server properties, this is only managed through the JBoss ON UI, not its
rhq-server.propertiesfile. - Server Public Address
- This gives the public IP address to use for the server. This is the address that must be recognized by all agents needing access to this server. By default, this is the value of the localhost's public IP address. The public IP address is used with the HTTP/HTTPS ports to provide a high availability endpoint for agents.NoteUnlike other server properties, this is only managed through the JBoss ON UI, not its
rhq-server.propertiesfile. - HTTP Port
- This sets the port that the JBoss ON GUI listens to for unsecured HTTP requests. This is the port number in the JBoss ON GUI URL, such as the 7080 in http://localhost:7080. This is also the unsecured port used as the endpoint in high availability.
- Secure HTTPS Port
- This sets the port that the JBoss ON GUI listens to for secured HTTPS requests. This is the port number used in the JBoss ON GUI URL, such as the 7443 in https://localhost:7443. This is also the secure port used as the endpoint in high availability.
- Server Bind Address
- This gives the IP address for the JBoss ON GUI console, among other services, to bind to. This is the host in the JBoss ON GUI URL, such as server.example.com in http://server.example.com:7080.
- Email SMTP Hostname
- This sets the hostname of the SMTP server used by the JBoss ON server. Emails are sent primarily for alert notifications.
- Email From Address
- This sets the address to use for the From header of all emails sent by the JBoss ON server.
6.3.2. Configuring Communication Settings
JBoss ON servers are configured to communicate to agents by defining and identifying ways that the server and agent can connect, as well as how other clients (like users accessing the JBoss ON GUI) can connect to the server. These communication endpoints include identifying the server hostname or IP address, ports that the server listens on for different types of messages, and protocols used to access the server. All of the user-configurable server connection parameters are described in the server property lists.
Connections, or transport methods, for the server are implemented through servlets (HTTP and HTTPS) or sockets (HTTPS). The servlet (HTTP) and sslservlet (HTTPS) transports route traffic through the Tomcat server embedded in the JBoss ON server.
Important
If the server is using the transport servlet or sslservlet, the agent communication is over the Tomcat connector. This means
rhq.communications.connector.bind-port is ignored and the Tomcat connector port is used to send messages from agent to server. By default, the Tomcat connector port is 7080 (servlet) or 7443 (sslservlet).
Note
Servlet-based transports leverage the Tomcat connector infrastructure to handle both agent and GUI requests. Using servlets, however, limits agents and GUI clients to use the same connection methods; for certificate-based SSL connections, servlets require users to authenticate to the GUI using a stored browser certificate. For SSL, then, it may be preferable to use socket connections, which allow different authentication methods for agent and GUI sessions.
See Section 4.2, “Setting up Client Authentication Between Servers and Agents” for setting up SSL sockets.
The general configuration settings set the port numbers that users can used to access the server.
# General Properties rhq.server.startup.web.http.port=7080 rhq.server.startup.web.https.port=7443
Additional connection settings can be added to configure SSL connections for inbound connections to the server (messages from the agent to the server) and outbound connections (messages from the server to the agent). For example:
rhq.server.tomcat.security.client-auth-mode=true rhq.server.tomcat.security.secure-socket-protocol=TLSv1,TLSv1.1,TLSv1.2 rhq.server.tomcat.security.algorithm=SunX509 rhq.server.tomcat.security.keystore.alias=RHQ rhq.server.tomcat.security.keystore.file=conf/rhq.keystore rhq.server.tomcat.security.keystore.password=RHQManagement rhq.server.tomcat.security.keystore.type=JKS rhq.server.tomcat.security.truststore.file=conf/rhq.truststore rhq.server.tomcat.security.truststore.password=RHQManagement rhq.server.tomcat.security.truststore.type=JKS
The third part of JBoss ON server communications provides more control over information the connection endpoints for JBoss ON servers and agents to use to talk with each other. These are transport parameters for the server. Both the JBoss ON agent and port use the same remoting framework, using invocation strings that are similar to URLs. These connection strings have the format:
protocol://server:port/transportParm1=value1&transportParam2=value2
Important
For most communications, the JBoss ON server must use either servlet or sslservlet protocols. The only instance where socket can be used is for passing transport parameters. Otherwise, socket and sslsocket are not supported.
The transport configuration first sets up connectors (called endpoints) that the servers and agents jointly define and use for communications. This means that the same information must be in both the server and agent configuration files. Each aspect of the remoting URL is built using separate server configuration parameters.
The standard server configuration has four parts, for the transport method, server IP address, agent port, and any parameters to append to the URL. For example:
rhq.communications.connector.transport=servlet rhq.communications.connector.bind-address=192.168.1.2 rhq.communications.connector.bind-port=16163 rhq.communications.connector.transport-params=/jboss-remoting-servlet-invoker/ServerInvokerServlet
That standard configuration is merged to create this URL:
servlet://192.168.1.2:16163/jboss-remoting-servlet-invoker/ServerInvokerServlet
A corresponding entry, with the same endpoint definition, is also listed in the agent configuration so that it knows how to send communications to the server, such as sending registration and availability reports.
RHQ Server IP Address=192.168.1.2 RHQ Server Port=16163 RHQ Server Transport Protocol=servlet RHQ Server Transport Parameters=/jboss-remoting-servlet-invoker/ServerInvokerServlet
Example 6.1. Basic Server-Agent Transport Example
A server with an IP address of 192.168.0.10 will connect to agents over the standard agent port of 16163. The server configuration has the following configuration to define the server address (
rhq.communications.connector.bind-address), the agent communications port (rhq.communications.connector.bind-port), and the connection protocol (rhq.communications.connector.transport):
rhq.communications.connector.transport=servlet rhq.communications.connector.bind-address=192.168.0.10 rhq.communications.connector.bind-port=16163 rhq.communications.connector.transport-params=enableTcpNoDelay=true&backlog=200
The connection URL, then, is:
servlet://192.169.0.10:16163/enableTcpNoDelay=true&backlog=200
The JBoss ON agent configuration will contain corresponding entries which match the server configuration:
RHQ Server IP Address=192.168.0.10 RHQ Server Port=16163 RHQ Server Transport Protocol=socket RHQ Server Transport Parameters=enableTcpNoDelay=true&backlog=200
Transport parameters can pass relevant information about both incoming and outgoing messages (called server and client messages, respectively, because of how the JBoss ON server handles the messages). These transport parameters are strung together with ampersands (&), as with a standard web URL parameters.
Both server and client transport parameters are passed in the same URL; the JBoss ON server only processes whatever parameters are relevant for the current operation. In Example 6.1, “Basic Server-Agent Transport Example”, for instance, the configuration sets two transport parameters,
enableTcpNoDelay (client) and backlog (server). When the JBoss ON server is receiving messages — when it function as a communications server — it uses the backlog parameter and ignore enableTcpNoDelay because enableTcpNoDelay is only for outgoing (client) messages.
rhq-server.properties General Server Connection Parameters
- jboss.bind.address [1][2]
- Gives the IP address for the JBoss ON GUI console, among other services, to bind to. This is the host in the JBoss ON GUI URL, such as server.example.com in http://server.example.com:7080.
- rhq.server.startup.web.http.port [1][2]
- Gives the port that the JBoss ON GUI listens to for unsecured HTTP requests. This is the port number in the JBoss ON GUI URL, such as the 7080 in http://localhost:7080. This is also the unsecured port used as the endpoint in high availability.
- rhq.server.startup.web.https.port [1][2]
- Gives the port that the JBoss ON GUI listens to for secured HTTPS requests. This is the port number in the JBoss ON GUI URL, such as the 7443 in https://localhost:7443. This is also the secure port used as the endpoint in high availability.
- rhq.server.startup.keystore.filename [2]
- The JBoss ON GUI can accept browser requests over HTTPS. If you want to authenticate the JBoss ON GUI to remote browsers, you need to put an SSL certificate in a keystore file. This setting points to the location of the keystore file. Note that this file name must be a relative file path relative to the
<JBoss ON server Install Dir>/jbossas/standalone/configurationdirectory. The JBoss ON server ships with a self-signed certificate in a default keystore file. - rhq.server.startup.keystore.password [2]
- The password of the keystore file. This is so the JBoss ON GUI can access the keystore file in order to be able to serve the certificate to browser clients.
- rhq.server.startup.keystore.sslprotocol [2]
- The protocol that browser clients should use to communicate with the JBoss ON GUI.
- rhq.server.maintenance-mode-at-start
- Sets whether to start the server in maintenance mode (true) or whether to start the server in whatever mode it was in when it shut down (false). The default is false.
rhq-server.properties SSL Server Connection Parameters
- rhq.communications.connector.security.secure-socket-protocol (agent to server) , rhq.server.client.security.secure-socket-protocol (server to agent)
- The secure protocol that agents must use when communicating with this JBoss ON server.
- rhq.communications.connector.security.keystore.file (agent to server) , rhq.server.client.security.keystore.file (server to agent)
- The keystore file that contains a certificate that authenticates the JBoss ON server to the agents.
- rhq.communications.connector.security.keystore.algorithm (agent to server) , rhq.server.client.security.keystore.algorithm (server to agent)
- rhq.communications.connector.security.keystore.type (agent to server) , rhq.server.client.security.keystore.type (server to agent)
- The file format of the keystore.para
- rhq.communications.connector.security.keystore.password (agent to server) , rhq.server.client.security.keystore.password (server to agent)
- The password that is used to gain access to the keystore file.
- rhq.communications.connector.security.keystore.key-password (agent to server) , rhq.server.client.security.keystore.key-password (server to agent)
- The password that is used to gain access to the key inside the keystore.
- rhq.communications.connector.security.keystore.alias (agent to server) , rhq.server.client.security.keystore.alias (server to agent)
- The alias that identifies the JBoss ON server's key within its keystore.
- rhq.communications.connector.security.truststore.file (agent to server) , rhq.server.client.security.truststore.file (server to agent)
- The truststore file that contains certificates that this JBoss ON server trusts. If you need the JBoss ON server to authenticate JBoss ON agents, you must set this; otherwise it is not needed. This truststore contains certificates for all JBoss ON agents that need to communicate with this JBoss ON server. See the Incoming Client Authentication Mode.
- rhq.communications.connector.security.truststore.algorithm (agent to server) , rhq.server.client.security.truststore.algorithm (server to agent)
- rhq.communications.connector.security.truststore.type (agent to server) , rhq.server.client.security.truststore.type (server to agent)
- The file format of the truststore file.
- rhq.communications.connector.security.truststore.password (agent to server) , rhq.server.client.security.truststore.password (server to agent)
- The password that is used to gain access to the truststore file.
- rhq.communications.connector.security.client-auth-mode (agent to server) , rhq.server.client.security.server-auth-mode-enabled (server to agent)
- Indicates if the JBoss ON server must authenticate the JBoss ON agents that are sending it messages. If the server is using secure connections, but does not have trusted certificates for all of the JBoss ON agents in a truststore, set this to none. The valid values are:
trueorfalse.rhq.communications.connector.security.client-auth-mode:none,wantorneed.rhq.server.client.security.server-auth-mode-enabled:trueorfalse.
rhq-server.properties Transport Connection Server Parameters
- rhq.communications.connector.transport
- Defines how the JBoss ON agents need to transport messages to the JBoss ON server. The allowed values are either servlet or sslservlet. The agent requests go through the JBoss ON server web application layer (i.e. the secure Tomcat Connector). With sslservlet, not only do agent requests route through the web application layer, but they are also secured through the secure Tomcat Connector. The keystore used for incoming agent message authentication is the same as that configured in
rhq.communications.connector.security.keystore.file.NoteThis transport setting does not restrict agents from only going over that particular connection method. By default, the JBoss ON server always deploys the communications connector that allows for both servlet and sslservlet traffic. This setting tells the agent to decide what transport is used when it sends messages to the server. If the server has its transport set to servlet, but the agent is configured to talk to the server via sslservlet, the messages the agent sends will be via sslservlet. - rhq.communications.connector.bind-address
- This is the address that is placed in the server's JBoss/Remoting locator URL. This defines the endpoint that the JBoss ON server will bind its connector to. It also represents the public endpoint address that all agents can use to connect to the server.
- rhq.communications.connector.bind-port
- Defines the endpoint that the JBoss ON server binds to, as well as the public address that all agents can use to connect to the server. This is hidden from view in the installer, although it still appears in the
rhq-server.propertiesfile. This value can be blank; the server sets this to either the HTTP or HTTPS port, depending on the transport configured for the server. - rhq.communications.connector.transport-params
- Defines additional transport parameters the JBoss ON server will set on its connector that will accept incoming messages from the JBoss ON agents. All of the possible transport parameters are listed in Table 6.1, “Transport Parameters”.
- rhq.communications.multicast-detector.enabled
- If true, the JBoss ON server will attempt to auto-detect JBoss ON agents coming online and going offline using multicast detection. Your network must support multicast traffic for this to work.
- rhq.communications.multicast-detector.bind-address
- The address that the multicast detector directly binds to. This is not used, or needed, if you have not enabled multicast detection.
- rhq.communications.multicast-detector.multicast-address
- The address that the multicast detector will broadcast messages to. This is not used, or needed, if you have not enabled multicast detection.
- rhq.communications.multicast-detector.port
- The port that the multicast detector will broadcast messages to. This is not used, or needed, if you have not enabled multicast detection.
| Transport Parameter | Description | For Incoming Messages or for Outgoing Messages |
|---|---|---|
| serverBindAddress | The address on which the server socket binds to listen for requests. The default is an empty value which indicates the server socket should be bound to the host provided by the InvokerLocator URL (the host). | Incoming |
| serverBindPort | The port to listen for requests on. | Incoming |
| timeout | The socket timeout value. The default on the server side is 60000 (one minute). If the timeout parameter is set, its value will also be passed to the client-side (see below). | Incoming |
| backlog | The preferred number of unaccepted incoming connections allowed at a given time. The actual number may be greater than the specified backlog. When the queue is full, further connection requests are rejected. Must be a positive value greater than 0. If the value passed if equal or less than 0, then the default value will be assumed. The default value is 200. | Incoming |
| numAcceptThreads | The number of threads that exist for accepting client connections. The default is 1. | Incoming |
| maxPoolSize | The number of server threads for processing client requests. The default is 300. | Incoming |
| socket.check_connection | Indicates if the invoker should try to check the connection before re-using it by sending a single byte ping from the client to the server and then back from the server. This configuration needs to be set on both the client and server to work. The default value is false. | Incoming |
| clientConnectAddress | The IP address or hostname the client will use to connect to the server-side socket. This would be needed in the case that the client will be going through a router that forwards requests made externally to a different IP address or hostname internally. If no clientConnectAddress or serverBindAddress is specified, the local host's address is used. | Outgoing |
| clientConnectPort | The port the client will use to connect to the server-side socket. This would be needed in the case that the client will be going through a router that forwards requests made externally to a different port internally. | Outgoing |
| timeout | The socket timeout value. The default on the client side is 1800000 (or 30 minutes). | Outgoing |
| enableTcpNoDelay | Indicates if the client socket should have TCP_NODELAY turned on or off. TCP_NODELAY is for a specific purpose; to disable the Nagle buffering algorithm. It should only be set for applications that send frequent small bursts of information without getting an immediate response. The default is false. | Outgoing |
| clientMaxPoolSize | The client-side maximum number of active socket connections. This basically equates to the maximum number of concurrent client calls that can be made from the socket client invoker. The default is 50. | Outgoing |
| numberOfRetries | The number of retries to get a socket from the pool. This basically equates to the number of seconds the client will wait to get a client socket connection from the pool before timing out. If the max retries is reached, a CannotConnectException will be thrown. The default is 30. | Outgoing |
| numberOfCallRetries | The number of retries for making the invocation. This is unrelated to numberOfRetries in that when this comes into play is after it has already received a client socket connection from the pool. However, it is possible that the socket connection timed out while waiting within the pool. Since a connection check is not done by default, the connection is thrown away and an attempt to get a new one will be made. This will happen for however many numberOfCallRetries is (which defaults to 3). However, when (numberOfCallsRetries - 2) is reached, the entire connection pool is flushed under the assumption that all connections in the pool have timed out and are invalid and will start over by creating a new connection. If this still fails, a MarshalException is thrown. | Outgoing |
| socket.check_connection | Indicates if the invoker should try to check the connection before re-using it by sending a single byte ping from the client to the server and then back from the server. This configuration needs to be set on both client and server to work. This if false by default. | Outgoing |
6.3.3. Setting Concurrency Limits
JBoss ON can handle large numbers of agents, potentially hundreds. The JBoss ON server can possibly be flooded with messages if many agents attempt to communicate with the server simultaneously. This can happen if the JBoss ON server is restarted after being down for a period of time; when JBoss ON agents detect that the JBoss ON server has come back, they all immediately attempt to send it a backlog of messages.
The JBoss ON server can have a configurable limit on the number of concurrent messages that can be processed at one time, to mitigate any risk of flooding the server. Any messages that come in past that limit are dropped and the agent is asked to send them later.
All of the concurrency-related parameters are listed in Table 6.2, “rhq-server.properties Parameters for Concurrency Limits”.
Concurrency limits not only limit the number of agent connections, but also the number of connections to the GUI and other web connections to the server. There are three primary parameters that control the concurrency limits:
- A global limit on the total number of incoming messages to the server (
rhq.communications.global-concurrency-limit).This is the total number of allowed agent connections. There are other concurrency limits for specific message types which can help tune performance for content downloads, inventory synchronization, and other resource-intensive or recurring agent operations. Those concurrency limits apply only to those specific message types, and those limits are evaluated independently of each other. The global concurrency limit is the total cap for all agent connections. This is the effective concurrency limit, even if the sum of the other concurrency limits is higher. - A limit on the total number of concurrent web connections allowed (
rhq.server.startup.web.max-connections).This counts any client connection which connects to the JBoss ON server over an HTTP or HTTPS connection. This includes web GUI connections, of course, but it also includes all agent connections which use the (default) servlet or ssslservlet transports.The limit on web connections is the same for both non-secured HTTP requests and HTTPS requests, but the limit is additive so HTTP and HTTPS connections count against different pools. The total maximum connections allowed is actually twice whatever therhq.server.startup.web.max-connectionsvalue is. For example, if the setting is 300, then 300 HTTP requests are allowed and 300 HTTPS requests are allowed, for total of 600 concurrent web connections. - Limits on the number of downloads from agents (
rhq.server.agent-downloads-limit) and from other clients (rhq.server.client-downloads-limit).
Example 6.2. Concurrency Limits
rhq.server.startup.web.max-connections=200 rhq.server.agent-downloads-limit=45 rhq.server.client-downloads-limit=5 rhq.communications.global-concurrency-limit=30
| Parameter | Description |
|---|---|
| rhq.server.startup.web.max-connections |
Sets a limit on the number of web connections that can be concurrently created, including both connections to the GUI and connections by agents.
Note
If agent requests are routed over web connections, make sure that the rhq.communications.global-concurrency-limit value is slightly lower than the web connections limit. Otherwise, GUI users could be blocked from accessing the JBoss ON UI whenever there is a high agent load.
|
| rhq.communications.global-concurrency-limit |
Sets the total number of agent messages that come into the server. This only affected incoming agent messages, not GUI requests. If this global concurrency limit is set to 300, no more than 300 total agent messages can be processed at any one time, regardless of what kinds of messages are coming in.
Even if the sum of the other concurrency limits are higher than this global limit, they are capped at this global limit since there can never be more messages processed than the global limit.
This value should be slightly lower than the number of allowed web connections so that web connections to the GUI are not blocked when there is a high agent load.
|
| rhq.server.concurrency-limit.inventory-report | Inventory reports are sent from the agent when the agent starts up, and periodically thereafter. Inventory reports can be large, depending on the number of resources on the agent machine. |
| rhq.server.concurrency-limit.availability-report | Availability reports are regularly sent from the agent, typically every 60 seconds. Availability reports are usually very small, but occur in large numbers due to the high frequency of their transmission. |
| rhq.server.concurrency-limit.inventory-sync | Inventory synchronizations occur when the agent needs to synchronize its inventory with that of the server. Agents typically synchronize at startup. Traffic that flows as part of inventory synchronizations is usually large, depending upon the number of resources managed by the agent. |
| rhq.server.concurrency-limit.content-report | Content reports are similar to inventory reports except they contain information about discovered content (i.e., installed packages of software). These reports can be large depending on the number of installed software the agent has discovered and is managing. |
| rhq.server.concurrency-limit.content-download | Content downloads occur when a resource on an agent needs to ask for the content of a package version, usually for the purpose of installing the package. |
| rhq.server.concurrency-limit.measurement-report | Measurement reports are periodically sent to the server whenever the agent completes measurement collections. The number and size of measurement reports can vary, depending on the number and frequency of measurements scheduled to be collected. The greater the number of schedule measurements the agent needs to collect, the more frequently measurement reports are sent, and the larger the reports will be. |
| rhq.server.concurrency-limit.measurement-schedule-request | Similar to inventory synchronization, measurement schedule requests are sent to the agent asking the server for an up-to-date set of measurement schedules that have to be collected. |
6.3.4. Configuring the SMTP Server for Email Notifications
Each JBoss ON server talks to a specific SMTP server. The SMTP server is defined in the
rhq-server.properties file. The default configuration points to the local JBoss ON server hosts.
# Email rhq.server.email.smtp-host=localhost rhq.server.email.smtp-port=25 rhq.server.email.from-address=rhqadmin@localhost
These settings can be edited to use a different SMTP server or email account.
Note
To confirm that the SMTP settings are correct and the server can send emails successfully, go to the test email page at
http://server/portal/admin/test/email.jsp.
| Parameter | Description |
|---|---|
| rhq.server.email.smtp-host | Sets the hostname of the SMTP server used by the JBoss ON server. |
| rhq.server.email.smtp-port | Sets the port of the SMTP server used by the JBoss ON server. |
| rhq.server.email.from-address | Sets the address to use for the From header of all emails sent by the JBoss ON server. |
6.3.5. Installing a Server Silently
Some options in the
rhq-server.properties file tell the installation process to load the server configuration from the file rather than the from the web-based installer.
# Auto-Install Pre-Configuration Settings rhq.autoinstall.enabled=true rhq.autoinstall.database=auto rhq.autoinstall.public-endpoint-address=
Important
The autoinstaller options are only evaluated once, when the JBoss ON server is first installed. After that initial configuration, the autoinstaller is disabled. These properties are ignored once the server is set up and cannot be used to initiate a re-install of an existing instance.
To re-install the server, first delete the server installation directory, then unzip the original JBoss ON server archive and install the server as if it were new.
| Parameter | Description |
|---|---|
| rhq.autoinstall.enabled | Tells the installation process whether to load the configuration from the rhq-server.properties file (true) or from the web-based installer (false). |
| rhq.autoinstall.database |
Tells the install process how to load or add database schema. There are three options:
|
| rhq.autoinstall.public-endpoint-address | Sets the IP address or hostname to use for the server. If no value is given, then the server detects and sets its own value when it starts. |
6.3.6. Protecting sensitive information in the Server Configuration
Important
By default all the passwords in the server configuration files are protected during upgrades and installations. This process is only needed when users want to protect additional properties.
JBoss ON supports encoding almost all properties in server configuration files, more specifically, the
{RHQ_SERVER_HOME}/jbossas/standalone/configuration/standalone-full.xml and {RHQ_SERVER_HOME}/bin/rhq-server.properties files. JBoss ON provides the rhq-encode-value.sh and rhq-encode-value.bat scripts in the {RHQ_SERVER_HOME}/bin/ directory to obfuscate properties.
6.3.6.1. standalone-full.xml
For
standalone-full.xml, property values are encoded by a password vault mechanism and all passwords are protected by default at installation. This password vault mechanism is provided as a feature in JBoss Enterprise Application Platform 6. JBoss ON also provides this feature using a modified implementation of the same password vault mechanism for use within JBoss ON. For more information on the password vault mechanism, please see Password Vaults for Sensitive Strings section of the JBoss Enterprise Application Platform 6 Administration and Configuration Guide.
6.3.6.2. rhq-server-properites
For
rhq-server.properties, property values are encoded using the RESTRICTED:: format and all password are protected by default at installation.
6.3.6.3. Using the rhq-encode-value Script for Encoding
Invoking the
rhq-encode-value script will prompt users for the desired property and value to encode:
> ./rhq-encode-value.sh
Property rhq.autoinstall.server.admin.password [y/n]: n
Property rhq.server.database.password [y/n]: n
Property: rhq.protect.property
Value: 1234
*** !!! WARNING !!!
*** Both standalone-full.xml and rhq-server.properties need to be updated if a property from rhq-server.properties is used in standalone-full.xml
*** !!! WARNING !!!
***
***
*** Encoded password for rhq-server.properties:
*** rhq.protect.property=RESTRICTED::-299a94df3b478ca8
***
*** Encoded password for standalone-full.xml with vault with password as default value:
*** ${VAULT::restricted::rhq.protect.property::-299a94df3b478ca8}
***
*** Encoded password for standalone-full.xml with vault without default:
*** ${VAULT::restricted::rhq.protect.property:: }
***
*** Encoded password for agent-configuration.xml:
*** <entry key="rhq.protect.property" value="RESTRICTED::-299a94df3b478ca8" />
***
*** Please consult the documentation for additional help.
After running the script, the values generated from
rhq-encode-value should be copied and pasted into server configuration files.
Important
Some properties present in
standalone-full.xml are also present in rhq-server.properites. When protect a property present in both files, ensure that both locations are updated with the same encoded variant prior to restarting the server. Partial updates may render the server unusable.
