- docs: Remove composer-cli.1 manpage
This commit is contained in:
Brian C. Lane
parent
b666fd7402
commit
bd7c3d46e8
941
0001-docs-Remove-composer-cli.1.patch
Normal file
941
0001-docs-Remove-composer-cli.1.patch
Normal file
@ -0,0 +1,941 @@
|
|||||||
|
From cc7430fbbd7f72e5d6efd3e83efe2616de3a5d58 Mon Sep 17 00:00:00 2001
|
||||||
|
From: "Brian C. Lane" <bcl@redhat.com>
|
||||||
|
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 <https://osbuild.org>\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] <BLUEPRINT> <TYPE> [<IMAGE\-NAME> <PROVIDER> <PROFILE> | <IMAGE\-NAME> <PROFILE.TOML>]
|
||||||
|
-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] <BLUEPRINT> <TYPE> [<IMAGE\-NAME> <PROFILE.TOML>]
|
||||||
|
-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 <UUID> [<SIZE>]
|
||||||
|
-Show the last SIZE kB of the compose log.
|
||||||
|
-.TP
|
||||||
|
-.B compose cancel <UUID>
|
||||||
|
-Cancel a running compose and delete any intermediate results.
|
||||||
|
-.TP
|
||||||
|
-.B compose delete <UUID,...>
|
||||||
|
-Delete the listed compose results.
|
||||||
|
-.TP
|
||||||
|
-.B compose info <UUID>
|
||||||
|
-Show detailed information on the compose.
|
||||||
|
-.TP
|
||||||
|
-.B compose metadata <UUID>
|
||||||
|
-Download the metadata use to create the compose to <uuid>\-metadata.tar
|
||||||
|
-.TP
|
||||||
|
-.B compose logs <UUID>
|
||||||
|
-Download the compose logs to <uuid>\-logs.tar
|
||||||
|
-.TP
|
||||||
|
-.B compose results <UUID>
|
||||||
|
-Download all of the compose results; metadata, logs, and image to <uuid>.tar
|
||||||
|
-.TP
|
||||||
|
-.B compose image <UUID>
|
||||||
|
-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 <BLUEPRINT,...>
|
||||||
|
-Display the blueprint in TOML format.
|
||||||
|
-.TP
|
||||||
|
-.B blueprints changes <BLUEPRINT,...>
|
||||||
|
-Display the changes for each blueprint.
|
||||||
|
-.TP
|
||||||
|
-.B blueprints diff <BLUEPRINT> <FROM\-COMMIT> <TO\-COMMIT>
|
||||||
|
-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 <BLUEPRINT,...>
|
||||||
|
-Save the blueprint to a file, <BLUEPRINT>.toml
|
||||||
|
-.TP
|
||||||
|
-.B blueprints delete <BLUEPRINT>
|
||||||
|
-Delete a blueprint from the server
|
||||||
|
-.TP
|
||||||
|
-.B blueprints depsolve <BLUEPRINT,...>
|
||||||
|
-Display the packages needed to install the blueprint.
|
||||||
|
-.TP
|
||||||
|
-.B blueprints push <BLUEPRINT>
|
||||||
|
-Push a blueprint TOML file to the server.
|
||||||
|
-.TP
|
||||||
|
-.B blueprints freeze <BLUEPRINT,...>
|
||||||
|
-Display the frozen blueprint\(aqs modules and packages.
|
||||||
|
-.TP
|
||||||
|
-.B blueprints freeze show <BLUEPRINT,...>
|
||||||
|
-Display the frozen blueprint in TOML format.
|
||||||
|
-.TP
|
||||||
|
-.B blueprints freeze save <BLUEPRINT,...>
|
||||||
|
-Save the frozen blueprint to a file, <blueprint\-name>.frozen.toml.
|
||||||
|
-.TP
|
||||||
|
-.B blueprints tag <BLUEPRINT>
|
||||||
|
-Tag the most recent blueprint commit as a release.
|
||||||
|
-.TP
|
||||||
|
-.B blueprints undo <BLUEPRINT> <COMMIT>
|
||||||
|
-Undo changes to a blueprint by reverting to the selected commit.
|
||||||
|
-.TP
|
||||||
|
-.B blueprints workspace <BLUEPRINT>
|
||||||
|
-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 <PROJECT,...>
|
||||||
|
-Show details about the listed projects.
|
||||||
|
-.TP
|
||||||
|
-.B sources list
|
||||||
|
-List the available sources
|
||||||
|
-.TP
|
||||||
|
-.B sources info <SOURCE\-NAME,...>
|
||||||
|
-Details about the source.
|
||||||
|
-.TP
|
||||||
|
-.B sources add <SOURCE.TOML>
|
||||||
|
-Add a package source to the server.
|
||||||
|
-.TP
|
||||||
|
-.B sources change <SOURCE.TOML>
|
||||||
|
-Change an existing source
|
||||||
|
-.TP
|
||||||
|
-.B sources delete <SOURCE\-NAME>
|
||||||
|
-Delete a package source.
|
||||||
|
-.UNINDENT
|
||||||
|
-.sp
|
||||||
|
-status show Show API server status.
|
||||||
|
-.INDENT 0.0
|
||||||
|
-.TP
|
||||||
|
-.B upload info <UPLOAD\-UUID>
|
||||||
|
-Details about an upload
|
||||||
|
-.TP
|
||||||
|
-.B upload start <BUILD\-UUID> <IMAGE\-NAME> [<PROVIDER> <PROFILE>|<PROFILE.TOML>]
|
||||||
|
-Upload a build image to the selected provider.
|
||||||
|
-.TP
|
||||||
|
-.B upload log <UPLOAD\-UUID>
|
||||||
|
-Show the upload log
|
||||||
|
-.TP
|
||||||
|
-.B upload cancel <UPLOAD\-UUID>
|
||||||
|
-Cancel an upload with that is queued or in progress
|
||||||
|
-.TP
|
||||||
|
-.B upload delete <UPLOAD\-UUID>
|
||||||
|
-Delete the upload and remove it from the build
|
||||||
|
-.TP
|
||||||
|
-.B upload reset <UPLOAD\-UUID>
|
||||||
|
-Reset the upload so that it can be tried again
|
||||||
|
-.TP
|
||||||
|
-.B providers list <PROVIDER>
|
||||||
|
-List the available providers, or list the <provider\(aqs> available profiles
|
||||||
|
-.TP
|
||||||
|
-.B providers show <PROVIDER> <PROFILE>
|
||||||
|
-show the details of a specific provider\(aqs profile
|
||||||
|
-.TP
|
||||||
|
-.B providers push <PROFILE.TOML>
|
||||||
|
-Add a new profile, or overwrite an existing one
|
||||||
|
-.TP
|
||||||
|
-.B providers save <PROVIDER> <PROFILE>
|
||||||
|
-Save the profile\(aqs details to a TOML file named <PROFILE>.toml
|
||||||
|
-.TP
|
||||||
|
-.B providers delete <PROVIDER> <PROFILE>
|
||||||
|
-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 <PROVIDER>\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 <PROFILE.TOML>\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 <UPLOAD\-UUID>\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 <UPLOAD\-UUID>\(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 <UUID> "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 <UUID> "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
|
||||||
|
|
||||||
@ -4,7 +4,7 @@
|
|||||||
|
|
||||||
Name: lorax
|
Name: lorax
|
||||||
Version: 35.1
|
Version: 35.1
|
||||||
Release: 1%{?dist}
|
Release: 2%{?dist}
|
||||||
Summary: Tool for creating the anaconda install images
|
Summary: Tool for creating the anaconda install images
|
||||||
|
|
||||||
License: GPLv2+
|
License: GPLv2+
|
||||||
@ -14,6 +14,7 @@ URL: https://github.com/weldr/lorax
|
|||||||
# git checkout -b archive-branch lorax-%%{version}-%%{release}
|
# git checkout -b archive-branch lorax-%%{version}-%%{release}
|
||||||
# tito build --tgz
|
# tito build --tgz
|
||||||
Source0: %{name}-%{version}.tar.gz
|
Source0: %{name}-%{version}.tar.gz
|
||||||
|
Patch0: 0001-docs-Remove-composer-cli.1.patch
|
||||||
|
|
||||||
BuildRequires: python3-devel
|
BuildRequires: python3-devel
|
||||||
BuildRequires: make
|
BuildRequires: make
|
||||||
@ -135,6 +136,7 @@ Lorax templates for creating the boot.iso and live isos are placed in
|
|||||||
|
|
||||||
%prep
|
%prep
|
||||||
%setup -q -n %{name}-%{version}
|
%setup -q -n %{name}-%{version}
|
||||||
|
%patch0 -p1
|
||||||
|
|
||||||
%build
|
%build
|
||||||
|
|
||||||
|
|||||||
Loading…
Reference in New Issue
Block a user