I recently updated my last entry, More About Configuring Policy Agent 3.0, saying that I would add an entry about the famadm utility. Yeah, so, that's what I'm doing now.
Much of this info comes from engineering folks: Dennis Seah, Hua Cui, and Sean Brydon.
As I mentioned in the update to my previous entry, info about setting up the famadm command line utility is provided on this Wiki page. Sean added that info, and while it has a Policy Agent 3.0 slant to it, much of the beginning steps that he describes relates to FAM 8, too, at least instructions describing how to make the famadm utility available.
Normal Software Development:
OpenSSO is changing constantly, of course. Some changes even affect the famadm utility. Therefore, from build 4 to 5 (build 5 isn't out as of yet), a few differences will exist. For example, access to agents has changed in the FAM Console. In build 4, you access agents from the Configuration tab. In build 5, you access agents the way it was done in Access Manager: In the Access Control tab, you select a realm. Then you can access agents. How does this relate to the famadm utility? In build 4, when issuing famadm to create or configure an agent, it was not required to list an agent's realm. Now it is required. You can use -e or --realm for the realm argument, as such:
famadm update-agent --realm
famadm update-agent -e
Here's the famadm command with the list-servers subcommand:
With the required options, this command lists all server instances. Here is some usage info for this command:
Issued from the directory containing the famadm utility, the command might look like either of the following two examples:
[root@localhost]# ./famadm list-servers --adminid amadmin --password-file /tmp/testpwd
[root@localhost]# ./famadm list-servers -u amadmin -f /tmp/testpwd
A More-Involved Example:
What Dennis pointed out to me was that you can enter the subcommand name of the famadm command, such as update-agent. To which, the response will be a list of options. First, here's a complete command issued from the directory containing the famadm utility:
[root@localhost]# ./famadm update-agent -e testRealm1 -b testAgent1 -u amadmin -f
/tmp/testpwd -a "com.sun.identity.agents.config.locale=en_US"
Now, in the box below is the famadm command with the update-agent subcommand, also issued from the directory containing the famadm utility (notice that the options for this subcommand are provided and explained).
[root@localhost]# ./famadm update-agent
Incorrect option(s), famadm update-agent
famadm update-agent --options [--global-options]
Update agent configuration.
Name of the locale to display the results.
Run in debug mode. Results sent to the debug file.
Run in verbose mode. Results sent to standard output.
Name of realm.
Name of agent.
Administrator ID of running the command.
File name that contains password of administrator.
Set this flag to overwrite properties values.
properties e.g. homeaddress=here.
Name of file that contains properties.
Let's focus on the following usage info:
We can tell that the update-agent subcommand requires the following arguments:
realm, agentname, adminid, password-file
The options bounded by square brackets are optional.
However, you need to use either --attributevalues or --datafile
to provide an attribute name and the corresponding value.
The following is an example of how to set the locale for a web agent by storing the property name and value in a data file:
-e testRealm1 -b testAgent1 -u amadmin -f /tmp/pwd -D /tmp/testproperty
where the testproperty
the following text:
Updated 05/09/08 - I got some comments from developer Charles Wesley about this blog entry. I concluded that I should add one more section to it. Therefore, I've added the following section about wildcards:
Wildcards and Attribute Values: A Word of Caution
When issuing the famadm
command, if you include attribute values that contain wildcards (e.g.
'\*'), then the associated attribute name/value pair should be enclosed
in double quotes to avoid substitution by the shell.
This applies when you use the -a (or --attributevalues)argument. This isn't necessary when you list the attributes in a data file and access them with the -D argument. The following example demonstrates the use of double quotes while setting a J2EE attribute (Not Enforced URIs).
[root@localhost]# ./famadm update-agent -e
testRealm1 -b testAgent1 -u amadmin -f /tmp/testpwd -a "com.sun.identity.agents.config.notenforced.uri=/exampledir/public/\*"