[#1717] correct some URLs

14 files changed, 29 insertions, 30 deletions

diff --git a/doc/devel/.gitignore b/doc/devel/.gitignore
index 724f4d4c54..1936cc1d44 100644
--- a/doc/devel/.gitignore
+++ b/doc/devel/.gitignore
@@ -1 +1 @@
-html
\ No newline at end of file
+html
diff --git a/doc/devel/README b/doc/devel/README
index aae3daf8c5..c62c5630e6 100644
--- a/doc/devel/README
+++ b/doc/devel/README
@@ -2,4 +2,4 @@ This is a folder with content for Doxygen.
 This is used by developers and is not used directly in official builds.
 
 To build doxygen documetation run:
-make devel
\ No newline at end of file
+make devel
diff --git a/doc/devel/cross-compile.dox b/doc/devel/cross-compile.dox
index 8b67a1ecbd..19c599d148 100644
--- a/doc/devel/cross-compile.dox
+++ b/doc/devel/cross-compile.dox
@@ -10,7 +10,7 @@
 
 The idea is to install Kea on a Raspberry Pi 4 Model B running Raspbian
 operation system (e.g. the
-<a href="https://www.raspberrypi.org/downloads/raspbian/">
+<a href="https://www.raspberrypi.org/software/operating-systems/">
 Raspbian Buster with desktop and recommended software</a> distribution)
 without having to compile Kea on the Raspberry Pi box itself as it
 takes some hours so using a standard Linux box with a x86_64 processor.
diff --git a/doc/devel/doc.dox b/doc/devel/doc.dox
index 208e3ebf1c..932d0d9ab9 100644
--- a/doc/devel/doc.dox
+++ b/doc/devel/doc.dox
@@ -67,4 +67,4 @@ $ cd doc/devel
 $ make devel
 @endcode
 
-*/
\ No newline at end of file
+*/
diff --git a/doc/examples/https/httpd2/kea-httpd2.conf b/doc/examples/https/httpd2/kea-httpd2.conf
index 097a5ba044..b138673c59 100644
--- a/doc/examples/https/httpd2/kea-httpd2.conf
+++ b/doc/examples/https/httpd2/kea-httpd2.conf
@@ -126,4 +126,4 @@ SSLMutex  "file:/usr/local/var/run/apache2/ssl_mutex"
     #   Certificate Authority. Client certificate must be signed by the CA.
     SSLCACertificateFile "/path/to/ca.crt"
 
-</VirtualHost>
\ No newline at end of file
+</VirtualHost>
diff --git a/doc/examples/kea6/all-options.json b/doc/examples/kea6/all-options.json
index be2d17e8c1..369454fc7d 100644
--- a/doc/examples/kea6/all-options.json
+++ b/doc/examples/kea6/all-options.json
@@ -998,7 +998,7 @@
       // Type: string
       {
         "code": 59,
-        "data": "https://how-to-boot.net/pxe/os.img",
+        "data": "https://boot.example.org/pxe/os.img",
         "name": "bootfile-url"
       },
 
diff --git a/doc/sphinx/.gitignore b/doc/sphinx/.gitignore
index ce7f2dce0e..99baf9bfbb 100644
--- a/doc/sphinx/.gitignore
+++ b/doc/sphinx/.gitignore
@@ -1,4 +1,3 @@
 /_build
 /api.rst
 /kea-messages.rst
-
diff --git a/doc/sphinx/arm/ddns.rst b/doc/sphinx/arm/ddns.rst
index 155e363659..fb74450851 100644
--- a/doc/sphinx/arm/ddns.rst
+++ b/doc/sphinx/arm/ddns.rst
@@ -328,7 +328,7 @@ TSIG Key List
 -------------
 
 A DDNS protocol exchange can be conducted with or without TSIG (defined
-in `RFC 2845 <https://tools.ietf/org/html/rfc2845>`__). This
+in `RFC 2845 <https://tools.ietf.org/html/rfc2845>`__). This
 configuration section allows the administrator to define the set of TSIG
 keys that may be used in such exchanges.
 
