Language Translated Unfinished Unfinished words Unfinished characters Untranslated Checks Suggestions Comments
English GPL-3.0 0 0 0 0 319 0 0
Basque GPL-3.0 0 0 0 0 3 0 0
Bengali (India) GPL-3.0 0 0 0 0 1 0 0
Catalan GPL-3.0 0 0 0 0 0 0 0
Chinese (Simplified) (zh_CN) GPL-3.0 0 0 0 0 67 0 0
Czech GPL-3.0 0 0 0 0 6 0 0
Dutch GPL-3.0 0 0 0 0 0 0 0
English (United Kingdom) GPL-3.0 0 0 0 0 0 0 0
Finnish GPL-3.0 18% 3,818 53,815 374,898 3,818 26 110 0
French GPL-3.0 0 0 0 0 196 0 0
German GPL-3.0 0 0 0 0 91 0 0
Hindi GPL-3.0 0 0 0 0 2 0 0
Hungarian GPL-3.0 0 0 0 0 0 0 0
Indonesian GPL-3.0 0 0 0 0 23 0 0
Japanese GPL-3.0 0 0 0 0 1 0 0
Kannada GPL-3.0 0 0 0 0 21 0 0
Korean GPL-3.0 54% 2,118 40,283 282,980 2,118 0 5 0
Marathi GPL-3.0 0 0 0 0 6 0 0
Polish GPL-3.0 0 0 0 0 4 0 0
Portuguese GPL-3.0 0 0 0 0 5 0 0
Portuguese (Brazil) GPL-3.0 0 0 0 0 5 0 0
Punjabi GPL-3.0 0 0 0 0 0 0 0
Russian GPL-3.0 0 0 0 0 325 0 0
Slovak GPL-3.0 0 0 0 0 49 0 0
Spanish GPL-3.0 0 0 0 0 163 0 0
Tajik GPL-3.0 0 0 0 0 5 0 0
Turkish GPL-3.0 0 0 0 0 0 0 0
Ukrainian GPL-3.0 0 0 0 0 150 0 0
Please sign in to see the alerts.

Overview

Project website www.freeipa.org
Instructions for translators

Mailing list for translators: <<trans@lists.fedoraproject.org>
Project maintainers User avatar abbra User avatar cheimes
Translation license GNU General Public License v3.0 or later
Translation process
  • Translations can be made directly.
  • Translation suggestions can be made.
  • Any authenticated user can contribute.
  • The translation uses bilingual files.
