Change to new branding

docs/README.md

@@ -5,8 +5,8 @@ The website content it is deployed automatically in the `gh-pages` branch by Git
 After cloning the repo (with submodules), just run `make serve` to test the website locally.
 
 ```
-$> git clone --recurse-submodule https://github.com/rancher-sandbox/cos-toolkit
-$> cd cos-toolkit
+$> git clone --recurse-submodule https://github.com/rancher/elemental-toolkit
+$> cd elemental-toolkit
 $> cd docs; make serve
 ```
 

docs/config.toml

@@ -1,9 +1,9 @@
-baseURL = "https://rancher-sandbox.github.io/cos-toolkit/" # for local debugging / is enough
+baseURL = "https://rancher.github.io/elemental-toolkit/" # for local debugging / is enough
 # Set canonifyUrls to true when baseURL is containing subpaths
 canonifyurls = true
 
 languageCode = "en-us"
-title = "cOS toolkit"
+title = "Elemental toolkit"
 
 enableRobotsTXT = true
 
@@ -58,21 +58,21 @@ id = "UA-00000000-0"
 [languages]
 [languages.en]
 title = "cOS toolkit"
-description = "cOS toolkit documentation website"
+description = "Elemental toolkit documentation website"
 languageName ="English"
 # Weight used for sorting.
 weight = 1
 
 [[menu.main]]
     name = "Github releases"
     weight = 50
-    url = "https://github.com/rancher-sandbox/cOS-toolkit/releases"
+    url = "https://github.com/rancher/elemental-toolkit/releases"
     pre = "<i class='fab fa-github'></i>"
     post = "" 
 [[menu.main]]
     name = "Browse packages"
     weight = 55
-    url = "https://rancher-sandbox.github.io/cos-toolkit-package-browser/"
+    url = "https://rancher.github.io/elemental-toolkit-package-browser/"
     pre = "<i class='fa fa-toolbox'></i>"
     post = "" 
 
@@ -115,13 +115,13 @@ version = "0.5.8"
 
 # A link to latest version of the docs. Used in the "version-banner" partial to
 # point people to the main doc site.
-url_latest_version = "https://rancher-sandbox.github.io/cos-toolkit/"
+url_latest_version = "https://rancher.github.io/elemental-toolkit/"
 
 # Repository configuration (URLs for in-page links to opening issues and suggesting changes)
-github_repo = "https://github.com/rancher-sandbox/cOS-toolkit"
+github_repo = "https://rancher.github.io/elemental-toolkit"
 # An optional link to a related project repo. For example, the sibling repository where your product code lives.
-github_project_repo = "https://github.com/rancher-sandbox/cOS-toolkit"
-github = "https://github.com/rancher-sandbox/cOS-toolkit"
+github_project_repo = "https://rancher.github.io/elemental-toolkit"
+github = "https://rancher.github.io/elemental-toolkit"
 # Specify a value here if your content directory is not in your repo's root directory
 github_subdir = "docs"
 # Uncomment this if you have a newer GitHub repo with "main" as the default branch,
@@ -160,8 +160,8 @@ footer_about_disable = false
 [params.ui.feedback]
 enable = true
 # The responses that the user sees after clicking "yes" (the page was helpful) or "no" (the page was not helpful).
-yes = 'Glad to hear it! Please <a href="https://github.com/rancher-sandbox/cOS-toolkit/issues/new">tell us how we can improve</a>.'
-no = 'Sorry to hear that. Please <a href="https://github.com/rancher-sandbox/cOS-toolkit/issues/new">tell us how we can improve</a>.'
+yes = 'Glad to hear it! Please <a href="https://github.com/rancher/elemental-toolkit/issues/new">tell us how we can improve</a>.'
+no = 'Sorry to hear that. Please <a href="https://github.com/rancher/elemental-toolkit/issues/new">tell us how we can improve</a>.'
 
 # Adds a reading time to the top of each doc.
 # If you want this feature, but occasionally need to remove the Reading time from a single page, 

docs/content/en/_index.html

@@ -1,5 +1,5 @@
 ---
-title: "cOS toolkit"
+title: "Elemental toolkit"
 description: "Immutable Linux Derivatives at your fingertips"
 ---
 
