projctl Command

The various subcommands of projctl command perform project-based advanced accounting activities such as adding a new project, removing a new project, and loading a specific accounting policy. These various options of projctl command are as explained below.

Flags

Item	Description
-a	Automatically loads the policies during system reboot.
-d	Generally specifies the path from where the project definition file or the admin policy file should be referred. When used in the merge subcommand, it specifies the target project definition file where the merged project definitions are to be stored.
-f	Overrides the policy rules when specified with chg and exec subcommands. Clears the project assigned to the processes when called with unldall subcommand. Force unload all the project definitions when called with unldprojs subcommand.
-g	Specifies that the projects and policies are to be downloaded from the LDAP repository.
-n	Sorts the list of project definitions based on the name.
-p	When used in the chg subcommand, passes the list of process IDs that require a change in project assignment. When used in the add, rm, and chattr subcommands, specifies the LDAP DN where the project definition is to be updated. When used in the ld and unld subcommands, specifies that the projects and policies are to be uploaded to the LDAP repository. Its argument indicates the DN where the projects and policies are to be uploaded.
-r	Reloads the policies.
-s	Used in projctl chattr agg subcommand to enable the project aggregation property.
-u	Used in projctl chattr agg subcommand to disable the project aggregation property.

Parameters

Item	Description
admpath	Path from where to select the admin policy file.
appname	Absolute path of the application whose project assignment list is requested.
cmd line	Absolute path of the command to be executed through projctl exec command.
comment	Project comments.
DN	Distinguished Name that indicates the absolute path to the project and policy objects on the LDAP server.
name	Name of the alternate admin policy definitions on the LDAP server.
pid	Process IDs.
projname	Name of the project.
projnumber	Numeric value for the project.
projpath	Path from where to select the project definition file.
sourceprojpath	Path from where the project definition file to be merged is to be picked up.
targetprojfile	Target project definition file where the project definitions should be merged.

Subcommands

add Subcommand

The add subcommand adds the definition of the project to the project definition file. If the –d flag is specified then the project definition is added into the project definition file, under the named path. The default is to add to the /etc/project/projdef system project definition file. The project definition file under any other path should be named as .projdef:. If the new project is to be added to the system project definition file and the projects are already loaded in kernel, then the specified new project will be added into kernel project registry. Otherwise, the entry will be made only in the file. The add subcommand takes the project name, project number, and an option argument for project comments as parameters. By default, the aggregation property of the project will be set to no for all the projects created using this command.

If -p is specified, the new project definition is added to default project DN or the specified DN on the LDAP server. If -p is not specified, .config will provide source information. Running the -p option requires root authority.

Each entry created by projctl add in the Project Definition File has the following format:

ProjectName:ProjectNumber:AggregationStatus::Comment

Examples for Project Definitions that illustrate the file format are as follows:

:: Project Definition File
:: Dated: 23-JUN-2003
AIX:3542:yes::To Classify AIX Legacy Applications
Test_Project:0x10000:yes::To Classify Testing work

chattr agg Subcommand

The chattr agg subcommand enables and disables aggregation property for the given project. If -s flag is used the aggregation is enabled. If -u flag is used aggregation is disabled. If –d flag is specified then the project definition is updated in the project definition file under the specified path. The default is to update the system project definition file (/etc/project/projdef). If the update is to the system project definition file and it is already loaded in kernel, then the specified new project is updated in kernel project registry as well. Otherwise, the changes will be made only to the project definition file.

If -p is specified, the project definition is modified on default project DN or the specified DN on the LDAP server. If -p is not specified, .config will provide source information. Executing the -p option requires root authority.

chg Subcommand

The chg subcommand enables the user to change the list of projects that the user is permitted to use for his processes. The intended project name is given as input to this subcommand. If the process IDs are provided as input, those processes will be classified under the specified project. If there are no process IDs provided as input, the project change will happen to the process which started the projctl command.

By default, the chg subcommand changes the project assignment within the scope of available rules. To override the rules and assign a project directly to a process, the -f force option must be specified.

chk Subcommand

The chk subcommands check the validity of various project policies. The subcommands validate the projects and policies so that they can be loaded safely into the kernel. There are several chk subcommands to support various project policies. The subcommands include:

