mirror of
https://github.com/clearlinux/clear-linux-documentation.git
synced 2026-07-06 20:59:18 +00:00
Merge branch 'master' into add/ps-deploy-at-scale-guide
This commit is contained in:
puneetse
@@ -3,16 +3,23 @@
|
||||
Clear Linux\* Project for Intel® Architecture
|
||||
#############################################
|
||||
|
||||
Welcome to the |CLOSIA| documentation pages. Our documentation is split into
|
||||
five sections: Get started, Concepts, Guides, Tutorials, and Reference.
|
||||
Under :ref:`get-started`, you can find information about installing |CL| on
|
||||
bare metal, in a virtual environment, or as a live image on a USB stick. Under
|
||||
the :ref:`concepts` section, you can find detailed technical information about
|
||||
the |CL| features. The :ref:`guides` section contains step-by-step
|
||||
instructions to complete common tasks. The :ref:`tutorials` section contains
|
||||
step-by-step instructions to complete the installation and configuration of
|
||||
tools needed for a specific use case. Lastly, the :ref:`reference` section
|
||||
contains information providing additional context or details.
|
||||
Welcome to the |CLOSIA| documentation pages. Our documentation is divided
|
||||
into five sections:
|
||||
|
||||
* :ref:`get-started` Information about installing |CL| on
|
||||
bare metal, in a virtual environment, or as a live image on a USB stick
|
||||
|
||||
* :ref:`concepts` Detailed technical information about
|
||||
|CL| features and what differentiates it from other |CL| distros
|
||||
|
||||
* :ref:`guides` Step-by-step instructions on how to complete
|
||||
common tasks that help you leverage |CL| native features
|
||||
|
||||
* :ref:`tutorials` Step-by-step instructions for applying specific use
|
||||
cases with |CL| that often involve third-party tools
|
||||
|
||||
* :ref:`reference` Technical descriptions that provide context or
|
||||
important details about |CL|
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
@@ -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.
|
||||
|
||||
|
||||
|
Before Width: | Height: | Size: 59 KiB 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.
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
.. _bare-metal-install:
|
||||
|
||||
Install Clear Linux OS on bare metal
|
||||
####################################
|
||||
Install Clear Linux OS on bare metal (automatic)
|
||||
################################################
|
||||
|
||||
These instructions guide you through the installation of |CLOSIA|
|
||||
on bare metal using a bootable USB drive.
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
.. _bare-metal-manual-install:
|
||||
|
||||
Bare metal manual installation guide
|
||||
####################################
|
||||
Install Clear Linux OS on bare metal (manual)
|
||||
#############################################
|
||||
|
||||
This section contains the steps for a |CL| manual installation. It picks up
|
||||
where the :ref:`bare-metal-install` left off.
|
||||
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 123 KiB After Width: | Height: | Size: 148 KiB |
BIN
Binary file not shown.
|
Before Width: | Height: | Size: 337 KiB After Width: | Height: | Size: 366 KiB |
BIN
Binary file not shown.
|
Before Width: | Height: | Size: 118 KiB After Width: | Height: | Size: 153 KiB |
@@ -3,6 +3,13 @@
|
||||
Guides
|
||||
######
|
||||
|
||||
Our Guides:
|
||||
|
||||
* Provide a critical, fundamental understanding of |CL| features
|
||||
* Show you how to leverage the full feature set of |CL|
|
||||
* Enhance your productivity when using |CL|
|
||||
|
||||
|
||||
The following guides provide step-by-step instructions for tasks that come
|
||||
after completing the |CL| :ref:`installation <get-started>`.
|
||||
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -0,0 +1,111 @@
|
||||
.. _developer-workstation:
|
||||
|
||||
Developer Workstation
|
||||
#####################
|
||||
|
||||
Overview
|
||||
********
|
||||
|
||||
*Developer Workstation* helps you find the :ref:`bundles-about` you need to
|
||||
start your |CL| development project.
|
||||
|
||||
Before continuing, we recommend that you learn how to use
|
||||
:ref:`swupd <swupd-guide>`. Visit our :ref:`swupd-about` page to understand
|
||||
how |CL| simplifies software versioning compared to other Linux\*
|
||||
distributions.
|
||||
|
||||
Workstation Setup
|
||||
=================
|
||||
|
||||
This guide helps you understand the minimum bundles required to get started.
|
||||
After installing them, you can add more bundles relevant to your use case.
|
||||
To run any process required for Clear Linux development, you can add the
|
||||
large bundle :ref:`*os-clr-on-clr* <enable-user-space>`. However, given how
|
||||
many packages this bundle contains, you may want instead to deploy a leaner
|
||||
OS with only those bundles relevant to your project. Developer Workstation
|
||||
responds to this need.
|
||||
|
||||
Use Table 1, *Clear Linux Developer Profiles*, to identify the *minimum
|
||||
required bundles* to get started developing based on your role or project.
|
||||
While your role may not neatly fit in one of these categories, consider using Table 1 as a starting point.
|
||||
|
||||
.. list-table:: **Table 1. Clear Linux Developer Profiles**
|
||||
:widths: 20, 20, 20, 20
|
||||
:header-rows: 1
|
||||
|
||||
* - Clear Linux Bundle
|
||||
- *Internet of Things (IoT)*
|
||||
- *System Administrator*
|
||||
- *Client/Cloud/Web Developer*
|
||||
|
||||
* - `editors`
|
||||
- ✓
|
||||
- ✓
|
||||
- ✓
|
||||
|
||||
* - `network-basic`
|
||||
- ✓
|
||||
- ✓
|
||||
- ✓
|
||||
|
||||
* - `openssh-server`
|
||||
- ✓
|
||||
- ✓
|
||||
- ✓
|
||||
|
||||
* - `webserver-basic`
|
||||
-
|
||||
- ✓
|
||||
- ✓
|
||||
|
||||
* - `application-server`
|
||||
-
|
||||
- ✓
|
||||
- ✓
|
||||
|
||||
* - `database-basic`
|
||||
-
|
||||
- ✓
|
||||
- ✓
|
||||
|
||||
* - `desktop-autostart`
|
||||
- ✓
|
||||
- ✓
|
||||
- ✓
|
||||
|
||||
* - `dev-utils`
|
||||
-
|
||||
-
|
||||
- ✓
|
||||
|
||||
`swupd` search
|
||||
==============
|
||||
|
||||
We recommend trying out :ref:`swupd search <swupd-search>`, to learn the
|
||||
commands to search for and add bundles relevant to your project.
|
||||
|
||||
:ref:`swupd-search` shows you how to:
|
||||
|
||||
* Use `swupd` to search for bundles
|
||||
* Use `swupd` to add bundles
|
||||
|
||||
Core Concepts
|
||||
=============
|
||||
|
||||
We recommend that you understand these core concepts in |CL| *before*
|
||||
developing your project.
|
||||
|
||||
* :ref:`Bundles <bundles-about>`
|
||||
* :ref:`Software update <swupd-about>`
|
||||
* :ref:`Mixer <mixer-about>`
|
||||
* :ref:`Autospec <autospec-about>`
|
||||
|
||||
Other resources for developers
|
||||
-----------------------------------
|
||||
|
||||
* `Developer Tooling Framework for Clear Linux`_
|
||||
* `Clear Linux Bundles`_
|
||||
|
||||
.. _Clear Linux Bundles: https://github.com/clearlinux/clr-bundles
|
||||
|
||||
.. _Developer Tooling Framework for Clear Linux: https://github.com/clearlinux/common
|
||||
@@ -9,6 +9,8 @@ maintaining |CLOSIA| after :ref:`installation <get-started>` is completed.
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
developer-workstation
|
||||
swupd-search
|
||||
enable-user-space
|
||||
swupd-guide
|
||||
bulk-provision
|
||||
|
||||
@@ -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.
|
||||
|
||||
|
||||
@@ -0,0 +1,144 @@
|
||||
.. _swupd-search:
|
||||
|
||||
Use swupd search to find bundles
|
||||
################################
|
||||
|
||||
.. contents::
|
||||
:local:
|
||||
:depth: 2
|
||||
|
||||
This document shows you how to use `swupd search` to find and add
|
||||
bundles.
|
||||
|
||||
Assumptions
|
||||
***********
|
||||
|
||||
This guide assumes you:
|
||||
|
||||
* Possess a basic knowledge of :ref:`swupd <swupd-guide>`
|
||||
* Understand :ref:`how swupd differs <swupd-about>` from
|
||||
other Linux\* distributions
|
||||
* May use :ref:`mixer` to build your own |CL| OS
|
||||
|
||||
How do I search for a bundle?
|
||||
*****************************
|
||||
|
||||
Use `swupd search` to locate the bundle where the application binary exists.
|
||||
|
||||
Example: Kata Containers
|
||||
========================
|
||||
|
||||
Containers have revolutionized the way we manage cloud infrastructure.
|
||||
Traditional containers often share the same OS kernel, which raises
|
||||
security concerns. Instead, with Kata Containers, each container has its own
|
||||
kernel instance and runs on its own :abbr:`Virtual Machine (VM)`. Whether you're running 3 or 300 nodes on your cluster, Kata Containers provide a
|
||||
lightweight, fast, and secure option for app/container management.
|
||||
|
||||
In |CL|, you only need to add `this bundle`_ to use `Kata Containers`_:
|
||||
`containers-virt`. Also, check out our tutorial: :ref:`kata`.
|
||||
|
||||
We need to find *kata* containers in a bundle. How do we search for it?
|
||||
|
||||
#. Enter :command:`swupd search`, followed by 'kata' as the search term:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
sudo swupd search kata
|
||||
|
||||
.. note::
|
||||
|
||||
`swupd search` downloads |CL| manifest data and searches for
|
||||
matching paths. Enter only one term, or hyphenated term, per
|
||||
search. Use the command :command:`man swupd` to learn more.
|
||||
|
||||
#. Alternatively, if you want to search binaries only, add the `-b`
|
||||
flag:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
sudo swupd search -b kata
|
||||
|
||||
.. note::
|
||||
|
||||
`-b` flag, or `--binary`, means: Restrict search to program binary paths. Omit this flag if you want a larger scope of search results.
|
||||
|
||||
Only the base bundle is returned. In |CL|, *bundles* can contain
|
||||
other *bundles* via `includes`. For more details, see `Bundle Definition Files`_ and its subdirectory *bundles*.
|
||||
|
||||
If your search does not produce results on a specific term when using
|
||||
the `-b` flag, abbreviate the search term. For example, if you search
|
||||
for *kubernetes* and it does not show results, instead abbreviate the
|
||||
term to *kube* to show results.
|
||||
|
||||
#. Optionally, you can review our `bundles`_ or individual `packages`_
|
||||
|
||||
#. Using `sudo swupd search -b kata` shows a match for our use case.
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
Bundle containers-virt (834 MB to install)
|
||||
/usr/bin/kata-virtfs-lite-proxy-helper
|
||||
/usr/bin/kata-runtime
|
||||
/usr/bin/kata-qemu-lite-system-x86_64
|
||||
/usr/bin/kata-qemu-lite-pr-helper
|
||||
/usr/bin/kata-qemu-lite-ga
|
||||
/usr/bin/kata-collect-data.sh
|
||||
|
||||
.. note::
|
||||
|
||||
If the bundle is already installed, *[installed]* appears in search results. If this doesn't apppear, the bundle needs to be installed.
|
||||
|
||||
#. Add the bundle `containers-virt`:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
sudo swupd bundle-add containers-virt
|
||||
|
||||
.. note::
|
||||
|
||||
To add multiple bundles simply add a space followed by the bundle name.
|
||||
|
||||
#. When prompted, enter your password.
|
||||
|
||||
#. Upon successful installation, your console should show similar data:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
Downloading packs...
|
||||
|
||||
Extracting containers-virt pack for version 24430
|
||||
...50%
|
||||
Extracting kernel-container pack for version 24430
|
||||
...100%
|
||||
Starting download of remaining update content. This may take a while...
|
||||
...100%
|
||||
Finishing download of update content...
|
||||
Installing bundle(s) files...
|
||||
...100%
|
||||
Calling post-update helper scripts.
|
||||
Successfully installed 1 bundle
|
||||
|
||||
FAQ
|
||||
===
|
||||
|
||||
Find answers to these common questions:
|
||||
|
||||
* How do I install and *use* :ref:`Kata Containers <kata>` on |CL|?
|
||||
|
||||
* How do I :ref:`kata_migration`?
|
||||
|
||||
* How do I show all :ref:`bundles available <swupd-guide>`?
|
||||
|
||||
* How do I :ref:`update swupd<swupd-guide>`?
|
||||
|
||||
* How do I :ref:`remove bundles<swupd-guide>`?
|
||||
|
||||
.. _Kata Containers: https://clearlinux.org/blogs/clear-linux-os-announces-support-kata-containers
|
||||
|
||||
.. _this bundle: https://github.com/clearlinux/clr-bundles/blob/master/bundles/containers-virt
|
||||
|
||||
.. _Bundle Definition Files: https://github.com/clearlinux/clr-bundles
|
||||
|
||||
.. _bundles: https://github.com/clearlinux/clr-bundles/tree/master/bundles
|
||||
|
||||
.. _packages: https://github.com/clearlinux/clr-bundles/blob/master/packages
|
||||
@@ -15,16 +15,18 @@ Internal cross-references
|
||||
An internal cross-reference is a reference to a location within the |CLOSIA|
|
||||
documentation. Use explicit markup labels and the ``:ref:`` role to create
|
||||
cross references to headings, figures, and code examples as needed. Every
|
||||
file must have a label before the title identical to the file's name in order
|
||||
to be able to add cross-references without having to open the file.
|
||||
file must have a label before the title, which is identical to the file's
|
||||
name, in order to be be cross-referenced within the entire documentation.
|
||||
|
||||
The labels' naming conventions are:
|
||||
Labels' naming conventions:
|
||||
|
||||
* Ensure the label is unique throughout the documentation
|
||||
|
||||
* Use only full words.
|
||||
|
||||
* Use \- to link multiple words.
|
||||
|
||||
* Use only as many words as necessary to ensure the label is unique.
|
||||
* Use only as many words as necessary.
|
||||
|
||||
These are some examples of proper labels:
|
||||
|
||||
@@ -81,7 +83,8 @@ This creates a link to the :ref:`label-of-target` using the text of the
|
||||
heading.
|
||||
|
||||
This creates a link to the :ref:`target <label-of-target>` using the word
|
||||
'target' instead of the heading.
|
||||
'target' instead of the heading. We use the term 'target' here similar to
|
||||
the way'anchor' is used in HTML.
|
||||
|
||||
.. note::
|
||||
|
||||
@@ -92,7 +95,7 @@ This creates a link to the :ref:`target <label-of-target>` using the word
|
||||
External References
|
||||
*******************
|
||||
|
||||
External references or hyperlinks can be added easily with ReST. Only
|
||||
External references or hyperlinks can be added easily with reST. Only
|
||||
hyperlinks with a separated target definition are allowed.
|
||||
|
||||
Do not use explicit hyperlinks consisting entire URLs. For example, links
|
||||
@@ -121,4 +124,30 @@ Use this template to add a hyperlink with a separated definition:
|
||||
|
||||
The state of `Oregon`_ offers a wide range of recreational activities.
|
||||
|
||||
.. _Oregon: http://traveloregon.com/
|
||||
The include directive
|
||||
*********************
|
||||
|
||||
Clear Linux documentation also uses the ``.. include::``
|
||||
directive to include a portion of another reST file.
|
||||
|
||||
Use the ``.. include::`` directive to show a select portion of a file.
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
.. include:: rest.rst
|
||||
:start-after: incl-restructured-text-overview:
|
||||
:end-before: incl-restructured-text-overview-end:
|
||||
|
||||
In this example, note that you must:
|
||||
|
||||
* Create a `target` that appears directly above a header (ease of inclusion)
|
||||
* Ensure that the target is unique, as explained in :ref:`target <internal-cross>`
|
||||
* Use a `:` at the end of the value of `start-after` and `end-before`.
|
||||
|
||||
Use of the ``.. inclusion::`` for :ref:`rest` is shown below.
|
||||
|
||||
.. include:: rest.rst
|
||||
:start-after: incl-restructured-text-overview:
|
||||
:end-before: incl-restructured-text-overview-end:
|
||||
|
||||
.. _Oregon: http://traveloregon.com/
|
||||
|
||||
@@ -36,7 +36,7 @@ The |CL| technical content is written in simple American English and our
|
||||
This guide includes the following sections:
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
:maxdepth: 3
|
||||
|
||||
basic
|
||||
structures
|
||||
@@ -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
|
||||
@@ -3,12 +3,19 @@
|
||||
RestructuredText guide
|
||||
######################
|
||||
|
||||
.. incl-restructured-text-overview:
|
||||
|
||||
Overview
|
||||
********
|
||||
|
||||
The |CLOSIA| uses Sphinx and RestructuredText as authoring tools for its
|
||||
documentation. This section contains the preferred methods for using the
|
||||
:abbr:`ReST (RestructuredText)` markup on your documents. Please refer to the
|
||||
`Sphinx documentation`_ for the complete list of available markup and use
|
||||
as much markup as possible.
|
||||
|
||||
.. _Sphinx documentation: http://www.sphinx-doc.org/en/stable/markup/index.html
|
||||
|
||||
Remember: **Changing incorrect markup is easier than adding markup from
|
||||
scratch.**
|
||||
|
||||
@@ -27,6 +34,8 @@ templates, or the code-block directive, for multi-lined templates.
|
||||
Every use case is explained, examples provided and, lastly,
|
||||
templates supplied.
|
||||
|
||||
.. incl-restructured-text-overview-end:
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 3
|
||||
|
||||
@@ -38,6 +47,3 @@ templates supplied.
|
||||
code
|
||||
contents
|
||||
|
||||
|
||||
.. _Sphinx documentation:
|
||||
http://sphinx-doc.org/contents.html
|
||||
|
||||
@@ -0,0 +1,113 @@
|
||||
.. _compatible-hardware:
|
||||
|
||||
Compatible Hardware
|
||||
###################
|
||||
|
||||
This document describes hardware that has been tested and confirmed as
|
||||
compatible with |CLOSIA|. This list is not comprehensive and will continue to
|
||||
grow.
|
||||
|
||||
.. list-table:: **Table 1. Clear Linux Compatible Hardware**
|
||||
:widths: 20, 20
|
||||
:header-rows: 1
|
||||
|
||||
* - Processor SKU
|
||||
- Platform
|
||||
|
||||
* - Intel® Core™ i5-6260U
|
||||
-
|
||||
|
||||
* - Intel® Core™ i5-6560U
|
||||
- Dell XPS\* 13 9350
|
||||
|
||||
* - Intel® Celeron® J3455
|
||||
- NUC6CAYS
|
||||
|
||||
* - Intel® Core™ i5-4250U
|
||||
-
|
||||
|
||||
* - Intel® Core™ i7-5557U
|
||||
-
|
||||
|
||||
* - Intel® Core™ i9-7900X
|
||||
- Gigabyte\* X299
|
||||
|
||||
* - Intel® Core™ i3-4130
|
||||
- Lenovo Thinkserver\* TS140
|
||||
|
||||
* - Intel® Core™ i7-7567U
|
||||
- NUC7i7BNH
|
||||
|
||||
* - Intel® Core™ i7-8809G
|
||||
- NUC8i7HVK
|
||||
|
||||
* - Intel® Core™ i5-7260U
|
||||
- NUC7i5BNH
|
||||
|
||||
* - Intel® Core™ i7-8650U
|
||||
- NUC7i7DNKE
|
||||
|
||||
* - Intel® Core™ i5-7300U
|
||||
- NUC7i5DNHE
|
||||
|
||||
* - Intel® Xeon® Gold 6138
|
||||
-
|
||||
|
||||
* - Intel® Xeon® E5-2699A v4
|
||||
- Dell PowerEdge\* R630
|
||||
|
||||
* - Intel® Xeon® E5-2620 v3
|
||||
-
|
||||
|
||||
* - Intel® Core™ i5-6600
|
||||
- Gigabyte\* Z170X-UD5
|
||||
|
||||
* - Intel® Core™ i5-4250U
|
||||
- D54250WYK
|
||||
|
||||
* - Intel® Xeon® E5-2699 v3
|
||||
- S2600WT2
|
||||
|
||||
* - Intel® Atom™ J3455
|
||||
- NUC6CAYB
|
||||
|
||||
* - Intel® Xeon® Bronze 3104
|
||||
- 0W23H8
|
||||
|
||||
* - Intel® Atom™ C2750
|
||||
- SuperMicro\* A1SAi
|
||||
|
||||
* - Intel® Atom™ E3825
|
||||
- CircuitCo MinnowBoard MAX\*
|
||||
|
||||
* - Intel® Core™ i7-8700
|
||||
- Gigabyte\* H370 WIFI
|
||||
|
||||
* - Intel® Core™ i7-3667U
|
||||
- Lenovo ThinkPad\* X1 Carbon laptop
|
||||
|
||||
* - Intel® Core™ i5-4210U
|
||||
- Dell XPS\* 13 laptop
|
||||
|
||||
* - Intel® Celeron® J3455
|
||||
- NUC6CAYB
|
||||
|
||||
* - Intel® Core™ i7-4790
|
||||
- Gigabyte\* desktop
|
||||
|
||||
* - Intel® Core™ i5-6260U
|
||||
- NUC6I6SYH
|
||||
|
||||
* - Intel® Core™ i7-5557U
|
||||
- NUC5I7RYH
|
||||
|
||||
* - Intel® Core™ i7-4700MQ
|
||||
- Lenovo ThinkPad\* T540p
|
||||
|
||||
* - Intel® Core™ i7-5557U
|
||||
- NUC5I7RYB
|
||||
|
||||
* - Intel® Core™ i5-6260U
|
||||
- NUC6I5SYH
|
||||
|
||||
\* Other names and brands may be claimed as the property of others.
|
||||
@@ -9,9 +9,11 @@ features.
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
compatible-hardware
|
||||
bundle-commands
|
||||
bundles/available-bundles
|
||||
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
|
||||
::
|
||||
|
||||
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.
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -3,6 +3,13 @@
|
||||
Tutorials
|
||||
#########
|
||||
|
||||
Our Tutorials:
|
||||
|
||||
* Demonstrate how to use |CL| features for cloud, client, distributed
|
||||
processing, and virtual environments
|
||||
* Involve specific application of |CL| that often use third-party tools
|
||||
* Extend the development possibilities of |CL| with specific use cases
|
||||
|
||||
This section provides detailed instructions to guide you through completing
|
||||
specific |CLOSIA| use cases.
|
||||
|
||||
|
||||
@@ -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