@@ -78,7 +78,7 @@ <h2 class="font-weight-bolder mb-0">How it Works<br></h2>
   <div class="white text-center">
     <h2>Get Started</h2>
     <div class="grid-three">
-      <h4>Step 1.<br/><tt>git clone <a href="https://github.com/rancher-sandbox/cos-toolkit" target="_blank">https://github.com/rancher-sandbox/cos-toolkit</a></tt></h4>
+      <h4>Step 1.<br/><tt>git clone <a href="https://github.com/rancher/elemental-toolkit" target="_blank">https://github.com/rancher/elemental-toolkit</a></tt></h4>
       <h4>Step 2.<br/><tt>docker build -t example examples/standard</tt></h4>
       <h4>Step 3.<br/><tt>elemental upgrade example</tt></h4>
     </div>
@@ -89,7 +89,7 @@ <h4>Step 3.<br/><tt>elemental upgrade example</tt></h4>
         <h2>Learn More</h2>
         <p class="text-center">Ready to upgrade?</p>
         <div class="text-center">
-          <a href="https://github.com/rancher-sandbox/cOS-toolkit" target="blank" class="btn">Build with cOS toolkit today</a>
+          <a href="https://github.com/rancher/elemental-toolkit" target="blank" class="btn">Build with cOS toolkit today</a>
         </div>
     </div>
   </div>

docs/content/en/docs/Creating derivatives/Packer/_index.md

@@ -9,6 +9,6 @@ description: >
 
 {{<image_center image="https://docs.google.com/drawings/d/e/2PACX-1vTOn0fYAI589csRoONln7aCttWWNyUc2DvEUt9Dw6tys4nzyearrIUaCXYpg6lknli16z_Kz1N-ugxK/pub?w=507&h=217">}}
 
