fixup: s/devies/devices/

[pve-docs.git] / pveum.adoc

diff --git a/pveum.adoc b/pveum.adoc
index cca1ece134424c00f1da067c743acc29f1db8e13..b0bb72afadd4c21f6252bb1ad1978a94947a9816 100644 (file)
--- a/pveum.adoc
+++ b/pveum.adoc
@@ -1,7 +1,8 @@
+[[chapter_user_management]]

 ifdef::manvolnum[]
 ifdef::manvolnum[]

-PVE({manvolnum})
-================
-include::attributes.txt[]
+pveum(1)
+========
+:pve-toplevel:

 
 NAME
 ----
 
 NAME
 ----


@@ -18,11 +19,10 @@ include::pveum.1-synopsis.adoc[]
 DESCRIPTION
 -----------
 endif::manvolnum[]
 DESCRIPTION
 -----------
 endif::manvolnum[]

-

 ifndef::manvolnum[]
 User Management
 ===============
 ifndef::manvolnum[]
 User Management
 ===============

-include::attributes.txt[]
+:pve-toplevel:

 endif::manvolnum[]
 
 // Copied from pve wiki: Revision as of 16:10, 27 October 2015
 endif::manvolnum[]
 
 // Copied from pve wiki: Revision as of 16:10, 27 October 2015


@@ -35,12 +35,13 @@ By using the role based user- and permission management for all
 objects (VMs, storages, nodes, etc.) granular access can be defined.
 
 
 objects (VMs, storages, nodes, etc.) granular access can be defined.
 
 

+[[pveum_users]]

 Users
 -----
 
 {pve} stores user attributes in `/etc/pve/user.cfg`.
 Passwords are not stored here, users are instead associated with
 Users
 -----
 
 {pve} stores user attributes in `/etc/pve/user.cfg`.
 Passwords are not stored here, users are instead associated with

-<<authentication-realms,authentication realms>> described below.
+<<pveum_authentication_realms,authentication realms>> described below.

 Therefore a user is internally often identified by its name and
 realm in the form `<userid>@<realm>`.
 
 Therefore a user is internally often identified by its name and
 realm in the form `<userid>@<realm>`.
 


@@ -65,6 +66,7 @@ still be changed and system mails will be sent to the email address
 assigned to this user.
 
 
 assigned to this user.
 
 

+[[pveum_groups]]

 Groups
 ~~~~~~
 
 Groups
 ~~~~~~
 


@@ -74,7 +76,7 @@ to groups instead of using individual users. That way you will get a
 much shorter access control list which is easier to handle.
 
 
 much shorter access control list which is easier to handle.
 
 

-[[authentication-realms]]
+[[pveum_authentication_realms]]

 Authentication Realms
 ---------------------
 
 Authentication Realms
 ---------------------
 


@@ -83,7 +85,7 @@ realm, the realms have to be configured in `/etc/pve/domains.cfg`.
 The following realms (authentication methods) are available:
 
 Linux PAM standard authentication::
 The following realms (authentication methods) are available:
 
 Linux PAM standard authentication::

-In this case a system user has to exist (eg. created via the `adduser`
+In this case a system user has to exist (e.g. created via the `adduser`

 command) on all nodes the user is allowed to login, and the user
 authenticates with their usual system password.
 +
 command) on all nodes the user is allowed to login, and the user
 authenticates with their usual system password.
 +


@@ -98,13 +100,13 @@ usermod -a -G watchman heinz
 Proxmox VE authentication server::
 This is a unix like password store (`/etc/pve/priv/shadow.cfg`).
 Password are encrypted using the SHA-256 hash method.
 Proxmox VE authentication server::
 This is a unix like password store (`/etc/pve/priv/shadow.cfg`).
 Password are encrypted using the SHA-256 hash method.

-This is the most convenient method for for small (or even medium)
+This is the most convenient method for small (or even medium)

 installations where users do not need access to anything outside of
 {pve}. In this case users are fully managed by {pve} and are able to
 change their own passwords via the GUI.
 
 LDAP::
 installations where users do not need access to anything outside of
 {pve}. In this case users are fully managed by {pve} and are able to
 change their own passwords via the GUI.
 
 LDAP::

