[docs] Various minor adjustments

Author: nemesifier

user/django-settings.rst

@@ -65,12 +65,6 @@ add any python instruction to define and manipulate settings via the
             },
         }
 
-        OPENWISP_ADMIN_THEME_LINKS = [
-            {'type': 'text/css', 'href': '/static/admin/css/openwisp.css', 'rel': 'stylesheet', 'media': 'all'},
-            {'type': 'text/css', 'href': '/static/custom.css', 'rel': 'stylesheet', 'media': 'all'},
-            {'type': 'image/x-icon', 'href': '/static/favicon.png', 'rel': 'icon'}
-        ]
-
 This allows for great flexibility in configuring and extending OpenWISP,
 because additional custom modules can be added and configured too.
 

user/firmware-upgrades.rst

@@ -2,7 +2,8 @@ Firmware Upgrades
 =================
 
 OpenWISP Firmware Upgrader has been introduced in OpenWISP 20 and focuses
-on allowing users to maintain the firmware of their network devices up to date.
+on allowing users to maintain the firmware of their network
+devices up to date.
 
 .. contents:: **Table of Contents**:
    :backlinks: none
@@ -26,95 +27,112 @@ Quickstart Guide
 
 Requirements:
 
-- Devices running at least OpenWRT 12.09 Attitude Adjustment, older versions
-  of OpenWRT have not worked at all in our tests
+- Devices running at least OpenWRT 12.09 Attitude Adjustment,
+  older versions of OpenWRT have not worked at all in our tests
 - Devices must have enough free RAM to be able to upload the
   new image to ``/tmp``
 
 1. Create a category
 ~~~~~~~~~~~~~~~~~~~~
 
 Create a category for your firmware images
-by going to *Firmware management > Firmware categories > Add firmware category*,
+by going to
+*Firmware management > Firmware categories > Add firmware category*,
 if you use only one firmware type in your network, you could simply
 name the category "default" or "standard".
 
 .. image:: https://raw.githubusercontent.com/openwisp/openwisp-firmware-upgrader/docs/docs/images/quickstart-category.gif
 
-If you use multiple firmware images with different features, create one category
-for each firmware type, eg:
+If you use multiple firmware images with different features,
+create one category for each firmware type, eg:
 
 - WiFi
 - SDN router
 - LoRa Gateway
 
 This is necessary in order to perform mass upgrades only on specific
-firmware categories when, for example, a new *LoRa Gateway* firmware becomes available.
+firmware categories when, for example, a new
+*LoRa Gateway* firmware becomes available.
 
 2. Create the build object
 ~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Create a build a build object by going to
 *Firmware management > Firmware builds > Add firmware build*,
-the build object is related to a firmware category and is the collection of the
-different firmware images which have been compiled for the different hardware models
-supported by the system.
+the build object is related to a firmware category and
+is the collection of the different firmware images which have
+been compiled for the different hardware models supported by the system.
 
-The version field indicates the firmware version, the change log field is optional but
-we recommend filling it to help operators know the differences between each version.
+The version field indicates the firmware version,
+the change log field is optional but we recommend filling it to help
+operators know the differences between each version.
 
 .. image:: https://raw.githubusercontent.com/openwisp/openwisp-firmware-upgrader/docs/docs/images/quickstart-build.gif
 
-An important but optional field of the build model is **OS identifier**, this field
-should match the value of the **Operating System** field which gets automatically filled
-during device registration, eg: ``OpenWrt 19.07-SNAPSHOT r11061-6ffd4d8a4d``.
+An important but optional field of the build model is **OS identifier**,
+this field should match the value of the **Operating System**
+field which gets automatically filled
+during device registration, eg:
+``OpenWrt 19.07-SNAPSHOT r11061-6ffd4d8a4d``.
 It is used by the firmware-upgrader module to automatically
-create ``DeviceFirmware`` objects for existing devices or when new devices register.
-A ``DeviceFirmware`` object represent the relationship between a device and a firmware image,
+create ``DeviceFirmware`` objects for existing devices or when
+new devices register.
+
+A ``DeviceFirmware`` object represent the relationship between a
+device and a firmware image,
 it basically tells us which firmware image is installed on the device.
 
 To find out the exact value to use, you should either do a
-test flash on a device and register it to the system or you should inspect the firmware image
+test flash on a device and register it to the system or you
+should inspect the firmware image
 by decompressing it and find the generated value in the firmware image.
 
-If you're not sure about what **OS identifier** to use, just leave it empty, you can fill
-it later on when you find out.
+If you're not sure about what **OS identifier** to use,
+just leave it empty, you can fill it later on when you find out.
 
 Now save the build object to create it.
 
 3. Upload images to the build
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-Now is time to add images to the build, we suggest adding one image at time.
-Alternatively the `REST API <#rest-api>`__ can be used to automate this step.
+Now is time to add images to the build, we suggest adding one
+image at time. Alternatively the
+`REST API <https://github.com/openwisp/openwisp-firmware-upgrader/tree/1.0#rest-api>`__
+can be used to automate this step.
 
 .. image:: https://raw.githubusercontent.com/openwisp/openwisp-firmware-upgrader/docs/docs/images/quickstart-firmwareimage.gif
 
 If you use a hardware model which is not listed in the image types, if the
