Creating advanced stand-alone server profiles
You can create a WSRR stand-alone server profile by using the Profile Management Tool. Choosing the Advanced option in the Profile Management tool creates a profile with a customized configuration.
About this task
By selecting the Advanced option, you can do the following:
- Assign customized values to ports, to the location of the profile, and to the names of the profile, node, server, host, and cell (when applicable).
- Configure the WSRR database.
- Create a web server definition.
- Enable administrative security.
- Create a system service to run the server, if your operating system and the privileges of your user account permit the creation of services.
- Configure the WSRR J2EE roles.
- Configure the WSRR JMS user ID.
- Configure the WSRR RunAs user ID.
Procedure
- Start the Profile Management Tool.
- Click Create.
- In the Environment Selection page, select WebSphere Service Registry and Repository > Service Registry stand-alone server. Click Next.
- In the Profile Creation Options page, select the Advanced profile creation option. Click Next.
- In the Profile Name and Location page, perform
the following steps.
- Specify a unique name and directory path for the profile, or accept
the defaults.
Each profile that you create must have a name. When you have more than one profile, you can tell them apart at their highest level by this name. If you elect not to use the default name, see Naming considerations for profiles, nodes, servers, hosts, and cells for information about issues you must consider when naming the profile, such as restrictions on the length of the directory name.
The directory you specify will contain the files that define the runtime environment, such as commands, configuration files, and log files. The default directory is dependent on platform:- install_root/profiles/profile_name
- install_root\profiles\profile_name
- The profile_name you specify is not unique.
- The directory you specify is not empty.
- Your user ID does not have sufficient permissions for the directory.
- There is not sufficient space to create the profile.
- To create the stand-alone server with configuration settings optimized for development environments, select the Create the server using the development template check box. By default, the production template is used; this applies configuration settings that are appropriate for a production environment where application changes are rare, and optimal runtime performance is important. If you select the development template option, this applies configuration settings that are appropriate for a development environment where frequent application updates are performed, and system resources are at a minimum; do not use this option for production servers.
- You can make the profile you are creating the default profile
(so commands work automatically with it) by selecting the Make
this profile the default check box. This check box is
displayed only if you have an existing profile on your system.
The first profile that you create on a workstation is the default profile.
The default profile is the default target for commands that are issued from the bin directory in the product installation root. When only one profile exists on a workstation, every command operates on that profile. If more than one profile exists, certain commands require that you specify the profile to which the command applies.
- Click Next. (If you click Back and
change the name of the profile, you might have to manually change
the name on this page when it is displayed again.)
The Node and Host Names page is displayed.
- Specify a unique name and directory path for the profile, or accept
the defaults.
- In the Node and Host Names page, specify the node, server,
host, and cell names for the stand-alone server profile, or accept
the defaults and click Next. Try
to keep the node name as short as possible, but ensure that node names
are unique within your deployment environment. See Naming considerations for profiles, nodes, servers, hosts, and cells for information about
reserved terms and other issues you must consider when naming.
The Administrative Security page is displayed.
- Optionally enable administrative security.
You can enable administrative security now, or later from the administrative console. To enable administrative security now, leave the Enable administrative security check box selected, supply a user name and password to log on to the administrative console, and click Next. To disable administrative security, clear the check box. To enable administrative security later from the administrative console, open the console and click Security > Business Integration Security.
If you chose to enable administrative security then application security will also automatically be enabled.
The Security Certificate (Part 1) page is displayed.
- In the Security Certificate (Part 1) page,
create a default personal certificate and a root signing certificate,
or import a personal certificate and a root signing certificate from
keystore files, and click Next.
You can create both certificates, import both certificates, or create one certificate, and import the other certificate.
When you import a personal certificate as the default personal certificate, import the root certificate that signed the personal certificate. Otherwise, the Profile Management Tool adds the signer of the personal certificate to the trust.p12 file. If you import the default personal certificate or the root signing certificate, specify the path and the password, and select the keystore type and the keystore alias for each certificate that you import.
The Security Certificate (Part 2) page is displayed.
- In the Security Certificate (Part 2) page,
verify that the certificate information is correct, and click Next.
If you create the certificates, you can use the default values or modify them to create new certificates. The default personal certificate is valid for one year by default and is signed by the root signing certificate. The root signing certificate is a self-signed certificate that is valid for 15 years by default. The default keystore password for the root signing certificate is WebAS. Change the password. The password cannot contain any double-byte character set (DBCS) characters because certain keystore types, including PKCS12, do not support these characters. The keystore types that are supported depend on the providers in the java.security file.
When you create either or both certificates, or import either or both certificates, the keystore files that are created are:- key.p12: Contains the default personal certificate.
- trust.p12: Contains the signer certificate from the default root certificate.
- root-key.p12: Contains the root signing certificate.
- default-signers.p12: Contains signer certificates that are added to any new keystore file that you create after the server is installed and running. By default, the default root certificate signer and a DataPower® signer certificate are in this keystore file.
- deleted.p12: Holds certificates deleted with the deleteKeyStore task so that they can be recovered if needed.
- ltpa.jceks: Contains server default Lightweight Third-Party Authentication (LTPA) keys that the servers in your environment use to communicate with each other.
An imported certificate is added to the key.p12 file or the root-key.p12 file.
If you import any certificates and the certificates do not contain the information that you want, click Back to import another certificate.
- Verify that the ports specified for the profile
are unique and click Next.
The Profile Management Tool detects ports currently used by other WebSphere® products and displays recommended port values that do not conflict with existing ones. If you have applications other than WebSphere ones that use specified ports, verify that the ports do not conflict.
Ports are recognized as being in use if the following conditions are satisfied:- The ports are assigned to a profile created under an installation performed by the current user.
- The ports are currently in use.
If you suspect a port conflict, you can investigate it after the profile is created. Determine the ports used during profile creation by examining the following file:- profile_root/properties/portdef.props
- profile_root\properties\portdef.props
The next step depends on your platform and whether you are installing as a root (Administrator) or non-root user.
If you are installing Next step On a Linux or Windows platform, and have root or Administrator group privileges The Linux or Windows Service Definition page is displayed. Proceed to step 11. On any other platform or as a non-root user on a Linux or Windows platform The Web Server Definition page is displayed. Proceed to step 12. - Choose
whether to run the process as a Windows service
on a Windows platform or
as a Linux service on a Linux platform and click Next. The Windows Service Definition page is displayed for the Windows platform only if the ID that installs the Windows service has the Administrator group privilege. If the profile is configured as a Windows service, the product starts Windows services for processes started by the startServer or startManager commands. For example, if you configure a server or deployment manager as a Windows service and issue the startServer or startManager commands, the wasservice command starts the defined services.Important: If you choose to log on as a specified user account, you must specify the user ID and the password for the user who is to run the service, and the startup type (default is Manual). The user ID must not have spaces in its name, it must belong to the Administrator group, and it must have the advanced user right "Log on as a service." If the user ID belongs to the Administrator group, the Profile Management Tool grants it the advanced user right if it does not already have it.
During profile deletion, you can remove the Windows service that is added during profile creation.
Profiles created to run as a Windows service fail to start when using IPv6 if the service is configured to run as Local System. Create a user-specific environment variable to enable IPv6. Because this environment variable is a user variable instead of a Local System variable, only a Windows service that runs as that specific user can access this environment variable. By default, when a new profile is created and configured to run as a Windows service, the service is set to run as Local System. When the WSRR Windows service tries to run, the service is unable to access the user environment variable that specifies IPv6, and thus tries to start as IPv4. The server does not start correctly in this case. To resolve the problem, when creating the profile, specify that the WSRR Windows service runs as the same user ID under which the environment variable that specifies IPv6 is defined, instead of as Local System.
The Linux Service Definition page is displayed only if the current operating system is a supported version of Linux and the current user has the appropriate permissions.
WSRR attempts to start Linux services for processes that are started by the startServer or startManager commands. For example, if you configure a server or deployment manager as a Linux service and issue the startServer or startManager commands, the wasservice command starts the defined services.
By default, WSRR is not selected to run as a Linux service.
To create the service, the user who runs the Profile Management Tool must be the root user. If you run the Profile Management Tool with a non-root user ID, the Linux Service Definition page is not displayed, and no service is created.
You must specify a user name under which the service runs.
To delete a Linux service, the user must be the root user or have proper privileges for deleting the service. Otherwise, a removal script is created that the root user can run to delete the service on behalf of the user.
- If you want to include a web server definition
in the profile now, perform the following steps:
- Select the Create a Web server definition check box.
- Specify the web server characteristics on the page, and click Next.
- Specify the web server characteristics on Part 2 of the page and click Next.
If you use a web server to route requests to WSRR, you need to include a web server definition. You can include the definition now, or define the web server to WSRR later. If you define the web server definition during the creation of this profile, you can install the web server and its plug-in after you create the profile. However, you must install both to the paths that you specify on the Web Server Definition pages. If you define the web server to WSRR after you create this profile, you must define the web server in a separate profile.
- In the Database Configuration page, configure
the WSRR, Activity Logging
and Service Integration Bus databases.
Refer to the Configuring the database using the Profile Management Tool topic for details and return to this step when you have completed the fields on the Database Configuration page and the Database Configuration (Part 2) page.
- If you have chosen to enable administrative security in
step 7, then
you will next see the JMS User ID Configuration page. Specify the
user name and password for the user to use to access the WSRR JMS
resources. The default value should be the administrator ID specified
in step 7 Note: If the JMS User ID password is later updated, you must open the WebSphere Administrator console and ensure that the password is also updated in the ServiceRegistry application. If the password for the WebSphere Application Server admin user, as is the default, is changed you must reset both the JMS User ID and RunAs User ID passwords too.
- If you have chosen to enable administrative security in
step 7, then
you will next see the RunAs User ID Configuration page. The RunAs
user ID specifies the user ID under which the enterprise application
is run. This user ID must be a member of the Administrator J2EE role
in WebSphere Application
Server, and must be mapped to the WSRRAdmin access control role in
WSRR. Note: If the RunAs User ID password is later updated, you must open the WebSphere Administrator console and ensure that the password is also updated in the ServiceRegistry application. If the password for the WebSphere Application Server admin user, as is the default, is changed you must reset both the JMS User ID and RunAs User ID passwords too.Note: If you plan to use the scheduler framework, or any WSRR feature that uses the scheduler framework, the specified RunAs user must belong to either the Administrator or the Operator administrative user role in WebSphere Application Server. The following features use the scheduler framework:
- Promotion
- Service Discovery
- Policy Analytics
- Subscription notifier
- UDDI synchronization
- Text search
- Tivoli® CCMDB synchronization
- ALE synchronization
- If you have chosen to enable administrative security in step 7, then you will next see the J2EE roles configuration page. Specify the users and groups to map to the User and Administrator J2EE roles in WSRR. Specific users or groups can be defined for each field. But it is limited to a single entry per field. Other values can be defined later in the WebSphere Administrative Console. The Profile Summary page is displayed.
- In the Profile Summary page, click Create to
create the profile or Back to change the characteristics
of the profile. When the profile creation is complete, the Profile Complete page is displayed with the message The Profile Management tool created the profile successfully.Attention: If errors are detected during profile creation, other messages might be displayed in place of the success message, for example:
- The Profile Management tool created the profile but errors occurred, which indicates that profile creation completed but errors were generated.
- The Profile Management tool cannot create the profile, which indicates that profile creation failed completely.
The Profile Complete page identifies the log file to reference in order to troubleshoot the problem.
- Complete the stand-alone server profile configuration by
performing one of the following tasks, depending on whether you must
manually configure the WSRR database.
- If you completed configuration of the WSRR database using the Profile Management Tool, ensure that Launch the First steps console is selected and click Finish to exit. Also, close the Profiles page, which is open in a separate window. Use the First steps console to start the server.
- If you chose to postpone actual database configuration by producing
scripts to be run manually, perform the following steps:
- Clear the check box beside Launch the First steps console and click Finish to close the Profile Management Tool. Also, close the Profiles page, which is open in a separate window.
- Use your site's standard database definition tools and procedures
to edit and run the scripts the Profile Management Tool generated
to create, or create and configure, the WSRR, Activity
Logging, and Service Integration Bus databases
(or their equivalents if they have different names on your system).
You identified the location for these scripts in step 2 of
the topic Configuring the database using the Profile Management Tool. Also see
the topics that describe manually creating new databases or new tables
in existing databases:
- For the WSRR database: Creating the database and tables after stand-alone profile creation or augmentation.
Results
What to do next
- Start the server
- Check the server operation by selecting Start the server from the First steps console. An output window opens. If you see a message like the following message, your server is operating properly:
ADMU3000I: Server server1 open for e-business; process id is 3348
You can also check server operation by running the Installation Verification Test (IVT) from the First steps console or by running the ivt command. This test verifies that your deployment manager or stand-alone server installation is operating correctly. For a stand-alone server profile, it also runs a System Health check and generates a report.
- Load and activate a WSRR configuration profile
- To use WSRR, you must load and activate a WSRR configuration profile. WSRR provides the governance enablement profile, located in the <WAS_INSTALL_ROOT>/WSRR/config directory. After your server is started, load and activate a profile; see Loading a configuration profile and Activating a configuration profile for details.
- Federating stand-alone server profiles to a deployment manager
Learn how to use the addNode command to federate a stand-alone server profile into a deployment manager cell. After federation, a node agent process is created. Both this node agent and the server process are managed by the deployment manager. If you federate a stand-alone server profile and include all of its applications, the act of federation installs the applications on the deployment manager. A stand-alone server profile can be federated only if there are no other federated profiles.