Item	Description
chkadm	Validates the admin policies. Each rule in the admin policy file usually has four attributes: user-id, group-id, application path name, and the project names. The chkadm subcommand checks whether these attributes are valid and reports any errors found in the policies. When the -d option is used, the chkadm subcommand uses the admin policy file from the specified path for checking the rules. It also uses the alias and the temporary project definition file (.projdef), if required. The projects used in the rule will be first searched in the system project definition file. If it is not found there, then the .projdef file under the specified path will be used.
chkall	Performs all the above validation activities, that is, it validates projects, user, group and admin policies. When the –d option is used, the chkadll subroutine uses the admin, alias, and project definition files from the specified path to validate the admin policies.
chkgrp	Validates the group policies. The validation involves checking whether the project list of the group contains valid projects.
chkprojs	Validates the system project definition file. Project Definitions are validated for uniqueness, project name and number validity, and attributes validity. The project name should be a POSIX alphanumeric string and the project number should be within the numeric range 0x00000001 - 0x00ffffff. The project numbers can be either decimal or hexadecimal numbers. All hexadecimal numbers should be shown with a prefix of `0x`. The aggregation property can be either a `y` or a `n` to indicate the status of aggregation. The chkprojs subcommand performs all these validity checks on the project definitions and reports any errors found with the project definitions.
chkusr	Validates the user policies. The validation involves checking whether the project list of the user contains valid projects.

Note: If wildcard characters are used in the admin policy rules then chkadm and chkall subcommands expand the wildcard characters and validate the output obtained.

exec Subcommand

The exec subcommand allows a user to launch arbitrary commands with any of the project names from the list of projects on which the command can work. Similar to chg option, used to override the rules and use any project to run the command line, the -f force option should be used. To get the list of projects that the command can be assigned to, use the projctl qapp subcommand.

ld Subcommand

The ld subcommands are used to load and reload projects and policies. There are specific load commands to perform the load operation on a specific policy. These various subcommands are as follows:

