freeipa/ipa-4-10 — Chinese (Simplified) (zh_CN) @ Fedora Weblate: %(desc)s: %(info)s

English

Chinese (Simplified) (zh_CN)

Actions

Groups of hosts.

Manage groups of hosts. This is useful for applying access control to a
number of hosts by using Host-based Access Control.

EXAMPLES:

Add a new host group:
ipa hostgroup-add --desc="Baltimore hosts" baltimore

Add another new host group:
ipa hostgroup-add --desc="Maryland hosts" maryland

Add members to the hostgroup:
ipa hostgroup-add-member --hosts=box1,box2,box3 baltimore

Add a hostgroup as a member of another hostgroup:
ipa hostgroup-add-member --hostgroups=baltimore maryland

Remove a host from the hostgroup:
ipa hostgroup-remove-member --hosts=box2 baltimore

Display a host group:
ipa hostgroup-show baltimore

Delete a hostgroup:
ipa hostgroup-del baltimore

ID ranges

Manage ID ranges used to map Posix IDs to SIDs and back.

There are two type of ID ranges which are both handled by this utility:

- the ID ranges of the local domain
- the ID ranges of trusted remote domains

Both types have the following attributes in common:

- base-id: the first ID of the Posix ID range
- range-size: the size of the range

With those two attributes a range object can reserve the Posix IDs starting
with base-id up to but not including base-id+range-size exclusively.

Additionally an ID range of the local domain may set
- rid-base: the first RID(*) of the corresponding RID range
- secondary-rid-base: first RID of the secondary RID range

and an ID range of a trusted domain must set
- rid-base: the first RID of the corresponding RID range
- dom_sid: domain SID of the trusted domain

EXAMPLE: Add a new ID range for a trusted domain

Since there might be more than one trusted domain the domain SID must be given
while creating the ID range.

ipa idrange-add --base-id=1200000 --range-size=200000 --rid-base=0 --dom-sid=S-1-5-21-123-456-789 trusted_dom_range

This ID range is then used by the IPA server and the SSSD IPA provider to
assign Posix UIDs to users from the trusted domain.

If e.g. a range for a trusted domain is configured with the following values:
base-id = 1200000
range-size = 200000
rid-base = 0
the RIDs 0 to 199999 are mapped to the Posix ID from 1200000 to 13999999. So
RID 1000 <-> Posix ID 1201000

EXAMPLE: Add a new ID range for the local domain

To create an ID range for the local domain it is not necessary to specify a
domain SID. But since it is possible that a user and a group can have the same
value as Posix ID a second RID interval is needed to handle conflicts.

ipa idrange-add --base-id=1200000 --range-size=200000 --rid-base=1000 --secondary-rid-base=1000000 local_range

The data from the ID ranges of the local domain are used by the IPA server
internally to assign SIDs to IPA users and groups. The SID will then be stored
in the user or group objects.

If e.g. the ID range for the local domain is configured with the values from
the example above then a new user with the UID 1200007 will get the RID 1007.
If this RID is already used by a group the RID will be 1000007. This can only
happen if a user or a group object was created with a fixed ID because the
automatic assignment will not assign the same ID twice. Since there are only
users and groups sharing the same ID namespace it is sufficient to have only
one fallback range to handle conflicts.

To find the Posix ID for a given RID from the local domain it has to be
checked first if the RID falls in the primary or secondary RID range and
the rid-base or the secondary-rid-base has to be subtracted, respectively,
and the base-id has to be added to get the Posix ID.

Typically the creation of ID ranges happens behind the scenes and this CLI
must not be used at all. The ID range for the local domain will be created
during installation or upgrade from an older version. The ID range for a
trusted domain will be created together with the trust by 'ipa trust-add ...'.

USE CASES:

Add an ID range from a transitively trusted domain

If the trusted domain (A) trusts another domain (B) as well and this trust
is transitive 'ipa trust-add domain-A' will only create a range for
domain A. The ID range for domain B must be added manually.

Add an additional ID range for the local domain

If the ID range of the local domain is exhausted, i.e. no new IDs can be
assigned to Posix users or groups by the DNA plugin, a new range has to be
created to allow new users and groups to be added. (Currently there is no
connection between this range CLI and the DNA plugin, but a future version
might be able to modify the configuration of the DNS plugin as well)

