|
|
This chapter provides administration information for CPC. This includes the following:
The utility used to start, stop and control the Server processes is SYnpt.
usage: SYnpt [ -s [ S C ] | -h | -r | -c | -q ]
where:
-sS--Starts the server part of the system.
-sC-- Starts the client part of the system.
-h-- Halts CPC if it is running.
-r-- Reconfigures CPC if it is running.
-c-- Displays the configuration variables and their values.
-q-- Queries the status of the system. If no option is specified, this is the default.
Complete the following procedure to manually startup the CPC Server.
Step 2 Verify that Informix is running using the following Informix command:
dbaccess
Step 3 Start the Server:
SYnpt -sS
Complete the following procedure to manually shutdown the CPC Server.
Step 2 Stop the Server:
SYnpt -h
This will also terminate all client applications.
It is recommended that you configure the CPC Server to start automatically when the Server host system is booted. After a successful Server installation, the S98Activator file will be created in the /opt/CPC/Server/mng/template directory--use this file as a template for your installation.
 |
Note Informix must be running before you start CPC. As well, if you are using the CORBA API provided with CPC, the CORBA daemon must be running before you start CPC. |
Complete the following procedure to auto-start the CORBA daemon.
Step 2 Copy the S97SYcorba file to the /etc/init.d directory:
cp /opt/CPC/Server/mng/template/S97SYcorba /etc/init.d
Step 3 Edit the /etc/init.d/S97SYcorba file and replace <Activator-login> with admin.
Step 4 Create start-up and shut-down links to /etc/init.d/S97SYcorba:
ln -s /etc/init.d/S97SYcorba /etc/rc2.d/S97SYcorba ln -s /etc/init.d/S97SYcorba /etc/rc0.d/K97SYcorba
Complete the following procedure if the Informix Server and the CPC Server do not run on the same host system:
Step 2 Copy the S98Activator file to the /etc/init.d directory:
cp /opt/CPC/Server/mng/template/S98Activator /etc/init.d
Step 3 Edit the /etc/init.d/S98Activator file and replace <Activator-login> with admin. The resulting file will resemble:
case $1 in `start') /bin/su - admin -c "\ synptclean -s2 ; \ SYnpt -sS" ;; `stop') /bin/su - admin -c "\ SYnpt -h ; \ sleep 20" ;; esac exit 0
Step 4 Create start-up and shut-down links to /etc/init.d/S98Activator:
ln -s /etc/init.d/S98Activator /etc/rc2.d/S98Activator ln -s /etc/init.d/S98Activator /etc/rc0.d/K98Activator
CPC's Server processes need to access the Informix database. Therefore, if the Informix Server and the CPC Server do run on the same host system, the Informix Server must be running before the CPC processes are started. In this case, complete the following procedure:
Step 2 Copy the S98Activator file to the /etc/init.d directory:
cp /opt/CPC/Server/mng/template/S98Activator /etc/init.d
Step 3 Edit the /etc/init.d/S98Activator file and replace <Activator-login> with admin and add lines to start and stop the Informix Server. The resulting file will resemble:
case $1 in `start') echo "Starting Informix Database" /bin/su - informix -c "$INFORMIXDIR/bin/oninit" sleep 60 /bin/su - admin "\ synptclean -s2 ; \ SYnpt -sS" ;; `stop') /bin/su - admin "c\ SYnpt -h ; \ sleep 20" sleep 60 echo "Stopping Informix Database" /bin/su - informix -c "$INFORMIXDIR/bin/onmode -ky" ;; esac exit 0
Step 4 Create start-up and shut-down links to /etc/init.d/S98Activator:
ln -s /etc/init.d/S98Activator /etc/rc2.d/S98Activator ln -s /etc/init.d/S98Activator /etc/rc0.d/K98Activator
| Directory/File | Function |
|---|---|
docs | This directory contains the released documentation. |
install | This directory contains all installation programs and archives. |
scripts | This directory contains scripts to be used with CPC. |
Manifest | This file contains version information which uniquely identifies a given release. |
I
| Directory/File | Function |
|---|---|
data | This directory maintains the internal CPC data files, such as those generated during the CR preparation phase (for example, configuration, activation, and control files). |
log | This directory maintains CPC log files such as the Audit log. |
mng | This directory maintains CPC management script files. |
sys | This directory maintains CPC executable modules and registration files |
user | This directory contains user files in the Client or combined installations only. This directory is empty in a Server only installation. |
CPC security restricts access to the system to valid CPC users. For each valid CPC user, the CPC security system provides a mechanism to restrict what functions can be performed on which objects, based on the permissions and the security tags defined for each user.
To enforce security, an object which should not be globally accessible must be tagged. A tag is an attribute on the object whose value is used by the security system to restrict access to the object. Access is controlled to those Operators with then "same" security tags: those Operators have proper ownership of the object. An object can be defined with none, one, or two security tags. The two security tags that are supported by CPC are the MD (Management Domain) and VPN (Virtual Private Network).
CPC has a UNIX-based security system that uses a UNIX ASCII file to hold user information. CPC uses the UNIX user id as the CPC user id or username. For more information about creating users, refer to the chapter titled "Initial Installation". A CPC superUser is defined to have all UNIX file privileges and all CPC privileges in the default security file. Each user must be defined with explicit permissions to access specific MDs and/or VPNs. A user can be given access to multiple MDs and VPNs. In addition to names, MDs and VPNs can have two special tag values:
1. The "*" tag matches all objects and is really the set of all tags.
2. The "untagged" tag matches objects which are tagged with the "untagged" tag. A tag that has no assigned value is considered to be untagged. The value to represent the untagged value is configurable in the security file.
|
Note If the MD or VPN is not specified for a specific permission, then it is defaulted with a value of "*". If an object has an untagged MD, then it is considered to be "not in any domain". If an object has an untagged VPN then it is considered to be in the "supply network". |
CPC has a security registration file in which an Administrator can define user roles, associate permissions with the roles, and then register users against the roles. The security rights are defined in the $CCP_REL/data/security/securityInfo file.
CPC security supports the following permissions.
| Permission | Description and Supported Functions |
|---|---|
Examine | Allows users to display but not modify configuration information. |
Request | Allows users to create, modify, and |
Approve | Allows users to approve, re-approve, and reject Transactions. |
Schedule | Allows users to abort, commit, delete, retry, and schedule Transactions. |
Modify | Allows users to open a Transaction, perform all necessary modifications to the objects, not including profile objects, close the Transaction, and submit the Transaction. |
Modify Profile | Allows users to perform all necessary modifications to profile objects, not including the objects to which they |
Typically, an CPC system has three types of users: the Administrator, Operator, and Observer. They are normally defined as follows:
An Administrator is given all rights to the CPC data. To create this user type, ensure that the security file contains the following type description in the USERTYPES BEGIN ... USERTYPES END section. If this is not present, add it anywhere within that section.
ActivatorAdministrator BEGIN Examine domain/* vpn/* Request domain/* vpn/* Modify domain/* vpn/* Approve domain/* vpn/* Schedule domain/* vpn/* ModifyProfile/* vpn/* ActivatorAdministrator END
Modify the line for the user userid in the security file from:
userid superUser
to
userid ActivatorAdministrator
An Operator is given all rights to the CPC data except for the right to create/modify profiles. To create this user type, ensure that the security file contains the following type description in the USERTYPES BEGIN ... USERTYPES END section. If this is not present, add it anywhere within that section.
ActivatorOperator BEGIN Examine domain/* vpn/* Request domain/* vpn/* Modify domain/* vpn/* Approve domain/* vpn/* Schedule domain/* vpn/* ActivatorOperator END
Modify the line for the user userid in the security file from:
userid superUser
to
userid ActivatorOperator
An Observer is given only read privileges to the CPC data. To create this user type, ensure that the security file contains the following type description in the USERTYPES BEGIN ... USERTYPES END section. If this is not present, add it anywhere within that section.
ActivatorObserver BEGIN Examine domain/* vpn/* ActivatorObserver END
Modify the line for the user userid in the security file from:
userid superUser
to
userid ActivatorObserver
The security specifications above allow a given user access to all MDs and VPNs for their specific security rights. These rights can be further limited to selected domains and/or networks by adding a new user type description with a unique name and then associating that userid with that type.
Within the type description, the domain and/or vpn specifications can be modified according to the following rules:
The MD tag is available for selected CPC objects. It allows the managed network to be partitioned into administrative domains which have different users assigned to each domain. domain/* matches all domains. It can be replaced with one or more specifications of the form domain/myDomain. myDomain is the specific domain name to which the permissions apply. The special domain name untagged means a domain which is given no value.
For example, to restrict the user op55 to be an Operator for the MD "west," the following type description should be added to the USERTYPES BEGIN ... USERTYPES END section of the securityInfo file. If this is not present, add it anywhere within that section.
westOperator BEGIN Examine domain/west vpn/* Request domain/west vpn/* Modify domain/west vpn/* Approve domain/west vpn/* Schedule domain/west vpn/* westOperator END
Modify the line for the user userid in the security file from:
userid superUser
to
op55 westOperator
The VPN tag is available for selected CPC objects. It specifies the name of the customer that owns the object. VPNs provide logical groupings of network devices and resources. vpn/* matches all networks. It can be replaced with one or more specifications of the form vpn/myVpn. myVpn is the specific network name to which the permissions apply. The special network name untagged means a network which is given no value.
For example, to restrict the user op75 to be an Observer for the VPN "chicago," the following type description should be added to the USERTYPES BEGIN ... USERTYPES END section of the securityInfo file. If this is not present, add it anywhere within that section.
chicagoObserver BEGIN Examine domain/* vpn/chicago chicagoObserver END
Modify the line for the user userid in the security file from:
userid superUser
to
op75 chicagoObserver
CPC stores its persistent data in an Informix database. Access to this database is controlled via authentication mechanisms implemented by Informix. Informix uses a two tier authentication system:
1. A user must first be permitted to access the Informix database server, and
2. A user must then have permissions to access and manipulate data within the CPC database.
In order to implement the first tier, Informix uses UNIX password mechanisms. Specifically, if a user needs access to an Informix database server, they must have log in permissions on the UNIX host on which that server is executing. The second tier is implemented through SQL commands issued when the CPC database is created.
CPC uses two distinct types of processes to access an Informix database server:
1. Informix-supplied tools, such as dbaccess.
2. Syndesis-written processes, such as SYCCSServer.
Each process type has differing password requirements.
These processes do not permit specification of a password on the command line or in an environment variable. Instead, Informix relies on UNIX mechanisms to provide authentication.
Step 2 If the process is executing on a remote workstation, then one of two mechanisms is used:
a. In a network for which NIS is active for both the workstation and server, no further action is required.
b. When NIS does not apply, one or both of the following mechanisms is used:
For more details on the use of these files, contact your UNIX system administrator or review the hosts.equiv(4) manual page (execute man rhosts).
These processes obtain their password from an environment variable CCPPASSWORD and provide this during server login for authentication.
The following describes the procedure for modifying the Informix server password for the CPC Administrator. In the text that follows, this user will be referred to as admin.
Step 2 Change the password for admin on the UNIX server acting as the database server host. If NIS is in use in the network, this can be done from any host using yppasswd(1). Otherwise, log in as admin or root to the server host and use passwd(1).
Step 3 Verify the previous step by signing on as admin and executing dbaccess -ds. If the password has been correctly modified, then this will show a list of databases. Otherwise, the error `956: Client host or user (xxx@xxx) is not trusted by the server' will appear. This test should be done twice: once while logged onto a workstation and once while logged onto the database server.
Step 4 Log into the host running the CPC Server as admin. Edit the file /opt/cpc/serverInstall/mng/utility/syccpenvsetup- where serverInstall is the directory into which the server is installed. Find the line which sets the environment variable CCPPASSWORD and change the password. On completion, the line will appear as:
CCPPASSWORD=newPassword
where newPassword is the new password. If this contains the " character then these should be preceded by a \ character.
Step 5 Restart CPC to verify that the password change has been correctly done.
Posted: Thu Aug 3 16:37:08 PDT 2000
Copyright 1989-2000©Cisco Systems Inc.