From the perspective of the server, each client, application client, and Tivoli Data Protection host server is a node requiring TSM services. For information, see Overview of Client Nodes and File Spaces. Client nodes can be local or remote to the TSM server. For information, see Comparing Network-Attached Nodes to Local Nodes.
Administrators can perform the following activities when managing client
nodes.
Task | Required Privilege Class |
---|---|
Updating, renaming, locking, or unlocking any client nodes | System or unrestricted policy |
Updating, renaming, locking, or unlocking client nodes assigned to specific policy domains | System, unrestricted policy, or restricted policy for those domains |
Displaying information about client nodes or file spaces | Any administrator |
Deleting any client nodes | System or unrestricted policy |
Removing client nodes assigned to specific policy domains | System, unrestricted policy, or restricted policy for those domains |
Managing client access authority levels | System |
You can use the UPDATE NODE command to update information such as the client's assigned policy domain, the user's password or contact information, and the client option set used by the node.
For example, update client node TOMC to prevent him from deleting archived files from storage pools by entering:
update node tomc archdelete=no
You can rename a client node with the RENAME NODE command. You may need to rename a client node if the workstation network name or host name changes. For example, with UNIX clients, users define their node name based on the value returned by the HOSTNAME command. When users access the server, their TSM user IDs match the host name of their workstations. If the host name changes, you can update a client node user ID to match the new host name.
For example, to rename CAROLH to ENGNODE, enter:
rename node carolh engnode
ENGNODE retains the contact information and access to backup and archive data that belonged to CAROLH. All files backed up or archived by CAROLH now belong to ENGNODE.
You can prevent client nodes from accessing the server with the LOCK NODE command. This will prevent client nodes from performing functions such as either backup and restore or archive and retrieve.
You can restore a locked node's access to the server with the UNLOCK NODE command.
For example, to prevent client node MAB from accessing the server, enter:
lock node mab
To let client node MAB access the server again, enter:
unlock node mab
You can delete a client node from the server with the REMOVE NODE command. All file spaces that belong to the client node must first be deleted from server storage. After all of the client node's file spaces have been deleted (see Deleting File Spaces and Client Nodes), you can delete the node.
For example, to remove client node DEBBYG, enter:
delete filespace debbyg * type=any
remove node debbyg
You can display information about client nodes. For example, as a policy administrator, you might query the server about all client nodes assigned to the policy domains for which you have authority. Or you might query the server for detailed information about one client node.
You can display information about client nodes assigned to specific policy domains. For example, to view information about client nodes that are assigned to STANDARD and ENGPOLDOM policy domains, enter:
query node * domain=standard,engpoldom
The output from that command might look like this:
+--------------------------------------------------------------------------------+ |Node Name Platform Policy Domain Days Since Days Since Locked? | | Name Last Password | | Access Set | |---------- -------- -------------- ---------- ---------- ------- | |DEBBYG DOS STANDARD 2 12 No | |ENGNODE AIX ENGPOLDOM <1 1 No | |HTANG OS/2 STANDARD 4 11 No | |MAB AIX ENGPOLDOM <1 1 No | |PEASE AIX STANDARD 3 12 No | |SSTEINER (?) ENGPOLDOM <1 1 No | | | +--------------------------------------------------------------------------------+
You can view information about specific client nodes. For example, to review the registration parameters defined for client node JOE, enter:
query node joe format=detailed
The resulting report would look like this:
+--------------------------------------------------------------------------------+ | | | Node Name: JOE | | Platform: WinNT | | Client OS Level: 4.00 | | Client Version: Version 3, Release 1, Level 3.0 | | Policy Domain Name: STANDARD | | Last Access Date/Time: 05/19/1999 18:55:46 | | Days Since Last Access: 6 | | Password Set Date/Time: 05/19/1999 18:26:43 | | Days Since Password Set: 6 | | Invalid Sign-on Count: 0 | | Locked?: No | | Contact: | | Compression: Client's Choice | | Archive Delete Allowed?: Yes | | Backup Delete Allowed?: No | | Registration Date/Time: 05/19/1999 18:26:43 | | Registering Administrator: SERVER_CONSOLE | |Last Communication Method Used: Tcp/Ip | | Bytes Received Last Session: 108,731 | | Bytes Sent Last Session: 698 | |Duration of Last Session (sec): 0.00 | | Pct. Idle Wait Last Session: 0.00 | | Pct. Comm. Wait Last Session: 0.00 | | Pct. Media Wait Last Session: 0.00 | | Optionset: | | URL:http://JOE:2121 | | Node Type: Client | | Password Expiration Period: 60 | | Keep Mount Point?: No Maximum Mount Points Allowed: 1 | +--------------------------------------------------------------------------------+
When a client node is registered with the server, an identical administrative user ID with client owner authority to the node is created at the same time. You can use this administrative user ID to access the Web backup-archive client from a Web browser.
Enterprise logon enables a user with the proper administrative user ID and password to access a TSM client for help desk activities, such as performing a client restore operation. This also allows for a native backup-archive client to log on to TSM using their node name and password, or administrative user ID and password if they are configured to access a 3.7.0 server or above.
The following can use enterprise logon:
By default, an administrator with system or policy privilege over a client's domain, can remotely access clients and perform backup and restore operations.
You can grant client access or client owner authority to other administrators by specifying CLASS=NODE and AUTH=ACCESS or AUTH=OWNER parameters on the GRANT AUTHORITY command. The administrator must have one of the following privileges to grant or revoke client access or client owner authority:
You can grant an administrator client access authority to individual clients or you can grant an administrator client access to all clients in a specified policy domain. For example, you may want to grant client access privileges to users that staff help desk environments.
The following describes the difference between client owner and client access privileges:
The administrator can change the client node's password for which they have authority.
This privilege class authority is useful for help desk personnel so they can assist users in backing up or restoring data without having system or policy privileges. The client data can only be restored to none other than the original client. An administrative user ID with client access privilege cannot directly access client's data from a native backup-archive client. A system or policy administrator has client access privileges by default.
To grant client access authority to administrator FRED for the LABCLIENT node, issue:
grant authority fred class=node auth=access node=labclient
The administrator FRED can now access the LABCLIENT client, and perform backup and restore. The administrator can only restore data to the LABCLIENT node.
To grant client owner authority to ADMIN1 for the STUDENT1 node, issue:
grant authority admin1 class=node auth=owner node=student1
The administrator ADMIN1 can now perform backup and restore operations for the STUDENT1 client node. The administrator can also restore files from the STUDENT1 client node to a different client node.
An administrator can use the REGISTER NODE command to automatically create an administrative user ID with client owner authority to a node when the node is defined to the server. By default, the server creates an administrative user ID in addition to the client node entry. For example, you want to register client node DESK2, issue:
register node desk2 pass2dsk
The DESK2 client node is registered, in addition to an administrator user ID with the same DESK2 ID. The administrator DESK2 has a password of pass2dsk. The DESK2 administrator now has client owner authority to the DESK2 node. If the PASSWORDACCESS=GENERATE option is used by the client to change the password, the administrative DESK2 ID can access the client from a remote location.
An administrator can prevent automatic creation of an administrative user ID with client owner authority by specifying USERID=NONE on the REGISTER NODE command. For example, you want to register DESK2 without creating an administrative user ID with client owner authority by default, issue the following:
register node desk2 pass2dsk userid=none
You can grant client owner authority to an existing administrative user ID. This is useful if you want to set up enterprise logon for a remote help desk. For example, to give client owner authority to the HELPADMIN user ID when registering the NEWCLIENT node, enter:
register node newclient pass2new userid=helpadmin
This command results in the NEWCLIENT node being registered with a password of pass2new, and also grants HELPADMIN client owner authority. This command would not create an administrator ID. The HELPADMIN client user ID is now able to access the NEWCLIENT node from a remote location.