In general it is not necessary to modify or delete ID ranges. If there is no
other way to achieve a certain configuration than to modify or delete an ID
range it should be done with great care. Because UIDs are stored in the file
system and are used for access control it might be possible that users are
allowed to access files of other users if an ID range got deleted and reused
for a different domain.

(*) The RID is typically the last integer of a user or group SID which follows
the domain SID. E.g. if the domain SID is S-1-5-21-123-456-789 and a user from
this domain has the SID S-1-5-21-123-456-789-1010 then 1010 is the RID of the
user. RIDs are unique in a domain, 32bit values and are used for users and
groups.

WARNING:

DNA plugin in 389-ds will allocate IDs based on the ranges configured for the
local domain. Currently the DNA plugin *cannot* be reconfigured itself based
on the local ranges set via this family of commands.

Manual configuration change has to be done in the DNA plugin configuration for
the new local range. Specifically, The dnaNextRange attribute of 'cn=Posix
IDs,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config' has to be
modified to match the new range.

Add new ID range.

To add a new ID range you always have to specify

--base-id
--range-size

Additionally

--rid-base
--secondary-rid-base

may be given for a new ID range for the local domain while

--rid-bas
--dom-sid

must be given to add a new range for a trusted AD domain.

WARNING:

DNA plugin in 389-ds will allocate IDs based on the ranges configured for the
local domain. Currently the DNA plugin *cannot* be reconfigured itself based
on the local ranges set via this family of commands.

Manual configuration change has to be done in the DNA plugin configuration for
the new local range. Specifically, The dnaNextRange attribute of 'cn=Posix
IDs,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config' has to be
modified to match the new range.

Permissions

A permission enables fine-grained delegation of rights. A permission is
a human-readable form of a 389-ds Access Control Rule, or instruction (ACI).
A permission grants the right to perform a specific task such as adding a
user, modifying a group, etc.

A permission may not contain other permissions.

* A permission grants access to read, write, add or delete.
* A privilege combines similar permissions (for example all the permissions
needed to add a user).
* A role grants a set of privileges to users, groups, hosts or hostgroups.

A permission is made up of a number of different parts:

1. The name of the permission.
2. The target of the permission.
3. The rights granted by the permission.

Rights define what operations are allowed, and may be one or more
of the following:
1. write - write one or more attributes
2. read - read one or more attributes
3. add - add a new entry to the tree
4. delete - delete an existing entry
5. all - all permissions are granted

Read permission is granted for most attributes by default so the read
permission is not expected to be used very often.

Note the distinction between attributes and entries. The permissions are
independent, so being able to add a user does not mean that the user will
be editable.

There are a number of allowed targets:
1. type: a type of object (user, group, etc).
2. memberof: a member of a group or hostgroup
3. filter: an LDAP filter
4. subtree: an LDAP filter specifying part of the LDAP DIT. This is a
super-set of the "type" target.
5. targetgroup: grant access to modify a specific group (such as granting
the rights to manage group membership)

EXAMPLES:

Add a permission that grants the creation of users:
ipa permission-add --type=user --permissions=add "Add Users"

Add a permission that grants the ability to manage group membership:
ipa permission-add --attrs=member --permissions=write --type=group "Manage Group Members"

Self-service Permissions

A permission enables fine-grained delegation of permissions. Access Control
Rules, or instructions (ACIs), grant permission to permissions to perform
given tasks such as adding a user, modifying a group, etc.

A Self-service permission defines what an object can change in its own entry.

EXAMPLES:

Add a self-service rule to allow users to manage their address:
ipa selfservice-add --permissions=write --attrs=street,postalCode,l,c,st "Users manage their own address"

When managing the list of attributes you need to include all attributes
in the list, including existing ones. Add telephoneNumber to the list:
ipa selfservice-mod --attrs=street,postalCode,l,c,st,telephoneNumber "Users manage their own address"

Display our updated rule:
ipa selfservice-show "Users manage their own address"

Delete a rule:
ipa selfservice-del "Users manage their own address"

Services

A IPA service represents a service that runs on a host. The IPA service
record can store a Kerberos principal, an SSL certificate, or both.

An IPA service can be managed directly from a machine, provided that
machine has been given the correct permission. This is true even for
machines other than the one the service is associated with. For example,
requesting an SSL certificate using the host service principal credentials
of the host. To manage a service using host credentials you need to
kinit as the host:

# kinit -kt /etc/krb5.keytab host/ipa.example.com@EXAMPLE.COM