Item	Description
ld	Loads the policies, which should be loaded during the system startup. It refers the /etc/project/.config file to determine which policies to load. If the kernel is loaded already with any one policy or project definition, then this command simply returns.
ldadm	Loads the admin policies. Similar to ldusr and ldgrp subcommands, ldadm also checks and loads the projects first, if they are yet to be loaded. Then it loads the admin policy rules, after validating them. When the -d option is used, the admin policy file will be picked from the specified path. The alias and the temporary project definition file under the specified path will be used to check the existence of alias and project entries. After the policies are loaded, this subcommand also copies the admin policy file to /etc/project/.admin. Loading the admin policies related to LDAP is handled by the following -p and -g arguments: projctl ldadm -g [name] Specifies that an admin policy will be loaded into the kernel using the LDAP repository. If -g is not specified, the local admin policy (/etc/project/admin) will be downloaded into the kernel. projctl ldadm -g [ [name:]DN \| name ] -d admpath Specifies that an LDAP admin policy will be downloaded to a local file without downloading the policy into the kernel. The source admin policy is located at the specified DN or is found using the accounting DNs in the ldap.cfg file. The -d parameter is used to specify where the policy files (projects, admin, and alias) are written. If the target location is below /etc/project/, the files are written according to the conventions used by the system. Files are written to: /etc/project/admin, /etc/project/alias, /etc/project/projdef /etc/project/ldap/admin, /etc/project/ldap/alias, /etc/project/ldap/projdef /etc/project/projdef, /etc/project/alter/policyname/admin, .../alias /etc/project/ldap/projdef, /etc/project/ldap/alter/policyname/admin, .../alias Otherwise, the three files are written to the specified directory. When an explicit DN is specified with the -g option, the projects are not downloaded because they could also be located on a different DN. In this case, the user has to download them separately. projctl ldadm -p [ [name:]DN \| name ] -d admpath Specifies that an admin policy located at the directory localpath will be uploaded to the LDAP server. This command also uploads projects that it finds in the localpath/.projdef temporary project definition file. When an explicit DN is specified with the -p option, only the admin policy is uploaded to the LDAP server because the projects could be located on a different DN. In this case, the user must explicitly upload the respective .projdef file to the appropriate DN. The system does not know the identity of this DN. The -d argument must be specified when the -g or -p arguments are used. The -r and -a arguments cannot be specified with the -p argument. If the -a argument is specified and the -g argument is not specified, the admin policies in the .config file are loaded. If the -r option is used, the .active file is used to determine the identity of the policies to load. The -r and -a options cannot be used together.
ldall	Downloads user, group, and admin policies into the kernel. Similar to the ldusr and ldgrp commands, this option attempts to download LDAP projects if an accounting DN has been specified for projects, because the User and Group Policies are not associated with Local or LDAP Users individually. This command attempts to download the default Admin policy using the configured admin DN in addition to downloading the Local Admin Policy.
ldgrp	Loads the group project policies. If they are not yet loaded, the ldgrp subcommand checks and loads the projects first. It then verifies the validity of the project list for all the groups and loads the rules.
ldprojs	Loads the project definitions from the system project definition /etc/project/projdef file. Before loading the projects, it checks the validity of the rules. If the rules are found to valid, then it loads them. projctl ldprojs -g Specifies that the project definitions will be loaded into the kernel using the LDAP repository. projctl ldprojs -p Specifies that project definitions are to be uploaded to the LDAP server. If -g and the -p are not specified, the locally defined projects (/etc/project/projdef) are loaded into the kernel. projctl ldprojs -g [DN] -d localpdfpath Specifies that the project definition file from the LDAP repository will be downloaded to a local file without downloading the projects into the kernel. If the -d argument is not specified, the projects are downloaded to /etc/project/ldap/projdef and they are downloaded into the kernel. The -d argument directs you to create the file at the designated location, but not to download it into the kernel. In this case, the projdef file is created at the designated location rather than in the .projdef file. The source project definitions are located at the specified DN. Alternately, you can find them using the configured accounting DN in the ldap.cfg file. projctl ldprojs -d localpdfpath Loads the local project definition file into the kernel. projctl ldprojs -p [DN] -d localpdfpath Specifies that the project definitions located at the specified path will be uploaded to the LDAP server. The project definitions should be available in the projdef file at the specified directory. The -d argument must be specified when the -g or -p directs you to create the file at the designated location, but not to download it into the kernel. In this case, the projdef arguments are used. This way, the upload and download operations can be symmetric with respect to the specification of parameters. The -r and -a arguments cannot be specified with the -p argument. If the -a argument is specified and the -g argument is not specified, the project repositories in the .config file are loaded. If the -r option is used, the .active file is used to determine the project repositories to load. The -r and -a options cannot be used together.
ldusr	Loads the user project policies. If they are not yet loaded, the lduser subcommand checks and loads the projects first. It then verifies the validity of the project list for all the users and loads the rules.

Note:

When –r option is used, all the above subcommands reload the respective policies. The ld –r subcommand queries the kernel to get the details of loaded policies and reloads them. The policy files to be reloaded will be referred from the /etc/project/.active file.
When ldadm and ldall subcommands are issued with both the options –d and –r, -r will be ignored.
All the ld subcommands update the /etc/project/.active file with the details of the policy that is loaded. When the -a option is passed, these subcommands also update the /etc/project/.config file in addition to updating the .active file. The /etc/project/.config file provides the details on the policies to be loaded automatically on system reboot.

merge Subcommand

The merge subcommand merges the projects defined in the project definition file under the specified path with the system project definition /etc/project/projdef file, by default. If a target project file name is passed using the -d option, the project definitions under the specified path are merged with the target project definition file. The merge operation will fail if there are conflicting entries between the target project definition file and the project definition file under the specified path. The merge command skips any duplicate entries to maintain unique entries in the target project definition file.

qapp Subcommand

The qapp subcommand displays the list of projects that an application can switch to in the current environment. It displays the list of all projects with which the specified application can be started.

qpolicy Subcommand

The qpolicy subcommand displays the currently loaded policies. This command queries the kernel to get the information about the types of loaded policies and displays them. If -g is specified, this command lists the policies from the LDAP default admin DN or from the specified DN.

qproj Subcommand

