Fix various issues.

Signed-off-by: Volker Theile <volker.theile@openmediavault.org>

administration/access_rights_management.rst

@@ -1,36 +1,57 @@
 Access Rights Management
 ########################
 
-In this section you can create and access information of |omv| users, groups and shared folders.
+In this section you can create and access information of |omv| users, groups
+and shared folders.
 
 User
 ====
+
 Create or modify users and configuration of home folders.
 
 Add
 ^^^^
 
 Information
-	The configuration panel gives you options to add, edit or remove users. When a user is created |omv| backend executes ``useradd`` in non-interactive mode with all the information passed from the text fields, this also creates an entry in ``/etc/passwd``, a hashed password in ``/etc/shadow`` and the corresponding password in the samba password database.
+	The configuration panel gives you options to add, edit or remove users.
+	When a user is created |omv| backend executes :command:`useradd` in
+	non-interactive mode with all the information passed from the text fields,
+	this also creates an entry in :file:`/etc/passwd`, a hashed password in
+	:file:`/etc/shadow` and the corresponding password in the samba password
+	database.
 
-	The mail field is used for cron jobs when the task is selected to run as specific user. By default users are created with ``/bin/nologin`` shell, this will prevent local and remote console access.
+	The mail field is used for cron jobs when the task is selected to run as
+	specific user. By default users are created with :command:`/bin/nologin`
+	shell, this will prevent local and remote console access.
 
 Group
-	Add or remove users from specific groups. In linux groups can be used to control access to certain features and also for permissions. Adding a user to the ``sudo`` group will give root privileges on shell or adding a user to ``saned`` will give user access to scanners. By default all users created in the |webui| are added to the ``users`` group (gid=100).
+	Add or remove users from specific groups. In linux groups can be used to
+	control access to certain features and also for permissions. Adding a user
+	to the ``sudo`` group will give root privileges on shell or adding a user
+	to ``saned`` will give user access to scanners. By default all users
+	created in the |webui| are added to the ``users`` group (``gid=100``).
 
 Public Key
 	Add or remove public keys for remote access for a user.
 
 .. :note:
-	- The user information information (except password) is also stored in the internal |omv|database, along with the public keys
-	- The grid parses information from the internal database and also from ``/etc/passwd`` entries with a uid higher than 1000. If you created a user in terminal then is not in the internal database. Just simply click edit and add some information to store in the internal database.
-	- A user can log into the web interface to see his own profile information. Depending if the adminstrator has setup the username account to allow changes, they can change their password and mail account.
-
+	- The user information information (except password) is also stored in the
+	  internal |omv|database, along with the public keys
+	- The grid parses information from the internal database and also from
+	  :file:`/etc/passwd` entries with a uid higher than 1000. If you created a
+	  user in terminal then is not in the internal database. Just simply click
+	  edit and add some information to store in the internal database.
+	- A user can log into the web interface to see his own profile information.
+	  Depending if the adminstrator has setup the username account to allow
+	  changes, they can change their password and mail account.
 
 Import
 ^^^^^^
 
-This can help when you need to bulk create users in one go. Create an spreadsheet with the corresponding data as described in the field text, save it as CSV (make sure the field separator is ``;``), then just simply::
+This can help when you need to bulk create users in one go. Create an
+spreadsheet with the corresponding data as described in the field text, save
+it as CSV (make sure the field separator is semicolon :code:`;`), then just
+simply::
 
 $ cat usersfile.csv
 
@@ -40,46 +61,64 @@ Example::
 	user2;1002;user2;user2@my.com;password2;;0
 	user3;1003;user3;user3@example.com;password3;;1
 
-Paste the contents into the import dialog. The last field is a boolean for allowing the user to change his account.
+Paste the contents into the import dialog. The last field is a boolean for
+allowing the user to change his account.
 
 Privileges
 ^^^^^^^^^^
 
