bdisk/docs/manual/user/BUILDINI.adoc

9.2 KiB
Raw Blame History

The build.ini file

This file is where you can specify some of the very basics of BDisk building. It allows you to specify/define certain variables and settings used by the build process. It uses ConfigParser for the parsing engine, and you can do some more advanced things with it than I demonstrate in the default.

Its single-level, but divided into "sections". This is unfortunately a limitation of ConfigParser, but it should be easy enough to follow.

Blank lines are ignored, as well as any lines beginning with # and ;. There are some restrictions and recommendations for some values, so be sure to note them when they occur. Variables referencing other values in the build.ini are allowed in the format of ${value} if its in the same section; otherwise, ${section:value} can be used.

Well go into more detail for each section below.

Example

[bdisk]
name = BDISK
uxname = bdisk
pname = BDisk
ver =
dev = A Developer
email = dev@domain.tld
desc = A rescue/restore live environment.
uri = https://domain.tld
root_password =
user = yes
[user]
username = ${bdisk:uxname}
name = Default user
password = $$6$$t92Uvm1ETLocDb1D$$BvI0Sa6CSXxzIKBinIaJHb1gLJWheoXp7WzdideAJN46aChFu3hKg07QaIJNk4dfIJ2ry3tEfo3FRvstKWasg/
[build]
mirror = mirror.us.leaseweb.net
mirrorproto = https
mirrorpath = /archlinux/iso/latest/
mirrorfile =
mirrorchksum = ${mirrorpath}sha1sums.txt
mirrorgpgsig =
gpgkey = 7F2D434B9741E8AC
gpgkeyserver =
gpg = no
dlpath = /var/tmp/${bdisk:uxname}
chrootdir = /var/tmp/chroots
basedir = /opt/dev/bdisk
isodir = ${dlpath}/iso
srcdir = ${dlpath}/src
prepdir = ${dlpath}/temp
archboot = ${prepdir}/${bdisk:name}
mountpt = /mnt/${bdisk:uxname}
multiarch = yes
ipxe = no
i_am_a_racecar = no
[gpg]
mygpgkey =
mygpghome =
[sync]
http = no
tftp = no
git = no
rsync = no
[http]
path = ${build:dlpath}/http
user = http
group = http
[tftp]
path = ${build:dlpath}/tftpboot
user = root
group = root
[ipxe]
iso = no
uri = https://domain.tld
ssldir = ${build:dlpath}/ssl
ssl_ca = ${ssldir}/ca.crt
ssl_cakey = ${ssldir}/ca.key
ssl_crt = ${ssldir}/main.crt
ssl_key = ${ssldir}/main.key
[rsync]
host =
user =
path =
iso = no

[bdisk]

This section controls some basic branding and information having to do with the end product.

name

This value is a "basic" name of your project. Its not really shown anywhere end-user visible, but we need a consistent name that follows some highly constrained rules:

  1. Alphanumeric only

  2. 8 characters total (or less)

  3. No whitespace

  4. ASCII only

  5. Will be converted to uppercase if it isnt already

uxname

This value is used for filenames and the like. I highly recommend it be the same as name (in lowercase) but it doesnt need to be. It also has some rules:

  1. Alphanumeric only

  2. No whitespace

  3. ASCII only

  4. Will be converted to lowercase if it isnt already

pname

This string is used for "pretty-printing" of the project name; it should be a more human-readable string.

  1. Can contain whitespace

  2. Can be mixed-case, uppercase, or lowercase

  3. ASCII only

ver

The version string. If this isnt specified, well try to guess based on the current git commit and tags in build:basedir.

  1. No whitespace

dev

The name of the developer or publisher of the ISO, be it an individual or organization. For example, if you are using BDisk to build an install CD for your distro, this would be the name of your distro. The same rules as pname apply.

  1. Can contain whitespace

  2. Can be mixed-case, uppercase, or lowercase

  3. ASCII only

email

An email address to use for git syncing messages, and/or GPG key generation.

desc

What this distribution/project is used for.

  1. Can contain whitespace

  2. Can be mixed-case, uppercase, or lowercase

  3. ASCII only

uri

What is this projects URI (website, etc.)? Alternatively, your personal site, your companys site, etc.

  1. Should be a valid URI understood by curl

root_password

The escaped, salted, hashed string to use for the root user.