-For Vagrant Boxes, OVA and QEMU images at the moment we are relying on [packer templates](https://github.com/rancher-sandbox/cOS-toolkit/tree/master/packer). 
+For Vagrant Boxes, OVA and QEMU images at the moment we are relying on [packer templates](https://github.com/rancher/elemental-toolkit/tree/master/packer). 
 
 The cOS vanilla images can be used as input to Packer to deploy pristine images of the user container image with [elemental reset](../../getting-started/deploy). 

docs/content/en/docs/Creating derivatives/Packer/build_ami.md

@@ -15,7 +15,7 @@ Requirements:
 * Packer
 * AWS access keys with the appropriate roles and permissions
 * A Vanilla AMI
-* [Packer templates](https://github.com/rancher-sandbox/cOS-toolkit/tree/master/packer)
+* [Packer templates](https://github.com/rancher/elemental-toolkit/tree/master/packer)
 
 The suggested approach is based on using Packer templates to customize the
 deployment and automate the upload and publish to AWS of cOS derivatives or cOS itself. For all the details

docs/content/en/docs/Creating derivatives/Packer/build_azure.md

@@ -15,7 +15,7 @@ Requirements:
 * Packer
 * Azure access keys with the appropriate roles and permissions
 * [A Vanilla image](../../../getting-started/booting/#importing-an-azure-image-manually)
-* [Packer templates](https://github.com/rancher-sandbox/cOS-toolkit/tree/master/packer)
+* [Packer templates](https://github.com/rancher/elemental-toolkit/tree/master/packer)
 
 The suggested approach is based on using Packer templates to customize the
 deployment and automate the upload and publish to Azure of cOS derivatives or cOS itself. For all the details

docs/content/en/docs/Creating derivatives/Packer/build_gcp.md

@@ -16,7 +16,7 @@ Requirements:
 * Google Compute Packer [plugin](https://www.packer.io/docs/builders/googlecompute)
 * [Google Cloud SDK](https://cloud.google.com/sdk/docs/install)
 * A Vanilla AMI
-* [Packer templates](https://github.com/rancher-sandbox/cOS-toolkit/tree/master/packer)
+* [Packer templates](https://github.com/rancher/elemental-toolkit/tree/master/packer)
 
 The suggested approach is based on using Packer templates to customize the
 deployment and automate the upload and publish to GCP of cOS derivatives or cOS itself. For all the details

docs/content/en/docs/Creating derivatives/Packer/build_images.md

@@ -14,9 +14,9 @@ Requirements:
 * Packer
 * Either qemu or VirtualBox functioning in the build host
 * a cOS or a [custom ISO](../../build_iso)
-* [Packer templates](https://github.com/rancher-sandbox/cOS-toolkit/tree/master/packer)
+* [Packer templates](https://github.com/rancher/elemental-toolkit/tree/master/packer)
 
-The suggested approach is based on using [Packer templates](https://github.com/rancher-sandbox/cOS-toolkit/tree/master/packer) to customize the
+The suggested approach is based on using [Packer templates](https://github.com/rancher/elemental-toolkit/tree/master/packer) to customize the
 deployment and automate creation of QCOW, Virtualbox and Vagrant images of cOS derivatives or cOS itself. For all the details
 and possibilties of Packer check the [official documentation](https://www.packer.io/guides/hcl).
 

docs/content/en/docs/Creating derivatives/_index.md

@@ -17,13 +17,13 @@ We can identify a build phase where we build the derivative, and a "runtime phas
 
 The image is described by a Dockerfile, composed of a base OS of choice (e.g. openSUSE, Ubuntu, etc. ) and the cOS toolkit itself in order to be consumed by cOS and allow to be upgraded from by other derivatives. 
 
-cOS-toolkit then converts the OCI artifact into a bootable medium (ISO, packer, ova, etc) and the image itself then can be used to bootstrap other derivatives, which can in turn upgrade to any derivative built with cOS.
+elemental-toolkit then converts the OCI artifact into a bootable medium (ISO, packer, ova, etc) and the image itself then can be used to bootstrap other derivatives, which can in turn upgrade to any derivative built with cOS.
 
 A derivative can also be later re-used again as input as base-image for downstream derivatives.
 
 All the documentation below imply that the container image generated will be the booting one, there are however several configuration entrypoint that you should keep in mind while building the image which are general across all the implementation:
 
-- Custom persistent runtime configuration has to be provided in `/system/oem` for derivatives, [see also the documentation section](../customizing/configuration_persistency).  Everything under `/system/oem` will be loaded during the various stages (boot, network, initramfs). You can check [here](https://github.com/rancher-sandbox/cOS-toolkit/tree/e411d8b3f0044edffc6fafa39f3097b471ef46bc/packages/cloud-config/oem) for the `cOS` defaults. See `00_rootfs.yaml` to customize the booting layout.
+- Custom persistent runtime configuration has to be provided in `/system/oem` for derivatives, [see also the documentation section](../customizing/configuration_persistency).  Everything under `/system/oem` will be loaded during the various stages (boot, network, initramfs). You can check [here](https://github.com/rancher/elemental-toolkit/tree/e411d8b3f0044edffc6fafa39f3097b471ef46bc/packages/cloud-config/oem) for the `cOS` defaults. See `00_rootfs.yaml` to customize the booting layout.
 - `/etc/cos/bootargs.cfg` contains the booting options required to boot the image with GRUB, [see grub customization](../customizing/configure_grub)
 - `/etc/cos-upgrade-image` contains the default upgrade configuration for recovery and the booting system image, [see customizing upgrades](../customizing/upgrades)
 

docs/content/en/docs/Creating derivatives/build_disk.md

@@ -19,7 +19,7 @@ converted to other formats after the installation by using `qemu-img convert`.
 
 ## Get Elemental
 
-Elemental binary can be downloaded from the [github releases](https://github.com/rancher-sandbox/elemental/releases/latest) page.
+Elemental binary can be downloaded from the [github releases](https://github.com/rancher/elemental-cli/releases/latest) page.
 
 The golang binary can be used as is, however take into account that some linux utilities are expected to be present in the host. More
 specific elemental expects to find common linux utilities to operate over block devices: rsync, parted, blkid, lsblk, udevadm, resize2fs, tune2fs, mkfs.ext2, etc.

docs/content/en/docs/Creating derivatives/build_iso.md

@@ -9,7 +9,7 @@ description: >
 
 ![](https://docs.google.com/drawings/d/e/2PACX-1vReZtyNs0imrji-AwnqK0-4ekCKLcKzfnQ_CwiMj93Q7IsycAJHwlNohwCv_hyHnaify7qO-v2Cecg5/pub?w=1223&h=691)
 
-In order to build an iso we rely on [elemental build-iso](https://github.com/rancher-sandbox/elemental) command. It accepts a YAML file denoting the packages to bundle in an ISO and a list of luet repositories where to download the packages from. In addition it can also overlay custom files or use container images from a registry as packages.
+In order to build an iso we rely on [elemental build-iso](https://github.com/rancher/elemental-cli) command. It accepts a YAML file denoting the packages to bundle in an ISO and a list of luet repositories where to download the packages from. In addition it can also overlay custom files or use container images from a registry as packages.
 
 To build an iso, just run:
 
@@ -21,7 +21,7 @@ Where `$IMAGE` is the container image you want to build the ISO for, you might w
 
 `elemental build-iso` command also supports reading a configuration `manifest.yaml` file. It is loaded form the directory specified by `--config-dir` elemental's flag.
 
-An example of a yaml file using the cos-toolkit opensuse repositories:
+An example of a yaml file using the elemental-toolkit opensuse repositories:
 
 ```yaml
 iso:

docs/content/en/docs/Creating derivatives/cosign.md

@@ -5,14 +5,14 @@ linkTitle: "Cosign"
 weight: 2
 date: 2020-11-02
 description: >
-  How we use cosign in cos-toolkit
+  How we use cosign in elemental-toolkit
 ---
 
 [Cosign](https://github.com/sigstore/cosign) is a project that signs and verifies containers and stores the signatures on OCI registries.
 
 You can check the cosign [github repo](https://github.com/sigstore/cosign) for more information.
 
-In cos-toolkit we sign every container that we generate as part of our publish process so the signature can be verified during package installation with luet or during deploy/upgrades from a deployed system to verify that the containers have not been altered in any way since their build.
+In elemental-toolkit we sign every container that we generate as part of our publish process so the signature can be verified during package installation with luet or during deploy/upgrades from a deployed system to verify that the containers have not been altered in any way since their build.
 
 Currently cosign provides 2 methods for signing and verifying.
 
@@ -40,13 +40,13 @@ If building a derivative, you can also sign and verify you final artifacts with
 As keyless is only possible to do in an CI environment (as it needs an OIDC token) you would need to set up private/public signature and verification.
 
 {{% alert title="Note" %}}
-If you are building and publishing your derivatives with luet on github, you can see an example on how we generate and push the keyless signatures ourselves on [this workflow](https://github.com/rancher-sandbox/cOS-toolkit/blob/master/.github/workflows/build-master-teal-x86_64.yaml#L445)
+If you are building and publishing your derivatives with luet on github, you can see an example on how we generate and push the keyless signatures ourselves on [this workflow](https://github.com/rancher/elemental-toolkit/blob/master/.github/workflows/build-master-teal-x86_64.yaml#L445)
 {{% /alert %}}
 
 
-### Verify cos-toolkit artifacts as part of derivative building
+### Verify elemental-toolkit artifacts as part of derivative building
 
-If you consume cos-toolkit artifacts in your Dockerfile as part of building a derivative you can verify the signatures of the artifacts by setting:
+If you consume elemental-toolkit artifacts in your Dockerfile as part of building a derivative you can verify the signatures of the artifacts by setting:
 
 ```dockerfile
 ENV COSIGN_REPOSITORY=raccos/releases-teal
@@ -59,7 +59,7 @@ The {{<package package="meta/cos-verify" >}} is a meta package that will pull {{
 {{% /alert %}}
 
 
-And then making sure you call luet with `--plugin luet-cosign`. You can see an example of this in our [standard Dockerfile example](https://github.com/rancher-sandbox/cOS-toolkit/tree/master/examples/standard) 
+And then making sure you call luet with `--plugin luet-cosign`. You can see an example of this in our [standard Dockerfile example](https://github.com/rancher/elemental-toolkit/tree/master/examples/standard) 
 
 That would verify the artifacts coming from our repository.
 

docs/content/en/docs/Creating derivatives/creating_bootable_images.md

@@ -19,7 +19,7 @@ Bootable images are standard container images, that means the usual `build` and
 The base image can be any Linux distribution that is compatible with our flavors.
 
 The image needs to ship:
-- parts of the cos-toolkit (required, see below)
+- parts of the elemental-toolkit (required, see below)
 - kernel (required)
 - initrd (required)
 - grub (required)
@@ -32,14 +32,14 @@ The image needs to ship:
 An illustrative example can be:
 
 
-{{<githubembed repo="rancher-sandbox/cos-toolkit" file="examples/standard/Dockerfile" lang="Dockerfile">}}
+{{<githubembed repo="rancher/elemental-toolkit" file="examples/standard/Dockerfile" lang="Dockerfile">}}
 
 With the config file:
 
-{{<githubembed repo="rancher-sandbox/cos-toolkit" file="examples/standard/conf/luet.yaml" lang="yaml">}}
+{{<githubembed repo="rancher/elemental-toolkit" file="examples/standard/conf/luet.yaml" lang="yaml">}}
 
 
-In the example above, the cos-toolkit parts that are **required** are pulled in by `RUN luet install -y meta/cos-minimal`.
+In the example above, the elemental-toolkit parts that are **required** are pulled in by `RUN luet install -y meta/cos-minimal`.
 Afterwards we install k9s and nerdctl packages to create our derivative with those packages on it.
 
 ### Meta packages
@@ -100,7 +100,7 @@ The {{<package package="meta/cos-verify" >}} is a meta package that will pull {{
 
 {{<package package="toolchain/cosign" >}} and {{<package package="toolchain/luet-cosign" >}} are optional packages that would install cosign and luet-cosign in order to verify the packages installed by luet.
 
-You can use cosign to both verify that packages coming from cos-toolkit are verified and sign your own derivative artifacts
+You can use cosign to both verify that packages coming from elemental-toolkit are verified and sign your own derivative artifacts
 
 {{% alert title="Note" %}}
 If you want to manually verify cosign and luet-cosign packages before installing them with luet, you can do so by:

docs/content/en/docs/Creating derivatives/package_stack.md

@@ -8,10 +8,10 @@ description: >
 ---
 
 
-When building a `cos-toolkit` derivative, a common set of packages are provided already with a common default configuration. Some of the most notably are:
+When building a `elemental-toolkit` derivative, a common set of packages are provided already with a common default configuration. Some of the most notably are:
 
 - systemd as init system
 - grub for boot loader
 - dracut for initramfs
 
-Each `cos-toolkit` flavor (opensuse, ubuntu, fedora) ships their own set of base packages depending on the distribution they are based against. You can find the list of packages in the `packages` keyword in the corresponding [values file for each flavor](https://github.com/rancher-sandbox/cOS-toolkit/tree/master/values)
+Each `elemental-toolkit` flavor (opensuse, ubuntu, fedora) ships their own set of base packages depending on the distribution they are based against. You can find the list of packages in the `packages` keyword in the corresponding [values file for each flavor](https://github.com/rancher/elemental-toolkit/tree/master/values)

docs/content/en/docs/Customizing/general_configuration.md

@@ -18,7 +18,7 @@ By default `<config-dir>` is set to `/etc/elemental` however this can be changed
 
 Below you can find an example of the config file including most of the available options:
 
-{{<githubembed repo="rancher-sandbox/elemental" file="config.yaml.example" lang="yaml">}}
+{{<githubembed repo="rancher/elemental-cli" file="config.yaml.example" lang="yaml">}}
 
 
 The `system` and `recovery-system` objects are an image specification. An image specification is defined by:

docs/content/en/docs/Customizing/oem_configuration.md

@@ -7,7 +7,7 @@ description: >
   OEM configuration reserved to cOS and derivatives
 ---
 
-There are several way to customize cOS and a cos-toolkit derivative:
+There are several way to customize cOS and a elemental-toolkit derivative:
 
 - declaratively in runtime with cloud-config file (by overriding, or extending)
 - stateful, embedding any configuration in the container image to be booted.