-The button opens a windows that displays all current exisitng |sf| and their privileges for the particular user selected. How the privileges are stored is described further down in the |sf| `section <#shared-folder>`_
+The button opens a windows that displays all current exisiting |sf| and their
+privileges for the particular user selected. How the privileges are stored is
+described further down in the |sf| `section <#shared-folder>`_.
 
 Settings
 ^^^^^^^^
 
-This option is to select a shared folder as root folder for home folder. New users created in the |webui|. Existing users created before this setting was enabled will not have their home folders moved to that location. You can manually edit ``/etc/passwd`` to point them to the new location.
+This option is to select a shared folder as root folder for home folder. New
+users created in the |webui|. Existing users created before this setting was
+enabled will not have their home folders moved to that location. You can
+manually edit :file:`/etc/passwd` to point them to the new location.
 
 Group
 =====
 
 Add
 ^^^
 
-Create groups and select the members. You can select current |omv| users and system accounts. Information is stored in ``config.xml`` and ``/etc/group``.
+Create groups and select the members. You can select current |omv| users
+and system accounts. Information is stored in ``config.xml`` and
+:file:`/etc/group`.
 
 Import
 ^^^^^^
 
-Bulk import works in similar as user account import. Just a csv text, delimited with ``;``. The dialog displays the necessary fields.
+Bulk import works in similar as user account import. Just a csv text,
+delimited with a semicolon :code:`;`. The dialog displays the necessary
+fields.
 
 Edit
 ^^^^
-Just to add or remove members from groups. Default groups created in the |webui| have a gid greater than 1000. Same as usernames that are created in CLI they are not stored in the internal database. Just edit, insert a comment.
+Just to add or remove members from groups. Default groups created in the
+|webui| have a gid greater than 1000. Same as usernames that are created
+in CLI they are not stored in the internal database. Just edit, insert a
+comment.
 
 Shared Folder
 =============
 
 Add
 ^^^
-A shared folder in |omv| is an internal database object configuration that has been created using the |webui|. The |sf| these main components:
 
-	- **Name:** The logical name. This can override the path name. Typing a name here will fill the path with the same string.
+A shared folder in |omv| is an internal database object configuration that
+has been created using the |webui|. The |sf| these main components:
+
+	- **Name:** The logical name. This can override the path name. Typing a
+	  name here will fill the path with the same string.
 	- **Device:** The parent filesystem associated with the |sf|.
-	- **Path:** The relative path to the mounted device. To share the whole disk just type ``/``.
-	- **Permissions:** The default descriptive text will create the |sf| with ``root:users`` ownership and ``775`` permission mode.
+	- **Path:** The relative path to the mounted device. To share the whole
+	  disk just type ``/``.
+	- **Permissions:** The default descriptive text will create the |sf|
+	  with ``root:users`` ownership and ``775`` permission mode.
 
 	**Available modes**
 
@@ -123,16 +162,20 @@ Some of the elements explained:
 
     - **uuid**: Internal database reference number.
     - **name**: logical name given to the |sf|.
-    - **mntent**: This the associated filesystem reference. The number is in the ``uuid`` format, in the the fstab ``config.xml`` section should contain a <mntent> reference with this number.
+    - **mntent**: This the associated filesystem reference. The number is in the :code:`uuid` format, in the the fstab ``config.xml`` section should contain a :code:`<mntent>` reference with this number.
     - **reldirpath**: Path relative to the parent filesystem.
     - **privileges**: Users associated with the |sf| and their access level.
 
-When a plugin or a service uses a |sf| its stores the uuid only. Later on using helper scripts or internal CLI |omv| commands the path can be obtained just by using the ``uuid`` number.
-A shared folder can be used across all over the system backend. Is available to select it in sharing services (ftp, samba, rsync, etc) at the same time. Plugins can use them also just by using the shared folder combo class.
+When a plugin or a service uses a |sf| its stores the uuid only. Later on
+using helper scripts or internal CLI |omv| commands the path can be obtained
+just by using the :code:`uuid` number.
+A shared folder can be used across all over the system backend. Is available
+to select it in sharing services (FTP, Samba, RSync, etc) at the same time.
+Plugins can use them also just by using the shared folder combo class.
 
 .. note::
 	- A |sf| belongs to an |omv| filesystem entry. Is not possible to unmount the filesystem volume without deleting the folder configuraton from the |webui|.