-It is possible to authenticate users via an LDAP server (eq.
+It is possible to authenticate users via an LDAP server (e.g.

 openldap). The server and an optional fallback server can be
 configured and the connection can be encrypted via SSL.
 +
 openldap). The server and an optional fallback server can be
 configured and the connection can be encrypted via SSL.
 +


@@ -135,7 +137,7 @@ If {pve} needs to authenticate (bind) to the ldap server before being
 able to query and authenticate users, a bind domain name can be
 configured via the `bind_dn` property in `/etc/pve/domains.cfg`. Its
 password then has to be stored in `/etc/pve/priv/ldap/<realmname>.pw`
 able to query and authenticate users, a bind domain name can be
 configured via the `bind_dn` property in `/etc/pve/domains.cfg`. Its
 password then has to be stored in `/etc/pve/priv/ldap/<realmname>.pw`

-(eg. `/etc/pve/priv/ldap/my-ldap.pw`). This file should contain a
+(e.g. `/etc/pve/priv/ldap/my-ldap.pw`). This file should contain a

 single line containing the raw password.
 
 Microsoft Active Directory::
 single line containing the raw password.
 
 Microsoft Active Directory::


@@ -183,6 +185,7 @@ https://developers.yubico.com/Software_Projects/YubiKey_OTP/YubiCloud_Validation
 host your own verification server].
 
 
 host your own verification server].
 
 

+[[pveum_permission_management]]

 Permission Management
 ---------------------
 
 Permission Management
 ---------------------
 


@@ -198,6 +201,7 @@ role)', with the role containing a set of allowed actions, and the path
 representing the target of these actions.
 
 
 representing the target of these actions.
 
 

+[[pveum_roles]]

 Roles
 ~~~~~
 
 Roles
 ~~~~~
 


@@ -219,7 +223,7 @@ of predefined roles which satisfies most needs.
 
 You can see the whole set of predefined roles on the GUI.
 
 
 You can see the whole set of predefined roles on the GUI.
 

-Adding new roles can currently only be done from the command line, like
+Adding new roles can be done via both GUI and the command line, like

 this:
 
 [source,bash]
 this:
 
 [source,bash]


@@ -245,7 +249,7 @@ Node / System related privileges::
 * `Sys.PowerMgmt`: Node power management (start, stop, reset, shutdown, ...)
 * `Sys.Console`: console access to Node
 * `Sys.Syslog`: view Syslog
 * `Sys.PowerMgmt`: Node power management (start, stop, reset, shutdown, ...)
 * `Sys.Console`: console access to Node
 * `Sys.Syslog`: view Syslog

-* `Sys.Audit`: view node status/config
+* `Sys.Audit`: view node status/config, Corosync cluster config and HA config

 * `Sys.Modify`: create/remove/modify node network parameters
 * `Group.Allocate`: create/remove/modify groups
 * `Pool.Allocate`: create/remove/modify a pool
 * `Sys.Modify`: create/remove/modify node network parameters
 * `Group.Allocate`: create/remove/modify groups
 * `Pool.Allocate`: create/remove/modify a pool


@@ -289,7 +293,7 @@ We use file system like paths to address these objects. These paths form a
 natural tree, and permissions of higher levels (shorter path) can
 optionally be propagated down within this hierarchy.
 
 natural tree, and permissions of higher levels (shorter path) can
 optionally be propagated down within this hierarchy.
 

-[[templated-paths]]
+[[pveum_templated_paths]]

 Paths can be templated. When an API call requires permissions on a
 templated path, the path may contain references to parameters of the API
 call. These references are specified in curly braces. Some parameters are
 Paths can be templated. When an API call requires permissions on a
 templated path, the path may contain references to parameters of the API
 call. These references are specified in curly braces. Some parameters are


@@ -304,7 +308,7 @@ Some examples are:
 * `/vms`: Covers all VMs
 * `/vms/{vmid}`: Access to specific VMs
 * `/storage/{storeid}`: Access to a storages
 * `/vms`: Covers all VMs
 * `/vms/{vmid}`: Access to specific VMs
 * `/storage/{storeid}`: Access to a storages