diff --git a/doc/sphinx/arm/dhcp4-srv.rst b/doc/sphinx/arm/dhcp4-srv.rst
index b8c3396ed4..5f457d6005 100644
--- a/doc/sphinx/arm/dhcp4-srv.rst
+++ b/doc/sphinx/arm/dhcp4-srv.rst
@@ -3953,7 +3953,8 @@ gave the best performance. Although this section describes our results, those ar
 recommendations and are very dependent on the particular hardware that was used
 for testing. We strongly advise that administrators run their own performance tests.
 
-A full report of Kea 1.7 performance results can be found `here <https://jenkins.isc.org/job/kea-1.7/job/performance/KeaPerformanceReport/>`_.
+A full report of performance results for the latest stable Kea can be found
+`here <https://jenkins.isc.org/job/kea-dev/job/performance/KeaPerformanceReport/>`_.
 This includes hardware and test scenario descriptions, as well as
 current results.
 
diff --git a/doc/sphinx/arm/dhcp6-srv.rst b/doc/sphinx/arm/dhcp6-srv.rst
index ce9c8f6a24..212ef64749 100644
--- a/doc/sphinx/arm/dhcp6-srv.rst
+++ b/doc/sphinx/arm/dhcp6-srv.rst
@@ -3437,7 +3437,8 @@ give the best performance. Although this section describes our results, they are
 recommendations and are very dependent on the particular hardware that was used
 for testing. We strongly advise that administrators run their own performance tests.
 
-A full report of Kea 1.7 performance results can be found `here <https://jenkins.isc.org/job/kea-1.7/job/performance/KeaPerformanceReport/>`_.
+A full report of performance results for the latest stable Kea can be found
+`here <https://jenkins.isc.org/job/kea-dev/job/performance/KeaPerformanceReport/>`_.
 This includes hardware and test scenario descriptions, as well as
 current results.
 
diff --git a/doc/sphinx/arm/hooks-lease-cmds.rst b/doc/sphinx/arm/hooks-lease-cmds.rst
index 764cd9d7d0..9f58288c11 100644
--- a/doc/sphinx/arm/hooks-lease-cmds.rst
+++ b/doc/sphinx/arm/hooks-lease-cmds.rst
@@ -991,4 +991,3 @@ An example result returned when the lease was found:
      "result": 0,
      "text": "NCR generated for: 2001:db8:1::1, hostname: example.com."
    }
-
diff --git a/doc/sphinx/arm/logging.rst b/doc/sphinx/arm/logging.rst
index 0d0c8dbfec..5b4dafe8a1 100644
--- a/doc/sphinx/arm/logging.rst
+++ b/doc/sphinx/arm/logging.rst
@@ -677,16 +677,15 @@ That breaks down as like so:
     it is an address so is displayed in hexadecimal.
 
   - ``%m``
-    The log message itself. Keg log messages all begin with a message
-    identifier followed by arbitrary log text. Every message in Kea has
-    a unique identifier, which can be used as an index to the
-    `Kea Messages Manual <https://jenkins.isc.org/job/Kea_doc/messages/kea-messages.html>`__,
-    where more information can be obtained.  In our example log above, the
-    identifier is ``DHCPSRV_TIMERMGR_START_TIMER``.   The log text is typically
-    a brief description detailing the condition that caused the message to be
-    logged. In our example, the information logged,
-    ``starting timer: reclaim-expired-leases``, explains that the timer for
-    the expired lease reclamation cycle has been started.
+    The log message itself. Kea log messages all begin with a message identifier
+    followed by arbitrary log text. Every message in Kea has a unique
+    identifier, which can be used as an index to the :ref:`kea-messages`, where
+    more information can be obtained. In our example log above, the identifier
+    is ``DHCPSRV_TIMERMGR_START_TIMER``. The log text is typically a brief
+    description detailing the condition that caused the message to be logged. In
+    our example, the information logged,
+    ``starting timer: reclaim-expired-leases``, explains that the timer for the
+    expired lease reclamation cycle has been started.
 
 .. Warning::
 
diff --git a/doc/sphinx/mes2doc.py b/doc/sphinx/mes2doc.py
index cff26009ff..493ccc6d71 100755
--- a/doc/sphinx/mes2doc.py
+++ b/doc/sphinx/mes2doc.py
@@ -69,7 +69,8 @@ def read_input_files(files):
 
 
 def generate_rst(messages):