Adding an IPA service allows the associated service to request an SSL
certificate or keytab, but this is performed as a separate step; they
are not produced as a result of adding the service.

Only the public aspect of a certificate is stored in a service record;
the private key is not stored.

EXAMPLES:

Add a new IPA service:
ipa service-add HTTP/web.example.com

Allow a host to manage an IPA service certificate:
ipa service-add-host --hosts=web.example.com HTTP/web.example.com
ipa role-add-member --hosts=web.example.com certadmin

Override a default list of supported PAC types for the service:
ipa service-mod HTTP/web.example.com --pac-type=MS-PAC

Delete an IPA service:
ipa service-del HTTP/web.example.com

Find all IPA services associated with a host:
ipa service-find web.example.com

Find all HTTP services:
ipa service-find HTTP

Disable the service Kerberos key and SSL certificate:
ipa service-disable HTTP/web.example.com

Request a certificate for an IPA service:
ipa cert-request --principal=HTTP/web.example.com example.csr

Generate and retrieve a keytab for an IPA service:
ipa-getkeytab -s ipa.example.com -p HTTP/web.example.com -k /etc/httpd/httpd.keytab

Groups of Sudo Commands

Manage groups of Sudo Commands.

EXAMPLES:

Add a new Sudo Command Group:
ipa sudocmdgroup-add --desc='administrators commands' admincmds

Remove a Sudo Command Group:
ipa sudocmdgroup-del admincmds

Manage Sudo Command Group membership, commands:
ipa sudocmdgroup-add-member --sudocmds=/usr/bin/less,/usr/bin/vim admincmds

Manage Sudo Command Group membership, commands:
ipa group-remove-member --sudocmds=/usr/bin/less admincmds

Show a Sudo Command Group:
ipa group-show localadmins

Sudo Rules

Sudo (su "do") allows a system administrator to delegate authority to
give certain users (or groups of users) the ability to run some (or all)
commands as root or another user while providing an audit trail of the
commands and their arguments.

IPA provides a means to configure the various aspects of Sudo:
Users: The user(s)/group(s) allowed to invoke Sudo.
Hosts: The host(s)/hostgroup(s) which the user is allowed to to invoke Sudo.
Allow Command: The specific command(s) permitted to be run via Sudo.
Deny Command: The specific command(s) prohibited to be run via Sudo.
RunAsUser: The user(s) or group(s) of users whose rights Sudo will be invoked with.
RunAsGroup: The group(s) whose gid rights Sudo will be invoked with.
Options: The various Sudoers Options that can modify Sudo's behavior.

An order can be added to a sudorule to control the order in which they
are evaluated (if the client supports it). This order is an integer and
must be unique.

IPA provides a designated binddn to use with Sudo located at:
uid=sudo,cn=sysaccounts,cn=etc,dc=example,dc=com

To enable the binddn run the following command to set the password:
LDAPTLS_CACERT=/etc/ipa/ca.crt /usr/bin/ldappasswd -S -W \
-H ldap://ipa.example.com -ZZ -D "cn=Directory Manager" \
uid=sudo,cn=sysaccounts,cn=etc,dc=example,dc=com

For more information, see the IPA Documentation to Sudo.

English	Chinese (Simplified) (zh_CN)
No related strings found in the glossary.

English

Chinese (Simplified) (zh_CN)