-	- If a |sf| is being used by a service (ftp, plugins, etc) is not possible to delete it. Is necessary to disengage the |sf| from the service(s) or section(s) that is holding it before proceeding with removal of the configuration. This will also prevent to unmount a device from the |webui| in the filesystem section if there is still a |sf| associated with it.
+	- If a |sf| is being used by a service (FTP, plugins, etc) is not possible to delete it. Is necessary to disengage the |sf| from the service(s) or section(s) that is holding it before proceeding with removal of the configuration. This will also prevent to unmount a device from the |webui| in the filesystem section if there is still a |sf| associated with it.
 	- Due to the design of the software is not possible at the moment to know what section or service is holding which |sf|.
 
 Edit
@@ -142,11 +185,22 @@ Edit |sf| is possible, but it has some limitations. The logical name cannot be c
 
 .. warning::
 
-	**NFS Server**: Editing the parent device will not descent into ``/etc/fstab``. Make sure you edit the share in the NFS section so the bind can be remounted.
+	**NFS Server**: Editing the parent device will not descent into :file:`/etc/fstab`. Make sure you edit the share in the NFS section so the bind can be remounted.
 
 Privileges
 ^^^^^^^^^^
 
-Same as in the user section, the window here is relative to the shared folder. It will display for the selected |sf| all the |omv| users/groups and their corresponding privileges. As you can see from the code block in the `add section <#id3>`_ privileges are expressed in the internal database in the same manner as permissions in linux, simplified using the octal mode: read/write(7), read-only(5) and no access(0).
-When a privilege is changed in the |webui| it descents into all relevant services (SMB, FTP and AFP). |omv| will reconfigure everything that is using a |sf|, this includes daemon files and stop/start daemons. This is important as some services or plugins might not use privileges but they will have their daemon restarted as they are using a |sf|.
-As explained here privileges can be edited from `shared folder <#shared-folder>`_ or `users <#user>`_ section. But is also possible to edit privileges from the |sf| combo selection. Example: go to ``Services -> SMB/CIFS -> Shares -> Edit``, the loupe next to |sf| field will display privileges and allow to edit them.
+Same as in the user section, the window here is relative to the shared folder.
+It will display for the selected |sf| all the |omv| users/groups and their
+corresponding privileges. As you can see from the code block in the
+`add section <#id3>`_ privileges are expressed in the internal database in the
+same manner as permissions in Linux, simplified using the octal mode:
+read/write(7), read-only(5) and no access(0).
+When a privilege is changed in the |webui| it descents into all relevant
+services (SMB, FTP and AFP). |omv| will reconfigure everything that is using
+a |sf|, this includes daemon files and stop/start daemons. This is important
+as some services or plugins might not use privileges but they will have
+their daemon restarted as they are using a |sf|. As explained here privileges
+can be edited from `shared folder <#shared-folder>`_ or `users <#user>`_
+section. But it is also possible to edit privileges from the |sf| combo
+selection.

administration/certificates.rst

@@ -1,41 +1,67 @@
 Certificates
 ############
 
-This section allows to create or import SSH keys or SSL certificates.
+This section allows you to create or import SSH keys or SSL certificates.
+
+.. _admin_certificate_ssh:
 
 SSH (Secure Shell)
 ==================
 