-hardware model is officially supported by OpenWRT, you can send us a pull-request to add it,
-otherwise you can use `the setting OPENWISP_CUSTOM_OPENWRT_IMAGES <#openwisp_custom_openwrt_images>`__
+hardware model is officially supported by OpenWRT,
+you can send us a pull-request to add it,
+otherwise you can use
+`the setting OPENWISP_CUSTOM_OPENWRT_IMAGES
+<https://github.com/openwisp/openwisp-firmware-upgrader/tree/1.0#openwisp_custom_openwrt_images>`__
 to add it.
 
 4. Perform a firmware upgrade to a specific device
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 .. image:: https://raw.githubusercontent.com/openwisp/openwisp-firmware-upgrader/docs/docs/images/quickstart-devicefirmware.gif
 
-Once a new build is ready, has been created in the system and its image have been uploaded,
-it will be the time to finally upgrade our devices.
+Once a new build is ready, has been created in the system and its
+image have been uploaded, it will be the time to finally
+upgrade our devices.
 
 To perform the upgrade of a single device, navigate to the device details,
 then go to the "Firmware" tab.
 
-If you correctly filled **OS identifier** in step 2, you should have a situation
-similar to the one above: in this example, the device is using version ``1.0``
-and we want to upgrade it to version ``2.0``, once the new firmware image
-is selected we just have to hit save, then a new tab will appear in the device page
-which allows us to see what's going on during the upgrade.
+If you correctly filled **OS identifier** in step 2,
+you should have a situation similar to the one above: in this example,
+the device is using version ``1.0`` and we want to upgrade it to
+version ``2.0``, once the new firmware image is selected we just have to
+hit save, then a new tab will appear in the device page which allows us
+to see what's going on during the upgrade.
+
+Right now, the update of the upgrade information is not asynchronous yet,
+so you will have to reload the page periodically to find new information.
 
-Right now, the update of the upgrade information is not asynchronous yet, so you will
-have to reload the page periodically to find new information. This will be addressed
-in a future release.
+This will be addressed in a future release.
 
 5. Performing mass upgrades
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -134,21 +152,24 @@ At this stage you can try a mass upgrade by doing the following:
 
 .. image:: https://raw.githubusercontent.com/openwisp/openwisp-firmware-upgrader/docs/docs/images/quickstart-batch-upgrade.gif
 
-At this point you should see a summary page which will inform you of which devices
-are going to be upgraded, you can either confirm the operation or cancel.
+At this point you should see a summary page which will inform you of
+which devices are going to be upgraded, you can either confirm the
+operation or cancel.
+
+Once the operation is confirmed you will be redirected to a page
+in which you can monitor the progress of the upgrade operations.
 
-Once the operation is confirmed you will be redirected to a page in which you
-can monitor the progress of the upgrade operations.
+Right now, the update of the upgrade information is not asynchronous yet,
+so you will have to reload the page periodically to find new information.
 
-Right now, the update of the upgrade information is not asynchronous yet, so you will
-have to reload the page periodically to find new information. This will be addressed
-in a future release.
+This will be addressed in a future release.
 
 Find out more about OpenWISP Firmware Upgrader
 ----------------------------------------------
 
-For more information about the features offered by OpenWISP Firmware Upgrader
-we refer to the following sections of its README:
+For more information about the features offered by
+OpenWISP Firmware Upgrader we refer to the following sections
+of its documentation:
 
 - `List of the available features
   <https://github.com/openwisp/openwisp-firmware-upgrader/tree/1.0#openwisp-firmware-upgrader>`_

user/monitoring.rst

@@ -65,12 +65,12 @@ and other actions like
 
 There are mainly two deployment scenarios for OpenWISP:
 
-1. the OpenWISP server is deployed on the public internet and the devices are
-   geographically distributed across different locations:
+1. the OpenWISP server is deployed on the public internet and the
+   devices are geographically distributed across different locations:
    **in this case a management tunnel is needed**
-2. the OpenWISP server is deployed on a computer/server which is located in
-   the same Layer 2 network (that is, in the same LAN) where the devices
-   are located.
+2. the OpenWISP server is deployed on a computer/server which is
+   located in the same Layer 2 network (that is, in the same LAN)
+   where the devices are located.
    **in this case a management tunnel is NOT needed**
 
 1. Public internet deployment
@@ -112,8 +112,9 @@ In this scenario, the following requirements are needed:
   which gets an IP address assigned to it and which is reachable from
   the OpenWISP server.
 
-- The devices must be configured to join the management tunnel automatically,
-  either via a pre-existing configuration in the firmware or via an
+- The devices must be configured to join the management
+  tunnel automatically, either via a pre-existing configuration in
+  the firmware or via an
   `OpenWISP Template <https://openwisp.io/docs/user/templates.html>`_.
 
 - The `openwisp-config <https://github.com/openwisp/openwisp-config>`_
