![]() |
![]()
| ![]() |
![]()
NAMEipa - IPA command-line interface SYNOPSISipa [options] [-c FILE] [-e KEY=VAL] COMMAND [parameters] DESCRIPTIONIPA is an integrated security information management solution based on 389 Directory Server (formerly know as Fedora Directory Server), MIT Kerberos, Dogtag Certificate System and DNS. It includes a web interface and command-line administration tools for managing identity data. This manual page focuses on the ipa script that serves as the main command-line interface (CLI) for IPA administration. More information about the project is available on its homepage located at http://www.freeipa.org. OPTIONS
COMMANDSThe principal function of the CLI is to execute administrative commands specified by the COMMAND argument. The majority of commands are executed remotely over XML-RPC on a IPA server listed in the configuration file (see FILES section of this manual page). From the implementation perspective, the CLI distinguishes two types of commands - built-ins and plugin provided. Built-in commands are static and are all available in all installations of IPA. There are two of them:
Plugin provided commands, as the name suggests, originate from IPA plugin modules. The available set may vary depending on your configuration and can be listed using the built-in help command (see above). Most plugin provided commands are tied to a certain type of IPA object. IPA objects encompass common abstractions such as users (user identities/accounts), hosts (machine identities), services, password policies, etc. Commands associated with an object are easily identified thanks to the enforced naming convention; the command names are composed of two parts separated with a dash: the name of the corresponding IPA object type and the name of action performed on it. For example all commands used to manage user identities start with "user-" (e.g. user-add, user-del). The following actions are available for most IPA object types:
The above types of commands except find take the objects primary key (e.g. user name for users) as their only positional argument unless there can be only one object of the given type. They can also take a number of options (some of which might be required in the case of add) that represent the objects attributes. find commands take an optional criteria string as their only positional argument. If present, all objects with an attribute that contains the criteria string are displayed. If an option representing an attribute is set, only object with the attribute exactly matching the specified value are displayed. Options with empty values are ignored. Without parameters all objects of the corresponding type are displayed. For IPA objects with attributes that can contain references to other objects (e.g. groups), the following action are usually available:
The above types of commands take the objects primary key as their only positional argument unless there can be only one object of the given type. They also take a number of options that represent lists of other object primary keys. Each of these options represent one type of object. For some types of objects, these commands might need to take more than one primary key. This applies to IPA objects organized in hierarchies where the parent object needs to be identified first. Parent primary keys are always aligned to the left (higher in the hierarchy = more to the left). For example the automount IPA plugin enables users to manage automount maps per location, as a result all automount commands take an automountlocation primary key as their first positional argument. All commands that display objects have three special options for controlling output:
AUDIT AND LOGGINGThe IPA API logs audit messages to systemd journal about each command executed through IPA API on the IPA server. These messages can be found by grepping systemd journal with journalctl -g IPA.API command. The message includes following information: May 21 11:31:33 master1.ipa1.test /usr/bin/ipa[247422]: [IPA.API] [autobind]: user_del: SUCCESS [ldap2_140328582446688] {"uid": ["foobar"], "continue": false, "version": "2.253"}
All explicitly requested operations logged. Internal operations, initiated as part of execution of the explicitly requested IPA API calls, aren't logged. For HTTP end-point operations will be logged as performed by the '/mod_wsgi' executable binary. Remaining details can be inspected through the systemd journal as journald records execution context. See systemd.journal-fields(7) for details. The details of the individual logged messages can be explained with the help of retrieved with 'journalctl -o json-pretty'. See journalctl(1) for details on the systemd journal viewer. For the sample message above, an explanation could be requested with 'journalctl -x -g ldap2_140328582446688' where LDAP backend connection instance identifier can be used to uniquely fetch that individual message. EXAMPLES
SERVERSThe ipa client will determine which server to connect to in this order:
ENVIRONMENT VARIABLES
FILES
EXIT STATUS0 if the command was successful 1 if an error occurred 2 if an entry is not found SEE ALSOipa-client-install(1), ipa-compat-manage(1), ipactl(1), ipa-dns-install(1), ipa-getcert(1), ipa-getkeytab(1), ipa-join(1), ipa-ldap-updater(1), ipa-nis-manage(1), ipa-replica-install(1), ipa-replica-manage(1), ipa-replica-prepare(1), ipa-rmkeytab(1), ipa-server-certinstall(2), ipa-server-install(1), ipa-server-upgrade(1), systemd.journal-fields(7), journalctl(1)
|