mirror of
https://github.com/clearlinux/clear-linux-documentation.git
synced 2026-07-07 05:06:15 +00:00
Merge branch 'master' of https://github.com/clearlinux/clear-linux-documentation into bare-metal-installation
This commit is contained in:
Michael Vincerra
@@ -6,7 +6,7 @@ Autospec
|
||||
.. _incl-autospec-overview:
|
||||
|
||||
Overview
|
||||
--------
|
||||
********
|
||||
|
||||
Whereas a standard RPM build process using ``rpmbuild`` requires a tarball
|
||||
and ``spec`` file to start, ``autospec`` only requires a tarball and package
|
||||
@@ -32,7 +32,7 @@ file.
|
||||
|
||||
For a comprehensive list of control files, view the `autospec readme`_.
|
||||
|
||||
.. _incl-autospec-overview-end
|
||||
.. _incl-autospec-overview-end:
|
||||
|
||||
Control files are explained in Table 1.
|
||||
|
||||
|
||||
@@ -15,3 +15,4 @@ details relevant to the |CL| features.
|
||||
bundles-about
|
||||
autospec-about
|
||||
restart
|
||||
telemetry-about
|
||||
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 59 KiB |
@@ -6,7 +6,8 @@ Restart system services after an OS update
|
||||
The software life cycle describes how software is created, developed, and
|
||||
deployed, and includes how to replace or update software. A good OS
|
||||
provides tools for the entire software life cycle. These tools must include
|
||||
ways to remove software components properly when replaced with something else.
|
||||
ways to remove software components properly when replaced with something
|
||||
else.
|
||||
|
||||
Most of the work on software update code in |CL| was focused on adding new
|
||||
software to the system. We recommended that users reboot their system once in
|
||||
@@ -32,9 +33,9 @@ solutions such as the following:
|
||||
* Ask the user to restart the OS.
|
||||
|
||||
Both solutions are acceptable for many OSes. However, |CL| updates software
|
||||
automatically and users do not see notices from the updater unless they review
|
||||
the journal. |CL| requires a completely different solution, with the following
|
||||
requirements:
|
||||
automatically and users do not see notices from the updater unless they
|
||||
review the journal. |CL| requires a completely different solution, with the
|
||||
following requirements:
|
||||
|
||||
* Eliminate the guesswork about what to restart and under what circumstances.
|
||||
* Cannot restart everything. Many service daemons do not support an automatic
|
||||
@@ -81,7 +82,7 @@ Figure 1: Invoke :command:`clr-service-restart`.
|
||||
|
||||
:command:`clr-service-restart` implements a whitelist to identify which
|
||||
daemons can be restarted. The system administrator can customize the default
|
||||
|CL| OS whitelist using :option:`allow` or :option:`disallow` options for
|
||||
|CL| OS whitelist using *allow* or *disallow* options for
|
||||
restarting system services. When a software update occurs,
|
||||
:command:`clr-service-restart` consults the whitelist to see if a service
|
||||
daemon is allowed to be restarted or not. See the options section for
|
||||
@@ -91,32 +92,33 @@ details.
|
||||
Options for clr-service-restart
|
||||
*******************************
|
||||
|
||||
The :option:`allow` option identifies a daemon to restart after an OS software
|
||||
The *allow* option identifies a daemon to restart after an OS software
|
||||
update. The :command:`clr-service-restart` daemon creates a symlink in
|
||||
:file:`/etc/clr-service-restart` as a record. The example below tells
|
||||
:command:`clr-service-restart` to restart the :option:`tallow` daemon after an
|
||||
:command:`clr-service-restart` to restart the *tallow* daemon after an
|
||||
OS software update.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
sudo clr-service-restart allow tallow.service
|
||||
|
||||
The :option:`disallow` option tells :command:`clr-service-restart` not to
|
||||
The *disallow* option tells :command:`clr-service-restart` not to
|
||||
restart the specified daemon even if the OS defaults permit the daemon to be
|
||||
restarted. The :command:`clr-service-restart` daemon creates a symlink in
|
||||
:file:`/etc/clr-service-restart` that points to :file:`/dev/null` as a record.
|
||||
The example below tells :command:`clr-service-restart` not to restart the
|
||||
:option:`rngd` daemon after an OS software update.
|
||||
:file:`/etc/clr-service-restart` that points to :file:`/dev/null` as a
|
||||
record. The example below tells :command:`clr-service-restart` not to
|
||||
restart the *rngd* daemon after an OS software update.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
sudo clr-service-restart disallow rngd
|
||||
|
||||
The :option:`default` option makes :command:`clr-service-restart` revert back
|
||||
to the OS defaults and delete any symlink in :file:`/etc/clr-service-restart`.
|
||||
The example below tells :command:`clr-service-restart` to restart
|
||||
:option:`rngd` automatically again, because :option:`rngd` is whitelisted for
|
||||
automatic service restarts by default in |CL|.
|
||||
The *default* option makes :command:`clr-service-restart` revert back
|
||||
to the OS defaults and delete any symlink
|
||||
in :file:`/etc/clr-service-restart`. The example below
|
||||
tells :command:`clr-service-restart` to restart *rngd* automatically again,
|
||||
because *rngd* is whitelisted for automatic service restarts by default
|
||||
in |CL|.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
@@ -132,23 +134,24 @@ services are restarted after an OS software update.
|
||||
To monitor :command:`clr-service-restart`, use one or both options described
|
||||
below.
|
||||
|
||||
:option:`-n`
|
||||
.. option:: -n
|
||||
|
||||
This option makes :command:`clr-service-restart` perform no restarts. Instead
|
||||
it displays the services that could potentially be restarted. When used,
|
||||
:command:`clr-service-restart` outputs a list of messages showing:
|
||||
This option makes :command:`clr-service-restart` perform no restarts.
|
||||
Instead it displays the services that could potentially be restarted.
|
||||
When used, :command:`clr-service-restart` outputs a list of messages
|
||||
showing:
|
||||
|
||||
* Which service needs a restart.
|
||||
* What unit it is.
|
||||
* Why it needs a restart.
|
||||
* Which command is required to restart the unit.
|
||||
* Which service needs a restart.
|
||||
* What unit it is.
|
||||
* Why it needs a restart.
|
||||
* Which command is required to restart the unit.
|
||||
|
||||
:option:`-a`
|
||||
.. option:: -a
|
||||
|
||||
This option makes :command:`clr-service-restart` consider all system services,
|
||||
not only the ones that are whitelisted. Because the default whitelist in |CL|
|
||||
is relatively short, you can use this option to restart all impacted services
|
||||
when you log in on the system.
|
||||
This option makes :command:`clr-service-restart` consider all system
|
||||
services, not only the ones that are whitelisted. Because the default
|
||||
whitelist in |CL| is relatively short, you can use this option to
|
||||
restart all impacted services when you log in on the system.
|
||||
|
||||
If you pass both options (:option:`-a` and :option:`-n`),
|
||||
:command:`clr-service-restart` displays a complete list of system services
|
||||
@@ -166,12 +169,14 @@ telemetry record and sends it to the optional |CL| telemetry service if both
|
||||
conditions below are met:
|
||||
|
||||
* If a unit fails to automatically restart after an OS update.
|
||||
* If that unit resides in the system location :file:`/usr/lib/systemd/system`.
|
||||
* If that unit resides in the system
|
||||
location :file:`/usr/lib/systemd/system`.
|
||||
|
||||
If you do not install the |CL| telemetrics bundle, the data is discarded. If
|
||||
you install the telemetrics bundle and you opt to send telemetry, then the
|
||||
system unit name is sent to the |CL| telemetry service. We evaluate the report
|
||||
and update the whitelist to remove services that are not safe to restart.
|
||||
system unit name is sent to the |CL| telemetry service. We evaluate the
|
||||
report and update the whitelist to remove services that are not safe to
|
||||
restart.
|
||||
|
||||
Conclusion
|
||||
**********
|
||||
|
||||
@@ -129,7 +129,7 @@ system and its updates as the basis. Using this tool, system administrators
|
||||
can focus on the custom pieces their deployments require while staying on
|
||||
a controlled update stream.
|
||||
|
||||
To learn how to run an update of your system, visit our :ref:`update` page.
|
||||
To learn how to run an update of your system, visit our :ref:`using swupd <swupd-guide>` page.
|
||||
|
||||
.. [1] The software update technology for Clear Linux* OS for Intel
|
||||
Architecture was first presented at the Linux Plumbers conference in 2012.
|
||||
|
||||
@@ -0,0 +1,82 @@
|
||||
.. _telemetry-about:
|
||||
|
||||
Telemetrics
|
||||
###########
|
||||
|
||||
One of the key features of |CLOSIA| is telemetry, which is used to
|
||||
monitor system health. Telemetry enables developers to observe and proactively
|
||||
address issues before end users are impacted.
|
||||
|
||||
*Telemetrics* is a combination word made from:
|
||||
|
||||
* *Telemetry* which is sensing and reporting data.
|
||||
* *Analytics* which is using visualization and statistical inferencing to make
|
||||
sense of the reported data.
|
||||
|
||||
|CL| telemetry reports system-level debug/crash information using specialized probes. The
|
||||
probes monitor system tasks such as :abbr:`swupd (software updater)`, kernel
|
||||
oops, machine error checks, and BIOS error report table for unhandled hardware
|
||||
failures. Telemetry enables real-time issue reporting to allow system
|
||||
developers to quickly focus on an issue and monitor corrective actions.
|
||||
|
||||
|CL| telemetry is fully customizable and can be used during software development
|
||||
for debugging purposes. You can use **libtelemetry** in your code to create custom
|
||||
telemetry records. You can also use **telem-record-gen** in script files or call
|
||||
it from another program.
|
||||
|
||||
Architecture
|
||||
************
|
||||
|
||||
|CL| telemetry has two fundamental components, which are shown in figure 1:
|
||||
|
||||
* Client: generates and delivers records to the backend server via the network.
|
||||
* Backend: captures records sent from the client and displays the cumulative
|
||||
content through a specialized interface.
|
||||
|
||||
.. note::
|
||||
|
||||
If you want to capture your own records for analysis, you must set up
|
||||
your own backend server.
|
||||
|
||||
.. figure:: figures/telemetry-about-1.png
|
||||
:scale: 75%
|
||||
:alt: Clear Linux Telemetry Architecture.
|
||||
|
||||
Figure 1: Clear Linux Telemetry Architecture.
|
||||
|
||||
The telemetry client provides the front end of a complete telemetrics solution
|
||||
and includes the following components:
|
||||
|
||||
* **telemd**, a daemon that prepares the records to send to a telemetrics server or
|
||||
spools the records on disk in case it cannot successfully deliver them.
|
||||
* Probes that collect specific types of data from the operating system.
|
||||
* **libtelemetry**, that telemetrics probes use to create telemetrics records and
|
||||
send them to the telemd daemon for further processing.
|
||||
|
||||
The telemetry backend provides the server-side component of a complete telemetrics solution and
|
||||
consists of:
|
||||
|
||||
* Nginx web server.
|
||||
* Two Flask apps:
|
||||
|
||||
* Collector, an ingestion web app for records received from telemetrics-client probes.
|
||||
* TelemetryUI, a web app that exposes several views to visualize the telemetry data
|
||||
and also provides a REST API to perform queries.
|
||||
|
||||
* PostgreSQL as the underlying database server.
|
||||
|
||||
The default telemetry backend server reports back to the |CL| development team
|
||||
and is not viewable outside the Intel firewall. If you want to collect your
|
||||
own records, then you must set up your own telemetry backend server.
|
||||
|
||||
Next steps
|
||||
**********
|
||||
|
||||
To put this concept into practice, see the following resources:
|
||||
|
||||
* :ref:`telemetry-enable`
|
||||
* :ref:`telemetry-backend`
|
||||
* `Telemetry feature description`_
|
||||
|
||||
.. _`Telemetry feature description`:
|
||||
https://clearlinux.org/features/telemetry
|
||||
@@ -68,9 +68,9 @@ Create a RPM with autospec
|
||||
**************************
|
||||
|
||||
.. include:: ../../concepts/autospec-about.rst
|
||||
:Start-after: incl-autospec-overview:
|
||||
:start-after: incl-autospec-overview:
|
||||
:end-before: incl-autospec-overview-end:
|
||||
|
||||
|
||||
For a detailed explanation of how ``autospec`` works on |CL|, visit our
|
||||
:ref:`autospec-about` about page. For a general understanding of how RPMs
|
||||
work, we recommend visiting the `rpm website`_ or the
|
||||
|
||||
@@ -92,7 +92,7 @@ Configuration
|
||||
within the web hosting directory of **ICIS**. The following example shows
|
||||
an Ister configuration file:
|
||||
|
||||
.. code-block:: json
|
||||
.. code-block:: none
|
||||
|
||||
template=http://192.168.1.1:60000/icis/static/ister/ister.json
|
||||
|
||||
@@ -102,7 +102,7 @@ Configuration
|
||||
kernel parameter value. The following example shows an iPXE boot script
|
||||
with the ``isterconf`` parameter:
|
||||
|
||||
.. code-block:: json
|
||||
.. code-block:: none
|
||||
|
||||
#!ipxe
|
||||
kernel linux quiet init=/usr/lib/systemd/systemd-bootchart initcall_debug tsc=reliable no_timer_check noreplace-smp rw initrd=initrd isterconf=http://192.168.1.1:60000/icis/static/ister/ister.conf
|
||||
@@ -129,7 +129,7 @@ Configuration
|
||||
in the ``static`` directory within the web hosting directory of **ICIS**.
|
||||
The following example shows one such assignment:
|
||||
|
||||
.. code-block:: json
|
||||
.. code-block:: none
|
||||
|
||||
# MAC address,role
|
||||
00:01:02:03:04:05,ciao
|
||||
@@ -138,7 +138,7 @@ Configuration
|
||||
:file:`config.txt` file, a default role for those MAC address may be
|
||||
defined as follows:
|
||||
|
||||
.. code-block:: json
|
||||
.. code-block:: none
|
||||
|
||||
# MAC address,role
|
||||
default,ciao
|
||||
|
||||
@@ -190,7 +190,7 @@ For example:
|
||||
|
||||
|
||||
Additionally, to build a mix with your own custom RPMs, use the optional
|
||||
:option:`--local-rpms` flag, for example:
|
||||
*--local-rpms* flag, for example:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
@@ -203,7 +203,7 @@ the paths manually. For more information on using these directories or
|
||||
setting them up manually, see `Create or locate RPMs for the mix`_.
|
||||
|
||||
If all upstream |CL| bundles will be part of the mix, you can easily add
|
||||
them all during initialization with the optional :option:`--all-upstream` flag. For example:
|
||||
them all during initialization with the optional *--all-upstream* flag. For example:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
@@ -212,7 +212,7 @@ them all during initialization with the optional :option:`--all-upstream` flag.
|
||||
Finally, you may want to track the contents of your mixer workspace with a
|
||||
git repository. This is a great way to track changes to your mix's content
|
||||
or to revert to earlier versions if something goes wrong. Mixer can set this
|
||||
up automatically with the optional :option:`--git` flag, for example:
|
||||
up automatically with the optional *--git* flag, for example:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
@@ -231,7 +231,7 @@ Edit builder.conf
|
||||
To configure the mixer tool, edit the :file:`builder.conf` as needed.
|
||||
|
||||
The file :file:`builder.conf` is read automatically from the current
|
||||
workspace directory. Use the :option:`--config` flag during initialization
|
||||
workspace directory. Use the *--config* flag during initialization
|
||||
to specify an alternate path to the file as needed.
|
||||
|
||||
The :file:`builder.conf` file has different sections, for example:
|
||||
@@ -417,7 +417,7 @@ bundles. When listing bundles with this command, mixer automatically
|
||||
recurses through the includes to show every single bundle in the mix.
|
||||
|
||||
If you see an unexpected bundle in the list, that bundle is probably included
|
||||
in another bundle. Use the :option:`--tree` flag to get a better view of how
|
||||
in another bundle. Use the *--tree* flag to get a better view of how
|
||||
a bundle ended up in the mix, for example:
|
||||
|
||||
.. code-block:: bash
|
||||
@@ -459,7 +459,7 @@ with the following command:
|
||||
mixer bundle list local
|
||||
|
||||
Both the local and upstream :command:`bundle list` commands accept the
|
||||
:option:`--tree` flag to show a visual representation of the inclusion relationships
|
||||
*--tree* flag to show a visual representation of the inclusion relationships
|
||||
between the bundles in the mix.
|
||||
|
||||
Edit the bundles in the mix
|
||||
@@ -561,7 +561,7 @@ This command removes `bundle1` from the mix bundle list stored in your
|
||||
:file:`mixbundles` file. By default, this command does not remove the bundle
|
||||
definition file from your local bundles. To completely remove a bundle,
|
||||
including its local bundle definition file, use the following command with
|
||||
the :option:`--local` flag:
|
||||
the *--local* flag:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
@@ -569,7 +569,7 @@ the :option:`--local` flag:
|
||||
|
||||
By default, removing a local bundle file with this command removes the bundle
|
||||
from the mix as well. To only remove the local bundle definition file, use
|
||||
the following command with the :option:`--mix=false` flag:
|
||||
the following command with the *--mix=false* flag:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
@@ -599,7 +599,7 @@ can run this validation manually on `bundle1` with the following command:
|
||||
.. note:: This command can be useful in many circumstances. One example is
|
||||
when importing already-existing local bundles from other projects.
|
||||
|
||||
If you use the optional :option:`--strict` flag, the command additionally
|
||||
If you use the optional *--strict* flag, the command additionally
|
||||
checks if the rest of the bundle header fields can be parsed, if the bundle
|
||||
header fields are non-empty, and if the bundle header ``Title`` field and
|
||||
the bundle filename match. Perform a strict validation of `bundle1` with the
|
||||
@@ -624,7 +624,7 @@ git commit after you modify the mix bundle list or edit a bundle definition
|
||||
file.
|
||||
|
||||
All the :command:`mixer bundle` commands in the previous sections support an
|
||||
optional :option:`--git` flag. This flag automatically applies a git commit
|
||||
optional *--git* flag. This flag automatically applies a git commit
|
||||
when the command completes, for example:
|
||||
|
||||
.. code-block:: bash
|
||||
@@ -654,7 +654,7 @@ chroots.
|
||||
We have added a new chroot-builder to the mixer tool itself. While this is
|
||||
currently an experimental feature, you should use the new chroot-builder. To
|
||||
use the new chroot-builder, use the following command with the
|
||||
:option:`--new-chroots` flag:
|
||||
*--new-chroots* flag:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
@@ -681,7 +681,7 @@ By default, mixer uses the legacy `swupd-server` to generate the update
|
||||
content. However, we have built a new implementation into the mixer tool
|
||||
itself. While this is currently an experimental feature, you should use the
|
||||
new `swupd-server`. To use the the new `swupd-server`, use the following
|
||||
command with the :option:`--new-swupd` flag:
|
||||
command with the *--new-swupd* flag:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
@@ -704,7 +704,7 @@ mix version to another, with the following command:
|
||||
|
||||
The pack-maker generates all delta packs for the bundles changed from
|
||||
`PAST_VERSION` to `MIX_VERSION`. If your `STATE_DIR` is in a different
|
||||
location, specify the location with the :option:`-S` flag. Mixer cannot
|
||||
location, specify the location with the *-S* flag. Mixer cannot
|
||||
create delta packs for the first build because the update is from version 0.
|
||||
Version 0 implicitly has no content. Thus, mixer can generate no deltas.
|
||||
|
||||
@@ -754,7 +754,7 @@ With the `ister` tool configured, build the image with the following command:
|
||||
|
||||
Mixer automatically looks for the :file:`release-image-config.json` file, but
|
||||
you can freely choose the filename. To use a different name, simply pass the
|
||||
:option:`--template` flag when creating your image, for example:
|
||||
*--template* flag when creating your image, for example:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
@@ -762,7 +762,7 @@ you can freely choose the filename. To use a different name, simply pass the
|
||||
|
||||
By default, `ister` uses the format version of the build machine it runs on.
|
||||
Therefore, if the format you are building differs from the format of the |CL|
|
||||
OS you are building on, you must use the :option:`--format <FORMAT_NUMBER>`
|
||||
OS you are building on, you must use the *--format <FORMAT_NUMBER>*
|
||||
flag. Find the current format version of your OS with the following command:
|
||||
|
||||
.. code-block:: bash
|
||||
@@ -780,14 +780,14 @@ Increment the mix version number for the next mix with the following command:
|
||||
|
||||
This command automatically updates the mix version stored in the
|
||||
:file:`mixversion` file, incrementing it by 10. To increment by a different
|
||||
amount, use the :option:`--increment` flag, for example:
|
||||
amount, use the *--increment* flag, for example:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
mixer versions update --increment 100
|
||||
|
||||
Alternatively, to set the mix version to a specific value, use the
|
||||
:option:`--mix-version` flag, for example:
|
||||
*--mix-version* flag, for example:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
@@ -802,7 +802,7 @@ If you have been tracking your workspace with git, you can restore the mix to
|
||||
an earlier state. However, be careful when "rewriting history" if you have
|
||||
published the mix content to users already.
|
||||
|
||||
Use the following command with the the :option:`--upstream-version` flag to
|
||||
Use the following command with the the *--upstream-version* flag to
|
||||
update the upstream version of |CL| used as a base for the mix:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
@@ -7,7 +7,7 @@ Use swupd
|
||||
valid system updates and, if found, download and install them. It can also
|
||||
perform verification of the system software.
|
||||
|
||||
|CL| uses :ref:`bundles-about<bundles>` as the base abstraction for
|
||||
|CL| uses :ref:`bundles <bundles-about>` as the base abstraction for
|
||||
installing functionality on top of the core operating system. Use the `swupd`
|
||||
tool to install and remove bundles.
|
||||
|
||||
|
||||
@@ -5,11 +5,11 @@ Enable and disable telemetry in Clear Linux
|
||||
|
||||
|CLOSIA| includes a telemetry solution as part of the OS that records events
|
||||
of interest and reports them back to the development team via the telemetrics
|
||||
daemon, :command:`telemd`. This functionality is maintained in the
|
||||
``telemetrics`` software bundle.
|
||||
daemon, **telemd**. This functionality is maintained in the
|
||||
**telemetrics** software bundle.
|
||||
|
||||
.. note::
|
||||
The telemetry functionality adheres to `Intel's privacy policies`_
|
||||
The telemetry functionality adheres to `Intel privacy policies`_
|
||||
regarding the collection and use of :abbr:`PII (Personally Identifiable
|
||||
Information)` and is open source. Specifically, no intentionally
|
||||
identifiable information about the user or system owner is collected.
|
||||
@@ -20,10 +20,10 @@ redirect where the records go if they wish to collect records for themselves.
|
||||
Install the telemetry software bundle
|
||||
*************************************
|
||||
|
||||
During the initial installation of |CL| you are requested to join the
|
||||
During the initial installation of |CL|, you are requested to join the
|
||||
stability enhancement program and allow |CLOSIA| to collect anonymous reports
|
||||
to improve system stability. If you chose not to join this program at that
|
||||
time then the telemetry software bundle is not added to your system.
|
||||
to improve system stability. If you choose not to join this program, then the
|
||||
telemetry software bundle is not added to your system.
|
||||
|
||||
To install the telemetry bundle, enter the following command as either the
|
||||
root user or with :command:`sudo` privileges:
|
||||
@@ -104,9 +104,13 @@ To completely remove telemetrics from your system, use the command
|
||||
Additional resources
|
||||
********************
|
||||
|
||||
https://clearlinux.org/features/telemetry
|
||||
* `Telemetry feature description`_
|
||||
* :ref:`Telemetry architecture<telemetry-about>`
|
||||
* :ref:`telemetry-backend`
|
||||
* https://github.com/clearlinux/telemetrics-client
|
||||
|
||||
https://github.com/clearlinux/telemetrics-client
|
||||
|
||||
.. _`Intel's privacy policies`:
|
||||
.. _`Intel privacy policies`:
|
||||
https://www.intel.com/content/www/us/en/privacy/intel-privacy-notice.html
|
||||
|
||||
.. _`Telemetry feature description`:
|
||||
https://clearlinux.org/features/telemetry
|
||||
|
||||
@@ -73,8 +73,7 @@ This style guide applies to the following technical content:
|
||||
|
||||
We are always grateful to receive content contributions and are happy to help
|
||||
via our mailing list or our IRC channel, #clearlinux. If you have found a
|
||||
problem with one of our documents, please file a bug report. Use our
|
||||
:ref:`bug-report` to submit the bug.
|
||||
problem with one of our documents, please file a `bug report`_.
|
||||
|
||||
Tone and audience
|
||||
*****************
|
||||
@@ -86,12 +85,12 @@ Remain professional in your writing and carry an undertone of cordiality,
|
||||
respect, and cooperation.
|
||||
|
||||
Assume your audience has about the same level of technical understanding and
|
||||
expertise as you did when you first started collaborating. Do not talk down to
|
||||
our readers but do not assume they know everything about the subject.
|
||||
expertise as you did when you first started collaborating. Do not talk down
|
||||
to our readers but do not assume they know everything about the subject.
|
||||
Offer brief explanations or summaries of "common knowledge" if a
|
||||
significant portion of readers might benefit.
|
||||
|
||||
All contributions must follow our :ref:`code-of-conduct`.
|
||||
All contributions must follow our `code of conduct`_.
|
||||
|
||||
Methodology
|
||||
***********
|
||||
@@ -126,7 +125,7 @@ decisions are explained in the respective section.
|
||||
|
||||
This guide takes precedence over all other style guides in all cases. In
|
||||
cases where the guide does not address the issue at hand, please report the
|
||||
issue to the `mailing list`_ using our :ref:`bug-report`.
|
||||
issue to the `mailing list`_ using our `bug report`_.
|
||||
|
||||
Use the Merriam-Webster's Collegiate Dictionary to determine correct
|
||||
spelling, hyphenation, and usage.
|
||||
@@ -136,3 +135,5 @@ spelling, hyphenation, and usage.
|
||||
.. _documentation section: https://clearlinux.org/documentation
|
||||
.. _Clear Linux documentation repository:
|
||||
https://github.com/clearlinux/clear-linux-documentation
|
||||
.. _bug report: https://github.com/clearlinux/distribution/issues
|
||||
.. _code of conduct: https://clearlinux.org/community/code-of-conduct
|
||||
|
||||
@@ -6,112 +6,157 @@ Inline Markup
|
||||
Sphinx supports a large number of inline markup elements called roles. The
|
||||
|CLOSIA| documentation encourages the use of as many roles as
|
||||
possible. Thus, you can use any additional roles supported by Sphinx
|
||||
even if not listed here. Please refer to the `Sphinx Inline Markup`_
|
||||
not listed here. Please refer to the `Sphinx reStructuredText Markup`_
|
||||
documentation for the full list of supported roles.
|
||||
|
||||
The following markup is required in every instance unless otherwise
|
||||
specified. Each item provides examples and a template for the correct use of
|
||||
the roles.
|
||||
specified. Each item provides a syntax example followed by the rendered
|
||||
result.
|
||||
|
||||
* Use the `:abbr:` abbreviation role to define an acronym or an initialism.
|
||||
Abbreviations
|
||||
Use the `:abbr:` abbreviation role to define an acronym or an initialism.
|
||||
Add the abbreviation markup only once per file. After the abbreviation, the
|
||||
acronym can be used without further definition or markup. Do not use
|
||||
abbreviation markup on headings.
|
||||
|
||||
:abbr:`API (Application Program Interface)`
|
||||
::
|
||||
|
||||
Template:
|
||||
:abbr:`API (Application Program Interface)`
|
||||
|
||||
``:abbr:`TIA (This Is an Abbreviation)```
|
||||
.. parsed-literal::
|
||||
|
||||
* Use the `:command:` role when the name of a specific command is used in a
|
||||
:abbr:`API (Application Program Interface)`
|
||||
|
||||
OS Commands
|
||||
Use the `:command:` role when the name of a specific command is used in a
|
||||
paragraph for emphasis. Use the ``.. code-block::`` directive for fully
|
||||
actionable commands in a series of steps.
|
||||
|
||||
:command:`make`
|
||||
::
|
||||
|
||||
Template:
|
||||
:command:`make`
|
||||
|
||||
``:command:`command```
|
||||
.. parsed-literal::
|
||||
|
||||
* Use the `:option:` role to emphasize the name of a command option
|
||||
with or without its value. This markup is usually employed in
|
||||
combination with the `:command:` role. For example:
|
||||
:command:`make`
|
||||
|
||||
:option:`-f`
|
||||
:option:`--all`
|
||||
:option:`-o output.xsl`
|
||||
The :command:`pandoc` command can be used without the :option:`-o`
|
||||
option, creating an output file with the same name as the source
|
||||
but a different extension.
|
||||
Commandline Options
|
||||
In most cases, use asterisks "*" to emphasize the name of a command
|
||||
option.
|
||||
|
||||
Template:
|
||||
::
|
||||
|
||||
``:option:`Option```
|
||||
Use the *-p* option to print the file.
|
||||
|
||||
* Use the `:file:` role to emphasize a filename or directory. Do not use the
|
||||
.. parsed-literal::
|
||||
|
||||
Use the *-p* option to print the file.
|
||||
|
||||
However, if you have defined an ``.. option::`` directive, you may
|
||||
use the `:option:` role. Note that the result links back to the
|
||||
option definition.
|
||||
|
||||
.. code-block:: rest
|
||||
|
||||
.. option: -o <output.xsl>
|
||||
|
||||
Description of the -o option
|
||||
|
||||
The :command:`pandoc` command can be used without :option:`-o`
|
||||
|
||||
.. option:: -o <output.xsl>
|
||||
|
||||
Description of the -o option
|
||||
|
||||
.. parsed-literal::
|
||||
|
||||
The :command:`pandoc` command can be used without :option:`-o`
|
||||
|
||||
Files
|
||||
Use the `:file:` role to emphasize a filename or directory. Do not use the
|
||||
role inside a code-block but use it inside all notices that contain files
|
||||
or directories. Place variable parts of the path or filename in brackets
|
||||
`{}`.
|
||||
|
||||
:file:`collaboration.rst` :file:`doc/{user}/collaboration/figures`
|
||||
.. code-block:: rest
|
||||
|
||||
Template:
|
||||
:file:`collaboration.rst`
|
||||
|
||||
``:file:`filename.ext` :file:`path/or/directory```
|
||||
:file:`doc/{user}/collaboration/figures`
|
||||
|
||||
* Use the `:guilabel:` role to emphasize elements of a graphic
|
||||
.. parsed-literal::
|
||||
|
||||
:file:`collaboration.rst`
|
||||
|
||||
:file:`doc/{user}/collaboration/figures`
|
||||
|
||||
GUI Objects
|
||||
Use the `:guilabel:` role to emphasize elements of a graphic
|
||||
user interface within a description. It replaces the use of quotes
|
||||
when referring to windows' names, button labels, options, or single
|
||||
menu elements. Always follow the marked element with the appropriate
|
||||
noun. For example:
|
||||
|
||||
In the :guilabel:`Tools` menu.
|
||||
Press the :guilabel:`OK` button.
|
||||
In the :guilabel:`Settings` window you find the :guilabel:`Hide
|
||||
Content` option.
|
||||
::
|
||||
|
||||
Template:
|
||||
In the :guilabel:`Tools` menu, click :guilabel:`settings`.
|
||||
|
||||
``:guilabel:`UI-Label```
|
||||
.. parsed-literal::
|
||||
|
||||
* Use the `:menuselection:` role to indicate the navigation through a menu
|
||||
In the :guilabel:`Tools` menu, click :guilabel:`settings`.
|
||||
|
||||
Menu Navigation
|
||||
Use the `:menuselection:` role to indicate the navigation through a menu
|
||||
ending with a selection. Every `:menuselection:` element can have up to two
|
||||
menu steps before the selected item. If more than two steps are required,
|
||||
it can be combined with a `:guilabel:` or with another `:menuselection:`
|
||||
element. For example:
|
||||
|
||||
:menuselection:`File --> Save As --> PDF`
|
||||
Go to :guilabel:`File` and select :menuselection:`Import --> Data
|
||||
Base --> MySQL`.
|
||||
Go to :menuselection:`Window --> View` and select :menuselection:`
|
||||
Perspective --> Other --> C++`
|
||||
::
|
||||
|
||||
Template:
|
||||
Go to :guilabel:`File` and select :menuselection:`Import --> Data Base --> MySQL`.
|
||||
|
||||
``:menuselection:`1stMenu --> 2ndMenu --> Selection```
|
||||
Go to :menuselection:`Window --> View` and select :menuselection:`Perspective --> Other --> C++`
|
||||
|
||||
* Use the `:makevar:` role to emphasize the name of a Makefile variable.
|
||||
.. parsed-literal::
|
||||
|
||||
Go to :guilabel:`File` and select :menuselection:`Import --> Data Base --> MySQL`.
|
||||
|
||||
Go to :menuselection:`Window --> View` and select :menuselection:`Perspective --> Other --> C++`
|
||||
|
||||
Makefile Variables
|
||||
Use the `:makevar:` role to emphasize the name of a Makefile variable.
|
||||
The role can include only the name of the variable or the variable
|
||||
plus its value.
|
||||
|
||||
:makevar:`PLATFORM_CONFIG`
|
||||
:makevar:`PLATFORM_CONFIG=basic_atom`
|
||||
::
|
||||
|
||||
Template:
|
||||
:makevar:`PLATFORM_CONFIG`
|
||||
|
||||
``:makevar:`VARIABLE```
|
||||
:makevar:`PLATFORM_CONFIG=basic_atom`
|
||||
|
||||
* Use the `:envvar:` role to emphasize the name of environment
|
||||
.. parsed-literal::
|
||||
|
||||
:makevar:`PLATFORM_CONFIG`
|
||||
|
||||
:makevar:`PLATFORM_CONFIG=basic_atom`
|
||||
|
||||
Environment Variables
|
||||
Use the `:envvar:` role to emphasize the name of environment
|
||||
variables. Just as with `:makevar:`, the markup can include only the
|
||||
name of the variable or the variable plus its value.
|
||||
|
||||
:envvar:`ZEPHYR_BASE`
|
||||
:envvar:`QEMU_BIN_PATH=/usr/local/bin`
|
||||
::
|
||||
|
||||
Template:
|
||||
:envvar:`ZEPHYR_BASE`
|
||||
|
||||
:envvar:`QEMU_BIN_PATH=/usr/local/bin`
|
||||
|
||||
``:envvar:`ENVIRONMENT_VARIABLE```
|
||||
.. parsed-literal::
|
||||
|
||||
.. _Sphinx Inline Markup:
|
||||
http://sphinx-doc.org/markup/inline.html#inline-markup
|
||||
:envvar:`ZEPHYR_BASE`
|
||||
|
||||
:envvar:`QEMU_BIN_PATH=/usr/local/bin`
|
||||
|
||||
.. _Sphinx reStructuredText Markup:
|
||||
http://www.sphinx-doc.org/en/master/usage/restructuredtext/index.html
|
||||
@@ -14,4 +14,5 @@ features.
|
||||
how-to-clear-overview
|
||||
collaboration/collaboration
|
||||
compatible-kernels
|
||||
system-requirements
|
||||
system-requirements
|
||||
image-types
|
||||
|
||||
@@ -390,7 +390,7 @@ For this tutorial, we are using the |CL| Basic SKU for our VM.
|
||||
|
||||
If you have already defined your public/private SSH key pair and they
|
||||
are stored in your :file:`$HOME/.ssh` directory, you do not need to
|
||||
include the :option:`--generate-ssh-keys` option.
|
||||
include the *--generate-ssh-keys* option.
|
||||
|
||||
Your output from this command will look similar to this output, where
|
||||
[user] is your user name:
|
||||
|
||||
@@ -141,12 +141,12 @@ an the official Docker image for nginx, an open source reverse proxy server.
|
||||
detailed :command:`docker run` switches and syntax, refer to the
|
||||
`Docker Documentation`_ .
|
||||
|
||||
* The :option:`--name` switch lets you provide a friendly name to
|
||||
* The *--name* switch lets you provide a friendly name to
|
||||
target the container for future operations
|
||||
|
||||
* The :option:`-d` switch launches the container in the background
|
||||
* The *-d* switch launches the container in the background
|
||||
|
||||
* The :option:`-p` switch allows the container's HTTP port (80) to be
|
||||
* The *-p* switch allows the container's HTTP port (80) to be
|
||||
accessible from the Clear Linux host on port 8080
|
||||
|
||||
#. You can access the Welcome to Nginx! splash page running in the container
|
||||
|
||||
@@ -184,7 +184,7 @@ You can see the multiple clones of the `foo` function:
|
||||
The cloned functions use AVX2 registers and vectorized instructions. To
|
||||
verify, enter the following commands:
|
||||
|
||||
.. code-block:: assembly
|
||||
.. code-block:: asm
|
||||
|
||||
vpaddd (%r8,%rax,1),%ymm0,%ymm0
|
||||
vmovdqu %ymm0,(%rcx,%rax,1)
|
||||
@@ -213,53 +213,54 @@ To follow the same approach with a package like FFT, we must use the
|
||||
For example, the :file:`fftw-3.3.6-pl2/tools/fftw-wisdom.c.patch` file
|
||||
generates the following patches:
|
||||
|
||||
.. code-block:: git
|
||||
.. code-block:: diff
|
||||
:linenos:
|
||||
|
||||
1 --- fftw-3.3.6-pl2/libbench2/verify-lib.c 2017-01-27 21:08:13.000000000 +0000
|
||||
2 +++ fftw-3.3.6-pl2/libbench2/verify-lib.c~ 2017-09-27 17:49:21.913802006 +0000
|
||||
3 @@ -33,6 +33,7 @@
|
||||
4
|
||||
5 double dmax(double x, double y) { return (x > y) ? x : y; }
|
||||
6
|
||||
7 +__attribute__((target_clones("avx2","arch=atom","default")))
|
||||
8 static double aerror(C *a, C *b, int n)
|
||||
9 {
|
||||
10 if (n > 0) {
|
||||
11 @@ -111,6 +112,7 @@
|
||||
12 }
|
||||
13
|
||||
14 /* make array hermitian */
|
||||
15 +__attribute__((target_clones("avx2","arch=atom","default")))
|
||||
16 void mkhermitian(C *A, int rank, const bench_iodim *dim, int stride)
|
||||
17 {
|
||||
18 if (rank == 0)
|
||||
19 @@ -148,6 +150,7 @@
|
||||
20 }
|
||||
21
|
||||
22 /* C = A + B */
|
||||
23 +__attribute__((target_clones("avx2","arch=atom","default")))
|
||||
24 void aadd(C *c, C *a, C *b, int n)
|
||||
25 {
|
||||
26 int i;
|
||||
27 @@ -159,6 +162,7 @@
|
||||
28 }
|
||||
29
|
||||
30 /* C = A - B */
|
||||
31 +__attribute__((target_clones("avx2","arch=atom","default")))
|
||||
32 void asub(C *c, C *a, C *b, int n)
|
||||
33 {
|
||||
34 int i;
|
||||
35 @@ -170,6 +174,7 @@
|
||||
36 }
|
||||
37
|
||||
38 /* B = rotate left A (complex) */
|
||||
39 +__attribute__((target_clones("avx2","arch=atom","default")))
|
||||
40 void arol(C *b, C *a, int n, int nb, int na)
|
||||
41 {
|
||||
42 int i, ib, ia;
|
||||
43 @@ -192,6 +197,7 @@
|
||||
44 }
|
||||
45 }
|
||||
--- fftw-3.3.6-pl2/libbench2/verify-lib.c 2017-01-27 21:08:13.000000000 +0000
|
||||
+++ fftw-3.3.6-pl2/libbench2/verify-lib.c~ 2017-09-27 17:49:21.913802006 +0000
|
||||
@@ -33,6 +33,7 @@
|
||||
|
||||
double dmax(double x, double y) { return (x > y) ? x : y; }
|
||||
|
||||
+__attribute__((target_clones("avx2","arch=atom","default")))
|
||||
static double aerror(C *a, C *b, int n)
|
||||
{
|
||||
if (n > 0) {
|
||||
@@ -111,6 +112,7 @@
|
||||
}
|
||||
|
||||
/* make array hermitian */
|
||||
+__attribute__((target_clones("avx2","arch=atom","default")))
|
||||
void mkhermitian(C *A, int rank, const bench_iodim *dim, int stride)
|
||||
{
|
||||
if (rank == 0)
|
||||
@@ -148,6 +150,7 @@
|
||||
}
|
||||
|
||||
/* C = A + B */
|
||||
+__attribute__((target_clones("avx2","arch=atom","default")))
|
||||
void aadd(C *c, C *a, C *b, int n)
|
||||
{
|
||||
int i;
|
||||
@@ -159,6 +162,7 @@
|
||||
}
|
||||
|
||||
/* C = A - B */
|
||||
+__attribute__((target_clones("avx2","arch=atom","default")))
|
||||
void asub(C *c, C *a, C *b, int n)
|
||||
{
|
||||
int i;
|
||||
@@ -170,6 +174,7 @@
|
||||
}
|
||||
|
||||
/* B = rotate left A (complex) */
|
||||
+__attribute__((target_clones("avx2","arch=atom","default")))
|
||||
void arol(C *b, C *a, int n, int nb, int na)
|
||||
{
|
||||
int i, ib, ia;
|
||||
@@ -192,6 +197,7 @@
|
||||
}
|
||||
}
|
||||
|
||||
With these patches, we can select where to apply the FMV technology making
|
||||
bringing architecture-based optimizations to application code even easier.
|
||||
|
||||
@@ -3,16 +3,16 @@
|
||||
Install Kata Containers\*
|
||||
#########################
|
||||
|
||||
This tutorial describes how to install, configure and run Kata Containers\* on
|
||||
|CLOSIA|. Kata Containers is an open source project dedicated to the
|
||||
development of a lightweight implementation of Virtual Machines (VMs)
|
||||
offering the speed of containers and the security of VMs.
|
||||
This tutorial describes how to install, configure, and run `Kata Containers`_
|
||||
on |CLOSIA|. Kata Containers is an open source project developing a
|
||||
lightweight implementation of :abbr:`VMs (Virtual Machines)` that offer the
|
||||
speed of containers and the security of VMs.
|
||||
|
||||
Prerequisites
|
||||
*************
|
||||
|
||||
This tutorial assumes you have installed |CL| on your host system.
|
||||
For detailed instructions on installing |CL| on a bare metal system, visit
|
||||
For detailed instructions on installing |CL| on a bare metal system, follow
|
||||
the :ref:`bare metal installation tutorial<bare-metal-install>`.
|
||||
|
||||
If you have Clear Containers installed on your |CL| system, then follow the
|
||||
@@ -28,24 +28,23 @@ Install Kata Containers
|
||||
***********************
|
||||
|
||||
Kata Containers is included in the :file:`containers-virt` bundle. To install the
|
||||
framework, enter:
|
||||
framework, enter the following command:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
sudo swupd bundle-add containers-virt
|
||||
|
||||
Configure Docker\* to use Kata Containers by default
|
||||
Configure Docker\* to use Kata Containers by default.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
sudo mkdir -p /etc/systemd/system/docker.service.d/
|
||||
cat <<EOF | sudo tee /etc/systemd/system/docker.service.d/kata-containers.conf
|
||||
cat <<EOF | sudo tee /etc/systemd/system/docker.service.d/51-runtime.conf
|
||||
[Service]
|
||||
ExecStart=
|
||||
ExecStart=/usr/bin/dockerd -D --add-runtime kata-runtime=/usr/bin/kata-runtime --default-runtime=kata-runtime
|
||||
Environment="DOCKER_DEFAULT_RUNTIME=--default-runtime kata-runtime"
|
||||
EOF
|
||||
|
||||
Restart the Docker and Kata Containers systemd services
|
||||
|
||||
Restart the Docker and Kata Containers systemd services.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
@@ -61,9 +60,8 @@ Run Kata Containers
|
||||
|
||||
.. note::
|
||||
|
||||
In cases where it is necessary to use a proxy server and your proxy
|
||||
environment variables are already set, run the following commands as
|
||||
a shell script to configure Docker:
|
||||
If you use a proxy server and your proxy environment variables are already
|
||||
set, run the following commands as a shell script to configure Docker:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
@@ -81,24 +79,28 @@ Run Kata Containers
|
||||
|
||||
**Congratulations!**
|
||||
|
||||
You have successfully installed and set up Kata Containers on |CLOSIA|.
|
||||
You've successfully installed and set up Kata Containers on |CLOSIA|.
|
||||
|
||||
More information about Docker in |CLOSIA|
|
||||
*****************************************
|
||||
More information about Docker
|
||||
*****************************
|
||||
|
||||
Docker on |CLOSIA| provides a docker.service service file to start the Docker
|
||||
daemon. The daemon will use runc or kata-runtime depending on
|
||||
the environment:
|
||||
Docker on |CLOSIA| provides a :file:`docker.service` file to start the Docker
|
||||
daemon. The daemon will use runc or kata-runtime depending on the
|
||||
environment:
|
||||
|
||||
If you are running |CL| on bare metal or on a VM with Nested
|
||||
Virtualization activated, Docker will use kata-runtime as the
|
||||
default runtime. If you are running |CL| on a VM without Nested
|
||||
Virtualization, Docker will use runc as the default runtime. It is not
|
||||
necessary to manually configure the runtime for Docker, since Docker itself
|
||||
will automatically use the one supported by the system.
|
||||
* If you are running |CL| on bare metal or on a VM with Nested
|
||||
Virtualization activated, Docker uses kata-runtime as the
|
||||
default runtime.
|
||||
* If you are running |CL| on a VM without Nested Virtualization,
|
||||
Docker uses runc as the default runtime.
|
||||
|
||||
To check which runtime your system is using, run:
|
||||
You do not need to manually configure the runtime for Docker, because
|
||||
it automatically uses the runtime supported by the system.
|
||||
|
||||
Check which runtime your system is using with the command:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
sudo docker info | grep runtime
|
||||
|
||||
.. _Kata Containers: https://katacontainers.io/
|
||||
|
||||
@@ -37,14 +37,6 @@ Make any required changes before continuing this process.
|
||||
|
||||
You do not need to manually remove any Clear Containers packages.
|
||||
|
||||
Disable Clear Containers manager configuration
|
||||
**********************************************
|
||||
|
||||
Remove the Clear Containers configuration file:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
sudo rm /etc/systemd/system/docker.service.d/clear-containers.conf
|
||||
|
||||
Enable Kata Containers as default
|
||||
*********************************
|
||||
@@ -54,10 +46,9 @@ Enable Kata Containers as default
|
||||
.. code-block:: bash
|
||||
|
||||
sudo mkdir -p /etc/systemd/system/docker.service.d/
|
||||
cat <<EOF | sudo tee /etc/systemd/system/docker.service.d/kata-containers.conf
|
||||
cat <<EOF | sudo tee /etc/systemd/system/docker.service.d/51-runtime.conf
|
||||
[Service]
|
||||
ExecStart=
|
||||
ExecStart=/usr/bin/dockerd -D --add-runtime kata-runtime=/usr/bin/kata-runtime --default-runtime=kata-runtime
|
||||
Environment="DOCKER_DEFAULT_RUNTIME=--default-runtime kata-runtime"
|
||||
EOF
|
||||
|
||||
#. Restart the Docker systemd services.
|
||||
|
||||
@@ -53,7 +53,7 @@ RAM and a 360GB SSD. Table 1 lists the information specific to the
|
||||
installation of the tested operating systems.
|
||||
|
||||
.. csv-table:: Table 1: OS specific installation information
|
||||
:header: # , OS, Version, Partition Size [1], Swap Size [2], EFI Partition Size [3], Download Link
|
||||
:header: # , OS, Version, Partition Size [#]_, Swap Size [#]_, EFI Partition Size [#]_, Download Link
|
||||
|
||||
1,Clear Linux,16140,50 GB,8 GB,1 GB,https://download.clearlinux.org/releases/16140/clear/
|
||||
2,Windows,Server 2016,50 GB,N/A,Shared with #1,https://www.microsoft.com/en-us/cloud-platform/windows-server
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
.. _telemtry-backend:
|
||||
.. _telemetry-backend:
|
||||
|
||||
Create a telemetry backend server in Clear Linux
|
||||
################################################
|
||||
@@ -100,35 +100,35 @@ Run the deploy.sh script to install the backend server
|
||||
The :command:`deploy.sh` is a bash shell script that allows you to perform the
|
||||
following actions:
|
||||
|
||||
* :option:`deploy` - install a complete instance of the telemetrics backend
|
||||
* *deploy* - install a complete instance of the telemetrics backend
|
||||
server and all required components. This is the default action if no
|
||||
:option:`-a` argument is given on the command line.
|
||||
* :option:`install` - installs and enables all required components for the
|
||||
*-a* argument is given on the command line.
|
||||
* *install* - installs and enables all required components for the
|
||||
telemetrics backend server.
|
||||
* :option:`migrate` - migrate database to new schema.
|
||||
* :option:`resetdb` - reset the database.
|
||||
* :option:`restart` - restart the nginx and uWSGI services.
|
||||
* :option:`uninstall` - uninstall all packages.
|
||||
* *migrate* - migrate database to new schema.
|
||||
* *resetdb* - reset the database.
|
||||
* *restart* - restart the nginx and uWSGI services.
|
||||
* *uninstall* - uninstall all packages.
|
||||
|
||||
.. note::
|
||||
|
||||
The :option:`uninstall` option does not perform any actions if the
|
||||
The *uninstall* option does not perform any actions if the
|
||||
distro is set to |CL| and will only uninstall packages if the distro is
|
||||
Ubuntu
|
||||
|
||||
Next, we install the telemetrics backend server with the following options:
|
||||
|
||||
* :option:`-a install` to perform an install
|
||||
* :option:`-d clr` to install to a |CL| distro
|
||||
* :option:`-H localhost` to set the domain to localhost
|
||||
* *-a install* to perform an install
|
||||
* *-d clr* to install to a |CL| distro
|
||||
* *-H localhost* to set the domain to localhost
|
||||
|
||||
We do not need to set the following options since the values are set to the
|
||||
correct values we want by default:
|
||||
|
||||
* :option:`-r https://github.com/clearlinux/telemetrics-backend` sets the
|
||||
* *-r https://github.com/clearlinux/telemetrics-backend* sets the
|
||||
repo location for :command:`git` to clone from.
|
||||
* :option:`-s master` to set the location, or branch.
|
||||
* :option:`-t git` to set the source type to git.
|
||||
* *-s master* to set the location, or branch.
|
||||
* *-t git* to set the source type to git.
|
||||
|
||||
.. caution::
|
||||
The :file:`deploy.sh` shell script has minimal error checking and makes
|
||||
@@ -464,14 +464,17 @@ it.
|
||||
Additional resources
|
||||
********************
|
||||
|
||||
https://clearlinux.org/features/telemetry
|
||||
|
||||
https://github.com/clearlinux/telemetrics-client
|
||||
|
||||
https://github.com/clearlinux/telemetrics-backend
|
||||
* `Telemetry feature description`_
|
||||
* :ref:`Telemetry architecture<telemetry-about>`
|
||||
* :ref:`telemetry-enable`
|
||||
* https://github.com/clearlinux/telemetrics-client
|
||||
* https://github.com/clearlinux/telemetrics-backend
|
||||
|
||||
.. _`Clear Linux telemetry backend server overview`:
|
||||
https://github.com/clearlinux/telemetrics-backend
|
||||
|
||||
.. _`Intel privacy policies`:
|
||||
https://www.intel.com/content/www/us/en/privacy/intel-privacy-notice.html
|
||||
|
||||
.. _`Telemetry feature description`:
|
||||
https://clearlinux.org/features/telemetry
|
||||
|
||||
@@ -295,3 +295,6 @@ texinfo_documents = [
|
||||
|
||||
# If true, generates permalinks on the HTML output.
|
||||
html_add_permalinks = ""
|
||||
|
||||
#suppresses warnings for options that aren't referenced
|
||||
#suppress_warnings = ["ref.option"]
|
||||
|
||||
Reference in New Issue
Block a user