From 50744a4fc7d2bf870a80e9b184f838ab76df41b2 Mon Sep 17 00:00:00 2001 From: Stefan Sundin Date: Sat, 12 Nov 2022 12:59:56 -0800 Subject: [PATCH] Fix various minor formatting issues, mostly in the documentation. --- BUILDING.md | 34 ++++++----- CHANGELOG.md | 2 +- CONTRIBUTING.md | 2 +- PROVISIONING-METAL.md | 13 +++-- PUBLISHING-AWS.md | 3 +- PUBLISHING.md | 4 +- QUICKSTART-ECS.md | 23 ++++---- QUICKSTART-EKS.md | 52 +++++++++-------- QUICKSTART-LOCAL.md | 18 +++--- QUICKSTART-VMWARE.md | 58 ++++++++++++------- README.md | 56 +++++++++--------- ROADMAP.md | 25 ++++---- SECURITY_GUIDANCE.md | 6 +- TESTING.md | 28 ++++----- packages/README.md | 12 ++-- packages/docker-cli/clarify.toml | 2 +- packages/ecs-agent/pkg.rs | 2 +- .../kubernetes-1.24/etc-kubernetes-pki.mount | 2 +- sources/api/README.md | 12 ++-- sources/api/apiclient/README.md | 40 ++++++------- sources/api/apiclient/README.tpl | 38 ++++++------ sources/api/apiserver/README.md | 2 +- sources/api/bootstrap-containers/README.md | 6 +- sources/api/bootstrap-containers/src/main.rs | 4 +- sources/api/bork/src/README.md | 4 +- sources/api/certdog/README.md | 2 +- sources/api/corndog/README.md | 2 +- sources/api/datastore/README.md | 2 +- sources/api/early-boot-config/README.md | 2 +- sources/api/ecs-settings-applier/README.md | 2 +- sources/api/host-containers/README.md | 2 +- sources/api/migration/README.md | 4 +- sources/api/migration/migrator/README.md | 2 +- sources/api/netdog/README.md | 2 +- sources/api/pluto/README.md | 4 +- sources/api/pluto/README.tpl | 2 +- sources/api/prairiedog/README.md | 2 +- sources/api/schnauzer/README.md | 2 +- sources/api/settings-committer/README.md | 2 +- sources/api/shibaken/README.md | 2 +- sources/api/static-pods/README.md | 2 +- sources/api/storewolf/README.md | 2 +- sources/api/sundog/README.md | 2 +- sources/api/thar-be-settings/README.md | 2 +- sources/api/thar-be-updates/README.md | 2 +- sources/bottlerocket-release/README.md | 2 +- sources/bottlerocket-variant/README.md | 2 +- sources/cfsignal/README.md | 2 +- sources/constants/README.md | 2 +- sources/driverdog/README.md | 2 +- sources/generate-readme/src/lib.rs | 7 ++- sources/ghostdog/README.md | 2 +- sources/imdsclient/README.md | 2 +- sources/logdog/README.md | 5 +- sources/logdog/src/main.rs | 3 +- sources/metricdog/README.md | 2 +- sources/models/README.md | 2 +- sources/models/model-derive/README.md | 2 +- sources/models/scalar-derive/README.md | 2 +- sources/models/scalar/README.md | 2 +- sources/parse-datetime/README.md | 2 +- sources/retry-read/README.md | 2 +- sources/shimpei/README.md | 2 +- sources/updater/.gitignore | 2 +- sources/updater/README.md | 14 ++--- sources/updater/signpost/.gitignore | 2 +- .../kms_key_setup.yml | 2 +- .../cloudformation-templates/s3_setup.yml | 8 +-- .../test_tomls/toml_yaml_conversion.toml | 10 ++-- tools/partyplanner | 10 ++-- tools/pubsys/policies/ssm/README.md | 4 +- tools/rpm2img | 2 +- tools/testsys/Test.toml.example | 4 +- variants/README.md | 8 +-- 74 files changed, 320 insertions(+), 283 deletions(-) diff --git a/BUILDING.md b/BUILDING.md index b773439d044..44af8ca9396 100644 --- a/BUILDING.md +++ b/BUILDING.md @@ -25,13 +25,13 @@ Ensure the following OS packages are installed: ##### Ubuntu -``` +```shell apt install build-essential openssl libssl-dev pkg-config liblz4-tool ``` ##### Fedora -``` +```shell yum install make automake gcc openssl openssl-devel pkg-config lz4 perl-FindBin perl-lib ``` @@ -45,7 +45,7 @@ Rust 1.51.0 or higher is required. To organize build tasks, we use [cargo-make](https://sagiegurari.github.io/cargo-make/). To get it, run: -``` +```shell cargo install cargo-make ``` @@ -68,11 +68,11 @@ Docker's [post-installation steps for Linux](https://docs.docker.com/install/lin To build an image, run: -``` +```shell cargo make ``` -This will build an image for the default variant, `aws-k8s-1.24`. +This will build an image for the default variant (a recent `aws-k8s-*`, see the `BUILDSYS_VARIANT` variable in [Makefile.toml](Makefile.toml) to find the current default variant). All packages will be built in turn, and then compiled into an `img` file in the `build/images/` directory. The version number in [Release.toml](Release.toml) will be used in naming the file, and will be used inside the image as the release version. @@ -80,16 +80,22 @@ If you're planning on [publishing your build](PUBLISHING.md), you may want to ch To build an image for a different variant, run: -``` +```shell cargo make -e BUILDSYS_VARIANT=my-variant-here ``` To build an image for a different architecture, run: -``` +```shell cargo make -e BUILDSYS_ARCH=my-arch-here ``` +If you want to limit the build concurrency, set `BUILDSYS_JOBS` (the default is `8`): + +```shell +cargo make -e BUILDSYS_JOBS=4 +``` + (You can use variant and arch arguments together, too.) #### Package licenses @@ -160,7 +166,7 @@ If you're using an EC2 instance, the [EC2 instance's IAM role](https://docs.aws. For a simple start, pick an [EC2 region](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html#concepts-available-regions), then run: -``` +```shell cargo make -e PUBLISH_REGIONS=your-region-here ami ``` @@ -170,7 +176,7 @@ Your new AMI ID will be printed after it's registered. If you built your image for a different architecture or variant, just use the same arguments here: -``` +```shell cargo make -e PUBLISH_REGIONS=your-region-here -e BUILDSYS_VARIANT=my-variant-here ami ``` @@ -200,19 +206,19 @@ kmod kits are included in the official Bottlerocket repos starting with Bottlero Let's say you want to download the kit for building x86_64 modules for v1.7.0 and variant aws-k8s-1.21. First, you need tuftool: -```bash +```shell cargo install tuftool ``` Next, you need the Bottlerocket root role, which is used by tuftool to verify the kmod kit. This will download and verify the root role itself: -```bash +```shell curl -O "https://cache.bottlerocket.aws/root.json" sha512sum -c <<<"b81af4d8eb86743539fbc4709d33ada7b118d9f929f0c2f6c04e1d41f46241ed80423666d169079d736ab79965b4dd25a5a6db5f01578b397496d49ce11a3aa2 root.json" ``` Next, set your desired parameters, and download the kmod kit: -```bash +```shell ARCH=x86_64 VERSION=v1.7.0 VARIANT=aws-k8s-1.21 @@ -227,11 +233,11 @@ tuftool download "${OUTDIR}" --target-name ${VARIANT}-${ARCH}-kmod-kit-${VERSION ### Using the kmod kit To use the kmod kit, extract it, and update your PATH to use its toolchain: -```bash +```shell tar xf "${VARIANT}-${ARCH}-kmod-kit-${VERSION}.tar.xz" export CROSS_COMPILE="${ARCH}-bottlerocket-linux-musl-" -export KERNELDIR="${PWD}/${VARIANT}-${ARCH}-kmod-kit-${VERSION}/kernel-devel +export KERNELDIR="${PWD}/${VARIANT}-${ARCH}-kmod-kit-${VERSION}/kernel-devel" export PATH="${PWD}/${VARIANT}-${ARCH}-kmod-kit-${VERSION}/toolchain/usr/bin:${PATH}" ``` diff --git a/CHANGELOG.md b/CHANGELOG.md index f9ea3c21e33..184d4ce9425 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -276,7 +276,7 @@ * New mount in host containers for system logs ([#2295]) * Apply strict mount options and enforce execution rules ([#2239]) * Switch to a more commonly used syntax for disabling kernel config settings ([#2290]) -* Respect proxy settings when running setting generators ([#2227]) +* Respect proxy settings when running setting generators ([#2227]) * Add `NET_CAP_ADMIN` to bootstrap containers ([#2266]) * Reduce log output for DHCP services ([#2260]) * Fix invalid kernel config options ([#2269]) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index eae718f99ba..724daab650b 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -39,7 +39,7 @@ To send us a pull request, please: GitHub provides additional documentation on [forking a repository](https://help.github.com/articles/fork-a-repo/) and [creating a pull request](https://help.github.com/articles/creating-a-pull-request/). -## Repo branch and tag structure +## Repo branch and tag structure Active development occurs under the `develop` branch. diff --git a/PROVISIONING-METAL.md b/PROVISIONING-METAL.md index f4e998a0d48..c3ff040d585 100644 --- a/PROVISIONING-METAL.md +++ b/PROVISIONING-METAL.md @@ -27,14 +27,15 @@ The Bottlerocket image for bare metal is signed and uploaded alongside the rest You first need the Bottlerocket root role, which is used by `tuftool` to verify the image. The following will download and verify the root role itself: -``` +```shell curl -O "https://cache.bottlerocket.aws/root.json" sha512sum -c <<<"b81af4d8eb86743539fbc4709d33ada7b118d9f929f0c2f6c04e1d41f46241ed80423666d169079d736ab79965b4dd25a5a6db5f01578b397496d49ce11a3aa2 root.json" ``` Next, set your desired version and variant, and use `tuftool` to download the image: To install `tuftool` you'll need to install Rust (via [rustup](https://rustup.rs/) or the official site), and then you can run `cargo install tuftool`. -``` + +```shell ARCH="x86_64" VERSION="v1.9.0" VARIANT="metal-k8s-1.23" @@ -106,6 +107,7 @@ Please keep in mind that when using static addresses, DNS information must be su * `route-metric` (integer): Relative route priority. Example `net.toml` with comments: + ```toml version = 2 @@ -174,6 +176,7 @@ Settings prefixed with `init` are added to the kernel command line after the `-- In the example below, two console devices are set up, and `systemd`'s log level is set to `debug`. Example Boot Configuration: + ``` kernel { console = tty0, "ttyS1,115200n8" @@ -187,7 +190,8 @@ The Bottlerocket SDK provides the `bootconfig` CLI tool, which is used to create To create the Boot Configuration initrd, create a config file named `bootconfig-input` containing your desired key/value pair kernel and init arguments. Then run the following (you will need Docker installed): -``` + +```shell ARCH=$(uname -m) SDK_VERSION="v0.26.0" SDK_IMAGE="public.ecr.aws/bottlerocket/bottlerocket-sdk-${ARCH}:${SDK_VERSION}" @@ -208,7 +212,8 @@ The above command will create the properly named initrd `bootconfig.data` in you This is the file you will write to disk during provisioning. You can list a `bootconfig.data`'s contents, which also validates its format, by running: -``` + +```shell ARCH=$(uname -m) SDK_VERSION="v0.26.0" SDK_IMAGE="public.ecr.aws/bottlerocket/bottlerocket-sdk-${ARCH}:${SDK_VERSION}" diff --git a/PUBLISHING-AWS.md b/PUBLISHING-AWS.md index 3ac2116ac4e..486ccdb98c5 100644 --- a/PUBLISHING-AWS.md +++ b/PUBLISHING-AWS.md @@ -109,7 +109,7 @@ This is useful for testing, and for sharing private AMIs with specific accounts. If you want to make your AMIs public to the world, there's a shortcut: -``` +```shell cargo make ami-public ``` @@ -137,6 +137,7 @@ This will copy the fully versioned parameter from earlier, something like: ``` ...to a simpler parameter name: + ``` /your/prefix/here/aws-k8s-1.24/x86_64/latest/image_id ``` diff --git a/PUBLISHING.md b/PUBLISHING.md index a60be25efaf..d80f2475b95 100644 --- a/PUBLISHING.md +++ b/PUBLISHING.md @@ -141,13 +141,13 @@ There's nothing secret in a root role file, so if you have a way of storing it r The `signing_keys` portion above references a local file path. If you want to use an SSM or KMS key, you'd write it like this, instead: -``` +```toml signing_keys = { kms = { key_id = "abc-def-123" } } ``` ...or... -``` +```toml signing_keys = { ssm = { parameter = "/my/parameter" } } ``` diff --git a/QUICKSTART-ECS.md b/QUICKSTART-ECS.md index f916379c538..0add9c3be3b 100644 --- a/QUICKSTART-ECS.md +++ b/QUICKSTART-ECS.md @@ -24,7 +24,7 @@ For more information about clusters, see You can create a cluster with the AWS CLI as follows: -``` +```shell aws ecs --region us-west-2 create-cluster --cluster-name bottlerocket ``` @@ -82,12 +82,13 @@ For example, to use the parameter above, you would pass this as the AMI ID in yo If you prefer to fetch the AMI ID yourself, you can use [aws-cli](https://aws.amazon.com/cli/) on the command line. To fetch the example parameter above, for the us-west-2 region, you could run this: -``` +```shell aws ssm get-parameter --region us-west-2 --name "/aws/service/bottlerocket/aws-ecs-1/x86_64/latest/image_id" --query Parameter.Value --output text ``` -If you have `jq` and would like a bit more information, try this: -``` +If you have `jq` installed and would like a bit more information, try this: + +```shell aws ssm get-parameters --region us-west-2 \ --names "/aws/service/bottlerocket/aws-ecs-1/x86_64/latest/image_id" \ "/aws/service/bottlerocket/aws-ecs-1/x86_64/latest/image_version" \ @@ -107,7 +108,7 @@ in your account. To find your default VPC, run this command. (If you use an AWS region other than "us-west-2", make sure to change that.) -``` +```shell aws ec2 describe-vpcs \ --region us-west-2 \ --filters=Name=isDefault,Values=true \ @@ -118,7 +119,7 @@ If you want to use a different VPC you created, run this to get the ID for your Make sure to change VPC_NAME to the name of the VPC you created. (If you use an EC2 region other than "us-west-2", make sure to change that too.) -``` +```shell aws ec2 describe-vpcs \ --region us-west-2 \ --filters=Name=tag:Name,Values=VPC_NAME \ @@ -130,7 +131,7 @@ It will give you a list of the subnets and tell you whether each is public or pr Make sure to change VPC_ID to the value you received from the previous command. (If you use an EC2 region other than "us-west-2", make sure to change that too.) -``` +```shell aws ec2 describe-subnets \ --region us-west-2 \ --filter=Name=vpc-id,Values=VPC_ID \ @@ -170,7 +171,7 @@ If you add SSM permissions, you can use Bottlerocket's default SSM agent to get To attach the role policy for SSM permissions, run the following (replacing INSTANCE_ROLE_NAME with the name of your instance role): -``` +```shell aws iam attach-role-policy \ --role-name INSTANCE_ROLE_NAME \ --policy-arn arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore @@ -178,7 +179,7 @@ aws iam attach-role-policy \ Next, to retrieve the instance profile name used to launch instances, run this: -``` +```shell aws iam list-instance-profiles-for-role --role-name INSTANCE_ROLE_NAME --query "InstanceProfiles[*].InstanceProfileName" --output text ``` @@ -190,7 +191,7 @@ For the instance to be able to communicate with ECS, we need to make sure to con Create a file called `user-data.toml` with the following contents, where CLUSTER_NAME is the name of the cluster you created above (for example, "bottlerocket"). -``` +```toml [settings.ecs] cluster = "CLUSTER_NAME" ``` @@ -209,7 +210,7 @@ There are a few values to make sure you change in this command: * user-data.toml: the path to the user data file you created earlier * INSTANCE_PROFILE_NAME: the IAM instance profile you created, e.g. `ecsInstanceRole` -``` +```shell aws ec2 run-instances --key-name YOUR_KEY_NAME \ --subnet-id SUBNET_ID \ --image-id BOTTLEROCKET_AMI_ID \ diff --git a/QUICKSTART-EKS.md b/QUICKSTART-EKS.md index 7d98c4fb8e8..5b12eb1ea0f 100644 --- a/QUICKSTART-EKS.md +++ b/QUICKSTART-EKS.md @@ -44,7 +44,7 @@ To learn more about eksctl configuration files, you can look at the [full schema You can set up a new cluster like this, pointing to the file you created in the last step: -``` +```shell eksctl create cluster --config-file ./my-eksctl.yaml ``` @@ -63,13 +63,13 @@ A walk-through of creating a storage class using the driver is available [here]( By default `kube-proxy` will set the `nf_conntrack_max` kernel parameter to a default value that may differ from what Bottlerocket originally sets at boot. If you prefer to keep Bottlerocket's [default setting](packages/release/release-sysctl.conf), edit the kube-proxy configuration details with: -``` +```shell kubectl edit -n kube-system daemonset kube-proxy ``` Add `--conntrack-max-per-core` and `--conntrack-min` to the kube-proxy arguments like so (a setting of 0 implies no change): -``` +```yaml containers: - command: - kube-proxy @@ -147,12 +147,13 @@ For example, to use the parameter above, you would pass this as the AMI ID in yo If you prefer to fetch the AMI ID yourself, you can use [aws-cli](https://aws.amazon.com/cli/) on the command line. To fetch the example parameter above, for the us-west-2 region, you could run this: -``` +```shell aws ssm get-parameter --region us-west-2 --name "/aws/service/bottlerocket/aws-k8s-1.24/x86_64/latest/image_id" --query Parameter.Value --output text ``` -If you have `jq` and would like a bit more information, try this: -``` +If you have `jq` installed and would like a bit more information, try this: + +```shell aws ssm get-parameters --region us-west-2 \ --names "/aws/service/bottlerocket/aws-k8s-1.24/x86_64/latest/image_id" \ "/aws/service/bottlerocket/aws-k8s-1.24/x86_64/latest/image_version" \ @@ -161,16 +162,14 @@ aws ssm get-parameters --region us-west-2 \ ### Cluster setup -*Note:* most commands will have a region argument; make sure to change it if you don't want to set up in us-west-2. -Also be aware that when operating in GovCloud the IAM ARNs will need to be updated to the following: `arn:aws-us-gov`. -For example: - `arn:aws:iam::aws:policy/AmazonEKSWorkerNodePolicy` - will be updated to: - `arn:aws-us-gov:iam::aws:policy/AmazonEKSWorkerNodePolicy`. +*Note:* most commands will have a region argument; make sure to change it if you don't want to set up in us-west-2. +Also be aware that when operating in GovCloud the IAM ARNs will need to be updated to the following: `arn:aws-us-gov`. +For example, `arn:aws:iam::aws:policy/AmazonEKSWorkerNodePolicy` must be updated to +`arn:aws-us-gov:iam::aws:policy/AmazonEKSWorkerNodePolicy`. You can set up a new cluster like this: -``` +```shell eksctl create cluster --region us-west-2 --name bottlerocket ``` @@ -187,7 +186,8 @@ Bottlerocket uses a TOML-formatted configuration file as user data. This can include the configuration of the Kubernetes cluster we just created. Run this to generate the configuration file with the relevant cluster config, including the API endpoint and base64-encoded certificate authority. -``` + +```shell eksctl get cluster --region us-west-2 --name bottlerocket -o json \ | jq --raw-output '.[] | "[settings.kubernetes]\napi-server = \"" + .Endpoint + "\"\ncluster-certificate =\"" + .CertificateAuthority.Data + "\"\ncluster-name = \"bottlerocket\""' > user-data.toml ``` @@ -201,7 +201,7 @@ Next, run this to get information about the subnets that eksctl created. It will give you a list of the subnets and tell you whether each is public or private. (If you use an EC2 region other than "us-west-2", make sure to change that.) -``` +```shell aws ec2 describe-subnets \ --subnet-ids $(eksctl get cluster --region us-west-2 --name bottlerocket -o json | jq --raw-output '.[].ResourcesVpcConfig.SubnetIds[]') \ --region us-west-2 \ @@ -229,7 +229,7 @@ The instance we launch needs to be associated with an IAM role that allows for c The ARN of the IAM role can be retrieved with: -``` +```shell eksctl get iamidentitymapping --region us-west-2 --cluster bottlerocket ``` @@ -248,7 +248,7 @@ If you add SSM permissions, you can use Bottlerocket's default SSM agent to get To attach the role policy for SSM permissions, run the following: -``` +```shell aws iam attach-role-policy \ --role-name INSTANCE_ROLE_NAME \ --policy-arn arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore @@ -264,29 +264,30 @@ Member must have length less than or equal to 64 Next, to retrieve the instance profile name used to launch instances, run this: -``` +```shell aws iam list-instance-profiles-for-role --role-name INSTANCE_ROLE_NAME --query "InstanceProfiles[*].InstanceProfileName" --output text ``` There should only be one that looks like: + ``` eksctl-bottlerocket-nodegroup-ng-IDENTIFIER-NodeInstanceProfile-IDENTIFIER ``` -Note this down as the INSTANCE_PROFILE_NAME for the final launch command. +Note this down as the `INSTANCE_PROFILE_NAME` for the final launch command. ### kube-proxy settings By default `kube-proxy` will set the `nf_conntrack_max` kernel parameter to a default value that may differ from what Bottlerocket originally sets at boot. If you prefer to keep Bottlerocket's [default setting](packages/release/release-sysctl.conf), edit the kube-proxy configuration details with: -``` +```shell kubectl edit -n kube-system daemonset kube-proxy ``` Add `--conntrack-max-per-core` and `--conntrack-min` to the kube-proxy arguments like so (a setting of 0 implies no change): -``` +```yaml containers: - command: - kube-proxy @@ -303,7 +304,7 @@ For the instance to be able to communicate with the EKS cluster control plane an Run the following command: -``` +```shell aws ec2 describe-security-groups --region us-west-2 \ --filters 'Name=tag:Name,Values=*bottlerocket*' \ --query "SecurityGroups[*].{Name:GroupName,ID:GroupId}" @@ -314,7 +315,7 @@ You want to save the IDs for the `...ClusterSharedNodeSecurityGroup...` and `... Example: -``` +```json [ { "Name": "eksctl-bottlerocket-cluster-ClusterSharedNodeSecurityGroup-IDENTIFIER", @@ -333,7 +334,8 @@ Example: If you chose a public subnet, and you plan to SSH to the instance (using the admin container), you'll also need to allow SSH traffic to your security group. You can do that with a command like this - just make sure to insert a security group from the last command, and your source network CIDR. -``` + +```shell aws ec2 authorize-security-group-ingress --region us-west-2 \ --group-id SECURITY_GROUP_ID_1 --cidr YOUR_NETWORK_CIDR \ --protocol tcp --port 22 @@ -354,7 +356,7 @@ There are a few values to make sure you change in this command: * user-data.toml: the path to the user data file you created earlier * INSTANCE_PROFILE_NAME: the instance profile created by `eksctl` for the cluster nodegroups. -``` +```shell aws ec2 run-instances --key-name YOUR_KEY_NAME \ --subnet-id SUBNET_ID \ --security-group-ids SECURITY_GROUP_ID_1 SECURITY_GROUP_ID_2 \ diff --git a/QUICKSTART-LOCAL.md b/QUICKSTART-LOCAL.md index acbc19f3f55..b9e9c221507 100644 --- a/QUICKSTART-LOCAL.md +++ b/QUICKSTART-LOCAL.md @@ -16,7 +16,7 @@ Please refer to [`BUILDING.md`](https://github.com/bottlerocket-os/bottlerocket/ The use of QEMU requires extra packages which you may install using this dnf invocation: -``` +```shell sudo dnf install qemu ``` @@ -35,7 +35,7 @@ As an alternative, the `start-local-vm` wrapper script included in the `tools` d The `start-local-vm` wrapper configures QEMU to provide one virtual network interface to the VM. To enable this interface, create a file named `net.toml` containing the following TOML snippet: -``` +```toml version = 1 [enp0s16] @@ -64,7 +64,7 @@ If you would like to use the admin container, you will need to create some base6 Full details are covered in the [admin container documentation](https://github.com/bottlerocket-os/bottlerocket-admin-container#authenticating-with-the-admin-container). If we assume you have a public key at `${HOME}/.ssh/id_rsa.pub`, the below will add the correct user data to your `user-data.toml`. -``` +```shell PUBKEY_FILE="${HOME}/.ssh/id_rsa.pub" PUBKEY=$(< "${PUBKEY_FILE}") ADMIN_USER_DATA="$(echo '{"ssh": {"authorized-keys": ["'"${PUBKEY}"'"]}}' | base64 -w 0)" @@ -87,7 +87,7 @@ Full details can be found in the [control container documentation](https://githu You'll first need an AWS account, and AWS CLI installed. Then you'll create a service role in that account to [grant AWS STS trust to the AWS Systems Manager service](https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-service-role.html). -``` +```shell cat < ssmservice-trust.json { "Version": "2012-10-17", @@ -114,7 +114,7 @@ aws iam attach-role-policy \ Once the above is created, we can use the role to create an activation code and ID. -``` +```shell export SSM_ACTIVATION="$(aws ssm create-activation \ --iam-role SSMServiceRole \ --registration-limit 100 \ @@ -122,9 +122,9 @@ export SSM_ACTIVATION="$(aws ssm create-activation \ --output json)" ``` -Using the above activation data we can create our user data to pass to the control container +Using the above activation data we can create our user data to pass to the control container: -``` +```shell SSM_ACTIVATION_ID="$(jq -r '.ActivationId' <<< ${SSM_ACTIVATION})" SSM_ACTIVATION_CODE="$(jq -r '.ActivationCode' <<< ${SSM_ACTIVATION})" CONTROL_USER_DATA="$(echo '{"ssm": {"activation-id": "'${SSM_ACTIVATION_ID}'", "activation-code": "'${SSM_ACTIVATION_CODE}'", "region": "us-west-2"}}' | base64 -w0)" @@ -143,7 +143,7 @@ EOF We have now prepared all configuration we might need. Assuming you are in the root of the main Bottlerocket repository, you can run -``` +```shell ./tools/start-local-vm --variant metal-dev --arch $(uname -m) --inject-file net.toml --inject-file user-data.toml ``` @@ -164,6 +164,6 @@ If you want to terminate the VM, you can either instruct it to `systemctl powero By default, the `start-local-vm` wrapper will forward the host's TCP port 2222 to the VM's port 22. If you enabled the admin host container, the SSH server running in it will therefore be available by connecting to localhost's port 2222: -``` +```shell ssh -p 2222 ec2-user@localhost ``` diff --git a/QUICKSTART-VMWARE.md b/QUICKSTART-VMWARE.md index 59f5f94c03b..9831911d3d8 100644 --- a/QUICKSTART-VMWARE.md +++ b/QUICKSTART-VMWARE.md @@ -8,6 +8,7 @@ You must be able to access vSphere, via webUI or some type of client. We will use the CLI tool [`govc`](https://github.com/vmware/govmomi/tree/master/govc) to communicate with vSphere in this guide. `govc` can use [environment variables or take arguments](https://github.com/vmware/govmomi/tree/master/govc#usage) to specify needed parameters. For the purposes of this guide we will assume that the following environment variables are set to the proper values in your environment: + ``` GOVC_URL GOVC_USERNAME @@ -36,13 +37,14 @@ The Bottlerocket OVA is signed and uploaded alongside the rest of the Bottlerock You first need the Bottlerocket root role, which is used by `tuftool` to verify the OVA. The following will download and verify the root role itself: -``` +```shell curl -O "https://cache.bottlerocket.aws/root.json" sha512sum -c <<<"b81af4d8eb86743539fbc4709d33ada7b118d9f929f0c2f6c04e1d41f46241ed80423666d169079d736ab79965b4dd25a5a6db5f01578b397496d49ce11a3aa2 root.json" ``` Next, set your desired version and variant, and download the OVA: -``` + +```shell VERSION="v1.6.1" VARIANT="vmware-k8s-1.21" OVA="bottlerocket-${VARIANT}-x86_64-${VERSION}.ova" @@ -59,12 +61,14 @@ tuftool download "${OUTDIR}" --target-name "${OVA}" \ Once you have downloaded the OVA, you can upload it to vSphere. The first command generates a spec file (`bottlerocket_spec.json` in this case) using the OVA and gives you few options for your deployment. -``` + +```shell govc import.spec "${OUTDIR}/${OVA}" > bottlerocket_spec.json ``` The spec will look similar to this: -``` + +```json { "DiskProvisioning": "flat", "IPAllocationPolicy": "dhcpPolicy", @@ -84,7 +88,8 @@ The spec will look similar to this: ``` We will use `$GOVC_NETWORK` to populate the value for `Network` in the file and use it to upload the OVA! -``` + +```shell VM_NAME="bottlerocket-quickstart-${VERSION}" jq --arg network "${GOVC_NETWORK}" \ @@ -96,13 +101,15 @@ govc import.ova -options=bottlerocket_spec_edit.json -name="${VM_NAME}" "${OUTDI Since we intend to run multiple identical VMs, let's mark the OVA you just uploaded as a template. You can think of a template as a "golden" image, allowing you to create many VMs without affecting the "golden" image. -``` + +```shell govc vm.markastemplate "${VM_NAME}" ``` Let's create 3 Bottlerocket VMs using the template. The following will clone from the template, but leave the VMs turned off since we still need to set user data. -``` + +```shell for node in 1 2 3; do govc vm.clone -vm "${VM_NAME}" -on=false "${VM_NAME}-${node}" done @@ -115,26 +122,30 @@ The below commands assume a single cluster. #### API Server This is the address (including port) of the control plane. -``` + +```shell export API_SERVER="$(kubectl config view -o jsonpath='{.clusters[0].cluster.server}')" ``` #### Cluster DNS IP This is the IP address of the DNS pod/service. -``` + +```shell export CLUSTER_DNS_IP="$(kubectl -n kube-system get svc -l k8s-app=kube-dns -o=jsonpath='{.items[0].spec.clusterIP}')" ``` #### Bootstrap token Nodes require a token to establish trust between the node and the control plane. Tokens must be [used within 24 hours](https://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm-token/), but once the node has booted and registered with the cluster, it isn't used again. -``` + +```shell export BOOTSTRAP_TOKEN="$(kubeadm token create)" ``` #### Cluster Certificate This is the base64 encoded cluster certificate authority. -``` + +```shell export CLUSTER_CERTIFICATE="$(kubectl config view --raw -o=jsonpath='{.clusters[0].cluster.certificate-authority-data}')" ``` @@ -144,7 +155,8 @@ In order to join Bottlerocket to your cluster, it must be configured via user da There are multiple methods of passing user data to Bottlerocket in VMware; we will demonstrate all of them. Create a file called `user-data.toml` and populate it with the values you just retrieved. -``` + +```shell cat < user-data.toml [settings.kubernetes] api-server = "${API_SERVER}" @@ -164,7 +176,8 @@ You can use our [admin](https://github.com/bottlerocket-os/bottlerocket-admin-co If you would like to use the admin container, you will need to create some base64 encoded user data which will be passed to the container at runtime. Full details are covered in the [admin container documentation](https://github.com/bottlerocket-os/bottlerocket-admin-container#authenticating-with-the-admin-container). If we assume you have a public key at `${HOME}/.ssh/id_rsa.pub`, the below will add the correct user data to your `user-data.toml`. -``` + +```shell PUBKEY="${HOME}/.ssh/id_rsa.pub" ADMIN_USER_DATA="$(echo '{"ssh":{"authorized-keys":["'"$(cat ${PUBKEY})"'"]}}' | base64 -w 0)" @@ -182,7 +195,8 @@ Full details can be found in the [control container documentation](https://githu You'll first need an AWS account, and AWS CLI installed. Then you'll create a service role in that account to [grant AWS STS trust to the AWS Systems Manager service](https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-service-role.html). -``` + +```shell cat < ssmservice-trust.json { "Version": "2012-10-17", @@ -204,11 +218,12 @@ aws iam create-role \ # Attach the policy enabling the role to create session tokens aws iam attach-role-policy \ --role-name SSMServiceRole \ - --policy-arn arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore + --policy-arn arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore ``` Once the above is created, we can use the role to create an activation code and ID. -``` + +```shell export SSM_ACTIVATION="$(aws ssm create-activation \ --iam-role SSMServiceRole \ --registration-limit 100 \ @@ -216,8 +231,9 @@ export SSM_ACTIVATION="$(aws ssm create-activation \ --output json)" ``` -Using the above activation data we can create our user data to pass to the control container -``` +Using the above activation data we can create our user data to pass to the control container: + +```shell SSM_ACTIVATION_ID="$(jq -r '.ActivationId' <<< ${SSM_ACTIVATION})" SSM_ACTIVATION_CODE="$(jq -r '.ActivationCode' <<< ${SSM_ACTIVATION})" CONTROL_USER_DATA="$(echo '{"ssm":{"activation-id":"'${SSM_ACTIVATION_ID}'","activation-code":"'${SSM_ACTIVATION_CODE}'","region":"us-west-2"}}' | base64 -w0)" @@ -239,7 +255,7 @@ These extended attributes are `guestinfo.userdata` and `guestinfo.userdata.encod Valid values for `guestinfo.userdata.encoding` are: `base64`, `b64`, `gzip+base64`, and `gz+b64`. Given the above file `user-data.toml`, base64 encode and set user data for your VM: -``` +```shell export BR_USERDATA=$(base64 -w0 user-data.toml) for node in 1 2 3; do @@ -250,13 +266,13 @@ done ``` You can check that your user data was set; using node "1" as an example below: -``` +```shell govc vm.info -e -r -t "${VM_NAME}-1" ``` ## Launch! Once you've created your user data and given your VM a way to access it via guestinfo, you can launch all 3 Bottlerocket VMs in your cluster! -``` +```shell for node in 1 2 3; do govc vm.power -on "${VM_NAME}-${node}" done diff --git a/README.md b/README.md index c631d060f94..a1d3941df82 100644 --- a/README.md +++ b/README.md @@ -164,7 +164,7 @@ Once the instance is started, you can start a session: If you prefer a command-line tool, you can start a session with a recent [AWS CLI](https://aws.amazon.com/cli/) and the [session-manager-plugin](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager-working-with-install-plugin.html). Then you'd be able to start a session using only your instance ID, like this: -```txt +```shell aws ssm start-session --target INSTANCE_ID ``` @@ -172,7 +172,7 @@ With the [default control container](https://github.com/bottlerocket-os/bottlero To do even more, read the next section about the [admin container](#admin-container). You can access the admin container from the control container like this: -```sh +```shell enter-admin-container ``` @@ -192,25 +192,25 @@ enabled = true If Bottlerocket is already running, you can enable the admin container from the default [control container](#control-container) like this: -```sh +```shell enable-admin-container ``` Or you can start an interactive session immediately like this: -```sh +```shell enter-admin-container ``` If you're using a custom control container, or want to make the API calls directly, you can enable the admin container like this instead: -```txt +```shell apiclient set host-containers.admin.enabled=true ``` Once you've enabled the admin container, you can either access it through SSH or execute commands from the control container like this: -```txt +```shell apiclient exec admin bash ``` @@ -245,7 +245,7 @@ apiclient knows how to handle those update APIs for you, and you can run it from To see what updates are available: -```txt +```shell apiclient update check ``` @@ -254,20 +254,20 @@ The `available_updates` field will show the full list of available versions, inc To apply the latest update: -```txt +```shell apiclient update apply ``` The next time you reboot, you'll start up in the new version, and system configuration will be automatically [migrated](sources/api/migration/). To reboot right away: -```txt +```shell apiclient reboot ``` If you're confident about updating, the `apiclient update apply` command has `--check` and `--reboot` flags to combine the above actions, so you can accomplish all of the above steps like this: -```txt +```shell apiclient update apply --check --reboot ``` @@ -278,7 +278,7 @@ See the [apiclient documentation](sources/api/apiclient/) for more details. The system will automatically roll back if it's unable to boot. If the update is not functional for a given container workload, you can do a manual rollback: -```txt +```shell signpost rollback-to-inactive reboot ``` @@ -297,7 +297,7 @@ Here we'll describe the settings you can configure on your Bottlerocket instance You can see the current settings with an API request: -```txt +```shell apiclient get settings ``` @@ -310,7 +310,7 @@ For example, here's an abbreviated response: You can change settings like this: -```txt +```shell apiclient set motd="hi there" kubernetes.node-labels.environment=test ``` @@ -619,7 +619,7 @@ It is recommended to programmatically set these settings via `apiclient` through An example `apiclient` call to set registry credentials for `gcr.io` and `docker.io` looks like this: - ```bash + ```shell apiclient set --json '{ "container-registry": { "credentials": [ @@ -868,7 +868,7 @@ trusted=false Here's the same example but using API calls: -```txt +```shell apiclient set \ pki.my-trusted-bundle.data="W3N..." \ pki.my-trusted-bundle.trusted=true \ @@ -900,11 +900,11 @@ Keep in mind that the default admin container (since Bottlerocket v1.0.6) relies Here's an example of adding a custom host container with API calls: -```txt +```shell apiclient set \ - host-containers.custom.source=MY-CONTAINER-URI \ - host-containers.custom.enabled=true \ - host-containers.custom.superpowered=false + host-containers.custom.source=MY-CONTAINER-URI \ + host-containers.custom.enabled=true \ + host-containers.custom.superpowered=false ``` Here's the same example, but with the settings you'd add to user data: @@ -922,7 +922,7 @@ All host containers will have the `apiclient` binary available at `/usr/local/bi You can also use `apiclient` to run programs in other host containers. For example, to access the admin container: -```txt +```shell apiclient exec admin bash ``` @@ -970,11 +970,11 @@ Bootstrap containers have three different modes: Here's an example of adding a bootstrap container with API calls: -```txt +```shell apiclient set \ - bootstrap-containers.bootstrap.source=MY-CONTAINER-URI \ - bootstrap-containers.bootstrap.mode=once \ - bootstrap-containers.bootstrap.essential=true + bootstrap-containers.bootstrap.source=MY-CONTAINER-URI \ + bootstrap-containers.bootstrap.mode=once \ + bootstrap-containers.bootstrap.essential=true ``` Here's the same example, but with the settings you'd add to user data: @@ -1024,7 +1024,7 @@ They can be overridden for testing purposes in [the same way as other settings]( You can use `logdog` through the [admin container](#admin-container) to obtain an archive of log files from your Bottlerocket host. SSH to the Bottlerocket host or `apiclient exec admin bash` to access the admin container, then run: -```bash +```shell sudo sheltie logdog ``` @@ -1034,10 +1034,10 @@ This archive is accessible from host containers at `/.bottlerocket/support`. You can use SSH to retrieve the file. Once you have exited from the Bottlerocket host, run a command like: -```bash +```shell ssh -i YOUR_KEY_FILE \ - ec2-user@YOUR_HOST \ - "cat /.bottlerocket/support/bottlerocket-logs.tar.gz" > bottlerocket-logs.tar.gz + ec2-user@YOUR_HOST \ + "cat /.bottlerocket/support/bottlerocket-logs.tar.gz" > bottlerocket-logs.tar.gz ``` (If your instance isn't accessible through SSH, you can use [SSH over SSM](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager-getting-started-enable-ssh-connections.html).) diff --git a/ROADMAP.md b/ROADMAP.md index 970ef0b5d05..fd2088beb66 100644 --- a/ROADMAP.md +++ b/ROADMAP.md @@ -4,32 +4,31 @@ The Bottlerocket roadmap is public and hosted as a GitHub Project at the followi https://github.com/orgs/bottlerocket-os/projects/18 -GitHub Projects allows for multiple views that represent different ways of looking at the same data. +GitHub Projects allows for multiple views that represent different ways of looking at the same data. In the case of Bottlerocket, there are four views (represented as tabs): -* [All Items](https://github.com/orgs/bottlerocket-os/projects/18/views/1): a list of all the issues being actively worked on. +* [All Items](https://github.com/orgs/bottlerocket-os/projects/18/views/1): a list of all the issues being actively worked on. * [Upcoming Releases](https://github.com/orgs/bottlerocket-os/projects/18/views/2): the issues sorted into columns that represent an upcoming release. * [Feature Highlights](https://github.com/orgs/bottlerocket-os/projects/18/views/4): selected issues sorted into columns that represent particular features. -* [Themes](https://github.com/orgs/bottlerocket-os/projects/18/views/5): selected issues sorted into columns as they align to overarching thematic changes. +* [Themes](https://github.com/orgs/bottlerocket-os/projects/18/views/5): selected issues sorted into columns as they align to overarching thematic changes. ## What does the roadmap represent? -The roadmap is best understood as a point-in-time snapshot of what is being worked on and the intentions for upcoming releases. -Each item on the roadmap links back to a GitHub issue; issues represent a problem (i.e. a bug) or a change from the current functional state (i.e. an enhancement). +The roadmap is best understood as a point-in-time snapshot of what is being worked on and the intentions for upcoming releases. +Each item on the roadmap links back to a GitHub issue; issues represent a problem (i.e. a bug) or a change from the current functional state (i.e. an enhancement). -Both bug and enhancements can take a non-linear path to resolution. -The work to resolve these can take more or less effort than anticipated as paths are explored and complexity is thoughtfully considered. -Releases in Bottlerocket follow a loose release train model with each being spaced out about six weeks apart. +Both bug and enhancements can take a non-linear path to resolution. +The work to resolve these can take more or less effort than anticipated as paths are explored and complexity is thoughtfully considered. +Releases in Bottlerocket follow a loose release train model with each being spaced out about six weeks apart. So, roadmap items are continuously reconsidered and roadmap adjustments may be required. ## How do I follow a specific change to the roadmap? -For individual items, the best way to find out more information is to subscribe to notifications on GitHub for the specific issues linked in the roadmap. -This will give you insight into both the development and any large changes to how the issue gets packaged into a release. -Additionally, you can ask questions, provide feedback, and, hopefully, contribute. +For individual items, the best way to find out more information is to subscribe to notifications on GitHub for the specific issues linked in the roadmap. +This will give you insight into both the development and any large changes to how the issue gets packaged into a release. +Additionally, you can ask questions, provide feedback, and, hopefully, contribute. ## Can I see a log of all the changes to the roadmap? -This was supported in [GitHub Projects classic](https://docs.github.com/en/issues/organizing-your-work-with-project-boards/tracking-work-with-project-boards/tracking-progress-on-your-project-board) however, Bottlerocket uses the newer version of this GitHub feature which lacks this particular log-like view. +This was supported in [GitHub Projects classic](https://docs.github.com/en/issues/organizing-your-work-with-project-boards/tracking-work-with-project-boards/tracking-progress-on-your-project-board) however, Bottlerocket uses the newer version of this GitHub feature which lacks this particular log-like view. In the future, it would be great to see this feature return to GitHub Projects or similar functionality through the [Bottlerocket website](https://github.com/bottlerocket-os/project-website) initiative. - diff --git a/SECURITY_GUIDANCE.md b/SECURITY_GUIDANCE.md index ae0d7baf5c6..45be18a6d0b 100644 --- a/SECURITY_GUIDANCE.md +++ b/SECURITY_GUIDANCE.md @@ -250,7 +250,7 @@ We recommend that you do not run containers as UID 0. These settings can passed as [user data](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/user-data.html) on EC2 instance launch. They apply to any Bottlerocket variant. -``` +```toml # Enable kernel lockdown in "integrity" mode. # This prevents modifications to the running kernel, even by privileged users. [settings.kernel] @@ -273,7 +273,7 @@ enabled = false These settings can passed as [user data](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/user-data.html) on EC2 instance launch. They are specific to the `aws-ecs-1` variant. -``` +```toml # By default, this variant does not allow launching privileged containers. # The feature can also be disabled explicitly. [settings.ecs] @@ -285,7 +285,7 @@ allow-privileged-containers = false The following [Pod Security Policy](https://kubernetes.io/docs/concepts/policy/pod-security-policy/) is based on our recommendations. It can be used as a starting point for your own policy. -``` +```yaml --- apiVersion: policy/v1beta1 kind: PodSecurityPolicy diff --git a/TESTING.md b/TESTING.md index 2b03cdf24b8..fc6458be606 100644 --- a/TESTING.md +++ b/TESTING.md @@ -67,7 +67,7 @@ kind create cluster --name testsys If you want to store the kubeconfig file, set the `KUBECONFIG` variable to some path (there should be no pre-existing file there). It doesn't really matter where this is, since this is a throwaway cluster and then write the -kubeconfig to that path. +kubeconfig to that path. The environment variable `TESTSYS_KUBECONFIG` is used by all testsys related cargo make tasks. @@ -111,7 +111,7 @@ export TESTSYS_AWS_SECRET_NAME="awsCredentials=" ### Conveniences All testsys commands can be run using cargo make to eliminate the chance of 2 different versions of -testsys bing used. +testsys being used. Testsys requires the controller and the agent images to be of the same testsys version. ```shell @@ -131,7 +131,7 @@ Check out the [example config file](tools/testsys/Test.toml.example) for a sampl For example, the instance type can be specified based on variant requirements: -```yaml +```toml [aws-k8s] # Set the default instance type for all `aws-k8s` variants instance-type = "m5.xlarge" @@ -181,13 +181,13 @@ cargo make \ -e BUILDSYS_VARIANT="aws-k8s-1.21" \ -e BUILDSYS_ARCH="x86_64" \ build - + cargo make \ -e BUILDSYS_VARIANT="aws-k8s-1.21" \ -e BUILDSYS_ARCH="x86_64" \ -e PUBLISH_REGIONS="us-west-2" ami - + cargo make \ -e BUILDSYS_VARIANT="aws-k8s-1.21" \ -e BUILDSYS_ARCH="x86_64" \ @@ -200,7 +200,7 @@ cargo make watch-test ### aws-ecs -You need to [build](BUILDING.md) Bottlerocket and create an AMI before you can run a test. +You need to [build](BUILDING.md) Bottlerocket and create an AMI before you can run a test. The default instance type to be used is `m5.large` for `x86_64` and `m6g.large` for `aarch64`, but can be controlled by setting the environment variable `TESTSYS_INSTANCE_TYPE`. This is useful while testing NVIDIA variants, since they require instance types with support for NVIDIA GPUs. Change the commands below to the desired `aws-ecs` variant and AWS region: @@ -210,13 +210,13 @@ cargo make \ -e BUILDSYS_VARIANT="aws-ecs-1" \ -e BUILDSYS_ARCH="x86_64" \ build - + cargo make \ -e BUILDSYS_VARIANT="aws-ecs-1" \ -e BUILDSYS_ARCH="x86_64" \ -e PUBLISH_REGIONS="us-west-2" ami - + cargo make \ -e BUILDSYS_VARIANT="aws-ecs-1" \ -e BUILDSYS_ARCH="x86_64" \ @@ -245,14 +245,14 @@ In order to accomplish this a few artifacts need to be created: #### Prepare `Infra.toml` -We need the URL of an accessible TUF repo so the Bottlerocket instances know where to retrieve the update metadata and targets. +We need the URL of an accessible TUF repo so the Bottlerocket instances know where to retrieve the update metadata and targets. Follow our [publishing guide](PUBLISHING.md#repo-location) to set up TUF repos. -`Infra.toml` is used by testsys to determine TUF repo locations, so `metadata_base_url` and `targets_base_url` need to be set based on the repo that was just created. +`Infra.toml` is used by testsys to determine TUF repo locations, so `metadata_base_url` and `targets_base_url` need to be set based on the repo that was just created. The examples below also assume that the default repo is being used in `Infra.toml`, but any repo can be used by setting the `PUBLISH_REPO` environment variable. #### Starting Bottlerocket images -In this example we will use `v1.9.0` as our starting Bottlerocket version, but any tag from Bottlerocket will work. +In this example we will use `v1.9.0` as our starting Bottlerocket version, but any tag from Bottlerocket will work. The following bash script will checkout the proper branch from git and create the build images and TUF repos for testing. ```shell @@ -275,7 +275,7 @@ WORKING_BRANCH="develop" git checkout "${WORKING_BRANCH}" ``` -Next, build Bottlerocket images and repos and sync TUF repos. +Next, build Bottlerocket images and repos and sync TUF repos. The architecture and variant can be configured with `BUILDSYS_ARCH` and `BUILDSYS_VARIANT`. ```shell @@ -293,8 +293,8 @@ This completes the setup and it is time to test migrations! The previous steps set up the artifacts necessary to perform migration testing using `testsys`. Ensure all environment variables are still set and set them if they aren't. -To run the migration test set `TESTSYS_TEST=migration` in the `cargo make test` call. -This will automatically determine the AMI that should be used by finding the latest released version of bottlerocket and checking the user's AMIs to find the correct starting AMI ID. +To run the migration test set `TESTSYS_TEST=migration` in the `cargo make test` call. +This will automatically determine the AMI that should be used by finding the latest released version of bottlerocket and checking the user's AMIs to find the correct starting AMI ID. Remember to set the environment variables for the architecture and variant. ```shell diff --git a/packages/README.md b/packages/README.md index 8014c53a370..f4826c27ace 100644 --- a/packages/README.md +++ b/packages/README.md @@ -70,7 +70,7 @@ Finally, it includes a `spec` file that defines the RPM. Our sample package has the following manifest. -``` +```toml [package] name = "libwoof" version = "0.1.0" @@ -139,7 +139,7 @@ We want those libraries to be built first, and for this one to be rebuilt when t We use the same build script for all packages. -``` +```rust use std::process::{exit, Command}; fn main() -> Result<(), std::io::Error> { @@ -158,7 +158,7 @@ The `package.metadata` table can be extended with declarative elements that enab We use the same Rust code for all packages. -``` +```rust // not used ``` @@ -217,7 +217,7 @@ The definitions for most of these can be found in [macros](../macros). The definition for `%{_cross_variant}` is the Bottlerocket variant being built. When developing a package on an RPM-based system, you can expand the macros with a command like this. -``` +```shell $ PKG=libwoof $ rpmspec \ --macros "/usr/lib/rpm/macros:macros/$(uname -m):macros/shared:macros/rust:macros/cargo" \ @@ -230,12 +230,12 @@ $ rpmspec \ The variants workspace's `Cargo.lock` may be affected by adding a package. 1. `cd` into the `variants` directory at the root of the repository. -2. Include the new package inside the `Cargo.toml` file of the variant you want to modify. +2. Include the new package inside the `Cargo.toml` file of the variant you want to modify. 3. Run `cargo generate-lockfile` to refresh `Cargo.lock`. To build your package, run the following command in the top-level Bottlerocket directory. -```sh +```shell cargo make -e PACKAGE=libwoof build-package ``` diff --git a/packages/docker-cli/clarify.toml b/packages/docker-cli/clarify.toml index 668d65bff8e..841e006c6ce 100644 --- a/packages/docker-cli/clarify.toml +++ b/packages/docker-cli/clarify.toml @@ -9,4 +9,4 @@ skip-files = ["license.go", "model/license.go"] expression = "MIT AND BSD-3-Clause" license-files = [ { path = "LICENSE", hash = 0xcdf3ae00}, -] \ No newline at end of file +] diff --git a/packages/ecs-agent/pkg.rs b/packages/ecs-agent/pkg.rs index a711fc02eee..d799fb2d44c 100644 --- a/packages/ecs-agent/pkg.rs +++ b/packages/ecs-agent/pkg.rs @@ -1 +1 @@ -// not used \ No newline at end of file +// not used diff --git a/packages/kubernetes-1.24/etc-kubernetes-pki.mount b/packages/kubernetes-1.24/etc-kubernetes-pki.mount index 38c482deb44..aad5fb37d05 100644 --- a/packages/kubernetes-1.24/etc-kubernetes-pki.mount +++ b/packages/kubernetes-1.24/etc-kubernetes-pki.mount @@ -13,4 +13,4 @@ Type=tmpfs Options=nosuid,nodev,noexec,noatime,context=system_u:object_r:secret_t:s0,mode=0700 [Install] -WantedBy=preconfigured.target \ No newline at end of file +WantedBy=preconfigured.target diff --git a/sources/api/README.md b/sources/api/README.md index c49e2e20ef1..77cd9c1ac01 100644 --- a/sources/api/README.md +++ b/sources/api/README.md @@ -142,14 +142,14 @@ These commands create one in `/tmp`, but you can create it in a more permanent l From the `sources/api/storewolf` directory: -``` +```shell cargo run -- --data-store-base-path /tmp/data-store --version 0.0.1 ``` Now you can start the API server. From the `sources/api/apiserver` directory: -``` +```shell cargo run -- --datastore-path /tmp/data-store/current --socket-path /tmp/bottlerocket-api.sock --log-level debug ``` @@ -161,7 +161,7 @@ This is so we can commit all settings generated at startup at once. We can use settings-committer to do the same thing with our development data store. From the `sources/api/settings-committer` directory: -``` +```shell cargo run -- --socket-path /tmp/bottlerocket-api.sock ``` @@ -178,7 +178,7 @@ Here's how you can test the feature locally. Follow the [setup steps above](#Setup) if you haven't already, then stop the apiserver, because we'll need to run it a different way. First, run a task in containerd locally. Here's an example: -``` +```shell sudo ctr i pull public.ecr.aws/amazonlinux/amazonlinux:latest sudo ctr run --rm -t public.ecr.aws/amazonlinux/amazonlinux:latest al bash ``` @@ -187,7 +187,7 @@ If you use a containerd socket other than the default `/run/containerd/container Next, run apiserver as root so it can talk to containerd. From the `sources` directory: -``` +```shell sudo target/debug/apiserver --datastore-path /tmp/data-store/current --socket-path /tmp/bottlerocket-api.sock ``` @@ -195,6 +195,6 @@ If you use a containerd socket other than the default `/run/containerd/container Finally, use apiclient to start another program in your container task. From the `sources/api/apiclient` directory: -``` +```shell cargo run -- --socket-path /tmp/bottlerocket-api.sock exec al bash ``` diff --git a/sources/api/apiclient/README.md b/sources/api/apiclient/README.md index 34b5683606a..d6a034f8e11 100644 --- a/sources/api/apiclient/README.md +++ b/sources/api/apiclient/README.md @@ -13,17 +13,17 @@ It can be pointed to another socket using `--socket-path`, for example for local The most important use is probably checking your current settings: -``` +```shell apiclient get settings ``` `get` will request all settings whose names start with the given prefix, so you can drill down into specific areas of interest: -``` +```shell apiclient get settings.host-containers.admin ``` Or, request some specific settings: -``` +```shell apiclient get settings.motd settings.kernel.lockdown ``` @@ -39,20 +39,20 @@ For example, if you change an NTP setting, the NTP configuration will be updated There are two input methods. The simpler method looks like this: -``` +```shell apiclient set settings.x.y.z=VALUE ``` The "settings." prefix on the setting names is optional; this makes it easy to copy and paste settings from documentation, but you can skip the prefix when typing them manually. Here's an example call: -``` +```shell apiclient set kernel.lockdown=integrity motd="hi there" ``` If you're changing a setting whose name requires quoting, please quote the whole key=value argument, so the inner quotes aren't eaten by the shell: -``` +```shell apiclient set 'kubernetes.node-labels."my.label"=hello' ``` @@ -61,7 +61,7 @@ apiclient set 'kubernetes.node-labels."my.label"=hello' This simpler key=value form is convenient for most changes, but sometimes you'll want to specify input in JSON form. This can be useful if you have multiple changes within a subsection: -``` +```shell apiclient set --json '{"kernel": {"sysctl": {"vm.max_map_count": "262144", "user.max_user_namespaces": "16384"}}}' ``` @@ -71,7 +71,7 @@ For example, the "vm.max_map_count" value set above looks like an integer, but t As another example, if you want settings.motd to be "42", running `apiclient set motd=42` would fail because `42` is seen as an integer, and motd is a string. You can use JSON form to set it: -``` +```shell apiclient set --json '{"motd": "42"}' ``` @@ -79,7 +79,7 @@ apiclient set --json '{"motd": "42"}' To start, you can check what updates are available: -``` +```shell apiclient update check ``` @@ -87,7 +87,7 @@ This will show you the current state of the system along with any updates availa Assuming you want to accept the chosen update, you can apply it: -``` +```shell apiclient update apply ``` @@ -96,7 +96,7 @@ The next time you reboot, for example with `apiclient reboot`, the update will t If you're confident that you want to update immediately to the latest version, you can do all of the above in one step: -``` +```shell apiclient update apply --check --reboot ``` @@ -107,7 +107,7 @@ apiclient update apply --check --reboot This will reboot the system. You should use this after updating if you didn't specify the `--reboot` flag. -``` +```shell apiclient reboot ``` @@ -120,12 +120,12 @@ You can think of it like a slim `ssh` that reuses the communication channel and Just tell it the container to run in and the command you want to run. For example, if you used SSM to get into the control container and want to access the admin container: -``` +```shell apiclient exec admin bash ``` You can also run noninteractive commands, and redirect output, so you can use it to copy files between containers: -``` +```shell apiclient exec admin cat /file > file ``` @@ -153,30 +153,30 @@ To see verbose response data, including the HTTP status code, use `-v` or `--ver To fetch the current settings: -``` +```shell apiclient raw -u /settings ``` This will return all of the current settings in JSON format. For example, here's an abbreviated response: -``` +```text {"motd":"...", {"kubernetes": ...}} ``` You can change settings by sending back the same type of JSON data in a PATCH request. This can include any number of settings changes. -``` +```shell apiclient raw -m PATCH -u /settings -d '{"motd": "my own value!"}' ``` This will *stage* the setting in a "pending" area - a transaction. You can see all your pending settings like this: -``` +```shell apiclient raw -u /tx ``` To *commit* the settings, and let the system apply them to any relevant configuration files or services, do this: -``` +```shell apiclient raw -m POST -u /tx/commit_and_apply ``` @@ -204,4 +204,4 @@ HTTP method, and any request body data. ## Colophon -This text was generated from `README.tpl` using [cargo-readme](https://crates.io/crates/cargo-readme), and includes the rustdoc from `src/lib.rs`. \ No newline at end of file +This text was generated from `README.tpl` using [cargo-readme](https://crates.io/crates/cargo-readme), and includes the rustdoc from `src/lib.rs`. diff --git a/sources/api/apiclient/README.tpl b/sources/api/apiclient/README.tpl index f3aac066426..55c12695481 100644 --- a/sources/api/apiclient/README.tpl +++ b/sources/api/apiclient/README.tpl @@ -13,17 +13,17 @@ It can be pointed to another socket using `--socket-path`, for example for local The most important use is probably checking your current settings: -``` +```shell apiclient get settings ``` `get` will request all settings whose names start with the given prefix, so you can drill down into specific areas of interest: -``` +```shell apiclient get settings.host-containers.admin ``` Or, request some specific settings: -``` +```shell apiclient get settings.motd settings.kernel.lockdown ``` @@ -39,20 +39,20 @@ For example, if you change an NTP setting, the NTP configuration will be updated There are two input methods. The simpler method looks like this: -``` +```shell apiclient set settings.x.y.z=VALUE ``` The "settings." prefix on the setting names is optional; this makes it easy to copy and paste settings from documentation, but you can skip the prefix when typing them manually. Here's an example call: -``` +```shell apiclient set kernel.lockdown=integrity motd="hi there" ``` If you're changing a setting whose name requires quoting, please quote the whole key=value argument, so the inner quotes aren't eaten by the shell: -``` +```shell apiclient set 'kubernetes.node-labels."my.label"=hello' ``` @@ -61,7 +61,7 @@ apiclient set 'kubernetes.node-labels."my.label"=hello' This simpler key=value form is convenient for most changes, but sometimes you'll want to specify input in JSON form. This can be useful if you have multiple changes within a subsection: -``` +```shell apiclient set --json '{"kernel": {"sysctl": {"vm.max_map_count": "262144", "user.max_user_namespaces": "16384"}}}' ``` @@ -71,7 +71,7 @@ For example, the "vm.max_map_count" value set above looks like an integer, but t As another example, if you want settings.motd to be "42", running `apiclient set motd=42` would fail because `42` is seen as an integer, and motd is a string. You can use JSON form to set it: -``` +```shell apiclient set --json '{"motd": "42"}' ``` @@ -79,7 +79,7 @@ apiclient set --json '{"motd": "42"}' To start, you can check what updates are available: -``` +```shell apiclient update check ``` @@ -87,7 +87,7 @@ This will show you the current state of the system along with any updates availa Assuming you want to accept the chosen update, you can apply it: -``` +```shell apiclient update apply ``` @@ -96,7 +96,7 @@ The next time you reboot, for example with `apiclient reboot`, the update will t If you're confident that you want to update immediately to the latest version, you can do all of the above in one step: -``` +```shell apiclient update apply --check --reboot ``` @@ -107,7 +107,7 @@ apiclient update apply --check --reboot This will reboot the system. You should use this after updating if you didn't specify the `--reboot` flag. -``` +```shell apiclient reboot ``` @@ -120,12 +120,12 @@ You can think of it like a slim `ssh` that reuses the communication channel and Just tell it the container to run in and the command you want to run. For example, if you used SSM to get into the control container and want to access the admin container: -``` +```shell apiclient exec admin bash ``` You can also run noninteractive commands, and redirect output, so you can use it to copy files between containers: -``` +```shell apiclient exec admin cat /file > file ``` @@ -153,30 +153,30 @@ To see verbose response data, including the HTTP status code, use `-v` or `--ver To fetch the current settings: -``` +```shell apiclient raw -u /settings ``` This will return all of the current settings in JSON format. For example, here's an abbreviated response: -``` +```text {"motd":"...", {"kubernetes": ...}} ``` You can change settings by sending back the same type of JSON data in a PATCH request. This can include any number of settings changes. -``` +```shell apiclient raw -m PATCH -u /settings -d '{"motd": "my own value!"}' ``` This will *stage* the setting in a "pending" area - a transaction. You can see all your pending settings like this: -``` +```shell apiclient raw -u /tx ``` To *commit* the settings, and let the system apply them to any relevant configuration files or services, do this: -``` +```shell apiclient raw -m POST -u /tx/commit_and_apply ``` diff --git a/sources/api/apiserver/README.md b/sources/api/apiserver/README.md index d8446a02471..956d537b95b 100644 --- a/sources/api/apiserver/README.md +++ b/sources/api/apiserver/README.md @@ -74,4 +74,4 @@ See `../../apiclient/README.md` for client examples. ## Colophon -This text was generated using [cargo-readme](https://crates.io/crates/cargo-readme), and includes the rustdoc from `src/lib.rs`. \ No newline at end of file +This text was generated using [cargo-readme](https://crates.io/crates/cargo-readme), and includes the rustdoc from `src/lib.rs`. diff --git a/sources/api/bootstrap-containers/README.md b/sources/api/bootstrap-containers/README.md index 7905a400e5d..4361e28765a 100644 --- a/sources/api/bootstrap-containers/README.md +++ b/sources/api/bootstrap-containers/README.md @@ -37,7 +37,7 @@ ENTRYPOINT ["sh", "bootstrap-script"] And `bootstrap-script` as: -```sh +```shell #!/usr/bin/env sh # We'll read some data to be written out from given user-data. USER_DATA_DIR=/.bottlerocket/bootstrap-containers/current @@ -68,10 +68,10 @@ You should see a new directory under `/var/lib` called `my_directory`, a file in directory called `bear.txt` and the following command should show `ʕ·͡ᴥ·ʔ` in the bootstrap containers logs: -```sh +```shell journalctl -u bootstrap-containers@bear.service ``` ## Colophon -This text was generated using [cargo-readme](https://crates.io/crates/cargo-readme), and includes the rustdoc from `src/main.rs`. \ No newline at end of file +This text was generated using [cargo-readme](https://crates.io/crates/cargo-readme), and includes the rustdoc from `src/main.rs`. diff --git a/sources/api/bootstrap-containers/src/main.rs b/sources/api/bootstrap-containers/src/main.rs index ca8a272c5f4..e8863c568b4 100644 --- a/sources/api/bootstrap-containers/src/main.rs +++ b/sources/api/bootstrap-containers/src/main.rs @@ -34,7 +34,7 @@ ENTRYPOINT ["sh", "bootstrap-script"] And `bootstrap-script` as: -```sh +```shell #!/usr/bin/env sh # We'll read some data to be written out from given user-data. USER_DATA_DIR=/.bottlerocket/bootstrap-containers/current @@ -65,7 +65,7 @@ You should see a new directory under `/var/lib` called `my_directory`, a file in directory called `bear.txt` and the following command should show `ʕ·͡ᴥ·ʔ` in the bootstrap containers logs: -```sh +```shell journalctl -u bootstrap-containers@bear.service ``` */ diff --git a/sources/api/bork/src/README.md b/sources/api/bork/src/README.md index 67000481a55..e1c31a90947 100644 --- a/sources/api/bork/src/README.md +++ b/sources/api/bork/src/README.md @@ -1,9 +1,9 @@ # bork -``` +```shell - <(rng.gen_range(0, 2048))> `---^- / | | ``` -Bork generates the random seed that Updog requires to interpret update metadata. \ No newline at end of file +Bork generates the random seed that Updog requires to interpret update metadata. diff --git a/sources/api/certdog/README.md b/sources/api/certdog/README.md index 8769328a9cf..e87b8418e09 100644 --- a/sources/api/certdog/README.md +++ b/sources/api/certdog/README.md @@ -8,4 +8,4 @@ Current version: 0.1.0 ## Colophon -This text was generated using [cargo-readme](https://crates.io/crates/cargo-readme), and includes the rustdoc from `src/main.rs`. \ No newline at end of file +This text was generated using [cargo-readme](https://crates.io/crates/cargo-readme), and includes the rustdoc from `src/main.rs`. diff --git a/sources/api/corndog/README.md b/sources/api/corndog/README.md index f5a52601673..418aa728189 100644 --- a/sources/api/corndog/README.md +++ b/sources/api/corndog/README.md @@ -9,4 +9,4 @@ It sets kernel-related settings, for example: ## Colophon -This text was generated from `README.tpl` using [cargo-readme](https://crates.io/crates/cargo-readme), and includes the rustdoc from `src/main.rs`. \ No newline at end of file +This text was generated from `README.tpl` using [cargo-readme](https://crates.io/crates/cargo-readme), and includes the rustdoc from `src/main.rs`. diff --git a/sources/api/datastore/README.md b/sources/api/datastore/README.md index 96453cfb35d..01a4c677908 100644 --- a/sources/api/datastore/README.md +++ b/sources/api/datastore/README.md @@ -31,4 +31,4 @@ The `deserialization` module provides code to deserialize datastore-acceptable k ## Colophon -This text was generated using [cargo-readme](https://crates.io/crates/cargo-readme), and includes the rustdoc from `src/lib.rs`. \ No newline at end of file +This text was generated using [cargo-readme](https://crates.io/crates/cargo-readme), and includes the rustdoc from `src/lib.rs`. diff --git a/sources/api/early-boot-config/README.md b/sources/api/early-boot-config/README.md index 65c977102af..ff36da7ce26 100644 --- a/sources/api/early-boot-config/README.md +++ b/sources/api/early-boot-config/README.md @@ -14,4 +14,4 @@ Currently, Amazon EC2 is supported through the IMDSv1 HTTP API. Data will be ta ## Colophon -This text was generated using [cargo-readme](https://crates.io/crates/cargo-readme), and includes the rustdoc from `src/main.rs`. \ No newline at end of file +This text was generated using [cargo-readme](https://crates.io/crates/cargo-readme), and includes the rustdoc from `src/main.rs`. diff --git a/sources/api/ecs-settings-applier/README.md b/sources/api/ecs-settings-applier/README.md index 7c936ece720..0ede9c91b2e 100644 --- a/sources/api/ecs-settings-applier/README.md +++ b/sources/api/ecs-settings-applier/README.md @@ -12,4 +12,4 @@ embedded lists. The structure and names of fields in the document can be found ## Colophon -This text was generated using from `README.tpl` [cargo-readme](https://crates.io/crates/cargo-readme), and includes the rustdoc from `src/main.rs`. \ No newline at end of file +This text was generated using from `README.tpl` [cargo-readme](https://crates.io/crates/cargo-readme), and includes the rustdoc from `src/main.rs`. diff --git a/sources/api/host-containers/README.md b/sources/api/host-containers/README.md index 0c30466d76c..1575be374b3 100644 --- a/sources/api/host-containers/README.md +++ b/sources/api/host-containers/README.md @@ -15,4 +15,4 @@ It queries the API for their settings, then configures the system by: ## Colophon -This text was generated using [cargo-readme](https://crates.io/crates/cargo-readme), and includes the rustdoc from `src/main.rs`. \ No newline at end of file +This text was generated using [cargo-readme](https://crates.io/crates/cargo-readme), and includes the rustdoc from `src/main.rs`. diff --git a/sources/api/migration/README.md b/sources/api/migration/README.md index 2b4f5b42024..dbe4cc6b4f2 100644 --- a/sources/api/migration/README.md +++ b/sources/api/migration/README.md @@ -55,7 +55,7 @@ Applications access the data store at `/var/lib/bottlerocket/datastore/current` `current` is a link to the major version, which is a link to the minor version, etc. Here's a full example setup for version 1.5: -``` +```shell /var/lib/bottlerocket/datastore/current -> v1 -> v1.5 @@ -193,4 +193,4 @@ If so, and we want to maintain user settings through the transition, we need to ### Migrations -The migration system could deserialize the function outputs into the incoming model types to confirm that the structure is valid; we should prototype this idea because it would add safety. \ No newline at end of file +The migration system could deserialize the function outputs into the incoming model types to confirm that the structure is valid; we should prototype this idea because it would add safety. diff --git a/sources/api/migration/migrator/README.md b/sources/api/migration/migrator/README.md index 1e1e8e9a6e6..72b70732952 100644 --- a/sources/api/migration/migrator/README.md +++ b/sources/api/migration/migrator/README.md @@ -24,4 +24,4 @@ documentation, one level up. ## Colophon -This text was generated from `README.tpl` using [cargo-readme](https://crates.io/crates/cargo-readme), and includes the rustdoc from `src/main.rs`. \ No newline at end of file +This text was generated from `README.tpl` using [cargo-readme](https://crates.io/crates/cargo-readme), and includes the rustdoc from `src/main.rs`. diff --git a/sources/api/netdog/README.md b/sources/api/netdog/README.md index df7059a0bc1..9d59f2f4fed 100644 --- a/sources/api/netdog/README.md +++ b/sources/api/netdog/README.md @@ -33,4 +33,4 @@ is meant to be used as a restart command for DNS API settings. ## Colophon -This text was generated using [cargo-readme](https://crates.io/crates/cargo-readme), and includes the rustdoc from `src/main.rs`. \ No newline at end of file +This text was generated using [cargo-readme](https://crates.io/crates/cargo-readme), and includes the rustdoc from `src/main.rs`. diff --git a/sources/api/pluto/README.md b/sources/api/pluto/README.md index 80422aca938..e88dac22fac 100644 --- a/sources/api/pluto/README.md +++ b/sources/api/pluto/README.md @@ -33,6 +33,6 @@ Pluto returns a special exit code of 2 to inform `sundog` that a setting should example, if `max-pods` cannot be generated, we want `sundog` to skip it without failing since a reasonable default is available. -## Colophon +## Colophon -This text was generated using [cargo-readme](https://crates.io/crates/cargo-readme), and includes the rustdoc from `src/main.rs`. \ No newline at end of file +This text was generated using [cargo-readme](https://crates.io/crates/cargo-readme), and includes the rustdoc from `src/main.rs`. diff --git a/sources/api/pluto/README.tpl b/sources/api/pluto/README.tpl index c362c047916..bf207d023ff 100644 --- a/sources/api/pluto/README.tpl +++ b/sources/api/pluto/README.tpl @@ -4,6 +4,6 @@ Current version: {{version}} {{readme}} -## Colophon +## Colophon This text was generated using [cargo-readme](https://crates.io/crates/cargo-readme), and includes the rustdoc from `src/main.rs`. diff --git a/sources/api/prairiedog/README.md b/sources/api/prairiedog/README.md index af599c5ad20..55c075b2a65 100644 --- a/sources/api/prairiedog/README.md +++ b/sources/api/prairiedog/README.md @@ -14,4 +14,4 @@ It does the following: ## Colophon -This text was generated from `README.tpl` using [cargo-readme](https://crates.io/crates/cargo-readme), and includes the rustdoc from `src/main.rs`. \ No newline at end of file +This text was generated from `README.tpl` using [cargo-readme](https://crates.io/crates/cargo-readme), and includes the rustdoc from `src/main.rs`. diff --git a/sources/api/schnauzer/README.md b/sources/api/schnauzer/README.md index 4a0006a0e0c..b8090d7cecd 100644 --- a/sources/api/schnauzer/README.md +++ b/sources/api/schnauzer/README.md @@ -17,4 +17,4 @@ If the returned value is "baz", our generated value will be "foo-baz". ## Colophon -This text was generated from `README.tpl` using [cargo-readme](https://crates.io/crates/cargo-readme), and includes the rustdoc from `src/main.rs`. \ No newline at end of file +This text was generated from `README.tpl` using [cargo-readme](https://crates.io/crates/cargo-readme), and includes the rustdoc from `src/main.rs`. diff --git a/sources/api/settings-committer/README.md b/sources/api/settings-committer/README.md index 677816f6c31..d2f4f22fa40 100644 --- a/sources/api/settings-committer/README.md +++ b/sources/api/settings-committer/README.md @@ -13,4 +13,4 @@ The `--transaction` argument can be used to specify another transaction. ## Colophon -This text was generated using [cargo-readme](https://crates.io/crates/cargo-readme), and includes the rustdoc from `src/main.rs`. \ No newline at end of file +This text was generated using [cargo-readme](https://crates.io/crates/cargo-readme), and includes the rustdoc from `src/main.rs`. diff --git a/sources/api/shibaken/README.md b/sources/api/shibaken/README.md index de5c3aa10f5..2ee7189a91d 100644 --- a/sources/api/shibaken/README.md +++ b/sources/api/shibaken/README.md @@ -16,4 +16,4 @@ shibaken can: ## Colophon -This text was generated from `README.tpl` using [cargo-readme](https://crates.io/crates/cargo-readme), and includes the rustdoc from `src/main.rs`. \ No newline at end of file +This text was generated from `README.tpl` using [cargo-readme](https://crates.io/crates/cargo-readme), and includes the rustdoc from `src/main.rs`. diff --git a/sources/api/static-pods/README.md b/sources/api/static-pods/README.md index c365f518b9b..a61dc4fbd33 100644 --- a/sources/api/static-pods/README.md +++ b/sources/api/static-pods/README.md @@ -15,4 +15,4 @@ It queries for all existing static pod settings, then configures the system as f ## Colophon -This text was generated using [cargo-readme](https://crates.io/crates/cargo-readme), and includes the rustdoc from `src/static_pods.rs`. \ No newline at end of file +This text was generated using [cargo-readme](https://crates.io/crates/cargo-readme), and includes the rustdoc from `src/static_pods.rs`. diff --git a/sources/api/storewolf/README.md b/sources/api/storewolf/README.md index d22e779f7ef..9da93a4efde 100644 --- a/sources/api/storewolf/README.md +++ b/sources/api/storewolf/README.md @@ -11,4 +11,4 @@ TOML files of the current variant's `defaults.d` directory, unless the datastore ## Colophon -This text was generated using [cargo-readme](https://crates.io/crates/cargo-readme), and includes the rustdoc from `src/main.rs`. \ No newline at end of file +This text was generated using [cargo-readme](https://crates.io/crates/cargo-readme), and includes the rustdoc from `src/main.rs`. diff --git a/sources/api/sundog/README.md b/sources/api/sundog/README.md index 54b08f7c059..e782252a4c5 100644 --- a/sources/api/sundog/README.md +++ b/sources/api/sundog/README.md @@ -11,4 +11,4 @@ The output is collected and sent to a known Bottlerocket API server endpoint. ## Colophon -This text was generated using [cargo-readme](https://crates.io/crates/cargo-readme), and includes the rustdoc from `src/main.rs`. \ No newline at end of file +This text was generated using [cargo-readme](https://crates.io/crates/cargo-readme), and includes the rustdoc from `src/main.rs`. diff --git a/sources/api/thar-be-settings/README.md b/sources/api/thar-be-settings/README.md index f1778440517..062c1da8f18 100644 --- a/sources/api/thar-be-settings/README.md +++ b/sources/api/thar-be-settings/README.md @@ -18,4 +18,4 @@ In the standalone ("all keys") mode, it queries the API for all services and con ## Colophon -This text was generated using [cargo-readme](https://crates.io/crates/cargo-readme), and includes the rustdoc from `src/lib.rs`. \ No newline at end of file +This text was generated using [cargo-readme](https://crates.io/crates/cargo-readme), and includes the rustdoc from `src/lib.rs`. diff --git a/sources/api/thar-be-updates/README.md b/sources/api/thar-be-updates/README.md index 3e0a8df65a5..3cad3a6ca67 100644 --- a/sources/api/thar-be-updates/README.md +++ b/sources/api/thar-be-updates/README.md @@ -20,4 +20,4 @@ thar-be-updates uses a lockfile to control read/write access to the disks and th ## Colophon -This text was generated from `README.tpl` using [cargo-readme](https://crates.io/crates/cargo-readme), and includes the rustdoc from `src/main.rs`. \ No newline at end of file +This text was generated from `README.tpl` using [cargo-readme](https://crates.io/crates/cargo-readme), and includes the rustdoc from `src/main.rs`. diff --git a/sources/bottlerocket-release/README.md b/sources/bottlerocket-release/README.md index 22edb8bfd47..f4e17dd8807 100644 --- a/sources/bottlerocket-release/README.md +++ b/sources/bottlerocket-release/README.md @@ -11,4 +11,4 @@ The information is pulled at runtime because build_id changes frequently and wou ## Colophon -This text was generated from `README.tpl` using [cargo-readme](https://crates.io/crates/cargo-readme), and includes the rustdoc from `src/lib.rs`. \ No newline at end of file +This text was generated from `README.tpl` using [cargo-readme](https://crates.io/crates/cargo-readme), and includes the rustdoc from `src/lib.rs`. diff --git a/sources/bottlerocket-variant/README.md b/sources/bottlerocket-variant/README.md index 3ec6979bcb5..cd958fbcf92 100644 --- a/sources/bottlerocket-variant/README.md +++ b/sources/bottlerocket-variant/README.md @@ -7,4 +7,4 @@ useful in build scripts and other tooling that is variant-aware. ## Colophon -This text was generated from `README.tpl` using [cargo-readme](https://crates.io/crates/cargo-readme), and includes the rustdoc from `src/lib.rs`. \ No newline at end of file +This text was generated from `README.tpl` using [cargo-readme](https://crates.io/crates/cargo-readme), and includes the rustdoc from `src/lib.rs`. diff --git a/sources/cfsignal/README.md b/sources/cfsignal/README.md index e484fcff156..831fa977111 100644 --- a/sources/cfsignal/README.md +++ b/sources/cfsignal/README.md @@ -19,4 +19,4 @@ Configuration is read from a TOML file, which is generated from Bottlerocket set ## Colophon -This text was generated from `README.tpl` using [cargo-readme](https://crates.io/crates/cargo-readme), and includes the rustdoc from `src/main.rs`. \ No newline at end of file +This text was generated from `README.tpl` using [cargo-readme](https://crates.io/crates/cargo-readme), and includes the rustdoc from `src/main.rs`. diff --git a/sources/constants/README.md b/sources/constants/README.md index 5658066c757..a8e92712675 100644 --- a/sources/constants/README.md +++ b/sources/constants/README.md @@ -6,4 +6,4 @@ Current version: 0.1.0 ## Colophon -This text was generated from `README.tpl` using [cargo-readme](https://crates.io/crates/cargo-readme), and includes the rustdoc from `src/main.rs`. \ No newline at end of file +This text was generated from `README.tpl` using [cargo-readme](https://crates.io/crates/cargo-readme), and includes the rustdoc from `src/main.rs`. diff --git a/sources/driverdog/README.md b/sources/driverdog/README.md index 3ecca665e3a..d3031542a8e 100644 --- a/sources/driverdog/README.md +++ b/sources/driverdog/README.md @@ -11,4 +11,4 @@ driverdog is a tool to link kernel modules at runtime. It uses a toml configurat ## Colophon -This text was generated from `README.tpl` using [cargo-readme](https://crates.io/crates/cargo-readme), and includes the rustdoc from `src/main.rs`. \ No newline at end of file +This text was generated from `README.tpl` using [cargo-readme](https://crates.io/crates/cargo-readme), and includes the rustdoc from `src/main.rs`. diff --git a/sources/generate-readme/src/lib.rs b/sources/generate-readme/src/lib.rs index c4cadece3d2..aef90d83688 100644 --- a/sources/generate-readme/src/lib.rs +++ b/sources/generate-readme/src/lib.rs @@ -72,7 +72,7 @@ where })?; let mut template = File::open("README.tpl").context(error::ReadmeTemplateOpenSnafu)?; - let content = cargo_readme::generate_readme( + let mut content = cargo_readme::generate_readme( &PathBuf::from("."), // root &mut source, // source Some(&mut template), // template @@ -84,6 +84,11 @@ where ) .map_err(|e| error::ReadmeGenerateSnafu { error: e }.build())?; + // Make sure the end of the file has a newline + if content.chars().last().unwrap_or_default() != '\n' { + content = content + "\n"; + } + let mut readme = File::create("README.md").context(error::ReadmeCreateSnafu)?; readme .write_all(content.as_bytes()) diff --git a/sources/ghostdog/README.md b/sources/ghostdog/README.md index 59a70b2afdc..0f070a9fd14 100644 --- a/sources/ghostdog/README.md +++ b/sources/ghostdog/README.md @@ -7,4 +7,4 @@ It can be called as a udev helper program to identify ephemeral disks. ## Colophon -This text was generated from `README.tpl` using [cargo-readme](https://crates.io/crates/cargo-readme), and includes the rustdoc from `src/main.rs`. \ No newline at end of file +This text was generated from `README.tpl` using [cargo-readme](https://crates.io/crates/cargo-readme), and includes the rustdoc from `src/main.rs`. diff --git a/sources/imdsclient/README.md b/sources/imdsclient/README.md index b48114953b0..563f05fd92d 100644 --- a/sources/imdsclient/README.md +++ b/sources/imdsclient/README.md @@ -21,4 +21,4 @@ The result is returned as a `String` _(ex. m5.large)_. ## Colophon -This text was generated from `README.tpl` using [cargo-readme](https://crates.io/crates/cargo-readme), and includes the rustdoc from `src/lib.rs`. \ No newline at end of file +This text was generated from `README.tpl` using [cargo-readme](https://crates.io/crates/cargo-readme), and includes the rustdoc from `src/lib.rs`. diff --git a/sources/logdog/README.md b/sources/logdog/README.md index 85026313708..6dea6ddeb48 100644 --- a/sources/logdog/README.md +++ b/sources/logdog/README.md @@ -8,7 +8,8 @@ Current version: 0.1.0 into a tarball for easy export. Usage example: -```rust + +```shell $ logdog logs are at: /var/log/support/bottlerocket-logs.tar.gz ``` @@ -25,4 +26,4 @@ based on the value of the `VARIANT` environment variable at build time. ## Colophon -This text was generated from `README.tpl` using [cargo-readme](https://crates.io/crates/cargo-readme), and includes the rustdoc from `src/main.rs`. \ No newline at end of file +This text was generated from `README.tpl` using [cargo-readme](https://crates.io/crates/cargo-readme), and includes the rustdoc from `src/main.rs`. diff --git a/sources/logdog/src/main.rs b/sources/logdog/src/main.rs index d6a43d874fa..879a3972bbb 100644 --- a/sources/logdog/src/main.rs +++ b/sources/logdog/src/main.rs @@ -5,7 +5,8 @@ into a tarball for easy export. Usage example: -``` + +```shell $ logdog logs are at: /var/log/support/bottlerocket-logs.tar.gz ``` diff --git a/sources/metricdog/README.md b/sources/metricdog/README.md index 49bec7dc5d4..85241841b61 100644 --- a/sources/metricdog/README.md +++ b/sources/metricdog/README.md @@ -59,4 +59,4 @@ ignore_waves = false ## Colophon -This text was generated from `README.tpl` using [cargo-readme](https://crates.io/crates/cargo-readme), and includes the rustdoc from `src/main.rs`. \ No newline at end of file +This text was generated from `README.tpl` using [cargo-readme](https://crates.io/crates/cargo-readme), and includes the rustdoc from `src/main.rs`. diff --git a/sources/models/README.md b/sources/models/README.md index b36643eb63d..51fdd6b047e 100644 --- a/sources/models/README.md +++ b/sources/models/README.md @@ -124,4 +124,4 @@ Note: all models share the same `Cargo.toml`. ## Colophon -This text was generated from `README.tpl` using [cargo-readme](https://crates.io/crates/cargo-readme), and includes the rustdoc from `src/lib.rs`. \ No newline at end of file +This text was generated from `README.tpl` using [cargo-readme](https://crates.io/crates/cargo-readme), and includes the rustdoc from `src/lib.rs`. diff --git a/sources/models/model-derive/README.md b/sources/models/model-derive/README.md index e04def47d1d..754380acd32 100644 --- a/sources/models/model-derive/README.md +++ b/sources/models/model-derive/README.md @@ -41,4 +41,4 @@ Similar to the `serde` attribute added to fields, this is because we don't want ## Colophon -This text was generated from `README.tpl` using [cargo-readme](https://crates.io/crates/cargo-readme), and includes the rustdoc from `src/lib.rs`. \ No newline at end of file +This text was generated from `README.tpl` using [cargo-readme](https://crates.io/crates/cargo-readme), and includes the rustdoc from `src/lib.rs`. diff --git a/sources/models/scalar-derive/README.md b/sources/models/scalar-derive/README.md index ca15ef1adc7..8f0c77c7f6b 100644 --- a/sources/models/scalar-derive/README.md +++ b/sources/models/scalar-derive/README.md @@ -172,4 +172,4 @@ impl Validate for MyWrapper { ## Colophon -This text was generated from `README.tpl` using [cargo-readme](https://crates.io/crates/cargo-readme), and includes the rustdoc from `src/lib.rs`. \ No newline at end of file +This text was generated from `README.tpl` using [cargo-readme](https://crates.io/crates/cargo-readme), and includes the rustdoc from `src/lib.rs`. diff --git a/sources/models/scalar/README.md b/sources/models/scalar/README.md index e41f88154b5..76a2c12046e 100644 --- a/sources/models/scalar/README.md +++ b/sources/models/scalar/README.md @@ -10,4 +10,4 @@ types. ## Colophon -This text was generated from `README.tpl` using [cargo-readme](https://crates.io/crates/cargo-readme), and includes the rustdoc from `src/lib.rs`. \ No newline at end of file +This text was generated from `README.tpl` using [cargo-readme](https://crates.io/crates/cargo-readme), and includes the rustdoc from `src/lib.rs`. diff --git a/sources/parse-datetime/README.md b/sources/parse-datetime/README.md index 527785201d1..0c5b491d255 100644 --- a/sources/parse-datetime/README.md +++ b/sources/parse-datetime/README.md @@ -24,4 +24,4 @@ Examples: ## Colophon -This text was generated from `README.tpl` using [cargo-readme](https://crates.io/crates/cargo-readme), and includes the rustdoc from `src/lib.rs`. \ No newline at end of file +This text was generated from `README.tpl` using [cargo-readme](https://crates.io/crates/cargo-readme), and includes the rustdoc from `src/lib.rs`. diff --git a/sources/retry-read/README.md b/sources/retry-read/README.md index 2ec99fefa4a..6eb03f6d898 100644 --- a/sources/retry-read/README.md +++ b/sources/retry-read/README.md @@ -9,4 +9,4 @@ of the input (unlike `read_to_end` and `read_to_string`). ## Colophon -This text was generated from `README.tpl` using [cargo-readme](https://crates.io/crates/cargo-readme), and includes the rustdoc from `src/lib.rs`. \ No newline at end of file +This text was generated from `README.tpl` using [cargo-readme](https://crates.io/crates/cargo-readme), and includes the rustdoc from `src/lib.rs`. diff --git a/sources/shimpei/README.md b/sources/shimpei/README.md index 6d7e8cd119a..4a40a65467d 100644 --- a/sources/shimpei/README.md +++ b/sources/shimpei/README.md @@ -8,4 +8,4 @@ Current version: 0.1.0 ## Colophon -This text was generated from `README.tpl` using [cargo-readme](https://crates.io/crates/cargo-readme), and includes the rustdoc from `src/main.rs`. \ No newline at end of file +This text was generated from `README.tpl` using [cargo-readme](https://crates.io/crates/cargo-readme), and includes the rustdoc from `src/main.rs`. diff --git a/sources/updater/.gitignore b/sources/updater/.gitignore index f0e3bcacb97..53eaa21960d 100644 --- a/sources/updater/.gitignore +++ b/sources/updater/.gitignore @@ -1,2 +1,2 @@ /target -**/*.rs.bk \ No newline at end of file +**/*.rs.bk diff --git a/sources/updater/README.md b/sources/updater/README.md index ee711f405ae..d9e4205a877 100644 --- a/sources/updater/README.md +++ b/sources/updater/README.md @@ -79,17 +79,17 @@ See the [apiclient README](../api/apiclient/README.md) for details. If you don't want to use the simpler update mode available in [apiclient](../api/apiclient/README.md), or you just want to control what's going on at a lower level, read on. First, refresh the list of available updates: -``` +```shell apiclient raw -u /actions/refresh-updates -m POST ``` Now you can see the list of available updates, along with the chosen update, according to your `version-lock` [setting](../../README.md#updates-settings): -``` +```shell apiclient get /updates/status ``` This will return the current update status in JSON format. The status should look something like the following (pretty-printed): -``` +```json { "update_state": "Available", "available_updates": [ @@ -122,23 +122,23 @@ This will return the current update status in JSON format. The status should loo You can see that we're running `v0.3.2` in the active partition, and that `v0.4.0` is available. If you're happy with that selection, you can request that the update be downloaded and applied to disk. (The update will remain inactive until you make the `activate-update` call below.) -``` +```shell apiclient raw -u /actions/prepare-update -m POST ``` After you request that the update be prepared, you can check the update status again until it reflects the new version in the staging partition. -``` +```shell apiclient get /updates/status ``` If the staging partition shows the new version, you can proceed to "activate" the update. This means that as soon as the host is rebooted it will try to run the new version. (If the new version can't boot, we automatically flip back to the old version.) -``` +```shell apiclient raw -u /actions/activate-update -m POST ``` You can reboot the host with: -``` +```shell apiclient raw -u /actions/reboot -m POST ``` diff --git a/sources/updater/signpost/.gitignore b/sources/updater/signpost/.gitignore index f0e3bcacb97..53eaa21960d 100644 --- a/sources/updater/signpost/.gitignore +++ b/sources/updater/signpost/.gitignore @@ -1,2 +1,2 @@ /target -**/*.rs.bk \ No newline at end of file +**/*.rs.bk diff --git a/tools/infrasys/cloudformation-templates/kms_key_setup.yml b/tools/infrasys/cloudformation-templates/kms_key_setup.yml index 09e3e113677..385174526be 100644 --- a/tools/infrasys/cloudformation-templates/kms_key_setup.yml +++ b/tools/infrasys/cloudformation-templates/kms_key_setup.yml @@ -25,6 +25,6 @@ Resources: AliasName: !Sub "alias/${Alias}" TargetKeyId: !Ref KMSKey -Outputs: +Outputs: KeyId: Value: !GetAtt KMSKey.Arn diff --git a/tools/infrasys/cloudformation-templates/s3_setup.yml b/tools/infrasys/cloudformation-templates/s3_setup.yml index 61cf5c663bc..31b4e9fe35d 100644 --- a/tools/infrasys/cloudformation-templates/s3_setup.yml +++ b/tools/infrasys/cloudformation-templates/s3_setup.yml @@ -1,11 +1,11 @@ Resources: TUFRepoBucket: Type: AWS::S3::Bucket - DeletionPolicy: Retain + DeletionPolicy: Retain Properties: VersioningConfiguration: Status: Enabled - AccessControl: LogDeliveryWrite + AccessControl: LogDeliveryWrite MetricsConfigurations: - Id: BucketMetrics BucketEncryption: @@ -17,8 +17,8 @@ Resources: BlockPublicPolicy: True IgnorePublicAcls: True RestrictPublicBuckets: True - -Outputs: + +Outputs: BucketName: Value: !Ref TUFRepoBucket RDN: diff --git a/tools/infrasys/test_tomls/toml_yaml_conversion.toml b/tools/infrasys/test_tomls/toml_yaml_conversion.toml index 57508f58a92..f2e580133ec 100644 --- a/tools/infrasys/test_tomls/toml_yaml_conversion.toml +++ b/tools/infrasys/test_tomls/toml_yaml_conversion.toml @@ -1,12 +1,12 @@ -[repo.default] +[repo.default] file_hosting_config_name = "TUF-Repo-S3-Buck" signing_keys = { kms = { available_keys = { "e4a8f7fe-2272-4e51-bc3e-3f719c77eb31" = "us-west-1" } } } root_keys = { kms = { available_keys = { "e4a8f7fe-2272-4e51-bc3e-3f719c77eb31" = "us-west-1" } } } root_key_threshold = 1 pub_key_threshold = 1 - -[aws] + +[aws] [aws.s3.TUF-Repo-S3-Buck] region = "us-west-2" - vpc_endpoint_id = "vpc-12345" - s3_prefix = "/my-bottlerocket-remix" + vpc_endpoint_id = "vpc-12345" + s3_prefix = "/my-bottlerocket-remix" diff --git a/tools/partyplanner b/tools/partyplanner index 259ee4bfbdc..b3bd1a18c77 100755 --- a/tools/partyplanner +++ b/tools/partyplanner @@ -58,7 +58,7 @@ BIOS_MIB="4" # one per disk OVERHEAD_MIB="$((GPT_MIB * 2 + BIOS_MIB))" # The 'recommended' size for the EFI partition is 100MB but our EFI images are -# under 1MB, so this will suffice for now. It would be possible to increase the +# under 2MB, so this will suffice for now. It would be possible to increase the # EFI partition size by taking space from the "reserved" area below. EFI_MIB="5" # one per bank @@ -71,7 +71,7 @@ EFI_MIB="5" # one per bank # # !!! WARNING !!! # -# Increasing any of these constants is very likely break systems on update, +# Increasing any of these constants is very likely to break systems on update, # since the corresponding partitions are adjacent on disk and have no room to # grow. BOOT_SCALE_FACTOR="20" @@ -223,9 +223,9 @@ set_partition_types() { local typecode for part in BOOT ROOT HASH RESERVED ; do for bank in A B ; do - typecode="BOTTLEROCKET_${part}_TYPECODE" - typecode="${!typecode}" - pp_type["${part}-${bank}"]="${typecode}" + typecode="BOTTLEROCKET_${part}_TYPECODE" + typecode="${!typecode}" + pp_type["${part}-${bank}"]="${typecode}" done done } diff --git a/tools/pubsys/policies/ssm/README.md b/tools/pubsys/policies/ssm/README.md index d4751b036f9..9760125ff7f 100644 --- a/tools/pubsys/policies/ssm/README.md +++ b/tools/pubsys/policies/ssm/README.md @@ -5,7 +5,7 @@ You can pass a different directory to `pubsys` to use a different set of paramet The directory is expected to contain a file named `defaults.toml` with a table entry per parameter, like this: -``` +```toml [[parameter]] name = "{variant}/{arch}/{image_version}/image_id" value = "{image_id}" @@ -30,7 +30,7 @@ The parameter will only be populated if the current `variant` or `arch` matches (If both `variant` and `arch` are listed, the build must match an entry from both lists.) For example, to add an extra parameter that's only set for "aarch64" builds of the "aws-ecs-1" variant: -``` +```toml [[parameter]] arch = ["aarch64"] variant = ["aws-ecs-1"] diff --git a/tools/rpm2img b/tools/rpm2img index ebc33db2063..0e34fe2f7ab 100755 --- a/tools/rpm2img +++ b/tools/rpm2img @@ -243,7 +243,7 @@ if [[ "${ARCH}" == "x86_64" ]]; then fi # We also need an EFI partition, formatted FAT32 with the -# EFI binary at the correct path, eg /efi/boot. The grub +# EFI binary at the correct path, e.g. /efi/boot. The grub # package has placed the image in /boot/efi/EFI/BOOT. mv "${ROOT_MOUNT}/boot/efi"/* "${EFI_MOUNT}" diff --git a/tools/testsys/Test.toml.example b/tools/testsys/Test.toml.example index 82190f87215..c3b41db4299 100644 --- a/tools/testsys/Test.toml.example +++ b/tools/testsys/Test.toml.example @@ -97,7 +97,7 @@ conformance-image = "" # Configurable values: # -# cluster-names: +# cluster-names: # All clusters the variant should be tested over. Cluster naming supports templated strings, and # both `arch` and `variant` are provided as variables (`{{arch}}-{{variant}}`). # @@ -116,4 +116,4 @@ conformance-image = "" # # conformance-registry: (K8s only) # Specify a custom registry for conformance testing images. -# For `aws-k8s` variants this will be used as the Sonobuoy e2e registry. \ No newline at end of file +# For `aws-k8s` variants this will be used as the Sonobuoy e2e registry. diff --git a/variants/README.md b/variants/README.md index 08d64dcde8f..e780809bd67 100644 --- a/variants/README.md +++ b/variants/README.md @@ -267,7 +267,7 @@ It has an empty `lib.rs` for the actual crate, since Cargo expects some Rust cod Our sample variant has the following manifest. -``` +```toml [package] name = "my-variant" version = "0.1.0" @@ -316,7 +316,7 @@ Be sure to include `publish = false` for all packages, as these are not standard We use the same build script for all variants. -``` +```rust use std::process::{exit, Command}; fn main() -> Result<(), std::io::Error> { @@ -335,14 +335,14 @@ The `package.metadata` table can be extended with declarative elements that enab We use the same Rust code for all variants. -``` +```rust // not used ``` ### Next Steps To build your variant, run the following command in the top-level Bottlerocket directory. -``` +```shell cargo make -e BUILDSYS_VARIANT=my-variant ```