Persistent data storage
The SafeLinx Server needs access to an ODBC-compliant relational database to store configuration information, session data, and accounting and billing information.
- Configuration information about the network resources that SafeLinx interacts with, for example resource identifiers and status.
- Transient active session data that records interactions between the SafeLinx Server and its clients during the establishment, maintenance, and release of connections. Session data is stored in the configured session database and is not preserved across SafeLinx restarts.
- Activity history, including information about the flow of individual IP packets or SMS messages, addressing, and session duration in its accounting and billing database wgacct. Accounting and billing data is used by third-party applications and by SafeLinx. SafeLinx does not need Accounting and Billing data to run.
- User account properties and data. In most environments, an existing LDAP directory service acts as the primary repository for user base and configuration information. However, SafeLinx can use a table in the configuration database to store this information. When an LDAP directory is used, SafeLinx maintains a shadow directory in its user account database to store login records and server assignments for its users. For more information about user information that is stored by SafeLinx, see User accounts.
To store persistent data storage in a production environment, you must configure a connection between the SafeLinx Server and ODBC-compliant relational database.
The SafeLinx Server uses two databases to store information. The wgdata database stores configuration information and session data. Configuration information includes the properties that you specify in the SafeLinx Administrator for resources on your network, such as authentication profiles, directory service servers, HTTP access services, and so forth. Session data includes real-time information for each active user about operations that are related to establishing, maintaining, and releasing connections to the SafeLinx Server.
The wgacct database stores accounting and billing information, including information about the flow of individual IP packets or SMS messages, addressing, and session duration.
A single relational database installation can support multiple SafeLinx Servers. If multiple SafeLinx Servers are configured to use a single relational database, you must assign unique names to the individual databases that each SafeLinx Server uses.
The type of database that you can use depends on the operating system on which the SafeLinx Server is installed. On Linux™, you can use IBM® DB2® or Oracle Database. For Windows™ Server deployments, you can use DB2® or Microsoft™ SQL Server.
You can install the relational database on the SafeLinx Server or on a remote server. To use a remote database, you must install a database client or driver on the SafeLinx Server so that it can communicate with the database. When you install the SafeLinx Server on Windows™ Server, the SQL drivers are installed automatically.
SafeLinx does not support the use of the Oracle Database Client. To store SafeLinx Server data in Oracle Database, you must install a licensed copy of Data Direct Connect driver on the SafeLinx Server
You are prompted to specify the method for storing persistent data during installation or during the initial configuration. When you install the SafeLinx Server on Windows™, you specify the wgdata database during the installation. On Linux™, you specify the database when you first configure the access manager.
To specify the wgacct and wgdata databases, you must provide the following information:
- Database name
- User ID and password of the database administrator
- Location of the local database, or the IP address and port number of the remote database server
When you name the databases, you can use the default names, or assign names of your own choosing. The database administrator's password is encrypted by access manager before it is stored with the SafeLinx Server configuration.
After you implement a storage method, it is possible to switch to a different method, but there is no tool or automated process to migrate data. To move data to a different repository, and retain existing configuration data, you must back up the data and then restore it to the new repository. For more information about backing up and restoring the SafeLinx configuration, see Backing Up SafeLinx Configuration and Changing the Data Storage Method on the HCL SafeLinx support site.