mirror of
https://github.com/clearlinux/clear-linux-documentation.git
synced 2026-08-20 14:17:36 +00:00
Merge branch 'master' of github.com:clearlinux/clear-linux-documentation into rtd-theme
This commit is contained in:
Kevin Putnam
@@ -102,6 +102,5 @@ Related topics
|
||||
|
||||
* :ref:`autospec`
|
||||
* :ref:`mixer`
|
||||
* :ref:`mixin`
|
||||
|
||||
.. _autospec readme: https://github.com/clearlinux/autospec
|
||||
|
||||
@@ -11,10 +11,8 @@ needs.
|
||||
However, if you need additional customization or content, |CL| provides the
|
||||
mixer tool. Depending on your needs, the mixer tool allows you to:
|
||||
|
||||
1. :ref:`create-mix` to create a distinct derivative of the |CL| that
|
||||
* :ref:`create-mix` to create a distinct derivative of the |CL| that
|
||||
contains your custom software.
|
||||
2. :ref:`create-mixin` to add custom bundles but also keep updating the OS
|
||||
from upstream.
|
||||
|
||||
.. _create-mix:
|
||||
|
||||
@@ -43,31 +41,6 @@ act as your own OSV. There is a greater level of responsibility, requiring
|
||||
more infrastructure and processes to adopt. However, with this approach, you
|
||||
have a higher degree of control and customization of your custom |CL|.
|
||||
|
||||
|
||||
.. _create-mixin:
|
||||
|
||||
Create a mixin
|
||||
==============
|
||||
|
||||
The second option is to use the :command:`mixin` tool, a light wrapper for
|
||||
mixer, to create custom bundles and sideload them into your upstream version
|
||||
of |CL|. A mixin is useful when you need to add custom or 3rd
|
||||
party content but want to keep on the upstream update cycle, as shown in
|
||||
Figure 2. You can also create new bundles using upstream packages.
|
||||
|
||||
.. figure:: figures/mixer-about-2.png
|
||||
:scale: 75%
|
||||
:alt: Creating a custom mix.
|
||||
|
||||
Figure 2: With a mixin you can add custom bundles, but stay on upstream.
|
||||
|
||||
Mixin is primarily intended for end users. It is easier to adopt as it does
|
||||
not require breaking from upstream or acting as an OSV. With mixin
|
||||
|
||||
* You are responsible for maintaining and testing your custom bundle(s).
|
||||
* You retain access to all upstream bundles and updates.
|
||||
* You can easily revert your system back to the upstream version.
|
||||
|
||||
Related topics
|
||||
==============
|
||||
|
||||
@@ -76,7 +49,6 @@ mixer and related topics to decide which customization approach is best for
|
||||
you.
|
||||
|
||||
* :ref:`mixer`
|
||||
* :ref:`mixin`
|
||||
* :ref:`bundles-about`
|
||||
* :ref:`swupd-about`
|
||||
* :ref:`deploy-at-scale`
|
||||
|
||||
@@ -1,10 +1,10 @@
|
||||
.. _security:
|
||||
|
||||
OS Security
|
||||
OS Security
|
||||
*************************
|
||||
|
||||
|CL-ATTR| aims to make systemic and layered security-conscious decisions
|
||||
that are both performant and practical. This security philosophy is rooted
|
||||
that are both performant and practical. This security philosophy is rooted
|
||||
within the project's codebase and operating culture.
|
||||
|
||||
|
||||
@@ -16,21 +16,21 @@ within the project's codebase and operating culture.
|
||||
Security in Updates
|
||||
===================
|
||||
|
||||
The |CL| team believes in the benefits of
|
||||
software security through open sourcing, incremental updates, and
|
||||
The |CL| team believes in the benefits of
|
||||
software security through open sourcing, incremental updates, and
|
||||
rapidly resolving known security advisories.
|
||||
|
||||
|
||||
|
||||
The latest Linux codebase
|
||||
-------------------------
|
||||
|
||||
|CL| uses the newest version of the Linux kernel which allows the operating
|
||||
system to leverage the latest features from the upstream Linux kernel,
|
||||
including security fixes.
|
||||
The latest Linux* codebase
|
||||
--------------------------
|
||||
|
||||
|CL| uses the newest version of the Linux kernel which allows the operating
|
||||
system to leverage the latest features from the upstream Linux kernel,
|
||||
including security fixes.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Automated Effective Updating
|
||||
----------------------------
|
||||
@@ -38,43 +38,43 @@ Automated Effective Updating
|
||||
|CL| is incrementally updated multiple times per day.
|
||||
|
||||
This `rolling release model`_ allows |CL| to consume the latest security
|
||||
fixes of software packages as soon as they become available.
|
||||
There is no waiting for major or minor releases on |CL|.
|
||||
fixes of software packages as soon as they become available.
|
||||
There is no waiting for major or minor releases on |CL|.
|
||||
|
||||
An update is not effective if it is just simply downloaded onto a system.
|
||||
An update is not effective if it is just simply downloaded onto a system.
|
||||
It needs to be obtained *AND* ensured that the new patched copy is being
|
||||
used; not an older copy loaded into memory. |CL| will let you know when a
|
||||
service needs to be rebooted or do it for your automatically after
|
||||
used; not an older copy loaded into memory. |CL| will let you know when a
|
||||
service needs to be rebooted or do it for your automatically after
|
||||
a software update, if desired.
|
||||
|
||||
|
||||
In |CL| updates are delivered automatically, efficiently,
|
||||
and effectively. For more information see
|
||||
In |CL| updates are delivered automatically, efficiently,
|
||||
and effectively. For more information see
|
||||
`documentation about Software Updates`_ in |CL|.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Automated CVE Scanning and Remediation
|
||||
--------------------------------------
|
||||
|
||||
The sheer number of software packages and security vulnerabilities is growing
|
||||
exponentially. Repositories of Common Vulnerabilities and Exposures (CVEs)
|
||||
and their fixes, if known, are published by :abbr:`NIST` in a
|
||||
The sheer number of software packages and security vulnerabilities is growing
|
||||
exponentially. Repositories of Common Vulnerabilities and Exposures (CVEs)
|
||||
and their fixes, if known, are published by :abbr:`NIST` in a
|
||||
National Vulnerability Database \ |NVD|\ and at \ |MITRE|\ .
|
||||
|
||||
|
||||
|CL| employs a proactive and measured approach to addressing known
|
||||
and fixable :abbr:`CVEs (Common Vulnerabilities and Exposures)`.
|
||||
Packages are automatically scanned against
|
||||
:abbr:`CVEs (Common Vulnerabilities and Exposures)` daily, and security
|
||||
patches are deployed as soon as they are available.
|
||||
Packages are automatically scanned against
|
||||
:abbr:`CVEs (Common Vulnerabilities and Exposures)` daily, and security
|
||||
patches are deployed as soon as they are available.
|
||||
|
||||
These combined practices minimize the amount of
|
||||
These combined practices minimize the amount of
|
||||
time |CL| systems are exposed to unnecessary security risk.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -86,18 +86,18 @@ Minimized attack surface
|
||||
-------------------------
|
||||
|
||||
|CL| removes legacy, unneeded, or redundant standards and
|
||||
components as much as possible to enable the use of best known security
|
||||
standards. Below are some examples:
|
||||
components as much as possible to enable the use of best known security
|
||||
standards. Below are some examples:
|
||||
|
||||
* `RC4`, `SSLv3`, `3DES`, and `SHA-1` ciphers which have had known
|
||||
vulnerabilities, have been explicitly disabled within many |CL| packages to
|
||||
avoid their accidental usage.
|
||||
* `RC4`, `SSLv3`, `3DES`, and `SHA-1` ciphers which have had known
|
||||
vulnerabilities, have been explicitly disabled within many |CL| packages to
|
||||
avoid their accidental usage.
|
||||
|
||||
* Services and subsystems which expose sensitive system information
|
||||
* Services and subsystems which expose sensitive system information
|
||||
have been removed such as the `finger` and `tcpwrappers`.
|
||||
|
||||
* `SFTP` has been disabled by default due to security
|
||||
considerations.
|
||||
* `SFTP` has been disabled by default due to security
|
||||
considerations.
|
||||
|
||||
|
||||
Verified trust
|
||||
@@ -105,65 +105,62 @@ Verified trust
|
||||
|
||||
|CL| encourages the use of secure practices such as encryption
|
||||
and digital signature verification throughout the system and discourages blind
|
||||
trust. Below are some examples:
|
||||
trust. Below are some examples:
|
||||
|
||||
* All update operations from swupd are transparently encrypted and checked
|
||||
against the |CL| maintainers' public key for authenticity.
|
||||
More information can be found in this blog post:
|
||||
`blog post about swupd security`_
|
||||
* All update operations from swupd are transparently encrypted and checked
|
||||
against the |CL| maintainers' public key for authenticity.
|
||||
More information can be found in this blog post:
|
||||
`blog post about swupd security`_
|
||||
|
||||
* Before being built, packages available from |CL| verify checksums and
|
||||
* Before being built, packages available from |CL| verify checksums and
|
||||
signatures provided by third party project codebases and maintainers.
|
||||
|
||||
* |CL| features a unified certificate store, `clrtrust`_ which comes
|
||||
ready to work with well-known Certificate Authorities out of the box.
|
||||
`clrtrust`_ also offers an easy to use command line interface for managing
|
||||
system-wide chains of trust, instead of ignoring foreign certificates.
|
||||
* |CL| features a unified certificate store, `clrtrust`_ which comes
|
||||
ready to work with well-known Certificate Authorities out of the box.
|
||||
`clrtrust`_ also offers an easy to use command line interface for managing
|
||||
system-wide chains of trust, instead of ignoring foreign certificates.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Compiled with secure options
|
||||
----------------------------
|
||||
|
||||
While |CL| packages are optimized for performance on
|
||||
Intel® architecture, security conscious kernel and compiler options are
|
||||
sensibly taken advantage of. Below are some examples:
|
||||
While |CL| packages are optimized for performance on
|
||||
Intel® architecture, security conscious kernel and compiler options are
|
||||
sensibly taken advantage of. Below are some examples:
|
||||
|
||||
|
||||
* Kernels shipped with |CL| are signed and disallow the usage of
|
||||
|
||||
* Kernels shipped with |CL| are signed and disallow the usage of
|
||||
custom kernel modules to maintain verifiable system integrity.
|
||||
|
||||
* `Address space layout randomization (ASLR)`_ and
|
||||
* `Address space layout randomization (ASLR)`_ and
|
||||
`Kernel address space layout randomization (KASLR)`_ are kernel features
|
||||
which defend against certain memory based attacks.
|
||||
which defend against certain memory based attacks.
|
||||
More information can be found in a `blog post about PIE executables`_ .
|
||||
|
||||
* `dm-verity`_ is a kernel mechanism readily available in |CL|
|
||||
which verifies integrity of the devices being written to, like hard disks,
|
||||
to help ensure they have not been tampered with.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Security in System Design
|
||||
=========================
|
||||
|
||||
Simple, yet effective, techniques are used throughout the
|
||||
Simple, yet effective, techniques are used throughout the
|
||||
|CL| system design to defend against common attack vectors and enable
|
||||
good security hygiene. Below are some examples:
|
||||
good security hygiene. Below are some examples:
|
||||
|
||||
|
||||
* Full disk encryption using `Linux Unified Key Setup`_ (LUKS) is available
|
||||
* Full disk encryption using `Linux Unified Key Setup`_ (LUKS) is available
|
||||
during installation.
|
||||
|
||||
* |CL| uses the PAM cracklib module to harden user login and password
|
||||
security resulting in:
|
||||
security resulting in:
|
||||
|
||||
- No default username or root password set out of the box with
|
||||
- No default username or root password set out of the box with
|
||||
|CL|, you will be asked to set your own password immediately.
|
||||
|
||||
- Simple password schemes, which are known to be easily compromised,
|
||||
@@ -172,9 +169,9 @@ good security hygiene. Below are some examples:
|
||||
- A password blacklist, to avoid system passwords being set to
|
||||
passwords which have been compromised in the past.
|
||||
|
||||
* `Tallow`_, a lightweight service which monitors and blocks suspicious SSH
|
||||
login patterns, is installed with the :command:`openssh-server` bundle.
|
||||
|
||||
* `Tallow`_, a lightweight service which monitors and blocks suspicious SSH
|
||||
login patterns, is installed with the :command:`openssh-server` bundle.
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -190,7 +187,7 @@ good security hygiene. Below are some examples:
|
||||
.. _`dm-verity`: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/device-mapper/verity.txt
|
||||
.. _`SELinux`: https://github.com/SELinuxProject
|
||||
.. _`Linux Unified Key Setup`: https://gitlab.com/cryptsetup/cryptsetup/
|
||||
.. _`blog post about PIE executables`: https://clearlinux.org/blogs/recent-gnu-c-library-improvements
|
||||
.. _`blog post about PIE executables`: https://clearlinux.org/blogs/recent-gnu-c-library-improvements
|
||||
.. _`Tallow`: https://github.com/clearlinux/tallow
|
||||
|
||||
.. |NVD| raw:: html
|
||||
@@ -200,4 +197,3 @@ good security hygiene. Below are some examples:
|
||||
.. |MITRE| raw:: html
|
||||
|
||||
<a href="https://cve.mitre.org/" target="_blank">https://cve.mitre.org/</a>
|
||||
|
||||
|
||||
@@ -3,8 +3,8 @@
|
||||
Deploy at Scale
|
||||
###############
|
||||
|
||||
Once you are comfortable with |CL-ATTR| :ref:`concepts <concepts>`, your next step
|
||||
as a system administrator is to understand how to deploy |CL|
|
||||
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
|
||||
@@ -32,39 +32,10 @@ Different business scenarios call for different deployment methodologies.
|
||||
distribution or the option to fork away from the |CL| distribution and
|
||||
act as your own :abbr:`OSV (Operating System Vendor)`.
|
||||
|
||||
Below are overviews of both approaches and some considerations.
|
||||
Below is an overview of 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.
|
||||
|
||||
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
|
||||
|CL| upstream.
|
||||
|
||||
#. 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
|
||||
act as an intermediary buffer between the OS releases. If you do decide
|
||||
to act as a gate to |CL| versions, define a desired release cadence for
|
||||
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.
|
||||
|WEB-SERVER-SCALE|
|
||||
|
||||
Option #2: Create your own Linux distribution (mix)
|
||||
---------------------------------------------------
|
||||
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
|
||||
@@ -267,7 +238,6 @@ 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.
|
||||
|
||||
.. _`mixin process`: https://clearlinux.org/documentation/clear-linux/guides/maintenance/mixin
|
||||
.. _`mixer process`: https://clearlinux.org/documentation/clear-linux/guides/maintenance/mixer
|
||||
.. _`downloads page`: https://clearlinux.org/downloads/
|
||||
.. _`containers page`: https://clearlinux.org/downloads/containers
|
||||
|
||||
@@ -4,6 +4,7 @@ Guides
|
||||
######
|
||||
|
||||
The following guides provide step-by-step instructions on using |CL|.
|
||||
Note: As of 22 May 2019 :file:`mixin` is no longer supported.
|
||||
|
||||
Tooling
|
||||
=======
|
||||
|
||||
@@ -238,11 +238,14 @@ and dependencies in order for autospec to complete a successful build.
|
||||
|
||||
cd packages/opae-sdk
|
||||
|
||||
#. Add a license:
|
||||
#. Add one or more valid license identifier from the
|
||||
`SPDX License List <https://spdx.org/licenses/>`_.
|
||||
In the example below, two different licenses are appropriate based on the
|
||||
opae-sdk project licensing:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
echo "Intel Corporation" > opae-sdk.license
|
||||
echo "BSD-3-Clause MIT" > opae-sdk.license
|
||||
|
||||
#. Run autospec again:
|
||||
|
||||
@@ -327,7 +330,7 @@ Test packaged software
|
||||
|
||||
After software has been packaged with autospec, the resulting RPMs can be
|
||||
tested for functionality before being integrated and deployed into a |CL|
|
||||
image with the :ref:`Mixer tool <mixer>` or :ref:`Mixin tool <mixin>`.
|
||||
image with the :ref:`Mixer tool <mixer>`.
|
||||
|
||||
The |CL| development tooling offers two ways to quickly test autospec
|
||||
generated RPMs.
|
||||
@@ -500,7 +503,6 @@ Related topics
|
||||
**************
|
||||
|
||||
* :ref:`Mixer tool <mixer>`
|
||||
* :ref:`Mixin tool <mixin>`
|
||||
|
||||
.. _user-setup script: https://github.com/clearlinux/common/blob/master/user-setup.sh
|
||||
.. _`Makefile.common file on GitHub`: https://github.com/clearlinux/common/blob/master/Makefile.common
|
||||
|
||||
@@ -829,7 +829,6 @@ Related topics
|
||||
**************
|
||||
|
||||
* :ref:`About mixer <mixer-about>`
|
||||
* :ref:`mixin`
|
||||
* :ref:`autospec-about`
|
||||
* :ref:`bundles-about`
|
||||
* :ref:`swupd-about`
|
||||
|
||||
@@ -1,191 +0,0 @@
|
||||
.. _mixin:
|
||||
|
||||
mixin
|
||||
#####
|
||||
|
||||
mixin is a tool provided in the |CL-ATTR| that allows users to add custom
|
||||
content to their client systems and still receive updates from their upstream OS
|
||||
vendor.
|
||||
|
||||
.. contents::
|
||||
:local:
|
||||
:depth: 1
|
||||
|
||||
Description
|
||||
***********
|
||||
|
||||
mixin uses the mixer tool to generate a local update for client systems. With
|
||||
the mixin tool, a user can add remote RPM repositories or local RPMs and mix
|
||||
them into their update stream, while continuing to get upstream bundles and
|
||||
updates. The metadata generated from the mixin tool is merged with the upstream
|
||||
metadata to provide a single source of update content, which swupd uses to
|
||||
perform updates.
|
||||
|
||||
The mixin tool is included in the :command:`mixer` bundle.
|
||||
|
||||
How to use
|
||||
**********
|
||||
|
||||
Learn the mixin tool set up and workflow.
|
||||
|
||||
.. contents::
|
||||
:local:
|
||||
:depth: 1
|
||||
|
||||
Prerequisites
|
||||
=============
|
||||
|
||||
Install the :command:`mixer` bundle to add the mixin tool. Refer to
|
||||
`Install a bundle`_ for more details.
|
||||
|
||||
Workflow
|
||||
========
|
||||
|
||||
The following steps show how to create and add a custom bundle with the mixin
|
||||
tool:
|
||||
|
||||
#. Add or create a new repo(s)
|
||||
|
||||
mixin pulls packages to build your custom bundle from locations referred to
|
||||
as repos. There are two default repos for mixin:
|
||||
|
||||
* upstream
|
||||
* local
|
||||
|
||||
Additional repos can be added, such as other locations on your local system
|
||||
or remote repos.
|
||||
|
||||
RPMs must be built specifically for |CL| in order for them to work properly.
|
||||
Refer to :ref:`autospec` for instruction on creating RPMs for |CL|.
|
||||
|
||||
#. Create a custom bundle with desired RPMs
|
||||
|
||||
Add the desired packages to your new bundle and build the bundle. By default,
|
||||
the bundle will be named after its parent repo.
|
||||
|
||||
The first time you build the bundle, mixer will create a new OS version by
|
||||
taking your current upstream |CL| version and multiplying it by 1000. For
|
||||
example, if your upstream version is 27650, your custom version will be
|
||||
27650000. For each subsequent call to mixin, mixer will increment the version
|
||||
by 10.
|
||||
|
||||
View the `mixin man page`_ for more information on mixin commands.
|
||||
|
||||
#. Update system to make custom bundle available
|
||||
|
||||
Update your system using swupd to make your custom bundle accessible.
|
||||
|
||||
When you first create your mix, you will have to do a one-time migration to
|
||||
your custom mix as part of the update. After you migrate, the system version
|
||||
switches over to your last custom version number as noted in the previous
|
||||
step. As long as you remain on your custom version of |CL| you can continue
|
||||
to create and add new bundles to your mix with no extra migration step.
|
||||
|
||||
#. Install custom bundles
|
||||
|
||||
Install your custom bundle using the normal swupd :command:`bundle-add`
|
||||
command.
|
||||
|
||||
View the `swupd man page`_ for more information on swupd commands.
|
||||
|
||||
Examples
|
||||
********
|
||||
|
||||
Complete all `Prerequisites`_ before using these examples.
|
||||
|
||||
Example 1: Add custom helloclear bundle
|
||||
=======================================
|
||||
|
||||
This example shows the basic steps of adding a custom bundle from a local repo.
|
||||
|
||||
#. Check that :command:`helloclear` does not exist on your system:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
helloclear
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
helloclear: command not found
|
||||
|
||||
#. Follow the "Build a new RPM" example from :ref:`autospec` to create a new
|
||||
`helloclear` RPM.
|
||||
|
||||
The resulting RPMs are in `~/clearlinux/packages/helloclear/rpms`.
|
||||
|
||||
#. Create a new repo.
|
||||
|
||||
#. Create a local repo folder and copy the new `helloclear` RPM files into
|
||||
the repo:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
mkdir ~/mixin-repo
|
||||
cp ~/clearlinux/packages/helloclear/rpms/helloclear-v1.0-1.x86_64.rpm ~/mixin-repo
|
||||
cp ~/clearlinux/packages/helloclear/rpms/helloclear-bin-v1.0-1.x86_64.rpm ~/mixin-repo
|
||||
|
||||
#. Create the repo data:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
cd ~/mixin-repo
|
||||
createrepo_c .
|
||||
|
||||
#. Add the repo name:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
sudo mixin repo add mylocalrepo file://$HOME/mixin-repo/
|
||||
|
||||
#. Create custom bundle with the new `helloclear` RPM. Add `helloclear` to the
|
||||
:command:`helloclear-bundle` bundle and build the bundle:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
sudo mixin package add helloclear --bundle helloclear-bundle
|
||||
sudo mixin build
|
||||
|
||||
#. Migrate your |CL| to your custom mix. Check your version before and after the
|
||||
update to see the switch to your custom mix:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
sudo swupd check-update
|
||||
sudo swupd update --migrate
|
||||
sudo swupd check-update
|
||||
|
||||
#. Install your custom bundle. Check that the `helloclear-bundle` is now
|
||||
available and install it to your system:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
sudo swupd bundle-list -a | grep helloclear-bundle
|
||||
sudo swupd bundle-add helloclear-bundle
|
||||
|
||||
#. Test for `helloclear` again to see that it is installed:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
helloclear
|
||||
|
||||
#. Revert your system back to upstream (optional). This example reverts back to
|
||||
upstream version 27650:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
sudo swupd verify --fix --picky --force -m 27650 -C /usr/share/clear/update-ca/Swupd_Root.pem
|
||||
sudo swupd clean --all
|
||||
sudo swupd check-update
|
||||
|
||||
Related topics
|
||||
**************
|
||||
|
||||
* :ref:`About mixer <mixer-about>`
|
||||
* :ref:`mixer`
|
||||
* :ref:`autospec-about`
|
||||
* :ref:`bundles-about`
|
||||
* :ref:`swupd-about`
|
||||
|
||||
.. _mixin man page: https://github.com/clearlinux/mixer-tools/blob/master/docs/mixin.1.rst
|
||||
.. _swupd man page: https://github.com/clearlinux/swupd-client/blob/master/docs/swupd.1.rst
|
||||
.. _Install a bundle: https://clearlinux.org/documentation/clear-linux/guides/maintenance/swupd-guide#adding-a-bundle
|
||||
@@ -52,12 +52,12 @@ Install the appropriate DKMS bundle using the instructions below:
|
||||
:end-before: kernel-modules-dkms-install-end:
|
||||
|
||||
|
||||
Download and install the NVIDIA Linux Driver
|
||||
********************************************
|
||||
Download and install the NVIDIA Drivers
|
||||
***************************************
|
||||
|
||||
|
||||
Download the NVIDIA Linux Driver
|
||||
================================
|
||||
Download the NVIDIA Drivers for Linux
|
||||
=====================================
|
||||
|
||||
#. Identify the model of NVIDIA GPU that is installed.
|
||||
|
||||
@@ -107,28 +107,35 @@ needs to be disabled before installation can continue.
|
||||
|
||||
|
||||
|
||||
Install the NVIDIA Linux Driver
|
||||
===============================
|
||||
Configure the Dynamic Linker
|
||||
============================
|
||||
|
||||
The NVIDIA installer will be directed to install files under
|
||||
:file:`/opt/nvidia` as much as possible to keep its contents isolated from the
|
||||
rest of the |CL| files under :file:`/usr`.
|
||||
rest of the |CL| system files under :file:`/usr`. The dynamic linker will
|
||||
need to be configured to use the NVIDIA-provided libraries.
|
||||
|
||||
|
||||
#. Configure the dynamic linker to look for and cache shared libraries under
|
||||
:file:`/opt/nvidia/lib` and :file:`/opt/nvidia/lib32`.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
echo "include /etc/ld.so.conf.d/*.conf" | sudo tee --append /etc/ld.so.conf
|
||||
|
||||
sudo mkdir /etc/ld.so.conf.d
|
||||
printf "/opt/nvidia/lib \n/opt/nvidia/lib32 \n" | sudo tee --append /etc/ld.so.conf.d/nvidia.conf
|
||||
|
||||
|
||||
|
||||
Install the NVIDIA Drivers
|
||||
==========================
|
||||
|
||||
|
||||
#. A terminal not running on */dev/tty1* is useful to view uninterrupted
|
||||
installation progress. Switch to a secondary virtual terminal by pushing
|
||||
:command:`CTRL + ALT + F2` or remotely login over SSH.
|
||||
|
||||
#. Configure the dynamic linker to look for and cache shared libraries under
|
||||
:file:`/opt/nvidia/lib` and :file:`/opt/nvidia/lib32` where the NVIDIA
|
||||
installer will place libraries.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
echo "include /etc/ld.so.conf.d/*.conf" | sudo tee --append /etc/ld.so.conf
|
||||
sudo mkdir /etc/ld.so.conf.d
|
||||
printf "/opt/nvidia/lib \n/opt/nvidia/lib32 \n" | sudo tee --append /etc/ld.so.conf.d/nvidia.conf
|
||||
|
||||
|
||||
#. Navigate into the directory where the NVIDIA installer was downloaded.
|
||||
|
||||
@@ -183,8 +190,55 @@ rest of the |CL| files under :file:`/usr`.
|
||||
with the proprietary NVIDIA drivers installed.
|
||||
|
||||
|
||||
Uninstalling the NVIDIA driver
|
||||
******************************
|
||||
|
||||
|
||||
Updating the NVIDIA Drivers
|
||||
***************************
|
||||
|
||||
The proprietary NVIDIA drivers are installed manually outside of :ref:`swupd
|
||||
<swupd-about>` and must be updated manually when needed.
|
||||
|
||||
Updating the NVIDIA drivers follows the same steps as initial installation,
|
||||
however the desktop environment must first be stopped so that the drivers are
|
||||
not in use.
|
||||
|
||||
#. Follow the steps in `Download the NVIDIA Drivers for Linux`_ section to get
|
||||
the latest NVIDIA drivers.
|
||||
|
||||
#. Temporarily set the default boot target to the *multi-user* which is
|
||||
a non-graphical runtime.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
sudo systemctl set-default multi-user.target
|
||||
|
||||
|
||||
#. Reboot the system and log back in. It is normal for the graphical
|
||||
environment to not start.
|
||||
|
||||
#. Follow the steps in `Install the NVIDIA Drivers`_ section to update
|
||||
the NVIDIA drivers. This installation will overwrite the previous NVIDIA
|
||||
drivers and files.
|
||||
|
||||
#. Set the default boot target back to the *graphical* target.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
sudo systemctl set-default graphical.target
|
||||
|
||||
|
||||
#. Reboot the system and log back in.
|
||||
|
||||
#. Trigger a flatpak update which will download the runtime corresponding
|
||||
with the new NVIDIA drivers for flatpak apps requiring it.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
flatpak update
|
||||
|
||||
|
||||
Uninstalling the NVIDIA Drivers
|
||||
*******************************
|
||||
|
||||
The NVIDIA drivers and associated software can be uninstalled and nouveau
|
||||
driver restored by:
|
||||
@@ -202,8 +256,8 @@ driver restored by:
|
||||
#. Follow the prompts on the screen and reboot the system.
|
||||
|
||||
|
||||
Debugging NVIDIA driver installation
|
||||
************************************
|
||||
Debugging Installation of NVIDIA Drivers
|
||||
****************************************
|
||||
|
||||
* The NVIDIA driver places installer and uninstaller logs under
|
||||
:file:`/var/log/nvidia-install` and :file:`/var/log/nvidia-uninstall`.
|
||||
|
||||
Reference in New Issue
Block a user