@@ -123,7 +124,8 @@ In this scenario, the following requirements are needed:
   use the management IP for reaching the device.
 
   For example, if the *management interface* is named ``tun0``,
-  the openwisp-config configuration should look like the following example:
+  the openwisp-config configuration should look like the following
+  example:
 
 .. code-block:: text
 

user/network-topology.rst

@@ -7,9 +7,10 @@ Network Topology
 `OpenWISP Network Topology
 <https://github.com/openwisp/openwisp-network-topology/tree/1.0>`_
 is a network topology collector and visualizer
-web application and API, it allows to collect network topology data from different
-networking software (dynamic mesh routing protocols, OpenVPN), store it,
-visualize it, edit its details, it also provides hooks (a.k.a
+web application and API, it allows to collect network topology data
+from different networking software (dynamic mesh routing protocols,
+OpenVPN), store it, visualize it, edit its details, it also provides
+hooks (a.k.a
 `Django signals <https://docs.djangoproject.com/en/4.0/topics/signals/>`_)
 to execute code when the status of a link changes.
 
@@ -44,9 +45,10 @@ Quickstart Guide
 This module works by periodically collecting the network topology
 graph data of the `supported networking software or formats
 <https://github.com/openwisp/openwisp-network-topology/tree/1.0#available-features>`_.
-The data has to be either fetched by the application or received in POST API
-requests, therefore after deploying the application, additional steps are required
-to make the data collection and visualization work, read on to find out how.
+The data has to be either fetched by the application or received in
+POST API requests, therefore after deploying the application,
+additional steps are required to make the data collection and
+visualization work, read on to find out how.
 
 Creating a topology
 ^^^^^^^^^^^^^^^^^^^
@@ -56,12 +58,14 @@ Creating a topology
 1. Create a topology object by going to *Network Topology* > *Topologies*
    > *Add topology*.
 2. Give an appropriate label to the topology.
-3. Select the *topology format* from the dropdown menu. The *topology format*
-   determines which parser should be used to process topology data.
+3. Select the *topology format* from the dropdown menu.
+   The *topology format* determines which parser should be used
+   to process topology data.
 4. Select the *Strategy* for updating this topology.
 
-   - If you are using `FETCH strategy <https://github.com/openwisp/openwisp-network-topology/tree/1.0#fetch-strategy>`_, then enter the
-     URL for fetching topology data in the *Url* field.
+   - If you are using `FETCH strategy
+     <https://github.com/openwisp/openwisp-network-topology/tree/1.0#fetch-strategy>`_,
+     then enter the URL for fetching topology data in the *Url* field.
    - If you are using `RECEIVE strategy <https://github.com/openwisp/openwisp-network-topology/tree/1.0#receive-strategy>`_, you will get the
      *URL* for sending topology data. The *RECEIVE* strategy provides an
      additional field *expiration time*. This can be used to add delay in
@@ -76,11 +80,12 @@ Sending data for topology with RECEIVE strategy
 
    E.g., in our case the URL is ``http://127.0.0.1:8000/api/v1/network-topology/topology/d17e539a-1793-4be2-80a4-c305eca64fd8/receive/?key=cMGsvio8q0L0BGLd5twiFHQOqIEKI423``.
 
-2. Create a script (eg: ``/opt/send-topology.sh``) which sends the topology
-   data using ``POST``, in the example script below we are sending the
-   status log data of OpenVPN but the same code can be applied to other
-   formats by replacing ``cat /var/log/openvpn/tun0.stats`` with the
-   actual command which returns the network topology output:
+2. Create a script (eg: ``/opt/send-topology.sh``) which sends the
+   topology data using ``POST``, in the example script below we are
+   sending the status log data of OpenVPN but the same code can be
+   applied to other formats by replacing
+   ``cat /var/log/openvpn/tun0.stats`` with the actual command which
+   returns the network topology output:
 
 .. code-block:: shell
 
@@ -95,7 +100,8 @@ Sending data for topology with RECEIVE strategy
             http://127.0.0.1:8000/api/v1/network-topology/topology/d17e539a-1793-4be2-80a4-c305eca64fd8/receive/?key=cMGsvio8q0L0BGLd5twiFHQOqIEKI423
 
 3. Add the ``/opt/send-topology.sh`` script created in the previous step
-   to the crontab, here's an example which sends the topology data every 5 minutes:
+   to the crontab, here's an example which sends the topology
+   data every 5 minutes:
 
 .. code-block:: shell
 
@@ -119,8 +125,8 @@ Sending data for topology with RECEIVE strategy
 Find out more about OpenWISP Network Topology
 ---------------------------------------------
 
-For more information about the features offered by OpenWISP Network Topology
-we refer to the following sections of its README:
+For more information about the features offered by OpenWISP Network
+Topology we refer to the following sections of its documentation:
 
 - `List of the available features
   <https://github.com/openwisp/openwisp-network-topology/tree/1.0#available-features>`_