-    rst = '''
+    rst = '''.. _kea-messages:
+
 ###################
 Kea Messages Manual
 ###################
diff --git a/doc/sphinx/umls.rst b/doc/sphinx/umls.rst
index 38d0a6d98c..d888b4d59f 100644
--- a/doc/sphinx/umls.rst
+++ b/doc/sphinx/umls.rst
@@ -34,7 +34,7 @@ The main loop is common to both DHCPv4 and DHPCv6 servers.
 DHCPv4 Packet Processing
 ^^^^^^^^^^^^^^^^^^^^^^^^
 
-Next is the DHCPv4 packet processing, where we determine what sort of DHCP message this is, Discover, Request, Release, Decline or Inform. This diagram shows the general, high level flow for processing an inbound client DHCP packet (e.g. Discover, Request, Release, etc) from receipt to the server's response.. 
+Next is the DHCPv4 packet processing, where we determine what sort of DHCP message this is, Discover, Request, Release, Decline or Inform. This diagram shows the general, high level flow for processing an inbound client DHCP packet (e.g. Discover, Request, Release, etc) from receipt to the server's response..
 
 .. figure:: uml/packet4.*
 
@@ -46,13 +46,13 @@ Next is the DHCPv4 packet processing, where we determine what sort of DHCP messa
 DHCP Request Processing
 ^^^^^^^^^^^^^^^^^^^^^^^
 
-The following diagrams focus on DHCPREQUEST processing. This chart gives an overview of the process, beginning with subnet selection, proceeding to checking for Host Reservations and evaluating client classes. Finally, before acknowledging the lease, the options are evaluated and added to the message. 
+The following diagrams focus on DHCPREQUEST processing. This chart gives an overview of the process, beginning with subnet selection, proceeding to checking for Host Reservations and evaluating client classes. Finally, before acknowledging the lease, the options are evaluated and added to the message.
 
 .. figure:: uml/request4.*
 
     DHCPREQUEST processing
 
-. 
+.
 
 .. _uml_select4:
 
@@ -72,7 +72,7 @@ Subnet selection is the process of choosing a subnet that is topologically appro
 DHCPv4 Special Case of Double-booting
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-After the subnet selection and before the lease allocation the DHCPv4 server handles the special case of clients restarting with an image provided by PXE boot or bootp.  Note that the Lease Request box is expanded below. 
+After the subnet selection and before the lease allocation the DHCPv4 server handles the special case of clients restarting with an image provided by PXE boot or bootp.  Note that the Lease Request box is expanded below.
 
 .. figure:: uml/assign-lease4.*
 
@@ -84,12 +84,12 @@ After the subnet selection and before the lease allocation the DHCPv4 server han
 DHCPv4 Allocate Lease
 ^^^^^^^^^^^^^^^^^^^^^
 
-This diagram provides the details of the processing the client request, showing renewing an existing lease, assigning a reserved lease and allocating an unreserved lease. The next diagram after this one shows the algorithm in more detail.  
+This diagram provides the details of the processing the client request, showing renewing an existing lease, assigning a reserved lease and allocating an unreserved lease. The next diagram after this one shows the algorithm in more detail.
 
 .. figure:: uml/request4-lease.*
 
     Allocate a lease for DHCPREQUEST
-    
+
 This diagram shows the algorithm used to validate a requested lease or select a new address to offer. The far right side of the diagram shows how a new address is selected when a new lease is required and the client has neither a requested address nor a reservation. Note that when a new lease is required and Kea iterates over pools and subnets, it starts with the subnet selected above in the subnet selection process.
 
 .. figure:: uml/requestLease4.*
@@ -123,7 +123,7 @@ The allocation engine checks for host reservations after selecting a subnet. Thi
 
 .. note::
 
-    To find a free lease the allocation engine begins with evaluating the most recently used subnet. 
+    To find a free lease the allocation engine begins with evaluating the most recently used subnet.
     The current subnet depends on the history of prior queries.
 
 
@@ -154,4 +154,3 @@ Before sending a response, options are added:
 .. figure:: uml/appendRequestedVendorOptions.*
 
     appendRequestedVendorOptions (append vendor requested options) algorithm
-