Please see the section on passwords for information on this value. In the example above, the string 6t92Uvm1ETLocDb1D$$BvI0Sa6CSXxzIKBinIaJHb1gLJWheoXp7WzdideAJN46aChFu3hKg07QaIJNk4dfIJ2ry3tEfo3FRvstKWasg/ is created from the password test. I cannot stress this enough, do not use a plaintext password here nor just use a regular /etc/shadow file/crypt(3) hash here. Read the section. I promise its short.

user

Default: no

This setting specifies if we should create a regular (non-root) user in the live environment.

Note
If enabled, this user has full sudo access.
Accepts (case-insensitive) one of:

yes

no

true

false

1

0

[user]

This section of build.ini controls aspects about bdisk:user. It is only used if bdisk:user is enabled.

username

What username should the user have? Standard *nix username rules apply:

  1. ASCII only

  2. 32 characters or less

  3. Alphanumeric only

  4. Lowercase only

  5. No whitespace

  6. Cannot start with a number

name

What comment/description/real name should be used for the user? For more information on this, see the passwd(5) man page's section on GECOS.

  1. ASCII only

password

The escaped, salted, hashed string to use for the non-root user.

Please see the section on passwords for information on this value. In the example above, the string 6t92Uvm1ETLocDb1D$$BvI0Sa6CSXxzIKBinIaJHb1gLJWheoXp7WzdideAJN46aChFu3hKg07QaIJNk4dfIJ2ry3tEfo3FRvstKWasg/ is created from the password test. I cannot stress this enough, do not use a plaintext password here nor just use a regular /etc/shadow file/crypt(3) hash here. Read the section. I promise its short.

[build]

This section controls some aspects about the host and things like filesystem paths, etc.

mirror

A mirror that hosts the bootstrap tarball. It is highly recommended you use an Arch Linux bootstrap tarball as the build process is highly specialized to this (but patches/feature requests are welcome for other built distros). You can find a list of mirrors at the bottom of Archs download page.

  1. No whitespace

  2. Must be accessible remotely/via a WAN-recognized address

  3. Must be a domain/FQDN only; no paths (those come later!)

mirrorproto

What protocol should we use for the mirror?

Must be (case-insensitive) one of:

http

https

ftp

mirrorpath

What is the path to the tarball directory on the mirror?

  1. Must be a complete path (e.g. /dir1/subdir1/subdir2)

  2. No whitespace

mirrorfile

What is the filename for the tarball found in the path specified in <<code_mirrorpath_code,mirrorpath>>? If left blank, we will use the sha1 <<code_mirrorchksum_code,checksum>> file to try to guess the most recent file.

mirrorchksum

The path to a sha1 checksum file of the bootstrap tarball.

  1. No whitespace

  2. Must be the full path

  3. Dont include the mirror domain or protocol

mirrorgpgsig

[optional]
default: (no GPG checking done)
requires: gpg/gnupg
requires: gpgkey

If the bootstrap tarball file has a GPG signature, we can use it for extra checking. If its blank, GPG checking will be disabled.

If you specify just .sig (or use the default and dont specify a <<code_mirrorfile_code,mirrorfile>>), BDisk will try to guess based on the file from the sha1 <<code_mirrorchksum_code,checksum>> file. Note that this must evaluate to a full URL. (e.g. ${mirrorproto}://${mirror}${mirrorpath}somefile.sig)

gpgkey

requires: gpg/gnupg

What is a key ID that should be used to verify/validate the mirrorgpgsig?

  1. Only used if mirrorgpgsig is set

  2. Can be in "short" form (e.g. 7F2D434B9741E8AC) or "full" form (4AA4767BBC9C4B1D18AE28B77F2D434B9741E8AC), with or without the 0x prefix.

gpgkeyserver

default: blank (GNUPG-bundled keyservers)
requires: gpg/gnupg

What is a valid keyserver we should use to fetch gpgkey?

  1. Only used if mirrorgpgsig is set

  2. The default (blank) is probably fine. If you dont specify a personal GPG config, then youll most likely want to leave this blank.

  3. If set, make sure it is a valid keyserver URI (e.g. hkp://keys.gnupg.net)

gpg

Should we sign our release files? See the gpg section.

Accepts (case-insensitive) one of:

yes

no

true

false

1

0

dlpath

Where should the release files be saved? Note that many other files are created here as well.

  1. No whitespace

  2. Will be created if it doesnt exist