Hosted accounting policies

An accounting policy is hosted by another system enabling a single point of control to be established for the management of accounting policies.

Using a single point of control simplifies the administration and maintenance of accounting policies. You can use this capability to account for a user who logs into multiple machines across an enterprise. Alternatively, or in conjunction with this capability, you can define server-specific billing strategies. The Advanced Accounting subsystem enables multiple policies to be defined concurrently for a server. You can use this flexibility to implement the right solution for your business.

You implement hosted accounting policies using the Lightweight Directory Access Protocol (LDAP), which defines a standard mechanism for accessing and updating information in a directory (a database) either locally or remotely using a client-server model. The Advanced Accounting subsystem uses this technology to provide a single point of control for the management and distribution of accounting policies and projects to LDAP clients. You must configure each LDAP client system to access accounting data on the LDAP server, but once configured, the client behaves as if the policy were defined locally on that system.

The Advanced Accounting subsystem is fully integrated with user authentication. When creating a new user or group, you can optionally specify a project list for that user or group. This project list is part of the definition of that user or group and is automatically delivered to the client system when the user logs in. The project list is just another user attribute.

In general, you should establish project definitions with the same scope as the user. If a user is defined globally through LDAP, then the user's project definitions should also be defined globally through LDAP. Similarly, if a user is defined locally on a particular system, then the user's project definitions should be defined locally on that system. This simplifies the billing strategy, but is not required by the Advanced Accounting subsystem. Both project repositories can be loaded at the same time to accommodate local and LDAP users. It is recommended that Local and LDAP project definitions are defined in a non-overlapping way, although the Advanced Accounting subsystem does not enforce this. Projects are resolved based on the order that the project repositories are loaded. Local projects may be given precedence over LDAP projects by loading the local project repository before the LDAP project repository, and vice versa. It is also possible to only use local or LDAP projects.

Admin policies can also be stored on an LDAP server. The Admin policy provides an alternative mechanism for performing classification that in some ways is easier to manage than specifying a project list for each user. The Admin policy is a collection of assignment rules that can be more easily updated because it is not distributed across many individual user definitions. The Admin policy is managed as a single entity. You can define both local- and LDAP-based Admin policies.

The LDAP server is not Advanced Accounting-aware and can be maintained at a different software level. You can upload a schema that describes Advanced Accounting data to the server, so that it can be used to distribute accounting policies and project definitions without any special knowledge of project and policies.

You use the mkprojldap command to configure the connection between the LDAP server and client. Specifically, you use this command to upload the LDAP schema associated with the Advanced Accounting data to the server. This command is also used to define the location on the server where the data is to be stored for a particular client. This enables you to implement a different Admin policy and project repository for each client system, if desired. These items are individually configurable to provide the maximum flexibility. One reason for implementing a different Admin policy could be for administrative purposes, such as making the policy reflect the set of authorized users. Or, you might need to accommodate a different billing strategy for a particular server. For example, the use of server X is always charged to account Y, or server X is intended to be used for projects W and Z only.

You must individually configure each client system for accounting purposes. You must specify the set of policies that should be activated on each system by using the projctl command. This command has been extended to provide new functions such as uploading and downloading LDAP-based projects and Admin policies. In general, once the client system has been set up, the location of the policy and project repository is transparent to the end user.

The Advanced Accounting subsystem produces accounting data locally. The acctctl command must still be used to define data files and to manage them on an ongoing basis. However, you might want to place these files on shared storage subsystems such as a Storage Area Network (SAN) or in a distributed file system like NFS or General Parallel File System (GPFS) so that a billing application can have access to all of the data.

You can use the ps command to show the origin of a project that has been assigned to a process. This information is also recorded in the accounting record for a process, so that report and analysis tools can properly match the assigned project to the proper project repository, assuming that the tool is aware of multiple project repositories. This situation is best avoided by defining non-overlapping ranges of projects for local and LDAP-based projects.