Compare commits
84 Commits
| Author | SHA1 | Date | |
|---|---|---|---|
| d919a7ebab | |||
| 75dca16915 | |||
| f5b036fb9e | |||
| bbefa05d09 | |||
| f2afe2420b | |||
| b37f135399 | |||
| 77f5c1594a | |||
| 03b0107829 | |||
| d18e7698db | |||
| 60be280fac | |||
| 739ecbe4a6 | |||
| c21f3b9301 | |||
| 145679ac60 | |||
| a88c59bdfd | |||
| 7f6b4a935c | |||
| 0128b5243b | |||
| ecbbb78759 | |||
| 2b5c7fb1ef | |||
| b94c22cf59 | |||
| 26468b6203 | |||
| c2d0ece7f5 | |||
| 6c900602eb | |||
| 4df59f7fe9 | |||
| d894493235 | |||
| 159263d7b9 | |||
| e400af6439 | |||
| 1ac170279a | |||
| 1444fee6af | |||
| 1af09259a8 | |||
| 17f5f7402b | |||
| a395fc16ca | |||
| 56d799c727 | |||
| 25873903eb | |||
| 61311d70de | |||
| 56b197c276 | |||
| fb217bc924 | |||
| 2cd9ea94f2 | |||
| e514baa3d3 | |||
| 82836666c9 | |||
| 54f7bb9c10 | |||
| 276d764221 | |||
| 6ceebea52e | |||
| c34f8a148b | |||
| 7ead9926de | |||
| 79d967924a | |||
| c0e5ffa2db | |||
| f4b275c480 | |||
| 549b9a5585 | |||
| ac4c443305 | |||
| fc3fbda322 | |||
| e64a2d5212 | |||
| 9145b8ce52 | |||
| da942ec694 | |||
| 950fa154ea | |||
| 0e54ac7da6 | |||
| ed17a45e71 | |||
| d2c9620079 | |||
| 35e09fc2e4 | |||
| 5bc2cec874 | |||
| 4c202b66d3 | |||
| e61dec33be | |||
| 81db392938 | |||
| 5c2f5e804f | |||
| 47bc6a3dad | |||
| dd693b5256 | |||
| d419346adc | |||
| 137d613a91 | |||
| a081d9ed11 | |||
| b79ceb24fb | |||
| 534514c83e | |||
| c9c36fb01c | |||
| a6fb705169 | |||
| 816df17a6d | |||
| 7b75a68df9 | |||
| aded6c6957 | |||
| 66d1c7fb9a | |||
| 4cb18f4643 | |||
| 0cc215db84 | |||
| 68d078ee4c | |||
| 92b30e5349 | |||
| 33bf629eef | |||
| e6bce3b1e0 | |||
| 5ac83dc3e8 | |||
| f3e8dc8307 |
@@ -1,14 +1,23 @@
|
||||
.. _mixer-about:
|
||||
|
||||
Mixer
|
||||
#######
|
||||
#####
|
||||
|
||||
Mixing refers to composing a custom, versioned image of |CLOSIA| for a specific use case. While upstream |CL| provides options to install bundles for various capabilities, some developers and OSVs may wish to either augment the operating system with functionality from their own packages or modify the structure of current bundles. Mixing offers a method to add capabilities while retaining the ability to stay up to date with an upstream version of |CL|.
|
||||
Mixing refers to composing a custom, versioned image of |CL-ATTR| for a
|
||||
specific use case. While upstream |CL| provides options to install bundles
|
||||
for various capabilities, some developers and OSVs may wish to either
|
||||
augment the operating system with functionality from their own packages
|
||||
or modify the structure of current bundles. Mixing offers a method to add
|
||||
capabilities while retaining the ability to stay up to date with an upstream
|
||||
version of |CL|.
|
||||
|
||||
Mixing is a multi-step process that starts with installing the mixer bundle using swupd. You will also need a working knowledge of :abbr:`RPMs (RPM Package Manager files)` and how |CL| bundles work. For a detailed guide on how to create a |CL| mix, visit :ref:`mixer`.
|
||||
Mixing is a multi-step process that starts with installing the mixer bundle
|
||||
using swupd. You will also need a working knowledge of
|
||||
:abbr:`RPMs (RPM Package Manager files)` and how |CL| bundles work. For a
|
||||
detailed guide on how to create a |CL| mix, visit :ref:`mixer`.
|
||||
|
||||
Related Concepts
|
||||
================
|
||||
Related topics
|
||||
==============
|
||||
|
||||
* :ref:`swupd-about`
|
||||
* :ref:`bundles-about`
|
||||
|
||||
@@ -97,7 +97,7 @@ standards. Below are some examples:
|
||||
have been removed such as the `finger` and `tcpwrappers`.
|
||||
|
||||
* `SFTP` has been disabled by default due to security
|
||||
considerations. See the `openssh-server reference page`_ for more details.
|
||||
considerations.
|
||||
|
||||
|
||||
Verified trust
|
||||
@@ -182,7 +182,6 @@ good security hygiene. Below are some examples:
|
||||
|
||||
.. _`documentation about Software Updates`: https://clearlinux.org/documentation/clear-linux/concepts/swupd-about
|
||||
.. _`cve-check-tool`: https://github.com/clearlinux/cve-check-tool
|
||||
.. _`openssh-server reference page`: https://clearlinux.org/documentation/clear-linux/reference/bundles/openssh-server
|
||||
.. _`blog post about swupd security`: https://clearlinux.org/blogs/security-software-update-clear-linux-os-intel-architecture
|
||||
.. _`rolling release model`: https://en.wikipedia.org/wiki/Rolling_release
|
||||
.. _`clrtrust`: https://github.com/clearlinux/clrtrust
|
||||
|
||||
@@ -3,35 +3,35 @@
|
||||
Software update
|
||||
###############
|
||||
|
||||
|CLOSIA| does software updates differently than traditional Linux-based
|
||||
operating systems. Where traditional distributions rely on packages for
|
||||
software deployment, |CL| uses the concept of a "bundle" for
|
||||
deployment. Traditional Linux packages provide a particular utility or
|
||||
library; |CL| bundles provide all necessary packages to enable a
|
||||
|CL-ATTR| does software updates differently than traditional Linux-based
|
||||
operating systems. Where traditional distributions rely on packages for
|
||||
software deployment, |CL| uses the concept of a "bundle" for
|
||||
deployment. Traditional Linux packages provide a particular utility or
|
||||
library; |CL| bundles provide all necessary packages to enable a
|
||||
specific function.
|
||||
|
||||
With |CL|, updating equates to an entirely new OS version with a
|
||||
specific set of bundles, as compared to a package-based distribution in
|
||||
which packages may be updated individually. |CL| updates are
|
||||
With |CL|, updating equates to an entirely new OS version with a
|
||||
specific set of bundles, as compared to a package-based distribution in
|
||||
which packages may be updated individually. |CL| updates are
|
||||
efficient, updating only changed files instead of entire packages.
|
||||
|
||||
System administrators can customize or add bundles to the OS, while still
|
||||
taking advantage of a controlled update stream. This enables system
|
||||
System administrators can customize or add bundles to the OS, while still
|
||||
taking advantage of a controlled update stream. This enables system
|
||||
administrators to focus on the pieces that make their deployment unique.
|
||||
|
||||
|
||||
Bundles
|
||||
=======
|
||||
|
||||
While we use packages to manage compiling source code into installable
|
||||
binaries, we do not deploy software through packages. Instead, we use bundles
|
||||
to deploy software, where each bundle encapsulates a particular functionality
|
||||
-- functionality that is enabled by composing all the required upstream
|
||||
open-source projects and packages into one logical unit: a bundle. This
|
||||
While we use packages to manage compiling source code into installable
|
||||
binaries, we do not deploy software through packages. Instead, we use bundles
|
||||
to deploy software, where each bundle encapsulates a particular functionality
|
||||
-- functionality that is enabled by composing all the required upstream
|
||||
open-source projects and packages into one logical unit: a bundle. This
|
||||
simplifies installing features on |CL|.
|
||||
|
||||
For additional resources regarding available bundles, useful bundle commands,
|
||||
and compatible |CL| kernels, visit our :ref:`bundles-about`
|
||||
For additional resources regarding available bundles, useful bundle commands,
|
||||
and compatible |CL| kernels, visit our :ref:`bundles-about`
|
||||
page.
|
||||
|
||||
|
||||
@@ -65,8 +65,8 @@ describe the versions of all the software on the OS. Each build is
|
||||
composed of a specific set of bundles made from a particular version of
|
||||
packages. This matters on a daily basis to system administrators, who
|
||||
need to determine which of their systems do not have the latest security
|
||||
fixes, or which combinations of software have been tested. Every release
|
||||
of the same number is guaranteed to contain the same versions of software,
|
||||
fixes, or which combinations of software have been tested. Every release
|
||||
of the same number is guaranteed to contain the same versions of software,
|
||||
so there's no ambiguity between two systems running the same version of |CL|.
|
||||
|
||||
|
||||
@@ -76,20 +76,20 @@ Updating
|
||||
Another notable difference between package-based distributions and |CL|
|
||||
is how updates are managed. On a package-based OS, system administrators update
|
||||
each individual package or piece of software to a newer (or older!) version. With
|
||||
|CL|, an update translates to an entirely new OS version, containing one
|
||||
or many updates. It is not possible to update a piece of the system while
|
||||
|CL|, an update translates to an entirely new OS version, containing one
|
||||
or many updates. It is not possible to update a piece of the system while
|
||||
remaining on the same version of |CL|.
|
||||
|
||||
How is this useful? Although it seems, at first, like a huge restriction
|
||||
or limitation, this method has many non-obvious benefits. Imagine a
|
||||
cloud environment composed of numerous machines. Here, a homogeneous set of
|
||||
software makes sense -- from the system administrator's level down to the
|
||||
user level. Homogeneous systems allow users to focus on their contributions
|
||||
and/or code, rather than configuring environments or worrying about
|
||||
synchronizing versions and updates. At the system admin level, it ensures
|
||||
user level. Homogeneous systems allow users to focus on their contributions
|
||||
and/or code, rather than configuring environments or worrying about
|
||||
synchronizing versions and updates. At the system admin level, it ensures
|
||||
security is tighter and makes it far easier to monitor and update patches.
|
||||
|
||||
|CL| promotes regular updating of the OS and will automatically check
|
||||
|CL| promotes regular updating of the OS and will automatically check
|
||||
for updates and apply them by default.
|
||||
|
||||
To learn how to run an update of your system, visit our :ref:`swupd-guide` page.
|
||||
@@ -98,9 +98,9 @@ To learn how to run an update of your system, visit our :ref:`swupd-guide` page.
|
||||
Update speed
|
||||
============
|
||||
|
||||
Software updates with |CL| are also efficient. Bundles simply describe
|
||||
a set of files, and the update technology updates *only* files that actually
|
||||
changed by using binary-delta technology for efficiency [1]_. Operating systems
|
||||
Software updates with |CL| are also efficient. Bundles simply describe
|
||||
a set of files, and the update technology updates *only* files that actually
|
||||
changed by using binary-delta technology for efficiency [1]_. Operating systems
|
||||
that use packages as the unit of deployment require full package updates (thus
|
||||
hogging resources), even when one small file in that package has changed.
|
||||
|
||||
@@ -128,5 +128,5 @@ a controlled update stream.
|
||||
To learn more about mixing, visit our :ref:`mixer-about` page.
|
||||
|
||||
|
||||
.. [1] The software update technology for |CLOSIA| was first presented at the
|
||||
.. [1] The software update technology for |CL-ATTR| was first presented at the
|
||||
Linux Plumbers conference in 2012.
|
||||
|
||||
@@ -0,0 +1,802 @@
|
||||
.. _bare-metal-install-beta:
|
||||
|
||||
Install |CL-ATTR| from the live desktop beta image
|
||||
##################################################
|
||||
|
||||
The live desktop beta image allows you to boot |CL-ATTR| into a GNOME
|
||||
desktop without modifying the host system. Using the live image, you can
|
||||
explore the possibilities of developing with |CL|. You can also launch the
|
||||
new installer and install |CL| on your target system.
|
||||
|
||||
.. contents:: :local:
|
||||
:depth: 1
|
||||
|
||||
System requirements
|
||||
*******************
|
||||
|
||||
Assure that your target system supports the installation:
|
||||
|
||||
* :ref:`system-requirements`
|
||||
* :ref:`compatibility-check`
|
||||
|
||||
Preliminary steps
|
||||
*****************
|
||||
|
||||
#. `Navigate to the image directory`_.
|
||||
|
||||
#. Download the file :file:`clear-<release number>-live-desktop-beta.img.xz`
|
||||
|
||||
.. note::
|
||||
|
||||
``<release-number>`` is the latest |CL| auto-numbered release.
|
||||
|
||||
#. Follow your OS instructions to create a bootable USB drive.
|
||||
|
||||
* :ref:`bootable-usb-linux-all`
|
||||
* :ref:`bootable-usb-mac-all`
|
||||
* :ref:`bootable-usb-windows-all`
|
||||
|
||||
.. _install-from-live-image:
|
||||
|
||||
Install from live image
|
||||
***********************
|
||||
|
||||
After you've downloaded and burned the live desktop image on a
|
||||
USB drive, follow these steps.
|
||||
|
||||
#. Insert the USB drive into an available USB slot.
|
||||
|
||||
#. Power on the system.
|
||||
|
||||
#. Open the system BIOS setup menu by pressing the F2 key.
|
||||
|
||||
.. note::
|
||||
|
||||
Your BIOS setup menu entry point may vary.
|
||||
|
||||
#. In the setup menu, enable the UEFI boot and set the USB drive as the
|
||||
first option in the device boot order.
|
||||
|
||||
#. Save these settings and exit.
|
||||
|
||||
#. Reboot the target system.
|
||||
|
||||
Launch the installer
|
||||
====================
|
||||
|
||||
#. After the |CL| live desktop image boots, select the :guilabel:`Activities` menu in the upper left.
|
||||
|
||||
#. Select the icon, :guilabel:`Install Clear Linux OS`, shown in Figure 1.
|
||||
|
||||
.. figure:: figures/bare-metal-install-beta-1.png
|
||||
:scale: 50 %
|
||||
:alt: Install Clear Linux OS icon
|
||||
|
||||
Figure 1: Install Clear Linux OS icon
|
||||
|
||||
#. Upon selecting the icon, the installer is launched, as shown in Figure 2.
|
||||
|
||||
.. figure:: figures/bare-metal-install-beta-2.png
|
||||
:scale: 50 %
|
||||
:alt: Clear Linux OS Installer
|
||||
|
||||
Figure 2: Clear Linux OS Installer
|
||||
|
||||
.. _minimum-installation-requirements:
|
||||
|
||||
Minimum installation requirements
|
||||
*********************************
|
||||
|
||||
To fulfill minimum installation requirements, complete
|
||||
:guilabel:`Required options`. All other menu items are optional.
|
||||
|
||||
.. note::
|
||||
|
||||
* In the Main menu, the :kbd:`Install` button is highlighted
|
||||
**only after** you complete :ref:`required-options-installation`.
|
||||
|
||||
* You must choose whether or not to participate in :ref:`telemetrics`
|
||||
before you can :ref:`finish-cl-installation`.
|
||||
|
||||
* You may wish to :ref:`test-network-settings` before you
|
||||
:ref:`configure-network-interfaces`. Assure that a ``Success`` message is received.
|
||||
|
||||
Main menu
|
||||
*********
|
||||
|
||||
In the |CL| Installer main menu, two tabs appear:
|
||||
:guilabel:`[R] Required options` and :guilabel:`[A] Advanced options`.
|
||||
Navigate between tabs using the arrow keys or these shortcut keys:
|
||||
|
||||
* :kbd:`Shift+A` for :guilabel:`[A] Advanced options`
|
||||
* :kbd:`Shift+R` for :guilabel:`[R] Required options`
|
||||
|
||||
To meet the minimum requirements, enter your choices in the
|
||||
:guilabel:`Required options`. After confirmation, your selections appear
|
||||
below menu options in the Main Menu, beside the :guilabel:`>>` chevron.
|
||||
|
||||
Navigation
|
||||
**********
|
||||
|
||||
* Select :kbd:`Tab` or :kbd:`Up/Down` arrows to highlight your choice.
|
||||
|
||||
* Select :kbd:`Enter` or :kbd:`Spacebar` to confirm your choice.
|
||||
|
||||
* Select :kbd:`Cancel` or :kbd:`Esc` to cancel your choice.
|
||||
|
||||
The |CL| Installer main menu appears as shown in Figure 3.
|
||||
|
||||
.. figure:: figures/bare-metal-install-beta-3.png
|
||||
:scale: 100 %
|
||||
:alt: Clear Linux OS Installer main menu
|
||||
|
||||
Figure 3: :guilabel:`Clear Linux OS Installer main menu`
|
||||
|
||||
.. _required-options-installation:
|
||||
|
||||
Required options
|
||||
****************
|
||||
|
||||
Choose Timezone
|
||||
===============
|
||||
|
||||
#. From the main menu, select :guilabel:`Choose Timezone`.
|
||||
|
||||
#. Select :kbd:`Enter` to continue.
|
||||
|
||||
#. In :guilabel:`Select System Timezone`, navigate to
|
||||
the desired timezone.
|
||||
|
||||
#. Use :kbd:`Tab` to navigate to :guilabel:`Confirm`.
|
||||
|
||||
#. Select :kbd:`Enter` to :kbd:`Confirm`.
|
||||
|
||||
.. note::
|
||||
|
||||
Select :guilabel:`Cancel` to restore the previously defined value and
|
||||
return to the main menu.
|
||||
|
||||
.. figure:: figures/bare-metal-install-beta-4.png
|
||||
:scale: 100 %
|
||||
:alt: Select System Timezone
|
||||
|
||||
Figure 4: :guilabel:`Select System Timezone`
|
||||
|
||||
Choose Language
|
||||
===============
|
||||
|
||||
#. From the main menu, select :guilabel:`Choose Language`.
|
||||
|
||||
#. Select :kbd:`Enter`.
|
||||
|
||||
#. In :guilabel:`Select System Language`, navigate to your desired language.
|
||||
|
||||
#. Select :kbd:`Tab` to highlight :kbd:`Confirm`.
|
||||
|
||||
#. Select :kbd:`Enter` to :kbd:`Confirm`.
|
||||
|
||||
.. note::
|
||||
|
||||
Select :guilabel:`Cancel` to restore the previously defined value and return to the main menu.
|
||||
|
||||
.. figure:: figures/bare-metal-install-beta-5.png
|
||||
:scale: 100 %
|
||||
:alt: Select System Language
|
||||
|
||||
Figure 5: :guilabel:`Select System Language`
|
||||
|
||||
|
||||
Configure the Keyboard
|
||||
======================
|
||||
|
||||
#. From the main menu, select :guilabel:`Configure the Keyboard`.
|
||||
|
||||
#. Select :kbd:`Enter`.
|
||||
|
||||
#. In :guilabel:`Select Keyboard`, navigate to the desired option.
|
||||
|
||||
#. In :guilabel:`Test keyboard`, type text to assure that the keys map to
|
||||
your keyboard.
|
||||
|
||||
#. Select :kbd:`Tab` to highlight :guilabel:`Confirm`.
|
||||
|
||||
#. Select :kbd:`Enter` to :kbd:`Confirm`.
|
||||
|
||||
.. note::
|
||||
|
||||
Select :guilabel:`Cancel` to restore the previously defined value and return to the main menu.
|
||||
|
||||
.. figure:: figures/bare-metal-install-beta-6.png
|
||||
:scale: 100 %
|
||||
:alt: Select Keyboard menu
|
||||
|
||||
Figure 6: :guilabel:`Select Keyboard menu`
|
||||
|
||||
Configure Media
|
||||
===============
|
||||
|
||||
#. From the main menu, select :guilabel:`Configure Media`.
|
||||
|
||||
.. note::
|
||||
|
||||
Available media appear by default.
|
||||
|
||||
#. Navigate to the desired media until highlighted.
|
||||
|
||||
.. TODO: Add another screenshot showing contextual menu.
|
||||
|
||||
#. Select :kbd:`Enter` or :kbd:`Spacebar` to select it.
|
||||
|
||||
Two options for partitioning appear.
|
||||
|
||||
#. Select :guilabel:`Auto Partition` to accept the default configuration, or
|
||||
:guilabel:`Add Partition` to add partitions manually. See instructions
|
||||
below.
|
||||
|
||||
.. figure:: figures/bare-metal-install-beta-7.png
|
||||
:scale: 100 %
|
||||
:alt: Configure Media menu
|
||||
|
||||
Figure 7: :guilabel:`Configure Media menu`
|
||||
|
||||
.. note::
|
||||
|
||||
Use additional options as necessary during partitioning:
|
||||
|
||||
* Select :guilabel:`Revert` to cancel changes and revert to the
|
||||
original configuration.
|
||||
* Select :guilabel:`Rescan` to show media connected to the host
|
||||
machine.
|
||||
|
||||
#. Select :kbd:`Enter` to :kbd:`Confirm`.
|
||||
|
||||
Choose one partitioning option below
|
||||
------------------------------------
|
||||
|
||||
* :ref:`auto-partition`
|
||||
* :ref:`add-partition`
|
||||
|
||||
.. _auto-partition:
|
||||
|
||||
Auto Partition
|
||||
==============
|
||||
|
||||
Auto partition will configure the media to meet the minimum requirements.
|
||||
|
||||
#. Select :guilabel:`Auto Partition` as shown in Figure 8.
|
||||
|
||||
#. Select :kbd:`Enter` or :kbd:`Spacebar` to highlight
|
||||
:guilabel:`Auto partition`.
|
||||
|
||||
#. Select :kbd:`Enter` to :kbd:`Confirm`.
|
||||
|
||||
This action returns you to the Main Menu.
|
||||
|
||||
.. figure:: figures/bare-metal-install-beta-8.png
|
||||
:scale: 100 %
|
||||
:alt: Auto Partition
|
||||
|
||||
Figure 8: :guilabel:`Auto Partition`
|
||||
|
||||
|
||||
#. You may skip to the :ref:`telemetry-tui` section below.
|
||||
|
||||
.. _add-partition:
|
||||
|
||||
Add Partition
|
||||
=============
|
||||
|
||||
Minimum requirements
|
||||
====================
|
||||
|
||||
To add partitions manually, assign partitions per the minimum
|
||||
requirements shown in Table 1:
|
||||
|
||||
.. list-table:: **Table 1. Disk Partition Setup**
|
||||
:widths: 33, 33, 33
|
||||
:header-rows: 1
|
||||
|
||||
* - FileSystem
|
||||
- Mount Point
|
||||
- Minimum size
|
||||
* - ``VFAT``
|
||||
- /boot
|
||||
- 150M
|
||||
* - ``swap``
|
||||
-
|
||||
- 256MB
|
||||
* - ``root``
|
||||
- /
|
||||
- *Size depends upon use case/desired bundles.*
|
||||
|
||||
#. In the Configure Media menu, select :guilabel:`Add Partition`.
|
||||
|
||||
.. note:: To change an existing partition, navigate to the partition,
|
||||
and select :guilabel:`Enter`.
|
||||
|
||||
boot partition
|
||||
--------------
|
||||
|
||||
#. In the :guilabel:`File System` menu, select :kbd:`Up/Down` arrows to
|
||||
select the file system type. See Figure 9.
|
||||
|
||||
#. In :guilabel:`Mount Point`, enter the ``/boot`` partition.
|
||||
|
||||
#. In :guilabel:`Size`, enter an appropriate size (e.g., 150M) per Table 1.
|
||||
|
||||
#. Navigate to :guilabel:`Confirm` until highlighted.
|
||||
|
||||
#. Select :guilabel:`Enter` to confirm.
|
||||
|
||||
.. figure:: figures/bare-metal-install-beta-9.png
|
||||
:scale: 100 %
|
||||
:alt: boot partition
|
||||
|
||||
Figure 9: :guilabel:`boot partition`
|
||||
|
||||
swap partition
|
||||
--------------
|
||||
|
||||
#. In the :guilabel:`File System` menu, select :kbd:`Up/Down` arrows to
|
||||
select the file system type. See Figure 10.
|
||||
|
||||
#. In :guilabel:`Mount Point`, the field remains blank.
|
||||
|
||||
.. note::
|
||||
|
||||
The Mount Point field is disabled.
|
||||
|
||||
#. In :guilabel:`Size`, enter an appropriate size (e.g., 256MB) per Table 1.
|
||||
|
||||
#. Navigate to :guilabel:`Add`.
|
||||
|
||||
#. Select :guilabel:`Enter` to continue.
|
||||
|
||||
.. figure:: figures/bare-metal-install-beta-10.png
|
||||
:scale: 100 %
|
||||
:alt: swap partition
|
||||
|
||||
Figure 10: :guilabel:`swap partition`
|
||||
|
||||
root partition
|
||||
--------------
|
||||
|
||||
#. In the :guilabel:`File System` menu, select :kbd:`Up/Down` arrows to
|
||||
select the file system type. See Figure 11.
|
||||
|
||||
#. In :guilabel:`Mount Point`, enter ``/root``.
|
||||
|
||||
#. In :guilabel:`Size`, enter an appropriate size per Table 1.
|
||||
|
||||
.. note::
|
||||
|
||||
The remaining available space shows by default.
|
||||
|
||||
#. Navigate to :guilabel:`Add` until highlighted.
|
||||
|
||||
#. Select :guilabel:`Enter` to continue.
|
||||
|
||||
You are returned to the :guilabel:`Configure media` menu.
|
||||
|
||||
#. Select :guilabel:`Confirm` to complete the media selection.
|
||||
|
||||
.. figure:: figures/bare-metal-install-beta-11.png
|
||||
:scale: 100 %
|
||||
:alt: root partition
|
||||
|
||||
Figure 11: :guilabel:`root partition`
|
||||
|
||||
You are returned to the :guilabel:`Configure media` menu. Your partitions should appear similar to those shown in Figure 12.
|
||||
|
||||
.. figure:: figures/bare-metal-install-beta-12.png
|
||||
:scale: 100 %
|
||||
:alt: Partitions
|
||||
|
||||
Figure 12: :guilabel:`Partitions`
|
||||
|
||||
#. Navigate to :guilabel:`Confirm` until highlighted.
|
||||
|
||||
#. Select :guilabel:`Enter` to complete adding partitions.
|
||||
|
||||
.. _telemetry-tui:
|
||||
|
||||
Telemetry
|
||||
=========
|
||||
|
||||
To fulfill the :guilabel:`Required options`, choose whether or not to
|
||||
participate in `telemetry`_. :ref:`telemetrics` is a |CL| feature that
|
||||
reports failures and crashes to the |CL| development team for improvements.
|
||||
For more detailed information, see our :ref:`telemetry-about` page.
|
||||
|
||||
#. In the main menu, navigate to :guilabel:`Telemetry` and select
|
||||
:kbd:`Enter`.
|
||||
|
||||
#. Select :kbd:`Tab` to highlight your choice.
|
||||
|
||||
#. Select :kbd:`Enter` to confirm.
|
||||
|
||||
.. figure:: figures/bare-metal-install-beta-13.png
|
||||
:scale: 100 %
|
||||
:alt: Enable Telemetry
|
||||
|
||||
Figure 13: :guilabel:`Enable Telemetry`
|
||||
|
||||
Skip to finish installation
|
||||
===========================
|
||||
|
||||
After selecting values for all :guilabel:`Required options`, you may skip directly to :ref:`finish-cl-installation`
|
||||
|
||||
If you wish to configure network interfaces or proxy settings,
|
||||
or add bundles, or add/manage users, continue to the next section.
|
||||
|
||||
Advanced Options
|
||||
****************
|
||||
|
||||
.. _configure-network-interfaces:
|
||||
|
||||
Configure Network Interfaces
|
||||
============================
|
||||
|
||||
By default, |CL| is configured to automatically detect the host network
|
||||
interface using DHCP. However, if you want to use a static IP address or if
|
||||
you do not have a DHCP server on your network, follow these instructions to
|
||||
manually configure the network interface. Otherwise, default network
|
||||
interface settings are automatically applied.
|
||||
|
||||
.. note::
|
||||
|
||||
If DHCP is available, no user selection may be required.
|
||||
|
||||
#. Navigate to :guilabel:`Configure Network Interfaces` and
|
||||
select :kbd:`Enter`.
|
||||
|
||||
#. Navigate to the network :guilabel:`interface` you wish to change.
|
||||
|
||||
#. When the desired :guilabel:`interface` is highlighted, select
|
||||
:guilabel:`Enter` to edit.
|
||||
|
||||
.. note:: Multiple network interfaces may appear.
|
||||
|
||||
.. figure:: figures/bare-metal-install-beta-14.png
|
||||
:scale: 100 %
|
||||
:alt: Configure Network Interfaces
|
||||
|
||||
Figure 14: :guilabel:`Configure Network Interfaces`
|
||||
|
||||
#. Notice :guilabel:`Automatic / dhcp` is selected by default (at bottom).
|
||||
|
||||
Optional: Navigate to the checkbox :guilabel:`Automatic / dhcp` and select
|
||||
:kbd:`Spacebar` to deselect.
|
||||
|
||||
.. figure:: figures/bare-metal-install-beta-15.png
|
||||
:scale: 100 %
|
||||
:alt: Network interface configuration
|
||||
|
||||
Figure 15: :guilabel:`Network interface configuration`
|
||||
|
||||
#. Navigate to the appropriate fields and assign the desired
|
||||
network configuration.
|
||||
|
||||
#. To save settings, navigate to :guilabel:`Confirm` and select
|
||||
:kbd:`Enter`.
|
||||
|
||||
.. note::
|
||||
|
||||
To revert to previous settings, navigate to the :guilabel:`Cancel`
|
||||
and select :kbd:`Enter`.
|
||||
|
||||
#. Upon confirming network configuration, the :guilabel:`Testing Networking`
|
||||
dialogue appears. Assure the result shows success. If a failure occurs,
|
||||
your changes will not be saved.
|
||||
|
||||
#. Upon confirmation, you are returned to :guilabel:`Network interface`
|
||||
settings.
|
||||
|
||||
#. Navigate to and select :guilabel:`Main Menu`.
|
||||
|
||||
Optional: :ref:`Skip to finish installation <finish-cl-installation>`.
|
||||
|
||||
Proxy
|
||||
=====
|
||||
|
||||
|CL| automatically attempts to detect proxy settings, as described in
|
||||
`Autoproxy`_. If you need to manually assign proxy settings, follow this
|
||||
instruction.
|
||||
|
||||
#. From the Advanced options menu, navigate to :guilabel:`Proxy`, and
|
||||
select :kbd:`Enter`.
|
||||
|
||||
#. Navigate to the field :guilabel:`HTTPS Proxy`.
|
||||
|
||||
.. figure:: figures/bare-metal-install-beta-16.png
|
||||
:scale: 100 %
|
||||
:alt: Configure the network proxy
|
||||
|
||||
Figure 16: :guilabel:`Configure the network proxy`
|
||||
|
||||
#. Enter the desired proxy address and port using conventional syntax,
|
||||
such as: http://address:port.
|
||||
|
||||
#. Navigate to :guilabel:`Confirm` and select :kbd:`Enter`.
|
||||
|
||||
#. To revert to previous settings, navigate to :guilabel:`Cancel`
|
||||
and select :guilabel:`Cancel`.
|
||||
|
||||
Optional: :ref:`Skip to finish installation <finish-cl-installation>`.
|
||||
|
||||
.. _test-network-settings:
|
||||
|
||||
Test Network Settings
|
||||
=====================
|
||||
|
||||
To manually assure network connectivity before installing |CL|,
|
||||
select :guilabel:`Test Network Settings` and select :guilabel:`Enter`.
|
||||
|
||||
A progress bar appears as shown in Figure 17.
|
||||
|
||||
.. figure:: figures/bare-metal-install-beta-17.png
|
||||
:scale: 100 %
|
||||
:alt: Testing Networking dialogue
|
||||
|
||||
Figure 17: :guilabel:`Testing Networking dialogue`
|
||||
|
||||
.. note::
|
||||
|
||||
Any changes made to network settings are automatically tested
|
||||
during configuration.
|
||||
|
||||
Optional: :ref:`Skip to finish installation <finish-cl-installation>`.
|
||||
|
||||
Bundle Selection
|
||||
================
|
||||
|
||||
#. On the Advanced menu, select :guilabel:`Bundle selection`
|
||||
|
||||
#. Navigate to the desired bundle using :kbd:`Tab` or :kbd:`Up/Down` arrows.
|
||||
|
||||
#. Select :kbd:`Spacebar` to select the checkbox for each desired bundle.
|
||||
|
||||
|
||||
.. figure:: figures/bare-metal-install-beta-18.png
|
||||
:scale: 100 %
|
||||
:alt: Bundle selection
|
||||
|
||||
Figure 18: :guilabel:`Bundle selection`
|
||||
|
||||
#. Select :kbd:`Confirm` or :kbd:`Cancel`.
|
||||
|
||||
You are returned to the :guilabel:`Advanced options` menu.
|
||||
|
||||
Optional: :ref:`Skip to finish installation <finish-cl-installation>`.
|
||||
|
||||
User Manager
|
||||
============
|
||||
|
||||
Add New User
|
||||
------------
|
||||
|
||||
#. In Advanced Options, select :guilabel:`User Manager`.
|
||||
|
||||
#. Select :guilabel:`Add New User` as shown in Figure 19.
|
||||
|
||||
.. figure:: figures/bare-metal-install-beta-19.png
|
||||
:scale: 100 %
|
||||
:alt: Add New User, User Name
|
||||
|
||||
Figure 19: :guilabel:`Add New User`
|
||||
|
||||
|
||||
#. Optional: Enter a :guilabel:`User Name`.
|
||||
|
||||
.. note:
|
||||
|
||||
The User Name must be alphanumeric and can include spaces, commas, or hyphens. Maximum length is 64 characters.
|
||||
|
||||
.. figure:: figures/bare-metal-install-beta-20.png
|
||||
:scale: 100 %
|
||||
:alt: User Name
|
||||
|
||||
Figure 20: :guilabel:`User Name`
|
||||
|
||||
#. Enter a :guilabel:`Login`.
|
||||
|
||||
.. note::
|
||||
|
||||
The User Login must be alphanumeric and can include hyphens and underscores. Maximum length is 31 characters.
|
||||
|
||||
#. Enter a :guilabel:`Password`.
|
||||
|
||||
.. note:
|
||||
|
||||
Minimum length is 8 characters. Maximum length is 255 characters.
|
||||
|
||||
#. In :guilabel:`Retype`, enter the same password.
|
||||
|
||||
#. Optional: Navigate to the :guilabel:`Administrative` checkbox and select
|
||||
:kbd:`Spacebar` to assign administrative rights to the user.
|
||||
|
||||
.. note::
|
||||
|
||||
Selecting this option enables sudo privileges for the user.
|
||||
|
||||
.. figure:: figures/bare-metal-install-beta-21.png
|
||||
:scale: 100 %
|
||||
:alt: Administrative rights
|
||||
|
||||
Figure 21: :guilabel:`Administrative rights`
|
||||
|
||||
#. Select :kbd:`Confirm`.
|
||||
|
||||
.. note::
|
||||
|
||||
If desired, select :guilabel:`Reset` to reset the form.
|
||||
|
||||
Modify / Delete User
|
||||
--------------------
|
||||
|
||||
#. In User Manager, select :guilabel:`Tab` to highlight the user, as shown
|
||||
in Figure 22.
|
||||
|
||||
#. Select :kbd:`Enter` to modify the user.
|
||||
|
||||
.. figure:: figures/bare-metal-install-beta-22.png
|
||||
:scale: 100 %
|
||||
:alt: Modify User
|
||||
|
||||
Figure 22: :guilabel:`Modify User`
|
||||
|
||||
#. Modify user details as desired.
|
||||
|
||||
Optional: To delete the user, navigate to the :guilabel:`Delete`
|
||||
button and select :kbd:`Enter`
|
||||
|
||||
#. Navigate to :kbd:`Confirm` until highlighted.
|
||||
|
||||
.. note::
|
||||
|
||||
Optional: Select :guilabel:`Reset` to rest the form.
|
||||
|
||||
#. Select :guilabel:`Confirm` to save the changes you made.
|
||||
|
||||
You are returned to the User Manager menu.
|
||||
|
||||
Optional: :ref:`Skip to finish installation <finish-cl-installation>`.
|
||||
|
||||
Kernel Command Line
|
||||
===================
|
||||
|
||||
For more advanced users, |CL| provides the ability to add, or remove, kernel
|
||||
arguments. If you want to append a new argument, enter the argument here.
|
||||
This argument will be used every time you install a new kernel or update a
|
||||
new kernel.
|
||||
|
||||
#. In Advanced Options, select :guilabel:`Tab` to highlight
|
||||
:guilabel:`Kernel Command Line`.
|
||||
|
||||
#. Select :kbd:`Enter`.
|
||||
|
||||
#. To add or remove arguments, choose one of the following options.
|
||||
|
||||
.. figure:: figures/bare-metal-install-beta-23.png
|
||||
:scale: 100 %
|
||||
:alt: kernel command line
|
||||
|
||||
Figure 23: :guilabel:`kernel command line`
|
||||
|
||||
#. To add arguments, enter the argument in :guilabel:`Add Extra Arguments`.
|
||||
|
||||
#. To remove an existing argument, enter the argument in
|
||||
:guilabel:`Remove Arguments`.
|
||||
|
||||
#. Select :kbd:`Confirm`.
|
||||
|
||||
Optional: :ref:`Skip to finish installation <finish-cl-installation>`.
|
||||
|
||||
Kernel Selection
|
||||
================
|
||||
|
||||
#. Select a kernel option. By default, the latest kernel release is
|
||||
selected.
|
||||
|
||||
.. note::
|
||||
|
||||
To choose a different kernel, such as Long Term Support (LTS), shown in Figure 24, navigate to it using :guilabel:`Tab`.
|
||||
|
||||
.. figure:: figures/bare-metal-install-beta-24.png
|
||||
:scale: 100 %
|
||||
:alt: Kernel selection
|
||||
|
||||
Figure 24: :guilabel:`Kernel selection`
|
||||
|
||||
#. Select :kbd:`Spacebar` to select the desired option.
|
||||
|
||||
#. Select :kbd:`Confirm`.
|
||||
|
||||
Optional: :ref:`Skip to finish installation <finish-cl-installation>`.
|
||||
|
||||
Swupd Mirror
|
||||
============
|
||||
|
||||
If you have your own custom mirror of |CL|, you may want to add that URL.
|
||||
|
||||
#. In Advanced Options, select :guilabel:`Swupd Mirror`.
|
||||
|
||||
#. To add a local swupd mirror, enter a valid URL in :guilabel:`Mirror URL:`
|
||||
|
||||
#. Select :kbd:`Confirm`.
|
||||
|
||||
.. figure:: figures/bare-metal-install-beta-25.png
|
||||
:scale: 100 %
|
||||
:alt: Swupd Mirror
|
||||
|
||||
Figure 25: :guilabel:`Swupd Mirror`
|
||||
|
||||
Optional: :ref:`Skip to finish installation <finish-cl-installation>`.
|
||||
|
||||
Assign Hostname
|
||||
===============
|
||||
|
||||
#. In Advanced Options, select :guilabel:`Assign Hostname`.
|
||||
|
||||
#. In :guilabel:`Hostname`, enter the hostname only (excluding the domain).
|
||||
|
||||
.. note::
|
||||
|
||||
Hostname does not allow empty spaces. Hostname must start with an
|
||||
alphanumeric character but may also contain hyphens. Maximum length of
|
||||
63 characters.
|
||||
|
||||
.. figure:: figures/bare-metal-install-beta-26.png
|
||||
:scale: 100 %
|
||||
:alt: Assign Hostname
|
||||
|
||||
Figure 26: :guilabel:`Assign Hostname`
|
||||
|
||||
|
||||
#. Navigate to :kbd:`Confirm` until highlighted.
|
||||
|
||||
#. Select :kbd:`Confirm`.
|
||||
|
||||
Optional: :ref:`Skip to finish installation <finish-cl-installation>`.
|
||||
|
||||
Automatic OS Updates
|
||||
====================
|
||||
|
||||
In the rare case that you need to disable automatic software updates,
|
||||
follow the onscreen instructions.
|
||||
|
||||
#. In Advanced Options, select :guilabel:`Automatic OS Updates`.
|
||||
|
||||
#. Select the desired option.
|
||||
|
||||
.. figure:: figures/bare-metal-install-beta-27.png
|
||||
:scale: 100 %
|
||||
:alt: Automatic OS Updates
|
||||
|
||||
Figure 27: :guilabel:`Automatic OS Updates`
|
||||
|
||||
You are returned to the :guilabel:`Main Menu`.
|
||||
|
||||
.. _finish-cl-installation:
|
||||
|
||||
Finish installation
|
||||
*******************
|
||||
|
||||
#. When you are satisfied with your installation configuration, navigate to
|
||||
:guilabel:`Install` and select :kbd:`Enter`.
|
||||
|
||||
.. note::
|
||||
|
||||
Whenever installation is finished, a ``reboot`` button appears.
|
||||
|
||||
#. Select ``reboot``.
|
||||
|
||||
#. When the system reboots, remove any installation media present.
|
||||
|
||||
**Congratulations!**
|
||||
|
||||
You have successfully installed |CL| on bare metal using the new installer.
|
||||
|
||||
.. _Navigate to the image directory: https://download.clearlinux.org/image/
|
||||
.. _Autoproxy: https://clearlinux.org/features/autoproxy
|
||||
.. _telemetry: https://clearlinux.org/features/telemetry
|
||||
|
After Width: | Height: | Size: 663 KiB |
|
After Width: | Height: | Size: 6.3 KiB |
|
After Width: | Height: | Size: 37 KiB |
|
After Width: | Height: | Size: 6.3 KiB |
|
After Width: | Height: | Size: 8.1 KiB |
|
After Width: | Height: | Size: 5.8 KiB |
|
After Width: | Height: | Size: 5.6 KiB |
|
After Width: | Height: | Size: 4.3 KiB |
|
After Width: | Height: | Size: 7.7 KiB |
|
After Width: | Height: | Size: 8.1 KiB |
|
After Width: | Height: | Size: 7.0 KiB |
|
After Width: | Height: | Size: 519 KiB |
|
After Width: | Height: | Size: 5.7 KiB |
|
After Width: | Height: | Size: 6.0 KiB |
|
After Width: | Height: | Size: 5.2 KiB |
|
After Width: | Height: | Size: 7.6 KiB |
|
After Width: | Height: | Size: 5.8 KiB |
|
After Width: | Height: | Size: 5.5 KiB |
|
After Width: | Height: | Size: 4.7 KiB |
|
After Width: | Height: | Size: 9.6 KiB |
|
After Width: | Height: | Size: 6.4 KiB |
|
After Width: | Height: | Size: 8.5 KiB |
|
After Width: | Height: | Size: 11 KiB |
|
After Width: | Height: | Size: 6.6 KiB |
|
After Width: | Height: | Size: 5.6 KiB |
|
After Width: | Height: | Size: 6.1 KiB |
|
After Width: | Height: | Size: 6.4 KiB |
@@ -6,9 +6,9 @@ Install |CL-ATTR| on bare metal (automatic)
|
||||
These instructions guide you through the installation of |CL-ATTR|
|
||||
on bare metal using a bootable USB drive.
|
||||
|
||||
Before you begin, check that your system meets the requirements to install |CL|:
|
||||
Before you begin, check that your system meets the requirements to install |CL|:
|
||||
|
||||
* :ref:`system-requirements`
|
||||
* :ref:`system-requirements`
|
||||
* :ref:`compatibility-check`
|
||||
|
||||
|
||||
@@ -19,7 +19,7 @@ Get the latest |CL| installer image from the `image`_ directory.
|
||||
Look for the :file:`clear-[version number]-installer.img.xz` file. You can also use this command:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
|
||||
curl -O https://download.clearlinux.org/image/$(curl https://download.clearlinux.org/image/latest-images | grep "installer")
|
||||
|
||||
Once you have downloaded the image, verify and decompress the file.
|
||||
@@ -58,7 +58,7 @@ Follow these steps to install |CL| on the target system:
|
||||
#. Reboot the target system.
|
||||
|
||||
#. The |CL| boot menu will start as shown in figure 1.
|
||||
Select :guilabel:`Clear Linux OS for Intel Architecture` and press the
|
||||
Select :guilabel:`Clear Linux OS` and press the
|
||||
:kbd:`Enter` key or wait five seconds to automatically select it.
|
||||
|
||||
.. figure:: figures/bare-metal-install-1.png
|
||||
@@ -225,7 +225,7 @@ process. Otherwise, you can follow the |CL| automatic installation steps.
|
||||
:guilabel:`< Automatic >` menu item shown in figure 7 and press the
|
||||
:kbd:`Enter` key.
|
||||
|
||||
The :guilabel:`Choose target device for installation` screen shown in figure 8 appears.
|
||||
The :guilabel:`Choose target device for installation` screen shown in figure 8 appears.
|
||||
|
||||
#. Move the cursor to the desired target and press the :kbd:`Enter`
|
||||
key.
|
||||
@@ -255,7 +255,7 @@ process. Otherwise, you can follow the |CL| automatic installation steps.
|
||||
through the automated installation process.
|
||||
|
||||
Once all steps have completed, you will see the :guilabel:`Successful
|
||||
installation` status message and the :guilabel:`< Ok >` button is highlighted as shown in figure 10.
|
||||
installation` status message and the :guilabel:`< Ok >` button is highlighted as shown in figure 10.
|
||||
|
||||
#. Press the :kbd:`Enter` key to continue.
|
||||
|
||||
@@ -266,10 +266,10 @@ process. Otherwise, you can follow the |CL| automatic installation steps.
|
||||
Figure 10: :guilabel:`Installation complete`
|
||||
|
||||
Figure 11 shows the final installer screen, showing that the
|
||||
installation completed successfully and the system will reboot.
|
||||
installation completed successfully and the system will reboot.
|
||||
|
||||
#. Press the :kbd:`Enter` key and remove the USB media while the system
|
||||
restarts.
|
||||
#. Press the :kbd:`Enter` key and remove the USB media while the system
|
||||
restarts.
|
||||
|
||||
.. figure:: figures/bare-metal-install-11.png
|
||||
:scale: 50 %
|
||||
@@ -306,8 +306,8 @@ Next steps
|
||||
**********
|
||||
|
||||
The automatic installation of |CL| is designed to install with minimal
|
||||
software overhead. Some housekeeping and package installations could be
|
||||
needed before you can take full advantage of the |CL| operating system.
|
||||
software overhead. Some housekeeping and package installations could be
|
||||
needed before you can take full advantage of the |CL| operating system.
|
||||
|
||||
See the :ref:`enable-user-space` guide for additional information and
|
||||
instructions.
|
||||
|
||||
|
Before Width: | Height: | Size: 51 KiB After Width: | Height: | Size: 37 KiB |
|
Before Width: | Height: | Size: 10 KiB After Width: | Height: | Size: 8.1 KiB |
|
Before Width: | Height: | Size: 269 KiB After Width: | Height: | Size: 248 KiB |
|
Before Width: | Height: | Size: 236 KiB After Width: | Height: | Size: 203 KiB |
@@ -0,0 +1,203 @@
|
||||
.. _bootable-usb-beta-all:
|
||||
|
||||
Create a bootable USB on your OS
|
||||
################################
|
||||
|
||||
Follow these instructions to create a bootable |CL-ATTR| USB drive based on
|
||||
your OS.
|
||||
|
||||
* :ref:`bootable-usb-linux-all`
|
||||
* :ref:`bootable-usb-mac-all`
|
||||
* :ref:`bootable-usb-windows-all`
|
||||
|
||||
Return to :ref:`install-from-live-image`
|
||||
|
||||
Requirements:
|
||||
*************
|
||||
|
||||
* Use a **16GB** or larger USB drive.
|
||||
|
||||
.. _bootable-usb-linux-all:
|
||||
|
||||
Create a bootable USB drive on Linux
|
||||
************************************
|
||||
|
||||
.. include:: ../../guides/maintenance/download-verify-decompress-linux.rst
|
||||
:Start-after: verify-linux:
|
||||
|
||||
|
||||
Burn the |CL| image onto a USB drive
|
||||
====================================
|
||||
|
||||
.. caution::
|
||||
|
||||
|CAUTION-BACKUP-USB|
|
||||
|
||||
#. Open a terminal emulator and get root privilege.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
sudo -s
|
||||
|
||||
#. Go to the directory with the decompressed image.
|
||||
#. Plug in the USB drive.
|
||||
#. Identify the USB drive using the :command:`lsblk` command. This shows all
|
||||
drives attached to the system, including the primary hard disk. In the
|
||||
example output below, there are 4 drives
|
||||
(`/dev/sda`, `/dev/sdb`, `/dev/sdc`, and `/dev/sdd`) attached, where
|
||||
`/dev/sda` is primary drive in this case. The remaining are 3 USB drives.
|
||||
The output also shows the mounted partitions (under the `MOUNTPOINT`
|
||||
column) for each drive.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
lsblk
|
||||
|
||||
Example output:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
|
||||
sdd 8:48 1 15G 0 disk
|
||||
├─sdd2 8:50 1 5G 0 part /run/media/user1/960c184f-3bb7-42b7-bcaf-0c1282
|
||||
├─sdd3 8:51 1 8G 0 part /run/media/user1/704f3382-b26d-4f34-af1b-cb9aab
|
||||
└─sdd1 8:49 1 2G 0 part
|
||||
sdb 8:16 1 14.8G 0 disk
|
||||
└─sdb1 8:17 1 14.8G 0 part /run/media/user1/PATRIOT_USB
|
||||
sdc 8:32 1 7.3G 0 disk
|
||||
└─sdc1 8:33 1 7.3G 0 part /run/media/user1/LINUX MINT
|
||||
sda 8:0 0 335.4G 0 disk
|
||||
├─sda4 8:4 0 28G 0 part
|
||||
├─sda2 8:2 0 3.7G 0 part [SWAP]
|
||||
├─sda7 8:7 0 6G 0 part /home
|
||||
├─sda5 8:5 0 1G 0 part /boot
|
||||
├─sda3 8:3 0 954M 0 part /boot/efi
|
||||
├─sda1 8:1 0 28G 0 part
|
||||
├─sda8 8:8 0 30G 0 part /
|
||||
└─sda6 8:6 0 7.9G 0 part [SWAP]
|
||||
|
||||
#. Before an image can be burned onto a USB drive, it should be un-mounted.
|
||||
Some Linux* distros may automatically mount a USB drive when it is plugged
|
||||
in. To unmount, use the :command:`umount` command followed by the device
|
||||
identifier/partition. For example: From the above :command:`lsblk` output,
|
||||
`/dev/sdd` has 2 mounted partitions. To unmount them, enter:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
umount /dev/sdd2
|
||||
umount /dev/sdd3
|
||||
|
||||
#. Burn the image onto the USB drive. The command-line example below burns an
|
||||
uncompressed image onto `/dev/sdd`:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
dd if=./clear-[version number]-[image type] of=/dev/sdd bs=4M status=progress
|
||||
|
||||
.. _bootable-usb-mac-all:
|
||||
|
||||
Create a bootable USB drive on macOS*
|
||||
*************************************
|
||||
|
||||
.. include:: ../../guides/maintenance/download-verify-decompress-mac.rst
|
||||
:start-after: verify-mac:
|
||||
|
||||
|
||||
Burn the |CL| image onto a USB drive
|
||||
====================================
|
||||
|
||||
.. caution::
|
||||
|
||||
|CAUTION-BACKUP-USB|
|
||||
|
||||
#. Launch the Terminal app.
|
||||
#. Go to the directory with the decompressed image.
|
||||
#. Plug in a USB drive and get its identifier by entering the command
|
||||
:command:`diskutil list`. See Figure 1.
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
diskutil list
|
||||
|
||||
.. figure:: figures/bootable-usb-mac-1.png
|
||||
:scale: 100 %
|
||||
:alt: Get USB drive identifier
|
||||
|
||||
Figure 1: macOS* - Get USB drive identifier
|
||||
|
||||
#. Unmount the USB drive identified in the previous step. The command-line
|
||||
example below umounts `/dev/disk2`:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
diskutil umountDisk /dev/disk2
|
||||
|
||||
#. Burn the image onto the drive using the :command:`dd` command. The
|
||||
command-line example below burns an uncompressed image onto `/dev/disk2`:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
sudo dd if=./clear-[version number]-[image type] of=/dev/rdisk2 bs=4m
|
||||
|
||||
|
||||
Adding an ‘r’ in front of the disk identifier should help speed up the
|
||||
imaging process.
|
||||
|
||||
You can press :kbd:`<CTL>-T` to check imaging progress.
|
||||
|
||||
#. Eject the USB drive.
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
diskutil eject /dev/disk2
|
||||
|
||||
.. _bootable-usb-windows-all:
|
||||
|
||||
Create a bootable USB drive on Windows\*
|
||||
****************************************
|
||||
|
||||
.. include:: ../../guides/maintenance/download-verify-decompress-windows.rst
|
||||
:Start-after: verify-windows:
|
||||
|
||||
Burn the |CL| image onto a USB drive
|
||||
====================================
|
||||
|
||||
.. caution::
|
||||
|
||||
|CAUTION-BACKUP-USB|
|
||||
|
||||
#. Download the `Rufus`_ utility to burn the image onto a USB drive.
|
||||
|
||||
#. Plug in the USB drive and open Rufus.
|
||||
|
||||
#. Click the :guilabel:`SELECT` button. See Figure 1.
|
||||
|
||||
.. figure:: figures/bootable-usb-windows-1.png
|
||||
:scale: 80 %
|
||||
:alt: Rufus utility - Click the SELECT button
|
||||
|
||||
Figure 1: Rufus utility - Click the SELECT button
|
||||
|
||||
#. Find and select the previously extracted |CL| image file.
|
||||
Then, click the :guilabel:`Open` button. See Figure 2.
|
||||
|
||||
.. figure:: figures/bootable-usb-windows-2.png
|
||||
:scale: 80 %
|
||||
:alt: Rufus utility - Show and select |CL| image file
|
||||
|
||||
Figure 2: Rufus utility - Show and select |CL| image file
|
||||
|
||||
#. Click the :guilabel:`START` button. See Figure 3.
|
||||
|
||||
.. figure:: figures/bootable-usb-windows-3.png
|
||||
:scale: 80 %
|
||||
:alt: Rufus utility - Click the START button
|
||||
|
||||
Figure 3: Rufus utility - Click START button
|
||||
|
||||
Return to install from live image
|
||||
*********************************
|
||||
|
||||
Return to :ref:`install-from-live-image`
|
||||
|
||||
.. _Rufus: https://rufus.ie/
|
||||
@@ -14,14 +14,16 @@ Pre-install
|
||||
* :ref:`compatibility-check`
|
||||
* :ref:`bootable-usb`
|
||||
|
||||
|
||||
|
||||
Install |CL|
|
||||
************
|
||||
|
||||
* :ref:`bare-metal-install`
|
||||
* :ref:`bare-metal-manual-install`
|
||||
* :ref:`virtual-machine-install`
|
||||
* :ref:`live-image`
|
||||
|
||||
* :ref:`live-image`
|
||||
* :ref:`bare-metal-install-beta`
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
@@ -33,4 +35,7 @@ Install |CL|
|
||||
virtual-machine-install/virtual-machine-install
|
||||
live-image
|
||||
compatibility-check
|
||||
bootable-usb/bootable-usb
|
||||
bootable-usb/bootable-usb
|
||||
|
||||
bare-metal-install-beta/bare-metal-install-beta
|
||||
bootable-usb/bootable-usb-beta-all
|
||||
|
||||
@@ -1,18 +0,0 @@
|
||||
.. _autoproxy:
|
||||
|
||||
Autoproxy
|
||||
#########
|
||||
|
||||
.. rst-class:: html-toggle
|
||||
|
||||
About
|
||||
=====
|
||||
|
||||
.. include:: autoproxy_about.rst.txt
|
||||
|
||||
.. rst-class:: html-toggle
|
||||
|
||||
Guide
|
||||
=====
|
||||
|
||||
.. include:: autoproxy_guide.rst.txt
|
||||
@@ -1,46 +0,0 @@
|
||||
The |CL-ATTR| is the first Linux distribution to support autoproxy. The OS
|
||||
can discover a Proxy Auto-Config (PAC) script and use it to automatically
|
||||
resolve the proxy needed for a given connection. With Autoproxy, you can use
|
||||
|CL| inside any proxy environment without having to manually
|
||||
configure the proxies:
|
||||
|
||||
* Automate unit testing without worrying about the proxy not being set
|
||||
* Remove unset proxies from the equation when dealing with network
|
||||
unavailability across systems.
|
||||
|
||||
* Automate unit testing without worrying about the proxy not being set
|
||||
* Remove unset proxies from the equation when dealing with network
|
||||
unavailability across systems.
|
||||
|
||||
Corporate and private networks can be very complex, needing to restrict and
|
||||
control network connections for security reasons. The typical side effects
|
||||
are limited or blocked connectivity and requiring manual configuration of
|
||||
proxies to perform the most mundane tasks such as cloning a repo or checking
|
||||
for updates. With |CL|, all of the work is done behind the scenes to
|
||||
effortlessly use your network and have connections “just work”.
|
||||
|
||||
How Autoproxy works
|
||||
-------------------
|
||||
|
||||
We designed autoproxy around general tools provided by nearly any Linux
|
||||
distribution with a few minor additions and modifications. We leveraged the
|
||||
DHCP and network information provided from systemd and created a
|
||||
PAC-discovery daemon. The daemon uses the information to resolve a URL for a
|
||||
PAC file. The daemon then passes the URL into PACrunner*. PACrunner
|
||||
downloads the PAC file and uses the newly implemented Duktape* engine to
|
||||
parse it.
|
||||
|
||||
.. figure:: figures/autoproxy_0.png
|
||||
:width: 400px
|
||||
|
||||
Figure 1: Autoproxy Flow
|
||||
|
||||
From that point on, any cURL* or network requests query PACrunner for the
|
||||
correct proxy to use. We modified the cURL library to communicate with
|
||||
PACrunner over DBus. However, cURL will ignore PACrunner and run normally if
|
||||
no PAC file is loaded or if you set any proxies manually. Thus, your
|
||||
environment settings are respected and no time is wasted trying to resolve a
|
||||
proxy.
|
||||
|
||||
More importantly: all these steps happen in the background, very quickly, and
|
||||
with no user interaction.
|
||||
@@ -1,79 +0,0 @@
|
||||
Autoproxy allows |CL| to operate seamlessly behind a proxy
|
||||
because :ref:`software update <swupd-guide>` and other |CL| tools are
|
||||
implemented on top of libcurl. Tools that do not use libcurl, like git, must
|
||||
be configured independently.
|
||||
|
||||
If you encounter problems with autoproxy functioning, use
|
||||
:command:`sudo pacdiscovery` and :command:`FindProxyForURL` to
|
||||
help troubleshoot assuming a familiarity with PAC files and WPAD.
|
||||
|
||||
.. note::
|
||||
|
||||
Learn more about WPAD, PAC files, and PAC functions at `findproxyforurl`_.
|
||||
|
||||
.. _findproxyforurl: http://findproxyforurl.com/
|
||||
|
||||
Running :command:`pacdiscovery` with no arguments will immediately indicate
|
||||
one of the following:
|
||||
|
||||
1. If there is a problem resolving the :command:`WPAD` host name resolution:
|
||||
|
||||
.. code:: console
|
||||
|
||||
$ pacdiscovery
|
||||
failed getaddrinfo: No address associated with hostname
|
||||
Unable to find wpad host
|
||||
|
||||
2. Or if the :command:`pacrunner` service is disabled (masked):
|
||||
|
||||
.. code:: console
|
||||
|
||||
$ pacdiscovery
|
||||
PAC url: http://autoproxy.your.domain.com/wpad.dat
|
||||
Failed to create proxy config: Unit pacrunner.service is masked.
|
||||
|
||||
Unmask the :command:`pacrunner` service by running:
|
||||
|
||||
.. code:: console
|
||||
|
||||
$ systemctl unmask pacrunner.service
|
||||
|
||||
:command:`FindProxyForURL` with :command:`busctl` can also indicate if the
|
||||
:command:`pacrunner.service` is masked.
|
||||
|
||||
.. code:: console
|
||||
|
||||
$ busctl call org.pacrunner /org/pacrunner/client org.pacrunner.Client FindProxyForURL ss "http://www.google.com" "google.com"
|
||||
Unit pacrunner.service is masked.
|
||||
dig wpad, dig wpad.<domain>
|
||||
|
||||
:command:`FindProxyForURL` returns the URL and port of the proxy server when
|
||||
an external URL and host are provided as arguments.
|
||||
|
||||
.. code:: console
|
||||
|
||||
$ busctl call org.pacrunner /org/pacrunner/client org.pacrunner.Client FindProxyForURL ss "http://www.google.com" "google.com"
|
||||
s "PROXY proxy.your.domain.com:<port>"
|
||||
|
||||
If a proxy server is not available, or if :command:`pacrunner` is running
|
||||
without a PAC file, :command:`FindProxyForURL` will return "DIRECT". Otherwise,
|
||||
it should return your local proxy settings as shown above.
|
||||
|
||||
.. code:: console
|
||||
|
||||
$ busctl call org.pacrunner /org/pacrunner/client org.pacrunner.Client FindProxyForURL ss "http://www.google.com" "google.com"
|
||||
s "DIRECT"
|
||||
|
||||
Once :command:`pacdiscovery` is able to look up :command:`WPAD`, restart the
|
||||
:command:`pacrunner` service:
|
||||
|
||||
.. code:: console
|
||||
|
||||
$ systemctl stop pacrunner
|
||||
$ systemctl restart pacdiscovery
|
||||
|
||||
.. note::
|
||||
|
||||
A "domain" or "search" entry in :file:`/etc/resolv.conf` is required for short
|
||||
name lookups to resolve. The :file:`resolv.conf` man page has additional
|
||||
details.
|
||||
|
Before Width: | Height: | Size: 24 KiB |
@@ -1,21 +1,21 @@
|
||||
.. _deploy-at-scale.rst:
|
||||
|
||||
Deploying |CL| at Scale
|
||||
#######################
|
||||
Deploy at Scale
|
||||
###############
|
||||
|
||||
Once you are comfortable with `Clear Linux concepts`_, your next step
|
||||
as a system administrator is to understand how to deploy Clear Linux*
|
||||
at scale in your environment.
|
||||
Once you are comfortable with |CL-ATTR| :ref:`concepts <concepts>`, your next step
|
||||
as a system administrator is to understand how to deploy |CL|
|
||||
at scale in your environment.
|
||||
|
||||
In this document the term *endpoint* refers to a system targeted for
|
||||
|CL| installation, whether that is a datacenter system or unit deployed in
|
||||
field.
|
||||
field.
|
||||
|
||||
.. note::
|
||||
|
||||
This is not a replacement or blueprint for designing your own IT
|
||||
operating environment.
|
||||
|
||||
operating environment.
|
||||
|
||||
Your |CL| deployment should complement the existing environment and
|
||||
available tools. It is assumed foundational core IT dependencies of your
|
||||
environment, such as your network, are healthy and scaled to suit the
|
||||
@@ -27,27 +27,27 @@ field.
|
||||
Pick a |CL| usage and update strategy
|
||||
=====================================
|
||||
|
||||
Different business scenarios call for different deployment methodologies.
|
||||
|CLOSIA| offers the flexibility to continue consuming the upstream |CL|
|
||||
Different business scenarios call for different deployment methodologies.
|
||||
|CL| offers the flexibility to continue consuming the upstream |CL|
|
||||
distribution or the option to fork away from the |CL| distribution and
|
||||
act as your own :abbr:`OSV (Operating System Vendor)`.
|
||||
act as your own :abbr:`OSV (Operating System Vendor)`.
|
||||
|
||||
Below are overviews of both approaches and some considerations.
|
||||
|
||||
Option #1: Use the |CL| as the upstream origin (mixin)
|
||||
------------------------------------------------------
|
||||
|
||||
This approach is *easier to adopt* by relying on the |CL| upstream for
|
||||
packaging updates for you to deploy.
|
||||
This approach is *easier to adopt* by relying on the |CL| upstream for
|
||||
packaging updates for you to deploy.
|
||||
|
||||
Custom software or packages that are not available in a preformed bundle
|
||||
can be added using the `mixin process`_ to form a custom bundle.
|
||||
If custom bundles are needed, you will be responsible for maintaining
|
||||
the custom bundle(s) and testing between |CL| releases in your environment,
|
||||
while the rest of the operating system and preformed bundles come from the
|
||||
can be added using the `mixin process`_ to form a custom bundle.
|
||||
If custom bundles are needed, you will be responsible for maintaining
|
||||
the custom bundle(s) and testing between |CL| releases in your environment,
|
||||
while the rest of the operating system and preformed bundles come from the
|
||||
|CL| upstream.
|
||||
|
||||
#. Ensure |CL| systems are able to be inventoried, managed, and orchestrated
|
||||
|
||||
#. Ensure |CL| systems are able to be inventoried, managed, and orchestrated
|
||||
to coordinate software updates.
|
||||
|
||||
#. With autoupdate enabled, |CL| is updated daily, however you may wish to
|
||||
@@ -56,70 +56,70 @@ while the rest of the operating system and preformed bundles come from the
|
||||
yourself which is realistic with the operational expectations of your
|
||||
environment.
|
||||
|
||||
#. Use a web caching proxy for |CL| updates for devices connected to
|
||||
a local area network (LAN), like a datacenter, to increase the speed
|
||||
and resiliency of updates from the |CL| update servers.
|
||||
|
||||
Your caching proxy server is just like any other web application.
|
||||
#. Use a web caching proxy for |CL| updates for devices connected to
|
||||
a local area network (LAN), like a datacenter, to increase the speed
|
||||
and resiliency of updates from the |CL| update servers.
|
||||
|
||||
Your caching proxy server is just like any other web application.
|
||||
|WEB-SERVER-SCALE|
|
||||
|
||||
Option #2: Create your own Linux distribution (mix)
|
||||
---------------------------------------------------
|
||||
|
||||
This approach forks away from the |CL| upstream and has you act as your own
|
||||
:abbr:`OSV (Operating System Vendor)` by leveraging the `mixer process`_ to
|
||||
create customized images based on |CL|. This is a level of responsibility
|
||||
that requires having more infrastructure and processes to adopt. In return,
|
||||
This approach forks away from the |CL| upstream and has you act as your own
|
||||
:abbr:`OSV (Operating System Vendor)` by leveraging the `mixer process`_ to
|
||||
create customized images based on |CL|. This is a level of responsibility
|
||||
that requires having more infrastructure and processes to adopt. In return,
|
||||
this approach *offers you a high degree of control and customization*.
|
||||
|
||||
* Development systems which are generating bundles and updates should be
|
||||
sufficiently performant for the task and separate from the swupd update
|
||||
* Development systems which are generating bundles and updates should be
|
||||
sufficiently performant for the task and separate from the swupd update
|
||||
webservers which are serving update content to production machines.
|
||||
|
||||
* swupd update webservers which are serving update content to
|
||||
* swupd update webservers which are serving update content to
|
||||
production machines (see `mixer process`_ for more information) should be
|
||||
appropriately scaled.
|
||||
appropriately scaled.
|
||||
|
||||
Your swupd update server is just like any other web application.
|
||||
|WEB-SERVER-SCALE|
|
||||
Your swupd update server is just like any other web application.
|
||||
|WEB-SERVER-SCALE|
|
||||
|
||||
Adopt an agile methodology
|
||||
--------------------------
|
||||
The cloud, and other scaled deployments, are all about flexibility and speed.
|
||||
It only makes sense that any |CL| deployment strategy should follow suit.
|
||||
It only makes sense that any |CL| deployment strategy should follow suit.
|
||||
|
||||
Manually rebuilding your own bundles or mix for every release is not
|
||||
sustainable at a large scale. A |CL| deployment pipeline should be agile
|
||||
enough to validate and produce new versions with speed. Whether or not those
|
||||
updates actually make their way to your production can be separate
|
||||
business decision. However this *ability to frequently roll new versions* of
|
||||
software to your endpoints is an important prerequisite.
|
||||
Manually rebuilding your own bundles or mix for every release is not
|
||||
sustainable at a large scale. A |CL| deployment pipeline should be agile
|
||||
enough to validate and produce new versions with speed. Whether or not those
|
||||
updates actually make their way to your production can be separate
|
||||
business decision. However this *ability to frequently roll new versions* of
|
||||
software to your endpoints is an important prerequisite.
|
||||
|
||||
You own the validation and lifecycle of the OS and should treat it like any
|
||||
You own the validation and lifecycle of the OS and should treat it like any
|
||||
other software development lifecycle. Below are some pointers:
|
||||
|
||||
* Thoroughly understand the custom software packages that you will need to
|
||||
integrate with |CL| and maintain along with their dependencies.
|
||||
|
||||
* Setup a path to production for building |CL| based images. At minimum this
|
||||
* Setup a path to production for building |CL| based images. At minimum this
|
||||
should include:
|
||||
|
||||
* A development clr-on-clr environment to test building packages and
|
||||
bundles for |CL| systems.
|
||||
* A development clr-on-clr environment to test building packages and
|
||||
bundles for |CL| systems.
|
||||
|
||||
* A pre-production environment to deploy |CL| versions to before
|
||||
production
|
||||
* A pre-production environment to deploy |CL| versions to before
|
||||
production
|
||||
|
||||
* Employ a continuous integration and continuous deployment (CI/CD)
|
||||
philosophy in order to:
|
||||
|
||||
- Automatically pull custom packages as they are updated from their
|
||||
upstream projects or vendors.
|
||||
- Automatically pull custom packages as they are updated from their
|
||||
upstream projects or vendors.
|
||||
|
||||
- Generate |CL| bundles and potentially bootable images with your
|
||||
customizations, if any.
|
||||
- Generate |CL| bundles and potentially bootable images with your
|
||||
customizations, if any.
|
||||
|
||||
- Measure against metrics and indicators which are relevant to your
|
||||
- Measure against metrics and indicators which are relevant to your
|
||||
business (e.g. performance, power, etc) from release to release.
|
||||
|
||||
- Integrate with your organization's governance processes, such as change
|
||||
@@ -128,92 +128,93 @@ other software development lifecycle. Below are some pointers:
|
||||
Versioning Infrastructure
|
||||
-------------------------
|
||||
|
||||
|CL| version numbers are very important as they apply to the whole
|
||||
|CL| version numbers are very important as they apply to the whole
|
||||
infrastructure stack from OS components to libraries and
|
||||
applications.
|
||||
applications.
|
||||
|
||||
Good record keeping is important, so you should keep a detailed registry
|
||||
Good record keeping is important, so you should keep a detailed registry
|
||||
and history of previously deployed versions and their contents.
|
||||
|
||||
With a glance at the |CL| version numbers deployed, you should be
|
||||
able to tell if your Clear systems are patched against a
|
||||
able to tell if your Clear systems are patched against a
|
||||
particular security vulnerability or incorporate a critical new feature.
|
||||
|
||||
|
||||
Pick an image distribution strategy
|
||||
===================================
|
||||
|
||||
Once you have decided on a usage and update strategy, you should understand
|
||||
*how* |CL| will be deployed to your endpoints. In a large scale
|
||||
deployment, interactive installers should be avoided in favor of automated
|
||||
Once you have decided on a usage and update strategy, you should understand
|
||||
*how* |CL| will be deployed to your endpoints. In a large scale
|
||||
deployment, interactive installers should be avoided in favor of automated
|
||||
installations or prebuilt images.
|
||||
|
||||
There are many well-known ways to install an operating system at scale. Each
|
||||
have their own benefits, and one may lend itself easier in your environment
|
||||
There are many well-known ways to install an operating system at scale. Each
|
||||
have their own benefits, and one may lend itself easier in your environment
|
||||
depending on the resources available to you.
|
||||
|
||||
See the `reference of Clear Linux image types`_
|
||||
|
||||
See the available :ref:`image-types`.
|
||||
|
||||
Below are some common ways to install |CL| to systems at scale:
|
||||
|
||||
Baremetal
|
||||
---------
|
||||
|
||||
Preboot Execution Environments (PXE) or other
|
||||
Preboot Execution Environments (PXE) or other
|
||||
out-of-band booting options are one way to distribute |CL|
|
||||
to physical baremetal systems on a LAN.
|
||||
|
||||
This option works well if your customizations are fairly small in size
|
||||
and infrastructure can be stateless.
|
||||
This option works well if your customizations are fairly small in size
|
||||
and infrastructure can be stateless.
|
||||
|
||||
The |CL| `downloads page`_ offers a Live Image that can be deployed as
|
||||
The |CL| `downloads page`_ offers a live image that can be deployed as
|
||||
a PXE boot server if one doesn't already exist in your environment. Also see
|
||||
`documentation on installing Clear Linux on bare metal systems`_
|
||||
documentation on how to :ref:`bare-metal-install`.
|
||||
|
||||
Cloud Instances or Virtual Machines
|
||||
Cloud Instances or Virtual Machines
|
||||
-----------------------------------
|
||||
Image templates in the form of cloneable disks are an effective way to
|
||||
distribute |CL| for virtual machine environments, whether on-premises or
|
||||
hosted by a Cloud Solution Provider (CSP).
|
||||
|
||||
When used in concert with cloud VM migration features,
|
||||
this can be a good option for allowing your applications a degree of high
|
||||
availability and workload mobility; VMs can be restarted on a cluster of
|
||||
hypervisor host or moved between datacenters transparently.
|
||||
Image templates in the form of cloneable disks are an effective way to
|
||||
distribute |CL| for virtual machine environments, whether on-premises or
|
||||
hosted by a Cloud Solution Provider (CSP).
|
||||
|
||||
The |CL| `downloads page`_ offers example prebuilt VM images and is
|
||||
readily available on popular CSPs. Also see
|
||||
`documentation on installing Clear Linux in VMs`_.
|
||||
When used in concert with cloud VM migration features,
|
||||
this can be a good option for allowing your applications a degree of high
|
||||
availability and workload mobility; VMs can be restarted on a cluster of
|
||||
hypervisor host or moved between datacenters transparently.
|
||||
|
||||
The |CL| `downloads page`_ offers example prebuilt VM images and is
|
||||
readily available on popular CSPs. Also see
|
||||
documentation on how to :ref:`virtual-machine-install`.
|
||||
|
||||
Containers
|
||||
----------
|
||||
|
||||
Containerization platforms allow images to be pulled from a
|
||||
repository and deployed repeatedly as isolated containers.
|
||||
Containerization platforms allow images to be pulled from a
|
||||
repository and deployed repeatedly as isolated containers.
|
||||
|
||||
Containers with a |CL| image can be a good option to blueprint and ship
|
||||
your application, including all its dependencies, as an artifact while
|
||||
allowing you or your customers to dynamically orchestrate and scale
|
||||
Containers with a |CL| image can be a good option to blueprint and ship
|
||||
your application, including all its dependencies, as an artifact while
|
||||
allowing you or your customers to dynamically orchestrate and scale
|
||||
applications.
|
||||
|
||||
|CL| is capable of running a Docker host, has a container image which can
|
||||
|CL| is capable of running a Docker host, has a container image which can
|
||||
be pulled from DockerHub, or can be built as a customized container.
|
||||
For more information visit the `containers page`_.
|
||||
|
||||
Considerations with stateless systems
|
||||
=====================================
|
||||
An important |CL| concept is statelessness and partitioning of system data
|
||||
from user data. This concept can change the way you think about an at scale
|
||||
An important |CL| concept is statelessness and partitioning of system data
|
||||
from user data. This concept can change the way you think about an at scale
|
||||
deployment.
|
||||
|
||||
Backup strategy
|
||||
---------------
|
||||
|
||||
A |CL| system and its infrastructure should be considered a commodity and
|
||||
A |CL| system and its infrastructure should be considered a commodity and
|
||||
be easily reproducible. Avoid focusing on backing up the operating system
|
||||
itself or default values.
|
||||
itself or default values.
|
||||
|
||||
Instead, focus on backing up what's important and unique - the application
|
||||
and data. In other words, only focus on backing up critical areas like
|
||||
Instead, focus on backing up what's important and unique - the application
|
||||
and data. In other words, only focus on backing up critical areas like
|
||||
`/home`, `/etc`, and `/var`.
|
||||
|
||||
Meaningful Logging & Telemetry
|
||||
@@ -222,16 +223,16 @@ Meaningful Logging & Telemetry
|
||||
Offload logging and telemetry from endpoints to external servers, so it is
|
||||
persistent and can be accessed on another server when an issue occurs.
|
||||
|
||||
* Remote syslogging in |CL| is available through the
|
||||
`systemd journal-remote service`_
|
||||
* Remote syslogging in |CL| is available through the
|
||||
`systemd journal-remote service`_
|
||||
|
||||
* |CL| offers a `native telemetry solution`_ which can be a powerful tool
|
||||
for a large deployment to quickly crowdsource issues of interest. Take
|
||||
* |CL| offers a `native telemetry solution`_ which can be a powerful tool
|
||||
for a large deployment to quickly crowdsource issues of interest. Take
|
||||
advantage of this feature with careful consideration of the target audience
|
||||
and the kind of data that would be valuable, and expose events
|
||||
appropriately.
|
||||
appropriately.
|
||||
|
||||
Your telemetry server is just like any other web application.
|
||||
Your telemetry server is just like any other web application.
|
||||
|WEB-SERVER-SCALE|
|
||||
|
||||
Orchestration and Configuration Management
|
||||
@@ -240,47 +241,43 @@ Orchestration and Configuration Management
|
||||
In cloud environments, where systems can be ephemeral, being able to
|
||||
configure and maintain generic instances is valuable.
|
||||
|
||||
|CL| offers an efficient cloud-init style solution, `micro-config-drive`_,
|
||||
|CL| offers an efficient cloud-init style solution, `micro-config-drive`_,
|
||||
through the *os-cloudguest* bundles which allow you to configure many Day 1
|
||||
tasks such as setting hostname, creating users, or placing
|
||||
SSH keys in an automated way at boot. For more information on
|
||||
automating configuration during deployment of |CL| endpoints see
|
||||
tasks such as setting hostname, creating users, or placing
|
||||
SSH keys in an automated way at boot. For more information on
|
||||
automating configuration during deployment of |CL| endpoints see
|
||||
the `documentation on bulk provisioning`_ .
|
||||
|
||||
A configuration management tool is useful for maintaining consistent system
|
||||
and application-level configuration. Ansible\* is offered through the
|
||||
|
||||
A configuration management tool is useful for maintaining consistent system
|
||||
and application-level configuration. Ansible\* is offered through the
|
||||
*sysadmin-hostmgmt* bundle as a configuration management and automation
|
||||
tool.
|
||||
tool.
|
||||
|
||||
Cloud-native applications
|
||||
-------------------------
|
||||
|
||||
An Infrastructure OS can design for good behavior, but it is ultimately up
|
||||
to applications to make agile design choices. Applications deployed
|
||||
on |CL| should aim to be host-aware but not depend on any specific host to
|
||||
An Infrastructure OS can design for good behavior, but it is ultimately up
|
||||
to applications to make agile design choices. Applications deployed
|
||||
on |CL| should aim to be host-aware but not depend on any specific host to
|
||||
run. References should be relative and dynamic when possible.
|
||||
|
||||
The application architecture should incorporate an appropriate tolerance for
|
||||
infrastructure outages. Don't just keep stateless design as a noted feature.
|
||||
Continuously test its use; Automate its use by redeploying |CL| and
|
||||
application on new hosts. This naturally minimizes configuration drift,
|
||||
The application architecture should incorporate an appropriate tolerance for
|
||||
infrastructure outages. Don't just keep stateless design as a noted feature.
|
||||
Continuously test its use; Automate its use by redeploying |CL| and
|
||||
application on new hosts. This naturally minimizes configuration drift,
|
||||
challenges your monitoring systems, and business continuity plans.
|
||||
|
||||
.. _`Clear Linux concepts`: https://clearlinux.org/documentation/clear-linux/concepts
|
||||
.. _`mixin process`: https://clearlinux.org/documentation/clear-linux/guides/maintenance/mixin
|
||||
.. _`mixer process`: https://clearlinux.org/documentation/clear-linux/guides/maintenance/mixer
|
||||
.. _`reference of Clear Linux image types`: https://clearlinux.org/documentation/clear-linux/guides/maintenance/image-types
|
||||
.. _`documentation on installing Clear Linux on bare metal systems`: https://clearlinux.org/documentation/clear-linux/get-started/bare-metal-install
|
||||
.. _`downloads page`: https://download.clearlinux.org/image/
|
||||
.. _`documentation on installing Clear Linux in VMs`: https://clearlinux.org/documentation/clear-linux/get-started/virtual-machine-install
|
||||
.. _`containers page`: https://clearlinux.org/containers
|
||||
.. _`systemd journal-remote service`: https://www.freedesktop.org/software/systemd/man/systemd-journal-remote.service.html
|
||||
.. _`native telemetry solution`: https://clearlinux.org/features/telemetry
|
||||
.. _`micro-config-drive`: https://github.com/clearlinux/micro-config-drive
|
||||
.. _`documentation on bulk provisioning`: https://clearlinux.org/documentation/clear-linux/guides/maintenance/bulk-provision
|
||||
|
||||
.. |WEB-SERVER-SCALE| replace::
|
||||
There are many well-known ways to achieve a scalable and resilient web
|
||||
.. |WEB-SERVER-SCALE| replace::
|
||||
There are many well-known ways to achieve a scalable and resilient web
|
||||
server for this purpose, however implementation details are not in the
|
||||
scope of this document. In general, they should be close to your
|
||||
endpoints, highly available, and easy to scale with a load balancer when
|
||||
|
||||
@@ -3,41 +3,20 @@
|
||||
Guides
|
||||
######
|
||||
|
||||
Our Guides:
|
||||
Our Guides:
|
||||
|
||||
* Provide a critical, fundamental understanding of |CL-ATTR| features
|
||||
* Show you how to leverage the full feature set of |CL|
|
||||
* Enhance your productivity when using |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>`.
|
||||
|
||||
Clear Linux Tooling
|
||||
===================
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
:glob:
|
||||
:maxdepth: 2
|
||||
|
||||
clearlinux/*
|
||||
telemetrics/telemetrics
|
||||
|
||||
Maintenance
|
||||
===========
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
:glob:
|
||||
|
||||
maintenance/*
|
||||
maintenance/maintenance
|
||||
network/network
|
||||
deploy-at-scale
|
||||
|
||||
Network
|
||||
=======
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
:glob:
|
||||
|
||||
network/*
|
||||
telemetrics/telemetrics
|
||||
|
||||
@@ -0,0 +1,71 @@
|
||||
.. _assign-static-ip:
|
||||
|
||||
Assign a static IP address to a network interface
|
||||
#################################################
|
||||
|
||||
Introduction
|
||||
************
|
||||
|
||||
By default, your |CL-ATTR| system automatically gets an IP address from your
|
||||
network via DHCP. If you do not have a DHCP server on your network or simply
|
||||
want to use a static IP address, follow the steps in this guide.
|
||||
|
||||
Process
|
||||
*******
|
||||
|
||||
#. Create this directory structure:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
sudo mkdir -p /etc/systemd/network
|
||||
|
||||
#. Identify the interface to be assigned the static IP address:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
ip addr
|
||||
|
||||
The system returns the following:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
|
||||
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
|
||||
inet 127.0.0.1/8 scope host lo
|
||||
valid_lft forever preferred_lft forever
|
||||
inet6 ::1/128 scope host
|
||||
valid_lft forever preferred_lft forever
|
||||
|
||||
2: wlp1s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
|
||||
link/ether 4a:98:8d:e5:43:15 brd ff:ff:ff:ff:ff:ff
|
||||
|
||||
3: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq state UP group default qlen 1000
|
||||
link/ether f4:4d:30:68:96:20 brd ff:ff:ff:ff:ff:ff
|
||||
inet 10.0.1.2/24 brd 10.54.74.255 scope global dynamic eno1
|
||||
valid_lft 6766sec preferred_lft 6766sec
|
||||
inet6 fe80::f64d:30ff:fe68:9620/64 scope link
|
||||
valid_lft forever preferred_lft forever
|
||||
|
||||
In this example, we will use the `eno1` interface.
|
||||
|
||||
#. Create the :file:`70-static.network` file and add the following:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
sudo $EDITOR /etc/systemd/network/70-static.network
|
||||
|
||||
[Match]
|
||||
Name=[interface name]
|
||||
[Network]
|
||||
Address=[IP address]/24
|
||||
DHCP=yes # to get DNS info, etc.
|
||||
|
||||
Replace [interface name] and [IP address] with your specific settings.
|
||||
|
||||
#. Restart the networkd service:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
sudo systemctl restart systemd-networkd
|
||||
|
||||
**Congratulations!** You have successfully assigned a static IP address.
|
||||
@@ -96,8 +96,7 @@ we build a new helloclear RPM.
|
||||
|
||||
.. note::
|
||||
|
||||
For a local tarball, use for the *URL*:
|
||||
file://<absolute-path-to-tarball>
|
||||
For a local tarball, use this type of *URL*: \file://<absolute-path-to-tarball>
|
||||
|
||||
#. If build failures or dependency issues occur, continue below.
|
||||
Otherwise, skip directly to `Next steps`_.
|
||||
|
||||
@@ -3,42 +3,39 @@
|
||||
Developer Workstation
|
||||
#####################
|
||||
|
||||
Overview
|
||||
********
|
||||
*Developer Workstation* helps you find the :ref:`bundles-about` you need to
|
||||
start your |CL-ATTR| development project.
|
||||
|
||||
*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
|
||||
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.
|
||||
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
|
||||
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 |CL| 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.
|
||||
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.
|
||||
Use Table 1, *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**
|
||||
.. list-table:: **Table 1. Developer Profiles**
|
||||
:widths: 20, 20, 20, 20
|
||||
:header-rows: 1
|
||||
|
||||
* - Clear Linux Bundle
|
||||
- *Internet of Things (IoT)*
|
||||
* - |CL| Bundle
|
||||
- *Internet of Things (IoT)*
|
||||
- *System Administrator*
|
||||
- *Client/Cloud/Web Developer*
|
||||
|
||||
* - `editors`
|
||||
|
||||
* - `editors`
|
||||
- ✓
|
||||
- ✓
|
||||
- ✓
|
||||
@@ -52,60 +49,60 @@ While your role may not neatly fit in one of these categories, consider using Ta
|
||||
- ✓
|
||||
- ✓
|
||||
- ✓
|
||||
|
||||
|
||||
* - `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.
|
||||
commands to search for and add bundles relevant to your project.
|
||||
|
||||
:ref:`swupd-search` shows you how to:
|
||||
:ref:`swupd-search` shows you how to:
|
||||
|
||||
* Use `swupd` to search for bundles
|
||||
* 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.
|
||||
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>`
|
||||
* :ref:`Autospec <autospec-about>`
|
||||
|
||||
Other resources for developers
|
||||
-----------------------------------
|
||||
|
||||
* `Developer Tooling Framework for Clear Linux`_
|
||||
* `Clear Linux Bundles`_
|
||||
* `Developer Tooling Framework`_ for |CL|
|
||||
* `Bundle definition files`_
|
||||
|
||||
.. _Clear Linux Bundles: https://github.com/clearlinux/clr-bundles
|
||||
.. _Bundle definition files: https://github.com/clearlinux/clr-bundles
|
||||
|
||||
.. _Developer Tooling Framework for Clear Linux: https://github.com/clearlinux/common
|
||||
.. _Developer Tooling Framework: https://github.com/clearlinux/common
|
||||
|
||||
@@ -4,7 +4,7 @@ Create and enable a new user space
|
||||
##################################
|
||||
|
||||
This section provides steps to complete the following basic setup tasks for
|
||||
a newly installed |CLOSIA| system:
|
||||
a newly installed |CL-ATTR| system:
|
||||
|
||||
* Create a new user.
|
||||
* Update the OS to its most current version using `swupd`.
|
||||
@@ -51,7 +51,7 @@ Install the `sysadmin-basic` bundle:
|
||||
|
||||
We provide the full list of bundles and packages installed with the
|
||||
`sysadmin-basic`_ bundle. Additionally, we have listed
|
||||
`all Clear Linux bundles`_, active or deprecated. Click any bundle on the
|
||||
`all bundles`_ for |CL|, active or deprecated. Click any bundle on the
|
||||
list to view the manifest of the bundle.
|
||||
|
||||
Set up a new user and add the new user to the `wheel` group
|
||||
@@ -88,7 +88,7 @@ Install a GUI to test `sudo` privileges
|
||||
.. note::
|
||||
|
||||
If you are following this sequence after just setting up the
|
||||
pre-configured VMware\* virtual machine from the repo, you must
|
||||
pre-configured VMware\* virtual machine from the repo, you must
|
||||
:ref:`increase virtual disk size<increase-virtual-disk-size>` or the
|
||||
following step will fail.
|
||||
|
||||
@@ -136,7 +136,7 @@ system.
|
||||
.. _`sysadmin-basic`:
|
||||
https://github.com/clearlinux/clr-bundles/blob/master/bundles/sysadmin-basic
|
||||
|
||||
.. _`all Clear Linux bundles`:
|
||||
.. _`all bundles`:
|
||||
https://github.com/clearlinux/clr-bundles/tree/master/bundles
|
||||
|
||||
.. _`wheel group`:
|
||||
|
||||
@@ -3,15 +3,15 @@
|
||||
Modify hostname on |CL-ATTR|
|
||||
############################
|
||||
|
||||
This guide describes how to modify and view the hostname of your
|
||||
This guide describes how to modify and view the hostname of your
|
||||
|CL-ATTR| system.
|
||||
|
||||
By default, |CL| installations have a machine generated name, which is a
|
||||
long string of letters and numbers. The generated name is fine for computers
|
||||
but is not human-friendly. Administrators and users will often want to rename
|
||||
their machines with a name that is easier to remember, type, and search
|
||||
for. Renaming a machine also makes it easier to identify, by including
|
||||
meaningful data in the name. The following examples show human-friendly machine
|
||||
By default, |CL| installations have a machine generated name, which is a
|
||||
long string of letters and numbers. The generated name is fine for computers
|
||||
but is not human-friendly. Administrators and users will often want to rename
|
||||
their machines with a name that is easier to remember, type, and search
|
||||
for. Renaming a machine also makes it easier to identify, by including
|
||||
meaningful data in the name. The following examples show human-friendly machine
|
||||
names:
|
||||
|
||||
* *regression-test*
|
||||
@@ -21,12 +21,12 @@ names:
|
||||
Set your hostname
|
||||
*****************
|
||||
|
||||
|CL| uses the :command:`hostnamectl` command to display and modify the machine
|
||||
name. :command:`hostnamectl` is part of the **os-core** bundle, which provides
|
||||
a basic Linux\* user space and utilities.
|
||||
|CL| uses the :command:`hostnamectl` command to display and modify the machine
|
||||
name. :command:`hostnamectl` is part of the **os-core** bundle, which provides
|
||||
a basic Linux\* user space and utilities.
|
||||
|
||||
This example sets the hostname to *telemetry-test-2-h15*, to identify a
|
||||
|CL| telemetry test machine on the second floor at grid location H15.
|
||||
This example sets the hostname to *telemetry-test-2-h15*, to identify a
|
||||
|CL| telemetry test machine on the second floor at grid location H15.
|
||||
Make sure to reboot after setting a new hostname.
|
||||
|
||||
.. code-block:: bash
|
||||
@@ -36,14 +36,14 @@ Make sure to reboot after setting a new hostname.
|
||||
|
||||
.. note::
|
||||
|
||||
There are three types of hostname: *static*, *transient*, and *pretty*.
|
||||
The most common is the static hostname. Static hostnames must be between
|
||||
two and 63 characters long, must start and end with a letter or number,
|
||||
and may contain letters (case-insensitive), numbers, dashes, or dots.
|
||||
There are three types of hostname: *static*, *transient*, and *pretty*.
|
||||
The most common is the static hostname. Static hostnames must be between
|
||||
two and 63 characters long, must start and end with a letter or number,
|
||||
and may contain letters (case-insensitive), numbers, dashes, or dots.
|
||||
|
||||
If the static hostname exists, it is used to generate the transient hostname,
|
||||
which is maintained by the kernel. The transient hostname can be changed
|
||||
by DHCP or mDNS at runtime.
|
||||
If the static hostname exists, it is used to generate the transient hostname,
|
||||
which is maintained by the kernel. The transient hostname can be changed
|
||||
by DHCP or mDNS at runtime.
|
||||
|
||||
The pretty hostname is a free-form UTF8 name used for presentation to the user.
|
||||
|
||||
@@ -70,5 +70,5 @@ You should see output similar to:
|
||||
Kernel : Linux 4.18.8-632.native
|
||||
Architecture : x86-64
|
||||
|
||||
|
||||
|
||||
**Congratulations!** You successfully modified the hostname of your |CL| system.
|
||||
|
||||
@@ -1,18 +1,18 @@
|
||||
.. _increase-virtual-disk-size:
|
||||
|
||||
Increase virtual disk size of a Clear Linux\* image
|
||||
###################################################
|
||||
Increase virtual disk size of a |CL-ATTR| image
|
||||
###############################################
|
||||
|
||||
|CLOSIA| prebuilt images come in different sizes, ranging from 300 MB to 20
|
||||
|CL-ATTR| prebuilt images come in different sizes, ranging from 300 MB to 20
|
||||
GB. This guide describes how to increase the size of your prebuilt |CL| image
|
||||
if you need more capacity.
|
||||
|
||||
.. contents:: This guide will cover:
|
||||
|
||||
Determine the partition order and sizes of the prebuilt image
|
||||
Determine the partition order and sizes of the prebuilt image
|
||||
*************************************************************
|
||||
|
||||
There are two methods to find the order and sizes of partitions virtual disk
|
||||
There are two methods to find the order and sizes of partitions virtual disk
|
||||
of your prebuilt |CL| image.
|
||||
|
||||
In both examples, the prebuilt Hyper-V image has a disk size of 8.5 GB with /
|
||||
@@ -28,7 +28,7 @@ execute the :command:`lsblk` command as shown below:
|
||||
|
||||
sudo lsblk
|
||||
|
||||
An example output of the :command:`lsblk` command:
|
||||
An example output of the :command:`lsblk` command:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
@@ -36,16 +36,16 @@ An example output of the :command:`lsblk` command:
|
||||
sda 8:0 0 8.5G 0 disk
|
||||
├─sda1 8:1 0 512M 0 part
|
||||
├─sda2 8:2 0 32M 0 part [SWAP]
|
||||
└─sda3 8:3 0 8G 0 part /
|
||||
└─sda3 8:3 0 8G 0 part /
|
||||
|
||||
An example of this can also be seen in Figure 1.
|
||||
|
||||
Checking :file:`config.json` used to build the image
|
||||
Checking :file:`config.json` used to build the image
|
||||
----------------------------------------------------
|
||||
|
||||
The second method to determine partition to check the :file:`config.json`
|
||||
The second method to determine partition to check the :file:`config.json`
|
||||
file used to create prebuilt image, located in the `releases`_ repository.
|
||||
For example, to find the size of the Hyper-V\* image version number 20450,
|
||||
For example, to find the size of the Hyper-V\* image version number 20450,
|
||||
follow these steps:
|
||||
|
||||
#. Go to the `releases`_ repository.
|
||||
@@ -74,17 +74,17 @@ follow these steps:
|
||||
|
||||
Increase virtual disk size
|
||||
**************************
|
||||
Once you have determined the disk and partition to be increased, you are
|
||||
Once you have determined the disk and partition to be increased, you are
|
||||
ready to perform the actual increase of the disk, partition, and filesystem.
|
||||
|
||||
Power off VM and increase virtual disk size:
|
||||
--------------------------------------------
|
||||
|
||||
To increase the virtual disk size for a prebuilt image, perform the steps
|
||||
To increase the virtual disk size for a prebuilt image, perform the steps
|
||||
below:
|
||||
|
||||
#. Shut down your VM if it is running.
|
||||
#. Use the process defined by your hypervisor
|
||||
#. Use the process defined by your hypervisor
|
||||
or cloud provider to increase
|
||||
the virtual disk size of your |CL| VM.
|
||||
#. Power up the VM.
|
||||
@@ -95,7 +95,7 @@ Resize the partition of the virtual disk:
|
||||
|
||||
#. Log in to an account with root privileges.
|
||||
#. Open a terminal emulator.
|
||||
#. Add the |CL| `storage-utils` bundle to install the
|
||||
#. Add the |CL| `storage-utils` bundle to install the
|
||||
:command:`parted` and :command:`resize2fs` tools.
|
||||
|
||||
.. code-block:: bash
|
||||
@@ -121,7 +121,7 @@ Resize the partition of the virtual disk:
|
||||
|
||||
Fix/Ignore?
|
||||
|
||||
#. Enter :command:`resizepart [partition number]` where
|
||||
#. Enter :command:`resizepart [partition number]` where
|
||||
*[partition number]* is the partition number of the partition to modify.
|
||||
#. Enter :command:`yes` when prompted.
|
||||
#. Enter the new `End` size.
|
||||
@@ -142,18 +142,18 @@ Resize the partition of the virtual disk:
|
||||
|
||||
.. figure:: figures/increase-virtual-disk-size-1.png
|
||||
:scale: 100 %
|
||||
:alt: Increase root partition size
|
||||
:alt: Increase root partition size
|
||||
|
||||
Figure 1: Increase root partition size.
|
||||
|
||||
Resize the filesytem
|
||||
Resize the filesytem
|
||||
--------------------
|
||||
|
||||
#. Enter :command:`sudo resize2fs -p /dev/[modified partition name]` where
|
||||
*[modified partition name]* is the partition that was changed in `parted`.
|
||||
|
||||
#. Run the :command:`df -h` to verify that the filesystem size has
|
||||
increased.
|
||||
increased.
|
||||
|
||||
Figure 2 depicts the described steps to resize the partition of the virtual disk from 8.5GB to 20GB.
|
||||
|
||||
@@ -164,6 +164,6 @@ Resize the filesytem
|
||||
Figure 2: Increase root filesystem size after partition has been expanded.
|
||||
|
||||
Congratulations! You have resized the disk, partition, and filesystem. At
|
||||
this point, the increase in disk capacity is usable.
|
||||
this point, the increase in disk capacity is usable.
|
||||
|
||||
.. _releases: https://download.clearlinux.org/releases/
|
||||
@@ -0,0 +1,176 @@
|
||||
.. _kernel-modules:
|
||||
|
||||
Add kernel modules
|
||||
##################
|
||||
|
||||
Kernel modules are additional pieces of software capable of being inserted
|
||||
into the Linux kernel to add functionality, such as a hardware driver.
|
||||
Kernel modules may already be part of the Linux source tree (in-tree) or may
|
||||
come from an external source, such as directly from a vendor (out-of-tree).
|
||||
|
||||
In cases where drivers beyond those enabled by default in |CL-ATTR| are
|
||||
needed it may be necessary to:
|
||||
|
||||
.. contents:: :local:
|
||||
:depth: 1
|
||||
:backlinks: top
|
||||
|
||||
Check if the module is available through |CL|
|
||||
=============================================
|
||||
|
||||
Using an existing module is significantly easier to maintain and retains
|
||||
signature verification of the |CL| kernel. For more information on |CL|
|
||||
security practices, see the :ref:`security` page.
|
||||
|
||||
|CL| comes with many upstream kernel modules available for use. If
|
||||
you require a kernel module, be sure to check whether it is already available in |CL| first.
|
||||
|
||||
You can search for kernel module file names, which end with the :file:`.ko`
|
||||
file extension, using the :command:`swupd search` command. For example:
|
||||
:command:`sudo swupd search ${module_name}.ko`.
|
||||
See :ref:`swupd-search` for more information.
|
||||
|
||||
Request the module be added to |CL|
|
||||
===================================
|
||||
|
||||
If the kernel module you need is already open source
|
||||
(e.g. in the Linux upstream) and likely to be useful to others,
|
||||
consider submitting a request to add or enable in the |CL| kernel.
|
||||
|
||||
Make enhancement requests to the |CL| distribution `on GitHub`_ .
|
||||
|
||||
Build and load an out-of-tree module
|
||||
====================================
|
||||
|
||||
In some cases you may need an out-of-tree kernel module that is not
|
||||
available through |CL|.
|
||||
|
||||
You can build and load out-of-tree kernel modules, however you must:
|
||||
|
||||
* disable secure boot
|
||||
* disable kernel module integrity checking
|
||||
* build the module against new versions of the Linux kernel
|
||||
|
||||
.. note::
|
||||
|
||||
Any time the kernel is upgraded on your Clear Linux system, you will
|
||||
need to rebuild your out-of-tree modules.
|
||||
|
||||
This approach works well for individual development or testing.
|
||||
For a more scalable and customizable approach, consider using the
|
||||
`mixer tool`_ to provide a custom kernel and updates.
|
||||
|
||||
Build kernel module
|
||||
-------------------
|
||||
|
||||
#. From a |CL| system, ensure you are running the *native* kernel.
|
||||
Currently only the native kernel is enabled to build and load
|
||||
out-of-tree modules.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ uname -r
|
||||
4.XX.YY-ZZZZ.native
|
||||
# Ensure *.native* is in the kernel name
|
||||
|
||||
#. Install the `linux-dev` bundle to obtain the kernel headers, which are
|
||||
required for compiling kernel modules.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
sudo swupd bundle-add linux-dev
|
||||
|
||||
#. Follow instructions from the kernel module source code to compile the
|
||||
kernel module.
|
||||
|
||||
|
||||
Load kernel module
|
||||
------------------
|
||||
|
||||
#. Disable Secure Boot in your system's UEFI settings, if you have enabled
|
||||
it. The loading of new out-of-tree modules modifies the signatures Secure
|
||||
Boot relies on for trust.
|
||||
|
||||
|
||||
#. Disable signature checking for the kernel by modifying the kernel boot
|
||||
parameters and reboot the system.
|
||||
|
||||
All kernel modules from |CL| have been signed to enforce kernel security.
|
||||
However, out-of-tree modules break this chain of trust so this mechanism
|
||||
needs to be disabled.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
sudo mkdir -p /etc/kernel/cmdline.d
|
||||
echo "module.sig_unenforce" | sudo tee /etc/kernel/cmdline.d/allow-unsigned-modules.conf
|
||||
|
||||
#. Update the boot manager and reboot the system to implement the changed
|
||||
kernel parameters.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
sudo clr-boot-manager update
|
||||
sudo reboot
|
||||
|
||||
.. note::
|
||||
|
||||
:command:`clr-boot-manager update` does not return any
|
||||
console output if successful.
|
||||
|
||||
|
||||
#. After rebooting, out-of-tree modules can be manually loaded with
|
||||
:command:`insmod`.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
sudo insmod ${path_to_module}
|
||||
|
||||
|
||||
Optional: Use `modprobe` to specify module options and aliases
|
||||
--------------------------------------------------------------
|
||||
|
||||
Use :command:`modprobe` to load a module and set options.
|
||||
|
||||
Because :command:`modprobe` can add or remove more than one module, due to
|
||||
modules having dependencies, a method of specifying what options are
|
||||
to be used with individual modules is useful. This can be done with
|
||||
configuration files under the :file:`/etc/modprobe.d` directory.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
sudo mkdir /etc/modprobe.d
|
||||
|
||||
All files underneath the :file:`/etc/modprobe.d` directory
|
||||
that end with the :file:`.conf` extension specify module options to use when
|
||||
loading. This can also be used to create convenient aliases for modules or
|
||||
they can override the normal loading behavior altogether for those with
|
||||
special requirements.
|
||||
|
||||
You can find more info on module loading in the modprobe.d manual page:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
man modprobe.d
|
||||
|
||||
Optional: Configure kernel modules to load at boot
|
||||
--------------------------------------------------
|
||||
|
||||
Use the :file:`/etc/modules-load.d` configuration directory to
|
||||
specify kernel modules to load automatically at boot.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
sudo mkdir /etc/modules-load.d
|
||||
|
||||
All files underneath the :file:`/etc/modules-load.d` directory
|
||||
that end with the :file:`.conf` extension contain a list of module names
|
||||
of aliases (one per line) to load at boot.
|
||||
|
||||
You can find more info on module loading in the modules-load.d manual page:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
man modules-load.d
|
||||
|
||||
.. _`on GitHub`: https://github.com/clearlinux/distribution
|
||||
.. _`mixer tool`: https://clearlinux.org/features/mixer-tool
|
||||
@@ -0,0 +1,29 @@
|
||||
.. _maintenance:
|
||||
|
||||
Maintenance guide
|
||||
#################
|
||||
|
||||
These guides provide step-by-step instructions for common tasks associated
|
||||
with maintaining |CL-ATTR| after :ref:`installation <get-started>` is
|
||||
completed.
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
developer-workstation
|
||||
swupd-search
|
||||
enable-user-space
|
||||
swupd-guide
|
||||
bulk-provision
|
||||
kernel-modules
|
||||
mixer
|
||||
mixin
|
||||
validate-signatures
|
||||
time
|
||||
hostname
|
||||
increase-virtual-disk-size
|
||||
download-verify-decompress-linux
|
||||
download-verify-decompress-mac
|
||||
download-verify-decompress-windows
|
||||
autospec
|
||||
assign-static-ip
|
||||
@@ -3,7 +3,7 @@
|
||||
Create and add custom bundles to your upstream Clear Linux system
|
||||
#################################################################
|
||||
|
||||
|CLOSIA| offers many curated bundles that you can install on your system to
|
||||
|CL-ATTR| offers many curated bundles that you can install on your system to
|
||||
create your desired capabilities. If the available upstream bundles do not
|
||||
meet your needs, you can create and add your own custom bundles to your
|
||||
system using one of two methods. Note: Upstream refers to the official
|
||||
|
||||
@@ -5,7 +5,7 @@ Use swupd
|
||||
|
||||
*swupd* manages the software update capability of |CL-ATTR|. It can check for
|
||||
valid system updates and, if found, download and install them. It can also
|
||||
perform verification of the system software.
|
||||
perform verification of the system software.
|
||||
|
||||
|CL| uses :ref:`bundles <bundles-about>` as the base abstraction for
|
||||
installing functionality on top of the core operating system. Use the `swupd`
|
||||
@@ -18,7 +18,7 @@ This guide assumes:
|
||||
* The device is able to connect to the release infrastructure
|
||||
http://update.clearlinux.org
|
||||
|
||||
.. contents::
|
||||
.. contents::
|
||||
:local:
|
||||
:depth: 2
|
||||
|
||||
@@ -54,7 +54,7 @@ Current OS version and update server info:
|
||||
Enable or disable automatic updates
|
||||
===================================
|
||||
|
||||
|CL| updates are automatic by default but can be set to occur only
|
||||
|CL| updates are automatic by default but can be set to occur only
|
||||
on demand. To verify your current auto-update setting:
|
||||
|
||||
.. code-block:: bash
|
||||
@@ -105,7 +105,7 @@ to, overwritten, removed, or modified (e.g., permissions).
|
||||
|
||||
sudo swupd verify
|
||||
|
||||
All directories that are watched by `swupd` are verified according to
|
||||
All directories that are watched by `swupd` are verified according to
|
||||
the manifest data and hash mismatches are flagged as follows:
|
||||
|
||||
.. code-block:: console
|
||||
@@ -113,7 +113,7 @@ the manifest data and hash mismatches are flagged as follows:
|
||||
Verifying version 23300
|
||||
Verifying files
|
||||
...0%
|
||||
Hash mismatch for file: /usr/bin/chardetect
|
||||
Hash mismatch for file: /usr/bin/chardetect
|
||||
...
|
||||
...
|
||||
Hash mismatch for file: /usr/lib/python3.6/site-packages/urllib3/util/wait.py
|
||||
@@ -124,7 +124,7 @@ the manifest data and hash mismatches are flagged as follows:
|
||||
|
||||
In this case, python packages that were installed on top of the default
|
||||
install were flagged as mismatched. `swupd` can be directed to ignore
|
||||
or fix issues based on :ref:`command line options <man_swupd>`.
|
||||
or fix issues based on :ref:`command line options <man_swupd>`.
|
||||
|
||||
Fixing hash mismatches
|
||||
======================
|
||||
@@ -138,7 +138,7 @@ ignore files or directories matching `/usr/lib/python`:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
sudo swupd verify --fix --picky --picky-whitelist=/usr/lib/python
|
||||
sudo swupd verify --fix --picky --picky-whitelist=/usr/lib/python
|
||||
|
||||
Bundles
|
||||
*******
|
||||
@@ -150,7 +150,7 @@ You can list all of the bundles currently installed on the system
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
sudo swupd bundle-list --all
|
||||
sudo swupd bundle-list --all
|
||||
|
||||
Finding a bundle containing a binary
|
||||
====================================
|
||||
@@ -160,7 +160,7 @@ binary. Note that it may be present in multiple bundles:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
swupd search -b <binary you want>
|
||||
swupd search -b <binary you want>
|
||||
|
||||
Adding a bundle
|
||||
===============
|
||||
|
||||
@@ -1,54 +1,54 @@
|
||||
.. _swupd-search:
|
||||
.. _swupd-search:
|
||||
|
||||
Use swupd search to find bundles
|
||||
################################
|
||||
|
||||
This document explains how to use `swupd search` to find and add
|
||||
bundles in |CL-ATTR|.
|
||||
bundles in |CL-ATTR|.
|
||||
|
||||
Assumptions
|
||||
***********
|
||||
|
||||
This guide assumes you:
|
||||
This guide assumes you:
|
||||
|
||||
* Possess a basic knowledge of :ref:`swupd <swupd-guide>`
|
||||
* Understand :ref:`how swupd differs <swupd-about>` from
|
||||
other Linux\* distributions
|
||||
* Possess a basic knowledge of :ref:`swupd <swupd-guide>`
|
||||
* Understand :ref:`how swupd differs <swupd-about>` from
|
||||
other Linux\* distributions
|
||||
* May :ref:`mixer` to produce a custom distribution/image
|
||||
|
||||
How do I search for a bundle?
|
||||
How do I search for a bundle?
|
||||
*****************************
|
||||
|
||||
Use `swupd search` to locate the bundle where the application binary exists.
|
||||
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.
|
||||
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 `one bundle`_ to use `Kata Containers`_:
|
||||
In |CL|, you only need to add `one 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?
|
||||
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:
|
||||
#. Enter :command:`swupd search`, followed by 'kata' as the search term:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
sudo swupd search kata
|
||||
|
||||
.. note::
|
||||
.. note::
|
||||
|
||||
`swupd search` downloads |CL| manifest data and searches for
|
||||
matching paths. Enter only one term, or hyphenated term, per
|
||||
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:
|
||||
flag:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
@@ -56,15 +56,15 @@ We need to find *kata* containers in a bundle. How do we search for it?
|
||||
|
||||
.. note::
|
||||
|
||||
`-b` flag, or `--binary`, means: Restrict search to program binary paths. Omit this flag if you want a larger scope of search results.
|
||||
`-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*.
|
||||
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.
|
||||
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`_
|
||||
|
||||
@@ -82,7 +82,7 @@ We need to find *kata* containers in a bundle. How do we search for it?
|
||||
|
||||
.. note::
|
||||
|
||||
If the bundle is already installed, *[installed]* appears in search results. If this doesn't apppear, the bundle needs to be installed.
|
||||
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`:
|
||||
|
||||
@@ -94,11 +94,11 @@ We need to find *kata* containers in a bundle. How do we search for it?
|
||||
|
||||
To add multiple bundles simply add a space followed by the bundle name.
|
||||
|
||||
#. When prompted, enter your password.
|
||||
#. When prompted, enter your password.
|
||||
|
||||
#. Upon successful installation, your console should show similar data:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
Downloading packs...
|
||||
|
||||
@@ -123,11 +123,11 @@ Learn how to:
|
||||
|
||||
* :ref:`kata_migration`
|
||||
|
||||
* :ref:`swupd-guide`
|
||||
* :ref:`swupd-guide`
|
||||
|
||||
* :ref:`Show all available bundles <swupd-guide>`
|
||||
|
||||
* :ref:`Remove bundles<swupd-guide>`
|
||||
* :ref:`Remove bundles<swupd-guide>`
|
||||
|
||||
.. _Kata Containers: https://clearlinux.org/blogs/clear-linux-os-announces-support-kata-containers
|
||||
|
||||
@@ -135,6 +135,6 @@ Learn how to:
|
||||
|
||||
.. _Bundle Definition Files: https://github.com/clearlinux/clr-bundles
|
||||
|
||||
.. _bundles: https://github.com/clearlinux/clr-bundles/tree/master/bundles
|
||||
.. _bundles: https://github.com/clearlinux/clr-bundles/tree/master/bundles
|
||||
|
||||
.. _packages: https://github.com/clearlinux/clr-bundles/blob/master/packages
|
||||
.. _packages: https://github.com/clearlinux/clr-bundles/blob/master/packages
|
||||
|
||||
@@ -3,7 +3,7 @@
|
||||
Set the time
|
||||
############
|
||||
|
||||
|CLOSIA| uses the `systemd-timesyncd.service` daemon to synchronize time.
|
||||
|CL-ATTR| uses the `systemd-timesyncd.service` daemon to synchronize time.
|
||||
|
||||
This guide describes how to reset the time in your |CL| system when
|
||||
the default :abbr:`NTP (Network Time Protocol)` servers cannot be reached.
|
||||
|
||||
@@ -3,7 +3,7 @@
|
||||
Validate signatures
|
||||
###################
|
||||
|
||||
|CLOSIA| offers a way to validate the content of an image or an update. All
|
||||
|CL-ATTR| offers a way to validate the content of an image or an update. All
|
||||
validation of content works by creating and signing a hash. A valid signature
|
||||
creates a chain of trust. A broken chain of trust, seen as an invalid
|
||||
signature, means the content is not valid.
|
||||
@@ -21,7 +21,7 @@ For the outlined steps, the installer image of the latest release of |CL| is
|
||||
used for illustrative purposes. You may use any image of |CL| you choose.
|
||||
|
||||
#. Download the image, the signature of the SHA512 sum of the image, and the
|
||||
Clear Linux certificate used for signing the SHA512 sum.
|
||||
|CL| certificate used for signing the SHA512 sum.
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
@@ -29,16 +29,16 @@ used for illustrative purposes. You may use any image of |CL| you choose.
|
||||
curl -O https://download.clearlinux.org/current/clear-$(curl https://download.clearlinux.org/latest)-installer.img.xz
|
||||
# Signature of SHA512 sum of image
|
||||
curl -O https://download.clearlinux.org/current/clear-$(curl https://download.clearlinux.org/latest)-installer.img.xz-SHA512SUMS.sig
|
||||
# Clear Linux certificate
|
||||
# Certificate
|
||||
curl -O https://download.clearlinux.org/releases/$(curl https://download.clearlinux.org/latest)/clear/ClearLinuxRoot.pem
|
||||
|
||||
#. Generate the SHA256 sum of the Clear Linux certificate.
|
||||
#. Generate the SHA256 sum of the |CL| certificate.
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
sha256sum ClearLinuxRoot.pem
|
||||
|
||||
#. Ensure the generated SHA256 sum of the Clear Linux certificate matches the
|
||||
#. Ensure the generated SHA256 sum of the |CL| certificate matches the
|
||||
following SHA256 sum to verify the integrity of the certificate.
|
||||
|
||||
.. code-block:: console
|
||||
@@ -52,7 +52,7 @@ used for illustrative purposes. You may use any image of |CL| you choose.
|
||||
sha512sum clear-$(curl https://download.clearlinux.org/latest)-installer.img.xz > sha512sum.out
|
||||
|
||||
#. Ensure the signature of the SHA512 sum of the image was created using the
|
||||
Clear Linux certificate. This validates the image is trusted and it has not
|
||||
|CL| certificate. This validates the image is trusted and it has not
|
||||
been modified.
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
@@ -3,8 +3,8 @@
|
||||
Build a custom |CL-ATTR| based Docker container image
|
||||
#######################################################
|
||||
|
||||
The official base |CL-ATTR| container image is published on Docker\* Hub and
|
||||
is updated on a regular basis. This guide contains the steps to build a
|
||||
The official base |CL-ATTR| container image is published on Docker\* Hub and
|
||||
is updated on a regular basis. This guide contains the steps to build a
|
||||
custom container image.
|
||||
|
||||
Prerequisites
|
||||
@@ -111,7 +111,7 @@ Build the base container image
|
||||
.. note::
|
||||
|
||||
* :file:`os-core` provides the minimal Linux namespace.
|
||||
* :file:`os-core-update` provides the basic suite for running the |CLOSIA|
|
||||
* :file:`os-core-update` provides the basic suite for running the |CL|
|
||||
updater.
|
||||
|
||||
#. Optionally, you can include additional bundles with the base image.
|
||||
|
||||
@@ -25,7 +25,7 @@ drivers, sample applications, and tools for fast packet processing.
|
||||
Prerequisites
|
||||
*************
|
||||
|
||||
* Two platforms using |CLOSIA| release `13330`_ or higher.
|
||||
* Two platforms using |CL-ATTR| release `13330`_ or higher.
|
||||
* Both images must include the :file:`kernel-native bundle`.
|
||||
* Install the :file:`network-basic-dev` bundle with the command:
|
||||
|
||||
@@ -130,7 +130,7 @@ NICs to DPDK modules to run DPDK applications.
|
||||
Set hugepages (Platforms A and B)
|
||||
*********************************
|
||||
|
||||
|CLOSIA| supports `hugepages` for the large memory pool allocation used for
|
||||
|CL| supports `hugepages` for the large memory pool allocation used for
|
||||
packet buffers.
|
||||
|
||||
#. Set the number of hugepages.
|
||||
@@ -264,7 +264,7 @@ machines control the NICs on the host.
|
||||
|
||||
sudo curl -O https://download.clearlinux.org/image/start_qemu.sh
|
||||
|
||||
#. Download a bare-metal image of |CLOSIA| and rename it as :file:`clear.img`.
|
||||
#. Download a bare-metal image of |CL| and rename it as :file:`clear.img`.
|
||||
|
||||
#. Look for an Ethernet\* device entry that contains vendor and device ID:
|
||||
|
||||
@@ -283,7 +283,7 @@ machines control the NICs on the host.
|
||||
host.
|
||||
|
||||
|
||||
#. Unbind the NICs from the host to do pass-through with virtual machines. |CLOSIA|
|
||||
#. Unbind the NICs from the host to do pass-through with virtual machines. |CL|
|
||||
supports this action. The commands take the format:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
@@ -1,9 +1,9 @@
|
||||
.. _ipxe-install:
|
||||
|
||||
Install Clear Linux over the network with iPXE
|
||||
################################################
|
||||
Install |CL-ATTR| over the network with iPXE
|
||||
############################################
|
||||
|
||||
This guide describes how to install Clear Linux\* using :abbr:`PXE (Pre-boot
|
||||
This guide describes how to install |CL-ATTR| using :abbr:`PXE (Pre-boot
|
||||
Execution Environment)`.
|
||||
|
||||
PXE is an industry standard that describes client-server interaction with
|
||||
|
||||
@@ -6,7 +6,7 @@ Combine multiple interfaces with network bonding
|
||||
Network bonding combines multiple network interfaces into a single logical
|
||||
interface to provide redundancy and bandwidth aggregation.
|
||||
|
||||
|CLOSIA| includes Linux bonding_ and team_ drivers. This guide describes how
|
||||
|CL-ATTR| includes Linux bonding_ and team_ drivers. This guide describes how
|
||||
to configure systemd to use the `bonding` driver.
|
||||
|
||||
The example demonstrates how to:
|
||||
|
||||
@@ -0,0 +1,16 @@
|
||||
.. _network:
|
||||
|
||||
Network guide
|
||||
#############
|
||||
|
||||
This guide provides step-by-step instructions for common tasks associated with
|
||||
the configuration, administration, and use of networks in the |CL-ATTR|.
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
ipxe-install
|
||||
dpdk
|
||||
network-bonding
|
||||
custom-clear-container
|
||||
vnc
|
||||
@@ -1,10 +1,10 @@
|
||||
.. _vnc:
|
||||
|
||||
Remote-desktop to a Clear Linux host using VNC
|
||||
Remote-desktop to a |CL-ATTR| host using VNC
|
||||
##############################################
|
||||
|
||||
:abbr:`VNC (Virtual Network Computing)` is a client-server GUI-based tool
|
||||
that allows you to connect via remote-desktop to your |CLOSIA| host.
|
||||
that allows you to connect via remote-desktop to your |CL-ATTR| host.
|
||||
|
||||
This guide shows you how to:
|
||||
|
||||
@@ -15,13 +15,13 @@ This guide shows you how to:
|
||||
* Terminate a VNC connection to your |CL| host.
|
||||
* Encrypt VNC traffic through an SSH tunnel.
|
||||
|
||||
Install the VNC server and misc. components on your Clear Linux host
|
||||
********************************************************************
|
||||
Install the VNC server and misc. components on your host
|
||||
********************************************************
|
||||
|
||||
To configure VNC to work on your |CL| host, install these bundles:
|
||||
|
||||
* `desktop-autostart`: Installs :abbr:`GDM (Gnome Desktop Manager)`, sets
|
||||
it to start automatically on boot, and installs TigerVNC Viewer.
|
||||
* `desktop-autostart`: Installs :abbr:`GDM (Gnome Desktop Manager)`, sets
|
||||
it to start automatically on boot, and installs TigerVNC Viewer.
|
||||
* `vnc-server`: Installs the TigerVNC server.
|
||||
|
||||
Follow these steps:
|
||||
@@ -35,16 +35,16 @@ Follow these steps:
|
||||
#. Install the |CL| bundles.
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
|
||||
# swupd bundle-add desktop-autostart vnc-server
|
||||
|
||||
#. Reboot your |CL| host.
|
||||
|
||||
Configure a VNC-server-start method on your Clear Linux host
|
||||
************************************************************
|
||||
Configure a VNC-server-start method on your host
|
||||
************************************************
|
||||
|
||||
There are three methods you can use to configure and start the VNC server on
|
||||
your host:
|
||||
There are three methods you can use to configure and start the VNC server on
|
||||
your |CL| host:
|
||||
|
||||
.. list-table:: Table 1: VNC-server-start Configuration Methods
|
||||
:widths: 10,20,20,20
|
||||
@@ -55,14 +55,14 @@ your host:
|
||||
- `Method 2`: Automatically start a VNC session via a systemd service script
|
||||
- `Method 3`: Create multi-user logins with authentication through GDM
|
||||
* - Description
|
||||
- This is the traditional method where you SSH into the |CL| host, manually
|
||||
start a VNC session to get a display ID, and connect to it by
|
||||
- This is the traditional method where you SSH into the |CL| host, manually
|
||||
start a VNC session to get a display ID, and connect to it by
|
||||
supplying the display ID.
|
||||
- The system administrator sets up a systemd service script for you with
|
||||
a pre-assigned display ID. You make a VNC connection and supply
|
||||
- The system administrator sets up a systemd service script for you with
|
||||
a pre-assigned display ID. You make a VNC connection and supply
|
||||
your pre-assigned display ID.
|
||||
- The system adminstrator configures GDM to accept connection requests.
|
||||
When you make a VNC connection to the |CL| host, you see
|
||||
When you make a VNC connection to the |CL| host, you see
|
||||
the GDM login screen and authenticate as if you are local.
|
||||
* - Who configures VNC settings?
|
||||
- You
|
||||
@@ -82,10 +82,10 @@ your host:
|
||||
- No. Use |CL| account username and password through GDM
|
||||
|
||||
|
||||
Although all three methods can coexist on the same |CL| host, we recommend
|
||||
you pick a method that suits your needs.
|
||||
Although all three methods can coexist on the same |CL| host, we recommend
|
||||
you pick a method that suits your needs.
|
||||
|
||||
For simplicity, the rest of this guide refers to these methods as
|
||||
For simplicity, the rest of this guide refers to these methods as
|
||||
`Method 1`, `Method 2`, and `Method 3`.
|
||||
|
||||
Method 1: Manually start a VNC session
|
||||
@@ -94,18 +94,18 @@ Method 1: Manually start a VNC session
|
||||
You (and each user) must perform these steps to initialize your VNC settings.
|
||||
|
||||
#. Log in.
|
||||
#. Open a terminal emulator.
|
||||
#. Open a terminal emulator.
|
||||
#. Start VNC with the :command:`vncserver` command. Since this is your
|
||||
first time starting VNC, it adds default configuration files and asks you
|
||||
to set a VNC password.
|
||||
|
||||
.. code-block:: console
|
||||
.. code-block:: console
|
||||
|
||||
$ vncserver
|
||||
$ vncserver
|
||||
|
||||
Example output:
|
||||
|
||||
.. code-block:: console
|
||||
.. code-block:: console
|
||||
|
||||
$ vncserver
|
||||
|
||||
@@ -123,15 +123,15 @@ You (and each user) must perform these steps to initialize your VNC settings.
|
||||
Starting applications specified in /home/vnc-user-a/.vnc/xstartup
|
||||
Log file is /home/vnc-user-a/.vnc/clr-linux:2.log
|
||||
|
||||
Upon completion, you can find the default configuration files and the
|
||||
password file hidden in the `.vnc` directory in your home directory.
|
||||
Upon completion, you can find the default configuration files and the
|
||||
password file hidden in the `.vnc` directory in your home directory.
|
||||
|
||||
Also, a VNC session starts and shows a unique display ID, which is the
|
||||
number following the hostname and the colon `:`. In the above example, the display ID is 2. In a later step, you will supply the display ID to
|
||||
your VNC viewer app for connection.
|
||||
Also, a VNC session starts and shows a unique display ID, which is the
|
||||
number following the hostname and the colon `:`. In the above example, the display ID is 2. In a later step, you will supply the display ID to
|
||||
your VNC viewer app for connection.
|
||||
|
||||
#. Kill the active VNC session for the time being with the
|
||||
:command:`vncserver -kill :[display ID]` command. Substitute [display ID]
|
||||
#. Kill the active VNC session for the time being with the
|
||||
:command:`vncserver -kill :[display ID]` command. Substitute [display ID]
|
||||
with your active VNC session display ID. For example:
|
||||
|
||||
.. code-block:: console
|
||||
@@ -140,22 +140,22 @@ You (and each user) must perform these steps to initialize your VNC settings.
|
||||
|
||||
.. note::
|
||||
|
||||
If you do not recall the active session display ID, use the
|
||||
:command:`vncserver -list` command to find it.
|
||||
If you do not recall the active session display ID, use the
|
||||
:command:`vncserver -list` command to find it.
|
||||
|
||||
#. Optional configurations:
|
||||
|
||||
* To customize settings such as screen size, security type, etc.,
|
||||
modify the :file:`$HOME/.vnc/config` file.
|
||||
* To customize the applications to run at startup, modify the
|
||||
:file:`$HOME/.vnc/xstartup` file.
|
||||
* To customize settings such as screen size, security type, etc.,
|
||||
modify the :file:`$HOME/.vnc/config` file.
|
||||
* To customize the applications to run at startup, modify the
|
||||
:file:`$HOME/.vnc/xstartup` file.
|
||||
|
||||
Method 2: Automatically start a VNC session via a systemd service script
|
||||
========================================================================
|
||||
|
||||
To configure VNC for this method, you must have root privileges. You will
|
||||
set up a systemd service file for all intended VNC users with their own
|
||||
preassigned unique display ID.
|
||||
set up a systemd service file for all intended VNC users with their own
|
||||
preassigned unique display ID.
|
||||
|
||||
#. Log in and get root privileges.
|
||||
|
||||
@@ -163,7 +163,7 @@ preassigned unique display ID.
|
||||
|
||||
$ sudo -s
|
||||
|
||||
#. Make sure the user accounts already exist. Use the following command to
|
||||
#. Make sure the user accounts already exist. Use the following command to
|
||||
list all users.
|
||||
|
||||
|
||||
@@ -180,8 +180,8 @@ preassigned unique display ID.
|
||||
#. Create a systemd service script file :file:`vncserver@:[X].service`,
|
||||
where [X] is the display ID, for each user in :file:`/etc/systemd/system`
|
||||
Each user must be assigned a unique display ID. Be sure the correct
|
||||
username is entered in the `User` field. The example below shows user
|
||||
`vnc-user-b` who is assigned the display ID `5`.
|
||||
username is entered in the `User` field. The example below shows user
|
||||
`vnc-user-b` who is assigned the display ID `5`.
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
@@ -203,12 +203,12 @@ preassigned unique display ID.
|
||||
[Install]
|
||||
WantedBy=multi-user.target
|
||||
|
||||
EOF
|
||||
EOF
|
||||
|
||||
#. Have each user log into their account and set a VNC password with
|
||||
#. Have each user log into their account and set a VNC password with
|
||||
the :command:`vncpasswd` command before proceeding to the next step.
|
||||
|
||||
#. Start the VNC service script and set it to start automatically on
|
||||
#. Start the VNC service script and set it to start automatically on
|
||||
boot for each user. Replace the [X] with the display ID.
|
||||
|
||||
.. code-block:: console
|
||||
@@ -217,29 +217,29 @@ preassigned unique display ID.
|
||||
# systemctl start vncserver@:[X].service
|
||||
# systemctl enable vncserver@:[X].service
|
||||
|
||||
#. After starting the services, verify they are running.
|
||||
#. After starting the services, verify they are running.
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
# systemctl | grep vnc
|
||||
|
||||
The example below shows 2 VNC sessions that were successfully started for
|
||||
The example below shows 2 VNC sessions that were successfully started for
|
||||
users `vnc-user-b` with display ID 5 and `vnc-user-c` with display ID 6.
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
# systemctl | grep vnc
|
||||
|
||||
vncserver@:5.services loaded active running VNC Remote Desktop Service for "vnc-user-b" with display ID "5"
|
||||
vncserver@:6.services loaded active running VNC Remote Desktop Service for "vnc-user-c" with display ID "6"
|
||||
system-vncserver.slice loaded active active system-vncserver.slice
|
||||
vncserver@:5.services loaded active running VNC Remote Desktop Service for "vnc-user-b" with display ID "5"
|
||||
vncserver@:6.services loaded active running VNC Remote Desktop Service for "vnc-user-c" with display ID "6"
|
||||
system-vncserver.slice loaded active active system-vncserver.slice
|
||||
|
||||
Method 3: Multi-user logins with authentication through GDM
|
||||
Method 3: Multi-user logins with authentication through GDM
|
||||
===========================================================
|
||||
|
||||
For this method, VNC is configured as a systemd service that listens on port
|
||||
5900 and GDM is configured to accept access requests from VNC. When you
|
||||
make a VNC connection to your |CL| host, you are presented with the GDM login screen and you authenticate as if you are local. You must have root privileges to perform this configuration.
|
||||
For this method, VNC is configured as a systemd service that listens on port
|
||||
5900 and GDM is configured to accept access requests from VNC. When you
|
||||
make a VNC connection to your |CL| host, you are presented with the GDM login screen and you authenticate as if you are local. You must have root privileges to perform this configuration.
|
||||
|
||||
#. Log in and get root privileges.
|
||||
|
||||
@@ -253,7 +253,7 @@ make a VNC connection to your |CL| host, you are presented with the GDM login sc
|
||||
|
||||
# mkdir -p /etc/systemd/system
|
||||
|
||||
#. Create a systemd socket file :file:`xvnc.socket` and add the following:
|
||||
#. Create a systemd socket file :file:`xvnc.socket` and add the following:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
@@ -307,7 +307,7 @@ make a VNC connection to your |CL| host, you are presented with the GDM login sc
|
||||
|
||||
EOF
|
||||
|
||||
#. Start the VNC socket script and set it to start automatically on boot.
|
||||
#. Start the VNC socket script and set it to start automatically on boot.
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
@@ -315,20 +315,20 @@ make a VNC connection to your |CL| host, you are presented with the GDM login sc
|
||||
# systemctl start xvnc.socket
|
||||
# systemctl enable xvnc.socket
|
||||
|
||||
#. After starting the socket, verify it is running.
|
||||
#. After starting the socket, verify it is running.
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
# systemctl | grep vnc
|
||||
|
||||
The example below shows the xvnc.socket is running.
|
||||
The example below shows the xvnc.socket is running.
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
# systemctl | grep vnc
|
||||
|
||||
xvnc.socket loaded active listening XVNC Server on port 5900
|
||||
system-xvnc.slice loaded active active system-xvnc.slice
|
||||
system-xvnc.slice loaded active active system-xvnc.slice
|
||||
|
||||
See the `vncserver` Man page for additional information.
|
||||
|
||||
@@ -336,15 +336,15 @@ Install a VNC viewer app and an SSH client on your client system
|
||||
****************************************************************
|
||||
|
||||
You need a VNC viewer app on your client system to connect to your |CL| host.
|
||||
An SSH client is only needed if you chose to use `Method 1` or you plan to
|
||||
encrypt your VNC traffic, which is discussed later in this guide.
|
||||
An SSH client is only needed if you chose to use `Method 1` or you plan to
|
||||
encrypt your VNC traffic, which is discussed later in this guide.
|
||||
|
||||
Perform the steps below to add these apps to your client system.
|
||||
Perform the steps below to add these apps to your client system.
|
||||
|
||||
Install a VNC viewer app
|
||||
========================
|
||||
|
||||
On |CL|:
|
||||
On |CL|:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
@@ -354,9 +354,9 @@ On Ubuntu, Mint:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
# apt-get install xtightvncviewer
|
||||
# apt-get install xtightvncviewer
|
||||
|
||||
On Fedora:
|
||||
On Fedora:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
@@ -365,38 +365,38 @@ On Fedora:
|
||||
On Windows:
|
||||
|
||||
* Install `RealVNC for Windows`_
|
||||
|
||||
|
||||
On macOS:
|
||||
|
||||
* Install `RealVNC for macOS`_
|
||||
* Install `RealVNC for macOS`_
|
||||
|
||||
Install an SSH client
|
||||
=====================
|
||||
|
||||
* On most Linux distros (Clear Linux, Ubuntu, Mint, Fedora, etc.) and macOS,
|
||||
* On most Linux distros (|CL|, Ubuntu, Mint, Fedora, etc.) and macOS,
|
||||
SSH is built-in so you don't need to install it.
|
||||
* On Windows, you can install `Putty`_.
|
||||
|
||||
Establish a VNC connection to your Clear Linux host
|
||||
***************************************************
|
||||
Establish a VNC connection to your host
|
||||
***************************************
|
||||
|
||||
Depending on the VNC-server-configuration method chosen, use the appropriate VNC connection:
|
||||
Depending on the VNC-server-configuration method chosen, use the appropriate VNC connection:
|
||||
|
||||
If you chose `Method 1`, you must take a few extra steps by
|
||||
using SSH to connect to your |CL| host and then manually launching VNC.
|
||||
If you chose `Method 1`, you must take a few extra steps by
|
||||
using SSH to connect to your |CL| host and then manually launching VNC.
|
||||
|
||||
If you chose `Method 2`, get your preassigned VNC display ID from your
|
||||
system administrator first and then proceed to the
|
||||
system administrator first and then proceed to the
|
||||
:ref:`connect-to-vnc-session` section below.
|
||||
|
||||
If you chose `Method 3`, proceed to the
|
||||
:ref:`connect-to-vnc-session` below.
|
||||
If you chose `Method 3`, proceed to the
|
||||
:ref:`connect-to-vnc-session` below.
|
||||
|
||||
|
||||
SSH into your Clear Linux host and launch VNC
|
||||
=============================================
|
||||
SSH into your host and launch VNC
|
||||
=================================
|
||||
|
||||
#. SSH into your Clear Linux host
|
||||
#. SSH into your |CL| host
|
||||
|
||||
#. On Linux distros and macOS:
|
||||
|
||||
@@ -409,8 +409,8 @@ SSH into your Clear Linux host and launch VNC
|
||||
#. Launch Putty.
|
||||
#. Under the :guilabel:`Category` section, select :guilabel:`Session`.
|
||||
See Figure 1.
|
||||
#. Enter the IP address of your Clear Linux host in the
|
||||
:guilabel:`Host Name (or IP address)` field.
|
||||
#. Enter the IP address of your |CL| host in the
|
||||
:guilabel:`Host Name (or IP address)` field.
|
||||
#. Set the :guilabel:`Connection type` option to :guilabel:`SSH`.
|
||||
#. Click the :guilabel:`Open` button.
|
||||
|
||||
@@ -420,8 +420,8 @@ SSH into your Clear Linux host and launch VNC
|
||||
|
||||
Figure 1: Putty - configure SSH session settings
|
||||
|
||||
#. Log in with your |CL| username and password. Do not use your VNC
|
||||
password.
|
||||
#. Log in with your |CL| username and password. Do not use your VNC
|
||||
password.
|
||||
#. Start a VNC session.
|
||||
|
||||
.. code-block:: console
|
||||
@@ -440,35 +440,35 @@ SSH into your Clear Linux host and launch VNC
|
||||
Log file is /home/vnc-user-c/.vnc/clr-linux:3.log
|
||||
|
||||
#. Take note of the generated display ID because you will input it into
|
||||
the VNC viewer app to establish the connection. The above example shows
|
||||
the display ID is 3.
|
||||
the VNC viewer app to establish the connection. The above example shows
|
||||
the display ID is 3.
|
||||
|
||||
.. note::
|
||||
|
||||
VNC automatically picks a unique display ID unless you specify one.
|
||||
To specify a display ID, enter a unique number that is not already
|
||||
in use after the colon. For example:
|
||||
VNC automatically picks a unique display ID unless you specify one.
|
||||
To specify a display ID, enter a unique number that is not already
|
||||
in use after the colon. For example:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ vncserver :8
|
||||
|
||||
#. You can now end the SSH connection by logging out. This does
|
||||
not terminate your active VNC session.
|
||||
#. You can now end the SSH connection by logging out. This does
|
||||
not terminate your active VNC session.
|
||||
|
||||
.. _connect-to-vnc-session:
|
||||
|
||||
Connect to your VNC session
|
||||
===========================
|
||||
|
||||
For `Method 1` and `Method 2`, you must connect to a specific active session
|
||||
or display ID using one of two options:
|
||||
For `Method 1` and `Method 2`, you must connect to a specific active session
|
||||
or display ID using one of two options:
|
||||
|
||||
* Use a fully-qualified VNC port number, which consists of the default VNC
|
||||
server port (5900) plus the display ID
|
||||
* Use the display ID
|
||||
* Use the display ID
|
||||
|
||||
For example, if the display ID is 3, it can be specified as `5903` or just
|
||||
For example, if the display ID is 3, it can be specified as `5903` or just
|
||||
as `3`. For `Method 3`, VNC does not expect a display ID. Use `5900`. For simplicity, the instructions below use the fully-qualified VNC port
|
||||
number.
|
||||
|
||||
@@ -483,22 +483,22 @@ number.
|
||||
#. Enter your credentials.
|
||||
|
||||
* For `Method 1` and `Method 2`, enter your VNC password. No username is
|
||||
required.
|
||||
required.
|
||||
* For `Method 3`, enter your |CL| account username and password through
|
||||
GDM.
|
||||
|
||||
.. note::
|
||||
|
||||
With `Method 3`, you cannot remotely log into your |CL| host through
|
||||
VNC if you are logged in locally and vice versa.
|
||||
VNC if you are logged in locally and vice versa.
|
||||
|
||||
**On Windows and macOS using `RealVNC` app:**
|
||||
|
||||
#. Start the RealVNC viewer app. See Figure 2.
|
||||
#. Enter the IP address of the Clear Linux host and the fully-qualified
|
||||
#. Enter the IP address of the |CL| host and the fully-qualified
|
||||
VNC port number.
|
||||
|
||||
The following screenshot shows connecting to |CL| host
|
||||
The following screenshot shows connecting to |CL| host
|
||||
192.168.25.54 with a fully-qualified VNC port number 5902.
|
||||
|
||||
.. figure:: figures/vnc/vnc-2.png
|
||||
@@ -512,7 +512,7 @@ number.
|
||||
#. Enter your credentials.
|
||||
|
||||
* For `Method 1` and `Method 2`, enter your VNC password. No username is
|
||||
required.
|
||||
required.
|
||||
* For `Method 3`, enter your |CL| account username and password through
|
||||
GDM.
|
||||
|
||||
@@ -520,8 +520,8 @@ number.
|
||||
|
||||
With `Method 3`, you cannot remotely log into your |CL| host through
|
||||
VNC if you are logged in locally and vice versa.
|
||||
|
||||
`Optional: Configure RealVNC Image Quality`
|
||||
|
||||
`Optional: Configure RealVNC Image Quality`
|
||||
-------------------------------------------
|
||||
|
||||
To increase the RealVNC viewer image quality, manually change the `ColorLevel` value. Follow these steps:
|
||||
@@ -546,16 +546,16 @@ To increase the RealVNC viewer image quality, manually change the `ColorLevel` v
|
||||
|
||||
Figure 4: RealVNC Viewer - change :guilabel:`ColorLevel`
|
||||
|
||||
Terminate a VNC connection to your Clear Linux host
|
||||
***************************************************
|
||||
Terminate a VNC connection to your host
|
||||
***************************************
|
||||
|
||||
For `Method 1` and `Method 2`, once started, a VNC session remains active
|
||||
For `Method 1` and `Method 2`, once started, a VNC session remains active
|
||||
on your |CL| host even if you close your VNC viewer app. If you want to
|
||||
truly terminate an active VNC session, follow these steps:
|
||||
|
||||
#. SSH into your Clear Linux host.
|
||||
#. SSH into your |CL| host.
|
||||
#. Open a terminal emulator.
|
||||
#. Find the active VNC session display ID with the command
|
||||
#. Find the active VNC session display ID with the command
|
||||
:command:`vncserver -list`.
|
||||
|
||||
.. code-block:: console
|
||||
@@ -581,7 +581,7 @@ truly terminate an active VNC session, follow these steps:
|
||||
Encrypt VNC traffic through an SSH tunnel
|
||||
*****************************************
|
||||
|
||||
By default, VNC traffic is not encrypted. Figure 6 shows an example warning
|
||||
By default, VNC traffic is not encrypted. Figure 6 shows an example warning
|
||||
from RealVNC Viewer.
|
||||
|
||||
.. figure:: figures/vnc/vnc-6.png
|
||||
@@ -592,13 +592,13 @@ from RealVNC Viewer.
|
||||
|
||||
To add security, VNC traffic can be routed through an SSH tunnel. This is accomplished by following these steps:
|
||||
|
||||
#. Configure the VNC server to only accept connection from localhost by
|
||||
#. Configure the VNC server to only accept connection from localhost by
|
||||
adding the `-localhost` option.
|
||||
#. Set up an SSH tunnel between your client system and your |CL| host.
|
||||
Your client system will forward traffic from the localhost (the client)
|
||||
destined for a specified fully-qualified VNC port number (on the client)
|
||||
to your |CL| host with the same port number.
|
||||
#. The VNC viewer app on your client system will now connect to localhost,
|
||||
#. Set up an SSH tunnel between your client system and your |CL| host.
|
||||
Your client system will forward traffic from the localhost (the client)
|
||||
destined for a specified fully-qualified VNC port number (on the client)
|
||||
to your |CL| host with the same port number.
|
||||
#. The VNC viewer app on your client system will now connect to localhost,
|
||||
instead of the IP address of your |CL| host.
|
||||
|
||||
Configure VNC to only accept connection from localhost
|
||||
@@ -622,11 +622,11 @@ For `Method 1`:
|
||||
localhost
|
||||
# alwaysshared
|
||||
|
||||
#. If an active session exists, kill it, and then restart it.
|
||||
#. If an active session exists, kill it, and then restart it.
|
||||
|
||||
For `Method 2`:
|
||||
|
||||
#. Edit the systemd service script :file:`vncserver@:[X].service` located in
|
||||
#. Edit the systemd service script :file:`vncserver@:[X].service` located in
|
||||
:file:`/etc/systemd/system` and add `-localhost` to the `ExecStart`
|
||||
line. The example below uses vncserver@:5.service:
|
||||
|
||||
@@ -657,12 +657,12 @@ For `Method 2`:
|
||||
|
||||
For `Method 3`:
|
||||
|
||||
#. No change is needed to the :file:`xvnc@service` script.
|
||||
#. No change is needed to the :file:`xvnc@service` script.
|
||||
|
||||
After you have restarted your VNC session, you can verify that it only
|
||||
accepts connections from localhost by using the :command:`netstat`
|
||||
command like this:
|
||||
|
||||
command like this:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ netstat -plant
|
||||
@@ -673,7 +673,7 @@ For `Method 3`:
|
||||
command.
|
||||
|
||||
Figure 7 shows two VNC sessions (5901 and 5905) accepting connections from
|
||||
any host as specified by the `0.0.0.0`'s. This is before the `-localhost` option was used.
|
||||
any host as specified by the `0.0.0.0`'s. This is before the `-localhost` option was used.
|
||||
|
||||
.. figure:: figures/vnc/vnc-7.png
|
||||
:scale: 100 %
|
||||
@@ -681,8 +681,8 @@ any host as specified by the `0.0.0.0`'s. This is before the `-localhost` optio
|
||||
|
||||
Figure 7: VNC sessions (5901 and 5905) accepting connections from any host
|
||||
|
||||
Figure 8 shows two VNC sessions (5901 and 5905) only accepting connections from localhost as specified by `127.0.0.1`'s. This is after the `-localhost` option was used.
|
||||
|
||||
Figure 8 shows two VNC sessions (5901 and 5905) only accepting connections from localhost as specified by `127.0.0.1`'s. This is after the `-localhost` option was used.
|
||||
|
||||
.. figure:: figures/vnc/vnc-8.png
|
||||
:scale: 100 %
|
||||
:alt: VNC session only accepting connection from localhost
|
||||
@@ -698,23 +698,23 @@ Set up an SSH tunnel from your client system to your |CL| host
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ ssh -L [client port number]:localhost:[fully-qualified VNC port number] \
|
||||
$ ssh -L [client port number]:localhost:[fully-qualified VNC port number] \
|
||||
-N -f -l [username] [clear-linux-host-ip-address]
|
||||
|
||||
#. Enter your |CL| account password (not your VNC password).
|
||||
|
||||
.. note::
|
||||
.. note::
|
||||
|
||||
* `-L` specifies that [client port number] on the localhost (on the
|
||||
client side) is forwarded to [fully-qualified VNC port number]
|
||||
client side) is forwarded to [fully-qualified VNC port number]
|
||||
(on the server side).
|
||||
* Replace `[client port number]` with an available client port number
|
||||
(for example: 1234). For simplicity, you can make the
|
||||
* Replace `[client port number]` with an available client port number
|
||||
(for example: 1234). For simplicity, you can make the
|
||||
`[client port number]` the same as the `[fully-qualified VNC port number]`.
|
||||
* Replace `[fully-qualified VNC port number]` with 5900 (default VNC
|
||||
port) plus the display ID. For example, if the display ID is 2,
|
||||
the fully-qualified VNC port number is is 5902.
|
||||
* `-N` tells SSH to only forward ports and not execute a remote
|
||||
* Replace `[fully-qualified VNC port number]` with 5900 (default VNC
|
||||
port) plus the display ID. For example, if the display ID is 2,
|
||||
the fully-qualified VNC port number is is 5902.
|
||||
* `-N` tells SSH to only forward ports and not execute a remote
|
||||
command.
|
||||
* `-f` tells SSH to go into the background before command execution.
|
||||
* `-l` specifies the username to log in as.
|
||||
@@ -722,28 +722,28 @@ Set up an SSH tunnel from your client system to your |CL| host
|
||||
**On Windows:**
|
||||
|
||||
#. Launch Putty.
|
||||
#. Specify the |CL| VNC host to connect to.
|
||||
|
||||
#. Under the :guilabel:`Category` section, select :guilabel:`Session`.
|
||||
#. Specify the |CL| VNC host to connect to.
|
||||
|
||||
#. Under the :guilabel:`Category` section, select :guilabel:`Session`.
|
||||
See Figure 1.
|
||||
#. Enter the IP address of your Clear Linux host in the
|
||||
:guilabel:`Host Name (or IP address)` field.
|
||||
#. Enter the IP address of your |CL| host in the
|
||||
:guilabel:`Host Name (or IP address)` field.
|
||||
#. Set the :guilabel:`Connection type` option to :guilabel:`SSH`.
|
||||
|
||||
#. Configure the SSH tunnel. See Figure 9 for an example.
|
||||
|
||||
#. Under the :guilabel:`Category` section, go to
|
||||
#. Under the :guilabel:`Category` section, go to
|
||||
:guilabel:`Connection` > :guilabel:`SSH` > :guilabel:`Tunnels`.
|
||||
|
||||
#. In the :guilabel:`Source port` field, enter an available client
|
||||
|
||||
#. In the :guilabel:`Source port` field, enter an available client
|
||||
port number (for example: 1234). For simplicity, you can make the
|
||||
`Source port` the same as the fully-qualified VNC port number.
|
||||
|
||||
#. In the :guilabel:`Destination` field, enter
|
||||
|
||||
#. In the :guilabel:`Destination` field, enter
|
||||
`localhost:` plus the fully-qualified VNC port number.
|
||||
|
||||
#. Click the :guilabel:`Add` button.
|
||||
|
||||
|
||||
.. figure:: figures/vnc/vnc-9.png
|
||||
:scale: 100 %
|
||||
:alt: Putty - configure SSH tunnel
|
||||
@@ -756,7 +756,7 @@ Set up an SSH tunnel from your client system to your |CL| host
|
||||
Connect to a VNC session through an SSH tunnel
|
||||
==============================================
|
||||
|
||||
After you have set up an SSH tunnel, follow these instructions to connect to
|
||||
After you have set up an SSH tunnel, follow these instructions to connect to
|
||||
your VNC session.
|
||||
|
||||
**On Linux distros:**
|
||||
@@ -776,13 +776,13 @@ your VNC session.
|
||||
.. figure:: figures/vnc/vnc-10.png
|
||||
:scale: 100 %
|
||||
:alt: RealVNC viewer app connecting to localhost:1234
|
||||
|
||||
|
||||
Figure 10: RealVNC viewer app connecting to `localhost:1234`
|
||||
|
||||
.. note::
|
||||
.. note::
|
||||
|
||||
RealVNC will still warn that the connection is not encrypted even
|
||||
though its traffic is going through the SSH tunnel. You can ignore
|
||||
RealVNC will still warn that the connection is not encrypted even
|
||||
though its traffic is going through the SSH tunnel. You can ignore
|
||||
this warning.
|
||||
|
||||
.. _RealVNC for Windows: https://www.realvnc.com/en/connect/download/viewer/windows/
|
||||
|
||||
@@ -3,13 +3,12 @@
|
||||
Available bundles
|
||||
#################
|
||||
|
||||
This document provides a current list of `available bundles`_ as
|
||||
of ``12 September 2018``.
|
||||
This document provides a current list of `available bundles`_. To learn more about how |CL-ATTR| uses bundles for software deployment, visit :ref:`bundles-about`.
|
||||
|
||||
Bundle list
|
||||
===========
|
||||
|
||||
.. raw:: html
|
||||
:file: bundles.html
|
||||
:file: bundles.html.txt
|
||||
|
||||
.. _available bundles: https://github.com/clearlinux/clr-bundles
|
||||
|
||||
@@ -169,7 +169,7 @@ an the official Docker image for nginx, an open source reverse proxy server.
|
||||
accessible from the |CL| host on port 8080
|
||||
|
||||
#. You can access the Welcome to Nginx! splash page running in the container
|
||||
by browsing to http://127.0.0.1:8080 or by running this :command:`curl`
|
||||
by browsing to \http://127.0.0.1:8080 or by running this :command:`curl`
|
||||
command from your |CL| machine:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
@@ -5,14 +5,14 @@ Enable AWS Greengrass* and OpenVINO™ on |CL-ATTR|
|
||||
|
||||
Hardware accelerated Function-as-a-Service (FaaS) enables cloud developers
|
||||
to deploy inference functionalities [1] on Intel® IoT edge devices with
|
||||
accelerators (Integrated GPU, Intel® FPGA, and Intel® Movidius™). These
|
||||
accelerators (CPU, Integrated GPU, Intel® FPGA, and Intel® Movidius™). These
|
||||
functions provide a great developer experience and seamless migration of
|
||||
visual analytics from cloud to edge in a secure manner using a containerized
|
||||
environment. Hardware-accelerated FaaS provides the best-in-class
|
||||
performance by accessing optimized deep learning libraries on Intel® IoT
|
||||
edge devices with accelerators.
|
||||
|
||||
This tutorial shows how to:
|
||||
This tutorial will demonstrate how to:
|
||||
|
||||
* Set up the Intel® edge device with |CL-ATTR|
|
||||
* Install the OpenVINO™ and AWS Greengrass* software stacks
|
||||
@@ -31,13 +31,13 @@ The AWS Greengrass samples are located at the `Edge-Analytics-FaaS`_.
|
||||
|
||||
We provide the following AWS Greengrass samples:
|
||||
|
||||
* :file:`greengrass_classification_sample.py`
|
||||
* `greengrass_classification_sample.py`_
|
||||
|
||||
This AWS Greengrass sample classifies a video stream using classification
|
||||
networks such as AlexNet and GoogLeNet and publishes top-10 results on AWS*
|
||||
IoT Cloud every second.
|
||||
|
||||
* :file:`greengrass_object_detection_sample_ssd.py`
|
||||
* `greengrass_object_detection_sample_ssd.py`_
|
||||
|
||||
This AWS Greengrass sample detects objects in a video stream and
|
||||
classifies them using single-shot multi-box detection (SSD) networks such
|
||||
@@ -45,61 +45,6 @@ We provide the following AWS Greengrass samples:
|
||||
detection outputs such as class label, class confidence, and bounding box
|
||||
coordinates on AWS IoT Cloud every second.
|
||||
|
||||
Converting Deep Learning Models
|
||||
*******************************
|
||||
|
||||
Sample Models
|
||||
=============
|
||||
|
||||
For classification, `download the BVLC Alexnet model`_ as an example.
|
||||
Any custom pre-trained classification models can be used with the
|
||||
classification sample.
|
||||
|
||||
For object detection, the sample models optimized for Intel® edge platforms
|
||||
are present at :file:`/usr/share/openvino/models`. These models are provided
|
||||
as an example; however, any custom pre-trained SSD models can be used with
|
||||
the object detection sample.
|
||||
|
||||
Running Model Optimizer
|
||||
=======================
|
||||
|
||||
Follow these instructions for `converting deep learning models to Intermediate Representation using Model Optimizer`_. For example, use the
|
||||
following commands.
|
||||
|
||||
For classification using BVLC Alexnet model:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
python3 mo.py --framework caffe --input_model <
|
||||
model_location>/bvlc_alexnet.caffemodel --input_proto <
|
||||
model_location>/deploy.prototxt --data_type <data_type> --output_dir <
|
||||
output_dir> --input_shape [1,3,227,227]
|
||||
|
||||
For object detection using SqueezeNetSSD-5Class model:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
python3 mo.py --framework caffe --input_model
|
||||
SqueezeNetSSD-5Class.caffemodel --input_proto
|
||||
SqueezeNetSSD-5Class.prototxt
|
||||
--data_type <data_type> --output_dir <output_dir>
|
||||
|
||||
In these examples:
|
||||
|
||||
* ``<model_location>`` is :file:`/usr/share/openvino/models`
|
||||
|
||||
* ``<data_type>`` is FP32 or FP16, depending on target device.
|
||||
|
||||
* ``<output_dir>`` is the directory where the user wants to store the
|
||||
Intermediate Representation (IR). IR contains .xml format corresponding
|
||||
to the network structure and .bin format corresponding to weights. This
|
||||
.xml file should be passed to <PARAM_MODEL_XML>.
|
||||
|
||||
* In the BVLC Alexnet model, the prototxt defines the input shape with
|
||||
batch size 10 by default. In order to use any other batch size, the
|
||||
entire input shape needs to be provided as an argument to the model
|
||||
optimizer. For example, to use batch size 1, you can provide
|
||||
“--input_shape [1,3,227,227]”.
|
||||
|
||||
Installing |CL| on the edge device
|
||||
**********************************
|
||||
@@ -129,13 +74,6 @@ services to use (see Greengrass user below).
|
||||
|
||||
usermod -G wheel -a <userid>
|
||||
|
||||
#. Create the user and group account for the Greengrass daemon:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
useradd ggc_user
|
||||
groupadd ggc_group
|
||||
|
||||
#. Create a :file:`/etc/fstab` file.
|
||||
|
||||
.. code-block:: bash
|
||||
@@ -151,8 +89,8 @@ services to use (see Greengrass user below).
|
||||
Add required bundles
|
||||
====================
|
||||
|
||||
Use the ``swupd`` software updater utility to add the following bundles to
|
||||
enable the OpenVINO software stack:
|
||||
Use the ``swupd`` software updater utility to add the prerequisite bundles
|
||||
for the OpenVINO software stack:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
@@ -165,6 +103,67 @@ enable the OpenVINO software stack:
|
||||
The ``computer-vision-basic`` bundle will install the OpenVINO software,
|
||||
along with the edge device models needed.
|
||||
|
||||
Converting Deep Learning Models
|
||||
===============================
|
||||
|
||||
Locate Sample Models
|
||||
--------------------
|
||||
|
||||
There are two types of provided models that can be used in conjunction with AWS Greengrass
|
||||
for this tutorial: classification or object detection.
|
||||
|
||||
To complete this tutorial using an image classification model,
|
||||
download the BVLC Alexnet model files `bvlc_alexnet.caffemodel`_ and `deploy.prototxt`_
|
||||
to the default model_location at :file:`/usr/share/openvino/models`.
|
||||
Any custom pre-trained classification models can be used with the
|
||||
classification sample.
|
||||
|
||||
For object detection, the sample models optimized for Intel® edge platforms
|
||||
are included with the computer-vision-basic bundle installation at :file:`/usr/share/openvino/models`.
|
||||
These models are provided as an example; however, you may also use a custom SSD model
|
||||
with the Greengrass object detection sample.
|
||||
|
||||
Running Model Optimizer
|
||||
-----------------------
|
||||
|
||||
Follow these instructions for `converting deep learning models to Intermediate Representation using Model Optimizer`_. To optimize either of the afformentioned sample models, run one of the following commands.
|
||||
|
||||
For classification using BVLC Alexnet model:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
python3 mo.py --framework caffe --input_model
|
||||
<model_location>/bvlc_alexnet.caffemodel --input_proto
|
||||
<model_location>/deploy.prototxt --data_type <data_type> --output_dir
|
||||
<output_dir> --input_shape [1,3,227,227]
|
||||
|
||||
For object detection using SqueezeNetSSD-5Class model:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
python3 mo.py --framework caffe --input_model
|
||||
<model_location>/'SqueezeNet 5-Class detection'/SqueezeNetSSD-5Class.caffemodel
|
||||
--input_proto <model_location>/'SqueezeNet 5-Class detection'/SqueezeNetSSD-5Class.prototxt
|
||||
--data_type <data_type> --output_dir <output_dir>
|
||||
|
||||
In these examples:
|
||||
|
||||
* ``<model_location>`` is :file:`/usr/share/openvino/models`
|
||||
|
||||
* ``<data_type>`` is FP32 or FP16, depending on target device.
|
||||
|
||||
* ``<output_dir>`` is the directory where the user wants to store the
|
||||
Intermediate Representation (IR). IR contains .xml format corresponding
|
||||
to the network structure and .bin format corresponding to weights. This
|
||||
.xml file should be passed to <PARAM_MODEL_XML>.
|
||||
|
||||
* In the BVLC Alexnet model, the prototxt defines the input shape with
|
||||
batch size 10 by default. In order to use any other batch size, the
|
||||
entire input shape needs to be provided as an argument to the model
|
||||
optimizer. For example, to use batch size 1, you can provide
|
||||
“--input_shape [1,3,227,227]”.
|
||||
|
||||
|
||||
Configuring an AWS Greengrass group
|
||||
===================================
|
||||
|
||||
@@ -176,7 +175,9 @@ cloud and edge.
|
||||
`AWS Greengrass developer guide`_
|
||||
|
||||
#. To install and configure AWS Greengrass core on edge platform, follow
|
||||
the instructions at `Start AWS Greengrass on the Core Device`_.
|
||||
the instructions at `Start AWS Greengrass on the Core Device`_. In
|
||||
step 8(b), download the x86_64 Ubuntu configuration of the AWS Greengrass
|
||||
core software.
|
||||
|
||||
.. note::
|
||||
|
||||
@@ -184,43 +185,40 @@ cloud and edge.
|
||||
of Module 1 of the `AWS Greengrass developer guide`_ because this is
|
||||
enabled already in |CL|.
|
||||
|
||||
Creating and Packaging Lambda Functions
|
||||
=======================================
|
||||
|
||||
#. Complete the tutorial at `Configure AWS Greengrass on AWS IoT`_ .
|
||||
|
||||
.. note::
|
||||
|
||||
This creates the tarball needed to create the AWS Greengrass
|
||||
environment on the edge device.
|
||||
|
||||
#. Assure to download both the security resources and the AWS Greengrass
|
||||
#. Be sure to download both the security resources and the AWS Greengrass
|
||||
core software.
|
||||
|
||||
.. note::
|
||||
|
||||
Security certificates are linked to your AWS* account.
|
||||
|
||||
#. Replace greengrassHelloWorld.py with Greengrass samples:
|
||||
|
||||
* greengrass_classification_sample.py
|
||||
Creating and Packaging Lambda Functions
|
||||
=======================================
|
||||
|
||||
* greengrass_object_detection_sample_ssd.py
|
||||
#. Complete steps 1-4 of the tutorial at `Create and Package Lambda Function`_ .
|
||||
|
||||
#. Zip these files with extracted Greengrass SDK folders from the previous
|
||||
.. note::
|
||||
|
||||
This creates the tarball needed to create the AWS Greengrass
|
||||
environment on the edge device.
|
||||
|
||||
|
||||
#. In step 5, replace greengrassHelloWorld.py with the classification or object detection
|
||||
Greengrass sample from `Edge-Analytics-Faas`_:
|
||||
|
||||
* Classification: `greengrass_classification_sample.py`_
|
||||
|
||||
* Object Detection: `greengrass_object_detection_sample_ssd.py`_
|
||||
|
||||
#. Zip the selected Greengrass sample with the extracted Greengrass SDK folders from the previous
|
||||
step into :file:`greengrass_sample_python_lambda.zip`.
|
||||
|
||||
The zip should contain:
|
||||
|
||||
* greengrasssdk
|
||||
|
||||
* greengrass sample
|
||||
|
||||
For the sample, choose one of these:
|
||||
|
||||
- greengrass_classification_sample.py
|
||||
|
||||
- greengrass_object_detection_sample_ssd.py
|
||||
* greengrass classification or object detection sample
|
||||
|
||||
For example:
|
||||
|
||||
@@ -229,11 +227,11 @@ Creating and Packaging Lambda Functions
|
||||
zip -r greengrass_lambda.zip greengrasssdk
|
||||
greengrass_object_detection_sample_ssd.py
|
||||
|
||||
#. Follow steps 6-11 to `complete creating lambdas`_.
|
||||
#. Return to the AWS Documentation and follow steps 6-11 to `complete creating lambdas`_.
|
||||
|
||||
.. note::
|
||||
|
||||
In the AWS documentation, step 9(a), while uploading the zip file,
|
||||
In step 9(a) of the AWS documentation, while uploading the zip file,
|
||||
make sure to name the handler as below depending on the AWS Greengrass
|
||||
sample you are using:
|
||||
|
||||
@@ -266,12 +264,14 @@ configuring the lambda function for AWS Greengrass.
|
||||
- Value
|
||||
* - PARAM_MODEL_XML
|
||||
- <MODEL_DIR>/<IR.xml>, where <MODEL_DIR> is user specified and
|
||||
contains IR.xml, the Intermediate Representation file from Intel® Model Optimizer
|
||||
contains IR.xml, the Intermediate Representation file from Intel® Model Optimizer.
|
||||
For this tutorial, <MODEL_DIR> should be set to '/usr/share/openvino/models'
|
||||
or one of its subdirectories.
|
||||
* - PARAM_INPUT_SOURCE
|
||||
- <DATA_DIR>/input.webm to be specified by user. Holds both input and
|
||||
output data. For webcam, set PARAM_INPUT_SOURCE to ‘/dev/video0’
|
||||
* - PARAM_DEVICE
|
||||
- For CPU, specify "CPU"
|
||||
- "CPU"
|
||||
* - PARAM_CPU_EXTENSION_PATH
|
||||
- /usr/lib64/libcpu_extension.so
|
||||
* - PARAM_OUTPUT_DIRECTORY
|
||||
@@ -377,7 +377,13 @@ References
|
||||
|
||||
.. _Edge-Analytics-FaaS: https://github.com/intel/Edge-Analytics-FaaS/tree/master/AWS%20Greengrass
|
||||
|
||||
.. _download the BVLC Alexnet model: https://github.com/BVLC/caffe/tree/master/models/bvlc_alexnet
|
||||
.. _bvlc_alexnet.caffemodel: http://dl.caffe.berkeleyvision.org/bvlc_alexnet.caffemodel
|
||||
|
||||
.. _deploy.prototxt: https://github.com/BVLC/caffe/blob/master/models/bvlc_alexnet/deploy.prototxt
|
||||
|
||||
.. _greengrass_classification_sample.py: https://github.com/intel/Edge-Analytics-FaaS/blob/master/AWS%20Greengrass/greengrass_classification_sample.py
|
||||
|
||||
.. _greengrass_object_detection_sample_ssd.py: https://github.com/intel/Edge-Analytics-FaaS/blob/master/AWS%20Greengrass/greengrass_object_detection_sample_ssd.py
|
||||
|
||||
.. _converting deep learning models to Intermediate Representation using Model Optimizer: https://software.intel.com/en-us/articles/OpenVINO-ModelOptimizer
|
||||
|
||||
@@ -401,4 +407,4 @@ References
|
||||
|
||||
.. _this link to add local resources and access privileges: https://docs.aws.amazon.com/greengrass/latest/developerguide/access-local-resources.html
|
||||
|
||||
.. _Configure AWS Greengrass on AWS IoT: https://docs.aws.amazon.com/greengrass/latest/developerguide/gg-config.html
|
||||
.. _Create and Package Lambda Function: https://docs.aws.amazon.com/greengrass/latest/developerguide/create-lambda.html
|
||||
|
||||
@@ -55,7 +55,7 @@ Apache software bundle on |CL|.
|
||||
sudo systemctl start httpd.service
|
||||
|
||||
#. To verify that the Apache server application is running, open a web
|
||||
browser and navigate to: http://localhost.
|
||||
browser and navigate to: \http://localhost.
|
||||
|
||||
If the service is running, a confirmation message will appear, similar to the
|
||||
message shown in figure 1.
|
||||
@@ -157,7 +157,7 @@ default values, and define a custom DocumentRoot for your web server.
|
||||
sudo systemctl stop httpd.service
|
||||
sudo systemctl start httpd.service
|
||||
|
||||
#. Go to http://localhost to view the new screen. You should see your updated
|
||||
#. Go to \http://localhost to view the new screen. You should see your updated
|
||||
default message from step 5.
|
||||
|
||||
#. Change the configuration back to the default :file:`/var/www/html`
|
||||
@@ -175,7 +175,7 @@ default values, and define a custom DocumentRoot for your web server.
|
||||
sudo systemctl stop httpd.service
|
||||
sudo systemctl start httpd.service
|
||||
|
||||
#. Go to http://localhost and verify that you can see the default screen
|
||||
#. Go to \http://localhost and verify that you can see the default screen
|
||||
again.
|
||||
|
||||
#. Optionally, remove the /var/www/tutorial directory you previously created.
|
||||
@@ -221,7 +221,7 @@ functionality to your web server, install PHP on your system.
|
||||
|
||||
<?PHP phpinfo() ?>
|
||||
|
||||
#. Go to http://localhost/phpinfo.php.
|
||||
#. Go to \http://localhost/phpinfo.php.
|
||||
|
||||
#. Verify that the PHP information screen appears, similar to figure 2:
|
||||
|
||||
@@ -409,7 +409,7 @@ You can use the phpMyAdmin web-based tool to manage your databases. Follow the
|
||||
steps below for setting up a database called "WordPress".
|
||||
|
||||
#. Verify that a successful installation of all LAMP server components by
|
||||
going to http://localhost/phpMyAdmin. See figure 3.
|
||||
going to \http://localhost/phpMyAdmin. See figure 3.
|
||||
|
||||
#. Log in with your root userid and the password you set up when you ran the
|
||||
:ref:`mysql_secure_installation command <set-password>`. Enter your
|
||||
|
||||
@@ -42,7 +42,7 @@ Download WordPress and manage directories
|
||||
=========================================
|
||||
|
||||
For this tutorial, you will create a WordPress blog that can be accessed at:
|
||||
http://<your_website>/blog.
|
||||
\http://<your_website>/blog.
|
||||
|
||||
To accomplish this setup, you must add WordPress components to the :file:`/var/www/html/blog`
|
||||
directory.
|
||||
@@ -87,7 +87,7 @@ Recall that you created a database and user when you installed phpMyAdmin when y
|
||||
set up a |CL| based :ref:`web server <web-server-install>`. Next, you must
|
||||
connect WordPress to the database and install WordPress.
|
||||
|
||||
To continue with the setup, go to: http://<your_website>/blog/wp-admin/install.php.
|
||||
To continue with the setup, go to: \http://<your_website>/blog/wp-admin/install.php.
|
||||
The WordPress language option screen appears, as shown in figure 1.
|
||||
|
||||
#. Select :guilabel:`English` and click :guilabel:`Continue`.
|
||||
@@ -177,7 +177,7 @@ Figure 7 shows the WordPress dashboard after a successful login:
|
||||
You are ready to go!
|
||||
|
||||
To check out your blog as it is seen by the outside world, enter:
|
||||
http://<your_website>/blog on your browser. Figure 8 shows the result:
|
||||
\http://<your_website>/blog on your browser. Figure 8 shows the result:
|
||||
|
||||
.. figure:: figures/wp-install-8.png
|
||||
:alt: WordPress blog
|
||||
|
||||
@@ -7,6 +7,7 @@ Clear Linux - Documentation
|
||||
:maxdepth: 1
|
||||
|
||||
clear-linux/clear-linux
|
||||
sitemap
|
||||
|
||||
License and disclaimers
|
||||
=======================
|
||||
|
||||
@@ -0,0 +1,13 @@
|
||||
.. _clear-linux-sitemap:
|
||||
|
||||
Clear Linux - Documentation Sitemap
|
||||
###################################
|
||||
|
||||
.. toctree::
|
||||
:includehidden:
|
||||
|
||||
clear-linux/get-started/get-started
|
||||
clear-linux/concepts/concepts
|
||||
clear-linux/guides/guides
|
||||
clear-linux/tutorials/tutorials
|
||||
clear-linux/reference/reference
|
||||
@@ -1,12 +1,10 @@
|
||||
.. |CL| replace:: Clear Linux OS
|
||||
|
||||
.. |CLOSIA| replace:: Clear Linux* OS
|
||||
|
||||
.. |CL-ATTR| replace:: Clear Linux* OS
|
||||
|
||||
.. |CL-PRJ| replace:: Clear Linux* project
|
||||
|
||||
.. |CC| replace:: Clear Containers
|
||||
|
||||
.. |CAUTION-BACKUP-USB| replace::
|
||||
.. |CAUTION-BACKUP-USB| replace::
|
||||
Burning an image formats the USB drive, thus destroying all existing content. Backup your data before proceeding.
|
||||
|
||||