-* `/pool/{poolname}`: Access to VMs part of a <<resource-pools,pool>
+* `/pool/{poolname}`: Access to VMs part of a <<pveum_pools,pool>>

 * `/access/groups`: Group administration
 * `/access/realms/{realmid}`: Administrative access to realms
 
 * `/access/groups`: Group administration
 * `/access/realms/{realmid}`: Administrative access to realms
 


@@ -321,6 +325,7 @@ by default). We use the following inheritance rules:
 * Permissions replace the ones inherited from an upper level.
 
 
 * Permissions replace the ones inherited from an upper level.
 
 

+[[pveum_pools]]

 Pools
 ~~~~~
 
 Pools
 ~~~~~
 


@@ -343,14 +348,15 @@ tree of logic and access-check functions:
 Each(`and`) or any(`or`) further element in the current list has to be true.
 
 `["perm", <path>, [ <privileges>... ], <options>...]`::
 Each(`and`) or any(`or`) further element in the current list has to be true.
 
 `["perm", <path>, [ <privileges>... ], <options>...]`::

-The `path` is a templated parameter (see <<templated-paths,Objects and
-Paths>>). All (or , if the `any` option is used, any) of the listed
+The `path` is a templated parameter (see
+<<pveum_templated_paths,Objects and Paths>>). All (or , if the `any`
+option is used, any) of the listed

 privileges must be allowed on the specified path. If a `require-param`
 option is specified, then its specified parameter is required even if the
 API call's schema otherwise lists it as being optional.
 
 `["userid-group", [ <privileges>... ], <options>...]`::
 privileges must be allowed on the specified path. If a `require-param`
 option is specified, then its specified parameter is required even if the
 API call's schema otherwise lists it as being optional.
 
 `["userid-group", [ <privileges>... ], <options>...]`::

-The callermust have any of the listed privileges on `/access/groups`. In
+The caller must have any of the listed privileges on `/access/groups`. In

 addition there are two possible checks depending on whether the
 `groups_param` option is set:
 +
 addition there are two possible checks depending on whether the
 `groups_param` option is set:
 +


@@ -369,14 +375,15 @@ privileges.)
 
 `["userid-param", "Realm.AllocateUser"]`::
 The user needs `Realm.AllocateUser` access to `/access/realm/<realm>`, with
 
 `["userid-param", "Realm.AllocateUser"]`::
 The user needs `Realm.AllocateUser` access to `/access/realm/<realm>`, with

-`<realm>` refering to the realm of the user passed via the `userid`
+`<realm>` referring to the realm of the user passed via the `userid`

 parameter. Note that the user does not need to exist in order to be
 associated with a realm, since user IDs are passed in the form of
 `<username>@<realm>`.
 
 `["perm-modify", <path>]`::
 parameter. Note that the user does not need to exist in order to be
 associated with a realm, since user IDs are passed in the form of
 `<username>@<realm>`.
 
 `["perm-modify", <path>]`::

-The `path` is a templated parameter (see <<templated-paths,Objects and
-Paths>>). The user needs either the `Permissions.Modify` privilege, or,
+The `path` is a templated parameter (see
+<<pveum_templated_paths,Objects and Paths>>). The user needs either the
+`Permissions.Modify` privilege, or,

 depending on the path, the following privileges as a possible substitute:
 +
 * `/storage/...`: additionally requires 'Datastore.Allocate`
 depending on the path, the following privileges as a possible substitute:
 +
 * `/storage/...`: additionally requires 'Datastore.Allocate`


@@ -476,7 +483,7 @@ Example1: Allow user `joe@pve` to see all virtual machines
 Delegate User Management
 ~~~~~~~~~~~~~~~~~~~~~~~~
 
 Delegate User Management
 ~~~~~~~~~~~~~~~~~~~~~~~~
 

-If you want to delegate user managenent to user `joe@pve` you can do
+If you want to delegate user management to user `joe@pve` you can do

 that with:
 
 [source,bash]
 that with:
 
 [source,bash]