Source code repository https://github.com/freeipa/freeipa
Repository branch ipa-4-9
Last remote commit Back to git snapshots d088b0dc6
Antonio Torres authored 2 weeks ago
Last commit in Weblate Translated using Weblate (Korean) d380890e8
User avatar simmon authored 2 months ago
Weblate repository https://translate.fedoraproject.org/git/freeipa/ipa-4-9/
File mask po/*.po

String statistics

Strings percent Hosted strings Words percent Hosted words Characters percent Hosted characters
Total 37,876 368,650 2,536,514
Source 4,823 60,489 417,653
Translated 84% 31,940 74% 274,552 74% 1,878,636
Needs editing 0% 0 0% 0 0% 0
Read-only 12% 4,823 16% 60,489 16% 417,653
Failing checks 3% 1,468 28% 103,629 28% 722,777
Strings with suggestions 1% 115 1% 1,557 1% 11,019
Untranslated strings 15% 5,936 25% 94,098 25% 657,878
Last 12 months Previous

Activity in last 12 months

495 changes 47 changes 194 changes 2 changes 219 changes 3 changes 185 changes 6 changes 519 changes 4 changes 122 changes 2 changes 118 changes 6 changes 33 changes 0 changes 92 changes 8 changes 96 changes 109 changes 1,101 changes 5 changes 3 changes 0 changes
Dec Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov

Quick numbers

368 k
Hosted words
37,876
Hosted strings
84%
Translated
0
Contributors
and previous 30 days

Trends of last 30 days

—
Hosted words
+100%
—
Hosted strings
+100%
—
Translated
+84%
—
Contributors
+100%
User avatar anonymous

Suggestion added

  1. freeipa
  2. ipa-4-9
  3. Korean

Plugin to make multiple ipa calls via one remote procedure call

To run this code in the lite-server

curl -H "Content-Type:application/json" -H "Accept:application/json" -H "Accept-Language:en" --negotiate -u : --cacert /etc/ipa/ca.crt -d @batch_request.json -X POST http://localhost:8888/ipa/json

where the contents of the file batch_request.json follow the below example

{"method":"batch","params":[[
{"method":"group_find","params":[[],{}]},
{"method":"user_find","params":[[],{"whoami":"true","all":"true"}]},
{"method":"user_show","params":[["admin"],{"all":true}]}
],{}],"id":1}

The format of the response is nested the same way. At the top you will see
"error": null,
"id": 1,
"result": {
"count": 3,
"results": [


And then a nested response for each IPA command method sent in the request


Plugin to make multiple ipa calls via one remote procedure call

To run this code in the lite-server

curl -H "Content-Type:application/json" -H "Accept:application/json" -H "Accept-Language:en" --negotiate -u : --cacert /etc/ipa/ca.crt -d @batch_request.json -X POST http://localhost:8888/ipa/json

where the contents of the file batch_request.json follow the below example

{"method":"batch","params":[[
{"method":"group_find","params":[[],{}]},
{"method":"user_find","params":[[],{"whoami":"true","all":"true"}]},
{"method":"user_show","params":[["admin"],{"all":true}]}
],{}],"id":1}

The format of the response is nested the same way. At the top you will see
"error": null,
"id": 1,
"result": {
"count": 3,
"results": [


And then a nested response for each IPA command method sent in the request
a month ago
User avatar anonymous

Suggestion added

  1. freeipa
  2. ipa-4-9
  3. Korean

HBAC Services

The PAM services that HBAC can control access to. The name used here
must match the service name that PAM is evaluating.

EXAMPLES:

Add a new HBAC service:
ipa hbacsvc-add tftp

Modify an existing HBAC service:
ipa hbacsvc-mod --desc="TFTP service" tftp

Search for HBAC services. This example will return two results, the FTP
service and the newly-added tftp service:
ipa hbacsvc-find ftp

Delete an HBAC service:
ipa hbacsvc-del tftp


HBAC 서비스

The PAM services that HBAC can control access to. The name used here
must match the service name that PAM is evaluating.

예제:

Add a new HBAC service:
ipa hbacsvc-add tftp

Modify an existing HBAC service:
ipa hbacsvc-mod --desc="TFTP service" tftp

Search for HBAC services. This example will return two results, the FTP
service and the newly-added tftp service:
ipa hbacsvc-find ftp

Delete an HBAC service:
ipa hbacsvc-del tftp
a month ago
User avatar anonymous

Suggestion added

  1. freeipa
  2. ipa-4-9
  3. Korean

Host-based access control

Control who can access what services on what hosts and from where. You
can use HBAC to control which users or groups on a source host can
access a service, or group of services, on a target host.

You can also specify a category of users, target hosts, and source
hosts. This is currently limited to "all", but might be expanded in the
future.

Target hosts and source hosts in HBAC rules must be hosts managed by IPA.

The available services and groups of services are controlled by the
hbacsvc and hbacsvcgroup plug-ins respectively.

EXAMPLES:

Create a rule, "test1", that grants all users access to the host "server" from
anywhere:
ipa hbacrule-add --usercat=all --srchostcat=all test1
ipa hbacrule-add-host --hosts=server.example.com test1

Display the properties of a named HBAC rule:
ipa hbacrule-show test1

Create a rule for a specific service. This lets the user john access
the sshd service on any machine from any machine:
ipa hbacrule-add --hostcat=all --srchostcat=all john_sshd
ipa hbacrule-add-user --users=john john_sshd
ipa hbacrule-add-service --hbacsvcs=sshd john_sshd

Create a rule for a new service group. This lets the user john access
the FTP service on any machine from any machine:
ipa hbacsvcgroup-add ftpers
ipa hbacsvc-add sftp
ipa hbacsvcgroup-add-member --hbacsvcs=ftp,sftp ftpers
ipa hbacrule-add --hostcat=all --srchostcat=all john_ftp
ipa hbacrule-add-user --users=john john_ftp
ipa hbacrule-add-service --hbacsvcgroups=ftpers john_ftp

Disable a named HBAC rule:
ipa hbacrule-disable test1

Remove a named HBAC rule:
ipa hbacrule-del allow_server

호스트-기반 접근 제어

Control who can access what services on what hosts. You
can use HBAC to control which users or groups can
access a service, or group of services, on a target host.

You can also specify a category of users and target hosts.
This is currently limited to "all", but might be expanded in the
future.

Target hosts in HBAC rules must be hosts managed by IPA.

The available services and groups of services are controlled by the
hbacsvc and hbacsvcgroup plug-ins respectively.

EXAMPLES:

Create a rule, "test1", that grants all users access to the host "server" from
anywhere:
ipa hbacrule-add --usercat=all test1
ipa hbacrule-add-host --hosts=server.example.com test1

Display the properties of a named HBAC rule:
ipa hbacrule-show test1

Create a rule for a specific service. This lets the user john access
the sshd service on any machine from any machine:
ipa hbacrule-add --hostcat=all john_sshd
ipa hbacrule-add-user --users=john john_sshd
ipa hbacrule-add-service --hbacsvcs=sshd john_sshd

Create a rule for a new service group. This lets the user john access
the FTP service on any machine from any machine:
ipa hbacsvcgroup-add ftpers
ipa hbacsvc-add sftp
ipa hbacsvcgroup-add-member --hbacsvcs=ftp --hbacsvcs=sftp ftpers
ipa hbacrule-add --hostcat=all john_ftp
ipa hbacrule-add-user --users=john john_ftp
ipa hbacrule-add-service --hbacsvcgroups=ftpers john_ftp

Disable a named HBAC rule:
ipa hbacrule-disable test1

Remove a named HBAC rule:
ipa hbacrule-del allow_server
a month ago
User avatar anonymous

Suggestion added

  1. freeipa
  2. ipa-4-9
  3. Korean

Group to Group Delegation

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.

Group to Group Delegations grants the members of one group to update a set
of attributes of members of another group.

EXAMPLES:

Add a delegation rule to allow managers to edit employee's addresses:
ipa delegation-add --attrs=street --group=managers --membergroup=employees "managers edit employees' street"

When managing the list of attributes you need to include all attributes
in the list, including existing ones. Add postalCode to the list:
ipa delegation-mod --attrs=street,postalCode --group=managers --membergroup=employees "managers edit employees' street"

Display our updated rule:
ipa delegation-show "managers edit employees' street"

Delete a rule:
ipa delegation-del "managers edit employees' street"

그룹간 위임

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.

Group to Group Delegations grants the members of one group to update a set
of attributes of members of another group.

예제:

Add a delegation rule to allow managers to edit employee's addresses:
ipa delegation-add --attrs=street --group=managers --membergroup=employees "managers edit employees' street"

When managing the list of attributes you need to include all attributes
in the list, including existing ones. Add postalCode to the list:
ipa delegation-mod --attrs=street --attrs=postalCode --group=managers --membergroup=employees "managers edit employees' street"

Display our updated rule:
ipa delegation-show "managers edit employees' street"

Delete a rule:
ipa delegation-del "managers edit employees' street"
a month ago
User avatar anonymous

Suggestion added

  1. freeipa
  2. ipa-4-9
  3. Korean

Directory Server Access Control Instructions (ACIs)

ACIs are used to allow or deny access to information. This module is
currently designed to allow, not deny, access.

The aci commands are designed to grant permissions that allow updating
existing entries or adding or deleting new ones. The goal of the ACIs
that ship with IPA is to provide a set of low-level permissions that
grant access to special groups called taskgroups. These low-level
permissions can be combined into roles that grant broader access. These
roles are another type of group, roles.

For example, if you have taskgroups that allow adding and modifying users you
could create a role, useradmin. You would assign users to the useradmin
role to allow them to do the operations defined by the taskgroups.

You can create ACIs that delegate permission so users in group A can write
attributes on group B.

The type option is a map that applies to all entries in the users, groups or
host location. It is primarily designed to be used when granting add
permissions (to write new entries).

An ACI consists of three parts:
1. target
2. permissions
3. bind rules

The target is a set of rules that define which LDAP objects are being
targeted. This can include a list of attributes, an area of that LDAP
tree or an LDAP filter.

The targets include:
- attrs: list of attributes affected
- type: an object type (user, group, host, service, etc)
- memberof: members of a group
- targetgroup: grant access to modify a specific group. This is primarily
designed to enable users to add or remove members of a specific group.
- filter: A legal LDAP filter used to narrow the scope of the target.
- subtree: Used to apply a rule across an entire set of objects. For example,
to allow adding users you need to grant "add" permission to the subtree
ldap://uid=*,cn=users,cn=accounts,dc=example,dc=com. The subtree option
is a fail-safe for objects that may not be covered by the type option.

The permissions define what the ACI is allowed to do, and are one or
more of:
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

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.

The bind rule defines who this ACI grants permissions to. The LDAP server
allows this to be any valid LDAP entry but we encourage the use of
taskgroups so that the rights can be easily shared through roles.

For a more thorough description of access controls see
http://www.redhat.com/docs/manuals/dir-server/ag/8.0/Managing_Access_Control.html

EXAMPLES:

NOTE: ACIs are now added via the permission plugin. These examples are to
demonstrate how the various options work but this is done via the permission
command-line now (see last example).

Add an ACI so that the group "secretaries" can update the address on any user:
ipa group-add --desc="Office secretaries" secretaries
ipa aci-add --attrs=streetAddress --memberof=ipausers --group=secretaries --permissions=write --prefix=none "Secretaries write addresses"

Show the new ACI:
ipa aci-show --prefix=none "Secretaries write addresses"

Add an ACI that allows members of the "addusers" permission to add new users:
ipa aci-add --type=user --permission=addusers --permissions=add --prefix=none "Add new users"

Add an ACI that allows members of the editors manage members of the admins group:
ipa aci-add --permissions=write --attrs=member --targetgroup=admins --group=editors --prefix=none "Editors manage admins"

Add an ACI that allows members of the admins group to manage the street and zip code of those in the editors group:
ipa aci-add --permissions=write --memberof=editors --group=admins --attrs=street,postalcode --prefix=none "admins edit the address of editors"

Add an ACI that allows the admins group manage the street and zipcode of those who work for the boss:
ipa aci-add --permissions=write --group=admins --attrs=street,postalcode --filter="(manager=uid=boss,cn=users,cn=accounts,dc=example,dc=com)" --prefix=none "Edit the address of those who work for the boss"

Add an entirely new kind of record to IPA that isn't covered by any of the --type options, creating a permission:
ipa permission-add --permissions=add --subtree="cn=*,cn=orange,cn=accounts,dc=example,dc=com" --desc="Add Orange Entries" add_orange


The show command shows the raw 389-ds ACI.

IMPORTANT: When modifying the target attributes of an existing ACI you
must include all existing attributes as well. When doing an aci-mod the
targetattr REPLACES the current attributes, it does not add to them.

Directory Server Access Control Instructions (ACIs)

ACIs are used to allow or deny access to information. This module is
currently designed to allow, not deny, access.

The aci commands are designed to grant permissions that allow updating
existing entries or adding or deleting new ones. The goal of the ACIs
that ship with IPA is to provide a set of low-level permissions that
grant access to special groups called taskgroups. These low-level
permissions can be combined into roles that grant broader access. These
roles are another type of group, roles.

For example, if you have taskgroups that allow adding and modifying users you
could create a role, useradmin. You would assign users to the useradmin
role to allow them to do the operations defined by the taskgroups.

You can create ACIs that delegate permission so users in group A can write
attributes on group B.

The type option is a map that applies to all entries in the users, groups or
host location. It is primarily designed to be used when granting add
permissions (to write new entries).

An ACI consists of three parts:
1. target
2. permissions
3. bind rules

The target is a set of rules that define which LDAP objects are being
targeted. This can include a list of attributes, an area of that LDAP
tree or an LDAP filter.

The targets include:
- attrs: list of attributes affected
- type: an object type (user, group, host, service, etc)
- memberof: members of a group
- targetgroup: grant access to modify a specific group. This is primarily
designed to enable users to add or remove members of a specific group.
- filter: A legal LDAP filter used to narrow the scope of the target.
- subtree: Used to apply a rule across an entire set of objects. For example,
to allow adding users you need to grant "add" permission to the subtree
ldap://uid=*,cn=users,cn=accounts,dc=example,dc=com. The subtree option
is a fail-safe for objects that may not be covered by the type option.

The permissions define what the ACI is allowed to do, and are one or
more of:
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

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.

The bind rule defines who this ACI grants permissions to. The LDAP server
allows this to be any valid LDAP entry but we encourage the use of
taskgroups so that the rights can be easily shared through roles.

For a more thorough description of access controls see
http://www.redhat.com/docs/manuals/dir-server/ag/8.0/Managing_Access_Control.html

EXAMPLES:

NOTE: ACIs are now added via the permission plugin. These examples are to
demonstrate how the various options work but this is done via the permission
command-line now (see last example).

Add an ACI so that the group "secretaries" can update the address on any user:
ipa group-add --desc="Office secretaries" secretaries
ipa aci-add --attrs=streetAddress --memberof=ipausers --group=secretaries --permissions=write --prefix=none "Secretaries write addresses"

Show the new ACI:
ipa aci-show --prefix=none "Secretaries write addresses"

Add an ACI that allows members of the "addusers" permission to add new users:
ipa aci-add --type=user --permission=addusers --permissions=add --prefix=none "Add new users"

Add an ACI that allows members of the editors manage members of the admins group:
ipa aci-add --permissions=write --attrs=member --targetgroup=admins --group=editors --prefix=none "Editors manage admins"

Add an ACI that allows members of the admins group to manage the street and zip code of those in the editors group:
ipa aci-add --permissions=write --memberof=editors --group=admins --attrs=street --attrs=postalcode --prefix=none "admins edit the address of editors"

Add an ACI that allows the admins group manage the street and zipcode of those who work for the boss:
ipa aci-add --permissions=write --group=admins --attrs=street --attrs=postalcode --filter="(manager=uid=boss,cn=users,cn=accounts,dc=example,dc=com)" --prefix=none "Edit the address of those who work for the boss"

Add an entirely new kind of record to IPA that isn't covered by any of the --type options, creating a permission:
ipa permission-add --permissions=add --subtree="cn=*,cn=orange,cn=accounts,dc=example,dc=com" --desc="Add Orange Entries" add_orange


The show command shows the raw 389-ds ACI.

IMPORTANT: When modifying the target attributes of an existing ACI you
must include all existing attributes as well. When doing an aci-mod the
targetattr REPLACES the current attributes, it does not add to them.
a month ago
User avatar None

Changes committed

  1. freeipa
  2. ipa-4-9
  3. Korean
Changes committed 2 months ago
User avatar simmon

Translation added

  1. freeipa
  2. ipa-4-9
  3. Korean
force host name even if not in DNS
만약 DNS에 없더라도 호스트 이름을 강제합니다
2 months ago
User avatar simmon

Translation added

  1. freeipa
  2. ipa-4-9
  3. Korean
Client credentials may be delegated to the service
클라이언트 자격 증명이 서비스로 위임 될 수 있습니다
2 months ago
User avatar simmon

Translation added

  1. freeipa
  2. ipa-4-9
  3. Korean
Trusted for delegation
위임을 위해 신뢰됨
2 months ago
User avatar simmon

Translation added

  1. freeipa
  2. ipa-4-9
  3. Korean
Pre-authentication is required for the service
사전-인증은 서비스를 위해 필요합니다
2 months ago
Browse all component changes