From 17e3b44300ec077f1accc500168da337b1637ba9 Mon Sep 17 00:00:00 2001 From: "Brian C. Lane" Date: Wed, 5 May 2021 14:30:14 -0700 Subject: [PATCH] - runtime-cleanup: Use branding package name instead of product.name (bcl@redhat.com) - treebuilder: Add branding package to template variables (bcl@redhat.com) - livemedia-creator: Use inst.ks on cmdline for virt (bcl@redhat.com) - docs: Remove composer-cli.1 (bcl@redhat.com) --- .gitignore | 1 + 0001-docs-Remove-composer-cli.1.patch | 941 -------------------------- lorax.spec | 12 +- sources | 2 +- 4 files changed, 10 insertions(+), 946 deletions(-) delete mode 100644 0001-docs-Remove-composer-cli.1.patch diff --git a/.gitignore b/.gitignore index 567070d..08171d5 100644 --- a/.gitignore +++ b/.gitignore @@ -197,3 +197,4 @@ /lorax-34.9.tar.gz /lorax-35.0.tar.gz /lorax-35.1.tar.gz +/lorax-35.2.tar.gz diff --git a/0001-docs-Remove-composer-cli.1.patch b/0001-docs-Remove-composer-cli.1.patch deleted file mode 100644 index e68da6a..0000000 --- a/0001-docs-Remove-composer-cli.1.patch +++ /dev/null @@ -1,941 +0,0 @@ -From cc7430fbbd7f72e5d6efd3e83efe2616de3a5d58 Mon Sep 17 00:00:00 2001 -From: "Brian C. Lane" -Date: Mon, 26 Apr 2021 16:24:12 -0700 -Subject: [PATCH] docs: Remove composer-cli.1 - ---- - docs/man/composer-cli.1 | 922 ---------------------------------------- - 1 file changed, 922 deletions(-) - delete mode 100644 docs/man/composer-cli.1 - -diff --git a/docs/man/composer-cli.1 b/docs/man/composer-cli.1 -deleted file mode 100644 -index ce78286c..00000000 ---- a/docs/man/composer-cli.1 -+++ /dev/null -@@ -1,922 +0,0 @@ --.\" Man page generated from reStructuredText. --. --.TH "COMPOSER-CLI" "1" "Mar 04, 2021" "35.0" "Lorax" --.SH NAME --composer-cli \- Composer Cmdline Utility Documentation --. --.nr rst2man-indent-level 0 --. --.de1 rstReportMargin --\\$1 \\n[an-margin] --level \\n[rst2man-indent-level] --level margin: \\n[rst2man-indent\\n[rst2man-indent-level]] --- --\\n[rst2man-indent0] --\\n[rst2man-indent1] --\\n[rst2man-indent2] --.. --.de1 INDENT --.\" .rstReportMargin pre: --. RS \\$1 --. nr rst2man-indent\\n[rst2man-indent-level] \\n[an-margin] --. nr rst2man-indent-level +1 --.\" .rstReportMargin post: --.. --.de UNINDENT --. RE --.\" indent \\n[an-margin] --.\" old: \\n[rst2man-indent\\n[rst2man-indent-level]] --.nr rst2man-indent-level -1 --.\" new: \\n[rst2man-indent\\n[rst2man-indent-level]] --.in \\n[rst2man-indent\\n[rst2man-indent-level]]u --.. --.INDENT 0.0 --.TP --.B Authors --Brian C. Lane <\fI\%bcl@redhat.com\fP> --.UNINDENT --.sp --\fBcomposer\-cli\fP is an interactive tool for use with a WELDR API server, --managing blueprints, exploring available packages, and building new images. As --of Fedora 34, \fIosbuild\-composer \fP is the recommended --server. --.sp --It requires the server to be installed on the local system, and the user --running it needs to be a member of the \fBweldr\fP group. --.SH COMPOSER-CLI CMDLINE ARGUMENTS --.sp --Lorax Composer commandline tool -- --.INDENT 0.0 --.INDENT 3.5 --.sp --.nf --.ft C --usage: composer\-cli [\-h] [\-j] [\-s SOCKET] [\-\-log LOG] [\-a APIVER] [\-\-test TESTMODE] [\-V] ... --.ft P --.fi --.UNINDENT --.UNINDENT --.SS Positional Arguments --.INDENT 0.0 --.TP --.Bargs --.UNINDENT --.SS Named Arguments --.INDENT 0.0 --.TP --.B\-j, \-\-json --Output the raw JSON response instead of the normal output. --.sp --Default: False --.TP --.B\-s, \-\-socket --Path to the socket file to listen on --.sp --Default: "/run/weldr/api.socket" --.TP --.B\-\-log --Path to logfile (./composer\-cli.log) --.TP --.B\-a, \-\-api --API Version to use --.sp --Default: "1" --.TP --.B\-\-test --Pass test mode to compose. 1=Mock compose with fail. 2=Mock compose with finished. --.sp --Default: 0 --.TP --.B\-V --show program\(aqs version number and exit --.sp --Default: False --.UNINDENT --.sp --.INDENT 0.0 --.TP --.B compose start [\-\-size XXXX] [ | ] --Start a compose using the selected blueprint and output type. Optionally start an upload. --\-\-size is supported by osbuild\-composer, and is in MiB. --.TP --.B compose start\-ostree [\-\-size XXXX] [\-\-parent PARENT] [\-\-ref REF] [\-\-url url] [ ] --Start an ostree compose using the selected blueprint and output type. Optionally start an upload. This command --is only supported by osbuild\-composer. \-\-size is in MiB. --.TP --.B compose types --List the supported output types. --.TP --.B compose status --List the status of all running and finished composes. --.TP --.B compose list [waiting|running|finished|failed] --List basic information about composes. --.TP --.B compose log [] --Show the last SIZE kB of the compose log. --.TP --.B compose cancel --Cancel a running compose and delete any intermediate results. --.TP --.B compose delete --Delete the listed compose results. --.TP --.B compose info --Show detailed information on the compose. --.TP --.B compose metadata --Download the metadata use to create the compose to \-metadata.tar --.TP --.B compose logs --Download the compose logs to \-logs.tar --.TP --.B compose results --Download all of the compose results; metadata, logs, and image to .tar --.TP --.B compose image --Download the output image from the compose. Filename depends on the type. --.TP --.B blueprints list --List the names of the available blueprints. --.TP --.B blueprints show --Display the blueprint in TOML format. --.TP --.B blueprints changes --Display the changes for each blueprint. --.TP --.B blueprints diff --Display the differences between 2 versions of a blueprint. --FROM\-COMMIT can be a commit hash or NEWEST --TO\-COMMIT can be a commit hash, NEWEST, or WORKSPACE --.TP --.B blueprints save --Save the blueprint to a file, .toml --.TP --.B blueprints delete --Delete a blueprint from the server --.TP --.B blueprints depsolve --Display the packages needed to install the blueprint. --.TP --.B blueprints push --Push a blueprint TOML file to the server. --.TP --.B blueprints freeze --Display the frozen blueprint\(aqs modules and packages. --.TP --.B blueprints freeze show --Display the frozen blueprint in TOML format. --.TP --.B blueprints freeze save --Save the frozen blueprint to a file, .frozen.toml. --.TP --.B blueprints tag --Tag the most recent blueprint commit as a release. --.TP --.B blueprints undo --Undo changes to a blueprint by reverting to the selected commit. --.TP --.B blueprints workspace --Push the blueprint TOML to the temporary workspace storage. --.TP --.B modules list --List the available modules. --.TP --.B projects list --List the available projects. --.TP --.B projects info --Show details about the listed projects. --.TP --.B sources list --List the available sources --.TP --.B sources info --Details about the source. --.TP --.B sources add --Add a package source to the server. --.TP --.B sources change --Change an existing source --.TP --.B sources delete --Delete a package source. --.UNINDENT --.sp --status show Show API server status. --.INDENT 0.0 --.TP --.B upload info --Details about an upload --.TP --.B upload start [ |] --Upload a build image to the selected provider. --.TP --.B upload log --Show the upload log --.TP --.B upload cancel --Cancel an upload with that is queued or in progress --.TP --.B upload delete --Delete the upload and remove it from the build --.TP --.B upload reset --Reset the upload so that it can be tried again --.TP --.B providers list --List the available providers, or list the available profiles --.TP --.B providers show --show the details of a specific provider\(aqs profile --.TP --.B providers push --Add a new profile, or overwrite an existing one --.TP --.B providers save --Save the profile\(aqs details to a TOML file named .toml --.TP --.B providers delete --Delete a profile from a provider --.UNINDENT -- --.SH EDIT A BLUEPRINT --.sp --Start out by listing the available blueprints using \fBcomposer\-cli blueprints --list\fP, pick one and save it to the local directory by running \fBcomposer\-cli --blueprints save http\-server\fP\&. --.sp --Edit the file (it will be saved with a .toml extension) and change the --description, add a package or module to it. Send it back to the server by --running \fBcomposer\-cli blueprints push http\-server.toml\fP\&. You can verify that it was --saved by viewing the changelog \- \fBcomposer\-cli blueprints changes http\-server\fP\&. --.sp --See the \fI\%Example Blueprint\fP for an example. --.SH BUILD AN IMAGE --.sp --Build a \fBqcow2\fP disk image from this blueprint by running \fBcomposer\-cli --compose start http\-server qcow2\fP\&. It will print a UUID that you can use to --keep track of the build. You can also cancel the build if needed. --.sp --The available types of images is displayed by \fBcomposer\-cli compose types\fP\&. --Currently this consists of: alibaba, ami, ext4\-filesystem, google, hyper\-v, --live\-iso, openstack, partitioned\-disk, qcow2, tar, vhd, vmdk --.sp --You can optionally start an upload of the finished image, see \fI\%Image Uploads\fP for --more information. --.SH MONITOR THE BUILD STATUS --.sp --Monitor it using \fBcomposer\-cli compose status\fP, which will show the status of --all the builds on the system. You can view the end of the anaconda build logs --once it is in the \fBRUNNING\fP state using \fBcomposer\-cli compose log UUID\fP --where UUID is the UUID returned by the start command. --.sp --Once the build is in the \fBFINISHED\fP state you can download the image. --.SH DOWNLOAD THE IMAGE --.sp --Downloading the final image is done with \fBcomposer\-cli compose image UUID\fP and it will --save the qcow2 image as \fBUUID\-disk.qcow2\fP which you can then use to boot a VM like this: --.INDENT 0.0 --.INDENT 3.5 --.sp --.nf --.ft C --qemu\-kvm \-\-name test\-image \-m 1024 \-hda ./UUID\-disk.qcow2 --.ft P --.fi --.UNINDENT --.UNINDENT --.SH IMAGE UPLOADS --.sp --\fBcomposer\-cli\fP can upload the images to a number of services, including AWS, --OpenStack, and vSphere. The upload can be started when the build is finished, --by using \fBcomposer\-cli compose start ...\fP or an existing image can be uploaded --with \fBcomposer\-cli upload start ...\fP\&. In order to access the service you need --to pass authentication details to composer\-cli using a TOML file, or reference --a previously saved profile. --.sp --\fBNOTE:\fP --.INDENT 0.0 --.INDENT 3.5 --With \fBosbuild\-composer\fP you can only specify upload targets during --the compose process. --.UNINDENT --.UNINDENT --.SH PROVIDERS --.sp --Providers are the services providers with Ansible playbook support under --\fB/usr/share/lorax/lifted/providers/\fP, you will need to gather some provider --specific information in order to authenticate with it. You can view the --required fields using \fBcomposer\-cli providers template \fP, eg. for AWS --you would run: --.INDENT 0.0 --.INDENT 3.5 --.sp --.nf --.ft C --composer\-cli upload template aws --.ft P --.fi --.UNINDENT --.UNINDENT --.sp --The output looks like this: --.INDENT 0.0 --.INDENT 3.5 --.sp --.nf --.ft C --provider = "aws" -- --[settings] --aws_access_key = "AWS Access Key" --aws_bucket = "AWS Bucket" --aws_region = "AWS Region" --aws_secret_key = "AWS Secret Key" --.ft P --.fi --.UNINDENT --.UNINDENT --.sp --Save this into an \fBaws\-credentials.toml\fP file and use it when running \fBstart\fP\&. --.SS AWS --.sp --The access key and secret key can be created by going to the --\fBIAM\->Users\->Security Credentials\fP section and creating a new access key. The --secret key will only be shown when it is first created so make sure to record --it in a secure place. The region should be the region that you want to use the --AMI in, and the bucket can be an existing bucket, or a new one, following the --normal AWS bucket naming rules. It will be created if it doesn\(aqt already exist. --.sp --When uploading the image it is first uploaded to the s3 bucket, and then --converted to an AMI. If the conversion is successful the s3 object will be --deleted. If it fails, re\-trying after correcting the problem will re\-use the --object if you have not deleted it in the meantime, speeding up the process. --.SH PROFILES --.sp --Profiles store the authentication settings associated with a specific provider. --Providers can have multiple profiles, as long as their names are unique. For --example, you may have one profile for testing and another for production --uploads. --.sp --Profiles are created by pushing the provider settings template to the server using --\fBcomposer\-cli providers push \fP where \fBPROFILE.TOML\fP is the same as the --provider template, but with the addition of a \fBprofile\fP field. For example, an AWS --profile named \fBtest\-uploads\fP would look like this: --.INDENT 0.0 --.INDENT 3.5 --.sp --.nf --.ft C --provider = "aws" --profile = "test\-uploads" -- --[settings] --aws_access_key = "AWS Access Key" --aws_bucket = "AWS Bucket" --aws_region = "AWS Region" --aws_secret_key = "AWS Secret Key" --.ft P --.fi --.UNINDENT --.UNINDENT --.sp --You can view the profile by using \fBcomposer\-cli providers aws test\-uploads\fP\&. --.SH BUILD AN IMAGE AND UPLOAD RESULTS --.sp --If you have a profile named \fBtest\-uploads\fP: --.INDENT 0.0 --.INDENT 3.5 --.sp --.nf --.ft C --composer\-cli compose start example\-http\-server ami "http image" aws test\-uploads --.ft P --.fi --.UNINDENT --.UNINDENT --.sp --Or if you have the settings stored in a TOML file: --.INDENT 0.0 --.INDENT 3.5 --.sp --.nf --.ft C --composer\-cli compose start example\-http\-server ami "http image" aws\-settings.toml --.ft P --.fi --.UNINDENT --.UNINDENT --.sp --It will return the UUID of the image build, and the UUID of the upload. Once --the build has finished successfully it will start the upload process, which you --can monitor with \fBcomposer\-cli upload info \fP --.sp --You can also view the upload logs from the Ansible playbook with: --.INDENT 0.0 --.INDENT 3.5 --.sp --.nf --.ft C --\(ga\(gacomposer\-cli upload log \(ga\(ga --.ft P --.fi --.UNINDENT --.UNINDENT --.sp --The type of the image must match the type supported by the provider. --.SH UPLOAD AN EXISTING IMAGE --.sp --You can upload previously built images, as long as they are in the \fBFINISHED\fP state, using \fBcomposer\-cli upload start ...\(ga\fP\&. If you have a profile named \fBtest\-uploads\fP: --.INDENT 0.0 --.INDENT 3.5 --.sp --.nf --.ft C --composer\-cli upload start "http\-image" aws test\-uploads --.ft P --.fi --.UNINDENT --.UNINDENT --.sp --Or if you have the settings stored in a TOML file: --.INDENT 0.0 --.INDENT 3.5 --.sp --.nf --.ft C --composer\-cli upload start "http\-image" aws\-settings.toml --.ft P --.fi --.UNINDENT --.UNINDENT --.sp --This will output the UUID of the upload, which can then be used to monitor the status in the same way --described above. --.SH DEBUGGING --.sp --There are a couple of arguments that can be helpful when debugging problems. --These are only meant for debugging and should not be used to script access to --the API. If you need to do that you can communicate with it directly in the --language of your choice. --.sp --\fB\-\-json\fP will return the server\(aqs response as a nicely formatted json output --instead of printing what the command would usually print. --.sp --\fB\-\-test=1\fP will cause a compose start to start creating an image, and then --end with a failed state. --.sp --\fB\-\-test=2\fP will cause a compose to start and then end with a finished state, --without actually composing anything. --.SH BLUEPRINT REFERENCE --.sp --Blueprints are simple text files in \fI\%TOML\fP format that describe --which packages, and what versions, to install into the image. They can also define a limited set --of customizations to make to the final image. --.sp --A basic blueprint looks like this: --.INDENT 0.0 --.INDENT 3.5 --.sp --.nf --.ft C --name = "base" --description = "A base system with bash" --version = "0.0.1" -- --[[packages]] --name = "bash" --version = "4.4.*" --.ft P --.fi --.UNINDENT --.UNINDENT --.sp --The \fBname\fP field is the name of the blueprint. It can contain spaces, but they will be converted to \fB\-\fP --when it is written to disk. It should be short and descriptive. --.sp --\fBdescription\fP can be a longer description of the blueprint, it is only used for display purposes. --.sp --\fBversion\fP is a \fI\%semver compatible\fP version number. If --a new blueprint is uploaded with the same \fBversion\fP the server will --automatically bump the PATCH level of the \fBversion\fP\&. If the \fBversion\fP --doesn\(aqt match it will be used as is. eg. Uploading a blueprint with \fBversion\fP --set to \fB0.1.0\fP when the existing blueprint \fBversion\fP is \fB0.0.1\fP will --result in the new blueprint being stored as \fBversion 0.1.0\fP\&. --.SS [[packages]] and [[modules]] --.sp --These entries describe the package names and matching version glob to be installed into the image. --.sp --The names must match the names exactly, and the versions can be an exact match --or a filesystem\-like glob of the version using \fB*\fP wildcards and \fB?\fP --character matching. --.sp --\fBNOTE:\fP --.INDENT 0.0 --.INDENT 3.5 --Currently there are no differences between \fBpackages\fP and \fBmodules\fP --in \fBosbuild\-composer\fP\&. Both are treated like an rpm package dependency. --.UNINDENT --.UNINDENT --.sp --For example, to install \fBtmux\-2.9a\fP and \fBopenssh\-server\-8.*\fP, you would add --this to your blueprint: --.INDENT 0.0 --.INDENT 3.5 --.sp --.nf --.ft C --[[packages]] --name = "tmux" --version = "2.9a" -- --[[packages]] --name = "openssh\-server" --version = "8.*" --.ft P --.fi --.UNINDENT --.UNINDENT --.SS [[groups]] --.sp --The \fBgroups\fP entries describe a group of packages to be installed into the image. Package groups are --defined in the repository metadata. Each group has a descriptive name used primarily for display --in user interfaces and an ID more commonly used in kickstart files. Here, the ID is the expected --way of listing a group. --.sp --Groups have three different ways of categorizing their packages: mandatory, default, and optional. --For purposes of blueprints, mandatory and default packages will be installed. There is no mechanism --for selecting optional packages. --.sp --For example, if you want to install the \fBanaconda\-tools\fP group you would add this to your --blueprint: --.INDENT 0.0 --.INDENT 3.5 --.sp --.nf --.ft C --[[groups]] --name="anaconda\-tools" --.ft P --.fi --.UNINDENT --.UNINDENT --.sp --\fBgroups\fP is a TOML list, so each group needs to be listed separately, like \fBpackages\fP but with --no version number. --.SS Customizations --.sp --The \fB[customizations]\fP section can be used to configure the hostname of the final image. eg.: --.INDENT 0.0 --.INDENT 3.5 --.sp --.nf --.ft C --[customizations] --hostname = "baseimage" --.ft P --.fi --.UNINDENT --.UNINDENT --.sp --This is optional and may be left out to use the defaults. --.SS [customizations.kernel] --.sp --This allows you to append arguments to the bootloader\(aqs kernel commandline. This will not have any --effect on \fBtar\fP or \fBext4\-filesystem\fP images since they do not include a bootloader. --.sp --For example: --.INDENT 0.0 --.INDENT 3.5 --.sp --.nf --.ft C --[customizations.kernel] --append = "nosmt=force" --.ft P --.fi --.UNINDENT --.UNINDENT --.SS [[customizations.sshkey]] --.sp --Set an existing user\(aqs ssh key in the final image: --.INDENT 0.0 --.INDENT 3.5 --.sp --.nf --.ft C --[[customizations.sshkey]] --user = "root" --key = "PUBLIC SSH KEY" --.ft P --.fi --.UNINDENT --.UNINDENT --.sp --The key will be added to the user\(aqs authorized_keys file. --.sp --\fBWARNING:\fP --.INDENT 0.0 --.INDENT 3.5 --\fBkey\fP expects the entire content of \fB~/.ssh/id_rsa.pub\fP --.UNINDENT --.UNINDENT --.SS [[customizations.user]] --.sp --Add a user to the image, and/or set their ssh key. --All fields for this section are optional except for the \fBname\fP, here is a complete example: --.INDENT 0.0 --.INDENT 3.5 --.sp --.nf --.ft C --[[customizations.user]] --name = "admin" --description = "Administrator account" --password = "$6$CHO2$3rN8eviE2t50lmVyBYihTgVRHcaecmeCk31L..." --key = "PUBLIC SSH KEY" --home = "/srv/widget/" --shell = "/usr/bin/bash" --groups = ["widget", "users", "wheel"] --uid = 1200 --gid = 1200 --.ft P --.fi --.UNINDENT --.UNINDENT --.sp --If the password starts with \fB$6$\fP, \fB$5$\fP, or \fB$2b$\fP it will be stored as --an encrypted password. Otherwise it will be treated as a plain text password. --.sp --\fBWARNING:\fP --.INDENT 0.0 --.INDENT 3.5 --\fBkey\fP expects the entire content of \fB~/.ssh/id_rsa.pub\fP --.UNINDENT --.UNINDENT --.SS [[customizations.group]] --.sp --Add a group to the image. \fBname\fP is required and \fBgid\fP is optional: --.INDENT 0.0 --.INDENT 3.5 --.sp --.nf --.ft C --[[customizations.group]] --name = "widget" --gid = 1130 --.ft P --.fi --.UNINDENT --.UNINDENT --.SS [customizations.timezone] --.sp --Customizing the timezone and the NTP servers to use for the system: --.INDENT 0.0 --.INDENT 3.5 --.sp --.nf --.ft C --[customizations.timezone] --timezone = "US/Eastern" --ntpservers = ["0.north\-america.pool.ntp.org", "1.north\-america.pool.ntp.org"] --.ft P --.fi --.UNINDENT --.UNINDENT --.sp --The values supported by \fBtimezone\fP can be listed by running \fBtimedatectl list\-timezones\fP\&. --.sp --If no timezone is setup the system will default to using \fIUTC\fP\&. The ntp servers are also --optional and will default to using the distribution defaults which are fine for most uses. --.sp --In some image types there are already NTP servers setup, eg. Google cloud image, and they --cannot be overridden because they are required to boot in the selected environment. But the --timezone will be updated to the one selected in the blueprint. --.SS [customizations.locale] --.sp --Customize the locale settings for the system: --.INDENT 0.0 --.INDENT 3.5 --.sp --.nf --.ft C --[customizations.locale] --languages = ["en_US.UTF\-8"] --keyboard = "us" --.ft P --.fi --.UNINDENT --.UNINDENT --.sp --The values supported by \fBlanguages\fP can be listed by running \fBlocalectl list\-locales\fP from --the command line. --.sp --The values supported by \fBkeyboard\fP can be listed by running \fBlocalectl list\-keymaps\fP from --the command line. --.sp --Multiple languages can be added. The first one becomes the --primary, and the others are added as secondary. One or the other of \fBlanguages\fP --or \fBkeyboard\fP must be included (or both) in the section. --.SS [customizations.firewall] --.sp --By default the firewall blocks all access except for services that enable their ports explicitly, --like \fBsshd\fP\&. This command can be used to open other ports or services. Ports are configured using --the port:protocol format: --.INDENT 0.0 --.INDENT 3.5 --.sp --.nf --.ft C --[customizations.firewall] --ports = ["22:tcp", "80:tcp", "imap:tcp", "53:tcp", "53:udp"] --.ft P --.fi --.UNINDENT --.UNINDENT --.sp --Numeric ports, or their names from \fB/etc/services\fP can be used in the \fBports\fP enabled/disabled lists. --.sp --The blueprint settings extend any existing settings in the image templates, so if \fBsshd\fP is --already enabled it will extend the list of ports with the ones listed by the blueprint. --.sp --If the distribution uses \fBfirewalld\fP you can specify services listed by \fBfirewall\-cmd \-\-get\-services\fP --in a \fBcustomizations.firewall.services\fP section: --.INDENT 0.0 --.INDENT 3.5 --.sp --.nf --.ft C --[customizations.firewall.services] --enabled = ["ftp", "ntp", "dhcp"] --disabled = ["telnet"] --.ft P --.fi --.UNINDENT --.UNINDENT --.sp --Remember that the \fBfirewall.services\fP are different from the names in \fB/etc/services\fP\&. --.sp --Both are optional, if they are not used leave them out or set them to an empty list \fB[]\fP\&. If you --only want the default firewall setup this section can be omitted from the blueprint. --.sp --NOTE: The \fBGoogle\fP and \fBOpenStack\fP templates explicitly disable the firewall for their environment. --This cannot be overridden by the blueprint. --.SS [customizations.services] --.sp --This section can be used to control which services are enabled at boot time. --Some image types already have services enabled or disabled in order for the --image to work correctly, and cannot be overridden. eg. \fBami\fP requires --\fBsshd\fP, \fBchronyd\fP, and \fBcloud\-init\fP\&. Without them the image will not --boot. Blueprint services are added to, not replacing, the list already in the --templates, if any. --.sp --The service names are systemd service units. You may specify any systemd unit --file accepted by \fBsystemctl enable\fP eg. \fBcockpit.socket\fP: --.INDENT 0.0 --.INDENT 3.5 --.sp --.nf --.ft C --[customizations.services] --enabled = ["sshd", "cockpit.socket", "httpd"] --disabled = ["postfix", "telnetd"] --.ft P --.fi --.UNINDENT --.UNINDENT --.SS [[repos.git]] --.sp --\fBNOTE:\fP --.INDENT 0.0 --.INDENT 3.5 --Currently \fBosbuild\-composer\fP does not support \fBrepos.git\fP --.UNINDENT --.UNINDENT --.sp --The \fB[[repos.git]]\fP entries are used to add files from a \fI\%git repository\fP --repository to the created image. The repository is cloned, the specified \fBref\fP is checked out --and an rpm is created to install the files to a \fBdestination\fP path. The rpm includes a summary --with the details of the repository and reference used to create it. The rpm is also included in the --image build metadata. --.sp --To create an rpm named \fBserver\-config\-1.0\-1.noarch.rpm\fP you would add this to your blueprint: --.INDENT 0.0 --.INDENT 3.5 --.sp --.nf --.ft C --[[repos.git]] --rpmname="server\-config" --rpmversion="1.0" --rpmrelease="1" --summary="Setup files for server deployment" --repo="PATH OF GIT REPO TO CLONE" --ref="v1.0" --destination="/opt/server/" --.ft P --.fi --.UNINDENT --.UNINDENT --.INDENT 0.0 --.IP \(bu 2 --rpmname: Name of the rpm to create, also used as the prefix name in the tar archive --.IP \(bu 2 --rpmversion: Version of the rpm, eg. "1.0.0" --.IP \(bu 2 --rpmrelease: Release of the rpm, eg. "1" --.IP \(bu 2 --summary: Summary string for the rpm --.IP \(bu 2 --repo: URL of the get repo to clone and create the archive from --.IP \(bu 2 --ref: Git reference to check out. eg. origin/branch\-name, git tag, or git commit hash --.IP \(bu 2 --destination: Path to install the / of the git repo at when installing the rpm --.UNINDENT --.sp --An rpm will be created with the contents of the git repository referenced, with the files --being installed under \fB/opt/server/\fP in this case. --.sp --\fBref\fP can be any valid git reference for use with \fBgit archive\fP\&. eg. to use the head --of a branch set it to \fBorigin/branch\-name\fP, a tag name, or a commit hash. --.sp --Note that the repository is cloned in full each time a build is started, so pointing to a --repository with a large amount of history may take a while to clone and use a significant --amount of disk space. The clone is temporary and is removed once the rpm is created. --.SH EXAMPLE BLUEPRINT --.sp --This example blueprint will install the \fBtmux\fP, \fBgit\fP, and \fBvim\-enhanced\fP --packages. It will set the \fBroot\fP ssh key, add the \fBwidget\fP and \fBadmin\fP --users as well as a \fBstudents\fP group: --.INDENT 0.0 --.INDENT 3.5 --.sp --.nf --.ft C --name = "example\-custom\-base" --description = "A base system with customizations" --version = "0.0.1" -- --[[packages]] --name = "tmux" --version = "*" -- --[[packages]] --name = "git" --version = "*" -- --[[packages]] --name = "vim\-enhanced" --version = "*" -- --[customizations] --hostname = "custombase" -- --[[customizations.sshkey]] --user = "root" --key = "A SSH KEY FOR ROOT" -- --[[customizations.user]] --name = "widget" --description = "Widget process user account" --home = "/srv/widget/" --shell = "/usr/bin/false" --groups = ["dialout", "users"] -- --[[customizations.user]] --name = "admin" --description = "Widget admin account" --password = "$6$CHO2$3rN8eviE2t50lmVyBYihTgVRHcaecmeCk31LeOUleVK/R/aeWVHVZDi26zAH.o0ywBKH9Tc0/wm7sW/q39uyd1" --home = "/srv/widget/" --shell = "/usr/bin/bash" --groups = ["widget", "users", "students"] --uid = 1200 -- --[[customizations.user]] --name = "plain" --password = "simple plain password" -- --[[customizations.user]] --name = "bart" --key = "SSH KEY FOR BART" --groups = ["students"] -- --[[customizations.group]] --name = "widget" -- --[[customizations.group]] --name = "students" --.ft P --.fi --.UNINDENT --.UNINDENT --.SH AUTHOR --Weldr Team --.SH COPYRIGHT --2018, Red Hat, Inc. --.\" Generated by docutils manpage writer. --. --- -2.26.3 - diff --git a/lorax.spec b/lorax.spec index dcc0f30..b9784bc 100644 --- a/lorax.spec +++ b/lorax.spec @@ -3,8 +3,8 @@ %define debug_package %{nil} Name: lorax -Version: 35.1 -Release: 2%{?dist} +Version: 35.2 +Release: 1%{?dist} Summary: Tool for creating the anaconda install images License: GPLv2+ @@ -14,7 +14,6 @@ URL: https://github.com/weldr/lorax # git checkout -b archive-branch lorax-%%{version}-%%{release} # tito build --tgz Source0: %{name}-%{version}.tar.gz -Patch0: 0001-docs-Remove-composer-cli.1.patch BuildRequires: python3-devel BuildRequires: make @@ -136,7 +135,6 @@ Lorax templates for creating the boot.iso and live isos are placed in %prep %setup -q -n %{name}-%{version} -%patch0 -p1 %build @@ -177,6 +175,12 @@ make DESTDIR=$RPM_BUILD_ROOT mandir=%{_mandir} install %{_datadir}/lorax/templates.d/* %changelog +* Wed May 05 2021 Brian C. Lane 35.2-1 +- runtime-cleanup: Use branding package name instead of product.name (bcl@redhat.com) +- treebuilder: Add branding package to template variables (bcl@redhat.com) +- livemedia-creator: Use inst.ks on cmdline for virt (bcl@redhat.com) +- docs: Remove composer-cli.1 (bcl@redhat.com) + * Mon Apr 26 2021 Brian C. Lane 35.1-1 - New lorax documentation - 35.1 (bcl@redhat.com) - Makefile: Use podman as a user for testing and docs (bcl@redhat.com) diff --git a/sources b/sources index 736709d..106d4ba 100644 --- a/sources +++ b/sources @@ -1 +1 @@ -SHA512 (lorax-35.1.tar.gz) = 3081eb8fe4ec2dc5bd6bda0e06a76d832b6cf63cdbbd23f5a79419c1dada68a591150513f5a0c487c9c335349983434be408e78a778e9201dc679dff7a5e7204 +SHA512 (lorax-35.2.tar.gz) = 2eb7d2cdf4e5ae49ba9218c616f5e467c6e7e5867cde149845d4b2e4cc89ff2fb262c59f79c2c2544051d3ccc082db54a1ff58a0dbff472130864770f6c45a0d