The qproj subcommand displays the details of the project name passed as its argument. If no argument is passed, then this subcommand lists all the project definitions in the system to which the calling process can be assigned. The display format will be the same as that of qprojs subcommand.

qprojs Subcommand

The qprojs subcommand displays the list of all the project definitions that is currently loaded in the kernel registry. The -n option provides the list sorted based on the project name. The display contains the project name, project number, and its aggregation status.

rm Subcommand

The rm subcommand removes the definition of locally defined projects from the project definition file. If the –d flag is specified, then the project definition is removed from the project definition file under the specified path. The default is to remove it from the system project definition file (/etc/project/projdef). If the update is to the system project definition file and it is already loaded in kernel, then the specified project is removed from kernel project registry. Otherwise, the entry will be removed only from the file.

If -p is specified, the source will be the LDAP from where the project definitions are to be removed. If an explicit DN is specified, the project definition will be removed from that specific DN. If no DN is passed, the default DN configured in the ldap.cfg file will be used. If the LDAP projects are currently loaded, the project definition is removed from the kernel project registry and the local LDAP project file also. Otherwise, only the LDAP repository is updated.

Note: The -p and -d options cannot be used together. If neither of these options are specified, the .config file will be used to provide the source information. This command requires root authority to execute.

unld Subcommand

The unld subcommands are used to unload project policies. Similar to the ld subcommands, the unld subcommands are used to unload specific policies. These various subcommands are as follows:

Item	Description
unldadm	Unloads the admin policies.
unldall	Unloads all the loaded policies.
unldgrp	Unloads the group policies.
unldprojs	Unloads only the project definitions.
unldusr	Unloads the user policies.

Note:

All these subcommands update the .active file after the respective policy is unloaded.
When the -a option is used, the /etc/project/.config file is also updated with the unloaded status of the respective policy.
The -g parameter specifies that the respective LDAP repository should be unloaded from the kernel. If -g is not specified, then the loaded repositories that are named in the .active file are unloaded.
The -p option must be specified to remove the specified LDAP repository from the LDAP server.
In the unldadm and unsubcommand, the name parameter indicates the admin policy name on the admin DN.

Exit Status

Item	Description
0	The command completed successfully.
>0	An error occurred. 1 Default error return code for read, write, and malloc failures. 2 EINVAL and ENOENT 3 EPERM and EACCES 4 EEXIST

Examples

To add a project newproj to the system project definition file, type:
```
projctl add newproj 34 "Test Project"
```
To remove the project test1 from the project definition file under the path /tmp/myproj, type:
```
projctl rm test1 –d /tmp/myproj
```
To enable the aggregation status of the project newproj, type:
```
projctl chattr agg newproj –s
```
To execute the ps command under the project newproj, overriding the existing rules, type:
```
projctl exec newproj "/usr/bin/ps" –f
```

To retrieve the currently loaded policies, type:

projctl qpolicy

Output:

Project definitions are loaded.
Project definition file name:  /etc/project/projdef
User policies are loaded.

To load the admin policies from the path /tmp/myproj, type:
```
projctl ldadm –d /tmp/myproj
```
To unload all the project policies now and during system reboot, type:
```
projctl unldall -a
```
To add a new project to the LDAP repository on a different DN, where DN is ou=projects,ou=aacct,ou=cluster1,cn=aixdata, type:
```
projctl add newproj 34 -p ou=projects,ou=aacct,ou=cluster1,cn=aixdata
```
To download the LDAP projects from the default DN to a local file under the /etc/project/ldap path, type:
```
projctl ldprojs -g -d /etc/project/ldap
```
To load the LDAP admin policies stored under the label newdef in the default DN to the kernel, type:
```
projctl ldadm -g newdef 
```

Location

/usr/bin/projctl

Files

Item	Description
/usr/bin/projctl	Contains the projctl command.
/etc/project/projdef	Contains the system project definition file.
/etc/project/ldap/projdef	Contains the default LDAP project definition file.
/etc/project/.active	Contains the status of currently loaded policies.
/etc/project/.config	Contains the status of the policies to be loaded during system reboot.
/etc/security/ldap/ldap.cfg	Contains the LDAP client configuration details for handling advanced accounting data.