Fixes #13252: Fix the doc: intro and installation sections

rudder-theme/src/partials/navigation-explore.hbs

@@ -19,10 +19,10 @@
         {{/each}}
         {{~#if (and @root.site.url (eq this.name "reference"))}}
         <li class="version">
-          <a href="https://www.rudder-project.org/doc-4.3/">4.3</a>
+          <a href="https://docs.rudder.io/reference/4.3/">4.3</a>
 	</li>
 	<li class="version">
-          <a href="https://www.rudder-project.org/doc-4.1/">4.1</a>
+          <a href="https://docs.rudder.io/reference/4.1/">4.1</a>
         </li>
         {{/if}}
       </ul>

src/get-started/modules/ROOT/pages/next.adoc

@@ -2,5 +2,5 @@
 
 This tutorial is now over. You can have a look at:
 
-* http://wwww.rudder-project.org/rudder-by-example[Rudder by example] for explained usecases
-* http://faq.rudder-project.org[Rudder FAQ]
+* xref:rudder-by-example:ROOT:index.adoc[Rudder by example] for explained usecases
+* http://faq.rudder-project.org[Rudder FAQ]

src/reference/modules/ROOT/pages/key_features.adoc

@@ -75,13 +75,13 @@ used to defined configuration rule targets. Typically, some configurations are
 linked to the kind of server (physical or virtual), the quantity of RAM
 available, the version of an OS library which contains a security bug, etc.
 
-All of these data are also available xref:administration:integration.adoc#rudder-integration[through Rudder APIs].
+All of these data are also available xref:administration:integration.adoc#rudder-api-integration[through Rudder APIs].
 
 == REST API
 
 All Rudder commands are available through an exhaustive REST API. That API is
 https://docs.rudder.io/api/[fully documented online] and can
-be used to xref:administration:integration.adoc#rudder-integration[quickly and smoothly integrate Rudder with your existing infrastructure].
+be used to xref:administration:integration.adoc#rudder-api-integration[quickly and smoothly integrate Rudder with your existing infrastructure].
 
 == Audit trace and Change Requests
 
@@ -106,7 +106,7 @@ plugin or a dedicated synchronisation tool].
 Rudder can use enterprise directories (LDAP, Active Directory)
 or be connected to an SSO to manage users authentication.
 
-Moreover, Rudder authentication layer is plugable and can be extended to other
+Moreover, Rudder authentication layer is pluggable and can be extended to other
 authentication protocol xref:TODO[like Radius or SPNEGO with plugins].
 
 [[intro-rudder-extensibility]]

src/reference/modules/administration/pages/_partials/glossary/cfengine-server.adoc

@@ -1,4 +1,4 @@
-CFEngine server::
+Policy server::
 
-Distribute the CFEngine configuration to the nodes.
+Distribute the configuration to the nodes.
 

src/reference/modules/administration/pages/integration.adoc

@@ -88,7 +88,7 @@ The documentation provided on APIs is exhaustive, but here comes a summary of
 what can be done with them:
 
 - accept, delete a node and manage its parameters,
-- get information with a parametrable depth about node inventories,
+- get information with a parametrizable depth about node inventories,
 - search for nodes,
 - manage (create, update, delete) groups, directives, rules and parameters,
 - interact with the Techniques library,

src/reference/modules/administration/pages/performance.adoc

@@ -171,7 +171,7 @@ I/O's, you might experience a sluggish CFEngine agent run everytime the machine
 tries to comply with your Rules.
 
 This is because the CFEngine agent tries to update its internal databases everytime the agent
-executes a promise (the .lmdb files in the /var/rudder/cfengine-community/state directory),
+executes a policy (the .lmdb files in the /var/rudder/cfengine-community/state directory),
 which even if the database is very light, takes some time if the machine has a very high iowait.
 
 In this case, here is a workaround you can use to restore CFEngine's full speed: you can use

src/reference/modules/administration/pages/procedures.adoc

@@ -188,7 +188,8 @@ psql -u rudder -d rudder -W < /root/rudder-backup-XXXXXXXX.sql
 rudder agent enable
 
 # And restart the machine or just Rudder:
-service rudder restart
+service rudder-server restart
+service rudder-agent restart
 
 ----
 

src/reference/modules/administration/pages/server.adoc

@@ -151,7 +151,7 @@ You can add as many networks as you want, the expected format is:
 === Clear caches
 
 Clear cached data, like node configuration. That will trigger a full
-redeployment, with regeneration of all promises files.
+redeployment, with regeneration of all policies files.
 
 === Reload dynamic groups
 
@@ -212,8 +212,8 @@ service rudder-agent restart
 
 ====
 
-This command can take more than one minute to restart the CFEngine daemon.
-This is not a bug, but an internal protection system of CFEngine.
+This command can take more than one minute to restart the agent daemons.
+This is not a bug, but an internal protection system of the agent.
 
 ====
 

src/reference/modules/installation/pages/_partials/relay_initial_config.adoc

@@ -19,7 +19,7 @@ host to be considered as a relay. You can find the UUID of your node with the
 When every step has completed successfully:
 
 - The Rudder root server will recognize the new node as a relay
-- It will generate specific promises for the relay
+- It will generate specific policies for the relay
 - The relay will update and switch to his new role
 
 This is an example of node details pane showing a relay server. Note the "Role:

src/reference/modules/installation/pages/operating_systems.adoc

@@ -1,3 +1,4 @@
+= Supported Operating Systems
 
 [[node-supported-os, the list of supported Operating Systems for Nodes]]
 == Fully supported Operating Systems
@@ -12,23 +13,23 @@ available for these platforms:
 
 GNU/Linux:
 
-* Debian 5 to 9
+* Debian 8 and 9
 
-* RedHat Enterprise Linux (RHEL) / RHEL-like 3 and 5 to 7
+* RedHat Enterprise Linux (RHEL) / RHEL-like 6 and 7 (64-bit)
 
-* SUSE Linux Enterprise Server (SLES) 10 SP3, 11 and 12
+* SUSE Linux Enterprise Server (SLES) 11 and 12 (64bit)
 
-* Ubuntu 10.04 LTS (Lucid), 12.04 LTS (Precise), 14.04 LTS (Trusty), 16.04 LTS (Xenial), 18.04 LTS (Bionic)
+* Ubuntu 14.04 LTS (Trusty), 16.04 LTS (Xenial), 18.04 LTS (Bionic) (64-bit)
 
-* Slackware 14
+* Slackware 14 (64-bit)
 
 Other Unix systems:
 
 * IBM AIX 5.3, 6.1 and 7.1
 
 Windows:
 
-* xref:installation:requirements.adoc#install-on-windows[Microsoft Windows] Server 2008 R2, 2012, 2012 R2, 2016
+* xref:TODO[Microsoft Windows] Server 2008 R2, 2012, 2012 R2, 2016
 
 [TIP]
 
@@ -79,14 +80,22 @@ any packages for them. Moreover, some Techniques may not work properly. If you
 wish to get Rudder support on those systems, please get in touch with us!
 
 A reference about how to manually build a Rudder agent is available on Rudder's
-documentation here: xref:reference:build.adoc#_building_the_rudder_agent[Building the Rudder Agent]
+xref:reference:build.adoc#_building_the_rudder_agent[build documentation].
 
 ====
 
 === For Rudder Nodes
 
 The following operating systems have had an agent built using xref:reference:build.adoc#_building_the_rudder_agent[Building the Rudder Agent]:
 
+* Debian 5 to 7
+
+* RedHat Enterprise Linux / CentOS 3 and 5
+
+* SUSE Linux Enterprise Server 10 SP3
+
+* Ubuntu 10.04 LTS (Lucid), 12.04 LTS (Precise)
+
 * FreeBSD
 
 * Solaris 10 and 11
@@ -104,4 +113,4 @@ Even if this distribution has not been tested by us, it has a reasonable chance
 
 We advise against using an unsupported OS for Rudder server because the server contains
 much more code than the agent. This code is tailored against specific OS versions
-to work around many system limitations and specificities.
+to work around many system limitations and specificities.

src/reference/modules/installation/pages/requirements.adoc

@@ -101,14 +101,14 @@ The required amount of RAM mainly depends on the number of managed nodes. A gene
 * more than 1000 nodes: 4 GB + 1 GB of RAM by 500 nodes above 1000.
 
 When managing more than 1000 nodes, we also recommend you to use a multiserver
-installation for Rudder as described in chapter xref:administration:multi_server.adoc#multiserver-rudder[Multiserver Rudder].
+installation for Rudder as described in the xref:administration:multi_server.adoc#multiserver-rudder[multiserver installation] chapter.
 
 When your server has more than 2 GB of RAM, you have to configure the RAM allocated
 to the Java Virtual Machine as explained in the section
 xref:administration:performance.adoc#_configure_ram_allocated_to_jetty[about webapplication RAM configuration].
 
 When your server has more than 4 GB, you may need to also tune the PostgresSQL
-server, as explained in the xref:administration:performance.adoc#_optimize_postgresql_server[Optimize PostgreSQL Server]
+server, as explained in the xref:administration:performance.adoc#_optimize_postgresql_server[optimize PostgreSQL Server]
 section.
 
 [TIP]
@@ -141,7 +141,7 @@ For example, a default installation with 500 nodes and an average of
 50 Directives by node, should require between *14 GB and 38 GB* of disk space
 for PostgreSQL.
 
-Follow the xref:administration:performance.adoc#_reports_retention[Reports Retention] section to configure the
+Follow the xref:administration:performance.adoc#_reports_retention[reports Retention] section to configure the
 retention duration.
 
 [WARNING]
@@ -159,7 +159,7 @@ Special attention should be given to:
 
 `/var/lib/pgsql`::
 (OS dependent).
-Please see the xref:installation:requirements.adoc#_database_maintenance[database maintenance] chapter for more details about the
+Please see above for more details about the
 PostgreSQL database size estimation.
 
 `/var/rudder`::

src/reference/modules/reference/pages/_partials/glossary/cfengine.adoc

@@ -2,4 +2,3 @@ CFEngine::
 
 CFEngine is a configuration management software. CFEngine comes from a
 contraction of ``ConFiguration Engine''.
-

src/reference/modules/reference/pages/architecture.adoc

@@ -92,7 +92,7 @@ waiting.inventory.queue.size=50
 
 ----
 
-Since Rudder 3.1.18 / 3.2.11 / 4.0.3, the number of currently waiting
+The number of currently waiting
 inventories can be obtained via a local REST API call to
 `http://localhost:8080/endpoint/api/info`:
 
@@ -125,7 +125,7 @@ The description of the category is included in +category.xml+.
 . At the second and third level, Technique identifier and version.
 
 . At the last level, each technique is described with a +metadata.xml+ file and
-one or several CFEngine template files (name ending with +.st+).
+one or several agent template files (name ending with +.st+).
 
 [source,python]
 
@@ -163,9 +163,7 @@ the LDAP subtree of Active Techniques.
 The LDAP tree contains also a set of subtrees for Node Groups, Rules and Node
 Configurations.
 
-At each change of the Node Configurations, Rudder Server creates CFEngine draft policies
-(+Cf3PolicyDraft+) that are stored in memory, and then invokes +cf-clerk+.
-+cf-clerk+ finally generates the CFEngine promises for the Nodes.
+At each change of the Node Configurations, Rudder Server generates the agent policies for the Nodes.
 
 image::graphviz/data_workflow.png[Rudder data workflow]
 
@@ -239,15 +237,15 @@ been validated in Rudder, this step fails.
 
 === Launch processes
 
-Ensure that the CFEngine community daemons +cf-execd+ and +cf-serverd+ are
+Ensure that the agent daemons +cf-execd+ and +cf-serverd+ are
 running. Try to start these daemons if they are not already started.
 
-Daily between 5:00 and 5:05, relaunch the CFEngine Community daemons +cf-execd+
+Daily between 5:00 and 5:05, relaunch the agent daemons +cf-execd+
 and +cf-serverd+.
 
 Add a line in +/etc/crontab+ to launch +cf-execd+ if it's not running.
 
-Ensure again that the CFEngine community daemons +cf-execd+ and +cf-serverd+
+Ensure again that the agent daemons +cf-execd+ and +cf-serverd+
 are running. Try to start these daemons if they are not already started.
 
 === Identify Rudder Root Server
@@ -310,7 +308,7 @@ sent by FusionInventory and insert the valuable data into the LDAP database.
 Application server for +rudder-webapp+ and +rudder-inventory-endpoint+. Both
 packages are written in 'Scala'. At compilation time, they are converted into
 +.war+ files. They need to be run in an application server. 'Jetty' is this
-application server. It depends on a compatible Java 7 Runtime Environment.
+application server. It depends on a compatible Java 8 Runtime Environment.
 
 +rudder-techniques+::
 
@@ -346,7 +344,7 @@ all above packages. It also
 
 ----
 
-- installs the initial promises for the Root Server in:
+- installs the initial policies for the Root Server in:
 
 ----
 
@@ -373,7 +371,7 @@ all above packages. It also
 +rudder-agent+::
 
 One single package integrates everything needed for the Rudder Agent. It
-contains CFEngine Commmunity, FusionInventory, and the initial promises for a
+contains CFEngine Community, FusionInventory, and the initial policies for a
 Node. It also contains an init script:
 
 ----
@@ -415,7 +413,7 @@ The rsyslog server is receiving the logs from the nodes and insert them into a
 PostgreSQL database. On SLES, the +rsyslog-pgsql+ package is not part of the
 distribution, it can be downloaded alongside Rudder packages.
 
-Java 7+ JRE::
+Java 8+ JRE::
 
 The Java runtime is needed by the Jetty application server. Where possible, the
 package from the distribution is used, else a Java RE must be downloaded

src/reference/modules/reference/pages/build.adoc

@@ -34,7 +34,7 @@ Now choose one of the 3 next chapter, depending on your case: dpkg (debian-like
 Set the version to build:
 
 * Update the debian/changelog file to make the first entry match the version you want to build.
-* Edit the SOURCES/Makefile file and set the value of RUDDER_VERSION_TO_PACKAGE: see http://www.rudder-project.org/archives/ for a complete list of available versions.
+* Edit the SOURCES/Makefile file and set the value of RUDDER_VERSION_TO_PACKAGE: see https://repository.rudder.io/sources/ for a complete list of available versions.
 
 Run the dpkg package builder:
 
@@ -50,7 +50,7 @@ The package will be stored in the parent directory.
 
 Set the version to build:
 
-* Edit the SOURCES/Makefile file and set the value of RUDDER_VERSION_TO_PACKAGE: see http://www.rudder-project.org/archives/ for a complete list of available versions.
+* Edit the SOURCES/Makefile file and set the value of RUDDER_VERSION_TO_PACKAGE: see https://repository.rudder.io/sources/ for a complete list of available versions.
 
 Run the rpm package builder:
 
@@ -69,7 +69,7 @@ The package will be stored in RPMS/
 Before building the agent, you must decide on some environment variables:
 
 
-* RUDDER_VERSION_TO_PACKAGE: the version of the sources that will be used, see http://www.rudder-project.org/archives/ for a complete list. If a 'rudder-sources' directory exists in SOURCES it will be used instead of downloading sources. The Variable still needs to be defined though.
+* RUDDER_VERSION_TO_PACKAGE: the version of the sources that will be used, see https://repository.rudder.io/sources/ for a complete list. If a 'rudder-sources' directory exists in SOURCES it will be used instead of downloading sources. The Variable still needs to be defined though.
 
 * DESTDIR: where to put the installation, use / to install on the system and leave the default of ./target to prepare a package.
 
@@ -90,4 +90,4 @@ env="RUDDER_VERSION_TO_PACKAGE=5.0.0 DESTDIR=/ USE_SYSTEM_PERL=true"
 make $env
 make install $env
 
-----
+----

src/reference/modules/reference/pages/reports.adoc

@@ -12,7 +12,7 @@ Each Technique, when converted into a Directive and applied to a Node, must gene
    * The Version Id (revision of the Rule) (autogenerated)
    * The name of the component the report is related to
    * The value of the key variable in the component (or None if not available)
-   * The Execution Timestamp, to know in which execution of the agent the promise has been generated
+   * The Execution Timestamp, to know in which execution of the agent the policy has been generated
 
 These reports are sent via Syslog to the Rudder Root Server, parsed and put in a database, that is queried to generate the reporting
 
@@ -33,7 +33,7 @@ A report has the following format :
    * VersionId : the revision of the ConfigurationRule, autogenerated
    * Component : the name of the component this Directive is related to (if no component are defined in the metadata.xml, then the Technique name is used)
    * Key : the value of the reference variable. If there is no reference variable, then the value None should be used
-   * ExecutionTimeStamp : the timestamp of the current CFEngine execution
+   * ExecutionTimeStamp : the timestamp of the current agent execution
    * NodeId : the id of the node
    * HumanReadableMessage : a message than a Human can understand
 
@@ -76,7 +76,7 @@ A report has the following format :
 | log
 | enforce
 | infinity
-| Used for logging purposes, to list all that is repaired by the promises.
+| Used for logging purposes, to list all that is repaired by the policies.
 
 | result_na
 | result
@@ -133,14 +133,14 @@ Variables used to generate the reports
 
 Some facilities have been created to help putting the right values at the right place
 
-   * `&TRACKINGKEY&`: this is an auto generated variable, put in the technique file, that Rudder will replace when writing the promises by
+   * `&TRACKINGKEY&`: this is an auto generated variable, put in the technique file, that Rudder will replace when writing the policies by
 
 ----
 
 <pre>RuleId@@DirectiveId@@VersionId
 
 ----
 
-   * `$(g.execRun)`: this is replaced at runtime by CFEngine 3 to the current execution time
-   * `$(g.uuid)`: this is replaced at runtime by CFEngine 3 to the Node Id
+   * `$(g.execRun)`: this is replaced at runtime by the agent to the current execution time
+   * `$(g.uuid)`: this is replaced at runtime by the agent to the Node Id
 

src/reference/modules/reference/pages/security.adoc

@@ -35,7 +35,7 @@ More precisely:
 === Common data
 
 This refers to content available from all nodes in the authorized networks, readable from all users
-on the nodes (and that can be transfered withtout encryption when using initial promises of a pre-4.0 node).
+on the nodes (and that can be transfered withtout encryption when using initial policies of a pre-4.0 node).
 
 These unprotected contents are: