Added fix for swupd bundle-add Error

Signed-off-by: Anthony Pray anthony.s.pray@intel.com When using the docker image you may see error "Failed to install x of x" ruining "swupd clean" will fix the problems.
Adds hugepages config guide to explain defaults and config settings (#1061 )
2026-08-24 00:15:57 +00:00 · 2020-03-09 12:11:34 -07:00 · 2020-03-06 15:26:02 -08:00 · 2020-03-06 14:59:39 -08:00 · 2020-03-06 14:57:09 -08:00 · 2020-03-06 14:47:52 -08:00
1413 changed files with 42576 additions and 313174 deletions
@@ -1,4 +0,0 @@
-# Sphinx build info version 1
-# This file records the configuration used when building these files. When it is not found, a full rebuild will be done.
-config: f8974e043de468370d3f73767671d8de
-tags: 645f666f9bcd5a90fca523b33c5a78b7
@@ -0,0 +1,22 @@
+---
+name: Modify document
+about: Modify a document for the Clear Linux* Project
+title: ''
+labels: P2
+assignees: ''
+
+---
+
+**Describe the error/improvement to an existing document or image**
+Provide a clear and concise description of the error or proposed improvement.
+
+**Screenshots**
+If applicable, add screenshots to help explain the error or unexpected behavior.
+
+**Environment (please complete the following):**
+ - Clear Linux OS version: [`cat /usr/lib/os-release`]
+ - Third-party tool/software: [version]
+ - Command [ [e.g. `sudo -i`]
+
+**Additional context**
+Add any other context about the problem here.
@@ -0,0 +1,20 @@
+---
+name: New document
+about: Request a new document for the Clear Linux* project
+title: ''
+labels: P2
+assignees: ''
+
+---
+
+**Do you think Clear Linux documentation needs a new document? Please describe.**
+Please provide a clear and concise description of the title and content. Identify the target audience: Developer; System Administrator; or Basic User.
+
+**Should the new document be a guide, a reference, or a tutorial?**
+Recommend a type of document, based on the structure here: https://clearlinux.org/documentation/clear-linux
+
+**Describe or provide examples of similar documents, if possible, from other web sites**
+Please provide an example of similar documents if possible.
+
+**Additional context**
+Add any other context or screenshots for the document request here.
@@ -0,0 +1,23 @@
+name: Check
+
+on: [pull_request]
+
+
+jobs:
+  build:
+
+    runs-on: ubuntu-latest
+
+    steps:
+    - uses: actions/checkout@v1
+    - name: Install dependencies
+      run: |
+        export PATH="$HOME/.local/bin:$PATH"
+        sudo apt-get install -y python3-setuptools
+        pip3 install --user -r requirements.txt
+    - name: Build the docs
+      run: |
+        export PATH="$HOME/.local/bin:$PATH"
+        make py
+        make htmlall
+        
@@ -0,0 +1,13 @@
+name: Greetings
+
+on: [pull_request, issues]
+
+jobs:
+  greeting:
+    runs-on: ubuntu-latest
+    steps:
+    - uses: actions/first-interaction@v1
+      with:
+        repo-token: ${{ secrets.GITHUB_TOKEN }}
+        issue-message: 'Welcome to Clear Linux* OS Docs. Thanks for submitting your first issue.'
+        pr-message: 'Welcome to Clear Linux* OS Docs. Thanks for submitting your first PR.'
@@ -0,0 +1,39 @@
+name: CI
+
+on:
+  push:
+    branches:
+        - master
+
+jobs:
+  build:
+
+    runs-on: ubuntu-latest
+
+    steps:
+    - uses: actions/checkout@v1
+    - name: Install dependencies
+      run: |
+        export PATH="$HOME/.local/bin:$PATH"
+        sudo apt-get install -y python3-setuptools
+        pip3 install --user -r requirements.txt
+    - name: Build the docs
+      run: |
+        export PATH="$HOME/.local/bin:$PATH"
+        make py
+        make htmlall
+    - name: Pre-deploy
+      run: |
+        wget https://github.com/clearlinux/clear-linux-documentation-zh-CN/releases/latest/download/clearlinux-docs-zh-CN.tar.gz
+        mkdir source/_build/html/zh_CN
+        tar xvzf clearlinux-docs-zh-CN.tar.gz -C source/_build/html/zh_CN
+        mv source/_build/html $HOME/output
+    - name: Deploy the docs
+      run: |
+        cd $HOME/output
+        git init
+        git config --global user.name "${GITHUB_ACTOR}"
+        git config --global user.email "${GITHUB_ACTOR}@github.com"
+        git add .
+        git commit -m "latest html output"
+        git push -f https://${GITHUB_ACTOR}:${{secrets.ACCESS_TOKEN}}@github.com/clearlinux/clear-linux-documentation.git HEAD:developmentHTML
@@ -0,0 +1,43 @@
+name: Publish
+
+on:
+  push:
+    branches:
+        - publish
+
+jobs:
+  build:
+
+    runs-on: ubuntu-latest
+
+    steps:
+    - uses: actions/checkout@v1
+    - name: Install dependencies
+      run: |
+        export PATH="$HOME/.local/bin:$PATH"
+        sudo apt-get install -y python3-setuptools
+        pip3 install --user -r requirements.txt
+    - name: Build the docs
+      run: |
+        export PATH="$HOME/.local/bin:$PATH"
+        make py
+        make htmlall
+    - name: Pre-deploy
+      run: |
+        wget https://github.com/clearlinux/clear-linux-documentation-zh-CN/releases/latest/download/clearlinux-docs-zh-CN.tar.gz
+        mkdir source/_build/html/zh_CN
+        tar xvzf clearlinux-docs-zh-CN.tar.gz -C source/_build/html/zh_CN
+        mv source/_build/html $HOME/output
+    - name: Deploy the docs
+      run: |
+        cd $HOME/output
+        git init
+        git config --global user.name "${GITHUB_ACTOR}"
+        git config --global user.email "${GITHUB_ACTOR}@github.com"
+        git add .
+        git commit -m "latest html output"
+        git push -f https://${GITHUB_ACTOR}:${{secrets.ACCESS_TOKEN}}@github.com/clearlinux/clear-linux-documentation.git HEAD:latestHTML
+    - name: Publish the docs
+      run: |
+        wget ${{secrets.PUBLISH_URL}}
+        cat clearlinux-latest
@@ -0,0 +1,19 @@
+#Exluding from the tree the html build files
+source/_build
+# ignore vi temporary files
+*.swp
+*~
+.*~
+
+# ignore VS code settings
+.vscode/
+
+# ignore .mo translation files
+*.mo
+
+# ignore artifacts generated by running make py
+cloned_repo
+bundles.html.txt
+
+# ignore the venv, used for running make py
+venv
@@ -0,0 +1,19 @@
+image: alpine
+
+pages:
+  script:
+  - apk --no-cache add python3
+  - python3 -m ensurepip
+  - pip3 install sphinx==1.8.0 docutils==0.14 sphinx_rtd_theme breathe==4.9.1 sphinxcontrib-plantuml sphinx-intl==2.0.0 sphinx-sitemap==1.0.2
+  - apk --no-cache add make
+  - apk --no-cache add doxygen
+  - apk --no-cache add graphviz
+  - apk --no-cache add ttf-dejavu 
+  - apk --no-cache add openjdk8-jre
+  - make htmlall
+  - mv source/_build/html/ public/
+  artifacts:
+    paths:
+    - public
+  only:
+  - rtd-theme
@@ -1,405 +0,0 @@
-
-<!DOCTYPE html>
-
-<html lang="en" data-content_root="../">
-  <head>
-    <meta charset="utf-8" />
-    <meta name="viewport" content="width=device-width, initial-scale=1.0" /><meta name="viewport" content="width=device-width, initial-scale=1" />
-
-    <title>FAQ &#8212; Documentation for Clear Linux* project</title>
-    <link rel="stylesheet" type="text/css" href="../_static/pygments.css?v=fa44fd50" />
-    <link rel="stylesheet" type="text/css" href="../_static/bizstyle.css?v=5283bb3d" />
-    <link rel="stylesheet" type="text/css" href="../_static/copybutton.css?v=76b2166b" />
-    
-    <script src="../_static/documentation_options.js?v=5929fcd5"></script>
-    <script src="../_static/doctools.js?v=9bcbadda"></script>
-    <script src="../_static/sphinx_highlight.js?v=dc90522c"></script>
-    <script src="../_static/clipboard.min.js?v=a7894cd8"></script>
-    <script src="../_static/copybutton.js?v=a56c686a"></script>
-    <script src="../_static/bizstyle.js"></script>
-    <link rel="canonical" href="https://clearlinux.github.io/clear-linux-documentation/FAQ/index.html" />
-    <link rel="icon" href="../_static/favicon.ico"/>
-    <link rel="author" title="About these documents" href="../about.html" />
-    <link rel="index" title="Index" href="../genindex.html" />
-    <link rel="search" title="Search" href="../search.html" />
-    <link rel="next" title="Contribute" href="../collaboration/collaboration.html" />
-    <link rel="prev" title="Tutorial difficulty ratings" href="../reference/tutorial-ratings.html" />
-    <meta name="viewport" content="width=device-width,initial-scale=1.0" />
-    <!--[if lt IE 9]>
-    <script src="_static/css3-mediaqueries.js"></script>
-    <![endif]-->
-  </head><body>
-    <div class="related" role="navigation" aria-label="Related">
-      <h3>Navigation</h3>
-      <ul>
-        <li class="right" style="margin-right: 10px">
-          <a href="../genindex.html" title="General Index"
-             accesskey="I">index</a></li>
-        <li class="right" >
-          <a href="../collaboration/collaboration.html" title="Contribute"
-             accesskey="N">next</a> |</li>
-        <li class="right" >
-          <a href="../reference/tutorial-ratings.html" title="Tutorial difficulty ratings"
-             accesskey="P">previous</a> |</li>
-        <li class="nav-item nav-item-0"><a href="../index.html">Documentation for Clear Linux* project</a> &#187;</li>
-        <li class="nav-item nav-item-this"><a href="">FAQ</a></li> 
-      </ul>
-    </div>  
-
-    <div class="document">
-      <div class="documentwrapper">
-        <div class="bodywrapper">
-          <div class="body" role="main">
-            
-  <section id="faq">
-<span id="id1"></span><h1>FAQ<a class="headerlink" href="#faq" title="Link to this heading">¶</a></h1>
-<p>Below is a list of commonly asked questions with answers sourced from the
-Clear Linux* OS team and <a class="reference external" href="https://community.clearlinux.org">Clear Linux community forums</a>.</p>
-<nav class="contents local" id="contents">
-<ul class="simple">
-<li><p><a class="reference internal" href="#general" id="id2">General</a></p>
-<ul>
-<li><p><a class="reference internal" href="#what-is-cl" id="id3">What is Clear Linux OS?</a></p></li>
-<li><p><a class="reference internal" href="#why-another-linux-distribution" id="id4">Why another Linux distribution?</a></p></li>
-<li><p><a class="reference internal" href="#is-it-a-derivative-of-another-linux-distribution" id="id5">Is it a derivative of another Linux distribution?</a></p></li>
-<li><p><a class="reference internal" href="#can-others-copy-improvements-from-cl" id="id6">Can others copy improvements from Clear Linux OS?</a></p></li>
-<li><p><a class="reference internal" href="#how-often-does-it-update" id="id7">How often does it update?</a></p></li>
-<li><p><a class="reference internal" href="#is-telemetry-required" id="id8">Is telemetry required?</a></p></li>
-<li><p><a class="reference internal" href="#what-is-the-default-firewall" id="id9">What is the default firewall?</a></p></li>
-<li><p><a class="reference internal" href="#where-are-the-files-that-i-usually-see-under-etc-like-fstab" id="id10">Where are the files that I usually see under /etc like fstab?</a></p></li>
-<li><p><a class="reference internal" href="#does-it-use-the-intel-compiler-icc" id="id11">Does it use the Intel Compiler (icc)?</a></p></li>
-</ul>
-</li>
-<li><p><a class="reference internal" href="#software" id="id12">Software</a></p>
-<ul>
-<li><p><a class="reference internal" href="#how-is-software-installed-and-updated" id="id13">How is software installed and updated?</a></p></li>
-<li><p><a class="reference internal" href="#does-it-use-rpms-or-debs-packages-like-other-distros" id="id14">Does it use RPMs or DEBs packages like other distros?</a></p></li>
-<li><p><a class="reference internal" href="#why-does-it-have-a-different-approach-to-software-management" id="id15">Why does it have a different approach to software management?</a></p></li>
-<li><p><a class="reference internal" href="#can-i-install-a-software-package-from-another-os-on-cl" id="id16">Can I install a software package from another OS on Clear Linux OS?</a></p></li>
-</ul>
-</li>
-<li><p><a class="reference internal" href="#software-availability" id="id17">Software availability</a></p>
-<ul>
-<li><p><a class="reference internal" href="#what-software-is-available-on-cl" id="id18">What software is available on Clear Linux OS?</a></p></li>
-<li><p><a class="reference internal" href="#is-google-chrome-available" id="id19">Is Google* Chrome* available?</a></p></li>
-<li><p><a class="reference internal" href="#is-microsoft-visual-studio-code-available" id="id20">Is Microsoft* Visual Studio Code* available?</a></p></li>
-<li><p><a class="reference internal" href="#is-ffmpeg-available" id="id21">Is FFmpeg available?</a></p></li>
-<li><p><a class="reference internal" href="#is-zfs-available" id="id22">Is ZFS* available?</a></p></li>
-<li><p><a class="reference internal" href="#can-you-add-a-driver-that-i-need" id="id23">Can you add a driver that I need?</a></p></li>
-</ul>
-</li>
-</ul>
-</nav>
-<section id="general">
-<h2><a class="toc-backref" href="#id2" role="doc-backlink">General</a><a class="headerlink" href="#general" title="Link to this heading">¶</a></h2>
-<section id="what-is-cl">
-<h3><a class="toc-backref" href="#id3" role="doc-backlink">What is Clear Linux OS?</a><a class="headerlink" href="#what-is-cl" title="Link to this heading">¶</a></h3>
-<p>Clear Linux OS is an open source, rolling release Linux distribution optimized for
-performance and security. See <a class="reference external" href="https://clearlinux.org/about">the about page</a>
-for more information.</p>
-<div class="line-block">
-<div class="line"><br /></div>
-</div>
-</section>
-<section id="why-another-linux-distribution">
-<h3><a class="toc-backref" href="#id4" role="doc-backlink">Why another Linux distribution?</a><a class="headerlink" href="#why-another-linux-distribution" title="Link to this heading">¶</a></h3>
-<p>The Clear Linux OS team felt that performance was left on the table with Linux software.
-Clear Linux OS takes a holistic approach to improve performance across the stack. We
-also wanted to take more modern approaches with OS updates and tooling.</p>
-<div class="line-block">
-<div class="line"><br /></div>
-</div>
-</section>
-<section id="is-it-a-derivative-of-another-linux-distribution">
-<h3><a class="toc-backref" href="#id5" role="doc-backlink">Is it a derivative of another Linux distribution?</a><a class="headerlink" href="#is-it-a-derivative-of-another-linux-distribution" title="Link to this heading">¶</a></h3>
-<p>No. Clear Linux OS is a new Linux distribution. It is not a fork and does not have a
-parent Linux distribution.</p>
-<div class="line-block">
-<div class="line"><br /></div>
-</div>
-</section>
-<section id="can-others-copy-improvements-from-cl">
-<h3><a class="toc-backref" href="#id6" role="doc-backlink">Can others copy improvements from Clear Linux OS?</a><a class="headerlink" href="#can-others-copy-improvements-from-cl" title="Link to this heading">¶</a></h3>
-<p>Yes, we absolutely love open source reuse and upstreaming improvements.</p>
-<div class="line-block">
-<div class="line"><br /></div>
-</div>
-</section>
-<section id="how-often-does-it-update">
-<h3><a class="toc-backref" href="#id7" role="doc-backlink">How often does it update?</a><a class="headerlink" href="#how-often-does-it-update" title="Link to this heading">¶</a></h3>
-<p>The Clear Linux OS team puts out multiple releases a week, often releasing two or more
-times a day. This rolling release approach allows Clear Linux OS to remain agile to
-upstream changes and security patches.</p>
-<div class="line-block">
-<div class="line"><br /></div>
-</div>
-</section>
-<section id="is-telemetry-required">
-<h3><a class="toc-backref" href="#id8" role="doc-backlink">Is telemetry required?</a><a class="headerlink" href="#is-telemetry-required" title="Link to this heading">¶</a></h3>
-<p>The telemetry solution provided by Clear Linux OS is entirely optional and customizable.
-It is disabled by default. If you do choose to enable telemetry, the data
-helps the Clear Linux OS team proactively identify and resolve bugs. See the
-<a class="reference internal" href="../guides/clear/telemetrics.html#telem-guide"><span class="std std-ref">telemetry</span></a> guide for more information.</p>
-<div class="line-block">
-<div class="line"><br /></div>
-</div>
-</section>
-<section id="what-is-the-default-firewall">
-<h3><a class="toc-backref" href="#id9" role="doc-backlink">What is the default firewall?</a><a class="headerlink" href="#what-is-the-default-firewall" title="Link to this heading">¶</a></h3>
-<p>Clear Linux OS packages <strong class="command">iptables</strong> and <strong class="command">firewalld</strong> as optional
-bundles, however, there are no default firewall rules. All network traffic is
-allowed by default.</p>
-<div class="line-block">
-<div class="line"><br /></div>
-</div>
-</section>
-<section id="where-are-the-files-that-i-usually-see-under-etc-like-fstab">
-<h3><a class="toc-backref" href="#id10" role="doc-backlink">Where are the files that I usually see under /etc like fstab?</a><a class="headerlink" href="#where-are-the-files-that-i-usually-see-under-etc-like-fstab" title="Link to this heading">¶</a></h3>
-<p>Clear Linux OS has a stateless design that maintains a separation between system files
-and user files. Default values are stored under <code class="file docutils literal notranslate"><span class="pre">/usr/share/defaults/</span></code>.
-Clear Linux OS starts with a mostly empty <code class="file docutils literal notranslate"><span class="pre">/etc</span></code> directory to store user-defined
-configurations. See the <a class="reference internal" href="../guides/clear/stateless.html#stateless"><span class="std std-ref">stateless</span></a> page for more information.</p>
-<p>See <a class="reference external" href="https://clearlinux.org/news-blogs/where-etcfstab-clear-linux">this blog post</a> for an
-example explaining how this is accomplished with <code class="file docutils literal notranslate"><span class="pre">/etc/fstab/</span></code>
-specifically.</p>
-<div class="line-block">
-<div class="line"><br /></div>
-</div>
-</section>
-<section id="does-it-use-the-intel-compiler-icc">
-<h3><a class="toc-backref" href="#id11" role="doc-backlink">Does it use the Intel Compiler (icc)?</a><a class="headerlink" href="#does-it-use-the-intel-compiler-icc" title="Link to this heading">¶</a></h3>
-<p>No. Clear Linux OS uses open source compilers: <strong class="command">gcc</strong> and <strong class="command">clang</strong>. Clear Linux OS
-does not compile any packages with <strong class="command">icc</strong>.</p>
-<p>For a more detailed explanation, see <a class="reference external" href="https://community.clearlinux.org/t/does-clear-linux-os-use-the-intel-compiler-icc-tl-nope/">this discussion on the community forum</a>.</p>
-<div class="line-block">
-<div class="line"><br /></div>
-</div>
-</section>
-</section>
-<section id="software">
-<h2><a class="toc-backref" href="#id12" role="doc-backlink">Software</a><a class="headerlink" href="#software" title="Link to this heading">¶</a></h2>
-<section id="how-is-software-installed-and-updated">
-<h3><a class="toc-backref" href="#id13" role="doc-backlink">How is software installed and updated?</a><a class="headerlink" href="#how-is-software-installed-and-updated" title="Link to this heading">¶</a></h3>
-<p>Clear Linux OS provides software in the form of <a class="reference internal" href="../guides/clear/bundles.html#bundles-guide"><span class="std std-ref">bundles</span></a> and
-updates software with <a class="reference internal" href="../guides/clear/swupd.html#swupd-guide"><span class="std std-ref">swupd</span></a>.</p>
-<p><a class="reference internal" href="../tutorials/flatpak.html#flatpak-tutorial"><span class="std std-ref">Flatpak*</span></a> is an application virtualization solution
-that allows more software to be available to Clear Linux OS users by augmenting the
-software Clear Linux OS packages natively with software available through Flatpak.</p>
-<p>Our goal is to have software packaged natively and made available through
-bundles whenever possible.</p>
-<div class="line-block">
-<div class="line"><br /></div>
-</div>
-</section>
-<section id="does-it-use-rpms-or-debs-packages-like-other-distros">
-<h3><a class="toc-backref" href="#id14" role="doc-backlink">Does it use RPMs or DEBs packages like other distros?</a><a class="headerlink" href="#does-it-use-rpms-or-debs-packages-like-other-distros" title="Link to this heading">¶</a></h3>
-<p>No. Clear Linux OS provides software to systems in the form of <a class="reference internal" href="../guides/clear/bundles.html#bundles-guide"><span class="std std-ref">Bundles</span></a>.
-Under the hood, Clear Linux OS developers use the RPM format as an intermediary step for
-packaging and determining software dependencies at OS build time.</p>
-<p>Individual RPMs and DEBs can sometimes be manually extracted and installed on
-a Clear Linux OS system with the right tools, but that is not the intended use case.</p>
-<div class="line-block">
-<div class="line"><br /></div>
-</div>
-</section>
-<section id="why-does-it-have-a-different-approach-to-software-management">
-<h3><a class="toc-backref" href="#id15" role="doc-backlink">Why does it have a different approach to software management?</a><a class="headerlink" href="#why-does-it-have-a-different-approach-to-software-management" title="Link to this heading">¶</a></h3>
-<p>The Clear Linux OS team wants software <em>installation</em> and <em>updates</em> to be as efficient
-and error free as possible. Clear Linux OS packages software differently and uses a
-novel updater to solve some of the classic problems with how the software
-packages are on Linux.</p>
-<p>For a more detailed explanation, see <a class="reference external" href="https://community.clearlinux.org/t/why-does-clearlinux-use-swupd-and-not-apt-deb-rpm/">this discussion on our community forum</a>.</p>
-<div class="line-block">
-<div class="line"><br /></div>
-</div>
-</section>
-<section id="can-i-install-a-software-package-from-another-os-on-cl">
-<h3><a class="toc-backref" href="#id16" role="doc-backlink">Can I install a software package from another OS on Clear Linux OS?</a><a class="headerlink" href="#can-i-install-a-software-package-from-another-os-on-cl" title="Link to this heading">¶</a></h3>
-<p>Software that is packaged in other formats for other Linux distributions is
-not guaranteed to work on Clear Linux OS and may be impacted by Clear Linux OS updates.</p>
-<p>If the software you’re seeking is open source, please submit a request to add
-it to Clear Linux OS. Submit requests on GitHub* here:
-<a class="reference external" href="https://github.com/clearlinux/distribution/issues">https://github.com/clearlinux/distribution/issues</a></p>
-<div class="line-block">
-<div class="line"><br /></div>
-</div>
-</section>
-</section>
-<section id="software-availability">
-<h2><a class="toc-backref" href="#id17" role="doc-backlink">Software availability</a><a class="headerlink" href="#software-availability" title="Link to this heading">¶</a></h2>
-<section id="what-software-is-available-on-cl">
-<h3><a class="toc-backref" href="#id18" role="doc-backlink">What software is available on Clear Linux OS?</a><a class="headerlink" href="#what-software-is-available-on-cl" title="Link to this heading">¶</a></h3>
-<p>Available software can be found in the <a class="reference external" href="https://clearlinux.org/software">Software Store</a>, through the GNOME*
-Software application on the desktop, or by using <a class="reference internal" href="../guides/clear/swupd.html#swupd-quick-ref"><span class="std std-ref">swupd search</span></a>.</p>
-<div class="line-block">
-<div class="line"><br /></div>
-</div>
-</section>
-<section id="is-google-chrome-available">
-<h3><a class="toc-backref" href="#id19" role="doc-backlink">Is Google* Chrome* available?</a><a class="headerlink" href="#is-google-chrome-available" title="Link to this heading">¶</a></h3>
-<p>The Google Chrome web browser is not distributed as a bundle in Clear Linux OS due to
-copyright and licensing complexities.</p>
-<p>A <a class="reference external" href="https://github.com/clearlinux/distribution/issues/422">discussion on manually installing and maintaining Google Chrome</a> can be found on
-GitHub.</p>
-<div class="line-block">
-<div class="line"><br /></div>
-</div>
-</section>
-<section id="is-microsoft-visual-studio-code-available">
-<h3><a class="toc-backref" href="#id20" role="doc-backlink">Is Microsoft* Visual Studio Code* available?</a><a class="headerlink" href="#is-microsoft-visual-studio-code-available" title="Link to this heading">¶</a></h3>
-<p>Yes. Find the CLI command for installing <a class="reference external" href="https://clearlinux.org/software?search_api_fulltext=vscode">VS Code</a> and other Flatpak apps in
-the <a class="reference external" href="https://clearlinux.org/software">software store</a>. Installing Flatpak apps is also covered in our
-<a class="reference internal" href="../tutorials/flatpak.html#flatpak-tutorial"><span class="std std-ref">tutorial</span></a>.</p>
-<p>The Clear Linux OS team is working on a natively packaged version of Visual Studio Code
-for future release.</p>
-<p>Join a community <a class="reference external" href="https://community.clearlinux.org/t/need-native-support-for-vs-code-through-swupd/">forum discussion about manually installing and maintaining
-Visual Studio Code</a>.</p>
-<div class="line-block">
-<div class="line"><br /></div>
-</div>
-</section>
-<section id="is-ffmpeg-available">
-<span id="licensing-restrict"></span><h3><a class="toc-backref" href="#id21" role="doc-backlink">Is FFmpeg available?</a><a class="headerlink" href="#is-ffmpeg-available" title="Link to this heading">¶</a></h3>
-<p><a class="reference external" href="https://ffmpeg.org/">FFmpeg</a> is a multimedia software suite, which is commonly used for
-various media encoding/decoding, streaming, and playback.</p>
-<p>Clear Linux OS does not distribute FFmpeg due to well-known licensing and legal
-complexities (See <a class="reference external" href="https://www.ffmpeg.org/legal.html">https://www.ffmpeg.org/legal.html</a> and
-<a class="reference external" href="http://blog.pkh.me/p/13-the-ffmpeg-libav-situation.html">http://blog.pkh.me/p/13-the-ffmpeg-libav-situation.html</a>).</p>
-<p>While Clear Linux OS cannot distribute FFmpeg, solutions for manually building and
-installing FFmpeg have been shared by users <a class="reference external" href="https://github.com/clearlinux/distribution/issues/429">on GitHub</a> and <a class="reference external" href="https://community.clearlinux.org/t/how-to-h264-etc-support-for-firefox-including-ffmpeg-install">the community
-forums</a>.</p>
-<div class="line-block">
-<div class="line"><br /></div>
-</div>
-</section>
-<section id="is-zfs-available">
-<h3><a class="toc-backref" href="#id22" role="doc-backlink">Is ZFS* available?</a><a class="headerlink" href="#is-zfs-available" title="Link to this heading">¶</a></h3>
-<p>ZFS is not available with Clear Linux OS because of copyright and licensing
-complexities. BTRFS is an alternative filesystem that is available in Clear Linux OS
-natively.</p>
-<p>A community contributed tutorial has been shared on how to <a class="reference internal" href="../tutorials/zfs.html#zfs"><span class="std std-ref">manually
-install ZFS</span></a>.</p>
-<div class="line-block">
-<div class="line"><br /></div>
-</div>
-</section>
-<section id="can-you-add-a-driver-that-i-need">
-<h3><a class="toc-backref" href="#id23" role="doc-backlink">Can you add a driver that I need?</a><a class="headerlink" href="#can-you-add-a-driver-that-i-need" title="Link to this heading">¶</a></h3>
-<p>If a kernel module is available as part of the Linux kernel source tree but
-not enabled in the Clear Linux OS kernels, in many cases the Clear Linux OS team will enable it
-upon request. Submit requests on GitHub here:
-<a class="reference external" href="https://github.com/clearlinux/distribution/issues">https://github.com/clearlinux/distribution/issues</a></p>
-<p>The Clear Linux OS team does not typically add out-of-tree kernel modules as a matter of
-practice because of the maintenance overhead. If the driver was unable to be
-merged upstream, there is a good chance we may be unable to merge it for
-similar reasons.</p>
-<p>Kernel modules can be individually built and installed on Clear Linux OS. See the
-<a class="reference internal" href="../guides/kernel/kernel-modules.html#kernel-modules"><span class="std std-ref">kernel modules</span></a> page for more information.</p>
-<div class="line-block">
-<div class="line"><br /></div>
-</div>
-</section>
-</section>
-</section>
-
-
-            <div class="clearer"></div>
-          </div>
-        </div>
-      </div>
-      <div class="sphinxsidebar" role="navigation" aria-label="Main">
-        <div class="sphinxsidebarwrapper">
-            <p class="logo"><a href="../index.html">
-              <img class="logo" src="../_static/clearlinux.png" alt="Logo of Clear Linux* Project Docs"/>
-            </a></p>
-  <div>
-    <h3><a href="../index.html">Table of Contents</a></h3>
-    <ul>
-<li><a class="reference internal" href="#">FAQ</a><ul>
-<li><a class="reference internal" href="#general">General</a><ul>
-<li><a class="reference internal" href="#what-is-cl">What is Clear Linux OS?</a></li>
-<li><a class="reference internal" href="#why-another-linux-distribution">Why another Linux distribution?</a></li>
-<li><a class="reference internal" href="#is-it-a-derivative-of-another-linux-distribution">Is it a derivative of another Linux distribution?</a></li>
-<li><a class="reference internal" href="#can-others-copy-improvements-from-cl">Can others copy improvements from Clear Linux OS?</a></li>
-<li><a class="reference internal" href="#how-often-does-it-update">How often does it update?</a></li>
-<li><a class="reference internal" href="#is-telemetry-required">Is telemetry required?</a></li>
-<li><a class="reference internal" href="#what-is-the-default-firewall">What is the default firewall?</a></li>
-<li><a class="reference internal" href="#where-are-the-files-that-i-usually-see-under-etc-like-fstab">Where are the files that I usually see under /etc like fstab?</a></li>
-<li><a class="reference internal" href="#does-it-use-the-intel-compiler-icc">Does it use the Intel Compiler (icc)?</a></li>
-</ul>
-</li>
-<li><a class="reference internal" href="#software">Software</a><ul>
-<li><a class="reference internal" href="#how-is-software-installed-and-updated">How is software installed and updated?</a></li>
-<li><a class="reference internal" href="#does-it-use-rpms-or-debs-packages-like-other-distros">Does it use RPMs or DEBs packages like other distros?</a></li>
-<li><a class="reference internal" href="#why-does-it-have-a-different-approach-to-software-management">Why does it have a different approach to software management?</a></li>
-<li><a class="reference internal" href="#can-i-install-a-software-package-from-another-os-on-cl">Can I install a software package from another OS on Clear Linux OS?</a></li>
-</ul>
-</li>
-<li><a class="reference internal" href="#software-availability">Software availability</a><ul>
-<li><a class="reference internal" href="#what-software-is-available-on-cl">What software is available on Clear Linux OS?</a></li>
-<li><a class="reference internal" href="#is-google-chrome-available">Is Google* Chrome* available?</a></li>
-<li><a class="reference internal" href="#is-microsoft-visual-studio-code-available">Is Microsoft* Visual Studio Code* available?</a></li>
-<li><a class="reference internal" href="#is-ffmpeg-available">Is FFmpeg available?</a></li>
-<li><a class="reference internal" href="#is-zfs-available">Is ZFS* available?</a></li>
-<li><a class="reference internal" href="#can-you-add-a-driver-that-i-need">Can you add a driver that I need?</a></li>
-</ul>
-</li>
-</ul>
-</li>
-</ul>
-
-  </div>
-  <div>
-    <h4>Previous topic</h4>
-    <p class="topless"><a href="../reference/tutorial-ratings.html"
-                          title="previous chapter">Tutorial difficulty ratings</a></p>
-  </div>
-  <div>
-    <h4>Next topic</h4>
-    <p class="topless"><a href="../collaboration/collaboration.html"
-                          title="next chapter">Contribute</a></p>
-  </div>
-  <div role="note" aria-label="source link">
-    <h3>This Page</h3>
-    <ul class="this-page-menu">
-      <li><a href="../_sources/FAQ/index.rst.txt"
-            rel="nofollow">Show Source</a></li>
-    </ul>
-   </div>
-<search id="searchbox" style="display: none" role="search">
-  <h3 id="searchlabel">Quick search</h3>
-    <div class="searchformwrapper">
-    <form class="search" action="../search.html" method="get">
-      <input type="text" name="q" aria-labelledby="searchlabel" autocomplete="off" autocorrect="off" autocapitalize="off" spellcheck="false"/>
-      <input type="submit" value="Go" />
-    </form>
-    </div>
-</search>
-<script>document.getElementById('searchbox').style.display = "block"</script>
-        </div>
-      </div>
-      <div class="clearer"></div>
-    </div>
-    <div class="related" role="navigation" aria-label="Related">
-      <h3>Navigation</h3>
-      <ul>
-        <li class="right" style="margin-right: 10px">
-          <a href="../genindex.html" title="General Index"
-             >index</a></li>
-        <li class="right" >
-          <a href="../collaboration/collaboration.html" title="Contribute"
-             >next</a> |</li>
-        <li class="right" >
-          <a href="../reference/tutorial-ratings.html" title="Tutorial difficulty ratings"
-             >previous</a> |</li>
-        <li class="nav-item nav-item-0"><a href="../index.html">Documentation for Clear Linux* project</a> &#187;</li>
-        <li class="nav-item nav-item-this"><a href="">FAQ</a></li> 
-      </ul>
-    </div>
-    <div class="footer" role="contentinfo">
-    &#169; Copyright 2022 Intel Corporation. All Rights Reserved..
-      Last updated on Nov 04, 2024.
-      Created using <a href="https://www.sphinx-doc.org/">Sphinx</a> 8.1.3.
-    </div>
-  </body>
-</html>
@@ -0,0 +1,39 @@
+# Makefile for Sphinx documentation
+
+SHELL := /bin/bash
+
+PY_VERSION ?= 3.6
+
+all:
+	make -C source html
+
+htmlall:
+	make -C source htmlall
+
+htmlzh:
+	make -C source htmlzh
+
+htmlde:
+	make -C source htmlde
+
+html:
+	make -C source html
+
+linkcheck:
+	make -C source linkcheck
+
+py:
+	make -C source py
+
+help:
+	@echo "Please use \`make <target>' where <target> is one of"
+	@echo "  html       to make standalone HTML files"
+
+clean:
+	make -C source clean
+	rm -rf venv
+
+venv:
+	virtualenv venv;\
+	source venv/bin/activate; \
+	pip3 install -r requirements.txt;
@@ -0,0 +1,184 @@
+Documentation build instructions
+################################
+
+.. todo add comment re not using standards here.
+
+`Clear Linux\* OS documentation`_ is written using `reStructuredText`_ and
+built using `Sphinx`_. Follow the instructions in this README to build the
+documentation locally for development and testing.
+
+Please make yourself familiar with our `contribution guidelines`_ before
+submitting a contribution.
+
+Clone the documentation repository
+**********************************
+
+Clone the documentation repository to your local machine.
+
+.. code-block:: bash
+
+   git clone https://github.com/clearlinux/clear-linux-documentation
+
+Requirements
+************
+
+Make sure you have Python 3 installed to start.
+
+The Sphinx documentation provides `instructions for installing Sphinx`_
+on various platforms.
+
+Use pip3 to install additional Python dependencies listed in the
+requirements.txt file found in the repository:
+
+.. code-block:: bash
+
+   pip3 install -r requirements.txt
+
+Run the build
+*************
+
+We build our documentation using Sphinx. In the source directory of your
+local clear-linux-documentation repository, preview changes to the
+documentation by building the docs in the default language (English) by
+running ``make html``:
+
+.. code-block:: bash
+
+   make html
+
+.. code-block:: console
+
+   sphinx-build -b html -d _build/doctrees   . _build/html
+   Running Sphinx v1.8.0
+   making output directory...
+   .
+   .
+   .
+   build succeeded, 0 warnings.
+
+   The HTML pages are in _build/html.
+
+   Build finished. The HTML pages are in _build/html.
+
+Open one of the HTML pages found in ``source/_build/html`` in a web browser
+to view the rendered documentation.
+
+If you want to build the documentation exactly as seen on the website, use
+``make py`` followed by ``make htmlall``. This builds some
+external dependencies and all supported languages.
+
+Use virtualenv 
+**************
+
+To develop documentation in a ``virtualenv``, use the ``venv`` target.
+The Clear Linux OS documentation make target ``venv`` provides a 
+simple development environment that ensures that you have the 
+latest packages and that you manage Python versions separately. Use of the 
+``virtualenv`` requires **Python 3.6** or higher. For Windows examples below, use Powershell as an Administrator.
+
+The **virtual environment** uses the same version of Python that was used to **create the virtual environment**. 
+
+Verify ``pip`` is installed. A file path to pip should appear. 
+
+On Clear Linux OS and macOS\*:
+
+.. code-block:: bash
+
+   which pip
+   
+On Windows\* 10 OS: 
+
+.. code-block:: bash
+
+   pip --version
+
+If ``pip`` is not installed, install it. 
+
+On Clear Linux OS and macOS:
+
+.. code-block:: bash
+
+   python3 -m pip install --user --upgrade pip
+
+On Windows 10 OS: 
+
+.. code-block:: bash
+
+   py -m pip install --upgrade pip
+
+.. note::
+
+   This assumes Python was already added to your Windows path. 
+
+Install virtualenv 
+==================
+
+Install ``virtualenv``. 
+
+On Clear Linux OS and macOS\*:
+
+.. code-block:: bash
+
+   python3 -m pip install --user virtualenv
+
+On Windows 10 OS: 
+
+.. code-block:: bash
+
+   py -m pip install --user virtualenv
+
+Create the ``virtualenv`` and install the required packages: 
+
+.. code-block:: bash
+
+   make venv
+
+Activate the ``venv``. 
+
+.. code-block:: bash
+
+   source venv/bin/activate
+
+Follow `Run the build`_ section to start developing documentation.
+
+Remove the ``venv`` when finished developing.  
+
+.. code-block:: bash
+
+   deactivate
+
+Additional help
+***************
+
+Cleaning up
+===========
+
+When testing changes in the documentation, make sure to remove the previous
+build before building again by running ``make clean``:
+
+.. code-block:: bash
+
+   make clean
+
+This will completely remove the previous build output, including artifacts 
+from the `make venv` target when done outside an active venv.
+
+Convenience script
+==================
+
+This bash script (Linux only) includes both ``make clean`` and
+``make html``. It also starts a simple Python web server that
+displays a preview of the site at http://localhost:8000 on your local machine.
+
+.. code-block:: bash
+
+   ./checkwork.sh
+
+To stop the web server simply use ``ctrl-c``.
+
+.. _Clear Linux\* OS documentation:  https://docs.01.org/clearlinux/
+.. _Sphinx: http://sphinx-doc.org/
+.. _reStructuredText: http://www.sphinx-doc.org/en/master/usage/restructuredtext/basics.html
+.. _contribution guidelines: https://docs.01.org/clearlinux/latest/collaboration/collaboration.html
+.. _instructions for installing Sphinx: https://www.sphinx-doc.org/en/master/usage/installation.html
+
@@ -1,311 +0,0 @@
-.. _about:
-
-About
-#####
-
-|CL-ATTR| does things differently. Our software architecture provides a
-unique and innovative platform for Linux* developers focused on
-performance and security for compute, server, and the cloud.
-
-.. contents::
-   :local:
-   :depth: 1
-
-What is |CL|?
-*************
-
-|CL| is an open source, rolling-release Linux distribution, optimized for
-performance and security from the cloud to the Edge. Designed from the ground up,
-|CL| provides an industry blueprint on how to incorporate Intel® architecture
-features for a modern, modular Linux OS. |CL| is not based on any other Linux
-distro.
-
-What |CL| isn't?
-****************
-
-|CL| is not intended to be a general-purpose Linux distribution, suitable 
-for novice end-users. While we ship common applications, our purpose isn’t 
-to make an OS for routine desktop tasks and provide immunity from all 
-security threats in all situations. Our unique focus means that what we consider *essential* use cases, *optional* use cases, or even *unsupported* use cases, differs from other Linux distros. See our :ref:`target audience <target-audience>` below. 
-
-Is |CL| completely Open Source?
-*******************************
-
-|CL| aims to be completely open source. Our project `source code`_ and 
-`packages source code`_ are available on GitHub\*. When considering projects 
-for inclusion, we check that they are in active development and are well 
-maintained. We have a very strict requirement for not accepting proprietary 
-packages and non-open source components.  For example, many Linux distros 
-may not be able to include certain media codecs due to 
-:ref:`licensing restrictions <licensing_restrict>`, but manual installation and `third party alternatives`_ are available. 
-
-.. _target-audience:
-
-Who is the target audience?
-***************************
-
-|CL| mainly targets professionals in IT, DevOps, Cloud/Container deployments, and :abbr:`AI (Artificial Intelligence)`. 
-
-Rather than making a standard Linux distribution, the |CL| team decided to
-build a unique Linux distro. Developing a distro in house allows us to experiment and iterate faster, which means we continually optimize performance and deliver security patches, :ref:`several times per week <release-cadence>`. Yet our experiments are only valuable if our software architecture gives you the freedom to innovate, too. To improve manageability, |CL| employs a :ref:`stateless` design, separating user and system management.  
-
-We leverage the pool of knowledge and skills at Intel to drive improvements to |CL|.
-
-Intel has worked with the Linux community and other distros for many years.
-Understanding what it takes to integrate features in our own Linux distro
-helps us collaborate with other distro owners and submit enhancements to
-upstream. We demonstrate the value of our distro by offering users the same
-tools we use. For example, :ref:`mixer`, a tool unique to |CL|, allows users
-to build custom derivatives and act as their own :abbr:`OSV (Operating System
-Vendor)`. 
-
-For more details on |CL| features, visit our :ref:`cl-guides` guides.
-
-How does |CL| address security?
-*******************************
-
-Several :ref:`security features <security>` are designed to work 
-out-of-the-box, yet they're not intended to be intrusive. We focus on 
-*essential* use cases and ignore *unwanted* or *unsupported* use cases. 
-For example, while |CL| does not enable antivirus by default, we provide a 
-bundle for it (``clamav``). We leave antivirus configuration to our users.  
-In addition, firewalls are less important if the OS doesn’t expose services 
-to the outside by default. In |CL|, we enforce this strategy by disabling 
-network services by default - e.g. ``mariadb`` listens on a UNIX socket; 
-``nginx`` won’t listen at all; and other services similarly are restricted 
-from being accessed over the network. This strategy alone makes firewall 
-software much less urgent--there simply isn’t anything that a firewall could 
-easily block.
-
-What’s the thinking around Server vs. Desktop?
-**********************************************
-
-|CL| focuses on performance for server and cloud use-cases first because 
-many design decisions associated with them are applicable to other 
-use-cases, such as IoT and the desktop client. While our initial focus was 
-on the command line, we realized that many people valued the ease-of-use of 
-a desktop environment.  Whereas in the past we tried to accommodate those 
-interested in a desktop version, we were forced to confront clear limits as
-to how we could meet this need. |CL| minimizes the customizations and patches in support of the desktop and provides a generic GNOME implementation. Other window managers or desktops are available; however, testing in |CL| is focused on GNOME. 
-
-What makes |CL| different?
-**************************
-
-.. _release-cadence:
-
-Release Cadence
-===============
-
-|CL| updates are based on a rolling release that can occur daily, up to a few
-times per week. Each release has a unique version number that identifies
-every component in the OS from kernel, to driver, to tool, to GUI
-application. Most components are included in entities called :ref:`bundles<bundles>`.
-
-Updates
-=======
-
-By default, |CL| automatically checks for updates, ensuring the latest
-performance and security fixes are installed as soon as they are available.
-|CL| stays in lockstep with upstream for current security upgrades and is 
-designed to rapidly deliver security mitigations to customers.
-:ref:`swupd-guide` is designed to manage updates and bundles.
-
-Ease of Use 
-===========
-
-|CL| makes it easier to manage a number of difficult problems.
-
-* :ref:`autoproxy` makes it possible for |CL| tools to operate in some proxy
-  environments without needing to be configured.
-
-* :ref:`stateless` means that configuration settings are easier to manage
-  and remain untouched when system software is updated.
-
-* :ref:`swupd-guide` simplifies managing software and maintaining
-  compatibility.
-
-Custom Derivatives
-==================
-
-The same tools used to build the |CL| are available *in* the OS. These tools can be used to create a custom distribution that continues to benefit from upstream rolling releases.
-
-.. figure:: /_figures/about/clear-lifecycle.png
-   :scale: 75%
-   :align: center
-   :alt: Creating and managing a Clear Linux* OS  version (or derivative)
-
-   Figure 1: Creating and managing a Clear Linux\* OS version (or derivative)
-
-Create
-======
-
-To create a custom distribution you need to understand how to use the
-:ref:`autospec` and :ref:`mixer` tools. Additional training materials are available in the `how-to-clear`_ GitHub project to help you get started with |CL| tools.
-
-Deploy
-======
-
-We also provide training on how to :ref:`deploy-at-scale`.
-
-Administrate
-============
-
-|CL| provides a :ref:`telem-guide` solution for collecting useful information
-about a deployment, as well as :ref:`debug` capabilities.
-
-Why create new components rather than modifying existing projects?
-******************************************************************
-
-One question that's often asked: “Why did you develop your own solution 
-instead of using <XYZ>?” (e.g. `swupd post`_).  We do evaluate existing 
-projects for inclusion in |CL|, yet there are cases where our unique 
-architecture and components would require too much customization to use 
-off-the-shelf projects.  In other situations, we may feel that using a new 
-language to develop the component would give us a performance advantage, 
-ease code development and maintenance, and grow the skills of our engineers 
-on new and upcoming programming languages.  And yes, sometimes there are 
-personal biases for and against some projects by the architects and 
-engineers.  We tend to move fast, and sometimes it’s easier to live with 
-suboptimal choices until we have the time or incentive to re-architect them 
-properly. 
-
-Which Components are used in Clear Linux?
-*****************************************
-
-.. list-table::
-   :widths: 33,33,33
-   :header-rows: 1
-
-   * - Component
-     - Enabled in OS/Bundle
-     - Optional
-
-   * - OS Installer
-     - `Clear Linux installer`_
-     - 
-
-   * - Bootloader
-     - `systemd-boot`_ (UEFI) / `syslinux`_ (Legacy)
-     - 
-
-   * - Boot Manager
-     - `Clear Linux Boot Manager`_
-     - 
-
-   * - Configuration initialization and management
-     - *NA*
-     - `micro-config-drive`_ (minimal cloud-init), Ansible
-
-   * - Software component installer, manager, updater
-     - `swupd`_
-     - 
-
-   * - Software bundle generator - 
-     - `mixer`_ and `Clear Linux Distro Factory`_
-     - 
-
-   * - Software package builder
-     - `autospec`_
-     - 
-
-   * - Software debugging
-     - *NA*
-     - `clr-debug-info`_ 
-
-   * - Unified TLS Trust Store Management
-     - `clrtrust`_
-     - 
-
-   * - System and software telemetry
-     - *NA*
-     - `Telemetrics`_ (disabled by default)
-
-   * - File system
-     - `EXT4`_ (default for rootfs), `VFAT`_, `EXT2 and EXT3`_, `F2FS`_
-     - 
-
-   * - Disk encryption
-     - *NA*
-     - `LUKS`_ 
-
-   * - System /Service manager  
-     - `systemd`_
-     - 
-
-   * - Display manager 
-     - `GNOME`_
-     - ``KDE``, ``Xfce``, ``lightdm``, ``sddm``  (see `Clear Linux store`_)
-
-   * - Display services (Desktop installed)
-     - `X.Org`_
-     - `Wayland`_ compositor
-
-   * - Network services
-     - `NetworkManager`_ by default, `systemd-networkd`_ See Note below.
-     - 
-
-   * - SSH Port scanning blocker
-     - `Tallow`_
-     - 
-
-   * - Firewall
-     - *NA*
-     - iptables and `firewalld`_
-
-   * - Antivirus
-     - *NA*
-     - `ClamAV*`_
-
-   * - Web browser
-     - `Lynx`_ or `links`_ for text environments, `Firefox*`_ for GUI
-     - 
-
-   * - Additional Software
-     - `Supplied Bundles`_
-     - Flatpak, 3rd-party software bundles
-
-.. note::
-   
-   The |CL| OS images targeted for cloud deployments continue to use
-   ``systemd-networkd`` to manage network connections.  In earlier |CL|, 
-   ``systemd-networkd`` was used to manage Ethernet interfaces and NetworkManager was used for wireless interfaces.
-
-
-*Intel and the Intel logo are trademarks of Intel Corporation or its subsidiaries.*
-
-.. _third party alternatives: https://community.clearlinux.org/t/about-the-3rd-party-sw-category/4072
-.. _how-to-clear: https://github.com/clearlinux/how-to-clear
-.. _Clear Linux store: https://clearlinux.org/software
-.. _source code: https://github.com/clearlinux
-.. _swupd post: https://community.clearlinux.org/t/why-does-clearlinux-use-swupd-and-not-apt-deb-rpm/
-.. _swupd: https://github.com/clearlinux/swupd-client
-.. _Clear Linux installer: https://github.com/clearlinux/clr-installer/
-.. _systemd-boot: https://www.freedesktop.org/software/systemd/man/systemd-boot.html
-.. _syslinux: https://wiki.syslinux.org/wiki/index.php?title=The_Syslinux_Project
-.. _Clear Linux Boot Manager: https://github.com/clearlinux/clr-boot-manager
-.. _mixer: https://github.com/clearlinux/mixer-tools
-.. _Clear Linux Distro Factory: https://github.com/clearlinux/clr-distro-factory
-.. _autospec: https://github.com/clearlinux/common
-.. _clr-debug-info: https://github.com/clearlinux/clr-debug-info
-.. _clrtrust: https://github.com/clearlinux/clrtrust
-.. _EXT4: https://ext4.wiki.kernel.org/index.php/Main_Page
-.. _VFAT: https://www.kernel.org/doc/html/latest/filesystems/vfat.html
-.. _EXT2 and EXT3: https://ext4.wiki.kernel.org/index.php/Main_Page
-.. _F2FS: https://www.kernel.org/doc/Documentation/filesystems/f2fs.txt
-.. _LUKS: https://gitlab.com/cryptsetup/cryptsetup/
-.. _systemd: https://www.freedesktop.org/wiki/Software/systemd/
-.. _GNOME: https://www.gnome.org/
-.. _X.Org: https://www.x.org/
-.. _Wayland: https://wayland.freedesktop.org/
-.. _NetworkManager: https://wiki.gnome.org/Projects/NetworkManager
-.. _systemd-networkd: https://www.freedesktop.org/software/systemd/man/systemd.network.html
-.. _Tallow: https://github.com/clearlinux/tallow
-.. _firewalld: https://docs.01.org/clearlinux/latest/guides/network/firewall.html#firewalld
-.. _ClamAV*: https://www.clamav.net/
-.. _Lynx: https://lynx.invisible-island.net/
-.. _links: http://links.twibright.com/
-.. _Firefox*: https://www.mozilla.org/en-US/firefox/
-.. _Supplied Bundles: https://clearlinux.org/software
-.. _micro-config-drive: https://github.com/clearlinux/micro-config-drive
-.. _Telemetrics: https://github.com/clearlinux/telemetrics-backend
-.. _packages source code: https://github.com/clearlinux-pkgs/
@@ -1,511 +0,0 @@
-.. _import-clr-aws:
-
-Import Clear Linux Image and Launch Instance on AWS
-###################################################
-
-Clear Linux is available on the AWS marketplace.  However, it may not 
-be the latest version because we only update the marketplace on a 
-periodic basis, as often as weekly or but maybe monthly as well.  
-If you want to use the latest release from us or upload your own 
-custom image, follow this guide.  
-
-.. contents::
-   :local:
-   :depth: 1
-
-Prerequisites
-*************
-
-* You are familiar with AWS and how to use it
-
-Download or create a |CL| image for AWS
-***************************************
-
-Obtain an AWS |CL| image using one of these methods.  
-
-Download pre-built image
-========================
-#. Go to the `Downloads`_ page and download the 
-   *Amazon\* Web Services (AWS)* image.
-
-#. Uncompress it.  
-
-Create a custom image using clr-installer
-=========================================
-#. On a |CL| system, open a terminal.
-
-#. Install the `clr-installer` bundle.
-
-   .. code-block:: bash
-
-      sudo swupd bundle-add clr-installer
-
-#. Download a sample `aws.yaml`_ configuration file. 
-
-#. Make changes to the configuration file as needed.
-   See `Installer YAML Syntax`_ for more information on clr-installer 
-   configuration YAML syntax.
-
-#. Download the `AWS image post-install script`_ and make it executable.
-
-#. Produce an image with clr-installer.
-
-   .. code-block:: bash
-      
-      clr-installer --template $PWD/aws.yaml
-
-Create an S3 bucket
-*******************
-
-#. Log into AWS.
-
-#. Go to :guilabel:`Services`, :guilabel:`Storage`, and select :guilabel:`S3`.
-   See Figure 1. 
-
-   .. figure:: ../../_figures/aws/import-clr-aws-01.png
-      :scale: 70%
-      :alt: AWS Services - S3 Management Console
-
-      Figure 1: AWS Services - S3 Management Console
-
-#. Click :guilabel:`+ Create bucket`.
-
-   .. figure:: ../../_figures/aws/import-clr-aws-02.png
-      :scale: 70%
-      :alt: AWS S3 - Create bucket
-
-      Figure 2: AWS S3 - Create bucket
-
-#. Set a bucket name and select a region.  
-   See Figure 3.
-
-   .. figure:: ../../_figures/aws/import-clr-aws-03.png
-      :scale: 70%
-      :alt: AWS S3 - Create bucket - Set bucket name and region
-
-      Figure 3: AWS S3 - Create bucket - Set bucket name and region
-
-#. Leave the :guilabel:`Configure options` and :guilabel:`Set permissions`
-   settings as is or configure as desired.  See Figure 4 and 5.
-
-   .. figure:: ../../_figures/aws/import-clr-aws-04.png
-      :scale: 70%
-      :alt: AWS S3 - Create bucket - Configure options
-
-      Figure 4: AWS S3 - Create bucket - Configure options
-
-   .. figure:: ../../_figures/aws/import-clr-aws-05.png
-      :scale: 70%
-      :alt: AWS S3 - Create bucket - Set permissions
-
-      Figure 5: AWS S3 - Create bucket - Set permissions
-
-#. At the :guilabel:`Review` screen, click :guilabel:`Create bucket`.
-
-   .. figure:: ../../_figures/aws/import-clr-aws-06.png
-      :scale: 70%
-      :alt: AWS S3 - Create bucket - Review
-
-      Figure 6: AWS S3 - Create bucket - Review
-
-   The created bucket should appear.  See Figure 7.
-
-   .. figure:: ../../_figures/aws/import-clr-aws-07.png
-      :scale: 70%
-      :alt: AWS S3 - Created bucket
-
-      Figure 7: AWS S3 - Created bucket
-
-Upload the |CL| image into the bucket
-*************************************
-
-#. Click on the bucket.
-   See Figure 8.
-
-   .. figure:: ../../_figures/aws/import-clr-aws-08.png
-      :scale: 70%
-      :alt: AWS S3 - Select bucket
-
-      Figure 8: AWS S3 - Select bucket
-
-#. Click :guilabel:`Upload`.
-   See Figure 9.
-
-   .. figure:: ../../_figures/aws/import-clr-aws-09.png
-      :scale: 70%
-      :alt: AWS S3 - Upload
-
-      Figure 9: AWS S3 - Upload
-
-#. Click :guilabel:`Add files` and select the |CL| image file to upload.
-   See Figure 10.
-
-   .. figure:: ../../_figures/aws/import-clr-aws-10.png
-      :scale: 70%
-      :alt: AWS S3 - Add files
-
-      Figure 10: AWS S3 - Add files
-
-#. Click :guilabel:`Next`.  Leave remaining settings as is or set as desired.
-   See Figure 11, Figure 12, and Figure 13.
-
-   .. figure:: ../../_figures/aws/import-clr-aws-11.png
-      :scale: 70%
-      :alt: AWS S3 - Add files
-
-      Figure 11: AWS S3 - Add files
-
-   .. figure:: ../../_figures/aws/import-clr-aws-12.png
-      :scale: 70%
-      :alt: AWS S3 - Set permissions
-
-      Figure 12: AWS S3 - Set permissions
-
-   .. figure:: ../../_figures/aws/import-clr-aws-13.png
-      :scale: 70%
-      :alt: AWS S3 - Set properties
-
-      Figure 13: AWS S3 - Set properties
-
-#. Click :guilabel:`Upload` to upload the image.
-   See Figure 14.
-
-   .. figure:: ../../_figures/aws/import-clr-aws-14.png
-      :scale: 70%
-      :alt: AWS S3 - Upload
-
-      Figure 14: AWS S3 - Upload
-
-Add a user to IAM with AWS_CLI privilege
-****************************************
-
-#. Go to :guilabel:`Services`, :guilabel:`Security, Identity, & Compliance`,
-   and select :guilabel:`IAM`.
-   See Figure 15. 
-
-   .. figure:: ../../_figures/aws/import-clr-aws-15.png
-      :scale: 70%
-      :alt: AWS Services - IAM
-
-      Figure 15: AWS Services - IAM
-
-#. On the left navigation bar under :guilabel:`Access management`, 
-   select :guilabel:`Users`.
-   See Figure 16.
-
-   .. figure:: ../../_figures/aws/import-clr-aws-16.png
-      :scale: 70%
-      :alt: AWS AIM - Access management
-
-      Figure 16: AWS AIM - Access management
-
-#. Click :guilabel:`Add user`.
-   See Figure 17.
-   
-   .. figure:: ../../_figures/aws/import-clr-aws-17.png
-      :scale: 70%
-      :alt: AWS AIM - Add user
-
-      Figure 17: AWS AIM - Add user
-
-#. Under the :guilabel:`Set user details` section, enter a user name.
-   See Figure 18.
-
-   .. figure:: ../../_figures/aws/import-clr-aws-18.png
-      :scale: 70%
-      :alt: AWS AIM - Enter user name and select access type
-
-      Figure 18: AWS AIM - Enter user name and select access type
-
-#. Under the :guilabel:`Select AWS access type` section, 
-   checkmark :guilabel:`Programmatic access`.
-   See Figure 18.
-
-#. Click :guilabel:`Next: Permissions`.
-
-#. Under :guilabel:`Set permissions`, select :guilabel:`Add user to group`.
-   See Figure 19.
-
-   .. figure:: ../../_figures/aws/import-clr-aws-19.png
-      :scale: 70%
-      :alt: AWS AIM - Set user permissions
-
-      Figure 19: AWS AIM - Set user permissions
-
-#. Under :guilabel:`Add user to group`, enter `AWS_CLI` into search window.
-   Checkmark :guilabel:`AWS_CLI`.
-   See Figure 19.
-
-#. Click :guilabel:`Next: Tags`.
-
-#. Click :guilabel:`Next: Review`.
-
-#. Click :guilabel:`Create user`.
-   See Figure 20.
-
-   .. figure:: ../../_figures/aws/import-clr-aws-20.png
-      :scale: 70%
-      :alt: AWS AIM - Create user
-
-      Figure 20: AWS AIM - Create user
-
-#. After the user is successfully added, save the :guilabel:`Access key ID`
-   and the :guilabel:`Secret access key`.  These will be used when setting up
-   the AWS CLI tool at a later step.
-   See Figure 21.
-
-   .. figure:: ../../_figures/aws/import-clr-aws-21.png
-      :scale: 70%
-      :alt: AWS AIM - Access key ID and secret access key
-
-      Figure 21: AWS AIM - Access key ID and secret access key
-
-#. Click :guilabel:`Close`.
-
-Install and configure the AWS CLI tool on your system
-*****************************************************
-
-#. To install the tool on |CL|, simply run:
-
-   .. code-block:: bash
-
-      sudo swupd bundle-add cloud-api
-
-   .. note:
-
-      If you are using a different OS, follow the 
-      `Installing the AWS CLI version 2`_ guide.
-
-#. Configure it with your security credentials, default region,
-   and default output format. See `Configuring the AWS CLI`_ for more information.
-
-   .. code-block:: bash
-
-      aws configure
-
-   Below is an example (using the security credentials that was created in 
-   the previous section):
-
-   .. code-block:: console
-
-      AWS Access Key ID [None]: AKIA5LEGQPQ3EUB3JMS7
-      AWS Secret Access Key [None]: EcvbWpWr+Gp7NhBoVEacwR3EifzN7xTTg8B1PHvO
-      Default region name [None]: us-west-2
-      Default output format [None]: json 
-
-#. Verify your credentials are good.
-
-   .. code-block:: bash
-      
-      aws iam list-access-keys
-
-   If you get something like the example below, then make sure you set your 
-   system date and time properly.
-
-   .. code-block:: console
-
-      An error occurred (SignatureDoesNotMatch) when calling the ListAccessKeys operation: Signature expired: 20200305T153154Z is now earlier than 20200305T231847Z (20200305T233347Z - 15 min.)
-
-Import a snapshot of the |CL| image
-***********************************
-
-#. Create a :file:`container.json` with the description of the image to import.
-   Specify the name of the S3 bucket that was created earlier for the 
-   `S3Bucket` field and the name of |CL| image that was uploaded to the S3 bucket
-   for the `S3Key`.
-
-   Here's an example:
-
-   .. code-block:: console
-
-      {
-        "Description": "My Clear Linux AWS 32400 Image",
-        "Format": "raw",
-        "UserBucket": {
-          "S3Bucket": "my-clearlinux-bucket",
-          "S3Key": "clear-32400-aws.img"
-        }
-      }
-
-#. Import a snapshot of the image.
-
-   .. code-block:: bash
-
-      aws ec2 import-snapshot \
-      --description "My Clear Linux AWS 32400 Snapshot" \
-      --disk-container file://container.json
-
-   You should get an output similar this example:
-
-   .. code-block:: console
-
-      {
-        "Description": "My Clear Linux AWS 32400 Snapshot",
-        "ImportTaskId": "import-snap-00fa9ccd98e9b8378",
-        "SnapshotTaskDetail": {
-            "Description": "My Clear Linux AWS 32400 Snapshot",
-            "DiskImageSize": 0.0,
-            "Format": "RAW",
-            "Progress": "3",
-            "Status": "active",
-            "StatusMessage": "pending",
-            "UserBucket": {
-                "S3Bucket": "my-clearlinux-bucket",
-                "S3Key": "clear-32400-aws.img"
-            }
-        }
-    }
-
-#. Using the `ImportTaskId` from the previous step, check the status 
-   of the import.  For example:
-
-   .. code-block:: bash
-
-      snapshot_id=$(aws ec2 describe-import-snapshot-tasks \
-      --import-task-ids "import-snap-00fa9ccd98e9b8378" \
-      | grep SnapshotId | awk -F '"' '{print $4}')
-
-   Wait for the `Status` field to show `completed` before proceeding.
-
-   The resulting `snapshot_id` will be used to create an AMI in 
-   the next section.
-
-Create an AMI from the snapshot
-*******************************
-
-There are 2 methods to create an AMI from the snapshot.
-
-* *AWS CLI Method*:
-    
-  .. code-block:: bash
-    
-     aws ec2 register-image \
-     --name "My-Clear-Linux-32400-AMI" \
-     --description "My Clear Linux 32400 AMI" \
-     --architecture x86_64 \
-     --virtualization-type hvm \
-     --ena-support \
-     --root-device-name "/dev/sda1" \
-     --block-device-mappings "[ 
-       { 
-         \”Deviceame\": \"/dev/sda1\", 
-         \"Ebs\": {
-           \"SnapshotId\": \"$snapshot_id\" 
-         } 
-       } 
-     ]"
-
-* *GUI Method*: 
-
-  #. Go to :guilabel:`Services`, :guilabel:`Compute`, and select 
-     :guilabel:`EC2`.
-     See Figure 22. 
-
-     .. figure:: ../../_figures/aws/import-clr-aws-22.png
-        :scale: 70%
-        :alt: AWS Services - EC2
-
-        Figure 22: AWS Services - EC2
-    
-  #. Click :guilabel:`Snapshots`.
-     See Figure 23. 
-
-     .. figure:: ../../_figures/aws/import-clr-aws-23.png
-        :scale: 70%
-        :alt: AWS Services - Snapshots
-
-        Figure 23: AWS Services - Snapshots
-
-  #. Locate the snaphot using the `Snapshot ID`.
-     See Figure 24.
-
-     .. figure:: ../../_figures/aws/import-clr-aws-24.png
-        :scale: 70%
-        :alt: AWS Services - Snapshots
-
-        Figure 24: AWS Services - Snapshots
-    
-  #. Right-click it and select :guilabel:`Create Image`.
-
-  #. Configure as follows:
- 
-     * Enter the name in the :guilabel:`Name` field
-     * Enter the description in the :guilabel:`Description` field
-     * Set the :guilabel:`Architecture` as `x86_64`
-     * Set the :guilabel:`Virtualization type` as `Hardware-assisted virtualization`
-     * Set the :guilabel:`Root device name` as `/dev/sda1`
-
-     See Figure 25.
-
-     .. figure:: ../../_figures/aws/import-clr-aws-25.png
-        :scale: 70%
-        :alt: AWS Services - Snapshots
-
-        Figure 25: AWS Services - Snapshots
-    
-  #. Click :guilabel:`Create`.
-
-Launch an instance
-******************
-
-#. Go to :guilabel:`Services`, :guilabel:`Compute`, and select 
-   :guilabel:`EC2`.
-   See Figure 26. 
-
-   .. figure:: ../../_figures/aws/import-clr-aws-26.png
-      :scale: 70%
-      :alt: AWS Services - EC2
-
-      Figure 26: AWS Services - EC2
-    
-#. Click the :guilabel:`Launch Instance` dropdown and select 
-   :guilabel:`Launch Instance`.
-   See Figure 27. 
-
-   .. figure:: ../../_figures/aws/import-clr-aws-27.png
-      :scale: 70%
-      :alt: AWS Services - Launch instance
-
-      Figure 27: AWS Services - Launch instance
-
-#. On the left navigation bar, select :guilabel:`My AMIs`.
-   See Figure 28. 
-
-   .. figure:: ../../_figures/aws/import-clr-aws-28.png
-      :scale: 70%
-      :alt: AWS Services - Select AMI
-
-      Figure 28: AWS Services - Select AMI
-
-#. Find your AMI and click :guilabel:`Select`.
-
-#. From here onward, configure the details of your instance as desired 
-   and launch it.
-   
-Connect to your |CL| instance
-*****************************
-
-#. Follow these steps to `connect to your instance`_.
-
-Related topics
-**************
-
-* :ref:`azure`
-* :ref:`gce`
-* :ref:`clr-digitalocean`
-
-.. _Downloads: 
-   https://clearlinux.org/downloads
-.. _aws.yaml: 
-   https://cdn.download.clearlinux.org/current/config/image/aws.yaml
-.. _AWS image post-install script:
-   https://cdn.download.clearlinux.org/current/config/image/aws-disable-root.sh
-.. _Installing the AWS CLI version 2: 
-   https://docs.aws.amazon.com/cli/latest/userguide/install-cliv2.html
-.. _Configuring the AWS CLI: 
-   https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html
-.. _connect to your instance: 
-   https://docs.01.org/clearlinux/latest/get-started/cloud-install/aws-web.html#connect-to-your-clear-linux-os-basic-instance
-.. _Installer YAML Syntax:
-   https://github.com/clearlinux/clr-installer/blob/master/scripts/InstallerYAMLSyntax.md
-
@@ -1,104 +0,0 @@
-.. _compatibility-check:
-
-Check Processor Compatibility
-#############################
-
-Before installing |CL-ATTR|, check your host system's processor compatibility using one of 
-the following options:
-
-.. note::
-   This does not check other system components (for example: storage and
-   graphics) for compatibility with |CL|.
-
-Option 1: Use the :command:`clear-linux-check-config.sh` script on an existing Linux system
-*******************************************************************************************
-
-#. Download the `clear-linux-check-config.sh`_ file.
-
-   If a browser is not available, use:
-
-   .. code-block:: bash
-
-      curl -O https://cdn.download.clearlinux.org/current/clear-linux-check-config.sh
-
-#. Make the script executable.
-
-   .. code-block:: bash
-
-      chmod +x clear-linux-check-config.sh
-
-#. Run the script.
-
-   #. Check to see if the host's processor is capable of running |CL|.
-
-      .. code-block:: bash
-
-         ./clear-linux-check-config.sh host
-
-   #. Check to see if the host is capable of running |CL| in a container.
-
-      .. code-block:: bash
-
-         ./clear-linux-check-config.sh container
-
-   The script prints a list of test results similar to the output below.
-   All items should return a `SUCCESS` status. This example indicates the
-   host's processor supports running |CL|.
-
-   .. code-block:: console
-
-      Checking if host is capable of running Clear Linux* OS
-
-      SUCCESS: 64-bit CPU (lm)
-      SUCCESS: Supplemental Streaming SIMD Extensions 3 (ssse3)
-      SUCCESS: Streaming SIMD Extension v4.1 (sse4_1)
-      SUCCESS: Streaming SIMD Extensions v4.2 (sse4_2)
-      SUCCESS: Carry-less Multiplication extensions (pclmulqdq)
-
-Option 2: Use a |CL| live image on a non-Linux system
-=====================================================
-
-#. `Download`_ either the `Desktop` or `Server` version of the live image ISO.
-
-#. Follow the instruction to :ref:`bootable-usb`.
-
-#. Boot up the |CL| live image on the USB.
-
-#. Check compatibility as follows:
-
-   * *Desktop version:*
-     
-     a. Open a terminal.
-
-     #. Check compatibility.
-
-        .. code-block:: bash
-
-	   sudo clr-installer --system-check
-
-   * *Server version:*
-
-     a. Log in as `root` and set a password.
-
-     #. Check compatibility.
-
-        .. code-block:: bash
-
-	   clr-installer --system-check
-
-   Expected output for a compatible host processor:
-
-   .. code-block:: console
-
-      Checking for required CPU feature: lm [success]
-      Checking for required CPU feature: sse4_2 [success]
-      Checking for required CPU feature: sse4_1 [success]
-      Checking for required CPU feature: pclmulqdq [success]
-      Checking for required CPU feature: ssse3 [success]
-      Success: System is compatible
-
-.. _clear-linux-check-config.sh: 
-   https://cdn.download.clearlinux.org/current/clear-linux-check-config.sh
-
-.. _Download:
-   https://clearlinux.org/downloads   
@@ -1,197 +0,0 @@
-.. _install-configfile:
-
-Install using clr-installer and a configuration file
-####################################################
-
-In addition to the interactive GUI and text-based modes,
-:command:`clr-installer` also supports an unattended mode where you 
-simply provide it a YAML configuration file.  
-
-This guide shows you two examples of how to use its unattended mode.  
-
-.. contents::
-   :local:
-   :depth: 1
-
-Prerequisites
-*************
-
-For installation onto bare metal, ensure that your target system 
-supports these requirements:
-
-* :ref:`system-requirements`
-* :ref:`compatibility-check`
-
-Download and make bootable USB of the live server image
-*******************************************************
-
-See :ref:`bootable-usb`.
-
-Example 1: Fresh installation onto bare metal
-*********************************************
-
-This example uses a YAML configuration file to perform a new installation.
-
-#. Boot up the |CL| Live Server USB thumb drive.
-
-#. Select :guilabel:`Clear Linux OS` from the menu.
-
-#. In the console window, log in as `root` and set a password.
-
-#. Verify you have a network connection to the Internet and configure proxy
-   settings if you're working behind a firewall.
-
-#. Download a sample YAML configuration file. For example, if you want to 
-   install |CL| with a desktop GUI, you might want to use :file:`live-desktop.yaml`.
-   Or you can use the :file:`live-server.yaml` if you want to install a non-GUI version
-   of |CL|.
-
-   * *Desktop:*
-
-     .. code-block:: bash
-
-        curl -O https://cdn.download.clearlinux.org/current/config/image/live-desktop.yaml
-
-   * *Server:*
-
-     .. code-block:: bash
-
-        curl -O https://cdn.download.clearlinux.org/current/config/image/live-server.yaml
-
-#. Edit the YAML configuration file and change the settings as needed.
-
-   Commonly-changed settings include (refer to the example below):
-
-   a. Under *block-devices* (line 15), set your target media.  For example: ``file: "/dev/sda"``.
-   #. Under *targetMedia* (line 34), set the third partition size to “0” to use the entire disk space.
-   #. Under *bundles* (line 37), add additional bundles as needed.
-   #. Delete the *post-install* section unless you have post-installation scripts.
-   #. Under *Version* (line 50), set a version number. To use the latest version, set to “0”.
-
-   See `Installer YAML Syntax`_ for more details.
-
-   .. code-block:: console
-      :linenos:
-      :emphasize-lines: 14,15,34,37,50
-
-		#clear-linux-config
-
-		# c-basic-offset: 2; tab-width: 2; indent-tabs-mode: nil
-		# vi: set shiftwidth=2 tabstop=2 expandtab:
-		# :indentSize=2:tabSize=2:noTabs=true:
-
-		# File:         developer-live-server.yaml
-		# Use Case:     Live Image which boots into login prompt
-		#               Optionally allows for installing Clear Linux OS
-		#               using the TUI clr-installer by running clr-installer
-
-		# switch between aliases if you want to install to an actual block device
-		# i.e /dev/sda
-		block-devices: [
-		   {name: "bdevice", file: "/dev/sda"}
-		]
-
-		targetMedia:
-		- name: ${bdevice}
-		  type: disk
-		  children:
-		  - name: ${bdevice}1
-		    fstype: vfat
-		    mountpoint: /boot
-		    size: "150M"
-		    type: part
-		  - name: ${bdevice}2
-		    fstype: swap
-		    size: "32M"
-		    type: part
-		  - name: ${bdevice}3
-		    fstype: ext4
-		    mountpoint: /
-		    size: "0"
-		    type: part
-
-		bundles: [os-core, os-core-update, NetworkManager, clr-installer, vim]
-
-		autoUpdate: false
-		postArchive: false
-		postReboot: false
-		telemetry: false
-		iso: true
-		keepImage: true
-
-		keyboard: us
-		language: en_US.UTF-8
-		kernel: kernel-native
-
-		version: 30010
-
-#. Start the unattended installation using the `--config` option.
-
-   .. code-block:: bash
-
-      clr-installer --config live-server.yaml
-
-#. Reboot your system after installation is completed.
-
-Example 2: Replicate a previous installation
-********************************************
-
-This example uses a saved configuration file from a previous installation,
-which you can use to easily clone the installation on additional machines
-, ideally with the same hardware configuration.
-
-.. warning::
-   
-   Be aware of the following when applying a saved configuration on a new machine:
-   
-   * Make sure the target media on the new machine matches up
-   
-   * The users' credentials will be replicated as well
-
-#. On a system where |CL| was installed, open a terminal window.
-
-#. Get root privilege.
-
-   .. code-block:: bash
-
-      sudo su
-
-#. Copy the :file:`clr-installer.yaml` from :file:`/root` to a USB thumb drive.
-
-   .. code-block:: bash
-
-      cp /root/clr-installer.yaml <USB-thumb-drive>
-
-#. Install on target system.
-
-   a. Boot up the |CL| Live Server USB thumb drive.
-
-   #. Select :guilabel:`Clear Linux OS` from the menu.
-
-   #. In the console window, log in as `root` and set a password.
-
-   #. Verify you have a network connection to the Internet and configure proxy
-      settings if you're working behind a firewall.
-
-   #. Plug in and mount the USB thumb drive containing the retrieved
-      :file:`clr-installer.yaml` configuration file.
-   
-   #. Doublecheck to make sure the target media in the saved configuration file
-      matches with the target system's. 
-
-   #. Start the installation.
-
-      .. code-block:: bash
-
-         clr-installer --config clr-installer.yaml
-
-   #. Reboot your system after installation is completed.
-
-References
-**********
-
-* `Clear Linux Installer`_
-* `Installer YAML Syntax`_
-
-.. _Clear Linux Installer: https://github.com/clearlinux/clr-installer
-.. _Installer YAML Syntax: https://github.com/clearlinux/clr-installer/blob/master/scripts/InstallerYAMLSyntax.md
@@ -1,407 +0,0 @@
-.. _virtualbox-cl-installer:
-
-|CL-ATTR| on VirtualBox\*
-#########################
-
-This page explains how to create a virtual machine on the `VirtualBox`_
-hypervisor with |CL-ATTR| as the guest operating system. These instructions
-support the |CL| live-server installer to create the |CL| virtual machine (VM).
-
-.. contents::
-   :local:
-   :depth: 1
-
-Prerequisites
-*************
-
-#. Enable virtualization, such as `Intel® Virtualization Technology <https://www.intel.com/content/www/us/en/virtualization/virtualization-technology/intel-virtualization-technology.html>`_
-   (Intel® VT), on the host system from EFI/BIOS.
-
-#. Download and install |VB| **version 6.0 or later** from
-   `VirtualBox`_ using the  `VirtualBox Installation Instructions`_ for your
-   platform.
-
-Download and extract the |CL| installer ISO
-*******************************************
-
-#. Download the :file:`clear-<VERSION>-live-server.iso.xz` of
-   |CL| on the `Downloads`_ page.
-
-#. Validate the integrity of the downloaded image by checking the file hash
-   and signatures. Refer to :ref:`validate-signatures` for detailed steps.
-
-#. Decompress the downloaded image.
-
-   - On Windows, you can use `7zip`_ to extract the file by right-clicking the
-     file to *Extract Here* (in the same directory)
-
-   .. figure:: figures/vbox/virtualbox-cl-installer-01.png
-      :scale: 100%
-      :alt: 7zip extract here command
-
-      Figure 1: 7zip extract here command
-
-   - On Linux :
-
-     .. code-block:: bash
-
-        xz -d clear-<VERSION>-live-server.iso.xz
-
-#. Delete the originally downloaded compressed file.
-
-Create a new |VB| virtual machine
-*********************************
-
-A new :abbr:`VM (Virtual Machine)` needs to be created in |VBM| where |CL|
-will be installed. General instructions for creating a virtual machine and
-details about using different settings are available in the VirtualBox manual section `Creating Your First Virtual Machine`_.
-
-#. Launch the |VBM| from your host system.
-
-#. Click the :guilabel:`New` button to create a new VM.
-
-#. Choose :guilabel:`Expert mode`.
-
-#. On the :guilabel:`Create Virtual Machine` screen, enter the following settings:
-
-   - **Name**: Choose name (e.g. ClearLinuxOS-VM).
-   - **Type**: Linux
-   - **Version**: **Linux 2.6 / 3.x / 4.x (64-bit)**
-   - **Hard disk**: `Create a virtual hard disk now`
-   - **Memory size default**: 2048 MB (Adjust appropriately.)
-
-     .. note::
-        Later, if you want to change the amount of RAM allocated, power down your VM. Return to :file:`Settings > System` and change
-        :guilabel:`Base Memory` to the desired size.
-
-   .. figure:: figures/vbox/virtualbox-cl-installer-02.png
-      :scale: 100%
-      :alt: Create Virtual Machine
-
-      Figure 2: Create Virtual Machine
-
-#. Click :guilabel:`Create`.
-
-#. On the :guilabel:`Create Virtual Hard Disk` screen, select:
-
-   - **File location**
-   - **File size**: **32.00 GB**. Adjust size to your needs.
-   - **Hard disk file type**: `VDI (VirtualBox Disk Image)`
-   - **Storage on physical hard disk**: `Dynamically allocated`
-
-   .. figure:: figures/vbox/virtualbox-cl-installer-03.png
-      :scale: 100%
-      :alt: Create Virtual Hard Disk
-
-      Figure 3: Create Virtual Hard Disk
-
-#. Click :guilabel:`Create`.
-
-   A new virtual machine will be created and appear in the |VBM|.
-
-#. Click :guilabel:`Settings` to configure the |CL| VM.
-
-#. In the left-hand menu, navigate to the :menuselection:`System` menu.
-
-#. On the :guilabel:`Motherboard` tab, select the :guilabel:`Chipset` menu, and
-   then select :menuselection:`ICH9`. See Figure 4.
-
-   .. note::
-
-      You can select which chipset will be presented to the virtual machine.
-      Consult the `VM VirtualBox User Manual`_ for more details.
-
-#. In :guilabel:`Enabled Features`, check these boxes:
-
-   - **Enable I/O APIC**
-   - **Enable EFI (special OSes only)**
-
-   .. figure:: figures/vbox/virtualbox-cl-installer-04.png
-      :scale: 100%
-      :alt: Settings > System
-
-      Figure 4: Settings > System
-
-   .. note::
-
-      By default, only 1 virtual CPU is allocated to the new VM. Consider
-      increasing the number of virtual processors allocated to the virtual
-      machine under Settings > System > Processor for increased
-      performance.
-
-#. Click :guilabel:`OK`.
-
-Install |CL| on the |VB| VM
-***************************
-
-|CL| is ready to be installed.
-
-Mount the installation ISO
-==========================
-
-The |CL| installer ISO needs to be mounted as a virtual CD-ROM on the VM
-before powering the VM on.
-
-#. From the *ClearLinux-OS* :guilabel:`Settings` menu at left, select
-   :guilabel:`Storage`.
-
-#. From :guilabel:`Storage Devices`, middle column, click the blue
-   disk labeled :guilabel:`Empty`.
-
-#. From the :guilabel:`Attributes` menu, click the blue CD disk next to
-   the :guilabel:`Optical Drive` drop down menu and click
-   :guilabel:`Choose Virtual Optical Disk File...`
-
-   .. figure:: figures/vbox/virtualbox-cl-installer-05.png
-      :scale: 100%
-      :alt: Choose Virtual Optical Disk Drive
-
-      Figure 5: Choose Virtual Optical Disk Drive
-
-#. Where there appears :guilabel:`Please choose a virtual optical disk file`,
-   select the ISO file and click *Open*.
-
-   .. figure:: figures/vbox/virtualbox-cl-installer-06.png
-      :scale: 100%
-      :alt: Mounting an ISO
-
-      Figure 6: Mounting an ISO
-
-#. Click :guilabel:`OK` to exit and return to the main |VBM|.
-
-Install |CL| with live-server installer
-=======================================
-
-#. In the |VBM|, select virtual machine you created and click :guilabel:`Start`.
-
-   .. figure:: figures/vbox/virtualbox-cl-installer-07.png
-      :scale: 100%
-      :alt: Start the installer
-
-      Figure 7: Start the installer
-
-   .. note::
-
-      To release the mouse cursor from the VM console window, press the right
-      :kbd:`Ctrl` key on the keyboard.
-
-#. When :guilabel:`Clear Linux Installer` in boot manager appears,
-   select :kbd:`Enter`. Do not install the bundle `desktop-autostart`.
-
-#. Follow the steps in :ref:`bare-metal-install-server` to
-   install |CL| onto the VM virtual disk. Note:
-
-   #. In :guilabel:`Configure Installation Media`, navigate top
-      VBOX HARDDISK, and then select :guilabel:`Confirm`.
-
-   #. In :menuselection:`Advanced options --> Manage User`, create an
-      administrative user.
-
-   #. Do not install the bundle `desktop-autostart`.
-
-#. When |CL| installation is complete, click :guilabel:`Exit`.
-
-#. At the prompt, enter:
-
-   .. code-block:: bash
-
-      shutdown now
-
-Unmount the ISO
-===============
-
-The |CL| installer ISO needs to be unmounted to allow the VM to boot from the
-virtual hard disk.
-
-#. Return to the |VBM|.
-
-#. Click :guilabel:`Settings` to configure the |CL| VM.
-
-#. From the VM :guilabel:`Settings` window, navigate to the :guilabel:`Storage`
-   pane in the left menu.
-
-#. From the middle :guilabel:`Storage Devices` column, click the blue CD disk
-   labeled :guilabel:`clear-<VERSION>-live-server.iso` under the
-   :guilabel:`Controller: IDE`.
-
-#. From the :guilabel:`Attributes` column on the right, in :guilabel:`Optical Drive`,
-   select the blue CD icon beside and click
-   :guilabel:`Remove Disk from Virtual Drive`.
-
-   .. figure:: figures/vbox/virtualbox-cl-installer-08.png
-      :scale: 100%
-      :alt: Remove Disk from Virtual Drive
-
-      Figure 8: Remove Disk from Virtual Drive
-
-#. Click :guilabel:`OK` to exit the :guilabel:`VM Settings` menu and return to
-   the main |VBM|.
-
-Install |VB| Linux Guest Additions
-==================================
-
-|CL| provides Linux Guest Additions drivers for full compatibility using an
-install script in the **kernel-lts** (Long Term Support) bundle by |CL|.
-
-#. From the |VBM| select the |CL| VM, and select :guilabel:`Start`.
-
-#. In the VM Console, log in as the administrative user previously created.
-
-   .. note::
-      A message may appear: "A kernel update is available: you may wish
-      to reboot the system."
-
-      To update the kernel, enter:
-
-      .. code-block:: bash
-
-          sudo reboot
-
-      At initial login, enter the administrative user's password and continue.
-
-#. Validate the installed kernel is **kernel-lts** by checking the output
-   of the :command:`uname -r` command. It should end in **.lts** or **.lts2018**.
-
-   .. code-block:: bash
-
-      uname -r
-      <VERSION>.lts
-
-   If the running kernel is not **lts**: install the LTS kernel manually,
-   update the bootloader, and check again:
-
-   .. code-block:: bash
-
-      sudo swupd bundle-add kernel-lts
-      clr-boot-manager set-kernel $(basename $(realpath /usr/lib/kernel/default-lts))
-      clr-boot-manager update
-      reboot
-
-#. Remove any kernel bundles that do not end in *-lts* or *kernel-install*
-   to simplify and avoid conflicts:
-
-   .. code-block:: bash
-
-      sudo swupd bundle-list | grep kernel
-      sudo swupd bundle-remove <NON-LTS-KERNEL>
-
-#. In the VM Console top menu, click :guilabel:`Devices`, and select
-   :guilabel:`Insert Guest Additions CD image...` to mount the |VB| driver
-   installation to the |CL| VM.
-
-   .. figure:: figures/vbox/virtualbox-cl-installer-09.png
-      :scale: 100%
-      :alt: Insert Guest Additions CD image
-
-      Figure 9: Insert Guest Additions CD image
-
-#. If a dialogue appears, "VBx_GAs_6.0.8... Would you like to run it?",
-   select :guilabel:`Cancel`.
-
-   Instead, we provide a script to patch and install |VB| drivers on |CL|.
-
-#. Open a Terminal and enter the script:
-
-   .. code-block:: bash
-
-      sudo install-vbox-lga
-
-   .. note::
-
-      Successful installation shows: "Guest Additions installation complete".
-      If drivers are already installed, don't re-install them.
-
-#. Shut down the system. Select :menuselection:`Machine --> ACPI Shutdown`.
-
-   .. figure:: figures/vbox/virtualbox-cl-installer-10.png
-      :scale: 100%
-      :alt: Powering off a VirtualBox VM
-
-      Figure 10: Powering off a VirtualBox VM
-
-#. Select :guilabel:`Settings`, :guilabel:`Display`.
-
-#. In :guilabel:`Graphics Controller`, select :guilabel:`VBoxSVGA`
-   to adjust screen size dynamically.
-
-   .. figure:: figures/vbox/virtualbox-cl-installer-11.png
-      :scale: 100%
-      :alt: Remove Disk from Virtual Drive
-
-      Figure 11: VirtualBox hardware acceleration error
-
-#. In the |VBM|, select :guilabel:`Start`.
-
-#. In the VM console, login and verify the |VB| drivers are loaded:
-
-   .. code-block:: bash
-
-      lsmod | grep ^vbox
-
-   You should see drivers loaded with names beginning with **vbox**:
-   (e.g., vboxvideo, vboxguest).
-
-#. Add `desktop-autostart` for a full desktop experience.
-
-   .. code-block:: bash
-
-      sudo swupd bundle-add desktop-autostart
-
-#. Reboot the VM and log in with the administrative user.
-
-   .. code-block:: bash
-
-      sudo reboot
-
-The |CL| VM running on |VB| is ready to develop and explore.
-
-Troubleshooting
-***************
-
-#. **Problem:** On a Microsoft\* Windows\* OS, |VB| encounters an error when
-   trying to start a VM indicating *VT-X/AMD-v hardware acceleration is not
-   available on your system.*
-
-   .. figure:: figures/vbox/virtualbox-cl-installer-12.png
-      :scale: 100%
-      :alt: Remove Disk from Virtual Drive
-
-      Figure 12: VirtualBox hardware acceleration error
-
-   **Solution:** First, double check the `Prerequisites`_ section to make
-   sure *Hardware accelerated virtualization* extensions have been enabled
-   in the host system's EFI/BIOS.
-
-   *Hardware accelerated virtualization*, may get disabled for |VB| when
-   another hypervisor, such as *Hyper-V* is enabled.
-
-   To disable *Hyper-V* execute this command in an
-   **Administrator: Command Prompt or Powershell**, and reboot the system:
-
-   .. code-block:: bash
-
-      bcdedit /set {current} hypervisorlaunchtype off
-
-   To enable Hyper-V again, execute this command in an
-   **Administrator: Command Prompt or Powershell**, and reboot the system:
-
-   .. code-block:: bash
-
-      bcdedit /set {current} hypervisorlaunchtype Auto
-
-
-*Intel and the Intel logo are trademarks of Intel Corporation or its subsidiaries.*
-
-.. _VirtualBox Installation Instructions: https://www.virtualbox.org/manual/ch02.html
-
-.. _VirtualBox: https://www.virtualbox.org
-
-.. _Downloads: https://clearlinux.org/downloads
-
-.. _`Creating Your First Virtual Machine`: https://www.virtualbox.org/manual/UserManual.html#gui-createvm
-
-.. _7zip: http://www.7-zip.org/
-
-.. _Intel® Virtualization Technology: https://www.intel.com/content/www/us/en/virtualization/virtualization-technology/intel-virtualization-technology.html
-
-.. _VM VirtualBox User Manual: https://docs.oracle.com/cd/E97728_01/E97727/html/settings-system.html
@@ -1,72 +0,0 @@
-.. _compatible-kernels:
-
-Kernels
-#######
-
-The |CL-ATTR| provides the following Linux kernels with a respective bundle.
-This document describes the specific use cases these `bundles`_ serve
-and provides links to their source code.
-
-Bare metal only
-***************
-
-Kernel native
-    The *kernel-native* bundle focuses on the bare metal platforms. It is
-    optimized for fast booting and performs best on the Intel® Architecture Processors
-    described on the :ref:`supported hardware list<system-requirements>`. The
-    optimization patches are found in our `Linux`_ GitHub\* repo.
-
-.. _vm-kernels:
-
-Also compatible with VMs
-************************
-
-Kernel LTS
-    The *kernel-lts* bundle focuses on the bare metal platforms but uses the
-    latest :abbr:`LTS (Long Term Support)` Linux kernel. It is optimized for
-    fast booting and performs best on the Intel® Architecture Processors described
-    on the :ref:`supported hardware list<system-requirements>`. Additionally, this
-    kernel includes the VirtualBox\* kernel modules, see our
-    :ref:`instructions on using Virtualbox<virtualbox-cl-installer>` for more
-    information. The optimization patches are found in our `Linux-LTS`_ GitHub
-    repo.
-
-VM only
-*******
-
-Kernel KVM
-    The *kernel-kvm* bundle focuses on the Linux
-    :abbr:`KVM (Kernel-based Virtual Machine)`. It is optimized for fast
-    booting and performs best on Virtual Machines running on the Intel® Architecture
-    Processors described on the
-    :ref:`supported hardware list<system-requirements>`. Use this kernel when
-    running |CL| as the guest OS on top of *qemu/kvm*. Use this kernel with
-    **cloud orchestrators** using *qemu/kvm* internally as their **hypervisor**
-    . This kernel can be used as a standalone |CL| VM, see our
-    :ref:`instructions on using KVM<kvm>` for more information. The
-    optimization patches are found in our `Linux-KVM`_ GitHub repo.
-
-Kernel Hyper-V\*
-    The *kernel-hyperv* bundle focuses on running Linux on Microsoft\*
-    Hyper-V. It is optimized for fast booting and performs best on Virtual
-    Machines running on the Intel® Architecture Processors described on the
-    :ref:`supported hardware list<system-requirements>`.
-    Use this kernel when running |CL| as the guest OS of **Cloud Instances** in
-    projects such as Microsoft `Azure`_\*. This kernel can be used in a
-    standalone |CL| VM, see our :ref:`instructions on using Hyper-V<hyper-v>`
-    for more information. The optimization patches are found in our
-    `Linux-HyperV`_ GitHub repo.
-
-*Intel and the Intel logo are trademarks of Intel Corporation or its subsidiaries.*
-
-.. _Linux: https://github.com/clearlinux-pkgs/linux
-.. _Linux-LTS: https://github.com/clearlinux-pkgs/linux-lts
-.. _Linux-KVM: https://github.com/clearlinux-pkgs/linux-kvm
-.. _Linux-HyperV: https://github.com/clearlinux-pkgs/linux-hyperv
-.. _Linux-HyperV-LTS: https://github.com/clearlinux-pkgs/linux-hyperv-lts
-.. _Linux-Container: https://github.com/clearlinux-pkgs/linux-container
-.. _bundles: https://github.com/clearlinux/clr-bundles
-.. _CIAO: https://github.com/01org/ciao
-.. _Azure:
-   https://azuremarketplace.microsoft.com/en-us/marketplace/apps/clear-linux-project.clear-linux-os
-
@@ -1,321 +0,0 @@
-.. _kubernetes-migration:
-
-Kubernetes\* migration
-######################
-
-This guide describes how to migrate `Kubernetes container orchestration system`_ on |CL-ATTR| from 1.17.x to 1.19.x.
-
-.. contents::
-   :local:
-   :depth: 1
-
-Background
-**********
-
-The version of Kubernetes\* was bumped from 1.17.7 to 1.19.4 in |CL-ATTR|
-release 34090. This guide and the |CL| bundle `k8s-migration` were created
-to help facilitate migration of a cluster from 1.17.x to the latest 1.19.x .
-
-The new |CL| bundle `k8s-migration` was added in |CL-ATTR| release 34270.
-
-Prerequisites
-*************
-
-* Make sure you check any updates to kubernetes upgrade doc for caveats related to the version that is running in the cluster.
-* Make sure ALL the nodes are in Ready state. Without that, the cluster cannot be upgraded.
-  Either fix the broken nodes or remove them from the cluster.
-
-.. contents::
-   :local:
-   :depth: 1
-
-Upgrade 1.17.x ---> 1.18.15
-***************************
-
-#. Upgrade Control Node to 1.18.15 first
-
-   First step would be to upgrade one of the main control node and
-   update kubernetes components on them. You will need to have a newer
-   version of :command:`kubeadm` for the upgrade to work. Please consult
-   `kubeadm upgrade guide`_
-   for any caveats from your current version to the new one.
-
-   Update |CL| to the latest release to update the kubernetes version.
-
-   .. code-block:: bash
-
-      sudo -E swupd update
-
-   .. note::
-      Note: PLEASE DO NOT REBOOT YOUR SYSTEM AT THIS TIME. |CL| is awesome and
-      your stuff will work just fine.
-
-#. Add the new Kubernetes migration bundle which contains the 1.18.15 binaries.
-
-   .. code-block:: bash
-
-      sudo -E swupd bundle-add k8s-migration
-
-#. Find the upgrade version of kubeadm that can used. This should be 1.18.15.
-
-   This command will show the command and possible jumps that can be made from the current kubernetes version.
-
-   .. code-block:: bash
-
-      sudo -E /usr/k8s-migration/bin/kubeadm upgrade plan
-
-   Sample output:
-
-   .. code-block:: console
-
-      [upgrade/config] Making sure the configuration is correct:
-      [upgrade/config] Reading configuration from the cluster...
-      [upgrade/config] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -oyaml'
-      [preflight] Running pre-flight checks.
-      [upgrade] Running cluster health checks
-      [upgrade] Fetching available versions to upgrade to
-      [upgrade/versions] Cluster version: v1.17.17
-      [upgrade/versions] kubeadm version: v1.18.15
-      I0209 21:12:49.868786  832739 version.go:252] remote version is much newer: v1.20.2; falling back to: stable-1.18
-      [upgrade/versions] Latest stable version: v1.18.15
-      [upgrade/versions] Latest stable version: v1.18.15
-      [upgrade/versions] Latest version in the v1.17 series: v1.17.17
-      [upgrade/versions] Latest version in the v1.17 series: v1.17.17
-
-      Components that must be upgraded manually after you have upgraded the control plane with 'kubeadm upgrade apply':
-      COMPONENT   CURRENT       AVAILABLE
-      Kubelet     3 x v1.17.7   v1.18.15
-
-      Upgrade to the latest stable version:
-
-      COMPONENT            CURRENT    AVAILABLE
-      API Server           v1.17.17   v1.18.15
-      Controller Manager   v1.17.17   v1.18.15
-      Scheduler            v1.17.17   v1.18.15
-      Kube Proxy           v1.17.17   v1.18.15
-      CoreDNS              1.6.5      1.6.7
-      Etcd                 3.4.3      3.4.3-0
-
-      You can now apply the upgrade by executing the following command:
-
-        kubeadm upgrade apply v1.18.15
-
-#. Upgrade the node to the intermediate 1.18.15 version of Kubernetes.
-
-   .. code-block:: bash
-
-      sudo -E /usr/k8s-migration/bin/kubeadm upgrade apply v1.18.15
-
-   .. note::
-      Note: Do **not** reboot the system yet.
-
-#. Upgrade Additional Control Nodes to 1.18.15
-
-   In multi-node control plane, verify all the control plane nodes are updated prior to upgrading the worker nodes/SUTs.
-
-#. Upgrade Other Nodes to 1.18.15
-
-   For each of the other nodes:
-
-   a. Update |CL| to the latest release to update the kubernetes version.
-
-      .. code-block:: bash
-
-         sudo -E swupd update
-
-   #. Add the new Kubernetes migration bundle which contains the 1.18.15 binaries.
-
-      .. code-block:: bash
-
-         sudo -E swupd bundle-add k8s-migration
-
-   #. On the **Admin node**, drain the Client node *FIRST*
-
-      .. code-block:: bash
-
-         /usr/k8s-migration/bin/kubectl drain <CLIENT_NODE_NAME> --ignore-daemonsets --delete-local-data
-
-   #. Back on the **Client node**, upgrade Kubernetes on the Client
-
-      .. code-block:: bash
-
-         sudo -E /usr/k8s-migration/bin/kubeadm upgrade node
-
-   #. On the **Admin node**, re-enable the Client
-
-      .. code-block:: bash
-
-         /usr/k8s-migration/bin/kubectl uncordon <CLIENT_NODE_NAME>
-
-
-   #. Back on the **Client node**, restart Kubernetes on the Client
-
-      .. code-block:: bash
-
-         sudo -E systemctl restart kubelet
-
-#. Restart Kubernetes on the Admin node(s) to finish the 1.18.x upgrade
-
-   .. code-block:: bash
-
-      sudo -E systemctl restart kubelet
-
-   .. note::
-      Note: Wait for all nodes to be Ready and showing the 1.19.x version.
-      This version will now show as it is the released version the
-      service files will see and use, but the Nodes are *not* upgraded yet.
-
-Upgrade 1.18.15 ---> 1.19.x
-***************************
-
-#. Upgrade Control Node to 1.19.x
-
-   Now that systems are upgraded to the intermediate release of 1.18.15
-   each of the nodes can be upgraded to the latest 1.19.x release.
-
-#. Find the upgrade version of kubeadm that can used. This should be 1.19.x.
-
-   This command will show the command and possible jumps that can be made from the current kubernetes version.
-
-   .. code-block:: bash
-
-      sudo -E kubeadm upgrade plan
-
-   Sample output:
-
-   .. code-block:: console
-
-      [upgrade/config] Making sure the configuration is correct:
-      [upgrade/config] Reading configuration from the cluster...
-      [upgrade/config] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -oyaml'
-      [preflight] Running pre-flight checks.
-      [upgrade] Running cluster health checks
-      [upgrade] Fetching available versions to upgrade to
-      [upgrade/versions] Cluster version: v1.18.15
-      [upgrade/versions] kubeadm version: v1.19.7
-      I0209 23:08:23.810900  925910 version.go:252] remote version is much newer: v1.20.2; falling back to: stable-1.19
-      [upgrade/versions] Latest stable version: v1.19.7
-      [upgrade/versions] Latest stable version: v1.19.7
-      [upgrade/versions] Latest version in the v1.18 series: v1.18.15
-      [upgrade/versions] Latest version in the v1.18 series: v1.18.15
-
-      Components that must be upgraded manually after you have upgraded the control plane with 'kubeadm upgrade apply':
-      COMPONENT   CURRENT       AVAILABLE
-      kubelet     3 x v1.17.7   v1.19.7
-
-      Upgrade to the latest stable version:
-
-      COMPONENT                 CURRENT    AVAILABLE
-      kube-apiserver            v1.18.15   v1.19.7
-      kube-controller-manager   v1.18.15   v1.19.7
-      kube-scheduler            v1.18.15   v1.19.7
-      kube-proxy                v1.18.15   v1.19.7
-      CoreDNS                   1.6.7      1.7.0
-      etcd                      3.4.3-0    3.4.13-0
-
-      You can now apply the upgrade by executing the following command:
-
-        kubeadm upgrade apply v1.19.7
-
-      The table below shows the current state of component configs as understood by this version of kubeadm.
-      Configs that have a "yes" mark in the "MANUAL UPGRADE REQUIRED" column require manual config upgrade or
-      resetting to kubeadm defaults before a successful upgrade can be performed. The version to manually
-      upgrade to is denoted in the "PREFERRED VERSION" column.
-
-      API GROUP                 CURRENT VERSION   PREFERRED VERSION   MANUAL UPGRADE REQUIRED
-      kubeproxy.config.k8s.io   v1alpha1          v1alpha1            no
-      kubelet.config.k8s.io     v1beta1           v1beta1             no
-
-#. Upgrade the node to the latest 1.19.x version of Kubernetes.
-
-   .. code-block:: bash
-
-      sudo -E /usr/bin/kubeadm upgrade apply v1.19.7
-
-   .. note::
-
-      Note: Do **not** reboot the system yet.
-
-#. Upgrade Additional Control Nodes to 1.19.x
-
-   In multi-node control plane, verify all the control plane nodes are updated prior to upgrading the worker nodes/SUTs.
-
-#. Upgrade Other Nodes to 1.19.x
-
-   For each of the other nodes:
-
-   a. On the **Admin node**, drain the Client *FIRST*
-
-      .. code-block:: bash
-
-         kubectl drain <CLIENT_NODE_NAME> --ignore-daemonsets
-
-   #. Back on the **Client node**, upgrade Kubernetes on the Client
-
-      .. code-block:: bash
-
-         sudo -E kubeadm upgrade node
-
-   #. On the **Admin node**, re-enable the Client
-
-      .. code-block:: bash
-
-         kubectl uncordon <CLIENT_NODE_NAME>
-
-   #. Back on the **Client node**, if you wish reboot the Client, it is now safe to do so.
-
-      .. code-block:: bash
-
-         sudo reboot
-
-#. Reboot the Control Node (optional)
-
-  *If you wish reboot the nodes, it is now safe to do so.*
-
-   .. code-block:: bash
-
-      sudo reboot
-
-**Congratulations!**
-
-You've successfully installed and set up Kubernetes in |CL| using CRI-O and kata-runtime. You are now ready to follow on-screen instructions to deploy a pod network to the cluster and join worker nodes with the displayed token and IP information.
-
-Clean up: Remove the migration bundle for each node
-
-.. code-block:: bash
-
-   sudo -E swupd bundle-remove k8s-migration
-
-Related topics
-**************
-
-Read the Kubernetes documentation to learn more about:
-
-*  `Kubernetes tutorial <tutorials/kubernetes>`_
-
-*  `Kubernetes best practices <tutorials/kubernetes-bp>`_
-
-*  Deploying Kubernetes with a `cloud-native-setup`_
-
-* `Understanding basic Kubernetes architecture`_
-
-* `Deploying an application to your cluster`_
-
-* Installing a `pod network add-on`_
-
-* `Joining your nodes`_
-
-
-.. _kubeadm upgrade guide: https://kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/
-
-.. _Kubernetes container orchestration system: https://kubernetes.io/
-
-.. _Understanding basic Kubernetes architecture: https://kubernetes.io/docs/user-journeys/users/application-developer/foundational/#section-3
-
-.. _Deploying an application to your cluster: https://kubernetes.io/docs/user-journeys/users/application-developer/foundational/#section-2
-
-.. _pod network add-on: https://kubernetes.io/docs/setup/independent/create-cluster-kubeadm/#pod-network
-
-.. _Joining your nodes: https://kubernetes.io/docs/setup/independent/create-cluster-kubeadm/#join-nodes
-
-.. _cloud-native-setup: https://github.com/clearlinux/cloud-native-setup/tree/master/clr-k8s-examples
@@ -1,241 +0,0 @@
-.. _performance:
-
-Performance
-###########
-
-|CL-ATTR| is built with optimizations across the whole stack for improved
-performance. |CL| achieves its performance through a variety of design decisions
-and software building techniques.
-
-.. contents:: :local:
-   :depth: 1
-
-Overview
-********
-
-The |CL| philosophy is to do everything with performance in mind. The |CL| team
-applies this philosophy in the project's codebase and operating culture.
-
-Below are some examples of the |CL| philosophy:
-
-**Consider performance holistically.**
-  Performance optimizations are considered across hardware and software. |CL|
-  shows the performance potential of a holistic approach on Linux, using Intel®
-  architecture with optimizations across the full stack.
-
-**Optimize for runtime performance.**
-  In general, |CL| will trade the one-time cost of longer build time and larger
-  storage footprint for the repeated benefit of improved runtime performance.
-  |CL| users benefit from the optimized software but aren't affected by the
-  increased build time because the |CL| team builds the software before
-  distributing it to |CL| clients.
-
-**Optimize performance for server and cloud use cases first.**
-  Design decisions that optimize performance for server and cloud also benefit
-  other use cases, such as IoT devices and desktop clients.
-
-|CL| has become well-known for the performance it can deliver.
-`Phoronix publishes
-Linux performance comparisons <https://www.phoronix.com/scan.php?page=news_topic&q=Clear+Linux>`_
-that include |CL|.
-
-Software build toolchain
-************************
-
-|CL| uses many techniques in its software build toolchain to improve software
-performance, such as aggressive compiler flags and CPU-specific optimizations.
-If maintained manually, these techniques can become complex to support due to
-the volume of packages and the potential for technical drift of package
-performance configurations. The |CL| team built the :ref:`autospec` tool to
-manage this complexity and to apply the techniques used in the software build
-toolchain across the entire project. autospec is available as part of the OS for
-developers to use when they build their own projects on |CL|.
-
-Latest versions of compilers and low-level libraries
-====================================================
-
-|CL| is a rolling release distribution and follows upstream software
-repositories, including compilers and libraries, for updates. |CL| includes
-upstream source-level optimizations as soon as they're available.
-
-A benchmark approach to compiler performance
-============================================
-
-|CL| chooses the compiler used to build each software package on a case-by-case
-basis to maximize performance. Typically, |CL| uses the open source `GNU Compiler
-Collection <https://gcc.gnu.org/>`_ (GCC) with the standard low-level
-libraries `Glibc <https://www.gnu.org/software/libc/>`_ and
-`libstdc++ <https://gcc.gnu.org/onlinedocs/libstdc++/>`_ for C and C++
-programming languages. If there is a performance advantage, |CL| will build
-packages with `Clang / LLVM <https://clang.llvm.org/>`_.
-
-|CL| uses patched compilers and low-level libraries for exact control of the
-software build. Patches include changes that default to more aggressive
-optimizations or optimizations that haven't yet been merged upstream.
-
-View the full list of patches in the autospec repositories on GitHub:
-
-* https://github.com/clearlinux-pkgs/gcc
-* https://github.com/clearlinux-pkgs/glibc
-* https://github.com/clearlinux-pkgs/llvm
-
-Aggressive compiler flags
-=========================
-
-|CL| uses aggressive
-`compiler flags <https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html>`_ to
-optimize software builds for runtime performance. Some significant flags that
-|CL| often implements are:
-
-`mtune and march <https://gcc.gnu.org/onlinedocs/gcc/x86-Options.html>`_
-	Options used to tune generated code with optimized instructions for specific
-	CPU types instead of creating generic code for maximum compatibility.
-
-	|CL| defines its minimum hardware requirements to be second-generation
-	Intel® microarchitecture code name Westmere (released in 2010) or later.
-	This enables compiler optimizations that are available only on newer
-	architectures. Whenever possible, |CL| tunes code for the Haswell generation
-	processors or newer.
-
-	|CL| sets	:command:`march=westmere` and :command:`mtune=haswell`.
-
-	.. note::
-		|CL| doesn't require Advanced Encryption Standard (AES), so it should
-		run on some Intel CPUs from the first generation of Intel® microarchitecture code name Nehalem (released in 2008). Refer to the
-		`recommended minimum system requirements <https://docs.01.org/clearlinux/latest/reference/system-requirements.html>`_ for specific requirements.
-
-`O3 <https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html>`_
-	The largest preset of compiler options optimizations for performance. O3
-	favors runtime performance.
-
-	View the "Optimize Options" section of the GCC man page for additional
-	information: :command:`man gcc`
-
-`LTO <https://gcc.gnu.org/onlinedocs/gccint/LTO.html>`_
-	Link-time optimization that performs an optimization between compiled object
-	files and creation of executable binaries by adding extra information to the
-	compiled object to help the linker.
-
-`PGO <https://en.wikipedia.org/wiki/Profile-guided_optimization>`_
-	Profile guided optimization or field guided optimization performs
-	optimization based on information sampled during the execution of the program.
-
-
-Compiler flags are set at different levels in the |CL| build environment:
-
-User flags
-	The set of default flags used by |CL| when a user compiles software
-	from source. The flags are exported as system-wide environment variables from
-	the
-	`/usr/share/defaults/etc/profile <https://github.com/clearlinux-pkgs/filesystem/blob/master/profile.x86_64>`_ file to the user’s shell by default. These are the
-	standard variables read by the compiler, named :command:`*FLAGS`, depending
-	on the compiler.
-
-	.. note::
-		Source code may come with software build systems that
-		override these values. This will cause a difference in expected flags.
-		The |CL| autospec tooling will attempt to ignore these overrides, but
-		the build system may still need patching. A manual build will not ignore
-		the build system override values if they exist.
-
-Global flags
-	Compiler flags applied at a global level for all packages. The |CL| RPM
-	configuration (`clr-rpm-config <https://github.com/clearlinux/clr-rpm-config>`_)
-	contains global compiler flags. Search the :file:`macros` file for
-	:command:`global_cflags` and search the :file:`rpmrc` file for
-	:command:`optflags`. Global compiler flags may be overridden.
-
-	.. note::
-		|CL| doesn't use RPMs to install software. |CL|
-		distributes software in the form of :ref:`bundles-guide`. The RPM format
-		is only used during the |CL| build process as a way to resolve
-		dependencies.
-
-Per-package flags
-	Compiler flags applied at a per-package level. The package's autospec
-	repository contains the package-specific compiler flags. Search the
-	:file:`.spec` file for the
-	section starting with :command:`export CFLAGS`.
-
-Multiple builds of libraries with CPU-specific optimizations
-============================================================
-
-To fully use the capabilities in different generations of CPU hardware, |CL|
-will perform multiple builds of libraries with CPU-specific optimizations. For
-example, |CL| builds libraries with Intel® Advanced Vector Extensions 2 (Intel®
-AVX2) and Intel® Advanced Vector Extensions 512 (Intel® AVX-512). |CL| can then
-dynamically link to the library with the newest optimization based on the
-processor in the running system. Runtime libraries used by ordinary applications
-benefit from these CPU specific optimizations.
-
-The autospec repository for Python* shows an example of this optimization:
-https://github.com/clearlinux-pkgs/python3
-
-Kernel
-******
-
-A modern kernel with variants optimized for different platforms
-===============================================================
-
-|CL| is a rolling release distribution that uses the newest upstream Linux
-kernel. The Linux kernel has frequent updates which can include performance
-enhancements. It's a policy of the |CL| team to try to upstream any performance
-enhancements in the Linux kernel for all to use.
-
-|CL| `builds different kernel variants <https://docs.01.org/clearlinux/latest/guides/clear/compatible-kernels.html>`_ for compatibility with specific platforms.
-For example, kernels meant to run on virtual machines skip support for much of
-the physical hardware that doesn’t show up in VM environments and will slow down
-boot.
-
-View the kernel configuration and patches to the default native kernel in the
-autospec repository: https://github.com/clearlinux-pkgs/linux/
-
-Utility to enforce kernel runtime parameters
-============================================
-
-The Linux kernel exposes parameters for tuning the behavior of drivers and
-devices such as certain buffers and resource management strategies. |CL| uses a
-small utility, `clr-power-tweaks <https://github.com/clearlinux-pkgs/clr-power-tweaks>`_,
-to set and enforce kernel parameter values weighted towards performance upon
-boot. View the set performance values by running :command:`sudo clr_power --debug`.
-
-Operating system
-****************
-
-Operating system and software build-time optimizations set the stage for high
-performance. Decisions made after the installation of |CL| are equally as
-important.
-
-
-CPU performance governor
-========================
-
-|CL| uses the performance CPU governor which calls for the CPU to operate at
-maximum clock frequency. In other words, P-state P0. The idea behind prioritizing
-maximum CPU performance is that the faster a program finishes execution, the
-faster the CPU can return to a low energy idle state. See the `CPU Power and
-Performance documentation <https://docs.01.org/clearlinux/latest/guides/maintenance/cpu-performance.html>`_
-for further details.
-
-Restructured boot sequence
-==========================
-
-To optimize boot speed, |CL| uses a restructured order for boot processes that
-minimizes the time services wait on slow operations and the time boot processes
-wait on each other.
-
-Systemd-bootchart is a tool for graphing the boot sequence and writes logs to a
-file under :file:`/run/log`. The tool and corresponding log file make diagnosing slow
-boot problems easier. All |CL| systems have `systemd-bootchart <https://github.com/systemd/systemd-bootchart>`_ enabled by default for every boot. systemd-bootchart configuration is
-non-blocking to not materially slow down boot performance.
-
-Related topics
-**************
-
-* :ref:`cpu-performance`
-* `A Linux* OS for Linux Developers <https://clearlinux.org/blogs-news/linux-os-linux-developers>`_
-* `The Performance Race <https://clearlinux.org/news-blogs/performance-race>`_
-* `Boosting Python* from profile-guided to platform-specific optimizations <https://clearlinux.org/news-blogs/boosting-python-profile-guided-platform-specific-optimizations>`_
-* `Transparent use of library packages optimized for Intel® architecture <https://clearlinux.org/news-blogs/transparent-use-library-packages-optimized-intel-architecture>`_
-
-*Intel and the Intel logo are trademarks of Intel Corporation or its subsidiaries.*
@@ -1,158 +0,0 @@
-.. _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
-within the project's codebase and operating culture.
-
-.. contents:: :local:
-   :depth: 1
-
-Security in updates
-*******************
-
-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.
-
-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|.
-
-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
-a software update, if desired.
-
-In |CL| updates are delivered automatically, efficiently, and effectively. For
-more information about software updates in |CL|, refer to the :ref:`swupd-guide`
-guide.
-
-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
-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 CVEs daily, and security
-patches are deployed as soon as they are available.
-
-These combined practices minimize the amount of time |CL| systems are exposed to unnecessary security risk.
-
-Security in software
-*********************
-
-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:
-
-* `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
-  have been removed such as the `finger` and `tcpwrappers`.
-
-* `SFTP` has been disabled by default due to security considerations.
-
-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:
-
-* All update operations from swupd are transparently encrypted and checked
-  against the |CL| maintainers' public key for authenticity.
-  More information about swupd security can be found in the
-  `Security for software update in Clear Linux* OS`_ blog post.
-
-* 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.
-
-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:
-
-* 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
-  `Kernel address space layout randomization (KASLR)`_  are kernel features
-  which defend against certain memory based attacks.
-  More information about PIE executables can be found in the
-  `Recent GNU* C library improvements`_ blog post.
-
-Security in system design
-*************************
-
-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:
-
-* Full disk encryption using :abbr:`LUKS (Linux Unified Key Setup)` is available
-  during installation. Refer to `cryptsetup`_ for additional information about
-  LUKS.
-
-* |CL| uses the PAM cracklib module to harden user login and password
-  security resulting in:
-
-  - 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,
-    cannot be set in |CL|.
-
-  - 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.
-
-*Intel and the Intel logo are trademarks of Intel Corporation or its subsidiaries.*
-
-.. _`Security for software update in Clear Linux* OS`: https://clearlinux.org/blogs/security-software-update-clear-linux-os-intel-architecture
-.. _`Recent GNU* C library improvements`: https://clearlinux.org/blogs/recent-gnu-c-library-improvements
-.. _`rolling release`: https://en.wikipedia.org/wiki/Rolling_release
-.. _`clrtrust`: https://github.com/clearlinux/clrtrust
-.. _`Address space layout randomization (ASLR)`: https://en.wikipedia.org/wiki/Address_space_layout_randomization
-.. _`Kernel address space layout randomization (KASLR)`: https://lwn.net/Articles/569635/
-.. _`cryptsetup`: https://gitlab.com/cryptsetup/cryptsetup/
-.. _`Tallow`: https://github.com/clearlinux/tallow
-
-.. |NVD| raw:: html
-
-    <a href="https://nvd.nist.gov/" target="_blank">https://nvd.nist.gov/</a>
-
-.. |MITRE| raw:: html
-
-    <a href="https://cve.mitre.org/" target="_blank">https://cve.mitre.org/</a>
@@ -1,149 +0,0 @@
-.. _stateless:
-
-Stateless
-#########
-
-In most operating systems, user data, system data, and configuration files
-can become intermingled, which can make them challenging to manage.
-
-.. figure:: figures/stateless-1.png
-   :scale: 45%
-   :align: center
-   :alt: Stateless: User and system files mixed
-
-   Figure 1: Without stateless, user and system files become mixed on the filesystem over time.
-
-|CL-ATTR| has a stateless design philosophy with the goal to provide an
-:abbr:`OS (operating system)` that functions without excessive user
-configuration or customization. Stateless in this context does *not* mean
-ephemeral or non-persistent.
-
-.. contents:: :local:
-   :depth: 1
-
-File-level separation
-*********************
-
-To accomplish a stateless design, the |CL| filesystem hierarchy is separated
-between user-owned areas and |CL|-owned areas.
-
-.. figure:: figures/stateless-2.png
-   :scale: 45%
-   :align: center
-   :alt: Stateless: User and system files separation
-
-   Figure 2: With stateless, user and system files are separated on the filesystem.
-
-System area
-===========
-Files under the :file:`/usr` directory are managed by |CL| as system files
-(except :file:`/usr/local`).
-Files written under the :file:`/usr` directory by users can get removed
-through system updates with :ref:`swupd <swupd-guide>`. This operating
-assumption allows |CL| to verify and maintain integrity of system files.
-
-User areas
-==========
-Files under the :file:`/usr/local`, :file:`/etc/`, :file:`/opt`, :file:`/home`,
-and :file:`/var` directories are owned and managed by the user. A freshly
-installed |CL| system will only have a minimal set of files in the
-:file:`/etc/` directory and software installed by |CL| does not write to
-:file:`/etc`. This operating assumption allows |CL| users to clearly identify
-the configuration that makes their system unique.
-
-
-Software configuration
-**********************
-
-With stateless separation, default software configurations are read in order
-from predefined source code, |CL| provided defaults, and user-provided
-configuration.
-
-Default configurations
-======================
-
-Software in |CL| provides default configuration values so that it is
-immediately functional, except for some that require additional configuration.
-
-If an upstream software puts default configurations in multiple locations 
-such as :file:`/usr/` and :file:`/etc`, it will be modified by the |CL| 
-distro to comply with the stateless design.  Also, some default configurations 
-may be modified to close security loopholes.  Defaults will reside 
-under :file:`/usr/share/defaults`.  These files can be referenced as 
-templates for customization.
-
-For example, after installing the `httpd` bundle for Apache web server, its 
-default configurations appear in the :file:`/usr/share/defaults/httpd/` directory.
-
-Overriding configurations
-=========================
-
-If a configuration needs to be changed, the appropriate file should be
-modified by the user under :file:`/etc/`. If the configuration file does not
-already exist, it can be created in the appropriate location.
-
-User-defined configuration files should contain the minimal set of desired
-changes and rely on default configuration for the rest.
-
-For example, a customized Apache configuration can be used instead by:
-
-#. Install the Apache web server bundle.
-
-   .. code-block:: bash
-
-      sudo swupd bundle-add httpd
-
-#. Create the destination directory for the configuration.
-
-   .. code-block:: bash
-
-      sudo mkdir /etc/httpd
-
-#. Copy the default configuration as a reference template.
-
-   .. code-block:: bash
-
-      sudo cp /usr/share/defaults/httpd/httpd.conf /etc/httpd/
-
-#. Make any desired modifications to the configurations.
-
-   .. code-block:: bash
-
-      sudoedit /etc/httpd/httpd.conf
-
-#. Reload the service or reboot the system to pickup any changes.
-
-   .. code-block:: bash
-
-      systemctl daemon-reload httpd && systemctl restart httpd
-
-This pattern can be used to modify the configurations of other programs too.
-The `stateless man page`_ has application-specific examples.
-
-System reset
-************
-
-One advantage of the stateless design is that the system defaults can be
-easily restored by simply deleting everything under :file:`/etc/` and
-:file:`/var`.
-
-Running the commands below effectively performs a system reset as if it was
-just installed:
-
-.. code-block:: bash
-
-   sudo rm -rf /etc
-   sudo rm -rf /var
-
-In other Linux distributions, this can be a catastrophic action that may render
-a system unable to boot and/or inaccessible.
-
-Additional information
-**********************
-
-* `stateless man page`_
-* :ref:`firmware`
-
-.. _`stateless man page`: https://github.com/clearlinux/clr-man-pages/blob/master/stateless.7.rst
-
-
@@ -1,281 +0,0 @@
-.. _swupd-3rd-party:
-
-swupd 3rd-party 
-###############
-
-Upstream |CL| offers a plethora of `bundles`_ to choose from.  
-
-For users who want access to additional software outside of the distro, 
-|CL| provides support for 3rd-party bundles.  
-
-There are two components to 3rd-party bundles:
-
-* Use :command:`mixer` to create 3rd-party bundles
-
-* Use the :command:`swupd` subcommand :command:`3rd-party` to manage repos, 
-  consume and manage bundles
-
-Follow this guide to set up a web server to host 3rd-party bundles, 
-build an example 3rd-party bundle, install and manage the bundle on a 
-client system. 
-
-.. contents::
-   :local:
-   :depth: 1
-
-Also, see our `general guidelines`_ on sharing 3rd-party bundles.  
-
-Prerequisite
-*************
-
-* Familiarity with :command:`mixer`
-* Familiarity with :command:`swupd`
-* You must be running |CL| version 32570 or higher
-
-.. include:: ./mixer.rst
-   :start-after: set-up-nginx-web-server-start:
-   :end-before: set-up-nginx-web-server-end:
-
-Create directory to hold 3rd-party app
-**************************************
-
-#. Create a top-level directory to hold all apps.
-	
-   .. code-block:: bash
-      
-      mkdir ~/my-3rd-party-apps && pushd $_
-
-#. Create a directory for each app and put the content of your software in it.  
-
-   In this example, the `helloclear.sh` app simply prints
-   "Hello Clear!" when invoked.  
-
-   .. code-block:: bash
-
-      # make helloclear directory
-      mkdir -p helloclear/usr/bin && pushd $_
-
-      # create helloclear.sh script
-      cat > helloclear.sh << EOF
-      #!/bin/bash
-      echo "Hello Clear!"
-      EOF
-
-      # make script executable
-      chmod +x helloclear.sh
-
-      popd
-
-   .. note:: 
-      
-      * You can put whatever you want in your app's directory. All of the content 
-        within each directory will get copied onto the client system under 
-        :file:`/opt/3rd-party/bundles/<repo-name>/`.
-
-      * To use a 3rd-party RPM, it is recommended to extract the content of the RPM 
-        into a directory.  Use :command:`rpm2cpio <RPM>| sudo cpio -idv`.
-       
-Create bundle of 3rd-party app with mixer
-*****************************************
-
-Next, use :command:`mixer` to create a bundle for each of the apps from the previous 
-section.  
-
-#. Install the mixer tool.
-   
-   .. code-block:: bash
-
-      sudo swupd bundle-add mixer
-
-#. Create a mixer workspace.
-   
-   .. code-block:: bash
-
-      mkdir ~/mixer && cd $_
-
-#. Initialize a mix without any default bundles.
-   
-   .. code-block:: bash
-
-      mixer init --no-default-bundles
-
-#. Configure :file:`builder.conf` to set the default bundle, CONTENTURL, and VERSIONURL.  
-   For the "URL"s in this example, it will be IP address of the web server that was
-   set up earlier.
-   Substitute <IP-address-of-web-server> with the IP address of your host.  
-
-   .. code-block:: bash
-      
-      mixer config set Swupd.BUNDLE "os-core"
-      mixer config set Swupd.CONTENTURL "http://<IP-address-of-web-server>"
-      mixer config set Swupd.VERSIONURL "http://<IP-address-of-web-server>"
-
-#. Create an empty local `os-core` bundle.  :command:`swupd` client expects the 
-   `os-core` bundle to exist in a mix even if it’s empty.
-
-   .. code-block:: bash
-      
-      mixer bundle create os-core --local
-
-#. Using the `helloclear` app as an example, create the `helloclear` bundle  
-   and use the `content()` directive with the path to the `helloclear` directory in
-   the bundle definition.
-
-   Refer to `bundle definition`_ for addition information on how to define a bundle.
-
-   .. code-block:: bash
-      
-      mixer bundle create helloclear --local
-      echo "content($HOME/my-3rd-party-apps/helloclear/)" >> local-bundles/helloclear
-
-#. Add both bundles to the mix.
-
-   .. code-block:: bash
-      
-      mixer bundle add os-core
-      mixer bundle add helloclear
-
-#. Build the bundles and generate the update content.
-
-   .. code-block:: bash
-      
-      sudo mixer build bundles
-      sudo mixer build update
-
-Install and manage 3rd-party bundle on client system
-****************************************************
-
-Finally, use the :command:`swupd` client tool to install and 
-manage the bundle created with :command:`mixer` earlier.
-All installed 3rd-party bundles reside in :file:`/opt/3rd-party/bundles/<repo-name>/`.
-
-#. First, add a repo link to the web server.
-   The `os-core` bundle will be added automatically when adding a repo.  
-   It contains items that mixer injected into the mix such as version information, 
-   format, CONTENTURL, VERSIONURL, and certificate.
-    
-   .. code-block:: bash
-
-      sudo swupd 3rd-party add my-3rd-party-repo \
-      http://<IP-address-of-web-server> --allow-insecure-http
-
-   .. note::
-      
-      By default, the :command:`swupd` client is designed to communicate 
-      with an HTTPS server. For development purposes, the swupd client 
-      can talk to an HTTP server if you add the flag ``--allow-insecure-http``.
-
-      To avoid adding this flag each time when invoking :command:`swupd`, enter:
-
-      .. code-block:: bash
-
-         sudo mkdir -p /etc/swupd
-
-         sudo tee -a /etc/swupd/config << EOF
-         [GLOBAL]
-         allow-insecure-http=true
-         EOF
-
-#. Query the list of bundles from the repo.
-   
-   .. code-block:: bash
-
-      sudo swupd 3rd-party bundle-list -a 
-
-#. Add the `helloclear` bundle.
-   
-   .. code-block:: bash
-
-      sudo swupd 3rd-party bundle-add helloclear
-
-#. List installed 3rd-party bundles.
-
-   .. code-block:: bash
-
-      sudo swupd 3rd-party bundle-list
-
-#. Look in :file:`/opt/3rd-party` to confirm they were installed there.  
-   
-   .. code-block:: bash
-
-      tree /opt/3rd-party
-
-   Example output:
-   
-   .. code-block:: console
-
-      /opt/3rd-party/
-      ├── bin
-      │   └── helloclear.sh
-      ├── bundles
-      │   └── my-3rd-party-repo
-      │       └── usr
-      │           ├── bin
-      │           │   └── helloclear.sh
-      │           ├── lib
-      │           │   └── os-release
-      │           └── share
-      │               ├── clear
-      │               │   ├── bundles
-      │               │   │   ├── helloclear
-      │               │   │   └── os-core
-      │               │   ├── update-ca
-      │               │   │   └── Swupd_Root.pem
-      │               │   ├── version
-      │               │   └── versionstamp
-      │               └── defaults
-      │                   └── swupd
-      │                       ├── contenturl
-      │                       ├── format
-      │                       └── versionurl
-      └── repo.ini
-
-      12 directories, 12 files
-
-Create more bundles and add to client
-*************************************
-
-From here on, to add new bundles to your mix, follow these steps:
-
-#. Follow the steps above to add a new directory for each app and put content into it.
-
-#. In the mixer workspace, run :command:`mixer versions update`.
-
-#. Follow the remaining mixer process to add and build bundles.  
-
-On the client side:
-
-#. Run :command:`sudo swupd 3rd-party update` to update to the latest version of your mix.
-
-   .. note::
-      
-      If `swupd autoupdate` is enabled, 3rd-party repositories will update 
-      automatically as well during regular swupd update.  
-
-#. Now, you can see and add the new bundles.
-
-Some limitations of 3rd-party bundles
-*************************************
-
-#. You cannot upload your bundles to a shared community repo because bundles
-   are tied to your particular mix with its own certificate. 
-   You have to host your own and share your repo.
-
-#. As with upstream bundles, 3rd-party bundles installation is simply the unpacking 
-   of files onto your system.  It cannot perform pre or post-installation actions such as 
-   adding a favorite shortcut to the Gnome desktop dock, for example.
-
-Related topics
-**************
-
-* :ref:`autospec`
-* :ref:`mixer`
-* :ref:`bundles`
-* :ref:`swupd-guide`
-
-.. _bundles: 
-   https://clearlinux.org/software
-.. _bundle definition:
-   https://docs.01.org/clearlinux/latest/guides/clear/mixer.html#id16
-.. _general guidelines:
-   https://community.clearlinux.org/t/about-the-3rd-party-sw-category/4072
@@ -1,49 +0,0 @@
-.. _guides:
-
-Guides
-######
-
-The following guides provide step-by-step instructions on using |CL|.
-
-.. note::
-
-   As of 22 May 2019 :file:`mixin` is no longer supported.
-
-.. _cl-guides:
-
-Clear Linux
-===========
-
-.. toctree::
-   :maxdepth: 1
-   :glob:
-
-   clear/*
-
-Maintenance
-===========
-
-.. toctree::
-   :maxdepth: 1
-   :glob:
-
-   maintenance/*
-
-Network
-=======
-
-.. toctree::
-   :maxdepth: 1
-   :glob:
-
-   network/*
-
-Kernel
-=======
-
-.. toctree::
-   :maxdepth: 1
-   :glob:
-
-   kernel/*
-
@@ -1,234 +0,0 @@
-.. _change-kernel-boot:
-
-Change Kernel Boot
-########################
-
-This tutorial explains the process of change kernel boot entry |CL-ATTR|.
-
-.. contents::
-   :local:
-   :depth: 1
-
-Description
-***********
-
-For this tutorial, you will modify your kernel list to boot with the kernel you want to use. This process is valid when you cannot compile third-party kernel modules and need to come back to old, or if you compile your custom kernel.
-
-
-Get the current boot status
-***************************
-
-.. code-block:: bash
-
-   bootctl status
-
-This is an example output:
-
-.. code-block:: bash
-
-    System:
-        Firmware: UEFI 2.70 (HP 265.256)
-        Firmware Arch: x64
-        Secure Boot: disabled
-        TPM2 Support: yes
-        Measured UKI: no
-        Boot into FW: supported
-  
-    Current Boot Loader:
-          Product: systemd-boot 255
-         Features: ✓ Boot counting
-                   ✓ Menu timeout control
-                   ✓ One-shot menu timeout control
-                   ✓ Default entry control
-                   ✓ One-shot entry control
-                   ✓ Support for XBOOTLDR partition
-                   ✓ Support for passing random seed to OS
-                   ✓ Load drop-in drivers
-                   ✓ Support Type #1 sort-key field
-                   ✓ Support @saved pseudo-entry
-                   ✓ Support Type #1 devicetree field
-                   ✓ Enroll SecureBoot keys
-                   ✓ Retain SHIM protocols
-                   ✓ Menu can be disabled
-                   ✓ Boot loader sets ESP information
-              ESP: /dev/disk/by-partuuid/ea2e4278-5c0c-4498-bc99-dfc48a71ceb5
-             File: └─/EFI/org.clearlinux/loaderx64.efi
-    
-    Random Seed:
-     System Token: set
-           Exists: yes
-    
-    Available Boot Loaders on ESP:
-              ESP: /boot (/dev/disk/by-partuuid/ea2e4278-5c0c-4498-bc99-dfc48a71ceb5)
-             File: ├─/EFI/systemd/systemd-bootx64.efi (systemd-boot 255)
-                   └─/EFI/BOOT/BOOTX64.EFI (systemd-boot 255)
-    
-    Boot Loaders Listed in EFI Variables:
-            Title: Linux bootloader
-               ID: 0x0007
-           Status: active, boot-order
-        Partition: /dev/disk/by-partuuid/ea2e4278-5c0c-4498-bc99-dfc48a71ceb5
-             File: └─/EFI/org.clearlinux/bootloaderx64.efi
-    
-            Title: Linux Boot Manager
-               ID: 0x0001
-           Status: active, boot-order
-        Partition: /dev/disk/by-partuuid/ea2e4278-5c0c-4498-bc99-dfc48a71ceb5
-             File: └─/EFI/systemd/systemd-bootx64.efi
-    
-            Title: Windows Boot Manager
-               ID: 0x0000
-           Status: active, boot-order
-        Partition: /dev/disk/by-partuuid/48d8a9eb-d84d-4a62-8302-edff383290e5
-             File: └─/EFI/Microsoft/Boot/bootmgfw.efi
-    
-    Boot Loader Entries:
-            $BOOT: /boot (/dev/disk/by-partuuid/ea2e4278-5c0c-4498-bc99-dfc48a71ceb5)
-            token: clear-linux-os
-    
-    Default Boot Loader Entry:
-             type: Boot Loader Specification Type #1 (.conf)
-            title: Clear Linux OS (Clear-linux-native-6.8.10-1434.conf)
-               id: Clear-linux-native-6.8.10-1434.conf
-           source: /boot//loader/entries/Clear-linux-native-6.8.10-1434.conf
-            linux: /boot//EFI/org.clearlinux/kernel-org.clearlinux.native.6.8.10-1434
-           initrd: /boot//EFI/org.clearlinux/freestanding-00-early-ucode.cpio
-                   /boot//EFI/org.clearlinux/initrd-org.clearlinux.native.6.8.10-1434
-                   /boot//EFI/org.clearlinux/freestanding-clr-init.cpio.gz
-                   /boot//EFI/org.clearlinux/freestanding-i915-firmware.cpio
-          options: root=UUID=67e7ac9a-f7a1-4d5e-bbd6-012f5fa81cb5 rd.luks.uuid=abe6aaf2-3425-4eb1-b7f5-3f36746426fa quiet console=tty0 console=ttyS0,115200n8 cryptomgr.notests init=/usr/bin/initra-desktop initcall>
-    lines 20-71/71 (END)
-                   ✓ Support @saved pseudo-entry
-                   ✓ Support Type #1 devicetree field
-                   ✓ Enroll SecureBoot keys
-                   ✓ Retain SHIM protocols
-                   ✓ Menu can be disabled
-                   ✓ Boot loader sets ESP information
-              ESP: /dev/disk/by-partuuid/ea2e4278-5c0c-4498-bc99-dfc48a71ceb5
-             File: └─/EFI/org.clearlinux/loaderx64.efi
-    
-    Random Seed:
-     System Token: set
-           Exists: yes
-    
-    Available Boot Loaders on ESP:
-              ESP: /boot (/dev/disk/by-partuuid/ea2e4278-5c0c-4498-bc99-dfc48a71ceb5)
-             File: ├─/EFI/systemd/systemd-bootx64.efi (systemd-boot 255)
-                   └─/EFI/BOOT/BOOTX64.EFI (systemd-boot 255)
-    
-    Boot Loaders Listed in EFI Variables:
-            Title: Linux bootloader
-               ID: 0x0007
-           Status: active, boot-order
-        Partition: /dev/disk/by-partuuid/ea2e4278-5c0c-4498-bc99-dfc48a71ceb5
-             File: └─/EFI/org.clearlinux/bootloaderx64.efi
-    
-            Title: Linux Boot Manager
-               ID: 0x0001
-           Status: active, boot-order
-        Partition: /dev/disk/by-partuuid/ea2e4278-5c0c-4498-bc99-dfc48a71ceb5
-             File: └─/EFI/systemd/systemd-bootx64.efi
-    
-            Title: Windows Boot Manager
-               ID: 0x0000
-           Status: active, boot-order
-        Partition: /dev/disk/by-partuuid/48d8a9eb-d84d-4a62-8302-edff383290e5
-             File: └─/EFI/Microsoft/Boot/bootmgfw.efi
-    
-    Boot Loader Entries:
-            $BOOT: /boot (/dev/disk/by-partuuid/ea2e4278-5c0c-4498-bc99-dfc48a71ceb5)
-            token: clear-linux-os
-    
-    Default Boot Loader Entry:
-             type: Boot Loader Specification Type #1 (.conf)
-            title: Clear Linux OS (Clear-linux-native-6.8.10-1434.conf)
-               id: Clear-linux-native-6.8.10-1434.conf
-           source: /boot//loader/entries/Clear-linux-native-6.8.10-1434.conf
-            linux: /boot//EFI/org.clearlinux/kernel-org.clearlinux.native.6.8.10-1434
-           initrd: /boot//EFI/org.clearlinux/freestanding-00-early-ucode.cpio
-                   /boot//EFI/org.clearlinux/initrd-org.clearlinux.native.6.8.10-1434
-                   /boot//EFI/org.clearlinux/freestanding-clr-init.cpio.gz
-                   /boot//EFI/org.clearlinux/freestanding-i915-firmware.cpio
-          options: root=UUID=67e7ac9a-f7a1-4d5e-bbd6-012f5fa81cb5 rd.luks.uuid=abe6aaf2-3425-4eb1-b7f5-3f36746426fa quiet console=tty0 console=ttyS0,115200n8 cryptomgr.notests init=/usr/bin/initra-desktop initcall_debug intel_iommu=igfx_off kvm-intel.nested=1 no_timer_check noreplace-smp page_alloc.shuffle=1 rcupdate.rcu_expedited=1 rootfstype=ext4,btrfs,xfs,f2fs tsc=reliable rw module.sig_unenforce rootflags=x-systemd.device-timeout=0
-
-Get the kernel list installed
-*****************************
-
-.. code-block:: bash
-
-   bootctl list
-
-And example output:
-
-.. code-block:: bash
-
-    type: Boot Loader Specification Type #1 (.conf)
-    title: Clear Linux OS (Clear-linux-preempt_rt-6.1.38-105.conf)
-    id: Clear-linux-preempt_rt-6.1.38-105.conf
-    source: /boot//loader/entries/Clear-linux-preempt_rt-6.1.38-105.conf
-    linux: /boot//EFI/org.clearlinux/kernel-org.clearlinux.preempt_rt.6.1.38-105
-    initrd: /boot//EFI/org.clearlinux/freestanding-00-early-ucode.cpio
-            /boot//EFI/org.clearlinux/freestanding-clr-init.cpio.gz
-            /boot//EFI/org.clearlinux/freestanding-i915-firmware.cpio
-    options: root=UUID=67e7ac9a-f7a1-4d5e-bbd6-012f5fa81cb5 rd.luks.uuid=abe6aaf2-3425-4eb1-b7f5-3f36746426fa quiet console=tty0 console=ttyS0,115200n8 cryptomgr.notests init=/usr/bin/initra-desktop initcall_debug intel_iommu=igfx_off kvm-intel.nested=1 no_timer_check noreplace-smp page_alloc.shuffle=1 rcupdate.rcu_expedited=1 rootfstype=ext4,btrfs,xfs t>
-
-    type: Boot Loader Specification Type #1 (.conf)
-    title: Clear Linux OS (Clear-linux-native-6.9.1-1436.conf)
-    id: Clear-linux-native-6.9.1-1436.conf
-    source: /boot//loader/entries/Clear-linux-native-6.9.1-1436.conf
-    linux: /boot//EFI/org.clearlinux/kernel-org.clearlinux.native.6.9.1-1436
-    initrd: /boot//EFI/org.clearlinux/freestanding-00-early-ucode.cpio
-            /boot//EFI/org.clearlinux/initrd-org.clearlinux.native.6.9.1-1436
-            /boot//EFI/org.clearlinux/freestanding-clr-init.cpio.gz
-            /boot//EFI/org.clearlinux/freestanding-i915-firmware.cpio
-    options: root=UUID=67e7ac9a-f7a1-4d5e-bbd6-012f5fa81cb5 rd.luks.uuid=abe6aaf2-3425-4eb1-b7f5-3f36746426fa quiet console=tty0 console=ttyS0,115200n8 cryptomgr.notests init=/usr/bin/initra-desktop initcall_debug intel_iommu=igfx_off kvm-intel.nested=1 no_timer_check noreplace-smp page_alloc.shuffle=1 rcupdate.rcu_expedited=1 rootfstype=ext4,btrfs,xfs,f>
-
-    type: Boot Loader Specification Type #1 (.conf)
-    title: Clear Linux OS (Clear-linux-native-6.8.10-1434.conf) (default) (selected)
-    id: Clear-linux-native-6.8.10-1434.conf
-    source: /boot//loader/entries/Clear-linux-native-6.8.10-1434.conf
-    linux: /boot//EFI/org.clearlinux/kernel-org.clearlinux.native.6.8.10-1434
-    initrd: /boot//EFI/org.clearlinux/freestanding-00-early-ucode.cpio
-            /boot//EFI/org.clearlinux/initrd-org.clearlinux.native.6.8.10-1434
-            /boot//EFI/org.clearlinux/freestanding-clr-init.cpio.gz
-            /boot//EFI/org.clearlinux/freestanding-i915-firmware.cpio
-    options: root=UUID=67e7ac9a-f7a1-4d5e-bbd6-012f5fa81cb5 rd.luks.uuid=abe6aaf2-3425-4eb1-b7f5-3f36746426fa quiet console=tty0 console=ttyS0,115200n8 cryptomgr.notests init=/usr/bin/initra-desktop initcall_debug intel_iommu=igfx_off kvm-intel.nested=1 no_timer_check noreplace-smp page_alloc.shuffle=1 rcupdate.rcu_expedited=1 rootfstype=ext4,btrfs,xfs,f>
-
-    type: Automatic
-    title: Reboot Into Firmware Interface
-    id: auto-reboot-to-firmware-setup
-    source: /sys/firmware/efi/efivars/LoaderEntries-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f
-
-Set default kernel to boot
-**************************
-
-You can check the id from the latest command:
-
-.. code-block:: bash
-
-   bootctl list |grep id: |cut -f 2 -d ":"
-     id: Clear-linux-preempt_rt-6.1.38-105.conf
-     id: Clear-linux-native-6.9.1-1436.conf
-     id: Clear-linux-native-6.8.10-1434.conf
-     id: auto-reboot-to-firmware-setup
-
-
-Set the kernel
-
-.. code-block:: bash
-
-   sudo bootctl set-default ID
-
-For example to set 6.9.1 entry:
-
-.. code-block:: bash
-
-   sudo bootctl set-default Clear-linux-native-6.9.1-1436.conf
-
-Just reboot
-
-.. code-block:: bash
-
-   sudo systemctl reboot
-
-You will boot with the kernel set before.
@@ -1,69 +0,0 @@
-.. _kernel-boot-msg:
-
-Capture Kernel Boot Messages in the Journal
-###########################################
-
-By default |CL| does not capture kernel boot messages in the journal logs, 
-where they're reported as "Missed" messages.  This design decision was made 
-to provide a faster boot performance.  On the other hand, if you wish to 
-see the messages, follow this guide.
-
-Here's an example a journal log with "Missed" messages:
-
-.. code-block:: console
-   :linenos:
-   :emphasize-lines: 4
-
-   -- Reboot --
-   Apr 10 19:55:43 kernel systemd-journald[300]: Journal started
-   Apr 10 19:55:43 kernel systemd-journald[300]: Runtime Journal (/run/log/journal/d01862ca79d1064ea379cd715cfdd53a) is 5.8M, max 47.0M, 41.1M free.
-   Apr 10 19:55:43 kernel systemd-journald[300]: Missed 2233 kernel messages
-   Apr 10 19:55:43 kernel systemd[1]: Started Journal Service.
-
-.. contents::
-   :local:
-   :depth: 1
- 
-Prerequisites
-*************
-
-* `systemd-journald` version 245 and higher 
-
-Enable journaling of kernel boot messages
-*****************************************
-
-#. Open a terminal window.
-
-#. Create a base journald configuration file.
-
-   .. code-block:: bash
-
-      sudo mkdir -p /etc/systemd/journald.conf.d
-      sudo cp /usr/lib/systemd/journald.conf.d/clear.conf /etc/systemd/journald.conf.d/
-
-#. Append :command:`BootKMsg=true` to it.
-   
-   .. code-block:: bash
-
-      echo "BootKMsg=true" | sudo tee -a /etc/systemd/journald.conf.d/clear.conf
-
-#. Reboot.  
-
-.. tip::
-
-   If you need to increase the kernel buffer length (for example, 1M), do this: 
-
-   .. code-block:: bash
-   
-      sudo mkdir -p /etc/kernel/cmdline.d/
-      echo "log_buf_len=1M" | sudo tee /etc/kernel/cmdline.d/log_buf_len.conf
-      sudo clr-boot-manager update
-
-Alternative
-***********
-
-An alternative is to use :command:`dmesg`.  
-
-.. code-block:: bash
-
-   sudo dmesg 
@@ -1,228 +0,0 @@
-.. _kernel-modules:
-
-Add kernel modules manually
-###########################
-
-This guide describes how to add kernel modules manually.
-
-.. contents:: :local:
-   :depth: 1
-   :backlinks: top
-
-Overview
-********
-
-Certain kernel modules are enabled by default in |CL-ATTR|. To use additional
-kernel modules that are not part of the Linux source tree, you may need to
-build out-of-tree kernel modules. Use this guide to add kernel modules
-manually, or refer to :ref:`kernel-modules-dkms`.
-
-Description
-***********
-
-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).
-
-
-.. _kernel-modules-availability-begin:
-
-Kernel module availability
-**************************
-
-|CL| comes with many upstream kernel modules available for use. 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.
-
-Before continuing, check if the kernel module you're looking for is already
-available in |CL| or submit a request to add the module.
-
-
-Check if the module is already available
-========================================
-
-
-You can search for kernel module file names, which end with the :file:`.ko`
-file extension, using the :command:`swupd search` command, as shown in the
-following example. See :ref:`swupd-guide` for more information.
-
-.. code-block:: bash
-
-   sudo swupd search ${module_name}.ko
-
-
-Submit a request to add the module
-==================================
-
-If the kernel module you need is already open source (for example, in the
-Linux kernel upstream) and likely to be useful to others, consider submitting
-a request to add or enable it in the |CL| kernel.
-
-Make enhancement requests to the |CL| `Distribution Project on GitHub
-<https://github.com/clearlinux/distribution>`_.
-
-.. _kernel-modules-availability-end:
-
-
-Build, install, and load an out-of-tree module
-**********************************************
-
-Follow the steps in this section if you are an individual user or testing, and
-you need an out-of-tree kernel module that is not available through |CL|. For
-a more scalable and customizable approach, we recommend using the
-:ref:`mixer` to provide a custom kernel and updates.
-
-
-Prerequisites
-=============
-
-Before you begin, you must:
-
-* Disable Secure Boot.
-* Disable kernel module integrity checking.
-* Have a kernel module package in the form of source code.
-* Rebuild the module against new versions of the Linux kernel.
-
-.. note::
-
-   Any time the kernel is upgraded on your Clear Linux system, you must
-   rebuild your out-of-tree modules.
-
-
-Build and install kernel module
-===============================
-
-#. Determine which kernel variant is running on |CL|. In the example below,
-   the *native* kernel is in use.
-
-   .. code-block:: bash
-
-      $ uname -r
-      5.XX.YY-ZZZZ.native
-
-#. Install the kernel dev bundle corresponding to the installed kernel. The
-   kernel dev bundle contains the kernel headers, which are placed under
-   :file:`/usr/lib/modules/$(uname -r)/build/include/` and are required to
-   compile kernel modules. For example:
-
-   * :command:`linux-dev` for developing against the native kernel.
-   * :command:`linux-lts-dev` for developing against the LTS kernel.
-
-   .. code-block:: bash
-
-      sudo swupd bundle-add linux-dev
-
-   
-
-#. Follow instructions from the kernel module source code to compile the
-   kernel module. For example:
-
-   .. code-block:: bash
-
-      curl -O http://<URL-TO-KERNEL-MODULE-SOURCE>.tar.gz
-      tar -xvf <KERNEL-MODULE-SOURCE>.tar.gz
-      cd <KERNEL-MODULE-SOURCE>/
-      cat README
-
-
-
-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 that
-   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::
-
-      If successful, the :command:`clr-boot-manager update` command does not
-      return any console output.
-
-#. After rebooting, manually load out-of-tree modules using the
-   :command:`insmod` command.
-
-   .. code-block:: bash
-
-      sudo insmod </PATH/TO/MODULE.ko>
-
-Examples
-********
-
-.. _kernel-modules-autoload-begin:
-
-Optional: Specify module options and aliases
-============================================
-
-Use the :command:`modprobe` command to load a module and set options.
-
-:command:`modprobe` may add or remove more than one module due to module
-interdependencies. You can specify which options to use with individual
-modules, by using 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. You can
-use :file:`.conf` files to create convenient aliases for modules or to
-override the normal loading behavior altogether for those with special
-requirements.
-
-Learn more about :command:`modprobe` on 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.
-
-Learn more about module loading in the modules-load.d manual page:
-
-.. code-block:: bash
-
-   man modules-load.d
-
-
-.. _kernel-modules-autoload-end:
-
-Related topic
-*************
-
-* :ref:`kernel-modules-dkms`
-
@@ -1,159 +0,0 @@
-.. _openssh-server:
-
-Enable and configure SSH service
-################################
-
-This guide describes how to set up the SSH service.
-
-.. contents::
-   :local:
-   :depth: 1
-
-Overview
-********
-
-The :command:`openssh-server` bundle provides the OpenSSH package that
-enables an SSH service in |CL-ATTR|. Remote users require an SSH service to be
-able to use an encrypted login shell. The SSH daemon has all of its configuration built in and no template configuration file is present on the file system.
-
-|CL| enables the `sshd.socket` unit, which listens on port 22 by default
-and starts the OpenSSH service as required. The first time OpenSSH starts, it
-generates the server SSH keys needed for the service.
-
-Prerequisites
-*************
-
-Ensure the :command:`openssh-server` bundle is installed.
-
-To list all bundles on your host, enter:
-
-.. code-block:: bash
-
-   sudo swupd bundle-list
-
-To add the :command:`openssh-server` bundle, enter:
-
-.. code-block:: bash
-
-   sudo swupd bundle-add openssh-server
-
-Change default port
-*******************
-
-Perform the following steps to change the default listening port for the
-OpenSSH service.
-
-#. Open the :file:`sshd.socket` file:
-
-   .. code-block:: bash
-
-      sudo systemctl edit sshd.socket
-
-#. Add the `[Socket]` section and `ListenStream` option to the sshd.socket
-   file as shown below. The first `ListenStream` entry removes the |CL|
-   default listen port value. The second `ListenStream` entry sets the new
-   default listen port value. In this example, we set the new default port
-   to 4200:
-
-   .. code-block:: console
-
-      [Socket]
-      ListenStream=
-      ListenStream=4200
-
-
-   Make sure to include a new line after the last line of text in the :file:`sshd.socket` file.
-
-#. Verify your changes:
-
-   .. code-block:: bash
-
-      cat /etc/systemd/system/sshd.socket.d/override.conf
-
-   The following output is displayed:
-
-   .. code-block:: console
-
-      [Socket]
-      ListenStream=
-      ListenStream=4200
-
-#. Reload the systemd daemon configurations:
-
-   .. code-block:: bash
-
-      sudo systemctl daemon-reload
-
-#. Restart the sshd.socket unit:
-
-   .. code-block:: bash
-
-      sudo systemctl restart sshd.socket
-
-#. Confirm the sshd.socket unit is listening on your new port:
-
-   .. code-block:: bash
-
-      sudo systemctl status sshd.socket
-
-   .. note::
-
-      Output should show :guilabel:`Active:` as `active(listening)`.
-
-Enable SFTP
-***********
-
-|CL| *disables* the :abbr:`SFTP (SSH File Transfer Protocol)` subsystem by
-default due to security considerations. To enable the SFTP subsystem, you can
-configure the :file:`/etc/ssh/sshd_config` file.
-
-#. Create the following file, if it does not already exist:
-   :file:`/etc/ssh/sshd_config`
-
-#. Add the the SFTP subsystem in :file:`/etc/ssh/sshd_config`:
-
-   .. code-block:: console
-
-      subsystem sftp /usr/libexec/sftp-server
-
-
-Congratulations! The SFTP subsystem is enabled. You do not need to restart the sshd service.
-
-Enable root login
-*****************
-
-To enable root login via SSH, perform the following steps:
-
-
-#. Create the following file, if it does not already exist:
-   :file:`/etc/ssh/sshd_config`
-
-#. Set the configuration variable in :file:`/etc/ssh/sshd_config`:
-
-   .. code-block:: console
-
-      PermitRootLogin yes
-
-You have now enabled root login on your system.  You do not need to restart the sshd service. 
-
-Enable X11-forwarding
-*********************
-
-X11 forwarding allows you to securely run graphical applications (that is, X
-clients) over the SSH connection. This enables remote GUI apps without the need
-for full VNC or remote desktop setup. To enable X11-forwarding via SSH,
-perform the following steps:
-
-#. Create the following file, if it does not already exist:
-   :file:`/etc/ssh/sshd_config`
-
-#. Set the following configuration variables.
-
-   .. code-block:: bash
-
-      AllowTcpForwarding yes
-      X11UseLocalhost yes
-      X11DisplayOffset 10
-      X11Forwarding yes
-
-You have now enabled X11-forwarding!  You do not need to restart the sshd service.
@@ -1,116 +0,0 @@
-.. _proxy:
-
-Proxy Configuration
-###################
-
-When working behind a corporate proxy server, one typically has to configure
-proxy settings for applications to reach the Internet.  |CL-ATTR| has 
-implemented an :ref:`autoproxy` feature to try and eliminate manual 
-configurations as much as possible.  However, there are still some applications 
-that cannot take full advantage of the :ref:`autoproxy` feature due to their 
-own ways of configuring proxy settings.  This guide shows you how to configure 
-proxy settings for some of the known applications manually.  
-
-.. contents::
-    :local:
-    :depth: 1
-
-Prerequisites
-*************
-
-* You have installed |CL| on your host system.
-
-  For detailed instructions on installing |CL| on a bare metal system, visit
-  the :ref:`bare metal installation guide <bare-metal-install-desktop>`.
-
-General proxy settings for many applications
-============================================
-
-#. First, apply these general proxy settings which should work for many 
-   applications.  If they do not work for a specific application, such as the 
-   ones listed below, apply application-specific proxy settings as needed.
-
-   Proxy settings:
-
-   .. code-block:: none
-
-      export http_proxy=http://<YOUR.HTTP-PROXY.URL:PORT>
-      export https_proxy=http://<YOUR.HTTPS-PROXY.URL:PORT>
-      export ftp_proxy=http://<YOUR.FTP-PROXY.URL:PORT>
-      export socks_proxy=http://<YOUR.SOCKS-PROXY.URL:PORT>
-      export no_proxy="<YOUR-DOMAIN>,localhost"
-      export HTTP_PROXY=$http_proxy
-      export HTTPS_PROXY=$https_proxy
-      export FTP_PROXY=$ftp_proxy
-      export SOCKS_PROXY=$socks_proxy
-      export NO_PROXY=$no_proxy
-
-   * *User-specific*, put them in :file:`$HOME/.bashrc`.
-
-   * *For all users*, put them in :file:`/etc/profile.d/proxy.conf`. 
-
-#. For the proxies to take effect, either :command:`source` the file manually
-   or log out and log back in.
-
-Docker\*
-========
-
-Please refer the official Docker links on how to configure proxies:
-
-* `Docker client`_
-* `Docker daemon`_
-
-git over SSH
-============
-
-Add the following to your :file:`~/.ssh/config` file:
-
-.. code-block:: none
-
-   host github.com
-        port 22
-        user git
-        ProxyCommand connect-proxy -S <YOUR.SSH-PROXY.URL:PORT> %h %p
-
-.. note::
-
-   Though :command:`netcat` is included with |CL|, it is not the BSD version,
-   which is the one usually used to enable git over SSH.
-
-autospec/mock
-=============
-
-:ref:`autospec` uses mock to do builds.  Configure mock's proxy settings with
-these steps:  
-
-#. Override the general mock configuration file with a custom one, otherwise
-   your settings will get overwritten each time autospec is updated.
-
-   .. code-block:: bash
-
-      sudo mkdir -p /etc/mock
-      sudo cp ~/clearlinux/projects/common/conf/clear.cfg /etc/mock/clear-custom.cfg
-
-#. :command:`sudoedit` :file:`/etc/mock/clear-custom.cfg` and add the highlighted
-   lines.
-
-   .. code-block:: none
-      :emphasize-lines: 3-5
-
-      ...
-      config_opts['use_bootstrap_container'] = False
-      config_opts['http_proxy'] = '<YOUR.HTTP.PROXY.URL>:<PORT>'
-      config_opts['https_proxy'] = '<YOUR.HTTPS.PROXY.URL>:<PORT>'
-      config_opts['no_proxy'] = '<YOUR.DOMAIN>,192.168.0.0/16,localhost,127.0.0.0/8'
-
-Kubernetes
-==========
-
-See :ref:`Setting proxy servers for Kubernetes <kubernetes>`.
-
-.. _Docker client:
-   https://docs.docker.com/network/proxy/#configure-the-docker-client
-
-.. _Docker daemon:
-   https://docs.docker.com/config/daemon/systemd/#httphttps-proxy
-
@@ -1,114 +0,0 @@
-.. _compatible-hardware:
-
-Compatible Hardware
-###################
-
-This document describes hardware that has been tested and confirmed as
-compatible with |CL-ATTR|. This list is not comprehensive and will continue to
-grow.
-
-.. list-table:: **Table 1. Compatible Hardware**
-    :widths: 20, 20
-    :header-rows: 1
-
-    * - Processor
-      - Platform
-
-    * - Intel® Core™ i5-6260U processor
-      -
-
-    * - Intel® Core™ i5-6560U processor
-      - Dell XPS\* 13 9350
-
-    * - Intel® Celeron® J3455 processor
-      - NUC6CAYS
-
-    * - Intel® Core™ i5-4250U processor
-      -
-
-    * - Intel® Core™ i7-5557U processor
-      -
-
-    * - Intel® Core™ i9-7900X X-series processor
-      - Gigabyte\* X299
-
-    * - Intel® Core™ i3-4130 processor
-      - Lenovo Thinkserver\* TS140
-
-    * - Intel® Core™ i7-7567U processor
-      - NUC7i7BNH
-
-    * - Intel® Core™ i7-8809G processor
-      - NUC8i7HVK
-
-    * - Intel® Core™ i5-7260U processor
-      - NUC7i5BNH
-
-    * - Intel® Core™ i7-8650U processor
-      - NUC7i7DNKE
-
-    * - Intel® Core™ i5-7300U processor
-      - NUC7i5DNHE
-
-    * - Intel® Xeon® Gold 6138 processor
-      -
-
-    * - Intel® Xeon® E5-2699A v4 processor
-      - Dell PowerEdge\* R630
-
-    * - Intel® Xeon® E5-2620 v3 processor
-      -
-
-    * - Intel® Core™ i5-6600 processor
-      - Gigabyte\* Z170X-UD5
-
-    * - Intel® Core™ i5-4250U processor
-      - D54250WYK
-
-    * - Intel® Xeon® E5-2699 v3 processor
-      - S2600WT2
-
-    * - Intel Atom™ J3455 processor
-      - NUC6CAYB
-
-    * - Intel® Xeon® Bronze 3104 processor
-      - 0W23H8
-
-    * - Intel Atom™ C2750 processor
-      - SuperMicro\* A1SAi
-
-    * - Intel Atom™ E3825 processor
-      - CircuitCo MinnowBoard MAX\*
-
-    * - Intel® Core™ i7-8700 processor
-      - Gigabyte\* H370 WIFI
-
-    * - Intel® Core™ i7-3667U processor
-      - Lenovo ThinkPad\* X1 Carbon laptop
-
-    * - Intel® Core™ i5-4210U processor
-      - Dell XPS\* 13 laptop
-
-    * - Intel® Celeron® J3455 processor
-      - NUC6CAYB
-
-    * - Intel® Core™ i7-4790 processor
-      - Gigabyte\* desktop
-
-    * - Intel® Core™ i5-6260U processor
-      - NUC6I6SYH
-
-    * - Intel® Core™ i7-5557U processor
-      - NUC5I7RYH
-
-    * - Intel® Core™ i7-4700MQ processor
-      - Lenovo ThinkPad\* T540p
-
-    * - Intel® Core™ i7-5557U processor
-      - NUC5I7RYB
-
-    * - Intel® Core™ i5-6260U processor
-      - NUC6I5SYH
-
-*Intel, Celeron, Xeon, Intel Atom, and Intel Core are trademarks of Intel
-Corporation or its subsidiaries.*
@@ -1,17 +0,0 @@
-.. _reference:
-
-Reference
-#########
-
-This section provides additional information on the |CL| project and
-features.
-
-.. toctree::
-   :maxdepth: 1
-
-   compatible-hardware
-   bundles/bundles
-   system-requirements
-   image-types
-   man-pages
-   tutorial-ratings
@@ -1,95 +0,0 @@
-.. _man-pages:
-
-Man pages
-#########
-
-These pages are generated from `Clear Linux\* tool
-repositories <https://github.com/clearlinux>`__. Updated |today|.
-
-
-`clr-man-pages <https://github.com/clearlinux/clr-man-pages>`__
-===============================================================
-
-.. toctree::
-   :maxdepth: 1
-
-   manpages/stateless.7.rst
-   manpages/os-core.7.rst
-   manpages/os-format.7.rst
-
-`clr-power-tweaks <https://github.com/clearlinux/clr-power-tweaks>`__
-=====================================================================
-
-.. toctree::
-   :maxdepth: 1
-
-   manpages/clr-power-tweaks.conf.5.rst
-   manpages/clr_power.1.rst
-
-`clrtrust <https://github.com/clearlinux/clrtrust>`__
-=====================================================
-
-.. toctree::
-   :maxdepth: 1
-
-   manpages/clrtrust.1.rst
-
-`micro-config-drive <https://github.com/clearlinux/micro-config-drive>`__
-=========================================================================
-
-.. toctree::
-   :maxdepth: 1
-
-   manpages/ucd.1.rst
-   manpages/cloud-config.5.rst
-   manpages/ucd-data-fetch.1.rst
-
-`mixer-tools <https://github.com/clearlinux/mixer-tools>`__
-===========================================================
-
-.. toctree::
-   :maxdepth: 1
-
-   manpages/mixer.bundle.1.rst
-   manpages/mixer.build.1.rst
-   manpages/mixer.add-rpms.1.rst
-   manpages/mixer.1.rst
-   manpages/mixer.repo.1.rst
-   manpages/mixer.versions.1.rst
-   manpages/mixer.init.1.rst
-   manpages/mixer.config.1.rst
-
-`swupd-client <https://github.com/clearlinux/swupd-client>`__
-=============================================================
-
-.. toctree::
-   :maxdepth: 1
-
-   manpages/swupd-update.service.4.rst
-   manpages/update-triggers.target.4.rst
-   manpages/swupd.1.rst
-   manpages/swupd-update.timer.4.rst
-
-`tallow <https://github.com/clearlinux/tallow>`__
-=================================================
-
-.. toctree::
-   :maxdepth: 1
-
-   manpages/tallow.1.rst
-   manpages/tallow.conf.5.rst
-   manpages/tallow.patterns.5.rst
-
-`telemetrics-client <https://github.com/clearlinux/telemetrics-client>`__
-=========================================================================
-
-.. toctree::
-   :maxdepth: 1
-
-   manpages/telemetrics.conf.5.rst
-   manpages/telem-record-gen.1.rst
-   manpages/telempostd.1.rst
-   manpages/telemprobd.1.rst
-   manpages/telemctl.1.rst
-   manpages/telemetry.3.rst
-
@@ -1,273 +0,0 @@
-cloud-config
-============
-
-`cloud-config(5) <cloud-config.5.html>`__ – User data format used by `ucd(1) <ucd.1.html>`__
-
-SYNOPSIS
--------
-
-``user-data``
-
-``#cloud-config``
-
-cloud-config data is provided by the cloud infrastructure to a cloud
-instance. This data is parsed by ``cloud-init(1)`` which then configures
-the cloud instance based on the information in the cloud-config.
-
-DESCRIPTION
-----------
-
-The user-data as provided can be of several formats. ``cloud-init(1)``
-supports the ``cloud-config`` format, but also supports generic shell
-scripts. If the user-data starts with ``#!``, it is assumed that the
-user-data is a generic shell script, and ``cloud-init`` will attempt to
-execute the data as a script. If the user-data starts with the
-``#cloud-config`` stanza, it is assumed the user-data is in the
-``cloud-config`` format, described below.
-
-The ``cloud-config`` format is used to structure configuration data
-provided to the cloud instance. This data is structured in the YAML
-format (``http://yaml.org``). Note that ``cloud-init``\ (1) uses the
-libyaml library, which supports YAML version 1.1.
-
-In the YAML content, the root node (the document) contains a sequence of
-directives. These directives inform cloud-init that the content of the
-directive are processed by a directive-specific handler, or “module”.
-
-cloud-init includes many modules, each expecting a specifically
-constructed content. This document lists the correct format and
-organization of each data section for the supported modules, describes
-their effect, and states various parameters for each option.
-
-Table of implemented directives. Column 3 (“Ref”) and column 4
-(“CoreOS”) list whether the reference specification or the CoreOS
-implementation support these directives. Note that implementation
-details may differ, due to the underlying differences in Operating
-Systems.
-
-::
-
-   Directive           |Description                          |Ref. |CoreOS.
-   --------------------|-------------------------------------|-----|-------
-   groups              |Configure user account groups        |yes  |no
-   package_upgrade     |Perform a software update            |yes  |no
-   packages            |Install additional software          |yes  |no
-   runcmd              |Execute system commands              |yes  |no
-   service             |Perform system service configuration |no   |no
-   ssh_authorized_keys |Provision SSH public keys            |yes  |yes
-   users               |Configure user accounts              |yes  |yes
-   write_files         |Write content to arbitrary files     |yes  |yes
-   hostname            |Define the system's hostname         |yes  |yes
-   envar               |Set environment variables            |no   |no
-   bootcmd             |Execute system commands on first boot|no   |no
-   wait_for_network    |Halt execution until network is up   |no   |no
-
-OPTIONS
-------
-
-For each of the directives listed in the table above, zero or more
-options may be provided. The list below documents the implemented
-options per directive. The “Type” field values are:
-
-TYPES
-~~~~~
-
-::
-
-   Type       |Description
-   -----------|-------------------------------------------------------------------
-   boolean    |Either true, false, yes, no, 0 or 1 (upper case and initial capitol
-              |letter versions treated identical)
-   string     |A generic string encoded value. Can be multiline or YAML encoded
-              |content
-   integer    |A string encoded decimal integer value
-   octal      |A string encoded octal integer value
-   hex        |A string encoded hexadecimal integer value
-   []         |if a type is listed with [] appended, it means there may be zero or
-              |more values, lists of values or any arbitrary depth of these nested
-   *          |Indicates this value isn't a separate key, but directly the
-              |associated value of the root node. This is applicable for directives
-              |that only have a single configuration parameter,
-              |e.g. "package_upgrade"
-
-groups
-~~~~~~
-
-::
-
-   Option    |Type     |Required    |Function
-   ----------|---------|------------|-----------------------------------
-   name      |string[] |no          |Create a new user account group and
-             |         |            |place listed user account names in
-             |         |            |that group
-
-package_upgrade
-~~~~~~~~~~~~~~~
-
-::
-
-   Option    |Type     |Required    |Function
-   ----------|---------|------------|-----------------------------------
-   *         |boolean  |yes         |Enables or disables whether software
-             |         |            |update is performed
-
-This option implies the ``wait_for_network`` option.
-
-packages
-~~~~~~~~
-
-::
-
-   Option    |Type     |Required    |Function
-   ----------|---------|------------|-----------------------------------
-   name      |string[] |no          |Enables installation of software bundles
-
-This option implies the ``wait_for_network`` option.
-
-runcmd
-~~~~~~
-
-::
-
-   Option    |Type     |Required    |Function
-   ----------|---------|------------|-----------------------------------
-   *         |string[] |no          |Executes a command, if the item is a list,
-             |         |            |the list will be converted to a string
-             |         |            |and executed as a command line.
-
-hostname
-~~~~~~~~
-
-::
-
-   Option    |Type     |Required    |Function
-   ----------|---------|------------|-----------------------------------
-   *         |string   |yes         |Defines the system's hostname
-
-service
-~~~~~~~
-
-::
-
-   Option    |Type     |Required    |Function
-   ----------|---------|------------|-----------------------------------
-   start     |string[] |no          |Start units
-   stop      |string[] |no          |Stop units
-   restart   |string[] |no          |Restart units
-   enable    |string[] |no          |Enable units to start automatically
-   disable   |string[] |no          |Disable units from starting automatically
-   reload    |string[] |no          |Reload service units
-   isolate   |string[] |no          |Change target to a new unit
-   mask      |string[] |no          |Prevent units from starting
-   unmask    |string[] |no          |Remove unit start prevention mask
-
-ssh_authorized_keys
-~~~~~~~~~~~~~~~~~~~
-
-::
-
-   Option    |Type     |Required    |Function
-   ----------|---------|------------|-----------------------------------
-   *         |string[] |no          |Specifies an SSH public key value, as
-             |         |            |string. This will be added to the default
-             |         |            |user account's SSH configuration
-
-users
-~~~~~
-
-::
-
-   Option    |Type     |Required    |Function
-   ----------|---------|------------|-----------------------------------
-   *         |[]       |no          |This directive expects a list of user
-             |         |            |definitions. Each definition can
-             |         |            |additionally specify the following
-             |         |            |sub-options:
-   name      |string   |yes         |A user account name to be created
-   gecos     |string   |no          |A real user name, can be left empty
-   homedir   |string   |no          |A home directory path. Default under "/home"
-   primary-group|string|no          |A group name.
-   groups    |string   |no          |Comma-separated list of group names or
-             |         |            |single group name. Specifies additional
-             |         |            |groups to put this user account into
-   lock-passwd|boolean |no          |Lock the user account
-   inactive  |boolean  |no          |Mark the user account as inactive
-   passwd    |string   |no          |Password hash for the user account
-   no-create-home|boolean|no        |Omits creating a home directory
-   no-user-group|boolean|no         |Omits group creating for the account
-   no-log-init|boolean |no          |Omits this account from lastlog/faillog
-   expiredate|string   |no          |A date at which to expire the password
-   ssh-authorized-keys|string[]|no  |Add SSH public keys to ssh configuration
-   sudo      |string[] |no          |Add sudoers lines for this account, the account
-             |         |            |name is automatically prepended
-   system    |boolean  |no          |Make the account a system account
-
-write_files
-~~~~~~~~~~~
-
-::
-
-   Option    |Type     |Required    |Function
-   ----------|---------|------------|-----------------------------------
-   *         |[]       |no          |This directive expects a list of write_files
-             |         |            |definitions. Each definition itself contains the
-             |         |            |following options:
-   content   |string   |yes         |The content to write to a file
-   path      |string   |yes         |The full path and filename of the file to
-             |         |            |be written out
-   owner     |string   |no          |Username and optionally group name, separated
-             |         |            |by ":" or ".". Defaults to "root.root"
-   permissions|octal   |no          |Octal value describing the file permissions
-             |         |            |default value is influenced according to
-             |         |            |`umask`
-
-envar
-~~~~~
-
-::
-
-   Option    |Type     |Required    |Function
-   ----------|---------|------------|-----------------------------------
-   *         |string   |yes         |Add environment variables to /etc/profile.d/cloud-init.sh
-             |         |            |and to current cloud-init process
-
-bootcmd
-~~~~~~~
-
-::
-
-   Option    |Type     |Required    |Function
-   ----------|---------|------------|-----------------------------------
-   *         |string[] |no          |Similar to runcmd but bootcmd will run only on first boot
-
-wait_for_network
-~~~~~~~~~~~~~~~~
-
-::
-
-   Option    |Type     |Required    |Function
-   ----------|---------|------------|-----------------------------------
-   *         |boolean  |no          |Enable to force waiting for a functional network.
-
-This option makes the program wait until an active network is detected.
-To prevent waiting, ensure that this option is disabled explicitly
-disabled, before other options are used. This may be needed when using
-the ``packages`` or ``package_upgrade`` options, which imply that this
-option is used.
-
-COPYRIGHT
---------
-
-  Copyright (C) 2017 Intel Corporation, License: CC-BY-SA-3.0
-
-SEE ALSO
--------
-
-``cloud-init``\ (1)
-
-NOTES
-----
-
-Creative Commons Attribution-ShareAlike 3.0 Unported
-
-  http://creativecommons.org/licenses/by-sa/3.0/
@@ -1,93 +0,0 @@
-clr-power-tweaks.conf
-=====================
-
-:Manual section: 5
-
-SYNOPSIS
--------
-
-``clr-power-tweaks.conf`` is an optional configuration file for the
-`clr_power(1) <clr_power.1.html>`__ utility.
-
-``/etc/clr-power-tweaks.conf``
-
-DESCRIPTION
-----------
-
-``clr-power-tweaks.conf`` is an optional configuration file for the
-`clr_power(1) <clr_power.1.html>`__ utility. The configuration file contains kernel and device
-parameter values used by the `clr_power(1) <clr_power.1.html>`__ utility.
-
-Configuration parameter values placed in ``clr-power-tweaks.conf`` will
-supersede the built-in defaults configured by `clr_power(1) <clr_power.1.html>`__. New
-parameters can be added to the configuration to supplement the built-in
-values. Built-in parameters can be changed by defining them in
-``clr-power-tweaks.conf`` with a different value. Parameters can be
-excluded from being modified by `clr_power(1) <clr_power.1.html>`__ by adding them in
-``clr-power-tweaks.conf`` without a value.
-
-FILE FORMAT
-----------
-
-``clr-power-tweaks.conf`` uses a key-value pairs to define parameter
-values.
-
-Each line contains one parameter-value pair, delimited by a space
-character.
-
-Parameters are paths from the proc(5) filesystem. Parameters paths can
-include glob(n) wildcards to match multiple paths.
-
-Acceptable values are determined by the parameter being set. Any
-parameter listed in the configuration file without a value will be
-excluded by `clr_power(1) <clr_power.1.html>`__ and the parameter will inherit the kernel’s
-built-in default parameter value.
-
-EXAMPLES
--------
-
-1. ``clr-power-tweaks.conf`` entry to override the default value in
-   `clr_power(1) <clr_power.1.html>`__ for CPU governor with **powersave**. All other values
-   built-in to `clr_power(1) <clr_power.1.html>`__ would still get applied.
-
-   Note the globbing used with ``*`` to target all CPU cores.
-
-   ::
-
-      /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor powersave
-
-2. ``clr-power-tweaks.conf`` entry to exclude a parameter causing it to
-   use the kernel’s built-in default value (60). All other values
-   built-in to `clr_power(1) <clr_power.1.html>`__ would still get applied.
-
-   Note the omission of a value.
-
-   ::
-
-      /proc/sys/vm/swappiness
-
-3. ``clr-power-tweaks.conf`` entry to add two new parameters to increase
-   UDP buffers All other values built-in to `clr_power(1) <clr_power.1.html>`__ would still get
-   applied.
-
-   ::
-
-      /proc/sys/net/ipv4/udp_rmem_min 8192
-      /proc/sys/net/ipv4/udp_wmem_min 8192
-
-BUGS
----
-
-The default `clr-power-tweaks.conf(5) <clr-power-tweaks.conf.5.html>`__ aims to have reasonable defaults
-for achieving power and performance efficiency. Default values may not
-be optimal for all systems and environments.
-
-See GitHub Issues: https://github.com/clearlinux/clr-power-tweaks/issues
-
-SEE ALSO
--------
-
-**clr_power.conf(5)**, **proc(5)**, **sysctl(2)**
-
-For parameters understood by the kernel, please see
-https://www.kernel.org/doc/html/latest/admin-guide/kernel-parameters.html
@@ -1,73 +0,0 @@
-clr_power
-=========
-
-:Manual section: 1
-
-SYNOPSIS
--------
-
-``clr_power`` is a utility to adjust power and performance settings in
-the operating system. It is configurable and can enforce power and
-performance policies.
-
-**clr_power** [**-d**\ \|\ **–debug**]
-
-DESCRIPTION
-----------
-
-``clr_power`` adjusts power and performance in the operating system by
-setting runtime kernel and device parameters in the proc(5) filesystem.
-``clr_power`` operates with built-in default values. Values can be added
-or changed in user-defined `clr-power-tweaks.conf(5) <clr-power-tweaks.conf.5.html>`__ file.
-
-``clr_power`` applies settings and immediately exits after it is
-started. It can act as a daemon that enforces settings with the included
-systemd files.
-
-The program handles server and desktop-like systems differently and will
-set values based on whether a system is a server platform or a desktop
-platform. Most systems will be assumed a server, and if it can’t be
-determined what type of platform the system is, treated as a server
-platform. By default, systems with CPU’s that identify as ``Core(TM)``,
-``Celeron`` and ``Pentium`` are treated as desktop systems, and systems
-with CPU’s that identify as ``Xeon`` are treated as server systems.
-
-Tunings applied will vary per system. To see what tunings are applied,
-run the program with the ``--debug`` option.
-
-OPTIONS
-------
-
-``-d``, ``--debug`` Display debug/verbose output including built-in
-values.
-
-``-S``, ``--server`` Treat the system as a server, and apply server
-specific tunings.
-
-``-D``, ``--desktop`` Treat the system as a desktop, and apply desktop
-specific tunings
-
-FILES
-----
-
-  *clr-power.service* systemd service unit that executes **clr_power**.
-
-  *clr-power.timer* systemd timer that periodically executes the
-   *clr-power.service* to enforce settings.
-
-  *clr-power-rfkill.service* systemd service that stops bluetooth
-   devices at boot to prevent power drain.
-
-  */etc/clr-power-tweaks.conf* Optional user-defined configuration file
-   to override or att values. See `clr-power-tweaks.conf(5) <clr-power-tweaks.conf.5.html>`__ for more
-   information.
-
-BUGS
----
-
-See GitHub Issues: https://github.com/clearlinux/clr-power-tweaks/issues
-
-SEE ALSO
--------
-
-`clr-power-tweaks.conf(5) <clr-power-tweaks.conf.5.html>`__, **proc(5)**
@@ -1,185 +0,0 @@
-clrtrust
-========
-
-:Manual section: 1
-
-SYNOPSIS
--------
-
-**clrtrust** is a tool for generating and managing a centralized trusted
-certificate store.
-
-``clrtrust [-v|--verbose] [-h|--help] [-c|--internal-rehash] <command> [options]``
-
-DESCRIPTION
-----------
-
-A trust store contains a set of X.509 certificates which the operating
-system and applications should consider trustworthy.
-
-The ``clrtrust`` tool provides a frontend for centralized trust store
-management. It allows for adding (trusting) and removing (distrusting)
-certificate authorities (CAs). It also provides maintenance commands for
-viewing and re-generating the trust store.
-
-Certificates can be provided by the operating system for out-of-box
-functionality. Certificates can also be provided and modified by
-privileged users.
-
-It is up to each application to make use of the trust store generated by
-``clrtrust``.
-
-OPTIONS
-------
-
-::
-
-   Usage: clrtrust [-v|--verbose] [-h|--help] [-c|--internal-rehash] <command> [options]
-
-       -v | --verbose          Shows more details about execution
-       -c | --internal-rehash  Forces use of internal implementation of c_rehash
-       -h | --help             Prints this message
-
-       Commands
-           generate    generates the trust store
-           list        list CAs
-           add         add trust to a CA
-           remove      remove trust to a CA
-           restore     restore trust to previously removed CA
-           check       sanity/consistency check of the trust store
-
-   clrtrust <command> --help to get help on specific command.
-
-**Commands that modify the trust store require root privileges.**
-
-  ``clrtrust generate [-f|--force]``
-
-   The ``generate`` command has no arguments and generates a unified
-   trust store composed of system-provided and user-provided
-   certificates, if any. The optional ``--force`` parameter will
-   forcibly generate the trust store, even if it results in an empty
-   store. See the FILES section for paths used for trust store
-   generation.
-
-  ``clrtrust list``
-
-   The ``list`` command has no arguments and outputs a list of trusted
-   certificates with the following fields:
-
-   ``id`` uniquely identifies the certificate. It can be used as input
-   to other ``clrtrust`` commands such as ``remove`` or ``restore``.
-
-   ``File`` contains the file path of the certificate in the trust
-   store.
-
-   ``Authority`` shows the name of the organization that issued the
-   certificate. This field is extracted from the certificate file.
-
-   ``Expires`` shows the expiration date of the certificate. This field
-   is extracted from the certificate file.
-
-  ``clrtust add [<certificateFile> ...] [-f|--force]``
-
-   The ``add`` command takes one or more certificates as required
-   argument(s). The certificate is identified by a file path. The
-   certificate file(s) must be PEM-encoded with only one certificate per
-   file. The optional ``--force`` parameter will forcibly add the
-   certificate to the trust store, even if it is not a root CA.
-
-   Adding a root CA to the trust store allows applications using the
-   trust store to trust the root CA certificate, trust certificate
-   chains issued by the authority, verify the authenticity of peer’s
-   certificate, and establish a connection.
-
-  ``clrtrust remove [<certificateFile|id> ...]``
-
-   The ``remove`` command takes one or more certificates as required
-   argument(s). The certificate is identified by a file path or ``id``.
-   The argument can be an ``id`` of the certificate (see the ``list``
-   command) or the file path of the certificate.
-
-   Removing a root CA from the trust store distrusts the certificate for
-   applications using the trust store. Certificate chains issued by the
-   authority will no longer be trusted, authenticity of the peer’s
-   certificate will no longer be verified, and a connection will not be
-   established.
-
-  ``clrtrust check``
-
-   The ``check`` command has no arguments and validate the consistency
-   of a previously generated unified trust store.
-
-EXAMPLES
--------
-
-View the list of trusted CAs
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-``clrtrust list``
-
-The command above outputs a list of trusted certificates in the format
-below:
-
-::
-
-   id: FA:B7:EE:36:97:26:62:FB:2D:B0:2A:F6:BF:03:FD:E8:7C:4B:2F:9B
-   File: /var/cache/ca-certs/anchors/certSIGN_ROOT_CA.crt
-   Authority: /C=RO/O=certSIGN/OU=certSIGN ROOT CA
-   Expires: Jul  4 17:20:04 2031 GMT
-
-The certificate can be further inspected using the ``openssl x509``
-command. For example:
-
-::
-
-   openssl x509 -in /var/cache/ca-certs/anchors/certSIGN_ROOT_CA.crt -noout -text
-
-Add (trust) a root CA
-~~~~~~~~~~~~~~~~~~~~~
-
-``clrtrust add ~/PrivateCA.pem``
-
-The command above will add a root CA certificate located in the
-``~/PrivateCA.pem`` file. If the certificate file is not in the PEM
-format, use ``openssl x509`` command to convert to PEM first. For
-example:
-
-::
-
-   openssl x509 -in PrivateCA.cer -inform der -out PrivateCA.pem -outform pem
-
-Remove (distrust) a root CA
-~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-``clrtrust remove ~/PrivateCA.pem``
-
-The command above will remove a root CA certificate located in the
-``~/PrivateCA.pem`` file from the trust store and distrust it.
-
-FILES
-----
-
-*/var/cache/ca-certs*
-
-Generated directory of certificates and verification keys. Do not modify
-contents outside of ``clrtrust``.
-
-*/usr/share/ca-certs/*
-
-Operating-system provided certificates and keys. Do not modify contents
-outside of ``clrtrust``.
-
-*/etc/ca-certs/*
-
-Generated directory of user-supplied certificates and verification keys.
-Do not modify contents outside of ``clrtrust``.
-
-BUGS
----
-
-See GitHub Issues: https://github.com/clearlinux/clrtrust/issues
-
-SEE ALSO
--------
-
-**openssl(1)**
@@ -1,149 +0,0 @@
-=====
-mixer
-=====
-
------------------------
-OS software update mixer
------------------------
-
-:Copyright: \(C) 2018 Intel Corporation, CC-BY-SA-3.0
-:Manual section: 1
-
-
-SYNOPSIS
-========
-
-``mixer [subcommand] <flags>``
-
-
-DESCRIPTION
-===========
-
-`mixer(1) <mixer.1.html>`__ is a software update generator that uses input RPMs and bundle
-definition files to create update metadata consumable by `swupd(1) <swupd.1.html>`__.
-
-``mixer`` operates in a mix workspace using configuration files existing in the
-workspace. The tool allows users to use RPMs from an upstream URL (default
-download.clearlinux.org), provide their own RPMs, and use RPMs from other remote
-repositories to build updates. Users can also define their own local bundle
-definitions as well as use the default bundle definitions from the upstream URL.
-
-``mixer`` provides commands to manage local RPMs and bundle definitions and
-configure remote RPM repositories.
-
-The output of ``mixer`` is a set of manifests readable by ``swupd`` as well as
-all the OS content ``swupd`` needs to perform its update operations. The OS
-content includes all the files in an update as well as zero- and delta-packs for
-improved update performance. The content that ``mixer`` produces is tied to a
-specific format so that ``swupd`` is guaranteed to understand it if the client
-is using the right version of ``swupd``. See `swupd(1) <swupd.1.html>`__ and `os-format(7) <os-format.7.html>`__
-for more details.
-
-
-OPTIONS
-=======
-
-The following options are applicable to most subcommands, and can be
-used to modify the core behavior and resources that ``mixer`` uses.
-
-  ``-h, --help``
-
-   Display general help information. If put after a subcommand, it will
-   display help specific to that subcommand.
-
-  ``--check``
-
-   Check all external dependencies needed by mixer.
-
-  ``-v, --version``
-
-   Displays the version information of the ``mixer`` program and exit.
-
-  ``--offline``
-
-   Skip caching upstream bundles and work entirely with local bundles.
-   Do not reach out over network to perform operations.
-
-
-SUBCOMMANDS
-===========
-
-``add-rpms``
-
-    Add RPMs from the configured LOCAL_RPM_DIR to the local dnf repository.
-    See `mixer.add-rpms(1) <mixer.add-rpms.1.html>`__ for more details.
-
-``build``
-
-    Build various pieces of OS content, including all metadata needed by
-    ``swupd`` to perform updates. ``mixer build`` is a complicated tool in
-    itself. See `mixer.build(1) <mixer.build.1.html>`__ for more details.
-
-``bundle``
-
-    Perform various configuration actions on local and upstream bundles. The
-    user can add or remove bundles from their mix, create new bundle definitions,
-    or validate local bundle definition files. See `mixer.bundle(1) <mixer.bundle.1.html>`__ for more details.
-
-``config``
-
-    Perform configuration related actions, including configuration file
-    validation and conversion from deprecated formats. See `mixer.config(1) <mixer.config.1.html>`__
-    for more details.
-
-``help``
-
-    Print help text for any ``mixer`` subcommand.
-
-``init``
-
-    Initialize ``mixer`` configuration and workspace. See `mixer.init(1) <mixer.init.1.html>`__ for
-    more details.
-
-``repo``
-
-    Add, list, remove, or edit RPM repositories to be used by mixer. This
-    subcommand allows users to configure which remote or local repositories
-    mixer should use to look for RPMs. See `mixer.repo(1) <mixer.repo.1.html>`__ for more
-    information.
-
-``versions``
-
-    Manage mix and upstream versions. By itself the command will print the
-    current version of mix and upstream, and also report the latest version of
-    upstream available. Also allows the user to update mix and upstream
-    versions. See `mixer.versions(1) <mixer.versions.1.html>`__ for more details.
-
-
-FILES
-=====
-
-`<mixer/workspace>/builder.conf`
-
-    The mixer configuration file.
-
-`<mixer/workspace>/.yum-mix.conf`
-
-    The default location for the DNF configuration file.
-
-
-EXIT STATUS
-===========
-
-On success, 0 is returned. A non-zero return code indicates a failure.
-
-SEE ALSO
--------
-
-* `mixer.add-rpms(1) <mixer.add-rpms.1.html>`__
-* `mixer.build(1) <mixer.build.1.html>`__
-* `mixer.bundle(1) <mixer.bundle.1.html>`__
-* `mixer.config(1) <mixer.config.1.html>`__
-* `mixer.init(1) <mixer.init.1.html>`__
-* `mixer.repo(1) <mixer.repo.1.html>`__
-* `mixer.versions(1) <mixer.versions.1.html>`__
-* `swupd(1) <swupd.1.html>`__
-* `os-format(7) <os-format.7.html>`__
-* https://github.com/clearlinux/mixer-tools
-* https://github.com/clearlinux/swupd-client
-* https://clearlinux.org/documentation/
@@ -1,50 +0,0 @@
-==============
-mixer.add-rpms
-==============
-
---------------------
-Add local RPMs to mix
---------------------
-
-:Copyright: \(C) 2018 Intel Corporation, CC-BY-SA-3.0
-:Manual section: 1
-
-
-SYNOPSIS
-========
-
-``mixer add-rpms [flags]``
-
-
-DESCRIPTION
-===========
-
-Adds RPMs from the `LOCAL_RPM_DIR` (configured in the `builder.conf`) to the
-local RPM repository to be used in creating a mix.
-
-
-OPTIONS
-=======
-
-In addition to the globally recognized ``mixer`` flags (see `mixer(1) <mixer.1.html>`__ for
-more details), the following options are recognized.
-
-  ``-c, --config {path}``
-
-   Optionally tell ``mixer`` to use the configuration file at `path`. Uses the
-   default `builder.conf` in the mixer workspace if this option is not provided.
-
-  ``-h, --help``
-
-   Display ``add-rpm`` help information and exit.
-
-
-EXIT STATUS
-===========
-
-On success, 0 is returned. A non-zero return code indicates a failure.
-
-SEE ALSO
--------
-
-* `mixer(1) <mixer.1.html>`__
@@ -1,298 +0,0 @@
-===========
-mixer.build
-===========
-
-----------------------------------
-Build varioius pieces of OS content
-----------------------------------
-
-:Copyright: \(C) 2018 Intel Corporation, CC-BY-SA-3.0
-:Manual section: 1
-
-
-SYNOPSIS
-========
-
-``mixer build [command] [flags]``
-
-
-DESCRIPTION
-===========
-
-Builds various pieces of OS content and output update metadata to
-`<mixer/workspace>/update/www/<version>/`. This metadata can be published
-directly to a web-server and consumed by client update systems via the
-`swupd(1) <swupd.1.html>`__ update tool. All steps can be run at once using ``build all`` or
-the steps can be run individually using the subcommands.
-
-
-OPTIONS
-=======
-
-In addition to the globally recognized ``mixer`` flags (see `mixer(1) <mixer.1.html>`__ for
-more details), the following options are recognized across all ``build``
-subcommands.
-
-  ``--bundle-workers``
-
-   Number of parallel workers when building bundles, passing 0 or omitting this
-   flag defaults the number of workers to the number of CPUs on the system.
-
-  ``--delta-workers``
-
-   Number of parallel workers when creating deltas, passing 0 or omitting this
-   flag defaults the number of workers to the number of CPUs on the system.
-
-  ``--fullfile-workers``
-
-   Number of parallel workers when creating fullfiles, passing 0 or omitting this
-   flag defaults the number of workers to the number of CPUs on the system.
-
-  ``--skip-format-check``
-
-   Skip check for compatible upstream format when building on top of a new
-   upstream.
-
-  ``-h, --help``
-
-   Display ``build`` help information and exit.
-
-
-SUBCOMMANDS
-===========
-
-``all``
-
-    Build all content for the mix. Implicitly runs ``build bundles`` followed by
-    ``build update``. In addition to the global options ``mixer build all``
-    takes the following options.
-
-    - ``-c, --config {path}``
-
-      Optionally tell ``mixer`` to use the configuration file at `path`. Uses
-      the default `builder.conf` in the mixer workspace if this option is not
-      provided.
-
-    - ``--format {number}``
-
-      Supply the format number to use for the build.
-
-    - ``-h, --help``
-
-      Display ``build all`` help information and exit.
-
-    - ``--increment``
-
-      Automatically increment the mix version post build.
-
-    - ``--min-version {version}``
-
-      Supply minimum version for ``mixer`` to use old content from. This option
-      tells ``mixer`` to regenerate all mix content starting from a certain
-      version. ``mixer`` will not use any OS content from a version older than
-      the min-version passed here.
-
-   - ``--no-signing``
-
-     Do not generate a certificate and do not sign the Manifest.MoM
-
-   - ``--prefix {path}``
-
-     Supply the `path` to the file system where the ``swupd`` binaries live.
-
-``bundles``
-
-    Build the bundles for your mix. This is done by extracting dependency
-    information and file lists for each package in each bundle definition for the
-    mix. In addition to the global options ``mixer build bundles`` takes the
-    following options.
-
-    - ``-c, --config {path}``
-
-      Optionally tell ``mixer`` to use the configuration file at `path`. Uses
-      the default `builder.conf` in the mixer workspace if this option is not
-      provided.
-
-    - ``-h, --help``
-
-      Display ``build bundles`` help information and exit.
-
-   - ``--no-signing``
-
-     Do not generate a certificate and do not sign the Manifest.MoM
-
-``delta-packs``
-
-    Build packs to optimize ``swupd update``\s between versions. When a
-    ``swupd`` client updates a bundle it looks for a pack file from its current
-    version to the new version. If available ``swupd`` will download and apply
-    the pack content to the file system. Delta packs contain binary diff files
-    that describe changes between updates whenever possible and full files only
-    when necessary. Because of this delta packs are a significant performance
-    optimization for client updates. Because the client can fall back to full
-    files if a pack is not available, delta packs are not necessary for a
-    functional update. In addition to the global options ``mixer build
-    delta-packs`` takes the following options.
-
-    - ``-c, --config {path}``
-
-      Optionally tell ``mixer`` to use the configuration file at `path`. Uses
-      the default `builder.conf` in the mixer workspace if this option is not
-      provided.
-
-    - ``--from {version}``
-
-      Generate packs from the specified `version`.
-
-    - ``-h, --help``
-
-      Display ``build delta-packs`` help information and exit.
-
-    - ``--previous-versions {number}``
-
-      Generate packs for `number` of previous versions.
-
-    - ``--report``
-
-      Report reason each file in the `to` manifest was packed in the delta pack
-      or not.
-
-    - ``--to {version}``
-
-      Generate packs targeting a specific `to` `version`.
-
-``delta-manifests``
-
-    Build manifest deltas to optimize ``swupd update``\s between versions. When a
-    ``swupd`` client update runs, it will first try to get a delta manifest file
-    if it exists and apply that on the bundle manifest file for the version
-    installed on their system (if it exists). This can save a large amount of
-    content being downloaded in the case of few files changing in a manifest.
-    Because the client can fall back to the full manifest file if a delta is not
-    available, delta manifests are not necessary for a functional update. In
-    addition to the global options ``mixer build delta-manifests`` takes the
-    following options.
-
-    - ``--from {version}``
-
-      Generate packs from the specified `version`.
-
-    - ``-h, --help``
-
-      Display ``build delta-manifests`` help information and exit.
-
-    - ``--previous-versions {number}``
-
-      Generate packs for `number` of previous versions.
-
-    - ``--to {version}``
-
-      Generate packs targeting a specific `to` `version`.
-
-``image``
-
-    Build an image from the mix content. In addition to the global options
-    ``mixer build image`` takes the following options.
-
-    - ``-c, --config {path}``
-
-      Optionally tell ``mixer`` to use the configuration file at `path`. Uses
-      the default `builder.conf` in the mixer workspace if this option is not
-      provided.
-
-    - ``--format {number}``
-
-      Supply the format `number` used for the mix.
-
-    - ``-h, --help``
-
-      Display ``build image`` help information and exit.
-
-    - ``--template {path}``
-
-      Provide the `path` to the image template file to use.
-
-``update``
-
-    Build the update content for the mix. This command builds the actual update
-    metadata (manifests) and content (full files and zero packs) necessary for
-    ``swupd`` to perform updates on client systems. ``update`` relies on the
-    output of ``build bundles`` as the input for this step and expects the
-    output of ``build bundles`` to exist in the
-    `<mixer/workspace>/update/image/<version>` directory. In addition to the
-    global options ``mixer build update`` takes the following options.
-
-    - ``-c, --config {path}``
-
-      Optionally tell ``mixer`` to use the configuration file at `path`. Uses
-      the default `builder.conf` in the mixer workspace if this option is not
-      provided.
-
-    - ``--format {number}``
-
-      Supply the format `number` used for the mix.
-
-    - ``-h, --help``
-
-      Display ``build update`` help information and exit.
-
-    - ``--increment``
-
-      Automatically increment the mix version post build.
-
-    - ``--min-version {version}``
-
-      Supply minimum version for ``mixer`` to use old content from. This option
-      tells ``mixer`` to regenerate all mix content starting from a certain
-      version. ``mixer`` will not use any OS content from a version older than
-      the min-version passed here.
-
-   - ``--no-signing``
-
-     Do not generate a certificate and do not sign the Manifest.MoM
-
-   - ``--prefix {path}``
-
-     Supply the `path` to the file system where the ``swupd`` binaries live.
-
-``validate``
-
-    Compare two versions to validate that manifest file changes align with corresponding
-    package changes. Inconsistencies between manifest entries and package contents are
-    reported as errors. When no errors occur, package update statistics are displayed.
-
-    - ``--from {version}``
-
-      Compare manifests ``from`` a specific version
-
-    - ``--to {version}``
-
-      Compare manifests ``to`` a specific version
-
-    - ``--from-repo-url {repo}={URL}``
-
-      Overrides the baseurl value for the provided repo in the DNF config file for the ``from`` version
-
-    - ``--to-repo-url {repo}={URL}``
-
-      Overrides the baseurl value for the provided repo in the DNF config file for the ``to`` version
-
-    - ``--table-width {width}``
-
-      Max width of package statistics table, defaults to terminal width and disabled by negative numbers
-
-    - ``-h, --help``
-
-      Display ``build validate`` help information and exit.
-
-
-EXIT STATUS
-===========
-
-On success, 0 is returned. A non-zero return code indicates a failure.
-
-SEE ALSO
--------
-
-* `mixer(1) <mixer.1.html>`__
-* `swupd(1) <swupd.1.html>`__
@@ -1,207 +0,0 @@
-============
-mixer.bundle
-============
-
------------------------------------------------
-Perform various configuration actions on bundles
------------------------------------------------
-
-:Copyright: \(C) 2018 Intel Corporation, CC-BY-SA-3.0
-:Manual section: 1
-
-
-SYNOPSIS
-========
-
-``mixer bundle [command] [flags]``
-
-
-DESCRIPTION
-===========
-
-Performs various configuration actions on upstream and local bundle definition
-files. List and validate mix bundles. Validate local bundle definition files.
-
-
-SUBCOMMANDS
-===========
-
-``add {bundle} [{bundle}...] [flags]``
-
-    Add local or upstream bundles to your mix by modifying the mix bundles list
-    at `<mixer/workspace>/mixbundles`. In addition to the global options ``mixer
-    bundle add`` takes the following options.
-
-    - ``--all-local``
-
-      Add all local bundles defined in `<mixer/workspace>/local-bundles` to the
-      mix. This command takes precedence over bundle list.
-
-    - ``--all-upstream``
-
-      Add all upstream bundles (cached in `<mixer/workspace>/upstream-bundles`
-      to the mix. This command takes precedence over bundle list.
-
-    - ``-c, --config {path}``
-
-      Optionally tell ``mixer`` to use the configuration file at `path`. Uses
-      the default `builder.conf` in the mixer workspace if this option is not
-      provided.
-
-    - ``--git``
-
-      Automatically apply a new git commit after modifying the mix bundles list
-      or bundle definitions. This is useful if your local bundles are kept under
-      version control.
-
-    - ``-h, --help``
-
-      Display ``bundle add`` help information and exit.
-
-``create``
-
-    Create new bundles or copy existing bundles.
-    This command will locate the bundle by first looking in local-bundles,
-    and then in upstream-bundles. If the bundle is only found upstream,
-    the bundle file will be copied to your local-bundles directory. If the bundle is
-    not found anywhere, a blank template will be created with the correct name.
-
-    Passing '--add' will also add the bundle(s) to your mix. Please note that
-    bundles are added after all bundles are created, and thus will not be added
-    if any errors are encountered earlier on.
-
-    In addition to the global options ``mixer bundle create`` takes the following
-    options.
-
-    - ``--add``
-
-      Add the bundle(s) to your mix after editing.
-
-    - ``--local``
-
-      Skip upstream check and create empty local bundle(s).
-
-    - ``-c, --config {path}``
-
-      Optionally tell ``mixer`` to use the configuration file at `path`. Uses
-      the default `builder.conf` in the mixer workspace if this option is not
-      provided.
-
-    - ``--git``
-
-      Automatically apply a new git commit after modifying the mix bundles list
-      or bundle definitions. This is useful if your local bundles are kept under
-      version control.
-
-    - ``-h, --help``
-
-      Display ``bundle create`` help information and exit.
-
-``list [mix|local|upstream] [flags]``
-
-    List the bundles in the mix, the available local bundles, or the available
-    upstream bundles. In addition to the global options ``mixer bundle list``
-    takes the following options.
-
-    - ``mix``
-
-      List the bundles in the mix.
-
-    - ``local``
-
-      List available locally-defined bundles.
-
-    - ``upstream``
-
-      List available upstream bundles.
-
-    - ``-c, --config {path}``
-
-      Optionally tell ``mixer`` to use the configuration file at `path`. Uses
-      the default `builder.conf` in the mixer workspace if this option is not
-      provided.
-
-    - ``-h, --help``
-
-      Display ``bundle list`` help information and exit.
-
-    - ``--tree``
-
-      Pretty-print the bundle list as a tree showing include information.
-
-``remove``
-
-    Removes bundles from your mix by modifying the mix bundle list (stored in
-    the `<mixer/workspace>/mixbundles` file). The mix bundle list is parsed, the
-    bundles are removed, and the resultant list is written back out in sorted
-    order. If bundles do not exist in the mix, they are skipped. In addition to
-    the global options ``mixer bundle remove`` takes the following options.
-
-    - ``-c, --config {path}``
-
-      Optionally tell ``mixer`` to use the configuration file at `path`. Uses
-      the default `builder.conf` in the mixer workspace if this option is not
-      provided.
-
-    - ``--git``
-
-      Automatically apply a new git commit after modifying the mix bundles list
-      or bundle definitions. This is useful if your local bundles are kept under
-      version control.
-
-    - ``-h, --help``
-
-      Display ``bundle remove`` help information and exit.
-
-    - ``--local``
-
-      Also remove the bundle file from local-bundles. This action is
-      irrevocable.
-
-    - ``--mix={bool}``
-
-      Remove bundle from the mix bundle list. This defaults to true.
-
-``validate``
-
-    Checks bundle definition files for validity. Only local bundle files are
-    checked; upstream bundles are trusted as valid. Valid bundles yield no
-    output. Any invalid bundles will yield a non-zero return code.
-
-    Basic validation includes checking syntax and structure, and that the bundle
-    has a valid name. Commands like ``mixer bundle add`` run basic validation
-    automatically.
-
-    In addition to the global options ``mixer bundle remove`` takes the
-    following options.
-
-    - ``--all-local``
-
-      Run validation against all local bundles.
-
-    - ``-c, --config {path}``
-
-      Optionally tell ``mixer`` to use the configuration file at `path`. Uses
-      the default `builder.conf` in the mixer workspace if this option is not
-      provided.
-
-    - ``-h, --help``
-
-      Display ``bundle validate`` help information and exit.
-
-    - ``--strict``
-
-      Perform strict validation to additionally check that the bundle header
-      fields are parse-able and non-empty, and that the header 'Title' is itself
-      valid and matches the bundle filename.
-
-
-EXIT STATUS
-===========
-
-On success, 0 is returned. A non-zero return code indicates a failure.
-
-SEE ALSO
--------
-
-* `mixer(1) <mixer.1.html>`__
@@ -1,79 +0,0 @@
-============
-mixer.config
-============
-
------------------------------------------
-Perform configuration manipulation actions
------------------------------------------
-
-:Copyright: \(C) 2018 Intel Corporation, CC-BY-SA-3.0
-:Manual section: 1
-
-
-SYNOPSIS
-========
-
-``mixer config [command]``
-
-
-DESCRIPTION
-===========
-
-Perform various configuration manipulation actions on the mixer configuration
-files.
-
-
-OPTIONS
-=======
-
-In addition to the globally recognized ``mixer`` flags (see `mixer(1) <mixer.1.html>`__ for
-more details), the following options are recognized.
-
-  ``-h, --help``
-
-   Display ``config`` help information and exit.
-
-
-SUBCOMMANDS
-===========
-
-``convert``
-
-    Convert an old config file to the new TOML format. The command will generate
-    a backup file of the old config and will replace it with the converted one.
-    Environment variables will not be expanded and the values will not be
-    validated. In addition to the global options ``mixer config convert`` takes
-    the following options.
-
-    - ``-c, --config {path}``
-
-      The `path` to the configuration file to convert.
-
-    - ``-h, --help``
-
-      Display ``config convert`` help and exit.
-
-``validate``
-
-    Parse a builder config file and display its properties. Properties
-    containing environment variables will be expanded.  In addition to the
-    global options ``mixer config validate`` takes the following options.
-
-    - ``-c, --config {path}``
-
-      The `path` to the configuration file to validate.
-
-    - ``-h, --help``
-
-      Display ``config validate`` help and exit.
-
-
-EXIT STATUS
-===========
-
-On success, 0 is returned. A non-zero return code indicates a failure.
-
-SEE ALSO
--------
-
-* `mixer(1) <mixer.1.html>`__
@@ -1,89 +0,0 @@
-==========
-mixer.init
-==========
-
------------------------------
-Initialize mixer and workspace
------------------------------
-
-:Copyright: \(C) 2018 Intel Corporation, CC-BY-SA-3.0
-:Manual section: 1
-
-
-SYNOPSIS
-========
-
-``mixer init [flags]``
-
-
-DESCRIPTION
-===========
-
-Initialize the mixer configuration and mixer workspace by writing default
-configuration files if necessary and building the proper directory structure.
-
-OPTIONS
-=======
-
-In addition to the globally recognized ``mixer`` flags (see `mixer(1) <mixer.1.html>`__ for
-more details), the following options are recognized.
-
-  ``--all-local``
-
-   Initialize mix with all local bundles automatically included.
-
-  ``--all-upstream``
-
-   Initialize the mix with all upstream bundles automatically included.
-
-  ``--clear-version {version}``
-
-   Upstream version used to compose the mix. It must be either an integer or 'latest' (default "latest")
-
-  ``--config {path}``
-
-   Supply a specific configuration file at `path` to use for mixing.
-
-  ``--format {format}``
-
-   Supply the format version for the mix.
-
-  ``--git``
-
-   Track mixer's internal work directory with git.
-
-  ``-h, --help``
-
-   Display ``init`` help information and exit.
-
-  ``--local-rpms``
-
-   Create and configure local RPM directories.
-
-  ``--mix-version {version}``
-
-   Supply the mix version to build (default is 10)
-
-  ``--no-default-bundles``
-
-   Skip adding default bundles to the mix
-
-  ``--upstream-url {url}``
-
-   Supply an upstream URL to use for mixing (default is
-   "https://download.clearlinux.org")
-
-  ``--upstream-version {version}``
-
-   Alias to `--clear-version` (default is "latest")
-
-
-EXIT STATUS
-===========
-
-On success, 0 is returned. A non-zero return code indicates a failure.
-
-SEE ALSO
--------
-
-* `mixer(1) <mixer.1.html>`__
@@ -1,85 +0,0 @@
-==========
-mixer.repo
-==========
-
---------------------------------------------------------------
-Perform various configuration actions on mixer RPM repositories
---------------------------------------------------------------
-
-:Copyright: \(C) 2018 Intel Corporation, CC-BY-SA-3.0
-:Manual section: 1
-
-
-SYNOPSIS
-========
-
-``mixer repo [command]``
-
-
-DESCRIPTION
-===========
-
-Perform various configuration actions on mixer RPM repositories. These RPM
-repositories are used as content sources for mixer to build updates from.
-
-
-OPTIONS
-=======
-
-In addition to the globally recognized ``mixer`` flags (see `mixer(1) <mixer.1.html>`__ for
-more details), the following options are recognized.
-
-  ``-c, --config {path}``
-
-   The `path` to the configuration file to use.
-
-  ``-h, --help``
-
-   Display subcommand help information and exit.
-
-
-SUBCOMMANDS
-===========
-
-``add {name} {url}``
-
-    Add the repo named `name` at the `url` url. In addition to the global
-    options ``mixer repo add`` takes the following options.
-
-    - ``--priority``
-
-      Repo priority between 1 and 99, where 1 is highest. This flag defaults to 1.
-
-``init``
-
-    Initialize the DNF configuration file with the default `Clear` repository
-    enabled.
-
-``list``
-
-    List all RPM repositories configured in the DNF configuration file used by
-    mixer.
-
-``remove {name}``
-
-    Remove the repo `name` from the DNF configuration file used by mixer.
-
-``set-priority {name} {priority}``
-
-    Sets the priority for repo `name` to the provided `priority`.
-
-``set-url {name} {url}``
-
-    Sets the URL for repo `name` to the provided `url`. If `name` does not exist
-    the repo will be added to the configuration.
-
-
-EXIT STATUS
-===========
-
-On success, 0 is returned. A non-zero return code indicates a failure.
-
-SEE ALSO
--------
-
-* `mixer(1) <mixer.1.html>`__
@@ -1,92 +0,0 @@
-==============
-mixer.versions
-==============
-
--------------------------------
-Manage mix and upstream versions
--------------------------------
-
-:Copyright: \(C) 2018 Intel Corporation, CC-BY-SA-3.0
-:Manual section: 1
-
-
-SYNOPSIS
-========
-
-``mixer versions``
-
-``mixer versions [command]``
-
-
-DESCRIPTION
-===========
-
-Manage mix and upstream versions. By itself the command will print the current
-version of mix and upstream, and also report on the latest version of upstream
-available. This command also allows the user to increment the mix version and
-optionally the upstream version.
-
-
-OPTIONS
-=======
-
-In addition to the globally recognized ``mixer`` flags (see `mixer(1) <mixer.1.html>`__ for
-more details), the following options are recognized.
-
-  ``-h, --help``
-
-   Display subcommand help information and exit.
-
-
-SUBCOMMANDS
-===========
-
-``update``
-
-    Increment the mix version to generate a new release. By default the mix
-    version is incremented by 10, following Clear Linux conventions to leave
-    room for intermediate versions if necessary. The increment can be configured
-    with the `--increment` flag. The ``update`` command also allows the user to
-    update the upstream version.
-
-    In addition to the global options ``mixer versions update`` takes the
-    following options.
-
-    - ``--clear-version {version}``
-
-      Alias to `--upstream-version`
-
-    - ``-c, --config {path}``
-
-      Supply the `path` to the configuration file to use.
-
-    - ``--increment {number}``
-
-      Amount to increment the current mix version (default is 10).
-
-    - ``--mix-version {version}``
-
-      Set a specific mix `version`.
-
-    - ``--upstream-version {version}``
-
-      Set a specific next upstream version (either version number or the default
-      "latest" string).
-
-    - ``--skip-format-check``
-
-      Skip check for compatible upstream format when changing upstream version.
-
-      This command will not update to an upstream version of a different format
-      ("format bumps"). At the moment this needs to be handled manually.
-
-
-EXIT STATUS
-===========
-
-On success, 0 is returned. A non-zero return code indicates a failure.
-
-SEE ALSO
--------
-
-* `mixer(1) <mixer.1.html>`__
@@ -1,37 +0,0 @@
-=======
-os-core
-=======
-
----------------------------------------------------
-Base files for Clear Linux OS for Intel Architecture
----------------------------------------------------
-
-:Copyright: \(C\) 2017 Intel Corporation, CC-BY-SA-3.0
-:Manual section: 7
-
-
-SYNOPSIS
-========
-
-* ``init``
-* ``root filesystem``
-* ``shell``
-
-
-DESCRIPTION
-===========
-
-os-core provides a minimal base for the Clear Linux OS for Intel
-Architecture. It contains required utilities for running the init
-program systemd, letting users log in and run bash shell commands. The
-core also contains pieces of packages that are required to run any
-other package in the distribution.
-
-This is the only required bundle for Clear Linux OS and can not be
-removed as all other bundles depend upon it.
-
-
-SEE ALSO
-========
-
-`<https://clearlinux.org/documentation/>`_
@@ -1,55 +0,0 @@
-=========
-OS Format
-=========
-
--------------------------------------
-A summary of OS formats in Clear Linux
--------------------------------------
-
-:Copyright: \(C) 2018 Intel Corporation, CC-BY-SA-3.0
-:Manual section: 7
-
-
-SYNOPSIS
-========
-
-``/usr/share/defaults/swupd/format``
-
-DESCRIPTION
-===========
-
-A format defines a range of OS versions that have compatible update metadata and
-content. An update client can update a system from the oldest version in the
-format to the latest version in the format without worrying about compatibility
-issues in the update content for the version it is updating to.
-
-A format bump occurs when the update metadata or content is changed in such a
-way that will cause client updates to break. In this case the format number must
-be incremented so clients will not attempt to update to the new versions in the
-new format without crossing the format boundary. Update clients update only to
-the latest build in their format. Once that update is complete the update client
-may then update forward again because the last version in the current format has
-identical content to the first version in the new format, including the new
-update client needed to understand the new format.
-
-Because the update system in Clear Linux (``swupd``) has auto-update turned on
-by default most users will never be aware of their system changing to a new
-format. Those users who have disabled auto-update may occasionally see ``swupd``
-perform two updates in a row when they only invoked ``swupd update`` once. This
-is because ``swupd`` detects when it crossed a format boundary and immediately
-re-executes an update to carry it to the latest version in the new format. This
-re-execution will actually invoke the new version of ``swupd`` that was
-delivered in the first update.
-
-Format bumps are simply a way for Clear Linux to introduce breaking changes to
-the OS without breaking user's update stream or workflow.
-
-
-SEE ALSO
-========
-
-* `mixer(1) <mixer.1.html>`__
-* `swupd(1) <swupd.1.html>`__
-* https://clearlinux.org/documentation/
-* https://github.com/clearlinux/swupd-client/
-* https://github.com/clearlinux/mixer-tools/
@@ -1,309 +0,0 @@
-=========
-stateless
-=========
-
---------------------------------------------------------------------------
-A guide to stateless configuration in Clear Linux OS for Intel Architecture
---------------------------------------------------------------------------
-
-:Copyright: \(C) 2017 Intel Corporation, CC-BY-SA-3.0
-:Manual section: 7
-
-
-SYNOPSIS
-========
-
-``/etc/``
-
-``/usr/share/defaults/``
-
-``/usr/share/defaults/etc/``
-
-``/var/``
-
-``/var/cache/``
-
-``/usr/local/``
-
-``/usr/src/``
-
-``/usr/lib/kernel/``
-
-``/usr/lib/modules/``
-
-
-DESCRIPTION
-===========
-
-The Clear Linux OS for Intel Architecture has a unique way of
-providing customization and configuration to system administrators and
-users. This man page aims to provide both an explanation of what this
-method is and how users of Clear Linux can use it and benefit from it.
-
-The goal of "stateless" is to provide a system OS that functions
-without user configuration. A system should not require editing of
-configuration files by the end user before it is functional, nor should
-it place lengthy and confusing configuration files automatically in
-user-maintained file system areas (``/etc/``) by default. And
-additionally, any configuration placed in user-maintained configuration
-should be removable without breaking functionality.
-
-This is achieved by several methods, each of which implements a part
-of the stateless goal.
-
-
-* Removal of configuration files
-
-The first step taken to achieve stateless configuration is to embed
-proper default configuration values in the software. Any missing
-critical configuration value should have a built-in default value.
-
-* Providing of default configuration files outside of ``/etc/``
-
-Software is adjusted to use a distribution provided default
-configuration file in ``/usr/share/defaults``. If no configuration
-file exists in ``/etc/`` for the software, the software must use the
-distribution default configuration file.
-
-* Allowing the end user to provide configuration in ``/etc/``
-
-If the user provides a properly formatted configuration file in
-the ``/etc/`` filesystem area (or, wherever it is relevant for the
-software), the software is instructed to use this configuration
-file instead of any other.
-
-
-Consequences for the system administrator (user)
------------------------------------------------
-
-The user should create configuration files as needed and avoid
-modifying distribution provided defaults. The filesystem folders and
-all content under ``/etc/`` and ``/var/`` may be modified as needed, but
-the content under ``/usr/``, ``/lib/``, ``/lib64/``, ``/bin/``, ``/sbin/`` should
-never be modified, and will be overwritten by `swupd(1) <swupd.1.html>`__ as needed.
-
-Some default configuration structure and data is automatically created
-under ``/etc/`` and ``/var/``. The user may remove these file system
-structures entirely - a reboot of the OS should properly restore the
-system to its factory default. This may also provide the user with
-a way to repair a defective system configuration.
-
-The user should, if user configuration of a service is needed,
-attempt to place the configuration file in the ``/etc/`` structure as
-the service requests. Often, template files for the configuration
-format can be found under the ``/usr/share/defaults/`` file structure,
-and these files can be copied to the ``/etc/`` file structure.
-
-To modify system service configuration (``systemd``\(1) service units),
-the user should not touch or modify unit files under the ``/usr/``
-file structure directly, as changes in those files will be lost after
-a system software update with `swupd(1) <swupd.1.html>`__.
-
-A list of package specific hints and best practices is listed below. In 
-many cases, the man pages for the respective packages also provides 
-detailed information as to how to configure the software. Please 
-consult the relevant manual pages for the software to find information
-on the specific syntax and options for each software.
-
-
-Where can I install system-wide files then?
-------------------------------------------
-
-`swupd(1) <swupd.1.html>`__ has a list of exempted locations where the system
-administrator can place files that will not get overwritten or removed
-at all. The default whitelisted directories are:
-
-    ``/usr/lib/modules``
-    ``/usr/lib/kernel``
-    ``/usr/local``
-    ``/usr/src``
-
-Using these locations for your own software is highly recommended. Not
-only do these locations provide a standard FHS compliant way of adding
-local software, they are sufficiently separated from OS software that
-maintaining them will be much more simple.
-
-
-ldconfig
--------
-
-    ``ldconfig``\(8)
-
-The default paths that the linker searches includes only ``/usr/lib64``
-and paths below that. This explicitly omits ``/usr/local/``. If you
-compile libraries manually and install them in other paths, you may
-need to configure the ``ld.so``\(8) linker to find these before you run
-``ldconfig``. For example:
-
-    ``echo "/usr/local/lib" | sudo tee -a /etc/ld.so.conf``
-
-    ``sudo ldconfig``
-
-
-systemd
-------
-
-    ``systemd``\(1)
-
-Unit files can be created under ``/etc/systemd/system`` as needed and 
-function normally. To override unit file options, the simplest method 
-is to have ``systemctl``\(1) copy it for you by invoking it as:
-
-    ``systemctl edit --full foo.service``
-
-This creates an exact copy of the default unit file and invokes the
-editor for the user, allowing the user to override any part of the unit.
-
-Unit files can be started as normal with ``systemctl start <unit>``.
-
-To enable services to start at boot time, use ``systemctl enable <unit>``.
-
-
-sshd
----
-
-    ``sshd``\(8)
-    ``sshd_config``\(5)
-
-The SSH daemon has all of its configuration built in and no template
-configuration file is present on the file system. The man page for
-``sshd_config``\(5) explains the format, and it suffices to put only a
-single option in the file
-
-   ``/etc/ssh/sshd_config``
-
-For example, to enable X11 forwarding through sshd all one has to do is
-add one line containing ``X11Forwarding yes``. Other often used options
-include ``PermitRootLogin yes`` to allow root ssh login access, and the
-following 3 lines to disable password authentication entirely:
-
-    ``ChallengeResponseAuthentication no``
-
-    ``PasswordAuthentication no``
-
-    ``UsePAM no``
-
-To modify the listening port of sshd, one needs to determine whether
-``sshd.socket`` or ``sshd.service`` is enabled first, since the methods
-for changing the port number depend on whether ``sshd``\(8) is controlling
-the port number, or whether ``systemd``\(1) is:
-
-    ``systemctl is-enabled sshd.socket``
-
-If enabled, the ``sshd.socket`` unit should be edited to modify the port:
-
-    ``systemctl edit --full sshd.socket``
-
-And, the user should modify the port number at ``ListenStream=`` to the
-desired new port number.
-
-If ``sshd.service`` is enabled, the user should create, and edit a new
-``/etc/ssh/sshd_config`` file:
-
-    ``mkdir -p /etc/ssh/``
-    ``vi /etc/ssh/sshd_config``
-
-And add a line in that file that reads:
-
-    ``Port 10022``
-    
-to, for instance, change the port number sshd.service will listen on
-to port 10022.
-
-Root login over SSH is disabled by default and should remain disabled
-for most systemd. However, in some cases this is acceptable and it can
-be easily enabled by adding the following line to ``/etc/ssh/sshd_config``
-that reads:
-
-    ``PermitRootLogin yes``
-
-
-nginx
-----
-
-Nginx ships by default in a non-functional configuration. However,
-an example configuration file is present that can be used to enable
-a simple server. To use this template configuration, create:
-
-    ``mkdir -p /etc/nginx/conf.d``
-
-And then copy configuration templates over to this folder:
-
-    ``cp /usr/share/nginx/conf/nginx.conf.example /etc/nginx/nginx.conf``
-    ``cp /usr/share/nginx/conf/server.conf.example /etc/nginx/conf.d/server.conf``
-
-Edit the file to assure options such as SSL and PHP are enabled in
-the preferred method. In the default configuration, PHP is enabled
-to run listening to ``/run/php-fpm.sock``. The template file has PHP
-by default disabled, but the listed example lines can be uncommented
-to make the nginx service process php documents.
-
-
-php-fpm
-------
-
-    ``php-fpm``\(8)
-
-Php's default configuration file doesn't allow us to provide an 
-alternative as it is programmed to only read the builtin file. If you 
-wish to have php-fpm use a different configuration, you must pass it a 
-startup option to tell it where it is. This can be done by ``systemctl 
-edit --full php-fpm.service``. That command copies the default php-fpm 
-service unit to ``/etc/systemd/system/`` and allows the user to override 
-any option. It spawns an editor with the copy.
-
-Then, the user should change the line:
-
-    ``ExecStart=/usr/sbin/php-fpm --nodaemonize``
-
-to:
-
-    ``ExecStart=/usr/sbin/php-fpm --nodaemonize --fpm-config /etc/php-fpm.conf``
-
-The template php-fpm.conf can be found at ``/usr/share/defaults/php/php-fpm.conf``.
-One should copy this to a place in ``/etc/``:
-
-    ``cp /usr/share/defaults/php/php-fpm.conf /etc/php-fpm.conf``
-
-Then, the user should edit ``/etc/php-fpm.conf`` and assure that 
-configuration options are all properly set as needed.
-
-Care must be taken using the default ``pool`` configuration. If needed, 
-the user should also create ``/etc/php-fpm.d/`` and include pool 
-configuration files from either ``/usr/share/defaults/php/php-fpm.d/`` or 
-copy them and modify them as needed as well, as well as adjust the 
-``include`` configuration option in ``php-fpm.conf`` to point to a new 
-location for pool configuration files.
-
-Network interface management
----------------------------
-
-Clear Linux has switched the network interface management model to be fully
-managed by NetworkManager when installed on real hardware. Previously, Ethernet
-interfaces were managed by systemd-networkd whereas Wi-Fi and others were
-managed by NetworkManager. Clear Linux cloud images continue to use
-systemd-networkd.
-
-When updating from previous versions of Clear Linux, the installation will be
-reconfigured to continue with systemd-networkd managing the Ethernet interfaces.
-Since the connectivity could be lost during the procedure, physical access to the
-system is required. To switch to NetworkManager for all the interfaces, the
-user should disable and stop systemd-networkd:
-
-    ``sudo systemctl disable systemd-networkd``
-    ``sudo systemctl stop systemd-networkd``
-
-Then, remove the file ``/etc/NetworkManager/conf.d/systemd-networkd-unmanaged.conf``
-
-Finally, restart NetworkManager
-
-    ``sudo systemctl restart NetworkManager``
-
-SEE ALSO
-========
-
-* `swupd(1) <swupd.1.html>`__
-* ``systemd``\(1)
-* https://clearlinux.org/documentation/
-* https://clearlinux.org/features/stateless
-* https://github.com/clearlinux/swupd-client/
@@ -1,46 +0,0 @@
-====================
-swupd-update.service
-====================
-
---------------------
-Performs an OS update
---------------------
-
-:Copyright: \(C) 2017 Intel Corporation, CC-BY-SA-3.0
-:Manual section: 4
-
-
-SYNOPSIS
-========
-
-``swupd-update.service``
-
-``/usr/lib/systemd/system/swupd-update.service``
-
-
-DESCRIPTION
-===========
-
-Instructs the ``systemd``\(1) system daemon how to start and control the
-``swupd`` service to perform an update.
-
-When this unit runs, the output will be sent to the systemd journal, and
-it can be inspected with the ``journalctl``\(1) command.
-
-The user can disable all background updates (either started through
-timers or not) by executing the following command:
-
-``systemctl mask swupd-update.service``
-
-
-ENVIRONMENT
-===========
-
-This unit is a ``systemd``\(1) unit file.
-
-
-SEE ALSO
-========
-
-`swupd(1) <swupd.1.html>`__,  `swupd-update.timer(4) <swupd-update.timer.4.html>`__
-
@@ -1,40 +0,0 @@
-==================
-swupd-update.timer
-==================
-
----------------------------
-Schedules periodical updates
----------------------------
-
-:Copyright: \(C) 2017 Intel Corporation, CC-BY-SA-3.0
-:Manual section: 4
-
-
-SYNOPSIS
-========
-
-``swupd-update.timer``
-
-``/usr/lib/systemd/system/swupd-update.timer``
-
-
-DESCRIPTION
-===========
-
-Instructs the ``systemd``\(1) system daemon when to periodically start a
-system software update. The update itself may not execute if the
-`swupd-update.service(4) <swupd-update.service.4.html>`__ is disabled. See that manual page for
-information on how to disable that unit.
-
-
-ENVIRONMENT
-===========
-
-This unit is a ``systemd``\(1) unit file.
-
-
-SEE ALSO
-========
-
-`swupd(1) <swupd.1.html>`__, `swupd-update.service(4) <swupd-update.service.4.html>`__
-
@@ -1,771 +0,0 @@
-=====
-swupd
-=====
-
--------------------------
-OS software update program
--------------------------
-
-:Copyright: \(C) 2020 Intel Corporation, CC-BY-SA-3.0
-:Manual section: 1
-
-
-SYNOPSIS
-========
-
-``swupd [subcommand] <flags>``
-
-
-DESCRIPTION
-===========
-
-`swupd(1) <swupd.1.html>`__ is an OS-level software update program that applies updates
-to system software.
-
-The updates are fetched from a central software update server. If a
-valid update is found on the server, it can be downloaded and applied.
-
-The ``swupd`` tool can also install and remove bundles, check for
-updates without applying them, perform system-level diagnose of
-the system software, and install an OS.
-
-A *version url* server provides version information. This server
-notifies the program of available updates.
-
-A *content url* server (can be the same as *version url* server)
-provides the file and metadata content for all versions. The content url
-server provides metadata in the form of manifests. These Manifest files
-list and describe file contents, symlinks, directories. Additionally,
-the actual content is provided to clients in the form of archive files.
-
-``swupd`` consumes update artifacts generated by ``mixer`` in the specific
-format the installed version of ``swupd`` understands. For more information
-about how these artifacts are generated see `mixer(1) <mixer.1.html>`__ and `os-format(7) <os-format.7.html>`__.
-
-The ``swupd`` tool can also manage 3rd-party content, this allows users to
-install, remove, and update bundles from 3rd-party repositories.
-
-OPTIONS
-=======
-
-The following options are applicable to most subcommands, and can be
-used to modify the core behavior and resources that swupd uses.
-
-h, --help    Display general help information. If put after a subcommand, it
-        will display help specific to that subcommand.
-
-v, --version   Displays the version information of the swupd program, and exit.
-        It also displays compile options and copyright information.
-
-p <path>, --path=<path>   Optionally set the top-level directory for the
-        swupd-managed system. This can be used to point to a chroot installation
-        of the OS or a custom mount. If not specified this will default to ``/``.
-
-u <url>, --url=<url>   Specify an RFC-3986 encoded url. The url will be used to
-        download version information and file content downloads.
-
-P <port>, --port=<port>    Specify the port number of the server to connect to.
-        Applies to both version and file content url server connections.
-
-c <url>, --contenturl=<url>    Specify an RFC-3986 encoded url. The url will be
-        used for file content downloads only.
-
-v <url>, --versionurl=<url>    Specify an RFC-3986 encoded url. The url will be
-        used to download version information.
-
-F <formatstring>, --format=<formatstring>  Specify the format suffix for
-        version file downloads. Is usually one of ``1``, ``2``, ``3``, etc. or
-        ``staging``. Software update formats may change regularly and normally
-        you should consult the swupd server data for the appropriate latest
-        version available. If that version is not supported by your version of
-        ``swupd``, you should subtract ``1`` from the number and try again until
-        it succeeds.
-
-S <path>, --statedir=<path>    Specify an alternate path for swupd cache and data directory.
-        Normally ``swupd`` uses ``/var/lib/swupd``.
-
-K <path>, --cachedir=<path>    Specify an alternate swupd cache directory.
-        Normally ``swupd`` uses ``/var/lib/swupd``.
-
-Z <path>, --datadir=<path>    Specify an alternate swupd data directory.
-        Normally ``swupd`` uses ``/var/lib/swupd``.
-
-C <path>, --certpath=<cert>  Specify alternate path to swupd certificate store (pem file).
-        Default is /usr/share/clear/update-ca/Swupd_Root.pem
-
-W <n>, --max-parallel-downloads=<n>    Set the maximum number of parallel downloads.
-
-r <n>, --max-retries=<n>   Maximum number of retries for download failures.
-
-d <n>, --retry-delay=<n>  Initial delay in seconds between download retries, this will
-        be doubled for each retry until the download succeeds or the maximum
-        number of retries has been reached.
-
-n, --nosigcheck    Do not attempt to enforce certificate or signature checking.
-
-n, --nosigcheck-latest     Do not attempt to enforce signature checking when
-        retrieving the latest version number.
-
-I, --ignore-time   Ignore system/certificate time when validating signature.
-
-t, --time  Show verbose time output for swupd operations.
-
-N, --no-scripts    Do not run the post-update scripts and boot update tool.
-
-b, --no-boot-update    Do not update the boot files using clr-boot-manager.
-
-j, --json-output   Prints the swupd output as a machine readable JSON stream.
-
-y, --yes   Assume yes as answer to all prompts and run non-interactively.
-
--allow-insecure-http   For security reasons, swupd only allows system updates
-        using secure https connections by default. This option forces swupd
-        to allow updates over insecure http connections.
-
-        ``Warning``: although it is not recommended, if an http server is
-        set up as the upstream server, the `allow_insecure_http=true` option will
-        need to be setup in the swupd configuration file for the autoupdate
-        command to continue to work.
-
--quiet    Sets `swupd` to print a minimal and more stable output that is easier
-        to parse for its commands. Only the most relevant information and errors
-        are printed out.
-        Output displayed when using this option is rarely going to change, so
-        this is a good option to use when writing scripts that use `swupd`.
-
--verbose   Enable verbosity for commands.
-
--debug     Print extra information to help debugging problems.
-
--no-progress   Don't print progress report on commands that informs the
-        percentage left in current operation.
-
--wait-for-scripts  Wait for the post-update scripts to complete.
-
--assume=<yes|no>   Sets an automatic response to all prompts and run
-        non-interactively.
-
-
-SUBCOMMANDS
-===========
-
-info
----
-
-    Shows the current OS version and the URLs used for updates.
-
-autoupdate
----------
-
-    Enables or disables automatic updates, or reports current
-    status. Enabling updates does not cause an immediate update -
-    use ``swupd update`` to force one if desired.
-
--enable    Enable autoupdates
--disable   Disable autoupdates
-
-check-update
------------
-
-    Checks whether an update is available and prints out the information
-    if so. Does not download update content.
-
-update
------
-
-    Performs a system software update.
-
-    The program will contact the version server at the version url, and
-    check to see if a system software update is available. If an update
-    is available, the update content will be downloaded from the content
-    url and stored in the `/var/lib/swupd` state path. Once all content
-    is downloaded and verified, the update is applied to the system.
-
-    In case any problem arises during a software update, the program
-    attempts to correct the issue, possibly by performing a ``swupd repair``
-    operation, which corrects broken or missing files and other issues.
-
-    After the update is applied, the system performs an array of
-    post-update actions. These actions are triggered through `systemd(1)`
-    and reside in the `update-triggers.target(4) <update-triggers.target.4.html>`__ system target.
-
-V <version>, --version=<version>   Update to a specific version, also accepts 'latest' (default).
-
-s, --status    Do not perform an update, instead display whether an update is
-        available on the version url server, and what version number is
-        available. This is the same as running ``swupd check-update``.
-
-k, --keepcache     Do not delete the swupd state directory content after
-        updating the system.
-
--download      Do not perform an update, instead download all resources needed
-        to perform the update, and exit.
-
--update-search-file-index  Update the index used by search-file to speed up
-        searches. Don't enable this if you have download or space restrictions.
-
--3rd-party     If update is successfull, also update content from 3rd-party
-        repositories.
-
-
-bundle-add <bundles>
--------------------
-
-    Installs new software bundles. Any bundle name listed after ``bundle-add``
-    will be installed in the system. A list of all existing bundles can be
-    displayed with the ``bundle-list --all`` command.
-
-    The names can also be aliases that are not actual bundles names but instead
-    are names in an alias configuration file. See ``swupd-alias``\(7)
-
--skip-optional     Do not install optional bundles (`also-add` flag in
-        Manifests).
-        A bundle may include other bundles that will also get installed
-        when installing the bundle that includes them. This included bundles
-        can be either optional, or mandatory. Optional bundles can be skipped
-        at install time by using this option.
-
--skip-diskspace-check  Skip checking for available disk space before installing
-        a bundle.
-        By default, swupd attempts to determine if there is enough free
-        disk space to add the passed in bundle before attempting to install.
-        The current implementation will check free space in ``/usr/`` by default,
-        or it will check the passed in --path option with ``/usr/`` appended.
-
-bundle-remove <bundles>
-----------------------
-
-    Removes software bundles. Any bundle name listed after ``bundle-remove``
-    will be removed from the system. If the bundle is required by another
-    bundle(s) on the system, a tree will be displayed to indicate which bundles
-    are blocking removal.
-
-x, --force     Removes a bundle along with all the bundles that depend on it.
-
-        ``Warning``: This operation is dangerous and must be used with care since
-        it can remove many unexpected bundles.
-
-R, --recursive Removes a bundle and its dependencies recursively, except for
-        bundle os-core.
-
-        ``Warning``: This operation is dangerous and must be used with care since
-        it can remove many unexpected bundles.
-
--orphans       Removes all orphaned bundles. Orphan bundles are those that are no
-        longer required by any of the tracked bundles.
-
-        ``Warning``: This operation is dangerous and must be used with care since
-        it can remove many unexpected bundles.
-
-bundle-list
-----------
-
-    List all installed software bundles in the local system. Available bundles
-    can be listed with the ``--all`` option.
-
-a, --all   Lists all available software bundles, either installed or not, that
-        are available.
-
-D <bundle>, --has-dep=<bundle>     Displays a list of all bundles which include
-        the passed BUNDLE as a dependency. Combine with ``--all`` to report all
-        bundles including those not installed on the system. Combine with
-        ``--verbose`` to show a tree of those bundles.
-
--status    Show the installation status of the listed bundles. Bundles
-        installation status can be; "explicitly installed", meaning that they
-        were specifically requested to be installed by the user, or they can be
-        "implicitly installed", meaning they were installed as a dependency of
-        another explicitly installed bundle.
-
--deps=<bundle>     Lists all bundle dependencies of the passed BUNDLE,
-        including recursively included bundles.
-
--orphans    List orphaned bundles. Orphan bundles are those that are installed
-         but no longer required by any tracked bundle.
-
-bundle-info
-----------
-
-    Display detailed information about a bundle.
-
-V <version>, --version=<version>   Show the bundle info for the specified
-        version, it also accepts 'latest'.i It defaults to the current version
-        if no version is specified.
-
--dependencies  Show the bundle's direct and indirect dependencies as well as if
-        they are optional or mandatory dependencies. Direct dependencies are
-        those that are specifically included by the bundle in question, while
-        indirect dependencies are those that are included by the bundles that
-        are a direct dependency of the bundle in question.
-
--files     Show the files directly included in this bundle, in other words it
-        shows the files included in the bundle's manifest. If this option is used
-        along with the ``--dependencies`` option, all files installed by the
-        bundle are listed, including those files installed by the dependencies
-        of the bundle.
-
-search
------
-
-    Swupd search functionality is provided by the swupd-search binary, available
-    on os-core-search bundle.
-
-    For more information run:
-
-    ``$ swupd search --help``
-
-search-file <string>
--------------------
-
-    Search for matching paths in manifest data. The specified `{string}`
-    is matched in any part of the path listed in manifests, and all
-    matches are printed, including the name of the bundle in which the
-    match was found.
-
-    If manifest data is not present in the state folder, it is
-    downloaded from the `content url`.
-
-    Because this search consults all manifests, it normally requires to
-    download all manifests for bundles that are not installed, and may
-    result in the download of several mega bytes of manifest data.
-
-V <version>, --version=<version>   Search for a match of the given file in the
-        specified version version.
-
-l, --library   Restrict search to designated dynamic shared library paths.
-
-B, --binary    Restrict search to designated program binary paths.
-
-T <num_results>, --top=<num_results>   Only display the top specified number of
-        results for each bundle.
-
-m, --csv   Output the search results in a machine readable CSV format.
-
-i, --init  Just perform the collection and download of all required manifest
-        resources needed to perform the search, then exit.
-
-o <order>, --order=<order>     Sort the output in one of two ways:
-
-        -  Use 'alpha' to order alphabetically (default)
-        -  Use 'size' to order by bundle size (smaller to larger)
-
-diagnose
--------
-
-    Perform system software installation verification. The program will
-    obtain all the manifests needed from version url and content url to
-    establish whether the system software is correctly installed and not
-    overwritten, modified, missing or otherwise incorrect (permissions, etc.).
-
-    After obtaining the proper resources, all files that are under
-    control of the software update program are verified according to the
-    manifest data
-
-V <version>, --version=<version>   Diagnose against the specified manifest VERSION.
-
-x, --force     Attempt to proceed even if non-critical errors found.
-
-q, --quick     Omit checking hash values. Instead only looks for missing files
-        and directories and/or symlinks.
-
-B <bundles>, --bundles=<bundles>     Forces swupd to only diagnose the (comma separated) list of bundles provided.
-
-        Examples:
-
-            - ``--bundles xterm,vim``
-
-                Diagnoses only bundles `xterm` and `vim`.
-
-Y, --picky     Also list files which should not exist. Only files listed in the
-         manifests should exist. By default swupd only looks for these
-         files at ``/usr``, this path can be changed using ``--picky-tree``.
-         Some paths at ``/usr`` are skipped by default:
-         ``/usr/lib/modules``, ``/usr/lib/kernel``, ``/usr/local``
-         and ``/usr/src``. These paths can be changed using
-         ``--picky-whitelist``.
-
-X <path>, --picky-tree=<path>  Changes the path where ``--picky`` and
-        ``--extra-files-only`` looks for extra files. To be specified as
-        absolute PATH.
-        The default path is ``/usr``.
-
-w <regex>, --picky-whitelist=<regex>   Any path matching the POSIX extended regular expression regex is ignored by ``--picky``. The given expression is always
-        wrapped in ``^(`` and ``)$`` and thus has to match the entire path.
-        Matched directories get skipped completely.
-
-        The default is to ignore ``/usr/lib/kernel``,
-        ``/usr/lib/modules``, ``/usr/src`` and ``/usr/local``.
-
-        Examples:
-
-            - ``/var|/etc/machine-id``
-
-                Ignores ``/var`` or ``/etc/machine-id``, regardless of
-                whether they are directories or something else. In the
-                usual case that ``/var`` is a directory, also everything
-                inside it is ignored because the directory gets skipped
-                while scanning the directory tree.
-
-            -  empty string or ``^$``
-
-                Matches nothing, because `paths` are never empty.
-
--extra-files-only      Like ``--picky``, but it only looks for extra files.
-        It omits checking hash values, and for missing files, directories and/or
-        symlinks.
-
--file  Forces swupd to only diagnose the specified file or directory
-        (recursively).
-
-repair
------
-
-    Correct any issues found. This will overwrite incorrect file content,
-    add missing files and do additional corrections, permissions, etc.
-
-V <version>, --version=<version>   Repair against the specified manifest
-        version.
-
-x, --force     Attempt to proceed even if non-critical errors found.
-
-q, --quick     Omit repairing corrupt files. Instead only add missing files
-        and directories and/or symlinks.
-
-B <bundles>, --bundles=<bundles>     Forces swupd to only repair the (comma separated) list
-        of bundles provided.
-
-        Examples:
-
-            - ``--bundles xterm,vim``
-
-                Repairs only bundles `xterm` and `vim`.
-
-Y, --picky     Also removes files which should not exist. Only files listed
-        in the manifests should exist. By default swupd only looks for these
-        files at ``/usr``, this path can be changed using ``--picky-tree``.
-        Some paths at ``/usr`` are skipped by default:
-        ``/usr/lib/modules``, ``/usr/lib/kernel``, ``/usr/local``
-        and ``/usr/src``. These paths can be changed using
-        ``--picky-whitelist``.
-
-X <path>, --picky-tree=<path>  Changes the path where ``--picky`` and
-        ``--extra-files-only`` looks for extra files. To be specified as
-        absolute PATH. The default path is ``/usr``.
-
-w <regex>, --picky-whitelist=<regex>   Any path matching the POSIX extended regular
-        expression regex is ignored by ``--picky``. The given expression is
-        always wrapped in ``^(`` and ``)$`` and thus has to match the entire
-        path. Matched directories get skipped completely.
-
-        The default is to ignore ``/usr/lib/kernel``,
-        ``/usr/lib/modules``, ``/usr/src`` and ``/usr/local``.
-
-        Examples:
-
-            - ``/var|/etc/machine-id``
-
-               Ignores ``/var`` or ``/etc/machine-id``, regardless of
-               whether they are directories or something else. In the
-               usual case that ``/var`` is a directory, also everything
-               inside it is ignored because the directory gets skipped
-               while scanning the directory tree.
-
-            -  empty string or ``^$``
-
-                Matches nothing, because paths are never empty.
-
--extra-files-only  Like ``--picky``, but it only removes extra files. It omits
-        repairing corrupt files, and adding missing files, directories and/or
-        symlinks.
-
--file  Forces swupd to only repair the specified file or directory
-        (recursively).
-
-os-install
----------
-
-    Perform system software installation in the specified location. Install
-    all files into `{path}` as specified by the ``swupd os-install {path}``
-    option. Useful to generate a new system root. The only bundle that will
-    be installed by default is ``os-core`` unless more bundles are specified
-    with the ``--bundles`` option.
-
-V <version>, --version=<version>   Install the specified version of the OS.
-
-x, --force     Attempt to proceed even if non-critical errors found.
-
-B <bundles>, --bundles=<bundles>   Include the (comma separated) list of
-        bundles with the base OS install.
-
-        Examples:
-
-            - ``--bundles xterm,vim``
-
-                Installs bundles `xterm` and `vim`, along with `os-core`
-                (installed by default).
-
-s <path>, --statedir-cache=<path>  After checking for content in the
-        `statedir`, check the `statedir-cache` before downloading it over the
-        network.
-
--download      Do not perform an install, instead download all resources
-        needed to perform the install, and exit.
-
--skip-optional     Do not install optional bundles (`also-add` flag in
-        Manifests).
-        A bundle may include other bundles that will also get installed
-        when installing the bundle that includes them. This included bundles
-        can be either optional, or mandatory. Optional bundles can be skipped
-        at install time by using this option.
-
-mirror
------
-
-    Configure a `mirror URL` for swupd to use instead of the defaults on the
-    system or compiled into the swupd binary.
-
-s <url>, --set=<url>     Set the `content` and `version URLs` to URL by adding
-        configuration files to ``<path>/etc/swupd/mirror_contenturl`` and
-        ``<path>/etc/swupd/mirror_versionurl``
-
-U, --unset     Remove the `content` and `version URL` configuration by removing
-        ``<path>/etc/swupd``
-
-clean
-----
-
-    Removes files cached by swupd.
-
-    Note that removing these files may cause swupd to perform slower the next time
-    it is used since it may need to download some files from the update server
-    again.
-
--all   | Removes all the content including recent metadata.
-
--dry-run       Just prints files that would be removed.
-
-hashdump
--------
-
-    Calculates and print the Manifest hash for a specific file on disk.
-
-n, --no-xattrs      Ignore extended attributes when calculating hash.
-
-p <path>, --path=<path>    Specify the PATH to use for operations. This can be
-        used to point to a chroot installation of the OS or a custom mount.
-
-3rd-party
---------
-
-    Manages 3rd-party repositories and content installed from them. A 3rd-party
-    repository enables the distribution of user produced content.
-
-    The following subcommands are available to manage `3rd-party repositories`:
-
-    -  ``add``
-
-       Adds a 3rd-party repository.
-
-         -  ``force``
-
-         Attempt to proceed with the removal of the repo even if non-critical
-         errors found.
-
-    -  ``remove``
-
-       Removes a 3rd-party repository along with all the content installed
-       from it from the system.
-
-         -  ``force``
-
-         Attempt to proceed with the removal of the repo even if non-critical
-         errors found.
-
-    -  ``list``
-
-       Lists the 3rd-party repositories available to the system. These
-       repositories must have been previously added using ``swupd 3rd-party add``.
-
-    Most of the swupd subcommands used for managing `upstream` content are
-    supported to manage `3rd-party` content along with most of their options.
-    To use these subcommands for 3rd-party content, it is necessary to use the
-    ``3rd-party`` subcommand followed by the desired operation to be performed.
-
-    This is the syntax for 3rd-party operations to manage content:
-
-    ``$ swupd 3rd-party <subcommand> [option(s)]``
-
-    Example:
-
-         -  ``swupd 3rd-party bundle-add my_bundle``
-
-            Looks for the 3rd-party bundle `my_bundle` among all the available
-            3rd-party repositories, and installs it in the system as long as
-            it is found in one, and only one, repository. If the bundle exists
-            in more than one 3rd-party repository, users are required to specify
-            the repository to install it from by using the ``--repo`` option.
-
-            There is no need to specify the 3rd-party repository if the bundle
-            name is unique among 3rd-party repositories, even if a bundle with
-            the same name exists in the upstream update server. Bundles from
-            3rd-party repositories are installed in a different location so they
-            don't clash with upstream bundles.
-
-         -  ``swupd 3rd-party update --repo my_repo``
-
-            Performs a software update for content installed from the 3rd-party
-            repository `my_repo`. If no repository is specified, content from
-            all 3rd-party repositories is updated.
-
-    All 3rd-party content is installed in the following location:
-    ``/opt/3rd-party/<bundle_name>/``
-
-    The following subcommands are available to manage `3rd-party content`:
-
-    -  ``update``
-
-       Update to latest version of a 3rd-party repository.
-       For information about the options for this command please refer to
-       the ``swupd update`` section.
-
-    -  ``bundle-add``
-
-       Installs a bundle from a 3rd-party repository.
-       For information about the options for this command please refer to
-       the ``swupd bundle-add`` section.
-
-    -  ``bundle-remove``
-
-       Remove a bundle from a 3rd-party repository.
-       For information about the options for this command please refer to
-       the ``swupd bundle-remove`` section.
-
-    -  ``bundle-list``
-
-       List bundles from a 3rd-party repository.
-       For information about the options for this command please refer to
-       the ``swupd bundle-list`` section.
-
-    -  ``bundle-info``
-
-       Display information about a bundle in a 3rd-party repository.
-       For information about the options for this command please refer to
-       the ``swupd bundle-info`` section.
-
-    -  ``diagnose``
-
-       Verify content from a 3rd-party repository.
-       For information about the options for this command please refer to
-       the ``swupd diagnose`` section.
-
-    -  ``repair``
-
-       Repair local issues relative to a 3rd-party repository.
-       For information about the options for this command please refer to
-       the ``swupd repair`` section.
-
-    -  ``check-update``
-
-       Check if a new version of a 3rd-party repository is available.
-       For information about the options for this command please refer to
-       the ``swupd check-update`` section.
-
-    -  ``clean``
-
-       Clean cached files of a 3rd-party repository.
-       For information about the options for this command please refer to
-       the ``swupd clean`` section.
-
-
-FILES
-=====
-
-/usr/share/defaults/swupd
-
-    Sometimes a set of flags is always used for one, or many swupd commands. The
-    ``swupd configuration file`` provides a convenient way of persistently define
-    these flags so they don't need to be specified every time a command is run.
-
-    The configuration file is an INI type of file that consists of sections, each led
-    by a [section] header, followed by key/value entries separated by a '=' character.
-    Note that there should be no whitespace between key=value. The configuration
-    file may include comments, prefixed by either the '#' or the ';' characters.
-
-    There can be one section for each swupd command (e.g. [bundle-add], [update], etc.)
-    and one for global options (e.g. [GLOBAL]). Global options can be specified in the
-    either in the GLOBAL section, in a command section, or in both. Global options
-    specified in the command section have higher precedence than those specified in the
-    GLOBAL section, so it is possible to define a GLOBAL option that will apply to all
-    swupd command except for that one overwritten in the command section.
-
-    A sample swupd configuration file can be found at this location (this file should not
-    be modified):
-    `/usr/share/defaults/swupd`
-
-    To use it, copy it to `/etc/swupd` where swupd reads the configuration from.
-
-
-EXIT STATUS
-===========
-
-On success, ``0`` is returned. A ``non-zero`` return code signals a failure.
-
-If the subcommand ``check-update`` was specified, the program returns
-``0`` if an update is available, ``1`` if no update available, and a
-return value higher than ``1`` signals a failure.
-
-If the subcommand was ``autoupdate`` without options, then the program
-returns ``0`` if automatic updating is enabled.
-
-If the subcommand was ``diagnose``, then the program returns ``0`` if the system
-is consistent at the end of the process or ``1`` if there are invalid/missing
-files in the system.
-
-The non-zero return codes for other operations are listed here:
-
-**2**     A required bundle was removed or was attempted to be removed
-
-| **3**     The specified bundle is invalid
-| **4**     Unable to download or read MoM manifest
-| **5**     Unable to delete a file
-| **6**     Unable to rename a directory
-| **7**     Unable to create a file
-| **8**     Unable to recursively load included manifests
-| **9**     Unable to obtain lock on state directory
-| **10**    Unable to rename a file
-| **11**    Unable to initialize curl agent
-| **12**    Initialization error
-| **13**    Bundle not tracked on system
-| **14**    Unable to load manifest into memory
-| **15**    Invalid command-line option
-| **16**    Unable to connect to update server
-| **17**    File download issue
-| **18**    Unable to untar a file
-| **19**    Unable to create required directory
-| **20**    Unable to determine current version of the OS
-| **21**    Unable to initialize signature verification
-| **22**    System time is off by a large margin
-| **23**    Pack download issue
-| **24**    Unable to verify server SSL certificate
-| **25**    There is not enough disk space left (or it cannot be determined)
-| **26**    The required path was not found in any manifest
-| **27**    Unexpected condition found
-| **28**    Unable to execute another program in a subprocess
-| **29**    Unable to list the content of a directory
-| **30**    An error occurred computing the hash of a file
-| **31**    Unable to get current system time
-| **32**    Unable to write a file
-| **34**    swupd ran out of memory
-| **35**    Unable to fix/replace/delete one or more files
-| **36**    Unable to execute binary, is either missing or invalid
-| **37**    Invalid 3rd-party repository (not found)
-| **38**    File is missing or invalid
-
-
-SEE ALSO
-========
-
-| `swupd-update.service(4) <swupd-update.service.4.html>`__,  `swupd-update.timer(4) <swupd-update.timer.4.html>`__,  `update-triggers.target(4) <update-triggers.target.4.html>`__,  `mixer(1) <mixer.1.html>`__,  `os-format(7) <os-format.7.html>`__
-
-| Official repository     https://github.com/clearlinux/swupd-client/
-| Official documentation  https://clearlinux.org/documentation/
@@ -1,63 +0,0 @@
-tallow
-======
-
-Reduce log clutter due to ssh login attempts.
-
-SYNOPSIS
--------
-
-``/usr/sbin/tallow``
-
-DESCRIPTION
-----------
-
-``tallow`` is a daemon that watches the systemd journal for messages
-from the ``sshd`` service. It parses the messages and looks for
-attempted random logins such as failed logins to the root account and
-failed logins to invalid user accounts, and various other obviously
-malicious login attempts that try things as forcing old protocols, or
-weak key systems.
-
-If such logins were detected, the offending IP address is stored in a
-list. Items from this list are regularly purged, but if the amount of
-times that a specific IP address is seen exceeds a threshold, an
-ipset(1) entry is inserted in the ``tallow`` or ``tallow6`` ipset, and
-further packets from that ip address will be blocked by an
-``iptables(1)`` or ``ip6tables(1)`` rule that tallow creates at startup.
-Additionally, certain types of login failure will trigger a short term
-ban of further packets from the offending IP address immediately.
-
-The system administrator needs to assure that the tallow and tallow6
-ipsets are left alone and that the inserted iptables rules are properly
-matching on packets.
-
-Care should be taken to assure that legitimate users are not blocked
-inadvertently. You may wish to list any valid IP address with the
-whitelist option in `tallow.conf(5) <tallow.conf.5.html>`__. Multiple addresses can be
-whitelisted.
-
-OPTIONS
-------
-
-The ``tallow`` daemon itself has no runtime configuration. All
-configuration is done through the `tallow.conf(5) <tallow.conf.5.html>`__ config file.
-
-SIGNALS
-------
-
-The ``USR1`` signal causes ``tallow`` to print out it’s internal
-tracking table of IP addresses. This requires that tallow is compiled
-with the ``-DDEBUG=1`` symbol passed to the compiler.
-
-SEE ALSO
--------
-
-systemd-journald(1), iptables(1), ipset(1), `tallow.conf(5) <tallow.conf.5.html>`__,
-`tallow.patterns(5) <tallow.patterns.5.html>`__
-
-BUGS
----
-
-``tallow`` is ``NOT A SECURITY SOLUTION``, nor does it protect against
-random password logins. A attacker may still be able to logon to your
-systems if you allow password logins.
@@ -1,92 +0,0 @@
-tallow.conf
-===========
-
-The tallow configuration file
-
-NAME
----
-
-tallow.conf - Tallow daemon configuration file
-
-SYNOPSIS
--------
-
-``/etc/tallow.conf``
-
-DESCRIPTION
-----------
-
-This file is read on startup by the `tallow(1) <tallow.1.html>`__ daemon, and can be used to
-provide options to the tallow daemon. If not present, tallow will
-operate with built-in defaults.
-
-OPTIONS
-------
-
-``fwcmd_path``\ =\ ``<string>`` Specifies the location of the ipset(1)
-firewall-cmd(1) programs. By default, tallow will look in “/usr/sbin”
-for them.
-
-``ipt_path``\ =\ ``<string>`` Specifies the location of the ipset(1)
-program and iptables(1) or ip6tables(1) programs. By default, tallow
-will look in “/usr/sbin” for them.
-
-``expires``\ =\ ``<int>`` The number of seconds that IP addresses are
-blocked for. Note that due to the implementation, IP addresses may be
-blocked for much longer than this period. If IP addresses are seen, but
-not blocked within this period, they are also removed from the watch
-list. Defaults to 3600s.
-
-``whitelist``\ =\ ``<ip address|pattern>`` Specify an IP address or
-``pattern`` that should never be blocked. Multiple IP addresses can be
-included by repeating the ``whitelist`` option several times. By
-default, 127.0.0.1, 192.168., and 10. are whitelisted. If you create a
-manual whitelist, you must include these entries if you want to continue
-them to be whitelisted as well, otherwise they will be omitted from the
-whitelist.
-
-If the last character of the listed ip adress is a ``.`` or a ``:``,
-then the matching is only performed on the leftmost characters of an IP
-address against the whitelist entry. For instance, if you whitelist
-``10.`` then all IP addresses in the ``10/8`` subnet mask will match
-this whitelist entry and never be blocked.
-
-``ipv6``\ =\ ``<0|1>`` Enable or disable ipv6 (ip6tables) support. Ipv6
-is disabled automatically on systems that do not appear to have ipv6
-support and enabled when ipv6 is present. Use this option to explicitly
-disable ipv6 support if your system does not have ipv6 or is missing
-ip6tables. Even with ipv6 disabled, tallow will track and log ipv6
-addresses.
-
-``nocreate``\ =\ ``<0|1>`` Disable the creation of firewall rules and
-ipset sets. By default, tallow will create new firewall-cmd(1) or
-iptables(1) and ip6tables(1) rules when needed automatically. If set to
-``1``, `tallow(1) <tallow.1.html>`__ will not create any new firewall DROP rules or
-ipset sets that are needed work. You should create them manually before
-tallow starts up and remove them afterwards using the sets of commands
-below.
-
-Use the following commands if you’re using iptables(1):
-
-::
-
-   ipset create tallow hash:ip family inet timeout 3600
-   iptables -t filter -I INPUT 1 -m set --match-set tallow src -j DROP
-
-   ipset create tallow6 hash:ip family inet6 timeout 3600
-   ip6tables -t filter -I INPUT 1 -m set --match-set tallow6 src -j DROP
-
-Use the following commands if you’re using firewalld(1):
-
-::
-
-     firewall-cmd --permanent --new-ipset=tallow --type=hash:ip --family=inet --option=timeout=3600
-     firewall-cmd --permanent --direct --add-rule ipv4 filter INPUT 1 -m set --match-set tallow src -j DROP
-
-     firewall-cmd --permanent --new-ipset=tallow6 --type=hash:ip --family=inet6 --option=timeout=3600
-     firewall-cmd --permanent --direct --add-rule ipv6 filter INPUT 1 -m set --match-set tallow6 src -j DROP
-
-SEE ALSO
--------
-
-`tallow(1) <tallow.1.html>`__, `tallow.patterns(5) <tallow.patterns.5.html>`__
@@ -1,136 +0,0 @@
-tallow.patterns
-===============
-
-Tallow pattern matching configuration files.
-
-SYNOPSIS
--------
-
-`tallow(1) <tallow.1.html>`__ uses regular expressions to match journal entries and extract
-an IP address from them. JSON files are used to configure the patterns
-and banning thresholds used by `tallow(1) <tallow.1.html>`__.
-
-``/etc/tallow/*.json`` ``/usr/share/tallow/*.json``
-
-DESCRIPTION
-----------
-
-`tallow(1) <tallow.1.html>`__ uses regular expressions to match journal entries and extract
-an IP address from them. JSON files are used to configure the patterns
-and banning thresholds used by `tallow(1) <tallow.1.html>`__. This adds the ability to
-extend the patterns `tallow(1) <tallow.1.html>`__ will recognize. Many JSON files can exist
-for logical grouping. The `tallow(1) <tallow.1.html>`__ daemon will read all JSON files in
-the configuration directories at startup.
-
-`tallow(1) <tallow.1.html>`__ operates with default pattern definitions
-in\ ``/usr/share/tallow/*.json``. Users can add more patterns with their
-own JSON files under ``/etc/tallow``. The default JSON files can be
-overridden by creating the same file under ``/etc/tallow``.
-
-FILE FORMAT
-----------
-
-Pattern configuration files use the JavaScript Object Notation (JSON)
-format.
-
-The JSON must be two levels deep and all properties are required. The
-root object is an array containing objects with a ``filter`` key and an
-``items`` key.
-
-  ``filter`` is a string that defines a field for filtering the journal
-   file. This helps make sure patterns are only matched to a subset of
-   journal entries. See systemd.journal-fields(7) for valid journal
-   fields.
-
-  ``items`` is an array of objects that contains three elements:
-   ``ban``, ``score``, and ``pattern``.
-
-   -  ``ban`` is an integer that defines the number of seconds to ban
-      originating IP for. If this value is > 0, the IP address get
-      banned immediately when a journal entry matches ``pattern``.
-
-   -  ``score`` is a double that defines a value to add to the
-      accumulated “score” of an originating IP address each time a
-      journal entry matches the ``pattern``. If the combined score is >
-      1.0, tallow bans the originating IP for the default time of 1
-      hour. The ``ban`` element value above is not used for bans made
-      due to ``score``.
-
-   -  ``pattern`` is a string that defines a Perl Compatible Regular
-      Expressions (PCRE) to match against the filtered journal entries.
-      The PCRE should extract exactly one substring: the originating IP
-      address for `tallow(1) <tallow.1.html>`__. See systemd.journal-fields(7) for valid
-      journal fields.
-
-EXAMPLES
--------
-
-1. The JSON below is a snippet from one of the default pattern
-   configuration files for blocking certain failed ``sshd`` connections.
-
-   The first pattern will ban an IP address after it fails to login 6
-   times causing it to reach a total score > 1.0.
-
-   The second pattern will ban an IP address for 10 seconds every time a
-   login is attempted with an invalid user. Additionally, it will ban
-   the IP address for 1 hour if it attempts to login with an invalid
-   user 6 times causing it to reach a total score > 1.0.
-
-   See the ``/usr/share/tallow/sshd.json`` file for more ``sshd``
-   examples.
-
-   ::
-
-      [
-        {
-          "filter": "SYSLOG_IDENTIFIER=sshd",
-          "items": [
-            {
-              "ban": 0,
-              "score": 0.2,
-              "pattern": "MESSAGE=Failed .* for .* from ([0-9a-z:.]+) port \\d+ ssh2"
-            },
-            {
-              "ban": 10,
-              "score": 0.2,
-              "pattern": "MESSAGE=Invalid user .* from ([0-9a-z:.]+) port \\d+"
-            }
-          ]
-        }
-      ]
-
-2. The JSON below defines a pattern for blocking connections based on
-   error logs from ``nginx-mainline`` if placed in a
-   ``/etc/tallow/nginx-mainline.json`` file.
-
-   The pattern will ban an IP address for 15 seconds every time it
-   attempts to access a script that does not exist. Additionally, it
-   will ban the IP address for 1 hour if it attempts to access invalid
-   scripts 4 times causing it to reach a total score > 1.0.
-
-   ::
-
-      [
-        {
-          "filter": "SYSLOG_IDENTIFIER=nginx-mainline",
-          "items": [
-            {
-              "ban": 15,
-              "score": 0.3,
-              "pattern": ".Primary script unknown. while reading response header from upstream, client: ([0-9a-z:.]+),"
-            }
-          ]
-        }
-      ]
-
-SEE ALSO
--------
-
-`tallow(1) <tallow.1.html>`__, `tallow.conf(5) <tallow.conf.5.html>`__
-
-BUGS
----
-
-``tallow`` is ``NOT A SECURITY SOLUTION``, nor does it protect against
-random password logins. An attacker may still be able to logon to your
-systems if you allow password logins.
@@ -1,81 +0,0 @@
-================
-telem-record-gen
-================
-
------------------------------
-Create custom telemetry record
------------------------------
-
-:Copyright: \(C) 2017 Intel Corporation, CC-BY-SA-3.0
-:Manual section: 1
-
-
-SYNOPSIS
-========
-
-``telem-record-gen`` <options>
-
-
-DESCRIPTION
-===========
-
-Generate and attempt to send a telemetry record to `telemprobd(1) <telemprobd.1.html>`__. This
-program can be used to create a telemetry record from a shell script
-or from another program using e.g. ``system()``. The program connects
-to a local `telemprobd(1) <telemprobd.1.html>`__ daemon to spool the record for delivery to
-the actual collection service.
-
-The payload can be provided as standard input, as a file with the
-``--payload-file`` option, or as a string argument with the ``--payload``
-option. If neither the ``--payload`` or ``--payload-file`` is provided,
-the payload is assumed to be on <stdin>.
-
-Each record is expected to have a class identifier, a record version
-number, and a severity level. A class identifier is required to be
-provided.
-
-
-OPTIONS
-=======
-
- * ``-h``, ``--help``:
-   Show help options.
-
- * ``-V``, ``--version``:
-   Print the program version.
-
- * ``-f``, ``--config-file`` <file>:
-   Path to configuration file (not implemented yet).
-
- * ``-s``, ``--severity``:
-   Severity level (1-4) - (default 1).
-
- * ``-c``, ``--class``:
-   Classification ``level_1``/``level_2``/``level_3``.
-
- * ``-p``, ``--payload`` <payload>:
-   Record body (max size = 8k).
-
- * ``-P``, ``--payload-file`` <file>:
-   File to read payload from.
-
- * ``-R``, ``--record-version`` <version>:
-   Version number for format of payload (default 1).
-
- * ``-e``, ``--event-id`` <version>:
-   Event id to use in the record. If not provided a randomly generated id will be assigned to record.
-
-
-
-RETURN VALUES
-=============
-
-0 on success. A non-zero exit code indicates a failure occurred.
-
-
-SEE ALSO
-========
-
-* `telemprobd(1) <telemprobd.1.html>`__
-* https://github.com/clearlinux/telemetrics-client
-* https://clearlinux.org/documentation/
@@ -1,58 +0,0 @@
-========
-telemctl
-========
-
-------------------------------------
-Telemetry service administration tool
-------------------------------------
-
-:Copyright: \(C) 2017 Intel Corporation, CC-BY-SA-3.0
-:Manual section: 1
-
-
-SYNOPSIS
-========
-
-``telemctl``
-
-``/etc/telemetrics/opt-in``
-
-
-DESCRIPTION
-===========
-
-Control actions for telemetry services. The command can be used to start,
-restart, or stop `telemprobd(1) <telemprobd.1.html>`__ and `telempostd(1) <telempostd.1.html>`__, or to opt-in or opt-out of telemetry delivery of records to a central telemetry service.
-
-
-OPTIONS
-=======
-
- * ``start``|``stop``|``restart``:
-   Starts, stops or restarts all running telemetry services.
-
- * ``opt-in``:
-   Opts in to telemetry and the opt-in file ``/etc/telemetrics/opt-in``
-   is created. Note: this is a one time required operation before
-   telemetry can be used the first time.
-
- * ``opt-out``:
-   Opts out of telemetry, and stops telemetry services. The opt-in file
-   ``/etc/telemetrics/opt-in`` is deleted.
-
- * ``is-active``:
-   Checks if telemetry client daemons are active (telemprobd and telempostd).
-
-
-RETURN VALUES
-=============
-
-0 on success. A non-zero exit code indicates a failure occurred.
-
-
-SEE ALSO
-========
-
-* `telemprobd(1) <telemprobd.1.html>`__
-* https://github.com/clearlinux/telemetrics-client
-* https://clearlinux.org/documentation/
@@ -1,109 +0,0 @@
-================
-telemetrics.conf
-================
-
------------------------------------
-Telemetry service configuration file
------------------------------------
-
-:Copyright: \(C) 2017 Intel Corporation, CC-BY-SA-3.0
-:Manual section: 5
-
-
-SYNOPSIS
-========
-
-``/etc/telemetrics/telemetrics.conf``
-
-``/usr/share/defaults/telemetrics/telemetrics.conf``
-
-
-DESCRIPTION
-===========
-
-This file contains configuration parameters for the `telemprobd(1) <telemprobd.1.html>`__ and `telempostd(1) <telempostd.1.html>`__ telemetry service daemons. The daemon reads this file at startup if it exists.
-
-
-SYNTAX
-======
-
-The configuration file contains ``key=value`` pairs, formatted as plain
-text, one option per line. Comments can be added by preceding them with the
-``#`` character. All configuration options should be in a section marked
-with ``[settings]``.
-
-
-OPTIONS
-=======
-
-  ``server=<url>``
-
-   Server URL including protocol designator.
-
-  ``socket_path=<path>``
-
-   Path to the socket that `telemprobd` will listen on.
-
-  ``cainfo=<path>``
-
-   Certificate file to use for validation of SSL endpoint.
-
-  ``tidheader=<header>``
-
-   Telemetry ID in header format, usually ``tidheader=X-Telemetry-TID:<uuid>``
-   post header used to group records in ingestion service, which may be
-   ingesting for more than one set of clients. Can be set to any string.
-
-  ``record_expiry=<minutes>``
-
-   Record expiry time in minutes.
-
-  ``spool_dir=<dir>``
-
-   Local spool directory used to store records being processed.
-
-  ``spool_max_size=<kB>``
-
-   maximum size of the spool directory in kB. A value of ``-1`` indicates
-   no limit. The block size of the files in this directory is considered,
-   and not the actual size of the record itself.
-
-  ``spool_process_time=<seconds>``
-
-   Time in seconds for processing spool. Valid range: 120..300. Values
-   outside this range are clamped.
-
-  ``rate_limit_enabled=<true|false>``
-
-   Enable rate limiting. If this is set to false then all rate-limiting
-   disabled. It is possible to disable each rate-limit individually below.
-
-  ``record_burst_limit=<limit>``
-
-   Rate limiting record burst limit. Valid Range:  0..``INT_MAX``, -1 = disabled.
-
-  ``record_window_length=<minutes>``
-
-   Rate limiting record window length in minutes. Valid Range: 0..59.
-
-  ``byte_burst_limit=<limit>``
-
-   Rate limiting byte burst limit. Valid Range:  0..`INT_MAX`, -1 = disabled.
-
-  ``byte_window_length=<minutes>``
-
-   Rate limiting byte window length in minutes. Valid Range: 0..59.
-
-  ``rate_limit_strategy=<strategy>``
-
-   Rate limit strategy - what to do with record if rate-limiting prevents
-   delivery over network. Valid stategies: ``spool``, ``drop``.
-
-
-SEE ALSO
-========
-
-* `telemprobd(1) <telemprobd.1.html>`__
-* `telempostd(1) <telempostd.1.html>`__
-* https://github.com/clearlinux/telemetrics-client
-* https://clearlinux.org/documentation/
@@ -1,71 +0,0 @@
-=========
-telemetry
-=========
-
----------------------------------------------
-C programming interface for telemetrics-client
----------------------------------------------
-
-:Copyright: \(C) 2017 Intel Corporation, CC-BY-SA-3.0
-:Manual section: 3
-
-
-SYNOPSIS
-========
-
-``#include "telemetry.h"``
-
-``struct telem_ref { struct telem_record *record; };``
-
-``int tm_create_record(struct telem_ref **t_ref, uint32_t severity, char *classification, uint32_t payload_version)``
-
-``int tm_set_payload(struct telem_ref *t_ref, char *payload)``
-
-``int tm_send_record(struct telem_ref *t_ref)``
-
-``void tm_free_record(struct telem_ref *t_ref)``
-
-``int tm_set_config_file(const char *c_file)``
-
-``int tm_is_opted_in(void)``
-
-
-DESCRIPTION
-===========
-
-The functions in the telemetry library facilitate the delivery of
-telemetry data to the `telemprobd(1) <telemprobd.1.html>`__ service.
-
-The function ``tm_create_record()`` initializes a telemetry record and
-sets the severity and classification of that record, as well as the
-payload version number. The memory needed to store the telemetry record
-is allocated and should be freed with ``tm_free_record()`` when no longer
-needed.
-
-The function ``tm_set_payload()`` attaches the provided telemetry record
-data to the telemetry record. The current maximum payload size is 8192b.
-
-The function ``tm_send_record()`` delivers the record to the local
-`telemprobd(1) <telemprobd.1.html>`__ service.
-
-The function ``tm_set_config_file()`` can be used to provide an alternate
-configuration path to the telemetry library.
-
-``tm_is_opted_in`` is a utility provided to check if the one time opt-in
-has been performed.
-
-RETURN VALUES
-=============
-
-All these functions return ``0`` on success, or a non-zero return value
-if an error occurred. The function ``tm_free_record()`` does not return
-any value. ``tm_is_opted_in`` returns ``1`` when telemetry is opted-in
-otherwise ``0``.
-
-
-SEE ALSO
-========
-
-* `telemprobd(1) <telemprobd.1.html>`__
-* https://github.com/clearlinux/telemetrics-client
-* https://clearlinux.org/documentation/
@@ -1,71 +0,0 @@
-==========
-telempostd
-==========
-
------------------------
-Telemetry client service
------------------------
-
-:Copyright: \(C) 2018 Intel Corporation, CC-BY-SA-3.0
-:Manual section: 1
-
-
-SYNOPSIS
-========
-
-``telempostd`` \<flags\>
-
-``/etc/telemetrics/telemetrics.conf``
-
-``/usr/share/defaults/telemetrics/telemetrics.conf``
-
-``/etc/telemetrics/opt-in-static-machine-id``
-
-
-DESCRIPTION
-===========
-
-The ``telempostd`` program delivers locally generated telemetry records to a remote
-telemetry service. Telemetry data can be in any format, and is relayed as-is.
-
-
-OPTIONS
-=======
-
-  * ``-f``, ``--config_file`` \[\<file\>\]:
-    Configuration file. This overrides the other parameters.
-
-  * ``-h``, ``--help``:
-    Display this help message.
-
-  * ``-V``, ``--version``:
-    Print the program version.
-
-
-FILES
-=====
-
-* ``/usr/share/defaults/telemetrics/telemetrics.conf``
-
-    If no custom configuration file is found, ``telempostd`` uses the
-    settings in this file.
-
-* ``/etc/telemetrics/telemetrics.conf``
-
-    Custom configuration file that ``telempostd`` reads. See `telemetrics.conf(5) <telemetrics.conf.5.html>`__.
-
-
-EXIT STATUS
-===========
-
-0 when no errors occurred. A non-zero exit status indicates a failure occurred.
-
-
-SEE ALSO
-========
-
-* `telemetry(3) <telemetry.3.html>`__
-* `telemetrics.conf(5) <telemetrics.conf.5.html>`__
-* https://github.com/clearlinux/telemetrics-client
-* https://clearlinux.org/documentation/
-
@@ -1,78 +0,0 @@
-==========
-telemprobd
-==========
-
------------------------
-Telemetry probes service
------------------------
-
-:Copyright: \(C) 2017 Intel Corporation, CC-BY-SA-3.0
-:Manual section: 1
-
-
-SYNOPSIS
-========
-
-``telemprobd`` \<flags\>
-
-``/etc/telemetrics/telemetrics.conf``
-
-``/usr/share/defaults/telemetrics/telemetrics.conf``
-
-``/etc/telemetrics/opt-in-static-machine-id``
-
-
-DESCRIPTION
-===========
-
-The ``telemprobd`` program handles communication between telemetry client and telemetry
-probes.
-
-
-OPTIONS
-=======
-
-  * ``-f``, ``--config_file`` \[\<file\>\]:
-    Configuration file. This overides the other parameters.
-
-  * ``-h``, ``--help``:
-    Display this help message.
-
-  * ``-V``, ``--version``:
-    Print the program version.
-
-
-FILES
-=====
-
-* ``/usr/share/defaults/telemetrics/telemetrics.conf``
-
-    If no custom configuration file is found, ``telemprobd`` uses the
-    settings in this file.
-
-* ``/etc/telemetrics/telemetrics.conf``
-
-    Custom configuration file that ``telemprobd`` reads. See `telemetrics.conf(5) <telemetrics.conf.5.html>`__.
-
-
-* ``/etc/telemetrics/opt-in-static-machine-id``
-
-    If this file exists, the first line of this file will be sent to
-    the server as the machine ID. Otherwise, the machine ID will be
-    random and changed regularly.
-
-
-EXIT STATUS
-===========
-
-0 when no errors occurred. A non-zero exit status indicates a failure occurred.
-
-
-SEE ALSO
-========
-
-* `telemetry(3) <telemetry.3.html>`__
-* `telemetrics.conf(5) <telemetrics.conf.5.html>`__
-* https://github.com/clearlinux/telemetrics-client
-* https://clearlinux.org/documentation/
-
@@ -1,53 +0,0 @@
-ucd-data-fetch
-==============
-
-`ucd-data-fetch(1) <ucd-data-fetch.1.html>`__ – Fetch user-data and ssh keys from cloud services
-
-SYNOPSIS
--------
-
-``/usr/bin/ucd-data-fetch <aws|oci|tencent>``
-
-DESCRIPTION
-----------
-
-``ucd-data-fetch`` is a helper agent program that fetches openstack
-user-data from the http://169.254.*/ service, as well as the SSH pubkey
-provided to the cloud instance. After fetching the two pieces of data,
-ucd-data-fetch combines them into a valid ``#cloud-config`` user-data
-text block and passes the output to `ucd(1) <ucd.1.html>`__ for
-processing/execution.
-
-The user-data file is currently only fetched for aws instances.
-
-OPTIONS
-------
-
-The only parameter supported is the name of the cloud service provider,
-and can be ``aws``, ``oci`` or ``tencent``. It is required, and if not
-passed as argument 1, will cause the program to terminate with an error
-message.
-
-EXIT STATUS
-----------
-
-On success, 0 is returned, a non-zero failure code otherwise. The exit
-code returned may be the exit code of the subsequent ``ucd`` program
-execution.
-
-COPYRIGHT
---------
-
-  Copyright (C) 2017-2019 Intel Corporation, License: CC-BY-SA-3.0
-
-SEE ALSO
--------
-
-`ucd(1) <ucd.1.html>`__
-
-NOTES
-----
-
-Creative Commons Attribution-ShareAlike 3.0 Unported
-
-  http://creativecommons.org/licenses/by-sa/3.0/
--- a/Show More
+++ b/Show More