No related strings found in the glossary.

	English	Chinese (Simplified) (zh_CN)	Actions
	Groups of hosts. Manage groups of hosts. This is useful for applying access control to a number of hosts by using Host-based Access Control. EXAMPLES: Add a new host group: ipa hostgroup-add --desc="Baltimore hosts" baltimore Add another new host group: ipa hostgroup-add --desc="Maryland hosts" maryland Add members to the hostgroup: ipa hostgroup-add-member --hosts=box1,box2,box3 baltimore Add a hostgroup as a member of another hostgroup: ipa hostgroup-add-member --hostgroups=baltimore maryland Remove a host from the hostgroup: ipa hostgroup-remove-member --hosts=box2 baltimore Display a host group: ipa hostgroup-show baltimore Delete a hostgroup: ipa hostgroup-del baltimore
	ID ranges Manage ID ranges used to map Posix IDs to SIDs and back. There are two type of ID ranges which are both handled by this utility: - the ID ranges of the local domain - the ID ranges of trusted remote domains Both types have the following attributes in common: - base-id: the first ID of the Posix ID range - range-size: the size of the range With those two attributes a range object can reserve the Posix IDs starting with base-id up to but not including base-id+range-size exclusively. Additionally an ID range of the local domain may set - rid-base: the first RID() of the corresponding RID range - secondary-rid-base: first RID of the secondary RID range and an ID range of a trusted domain must set - rid-base: the first RID of the corresponding RID range - dom_sid: domain SID of the trusted domain EXAMPLE: Add a new ID range for a trusted domain Since there might be more than one trusted domain the domain SID must be given while creating the ID range. ipa idrange-add --base-id=1200000 --range-size=200000 --rid-base=0 --dom-sid=S-1-5-21-123-456-789 trusted_dom_range This ID range is then used by the IPA server and the SSSD IPA provider to assign Posix UIDs to users from the trusted domain. If e.g. a range for a trusted domain is configured with the following values: base-id = 1200000 range-size = 200000 rid-base = 0 the RIDs 0 to 199999 are mapped to the Posix ID from 1200000 to 13999999. So RID 1000 <-> Posix ID 1201000 EXAMPLE: Add a new ID range for the local domain To create an ID range for the local domain it is not necessary to specify a domain SID. But since it is possible that a user and a group can have the same value as Posix ID a second RID interval is needed to handle conflicts. ipa idrange-add --base-id=1200000 --range-size=200000 --rid-base=1000 --secondary-rid-base=1000000 local_range The data from the ID ranges of the local domain are used by the IPA server internally to assign SIDs to IPA users and groups. The SID will then be stored in the user or group objects. If e.g. the ID range for the local domain is configured with the values from the example above then a new user with the UID 1200007 will get the RID 1007. If this RID is already used by a group the RID will be 1000007. This can only happen if a user or a group object was created with a fixed ID because the automatic assignment will not assign the same ID twice. Since there are only users and groups sharing the same ID namespace it is sufficient to have only one fallback range to handle conflicts. To find the Posix ID for a given RID from the local domain it has to be checked first if the RID falls in the primary or secondary RID range and the rid-base or the secondary-rid-base has to be subtracted, respectively, and the base-id has to be added to get the Posix ID. Typically the creation of ID ranges happens behind the scenes and this CLI must not be used at all. The ID range for the local domain will be created during installation or upgrade from an older version. The ID range for a trusted domain will be created together with the trust by 'ipa trust-add ...'. USE CASES: Add an ID range from a transitively trusted domain If the trusted domain (A) trusts another domain (B) as well and this trust is transitive 'ipa trust-add domain-A' will only create a range for domain A. The ID range for domain B must be added manually. Add an additional ID range for the local domain If the ID range of the local domain is exhausted, i.e. no new IDs can be assigned to Posix users or groups by the DNA plugin, a new range has to be created to allow new users and groups to be added. (Currently there is no connection between this range CLI and the DNA plugin, but a future version might be able to modify the configuration of the DNS plugin as well) In general it is not necessary to modify or delete ID ranges. If there is no other way to achieve a certain configuration than to modify or delete an ID range it should be done with great care. Because UIDs are stored in the file system and are used for access control it might be possible that users are allowed to access files of other users if an ID range got deleted and reused for a different domain. () The RID is typically the last integer of a user or group SID which follows the domain SID. E.g. if the domain SID is S-1-5-21-123-456-789 and a user from this domain has the SID S-1-5-21-123-456-789-1010 then 1010 is the RID of the user. RIDs are unique in a domain, 32bit values and are used for users and groups. WARNING: DNA plugin in 389-ds will allocate IDs based on the ranges configured for the local domain. Currently the DNA plugin cannot be reconfigured itself based on the local ranges set via this family of commands. Manual configuration change has to be done in the DNA plugin configuration for the new local range. Specifically, The dnaNextRange attribute of 'cn=Posix IDs,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config' has to be modified to match the new range.
	Add new ID range. To add a new ID range you always have to specify --base-id --range-size Additionally --rid-base --secondary-rid-base may be given for a new ID range for the local domain while --rid-bas --dom-sid must be given to add a new range for a trusted AD domain. WARNING: DNA plugin in 389-ds will allocate IDs based on the ranges configured for the local domain. Currently the DNA plugin cannot be reconfigured itself based on the local ranges set via this family of commands. Manual configuration change has to be done in the DNA plugin configuration for the new local range. Specifically, The dnaNextRange attribute of 'cn=Posix IDs,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config' has to be modified to match the new range.
	Netgroups A netgroup is a group used for permission checking. It can contain both user and host values. EXAMPLES: Add a new netgroup: ipa netgroup-add --desc="NFS admins" admins Add members to the netgroup: ipa netgroup-add-member --users=tuser1,tuser2 admins Remove a member from the netgroup: ipa netgroup-remove-member --users=tuser2 admins Display information about a netgroup: ipa netgroup-show admins Delete a netgroup: ipa netgroup-del admins
	Permissions A permission enables fine-grained delegation of rights. A permission is a human-readable form of a 389-ds Access Control Rule, or instruction (ACI). A permission grants the right to perform a specific task such as adding a user, modifying a group, etc. A permission may not contain other permissions. * A permission grants access to read, write, add or delete. * A privilege combines similar permissions (for example all the permissions needed to add a user). * A role grants a set of privileges to users, groups, hosts or hostgroups. A permission is made up of a number of different parts: 1. The name of the permission. 2. The target of the permission. 3. The rights granted by the permission. Rights define what operations are allowed, and may be one or more of the following: 1. write - write one or more attributes 2. read - read one or more attributes 3. add - add a new entry to the tree 4. delete - delete an existing entry 5. all - all permissions are granted Read permission is granted for most attributes by default so the read permission is not expected to be used very often. Note the distinction between attributes and entries. The permissions are independent, so being able to add a user does not mean that the user will be editable. There are a number of allowed targets: 1. type: a type of object (user, group, etc). 2. memberof: a member of a group or hostgroup 3. filter: an LDAP filter 4. subtree: an LDAP filter specifying part of the LDAP DIT. This is a super-set of the "type" target. 5. targetgroup: grant access to modify a specific group (such as granting the rights to manage group membership) EXAMPLES: Add a permission that grants the creation of users: ipa permission-add --type=user --permissions=add "Add Users" Add a permission that grants the ability to manage group membership: ipa permission-add --attrs=member --permissions=write --type=group "Manage Group Members"
	Ping the remote IPA server to ensure it is running. The ping command sends an echo request to an IPA server. The server returns its version information. This is used by an IPA client to confirm that the server is available and accepting requests. The server from xmlrpc_uri in /etc/ipa/default.conf is contacted first. If it does not respond then the client will contact any servers defined by ldap SRV records in DNS. EXAMPLES: Ping an IPA server: ipa ping ------------------------------------------ IPA server version 2.1.9. API version 2.20 ------------------------------------------ Ping an IPA server verbosely: ipa -v ping ipa: INFO: trying https://ipa.example.com/ipa/xml ipa: INFO: Forwarding 'ping' to server u'https://ipa.example.com/ipa/xml' ----------------------------------------------------- IPA server version 2.1.9. API version 2.20 -----------------------------------------------------
	Self-service Permissions A permission enables fine-grained delegation of permissions. Access Control Rules, or instructions (ACIs), grant permission to permissions to perform given tasks such as adding a user, modifying a group, etc. A Self-service permission defines what an object can change in its own entry. EXAMPLES: Add a self-service rule to allow users to manage their address: ipa selfservice-add --permissions=write --attrs=street,postalCode,l,c,st "Users manage their own address" When managing the list of attributes you need to include all attributes in the list, including existing ones. Add telephoneNumber to the list: ipa selfservice-mod --attrs=street,postalCode,l,c,st,telephoneNumber "Users manage their own address" Display our updated rule: ipa selfservice-show "Users manage their own address" Delete a rule: ipa selfservice-del "Users manage their own address"
	Services A IPA service represents a service that runs on a host. The IPA service record can store a Kerberos principal, an SSL certificate, or both. An IPA service can be managed directly from a machine, provided that machine has been given the correct permission. This is true even for machines other than the one the service is associated with. For example, requesting an SSL certificate using the host service principal credentials of the host. To manage a service using host credentials you need to kinit as the host: # kinit -kt /etc/krb5.keytab host/ipa.example.com@EXAMPLE.COM Adding an IPA service allows the associated service to request an SSL certificate or keytab, but this is performed as a separate step; they are not produced as a result of adding the service. Only the public aspect of a certificate is stored in a service record; the private key is not stored. EXAMPLES: Add a new IPA service: ipa service-add HTTP/web.example.com Allow a host to manage an IPA service certificate: ipa service-add-host --hosts=web.example.com HTTP/web.example.com ipa role-add-member --hosts=web.example.com certadmin Override a default list of supported PAC types for the service: ipa service-mod HTTP/web.example.com --pac-type=MS-PAC Delete an IPA service: ipa service-del HTTP/web.example.com Find all IPA services associated with a host: ipa service-find web.example.com Find all HTTP services: ipa service-find HTTP Disable the service Kerberos key and SSL certificate: ipa service-disable HTTP/web.example.com Request a certificate for an IPA service: ipa cert-request --principal=HTTP/web.example.com example.csr Generate and retrieve a keytab for an IPA service: ipa-getkeytab -s ipa.example.com -p HTTP/web.example.com -k /etc/httpd/httpd.keytab
	Groups of Sudo Commands Manage groups of Sudo Commands. EXAMPLES: Add a new Sudo Command Group: ipa sudocmdgroup-add --desc='administrators commands' admincmds Remove a Sudo Command Group: ipa sudocmdgroup-del admincmds Manage Sudo Command Group membership, commands: ipa sudocmdgroup-add-member --sudocmds=/usr/bin/less,/usr/bin/vim admincmds Manage Sudo Command Group membership, commands: ipa group-remove-member --sudocmds=/usr/bin/less admincmds Show a Sudo Command Group: ipa group-show localadmins
	Sudo Rules Sudo (su "do") allows a system administrator to delegate authority to give certain users (or groups of users) the ability to run some (or all) commands as root or another user while providing an audit trail of the commands and their arguments. IPA provides a means to configure the various aspects of Sudo: Users: The user(s)/group(s) allowed to invoke Sudo. Hosts: The host(s)/hostgroup(s) which the user is allowed to to invoke Sudo. Allow Command: The specific command(s) permitted to be run via Sudo. Deny Command: The specific command(s) prohibited to be run via Sudo. RunAsUser: The user(s) or group(s) of users whose rights Sudo will be invoked with. RunAsGroup: The group(s) whose gid rights Sudo will be invoked with. Options: The various Sudoers Options that can modify Sudo's behavior. An order can be added to a sudorule to control the order in which they are evaluated (if the client supports it). This order is an integer and must be unique. IPA provides a designated binddn to use with Sudo located at: uid=sudo,cn=sysaccounts,cn=etc,dc=example,dc=com To enable the binddn run the following command to set the password: LDAPTLS_CACERT=/etc/ipa/ca.crt /usr/bin/ldappasswd -S -W \ -H ldap://ipa.example.com -ZZ -D "cn=Directory Manager" \ uid=sudo,cn=sysaccounts,cn=etc,dc=example,dc=com For more information, see the IPA Documentation to Sudo.
	Failed CAs	作为其他用户运行失败
	Failed member manager	失败的成员
	Failed managedby	失败的成员
	System encoding must be UTF-8, '%(encoding)s' is not supported. Set LC_ALL="C.UTF-8", or LC_ALL="" and LC_CTYPE="C.UTF-8".
	Mapping ruleset "%(ruleset)s" has more than one rule for the %(helper)s helper
	%(desc)s: %(info)s	%(info)s
	%(exception)s	服务选项
	Forest '%(forest)s' has existing trust to forest(s) %(domains)s which prevents a trust to '%(conflict)s'
	%(line)s
	Forwarding policy conflicts with some automatic empty zones. Queries for zones specified by RFC 6303 will ignore forwarding and recursion and always result in NXDOMAIN answers. To override this behavior use forward policy 'only'.
	%(subject)s: Malformed certificate. %(reason)s
	The host was added but the DNS update failed with: %(reason)s
	The certificate for %(ca)s is not available on this server.	字符%(char)r是不允许的。
	ipa <command> --help
	Unable to parse option {item}	服务解析主体
	Exceeded number of tries to forward a request.	重试认证的次数
	single label {}s are not supported	主机不被支持
	cannot be longer that {} characters	DNS标签不能长于63个字符
	must be a certificate	撤销证书。
	must be a certificate signing request	提交一个证书签名请求。
	must be at least 0	必须至少%(minvalue)d

freeipa

ipa-4-10

Chinese (Simplified) (zh_CN)

Translate

Translation

Things to check

Python format

Glossary

String information

Flags

String age

Last updated

Source string age

Translation file