Use the following table to diagnose problems with the SDR component of
PSSP. Locate the symptom and perform the action described in the
Table 15. System Data Repository (SDR) symptoms
|Nonzero return code
|See Action 1 - Get the return code.
|Cannot connect to server
|See Action 2 - Analyze system or network changes.
|SDR class corrupted or missing
|See Action 3 - Analyze class situation.
|Cannot write to the SDR
|See Action 4 - Check authorization.
|Error code 005 - Write authority required.
|See Action 4 - Check authorization.
|Error code 006 - Administrator authority required.
|See Action 4 - Check authorization.
If you cannot run SDR commands, or a program that uses the SDR is failing when running SDR commands, get the return code or the message number from the failing SDR routine. The return codes from SDR routines are imbedded in the message numbers. The first four numbers in the SDR cataloged message are always 0025, followed by a hyphen and a three-digit number. The three digit number is the return code. For example, the following SDR message is issued with a return code of 080 from any SDR routine that cannot connect to the SDR server:
0025-080 The SDR routine could not connect to server.
Some programs report the return code from an SDR routine, but not the message. Use 0025 and the return code to find the appropriate message in PSSP: Messages Reference. Follow the action for the particular error message to correct the error.
Once you have correct the problem, rerun the command that produced the error to verify that it is corrected.
System or network changes could affect the SDR. If an SDR command fails to connect to the server, do the following:
default:default_syspar_ip_address primary:syspar_ip_address nameofdefault:default_hostname nameofprimary:syspar_hostnameprimary
If this file is missing or does not have these four records, the node may not be properly installed, or the file may have been altered or corrupted. You can edit this file to correct it, or copy the file from a working node in the same system partition.
The spget_syspar command may also fail if:
ping -c 1 IP_address
If the ping is successful, the output is similar to:
PING 184.108.40.206: (220.127.116.11): 56 data bytes 64 bytes from 18.104.22.168: icmp_seq=0 ttl=255 time=0 ms ----22.214.171.124 PING Statistics---- 1 packets transmitted, 1 packets received, 0% packet loss round-trip min/avg/max = 0/0/0 ms
If the ping fails, output is similar to:
PING 126.96.36.199: (188.8.131.52): 56 data bytes ----184.108.40.206 PING Statistics---- 1 packets transmitted, 0 packets received, 100% packet loss
In this case, contact your system administrator to investigate a network problem.
ps -ae | grep sdrd
If the process (sdrd) is not running, do the following:
/usr/bin/startsrc -g sdr
to start the SDR daemon. Start checks again at Step 5. If the SDR daemon is now running and continues to run, check the sdrd entry in the file /etc/inittab on the control workstation. It should read:
sdrd:2:once:/usr/bin/startsrc -g sdr
Issue an SDR command again to see if it now connects to the server.
If an SDR command ends with RC=102 (internal data format inconsistency) or 026 (class does not exist), first make sure that the class name is spelled correctly and that the case is correct. See the table of classes and attributes in "The System Data Repository" appendix in PSSP: Administration Guide. Then, follow the steps in "SDR Shadow Files" in the System Data Repository appendix in the PSSP: Administration Guide.
This condition could be caused by the /var file system filling up. If this is the case, either define more space for /var or remove unnecessary files.
If the problem persists, contact the IBM Support Center.
Once you have corrected the problem, rerun the command that produced the error to verify that it is corrected.
The trusted services authentication methods for a system partition determine the rules used by that system partition's sdrd to permit write and administrator access to the SDR. SDR administrator access is required for commands that change class definitions or create and delete files from the SDR. Write access is required for commands that add objects, change attributes and replace files in the SDR.
If the trusted services authentication methods are set to DCE only, appropriate credentials are needed to be able to issue write or administrator commands to the SDR. If the trusted services authentication methods are set to dce:compat, compat, or anything else, only the root user on the control workstation or an SP node in the sdrd's system partition can issue write or administrator commands to that system partition's SDR. For more information on authentication, see "The System Data Repository" appendix in PSSP: Administration Guide.
If an SDR command fails to write to the SDR, perform these steps:
If not, check the SP_NAME environment variable to see if it is set to connect to an unexpected system partition. If SP_NAME is not set, check the /etc/SDR_dest_info file for correctness. To correct the SDR_dest_info file, see Action 2 - Analyze system or network changes, Step 2.
Issue the klist command to see if you have DCE credentials. If so, you can see which SDR groups you belong to.
If you do not belong to a group with sdr and write in the name, you cannot write to the SDR. If you do not belong to a group with sdr and admin in the name, you cannot issue SDR administrator access commands.
If this is the case, ask your security administrator to add you to the appropriate sdr groups. As an alternative, dce_login to a principal that is in the appropriate sdr groups. If you have no credentials, dce_login to a principal in the appropriate sdr groups.
Note that there are separate groups for access to system classes which are global to all system partitions, and for access to partition-sensitive classes. The objects of partition-sensitive classes may be written only from that system partition's sdrd. Groups for system classes have system-class in their name, unless the name was overridden in the /spdata/sys1/spsec/spsec_overrides file. Groups for partition-sensitive classes do not have system-class in their name.
Partition-sensitive groups can also be partitioned. If the group has a :p appended to it in the spdata/sys1/spsec/spsec_overrides file, there will be a separate group for each partition, with its own access list.
To determine if there is a problem with DCE, see Diagnosing SP Security Services problems.
The root user on the control workstation or root on a node in the SDR's system partition is allowed to perform write or administrator commands to the SDR.
Issue the whoami command to make sure that you are running as root. If you are not root, and DCE is an option for your system partition, follow the actions in Step 3a.
If you are root, perform these steps:
where hostname is the hostname found in the previous step.
SDRGetObjects Adapter netaddr==ipaddress
where ipaddress is the address found in the previous step.
If there is no object for the IP address you entered, the SDR will not recognize your node as being in its system partition. Also, the SDR will not allow root on the node to perform write or administrator SDR commands. Possible causes are: the adapters were not set up correctly during installation, and the network is not set up correctly on the node.
To see how routing is set up on a node, see Diagnosing IP routing problems. For information on how to add adapters, see PSSP: Installation and Migration Guide.
Also, if there is an adapter on the node that cannot be defined in the Adapter class of the SDR, but commands from the node are routed across that adapter, the sdrd will not recognize the command as coming from one of its nodes.
In this case, a static route may be added from the node to the control workstation by using the smit fastpath mkroute. The destination address should be the IP address that represents the system partition of the node. The gateway IP address should be for an adapter that is defined in the SDR. Another possible workaround for this situation is to define the IP address of the unsupported adapter as a supported adapter type.
Once you have corrected the problem, check that the SDR can be written to by running the SDR_test command.