-The public/private pair keys created or imported here are for using in the rsync client (jobs) service section. Plugins can use the internal database if they want to use these keys using the ssh certificates combo class.
-The key pair will be stored in the internal database, but only the public key will be available for display just by clicking edit. Not displaying the private key is basic ssh security as it never has to leave the host where it was created. The public key can be copied to clipboard or any other transport to be added to a remote server.
-Add a comment as this will be appended to the public key, this is important if you need to revoke the key pair in the remote server in case the server that generated the pair is compromised.
+The public/private pair keys created or imported here are for using in the
+:ref:`RSync client (jobs) <admin_rsync_jobs_client>` service section.
+Plugins can use the internal database if they want to use these keys using the
+SSH certificates combo class.
+The key pair will be stored in the internal database, but only the public key
+will be available for display just by clicking edit. Not displaying the private
+key is basic ssh security as it never has to leave the host where it was
+created. The public key can be copied to clipboard or any other transport to be
+added to a remote server.
+Add a comment as this will be appended to the public key, this is important if
+you need to revoke the key pair in the remote server in case the server that
+generated the pair is compromised.
 The keys are stored beside the database in these two files:
 
-``/etc/ssh/openmediavault-<uuid_suffix>``  --> Private key
-
-``/etc/ssh/openmediavault-<uuid_suffix>.pub`` --> Public key
+- **Public key**: :file:`/etc/ssh/openmediavault-<uuid_suffix>.pub`
+- **Private key**: :file:`/etc/ssh/openmediavault-<uuid_suffix>`
 
-The <uuid> suffix is the internal |omv| reference number.
+The :code:`<uuid>` suffix is the internal |omv| reference number.
 
 .. note::
 
-	The public key is not displayed in RFC 4716. In case the remote server is also |omv| based, you need to `convert <services.html#id7>`_ it the appropiate format.
+	The public key is not displayed in RFC 4716. In case the remote server is
+	also |omv| based, you need to `convert <services.html#id7>`_ it the
+	appropiate format.
 
 
 SSL (Secure Socket Layer)
 =========================
 
-The SSL certificates created or imported here can be used by the |webui| or FTP server. Plugins can also use them by adding the SSL certificate combo class. The create window has the most common SSL certificates fields. The certificate/private pair is stored in the internal database and as files in the linux standard SSL location.
-Certificate file with a <uuid> suffix, which is the internal database number:
+The SSL certificates created or imported here can be used by the |webui| or FTP
+server. Plugins can also use them by adding the SSL certificate combo class.
+The create window has the most common SSL certificates fields. The
+certificate/private pair is stored in the internal database and as files in
+the Linux standard SSL location.
+Certificate file with a :code:`<uuid>` suffix, which is the internal database
+number:
 
-``/etc/ssl/certificates/openmediavault-<uuid>.cert``
+:file:`/etc/ssl/certificates/openmediavault-<uuid>.cert`
 
-Private key file with the same <uuid> suffix from to his certificate pair.
-``/etc/ssl/private/openmediavault-<uuid>.key``
+Private key file with the same :code:`<uuid>` suffix from to his certificate
+pair.
 
-When importing existing ssl certificates make sure they are formated/converted appropiatly.
+:file:`/etc/ssl/private/openmediavault-<uuid>.key`
 
-The command that creates the certificate runs in the PHP backend and is documented `here <https://github.com/openmediavault/openmediavault/blob/20ec529737e6eca2e1f98d0b3d1ade16a3c338e1/deb/openmediavault/usr/share/openmediavault/engined/rpc/certificatemgmt.inc#L234-L358>`_. This certificates are self signed, without root CA.
+When importing existing ssl certificates make sure they are formated/converted
+appropiatly.
+
+The command that creates the certificate runs in the PHP backend and is
+documented `here <https://github.com/openmediavault/openmediavault/blob/20ec529737e6eca2e1f98d0b3d1ade16a3c338e1/deb/openmediavault/usr/share/openmediavault/engined/rpc/certificatemgmt.inc#L234-L358>`_.
+This certificates are self signed, without root CA.
 
 LetsEncrypt
-	LE certificates can be imported directly, just locate your ``etc/letsencrypt/live/<mydomain.com>/{cert,privkey}.pem`` files and copy their contents in their respective field. No need to convert.
+===========
+
+Lets Encrypt certificates can be imported directly, just locate your
+:file:`etc/letsencrypt/live/<mydomain.com>/{cert,privkey}.pem` files and copy
+their contents in their respective field. No need to convert.