freeipa/master — Indonesian @ Fedora Weblate: Failed source hosts/hostgroups

English

Indonesian

Actions

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

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.

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	Indonesian
No related strings found in the glossary.

English

Indonesian

No related strings found in the glossary.

	English	Indonesian	Actions
	comma-separated list of privileges
	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
	Override default list of supported PAC types. Use 'NONE' to disable PAC support for this service
	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
	comma-separated list of sudo commands to add
	comma-separated list of sudo commands to remove
	Active directory domain administrator's password	Domain Active Directory
	GECOS field
	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.
	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.
	comma-separated list of sudo command groups to add
	comma-separated list of sudo command groups to remove
	Failed members
	Failed source hosts/hostgroups	Grup layanan/layanan gagal
	Failed hosts/hostgroups	%i hosts atau hostgroups ditambahkan.
	Failed users/groups	Grup layanan/layanan gagal
	Failed service/service groups	Grup layanan/layanan gagal
	Failed to remove	Tak bisa menghapus entri
	Failed RunAs
	Failed RunAsGroup
	Failed profiles	Gagal mengurai berkas konfig %s
	Failed CAs
	Failed member manager
	Failed managedby
	Failed allowed to retrieve keytab	Gagal mengambil kunci apapun
	Failed allowed to create keytab	Gagal memperoleh keytab
	Failed targets	Gagal mengurai hasil: %s
	A dictionary representing an LDAP entry
	A list of LDAP entries

freeipa

master

Indonesian

Translate

Translation

Things to check

Consecutive duplicated words

Glossary

String information

String age

Last updated

Source string age

Translation file