pveum.adoc

   1 [[chapter_user_management]]
   2 ifdef::manvolnum[]
   3 pveum(1)
   4 ========
   5 :pve-toplevel:
   6
   7 NAME
   8 ----
   9
  10 pveum - Proxmox VE User Manager
  11
  12
  13 SYNOPSIS
  14 --------
  15
  16 include::pveum.1-synopsis.adoc[]
  17
  18
  19 DESCRIPTION
  20 -----------
  21 endif::manvolnum[]
  22 ifndef::manvolnum[]
  23 User Management
  24 ===============
  25 :pve-toplevel:
  26 endif::manvolnum[]
  27
  28 // Copied from pve wiki: Revision as of 16:10, 27 October 2015
  29
  30 Proxmox VE supports multiple authentication sources, e.g. Linux PAM,
  31 an integrated Proxmox VE authentication server, LDAP, Microsoft Active
  32 Directory.
  33
  34 By using the role based user- and permission management for all
  35 objects (VMs, storages, nodes, etc.) granular access can be defined.
  36
  37
  38 [[pveum_users]]
  39 Users
  40 -----
  41
  42 {pve} stores user attributes in `/etc/pve/user.cfg`.
  43 Passwords are not stored here, users are instead associated with
  44 <<pveum_authentication_realms,authentication realms>> described below.
  45 Therefore a user is internally often identified by its name and
  46 realm in the form `<userid>@<realm>`.
  47
  48 Each user entry in this file contains the following information:
  49
  50 * First name
  51 * Last name
  52 * E-mail address
  53 * Group memberships
  54 * An optional Expiration date
  55 * A comment or note about this user
  56 * Whether this user is enabled or disabled
  57 * Optional two factor authentication keys
  58
  59
  60 System administrator
  61 ~~~~~~~~~~~~~~~~~~~~
  62
  63 The system's root user can always log in via the Linux PAM realm and is an
  64 unconfined administrator. This user cannot be deleted, but attributes can
  65 still be changed and system mails will be sent to the email address
  66 assigned to this user.
  67
  68
  69 [[pveum_groups]]
  70 Groups
  71 ~~~~~~
  72
  73 Each user can be member of several groups. Groups are the preferred
  74 way to organize access permissions. You should always grant permission
  75 to groups instead of using individual users. That way you will get a
  76 much shorter access control list which is easier to handle.
  77
  78
  79 [[pveum_authentication_realms]]
  80 Authentication Realms
  81 ---------------------
  82
  83 As {pve} users are just counterparts for users existing on some external
  84 realm, the realms have to be configured in `/etc/pve/domains.cfg`.
  85 The following realms (authentication methods) are available:
  86
  87 Linux PAM standard authentication::
  88 In this case a system user has to exist (e.g. created via the `adduser`
  89 command) on all nodes the user is allowed to login, and the user
  90 authenticates with their usual system password.
  91 +
  92 [source,bash]
  93 ----
  94 useradd heinz
  95 passwd heinz
  96 groupadd watchman
  97 usermod -a -G watchman heinz
  98 ----
  99
 100 Proxmox VE authentication server::
 101 This is a unix like password store (`/etc/pve/priv/shadow.cfg`).
 102 Password are encrypted using the SHA-256 hash method.
 103 This is the most convenient method for small (or even medium)
 104 installations where users do not need access to anything outside of
 105 {pve}. In this case users are fully managed by {pve} and are able to
 106 change their own passwords via the GUI.
 107
 108 LDAP::
 109 It is possible to authenticate users via an LDAP server (e.g.
 110 openldap). The server and an optional fallback server can be
 111 configured and the connection can be encrypted via SSL.
 112 +
 113 Users are searched under a 'Base Domain Name' (`base_dn`), with the
 114 user name found in the attribute specified in the 'User Attribute Name'
 115 (`user_attr`) field.
 116 +
 117 For instance, if a user is represented via the
 118 following ldif dataset:
 119 +
 120 ----
 121 # user1 of People at ldap-test.com
 122 dn: uid=user1,ou=People,dc=ldap-test,dc=com
 123 objectClass: top
 124 objectClass: person
 125 objectClass: organizationalPerson
 126 objectClass: inetOrgPerson
 127 uid: user1
 128 cn: Test User 1
 129 sn: Testers
 130 description: This is the first test user.
 131 ----
 132 +
 133 The 'Base Domain Name' would be `ou=People,dc=ldap-test,dc=com` and the user
 134 attribute would be `uid`.
 135 +
 136 If {pve} needs to authenticate (bind) to the ldap server before being
 137 able to query and authenticate users, a bind domain name can be
 138 configured via the `bind_dn` property in `/etc/pve/domains.cfg`. Its
 139 password then has to be stored in `/etc/pve/priv/ldap/<realmname>.pw`
 140 (e.g. `/etc/pve/priv/ldap/my-ldap.pw`). This file should contain a
 141 single line containing the raw password.
 142
 143 Microsoft Active Directory::
 144
 145 A server and authentication domain need to be specified. Like with
 146 ldap an optional fallback server, optional port, and SSL
 147 encryption can be configured.
 148
 149
 150 [[pveum_tfa_auth]]
 151 Two factor authentication
 152 -------------------------
 153
 154 There are two ways to use two factor authentication:
 155
 156 It can be required by the authentication realm, either via 'TOTP' or
 157 'YubiKey OTP'. In this case a newly created user needs their keys added
 158 immediately as there is no way to log in without the second factor. In the case
 159 of 'TOTP' a user can also change the 'TOTP' later on provided they can log in
 160 first.
 161
 162 Alternatively a user can choose to opt into two factor authentication via 'TOTP'
 163 later on even if the realm does not enforce it. As another option, if the server
 164 has an 'AppId' configured, a user can opt into 'U2F' authentication, provided
 165 the realm does not enforce any other second factor.
 166
 167 Realm enforced two factor authentication
 168 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 169
 170 This can be done by selecting one of the available methods
 171 via the 'TFA' dropdown box when adding or editing an Authentication Realm.
 172 When a realm has TFA enabled it becomes a requirement and only users with
 173 configured TFA will be able to login.
 174
 175 Currently there are two methods available:
 176
 177 Time based OATH (TOTP)::
 178 This uses the standard HMAC-SHA1 algorithm where the current time is hashed
 179 with the user's configured key. The time step and password length
 180 parameters are configured.
 181 +
 182 A user can have multiple keys configured (separated by spaces), and the
 183 keys can be specified in Base32 (RFC3548) or hexadecimal notation.
 184 +
 185 {pve} provides a key generation tool (`oathkeygen`) which prints out a
 186 random key in Base32 notation which can be used directly with various OTP
 187 tools, such as the `oathtool` command line tool, the Google authenticator
 188 or FreeOTP Android apps.
 189
 190 YubiKey OTP::
 191 For authenticating via a YubiKey a Yubico API ID, API KEY and validation
 192 server URL must be configured, and users must have a YubiKey available. In
 193 order to get the key ID from a YubiKey, you can trigger the YubiKey once
 194 after connecting it to USB and copy the first 12 characters of the typed
 195 password into the user's 'Key IDs' field.
 196 +
 197 Please refer to the
 198 https://developers.yubico.com/OTP/[YubiKey OTP] documentation for how to use the
 199 https://www.yubico.com/products/services-software/yubicloud/[YubiCloud] or
 200 https://developers.yubico.com/Software_Projects/YubiKey_OTP/YubiCloud_Validation_Servers/[
 201 host your own verification server].
 202
 203 [[pveum_user_configured_totp]]
 204 User configured TOTP authentication
 205 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 206
 207 A user can choose to use 'TOTP' as a second factor on login via the 'TFA' button
 208 in the user list, unless the realm enforces 'YubiKey OTP'.
 209
 210 [thumbnail="screenshot/gui-datacenter-users-tfa.png"]
 211
 212 After opening the 'TFA' window, the user is presented with a dialog to setup
 213 'TOTP' authentication. The 'Secret' field contains the key, which can simply be
 214 generated randomly via the 'Randomize' button. An optional 'Issuer Name' can be
 215 added to provide information to the 'TOTP' app what the key belongs to.
 216 Most 'TOTP' apps will show the issuer name together with the corresponding
 217 'OTP' values. The user name is also included in the QR code for the 'TOTP' app.
 218
 219 After generating a key, a QR code will be displayed which can be used with most
 220 OTP apps such as FreeOTP. Now the user needs to verify both the current user
 221 password (unless logged in as 'root'), as well as the ability to correctly use
 222 the 'TOTP' key by typing the current 'OTP' value into the 'Verification Code'
 223 field before pressing the 'Apply' button.
 224
 225 [[pveum_configure_u2f]]
 226 Server side U2F configuration
 227 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 228
 229 To allow users to use 'U2F' authentication, the server needs to have a valid
 230 domain with a valid https certificate. Initially an 'AppId'
 231 footnote:[AppId https://developers.yubico.com/U2F/App_ID.html]
 232 needs to be configured.
 233
 234 NOTE: Changing the 'AppId' will render all existing 'U2F' registrations
 235 unusable!
 236
 237 This is done via `/etc/pve/datacenter.cfg`, for instance:
 238
 239 ----
 240 u2f: appid=https://mypve.example.com:8006
 241 ----
 242
 243 For a single node, the 'AppId' can simply be the web UI address exactly as it
 244 is used in the browser, including the 'https://' and the port as shown above.
 245 Please note that some browsers may be more strict than others when matching
 246 'AppIds'.
 247
 248 When using multiple nodes, it is best to have a separate `https` server
 249 providing an `appid.json`
 250 footnote:[Multi-facet apps: https://developers.yubico.com/U2F/App_ID.html]
 251 file, as it seems to be compatible with most
 252 browsers. If all nodes use subdomains of the same top level domain, it may be
 253 enough to use the TLD as 'AppId', but note that some browsers may not accept
 254 this.
 255
 256 NOTE: A bad 'AppId' will usually produce an error, but we have encountered
 257 situation where this does not happen, particularly when using a top level domain
 258 'AppId' for a node accessed via a subdomain in Chromium. For this reason it is
 259 recommended to test the configuration with multiple browsers, as changing the
 260 'AppId' later will render existing 'U2F' registrations unusable.
 261
 262 [[pveum_user_configured_u2f]]
 263 Activating U2F as a user
 264 ~~~~~~~~~~~~~~~~~~~~~~~~
 265
 266 To enable 'U2F' authentication, open the 'TFA' window's 'U2F' tab, type in the
 267 current password (unless logged in as root), and press the 'Register' button.
 268 If the server is setup correctly and the browser accepted the server's provided
 269 'AppId', a message will appear prompting the user to press the button on the
 270 'U2F' device (if it is a 'YubiKey' the button light should be toggling off and
 271 on steadily around twice per second).
 272
 273 Firefox users may need to enable 'security.webauth.u2f' via 'about:config'
 274 before they can use a 'U2F' token.
 275
 276 [[pveum_permission_management]]
 277 Permission Management
 278 ---------------------
 279
 280 In order for a user to perform an action (such as listing, modifying or
 281 deleting a parts of a VM configuration), the user needs to have the
 282 appropriate permissions.
 283
 284 {pve} uses a role and path based permission management system. An entry in
 285 the permissions table allows a user or group to take on a specific role
 286 when accessing an 'object' or 'path'. This means an such an access rule can
 287 be represented as a triple of '(path, user, role)' or '(path, group,
 288 role)', with the role containing a set of allowed actions, and the path
 289 representing the target of these actions.
 290
 291
 292 [[pveum_roles]]
 293 Roles
 294 ~~~~~
 295
 296 A role is simply a list of privileges. Proxmox VE comes with a number
 297 of predefined roles which satisfies most needs.
 298
 299 * `Administrator`: has all privileges
 300 * `NoAccess`: has no privileges (used to forbid access)
 301 * `PVEAdmin`: can do most things, but miss rights to modify system settings (`Sys.PowerMgmt`, `Sys.Modify`, `Realm.Allocate`).
 302 * `PVEAuditor`: read only access
 303 * `PVEDatastoreAdmin`: create and allocate backup space and templates
 304 * `PVEDatastoreUser`: allocate backup space and view storage
 305 * `PVEPoolAdmin`: allocate pools
 306 * `PVESysAdmin`: User ACLs, audit, system console and system logs
 307 * `PVETemplateUser`: view and clone templates
 308 * `PVEUserAdmin`: user administration
 309 * `PVEVMAdmin`: fully administer VMs
 310 * `PVEVMUser`: view, backup, config CDROM, VM console, VM power management
 311
 312 You can see the whole set of predefined roles on the GUI.
 313
 314 Adding new roles can be done via both GUI and the command line.
 315
 316 [thumbnail="screenshot/gui-datacenter-role-add.png"]
 317 For the GUI just navigate to 'Permissions -> User' Tab from 'Datacenter' and
 318 click on the 'Create' button, there you can set a name and select all desired
 319 roles from the 'Privileges' dropdown box.
 320
 321 To add a role through the command line you can use the 'pveum' CLI tool, like
 322 this:
 323 [source,bash]
 324 ----
 325 pveum roleadd PVE_Power-only -privs "VM.PowerMgmt VM.Console"
 326 pveum roleadd Sys_Power-only -privs "Sys.PowerMgmt Sys.Console"
 327 ----
 328
 329
 330 Privileges
 331 ~~~~~~~~~~
 332
 333 A privilege is the right to perform a specific action. To simplify
 334 management, lists of privileges are grouped into roles, which can then
 335 be used in the permission table. Note that privileges cannot directly be
 336 assigned to users and paths without being part of a role.
 337
 338 We currently use the following privileges:
 339
 340 Node / System related privileges::
 341
 342 * `Permissions.Modify`: modify access permissions
 343 * `Sys.PowerMgmt`: Node power management (start, stop, reset, shutdown, ...)
 344 * `Sys.Console`: console access to Node
 345 * `Sys.Syslog`: view Syslog
 346 * `Sys.Audit`: view node status/config, Corosync cluster config and HA config
 347 * `Sys.Modify`: create/remove/modify node network parameters
 348 * `Group.Allocate`: create/remove/modify groups
 349 * `Pool.Allocate`: create/remove/modify a pool
 350 * `Realm.Allocate`: create/remove/modify authentication realms
 351 * `Realm.AllocateUser`: assign user to a realm
 352 * `User.Modify`: create/remove/modify user access and details.
 353
 354 Virtual machine related privileges::
 355
 356 * `VM.Allocate`: create/remove new VM to server inventory
 357 * `VM.Migrate`: migrate VM to alternate server on cluster
 358 * `VM.PowerMgmt`: power management (start, stop, reset, shutdown, ...)
 359 * `VM.Console`: console access to VM
 360 * `VM.Monitor`: access to VM monitor (kvm)
 361 * `VM.Backup`: backup/restore VMs
 362 * `VM.Audit`: view VM config
 363 * `VM.Clone`: clone/copy a VM
 364 * `VM.Config.Disk`: add/modify/delete Disks
 365 * `VM.Config.CDROM`: eject/change CDROM
 366 * `VM.Config.CPU`: modify CPU settings
 367 * `VM.Config.Memory`: modify Memory settings
 368 * `VM.Config.Network`: add/modify/delete Network devices
 369 * `VM.Config.HWType`: modify emulated HW type
 370 * `VM.Config.Options`: modify any other VM configuration
 371 * `VM.Snapshot`: create/remove VM snapshots
 372
 373 Storage related privileges::
 374
 375 * `Datastore.Allocate`: create/remove/modify a data store, delete volumes
 376 * `Datastore.AllocateSpace`: allocate space on a datastore
 377 * `Datastore.AllocateTemplate`: allocate/upload templates and iso images
 378 * `Datastore.Audit`: view/browse a datastore
 379
 380
 381 Objects and Paths
 382 ~~~~~~~~~~~~~~~~~
 383
 384 Access permissions are assigned to objects, such as a virtual machines,
 385 storages or pools of resources.
 386 We use file system like paths to address these objects. These paths form a
 387 natural tree, and permissions of higher levels (shorter path) can
 388 optionally be propagated down within this hierarchy.
 389
 390 [[pveum_templated_paths]]
 391 Paths can be templated. When an API call requires permissions on a
 392 templated path, the path may contain references to parameters of the API
 393 call. These references are specified in curly braces. Some parameters are
 394 implicitly taken from the API call's URI. For instance the permission path
 395 `/nodes/{node}` when calling '/nodes/mynode/status' requires permissions on
 396 `/nodes/mynode`, while the path `{path}` in a PUT request to `/access/acl`
 397 refers to the method's `path` parameter.
 398
 399 Some examples are:
 400
 401 * `/nodes/{node}`: Access to {pve} server machines
 402 * `/vms`: Covers all VMs
 403 * `/vms/{vmid}`: Access to specific VMs
 404 * `/storage/{storeid}`: Access to a storages
 405 * `/pool/{poolname}`: Access to VMs part of a <<pveum_pools,pool>>
 406 * `/access/groups`: Group administration
 407 * `/access/realms/{realmid}`: Administrative access to realms
 408
 409
 410 Inheritance
 411 ^^^^^^^^^^^
 412
 413 As mentioned earlier, object paths form a file system like tree, and
 414 permissions can be inherited down that tree (the propagate flag is set
 415 by default). We use the following inheritance rules:
 416
 417 * Permissions for individual users always replace group permissions.
 418 * Permissions for groups apply when the user is member of that group.
 419 * Permissions replace the ones inherited from an upper level.
 420
 421
 422 [[pveum_pools]]
 423 Pools
 424 ~~~~~
 425
 426 Pools can be used to group a set of virtual machines and data
 427 stores. You can then simply set permissions on pools (`/pool/{poolid}`),
 428 which are inherited to all pool members. This is a great way simplify
 429 access control.
 430
 431
 432 What permission do I need?
 433 ~~~~~~~~~~~~~~~~~~~~~~~~~~
 434
 435 The required API permissions are documented for each individual
 436 method, and can be found at http://pve.proxmox.com/pve-docs/api-viewer/
 437
 438 The permissions are specified as a list which can be interpreted as a
 439 tree of logic and access-check functions:
 440
 441 `["and", <subtests>...]` and `["or", <subtests>...]`::
 442 Each(`and`) or any(`or`) further element in the current list has to be true.
 443
 444 `["perm", <path>, [ <privileges>... ], <options>...]`::
 445 The `path` is a templated parameter (see
 446 <<pveum_templated_paths,Objects and Paths>>). All (or, if the `any`
 447 option is used, any) of the listed
 448 privileges must be allowed on the specified path. If a `require-param`
 449 option is specified, then its specified parameter is required even if the
 450 API call's schema otherwise lists it as being optional.
 451
 452 `["userid-group", [ <privileges>... ], <options>...]`::
 453 The caller must have any of the listed privileges on `/access/groups`. In
 454 addition there are two possible checks depending on whether the
 455 `groups_param` option is set:
 456 +
 457 * `groups_param` is set: The API call has a non-optional `groups` parameter
 458 and the caller must have any of the listed privileges on all of the listed
 459 groups.
 460 * `groups_param` is not set: The user passed via the `userid` parameter
 461 must exist and be part of a group on which the caller has any of the listed
 462 privileges (via the `/access/groups/<group>` path).
 463
 464 `["userid-param", "self"]`::
 465 The value provided for the API call's `userid` parameter must refer to the
 466 user performing the action. (Usually in conjunction with `or`, to allow
 467 users to perform an action on themselves even if they don't have elevated
 468 privileges.)
 469
 470 `["userid-param", "Realm.AllocateUser"]`::
 471 The user needs `Realm.AllocateUser` access to `/access/realm/<realm>`, with
 472 `<realm>` referring to the realm of the user passed via the `userid`
 473 parameter. Note that the user does not need to exist in order to be
 474 associated with a realm, since user IDs are passed in the form of
 475 `<username>@<realm>`.
 476
 477 `["perm-modify", <path>]`::
 478 The `path` is a templated parameter (see
 479 <<pveum_templated_paths,Objects and Paths>>). The user needs either the
 480 `Permissions.Modify` privilege, or,
 481 depending on the path, the following privileges as a possible substitute:
 482 +
 483 * `/storage/...`: additionally requires 'Datastore.Allocate`
 484 * `/vms/...`: additionally requires 'VM.Allocate`
 485 * `/pool/...`: additionally requires 'Pool.Allocate`
 486 +
 487 If the path is empty, `Permission.Modify` on `/access` is required.
 488
 489 Command Line Tool
 490 -----------------
 491
 492 Most users will simply use the GUI to manage users. But there is also
 493 a fully featured command line tool called `pveum` (short for ``**P**roxmox
 494 **VE** **U**ser **M**anager''). Please note that all Proxmox VE command
 495 line tools are wrappers around the API, so you can also access those
 496 functions through the REST API.
 497
 498 Here are some simple usage examples. To show help type:
 499
 500 [source,bash]
 501  pveum
 502
 503 or (to show detailed help about a specific command)
 504
 505 [source,bash]
 506  pveum help useradd
 507
 508 Create a new user:
 509
 510 [source,bash]
 511  pveum useradd testuser@pve -comment "Just a test"
 512
 513 Set or Change the password (not all realms support that):
 514
 515 [source,bash]
 516  pveum passwd testuser@pve
 517
 518 Disable a user:
 519
 520 [source,bash]
 521  pveum usermod testuser@pve -enable 0
 522
 523 Create a new group:
 524
 525 [source,bash]
 526  pveum groupadd testgroup
 527
 528 Create a new role:
 529
 530 [source,bash]
 531  pveum roleadd PVE_Power-only -privs "VM.PowerMgmt VM.Console"
 532
 533
 534 Real World Examples
 535 -------------------
 536
 537
 538 Administrator Group
 539 ~~~~~~~~~~~~~~~~~~~
 540
 541 One of the most wanted features was the ability to define a group of
 542 users with full administrator rights (without using the root account).
 543
 544 Define the group:
 545
 546 [source,bash]
 547  pveum groupadd admin -comment "System Administrators"
 548
 549 Then add the permission:
 550
 551 [source,bash]
 552  pveum aclmod / -group admin -role Administrator
 553
 554 You can finally add users to the new 'admin' group:
 555
 556 [source,bash]
 557  pveum usermod testuser@pve -group admin
 558
 559
 560 Auditors
 561 ~~~~~~~~
 562
 563 You can give read only access to users by assigning the `PVEAuditor`
 564 role to users or groups.
 565
 566 Example1: Allow user `joe@pve` to see everything
 567
 568 [source,bash]
 569  pveum aclmod / -user joe@pve -role PVEAuditor
 570
 571 Example1: Allow user `joe@pve` to see all virtual machines
 572
 573 [source,bash]
 574  pveum aclmod /vms -user joe@pve -role PVEAuditor
 575
 576
 577 Delegate User Management
 578 ~~~~~~~~~~~~~~~~~~~~~~~~
 579
 580 If you want to delegate user management to user `joe@pve` you can do
 581 that with:
 582
 583 [source,bash]
 584  pveum aclmod /access -user joe@pve -role PVEUserAdmin
 585
 586 User `joe@pve` can now add and remove users, change passwords and
 587 other user attributes. This is a very powerful role, and you most
 588 likely want to limit that to selected realms and groups. The following
 589 example allows `joe@pve` to modify users within realm `pve` if they
 590 are members of group `customers`:
 591
 592 [source,bash]
 593  pveum aclmod /access/realm/pve -user joe@pve -role PVEUserAdmin
 594  pveum aclmod /access/groups/customers -user joe@pve -role PVEUserAdmin
 595
 596 NOTE: The user is able to add other users, but only if they are
 597 members of group `customers` and within realm `pve`.
 598
 599
 600 Pools
 601 ~~~~~
 602
 603 An enterprise is usually structured into several smaller departments,
 604 and it is common that you want to assign resources to them and
 605 delegate management tasks. A pool is simply a set of virtual machines
 606 and data stores. You can create pools on the GUI. After that you can
 607 add resources to the pool (VMs, Storage).
 608
 609 You can also assign permissions to the pool. Those permissions are
 610 inherited to all pool members.
 611
 612 Lets assume you have a software development department, so we first
 613 create a group
 614
 615 [source,bash]
 616  pveum groupadd developers -comment "Our software developers"
 617
 618 Now we create a new user which is a member of that group
 619
 620 [source,bash]
 621  pveum useradd developer1@pve -group developers -password
 622
 623 NOTE: The -password parameter will prompt you for a password
 624
 625 I assume we already created a pool called ``dev-pool'' on the GUI. So we can now assign permission to that pool:
 626
 627 [source,bash]
 628  pveum aclmod /pool/dev-pool/ -group developers -role PVEAdmin
 629
 630 Our software developers can now administrate the resources assigned to
 631 that pool.
 632
 633
 634 ifdef::manvolnum[]
 635 include::pve-copyright.adoc[]
 636 endif::manvolnum[]
 637