r00t2/bdisk
1
0
Fork 0
Code Issues Pull Requests Projects Releases Activity

i cannot believe i just wiped out an entire night's worth of work.

Browse Source
This commit is contained in:
brent s. 2018-05-20 10:14:48 -04:00
parent b2498ba98d
commit f4f131890d
55 changed files with 2371 additions and 19 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1
TODO
View File

@ -8,6 +8,7 @@
- locking
- for docs, 3.x (as of 3.10) was 2.4M.
- GUI? at least for generating config...
- Need ability to write/parse mtree specs (or a similar equivalent) for applying ownerships/permissions to overlay files

- SSL key gen:
import OpenSSL

45
bdisk/GPG.py
View File

@ -5,6 +5,51 @@ import gpg.errors

# http://files.au.adversary.org/crypto/GPGMEpythonHOWTOen.html
# https://www.gnupg.org/documentation/manuals/gpgme.pdf
# Support ECC? https://www.gnupg.org/faq/whats-new-in-2.1.html#ecc
# section 4.1, 4.2, 7.5.1, 7.5.5 in gpgme manual
# Please select what kind of key you want:
# (1) RSA and RSA (default) - 1024-4096 bits
# (2) DSA and Elgamal - 768-3072
# (3) DSA (sign only) - 768-3072
# (4) RSA (sign only) - 1024-4096
# (7) DSA (set your own capabilities) - 768-3072
# (8) RSA (set your own capabilities) - 1024-4096
# (9) ECC and ECC - (see below)
# (10) ECC (sign only) - (see below)
# (11) ECC (set your own capabilities) - (see below)
# Your selection? 9
# Please select which elliptic curve you want:
# (2) NIST P-256
# (3) NIST P-384
# (4) NIST P-521
# (5) Brainpool P-256
# (6) Brainpool P-384
# (7) Brainpool P-512
# Your selection? 10
# Please select which elliptic curve you want:
# (1) Curve 25519
# (3) NIST P-256
# (4) NIST P-384
# (5) NIST P-521
# (6) Brainpool P-256
# (7) Brainpool P-384
# (8) Brainpool P-512
# (9) secp256k1
# gpgme key creation:
#g = gpg.Context()
#mainkey = g.create_key('test key via python <test2@test.com>', algorithm = 'rsa4096', expires = False,
# #certify = True,
# certify = False,
# sign = False,
# authenticate = False,
# encrypt = False)
#key = g.get_key(mainkey.fpr, secret = True)
#subkey = g.create_subkey(key, algorithm = 'rsa4096', expires = False,
# sign = True,
# #certify = False,
# encrypt = False,
# authenticate = False)


class GPGHandler(object):
def __init__(self, gnupg_homedir = None, key_id = None, keyservers = None):

211
bdisk/confgen.py
View File

@ -153,6 +153,8 @@ class ConfGenerator(object):
self.get_iso()
self.get_ipxe()
self.get_pki()
self.get_gpg()
self.get_sync()
except KeyboardInterrupt:
exit('\n\nCaught KeyboardInterrupt; quitting...')
return()
@ -296,8 +298,6 @@ class ConfGenerator(object):
'\nWhat is YOUR name?\nName: ')).strip()
meta_items['dev']['email'] = (input('\nWhat is your email address?'
'\nemail: ')).strip()
# TODO: this always returns invalid?? and doesn't seem to trigger
# the redo
if not valid.email(meta_items['dev']['email']):
print('Invalid; skipping...')
meta_items['dev']['email'] = None
@ -598,7 +598,10 @@ class ConfGenerator(object):
build.attrib['its_full_of_stars'] = 'yes'
print('\n++ BUILD || PATHS ++')
# Thankfully, we can simplify a lot of this.
_dir_strings = {'cache': ('the caching directory (used for temporary '
_dir_strings = {'base': ('the base directory (used for files that are '
'required for basic guest environment '
'support)'),
'cache': ('the caching directory (used for temporary '
'files, temporary downloads, etc.)'),
'chroot': ('the chroot directory (where we store '
'the root filesystems that are converted '
@ -795,6 +798,208 @@ class ConfGenerator(object):
self.profile.append(pki)
return()

def get_gpg(self):
_sigchk = False
_xpaths = ['//iso/@sign', '//ipxe/@sign']
for x in _xpaths:
_x = self.profile.xpath(x)
for a in _x:
if a == 'yes':
_sigchk = True
break
if _sigchk:
break
if not _sigchk:
# An empty gpg element signifies a blank configuration.
lxml.etree.SubElement(self.profile, 'gpg')
return()
gpg = lxml.etree.Element('gpg')
print('\n++ GPG ++')
_gpg = None
while not _gpg:
print('\n++ GPG || KEY ID ++')
_gpg = (input('\nYou have specified GPG signing for one or more '
'components. If you have a key already, please '
'enter the key ID here; otherwise if left blank, '
'BDisk will generate one for you.\n'
'Key ID: ')).upper().strip()
if _gpg == '':
_gpg = 'none'
else:
if not valid.gpgkeyID(_gpg):
print('That is not a valid GPG key ID. Retrying.')
continue
gpg.attrib['keyid'] = _gpg
print('\n++ GPG || GPG HOME DIRECTORY ++')
_gpghome = None
while not _gpghome:
_gpghome = (input('\nWhat directory should be used for the GnuPG '
'home directory? If left blank, BDisk will use '
'the system default (first checking for an '
'environment variable called GNUPGHOME, and '
'then trying the built-in ~/.gnupg directory).'
'\nGPG Home Directory: '))
if _gpghome.strip() != '':
gpg.attrib['gnupghome'] == _gpghome
else:
_gpghome = 'none'
print('\n++ GPG || KEYSERVER PUSHING ++')
_gpgpublish = prompt.confirm_or_no(prompt = (
'\nWould you like to push the key to the SKS keyserver pool '
'(making it much easier for end-users to look it up)?\n'),
usage = ('{0} for yes, {1} for no...\n'))
gpg.attrib['publish'] = ('yes' if _gpgpublish else 'no')
print('\n++ GPG || PASSWORD HANDLING ++')
_gpgpass_prompt = prompt.confirm_or_no(prompt = (
'\nWould you like BDisk to prompt you for a passphrase? If not, '
'you\'ll either have to include the passphrase in plaintext in '
'the configuration (HIGHLY unrecommended) or use a blank '
'passphrase (also HIGHLY unrecommended).\n'),
usage = ('{0} for yes, {1} for no...\n'))
gpg.attrib['prompt_passphrase'] = ('yes' if _gpgpass_prompt else 'no')
_pass = None
if not _gpgpass_prompt:
while not _pass:
print('\n++ GPG || PASSPHRASE ++')
_pass = getpass.getpass((
'\nYou have specified not to use passphrase prompting for '
'GPG. As such, you will need to provide the passphrase. '
'If left blank, BDisk will assume one is not/should not '
'be set.\nPassphrase (will NOT echo back; type '
'carefully!): '))
if _pass.strip() == '':
_pass = 'none'
elif not valid.password(_pass):
print('As a safety precaution, we are refusing to use '
'this password. It should entirely consist of the '
'95 printable ASCII characters. Consult the '
'manual\'s section on passwords for more '
'information.\nLet\'s try this again, shall we?')
_pass = None
continue
else:
gpg.attrib['passphrase'] = _pass
if gpg.attrib['keyid'] == 'none':
_more_subkeys = True
while _more_subkeys:
_subkey = prompt.gpg_keygen_attribs()
subkey = lxml.etree.SubElement(gpg, 'key')
for a in _subkey['attribs']:
subkey.attrib[a] = _subkey['attribs'][a]
for e in _subkey['params']:
param = lxml.etree.SubElement(subkey, e)
param.text = _subkey['params'][e]
_more_subkeys = prompt.confirm_or_no(prompt = (
'\nDo you want to add another subkey?\n'),
usage = ('{0} for yes, {1} for no...\n'))
self.profile.append(gpg)
return()

def get_sync(self):
print('\n++ SYNC ++')
print('This section will allow you to configure REMOTE paths to copy '
'the finished products to. These are COPIES, meaning they will '
'exist in the destination paths you specified earlier but will '
'also be copied to these destinations. The difference is these '
'can be on a remote host and will be copied via rsync.')
_sync_chk = prompt.confirm_or_no(prompt = (
'\nWould you like to enable remote syncing?\n'),
usage = ('{0} for yes, {1} for no...\n'))
if not _sync_chk:
elem = lxml.etree.SubElement(self.profile, 'sync')
rsync = lxml.etree.SubElement(elem, 'rsync')
rsync.attrib['enabled'] = 'no'
return()
sync = lxml.etree.Element('sync')
_syncs = {'ipxe': ('the iPXE base'),
'tftp': ('the TFTP root'),
'iso': ('the ISO images destination'),
'gpg': ('the exported GPG public key')}
for s in _syncs:
print('\n++ SYNC || {0} ++'.format(s.upper()))
_item_sync_chk = prompt.confirm_or_no(prompt = (
'\nWould you like to sync {0}?\n'.format(_syncs[s])),
usage = ('{0} for yes, {1} for no...\n'))
elem = lxml.etree.SubElement(sync, s)
elem.attrib['enabled'] = ('yes' if _item_sync_chk else 'no')
if not _item_sync_chk:
continue
if s == 'gpg':
_choices = ['ASCII', 'binary']
_export_type = (input(
('\nWhat type of export dump would you like to use '
'for the GPG public key? (You can use the first '
'letter only as an abbreviation; the default is '
'ASCII.)\n'
'Choices:\n\n\t{0}\n\nExport type: ').format(
'\n\t'.join(_choices)
))).strip().lower()
if _export_type.startswith('a'):
_export_type == 'asc'
elif _export_type.startswith('b'):
_export_type == 'bin'
else:
print('Using the default.')
_export_type == 'asc'
elem.attrib['format'] = _export_type
_path = None
while not _path:
_path = input(
('\nWhere (remote path) would you like {0} to be synced?\n'
'Path: ').format(_syncs[s]))
if _path.strip() == '':
print('Please specify a path. Retrying...')
_path = None
continue
elem.text = _path
rsync = lxml.etree.SubElement(sync, 'rsync')
print('\n++ SYNC || RSYNC ++')
_rsync = prompt.confirm_or_no(prompt = (
'\nEnable rsync? If disabled, no syncing would be done even if '
'enabled by a specific item above.\n'),
usage = ('{0} for yes, {1} for no...\n'))
if not _rsync:
self.profile.append(sync)
return()
_host = (input(
'\nWhat host should we use for rsync?\nHost: ')
).strip().lower()
if ':' in _host:
_h = _host.split(':')
_host = _h[0]
_port = _h[1]
else:
_port = None
host = lxml.etree.SubElement(rsync, 'host')
host.text = _host
while not _port:
_port = (input(
'\nWhat port should we use? (Default: 22)\nPort: ')
).strip()
if _port == '':
_port = '22'
if not valid.integer(_port):
print('Invalid port number; try again.')
_port = None
continue
port = lxml.etree.SubElement(rsync, 'port')
port.text = _port
_user = (input(
'\nWhat user should we use for {0}?\nUser: '.format(_host)
)).strip()
while not valid.username(_user):
print('Invalid username.')
_user = (input('\nUsername: ')).strip()
user = lxml.etree.SubElement(rsync, 'user')
user.text = _user
_pubkey = input('\nWhat path should we use for the SSH private key? '
'Default: ~/.ssh/id_rsa\n'
'Key path: ')
pubkey = lxml.etree.SubElement(rsync, 'pubkey')
pubkey.text = _pubkey
self.profile.append(sync)
return()

def main():
cg = ConfGenerator()
cg.main()

5
bdisk/confparse.py
View File

@ -37,8 +37,9 @@ class Conf(object):
You can provide any combination of these
(e.g. "profile={'id': 2, 'name' = 'some_profile'}").
"""
self.raw = _detect_cfg(cfg)
self.profile = profile
#self.raw = _detect_cfg(cfg) # no longer needed; in utils
self.xml_suppl = utils.xml_supplicant(cfg, profile = profile)
self.profile = self.xml_suppl
self.xml = None
self.profile = None
# Mad props to https://stackoverflow.com/a/12728199/733214

35
docs/examples/multi_profile.xml
View File

@ -70,6 +70,7 @@
</sources>
<build its_full_of_stars="yes">
<paths>
<base>{variable%bdisk_root}/base</base>
<cache>{variable%bdisk_root}/cache</cache>
<chroot>{variable%bdisk_root}/chroots</chroot>
<overlay>{variable%bdisk_root}/overlay</overlay>
@ -134,11 +135,21 @@
</subject>
</client>
</pki>
<gpg keyid="none" gnupghome="none" publish="no" sync="yes"/>
<!-- If prompt_passphrase is "no" and passphrase attribute is not given for a gpg element, we will try to use a
blank passphrase for all operations. -->
<gpg keyid="none" gnupghome="none" publish="no" prompt_passphrase="no">
<!-- The below is only used if we are generating a key (i.e. keyid="none"). -->
<key type="rsa" keysize="4096" expire="0">
<name>{xpath%../../../../meta/dev/author/text()}</name>
<email>{xpath%../../../../meta/dev/email/text()}</email>
<comment>for {xpath%../../../../meta/names/pname/text()} [autogenerated] | {xpath%../../../../meta/uri/text()} | {xpath%../../../../meta/desc/text()}</comment>
</key>
</gpg>
<sync>
<ipxe enabled="yes" rsync="yes">/srv/http/{xpath%../../meta/names/uxname/text()}</ipxe>
<tftp enabled="yes" rsync="yes">/tftproot/{xpath%../../meta/names/uxname/text()}</tftp>
<iso enabled="yes" rsync="yes">/srv/http/isos/{xpath%../../meta/names/uxname/text()}</iso>
<ipxe enabled="yes">/srv/http/{xpath%../../meta/names/uxname/text()}</ipxe>
<tftp enabled="yes">/tftproot/{xpath%../../meta/names/uxname/text()}</tftp>
<iso enabled="yes">/srv/http/isos/{xpath%../../meta/names/uxname/text()}</iso>
<gpg enabled="yes" format="asc">/srv/http/{xpath%../../meta/names/uxname/text()}/pubkey.asc</gpg>
<rsync enabled="yes">
<user>root</user>
<host>mirror.domain.tld</host>
@ -200,6 +211,7 @@
</sources>
<build its_full_of_stars="yes">
<paths>
<base>{variable%bdisk_root}/base</base>
<cache>{variable%bdisk_root}/cache</cache>
<chroot>{variable%bdisk_root}/chroots</chroot>
<overlay>{variable%bdisk_root}/overlay</overlay>
@ -250,11 +262,18 @@
</subject>
</client>
</pki>
<gpg keyid="none" gnupghome="none" publish="no" sync="yes"/>
<gpg keyid="none" gnupghome="none" publish="no" prompt_passphrase="no">
<key type="rsa" keysize="4096" expire="0">
<name>{xpath%../../../../meta/dev/author/text()}</name>
<email>{xpath%../../../../meta/dev/email/text()}</email>
<comment>for {xpath%../../../../meta/names/pname/text()} [autogenerated] | {xpath%../../../../meta/uri/text()} | {xpath%../../../../meta/desc/text()}</comment>
</key>
</gpg>
<sync>
<ipxe enabled="yes" rsync="yes">/srv/http/{xpath%../../meta/names/uxname/text()}</ipxe>
<tftp enabled="yes" rsync="yes">/tftproot/{xpath%../../meta/names/uxname/text()}</tftp>
<iso enabled="yes" rsync="yes">/srv/http/isos/{xpath%../../meta/names/uxname/text()}</iso>
<ipxe enabled="yes">/srv/http/{xpath%../../meta/names/uxname/text()}</ipxe>
<tftp enabled="yes">/tftproot/{xpath%../../meta/names/uxname/text()}</tftp>
<iso enabled="yes">/srv/http/isos/{xpath%../../meta/names/uxname/text()}</iso>
<gpg enabled="yes" format="asc">/srv/http/{xpath%../../meta/names/uxname/text()}/pubkey.asc</gpg>
<rsync enabled="yes">
<user>root</user>
<host>mirror.domain.tld</host>

55
docs/examples/simple_profile.xml Normal file
View File

@ -0,0 +1,55 @@
<?xml version="1.0" encoding="UTF-8" ?>
<bdisk>
<profile name="simple" id="1" uuid="7b9128d2-0ba5-4302-9b3c-9951401853e5">
<meta>
<names>
<name>BDISK</name>
<uxname>BDisk</uxname>
<pname>BDisk</pname>
</names>
<desc>A rescue/restore live environment.</desc>
<dev>
<author>A. Dev Eloper</author>
<email>dev@domain.tld</email>
<website>https://domain.tld/~dev</website>
</dev>
<uri>https://domain.tld/projname</uri>
<ver>1.0.0</ver>
<max_recurse>5</max_recurse>
<regexes/>
<variables/>
</meta>
<accounts>
<rootpass hashed="no" hash_algo="sha512" salt="auto">testpassword</rootpass>
</accounts>
<sources>
<source arch="x86_64">
<mirror>http://archlinux.mirror.domain.tld</mirror>
<rootpath>/iso/latest</rootpath>
<tarball>archlinux-bootstrap-2018.05.01-x86_64.tar.gz</tarball>
<checksum/>
<sig/>
</source>
</sources>
<build its_full_of_stars="no">
<paths>
<base>/tmp/bdisk/base</base>
<cache>/tmp/bdisk/cache</cache>
<chroot>/tmp/bdisk/chroots</chroot>
<overlay>/tmp/bdisk/overlay</overlay>
<templates>/tmp/bdisk/templates</templates>
<mount>/mnt/bdisk</mount>
<distros>/tmp/bdisk/distros</distros>
<dest>/tmp/bdisk/results</dest>
<iso>/tmp/bdisk/iso_overlay</iso>
<http>/tmp/bdisk/http</http>
<tftp>/tmp/bdisk/tftp</tftp>
<pki>/tmp/bdisk/pki</pki>
</paths>
<basedistro>archlinux</basedistro>
</build>
<iso sign="no" multi_arch="no" />
<gpg/>
<sync/>
</profile>
</bdisk>

29
docs/examples/single_profile.xml
View File

@ -61,7 +61,8 @@
<mirror>http://archlinux.mirror.domain.tld</mirror>
<rootpath>/iso/latest</rootpath>
<tarball flags="regex,latest">{regex%tarball_x86_64}</tarball>
<checksum hash_algo="sha1" flags="none">sha1sums.txt</checksum>
<checksum hash_algo="sha1"
flags="none">sha1sums.txt</checksum>
<sig keys="7F2D434B9741E8AC"
keyserver="hkp://pool.sks-keyservers.net"
flags="regex,latest">{regex%sig_x86_64}</sig>
@ -70,7 +71,8 @@
<mirror>http://archlinux32.mirror.domain.tld</mirror>
<rootpath>/iso/latest</rootpath>
<tarball flags="regex,latest">{regex%tarball_i686}</tarball>
<checksum hash_algo="sha512" explicit="yes">cf83e1357eefb8bdf1542850d66d8007d620e4050b5715dc83f4a921d36ce9ce47d0d13c5d85f2b0ff8318d2877eec2f63b931bd47417a81a538327af927da3e</checksum>
<checksum hash_algo="sha512"
explicit="yes">cf83e1357eefb8bdf1542850d66d8007d620e4050b5715dc83f4a921d36ce9ce47d0d13c5d85f2b0ff8318d2877eec2f63b931bd47417a81a538327af927da3e</checksum>
<sig keys="248BF41F9BDD61D41D060AE774EDA3C6B06D0506"
keyserver="hkp://pool.sks-keyservers.net"
flags="regex,latest">{regex%sig_i686}</sig>
@ -78,6 +80,7 @@
</sources>
<build its_full_of_stars="yes">
<paths>
<base>{variable%bdisk_root}/base</base>
<cache>{variable%bdisk_root}/cache</cache>
<chroot>{variable%bdisk_root}/chroots</chroot>
<overlay>{variable%bdisk_root}/overlay</overlay>
@ -146,11 +149,25 @@
</subject>
</client>
</pki>
<gpg keyid="none" gnupghome="none" publish="no" sync="yes" />
<!-- If prompt_passphrase is "no" and passphrase attribute is not given for a gpg element, we will try to use a
blank passphrase for all operations. -->
<gpg keyid="none"
gnupghome="none"
publish="no"
prompt_passphrase="no">
<!-- The below is only used if we are generating a key (i.e. keyid="none"). -->
<key type="rsa" keysize="4096" expire="0">
<name>{xpath%../../../../meta/dev/author/text()}</name>
<email>{xpath%../../../../meta/dev/email/text()}</email>
<comment>for {xpath%../../../../meta/names/pname/text()} [autogenerated] | {xpath%../../../../meta/uri/text()} | {xpath%../../../../meta/desc/text()}</comment>
</key>
</gpg>
<sync>
<ipxe enabled="yes" rsync="yes">/srv/http/{xpath%../../meta/names/uxname/text()}</ipxe>
<tftp enabled="yes" rsync="yes">/tftproot/{xpath%../../meta/names/uxname/text()}</tftp>
<iso enabled="yes" rsync="yes">/srv/http/isos/{xpath%../../meta/names/uxname/text()}</iso>
<ipxe enabled="yes">/srv/http/{xpath%../../meta/names/uxname/text()}</ipxe>
<tftp enabled="yes">/tftproot/{xpath%../../meta/names/uxname/text()}</tftp>
<iso enabled="yes">/srv/http/isos/{xpath%../../meta/names/uxname/text()}</iso>
<gpg enabled="yes"
format="asc">/srv/http/{xpath%../../meta/names/uxname/text()}/pubkey.asc</gpg>
<rsync enabled="yes">
<user>root</user>
<host>mirror.domain.tld</host>

6
docs/manual/BODY.adoc Normal file
View File

@ -0,0 +1,6 @@
include::USER.adoc[]
include::DEV.adoc[]
include::BOOT.adoc[]
include::FURTHER.adoc[]
include::FAQ.adoc[]
//include::FOOT.adoc[]

5
docs/manual/BOOT.adoc Normal file
View File

@ -0,0 +1,5 @@
= Netboot

It's possible to netboot my personal build of BDisk (or any environment built with BDisk, but this serves as an example for your own setup). I mostly keep this up for emergencies in case I need it, but it's good to show you that yes, you can boot a 2GB+ squashed and compressed filesystem from a <50MB image file.

include::netboot/HOWTO.adoc[]

5
docs/manual/DEV.adoc Normal file
View File

@ -0,0 +1,5 @@
= Developer Manual

BDisk can be sourced for other projects, as it's written in a modular manner. Version 4.x aims to be installable as a standard Python module. This developer manual intends to provide information you may need to change parts of BDisk (or change how it behaves) -- it *is* opensource, after all!

include::dev/FUNCTIONS.adoc[]

5
docs/manual/FAQ.adoc Normal file
View File

@ -0,0 +1,5 @@
= FAQ

Here you will find some answers to Frequently Asked Questions I've received about this project. Please be sure to check this list before <<FURTHER.adoc#_bug_reports_feature_requests, opening a bug report>> or sending a patch!

include::faq/INDEX.adoc[]

8
docs/manual/FOOT.adoc Normal file
View File

@ -0,0 +1,8 @@
//[appendix]
//= User Manual
//[appendix]
//= Developer Manual
//[appendix]
//= Netboot
//[appendix]
//= Bug Reports/Feature Requests

8
docs/manual/FURTHER.adoc Normal file
View File

@ -0,0 +1,8 @@
= Further Reading/Resources

Here you will find further info, other resources, and such relating to BDisk.

include::further/PASSWORDS.adoc[]
include::further/BUGS.adoc[]
include::further/CONTACT.adoc[]

51
docs/manual/HEAD.adoc Normal file
View File

@ -0,0 +1,51 @@
= BDisk User and Developer Manual
Brent Saner <bts@square-r00t.net>
v2.0, 2018-05
:doctype: book
:data-uri:
:imagesdir: images
:sectlinks:
:toc: preamble
:toc2: left
:idprefix:
:sectnums:
:toclevels: 2
// So there's currently a "bug" in that the TOC will display with continued numbering across parts.
// I essentially want the opposite of https://github.com/asciidoctor/asciidoctor/issues/979 TODO

[dedication]
= Thanks
See CREDITS in the project source for a list of thanks.


[preface]
= Preface
=== About the Author
I am a GNU/Linux Systems/Network Administrator/Engineer- I wear a lot of hats. I have a lot of side projects to keep me busy when I’m not working at _${dayjob}_, mostly to assist in other side projects and become more efficient and proficient at those tasks. “Shaving the yak,” footnote:[See http://catb.org/jargon/html/Y/yak-shaving.html] indeed.

A lot of research went into how low-level boot operations take place when writing BDisk, both in BIOS and UEFI footnote:[*Unified Extensible Firmware Interface.* UEFI is not BIOS, and BIOS is not UEFI.] (and corresponding concepts such as Secureboot, etc.) which is no easy task to understand and very commonly misunderstood. (For instance, a common misconception is that UEFI necessarily implies Secureboot. This is quite far from the truth and UEFI by itself is quite a useful replacement for BIOS). I invite you to do research into the specifications yourself; it's rather fascinating.


=== What is BDisk?
BDisk refers to both a live distribution I use in my own uses (for rescue situations, recovery, etc.) but foremost and most importantly, it also refers to the tool I use for building that distribution. In other words, it's both a complete GNU/Linux distribution you can run entirely from USB/CD/DVD/etc. (without needing to install it to your hard drive)... and also the name of a tool to create a custom GNU/Linux install. The latter is what this project and documentation refer to when the word “BDisk” is used.

This documentation was started when I rewrote BDisk in Python 3.x; versions 0.x-2.x of BDisk were written in Bash, and horribly inelegant and rigid. It was a valiant effort, and *mostly* worked. Until it stopped working. To my knowledge, it is (or was) in use by https://ninjaos.org[NinjaOS^] as well as a project for education purposes in Indonesia, though I imagine it's in use other places as well. Ideally it should help those wishing to offer specialized GNU/Linux live media or install CDs.

Version 4.x is an entire rewrite to be much more modular and implement a much more flexible structure based on feature requests that have accumulated over time. footnote:[I should take the time to note that I am still quite new to Python so expect there to be plenty of optimizations to be made and general WTF-ery from seasoned Python developers. If you encounter any bugs or improvements, please <<FURTHER.adoc#_bug_reports_feature_requests,report them>>! It'd be much appreciated.]

One of my main goals was to make BDisk as easy to use as possible. This is surprisingly hard to do- it’s quite challenging to try to approach software you’ve written with the mindset of someone other than you.

It’s my hope that by releasing this utility (and documenting it), you can use it and save some time for yourself as well (and hopefully get the chance to learn a bit more in the process!).

It of course is not the <<i_don_t_like_bdisk_are_there_any_other_alternatives,only live media creator>> out there, but most others only focus on remastering an existing ISO, or creating an installer ISO -- not creating a custom live-centric environment.

=== Copyright/Licensing
The BDisk code is https://www.gnu.org/licenses/gpl-3.0.en.html[GPLv3-licensed^]. This means that you can use it for business reasons, personal reasons, modify it, etc. Please be sure to familiarize yourself with the full set of terms. You can find the full license in `docs/LICENSE`.

image::https://www.gnu.org/graphics/gplv3-127x51.png[GPLv3,align="center"]

This document, and all other associated author-generated documentation, are released under the http://creativecommons.org/licenses/by-sa/4.0/[Creative Commons CC-BY-SA 4.0^] copyright. It's essentially the GPL for non-software, so similar terms apply.

image::https://i.creativecommons.org/l/by-sa/4.0/88x31.png[CC-BY-SA_4.0,align="center"]

include::BODY.adoc[]

10
docs/manual/TODO Normal file
View File

@ -0,0 +1,10 @@
- dev/{FUNCTIONS.adoc,functions/}
need to update with new subpackages/functions etc.

- script macOS tool for imaging to USB?

- in faq/LONGTIME.adoc, in ==== Configuring the local mirror and ==== Configuring BDisk, mirrorlist should be part of the archlinux plugin - NOT a distributed hardcoded file. (can we then get rid of <paths><base> entirely?)

- in faq/ISOBIG.adoc and the doc section it references, make sure we reference that the package lists are now in the environment plugin!

- change all references to build.ini to something like "BDisk configuration file"

22
docs/manual/USER.adoc Normal file
View File

@ -0,0 +1,22 @@
= User Manual

BDisk was ultimately designed to make your life easier. "Why would I possibly need yet another LiveCD/LiveUSB?" Well, that's sort of the point- by customizing a live distribution of GNU/Linux to _your_ particular needs/desires/whimsy, you can do away with the multiple other images you keep around. It's designed to let you create a fully customized distribution/live environment.

Using BDisk, you can:

* Install GNU/Linux (https://wiki.archlinux.org/index.php/installation_guide[Arch^], https://watchmysys.com/blog/2015/02/installing-centos-7-with-a-chroot/[CentOS^], https://www.debian.org/releases/stable/amd64/apds03.html.en[Debian^], https://wiki.gentoo.org/wiki/Handbook:AMD64#Installing_Gentoo[Gentoo^], https://help.ubuntu.com/lts/installation-guide/powerpc/apds04.html[Ubuntu^]...). BDisk's flagship and guaranteed guest distro may be Arch-based, but many if not most other distros offer ways to install from any GNU/Linux live distribution. Plus, with the 4.x rewrite, it is possible to add support for any modern GNU/Linux guest distro.
** This means one could easily create an http://aif.square-r00t.net/[automated Arch install ISO^], or Gentoo installer, etc.
* Perform disk maintenance (https://raid.wiki.kernel.org/index.php/RAID_setup[mdadm^], fdisk / http://www.rodsbooks.com/gdisk/[gdisk^], http://gparted.org/[gparted^], https://www.thomas-krenn.com/en/wiki/StorCLI[storcli^], etc.). Need to replace that disk in your RAID and you don't have hotswap? Not a problem!
* Rescue, recover, wipe (http://www.sleuthkit.org/sleuthkit/[scalpel^], http://www.andybev.com/index.php/Nwipe[nwipe^], http://foremost.sourceforge.net/[foremost^], etc.). Chances are this is why you booted a live distro in the first place, yes?
* Boot over the Internet (or LAN). Burning a new image to CD/DVD/USB is a pain. BDisk has built-in support for http://ipxe.org/[iPXE^] (and traditional PXE setups). Update the filesystem image once, deploy it everywhere.
* And much, much more.
** Seriously.

This manual will give you the information you need to build your very own live GNU/Linux distribution.

include::user/GETTING_STARTED.adoc[]
include::user/IMPORTANT_CONCEPTS.adoc[]
include::user/PROJECT_LAYOUT.adoc[]
include::user/BUILDINI.adoc[]
include::user/ADVANCED.adoc[]
include::user/BUILDING.adoc[]

24
docs/manual/dev/FUNCTIONS.adoc Normal file
View File

@ -0,0 +1,24 @@
== Layout of BDisk functions
These functions exist in <<_bdisk_,`bdisk/`>>.

include::functions/BCHROOT.adoc[]

=== `bdisk.py`
This file is a sort of "wrapper" -- it pulls all the other files in this directory together into a single usable Python script. In other words, to build a BDisk distribution, you would simply run `bdisk/bdisk.py` -- that's it! See <<building_a_bdisk_iso>>.

It contains no functions, it just contains minimal logic to tie all the other functions together.

include::functions/BGPG.adoc[]

include::functions/BSSL.adoc[]

include::functions/BSYNC.adoc[]

include::functions/BUILD.adoc[]

include::functions/HOST.adoc[]

include::functions/IPXE.adoc[]

include::functions/PREP.adoc[]

29
docs/manual/dev/functions/BCHROOT.adoc Normal file
View File

@ -0,0 +1,29 @@
=== `bchroot.py`
This file controls creation of the chroots -- the directories in which BDisk builds the actual system that is booted into.

==== chroot(_chrootdir_, _chroot_hostname_, _cmd_ = '`/root/pre-build.sh`')
This function manages mounting the mountpoints for the chroot(s) in preparation for the images of the live media. It also runs <<changing_the_build_process,the inner chroot preparation script>>. Returns `chrootdir` (same as the paramater provided).

===== chrootdir
The directory where the filesystem tree for the chroot lies. Absolute path only.

===== chroot_hostname
The hostname to use for the guest.

NOTE: This paramater may be removed in future versions.

===== cmd
The command to run inside the chroot once all the mountpoints are set up.

==== chrootUnmount(_chrootdir_)
Unmount the mounts set up in <<chroot_em_chrootdir_em_em_chroot_hostname_em_em_cmd_em_root_pre_build_sh,chroot()>>.

===== chrootdir
See <<chrootdir>>.

==== chrootTrim(_build_)
This function performs some cleanup and optimizations to the chroot(s).

===== build
A dictionary of <<code_build_code>>'s values (with some additional keys/values added). See <<parseconfig_em_confs_em,parseConfig()>>.

41
docs/manual/dev/functions/BGPG.adoc Normal file
View File

@ -0,0 +1,41 @@
=== `bGPG.py`
This contains functions having to do with GPG -- signing files, verifying other signatures, generating a key (if one wasn't specified), using a key (if one was specified), etc.

==== genGPG(_conf_)
This function controls generating (or "importing" an existing) GnuPG key for use with other operations. Returns `gpg`, a <<optional,PyGPGME>> object.

===== conf
A dictionary of the <<the_code_build_ini_code_file,configuration>> (with some additional keys/values added). See (TODO: link to host.py's config parser).

==== killStaleAgent(_conf_)
This function kills off any stale GnuPG agents running. Not doing so can cause some strange behaviour both during the build process and on the host.

===== conf
See <<conf>>.

==== signIMG(_path_, _conf_)
This function signs a given file with the keys BDisk was either configured to use or automatically generated.

===== path
The full, absolute path to the file to be signed. An https://www.gnupg.org/gph/en/manual/r1290.html[ASCII-armored^] https://www.gnupg.org/gph/en/manual/x135.html[detached^] signature (plaintext) will be generated at `_path_.asc`, and a binary detached signature will be generated at `_path_.sig`.

===== conf
See <<conf>>.

==== gpgVerify(_sigfile_, _datafile_, _conf_)
This function verifies a detatched signature against a file containing data. Returns *True* if the file verifies, or *False* if not.

===== sigfile
The detached signature file. Can be ASCII-armored or binary format. Full/absolute path only.

===== datafile
The file containing the data to be verified. Full/absolute path only.

===== conf
See <<conf>>.

==== delTempKeys(_conf_)
Delete automatically-generated keys (if we generated them) as well as the automatically imported verification key (<<code_gpgkey_code>>).

===== conf
See <<conf>>.

64
docs/manual/dev/functions/BSSL.adoc Normal file
View File

@ -0,0 +1,64 @@
=== `bSSL.py`
Functions having to do with OpenSSL are stored here. This is used primarily for "mini" builds (via iPXE), they let you boot your BDisk distribution over the Internet. If an SSL key, CA certificate, etc. weren't defined and you want to build a mini image, this file contains functions that will build an SSL PKI (public key infrastructure) for you automatically.

==== verifyCert(_cert_, _key_, _CA_ = None)
This function will verify a certificate's validity/pairing with a key, optionally against a given CA certificate. Returns *True* on successful verification, or *False* and an exit (for sanity purposes).

===== cert
The certificate to be validated. Must be a PyOpenSSL certificate object.

===== key
The key to validate against <<cert>>. Must be a PyOpenSSL key object.

===== CA
The CA, or certificate authority, certificate to verify against.

NOTE: This currently does not work, as PyOpenSSL does not currently support verifying against a specified CA certificate.

==== sslCAKey(_conf_)
This function imports a CA key (<<code_ssl_cakey_code>>) into a PyOpenSSL object (or generates one if necessary). Returns a PyOpenSSL key object.

===== conf
See <<conf>>.

==== sslCA(_conf_, _key_ = None)
This function imports a CA certificate (<<code_ssl_ca_code>>) into a PyOpenSSL object (or generates one if necessary). Returns a PyOpenSSL certificate object.

===== conf
See <<conf>>.

===== key
A PyOpenSSL key object that should be used to generate the CA certificate (or is paired to the CA certificate if specified).

==== sslCKey(_conf_)
This function imports a client key (<<code_ssl_key_code>>) into a PyOpenSSL object (or generates one if necessary). Returns a PyOpenSSL key object.

===== conf
See <<conf>>.

==== ssslCSR(_conf_, _key_ = None)
This function generates a CSR (certificate signing request).

===== conf
See <<conf>>.

===== key
A PyOpenSSL key object that should be used to generate the CSR. It should be a key that is paired to the client certificate.

==== sslSign(_conf_, _ca_, _key_, _csr_)
This function signs a CSR using a specified CA.

===== conf
See <<conf>>.

===== ca
A PyOpenSSL certificate object for the CA certificate. This certificate (object) should have signing capabilities.

===== key
A PyOpenSSL key object paired to <<ca_2>>.

===== csr
A PyOpenSSL CSR object. See <<ssslcsr_em_conf_em_em_key_em_none,sslCSR()>>.

==== sslPKI(_conf_)
Ties all the above together into one convenient function. Returns a PyOpenSSL certificate object of the signed client certificate.

26
docs/manual/dev/functions/BSYNC.adoc Normal file
View File

@ -0,0 +1,26 @@
=== `bsync.py`
This file has functions relating to copying your BDisk build to various resources. For instance, if you want your ISO available to download then this file would be used to copy your finished build to an HTTP server/root you specify.

==== http(_conf_)
This function prepares a *local* HTTP directory, or webroot. See <<code_http_code_2>>.

===== conf
See <<conf>>.

==== tftp(_conf_)
This function prepares a *local* TFTP directory (for traditional PXE). See <<code_tftp_code_2>>.

===== conf
See <<conf>>.

==== git(_conf_)
This function commits (and pushes) any changes you might have made to your project (<<code_basedir_code>>) automatically.

===== conf
See <<conf>>.

==== rsync(_conf_)
This function syncs your builds, HTTP directory (if enabled), TFTP directory (if enabled), etc. to a remote host. See <<code_rsync_code_2>>.

===== conf
See <<conf>>.

43
docs/manual/dev/functions/BUILD.adoc Normal file
View File

@ -0,0 +1,43 @@
=== `build.py`
This is responsible for building the "full" ISO, building UEFI support, etc.

==== genImg(_conf_)
This function builds the http://tldp.org/HOWTO/SquashFS-HOWTO/creatingandusing.html[squashed filesystem^] images and, <<code_gpg_code,if requested>>, signs them.

===== conf
See <<conf>>.

==== genUEFI(_build_, _bdisk_)
This function builds UEFI support for the ISO files. Returns the path of an embedded EFI bootable binary/ESP image.

===== build
The <<code_build_code,build section>> of the configuration.

===== bdisk
The <<code_bdisk_code,bdisk section>> of the configuration.

==== genISO(_conf_)
Builds the full ISO image(s). Returns a dictionary of information about the built ISO file (see <<iso>>).

===== conf
See <<conf>>.

==== displayStats(_iso_)
Parses the output of e.g. <<geniso_em_conf_em,genISO()>> and displays in a summary useful to the end-user.

===== iso
A dictionary of information about the ISO file. This is typically:

{'iso':
{'name':<'Main' for the full ISO, 'Mini' for the mini ISO, etc.>},
{<name>:
'sha':<SHA256 sum of ISO file>,
'file':<full/absolute path to ISO file>,
'size':<size, in "humanized" format (e.g. #GB, #MB, etc.)>,
'type':<Full or Mini>,
'fmt':<human readable ISO type. e.g. Hybrid for an image that can be burned directly to a disk via dd or burned to optical media>
}
}

==== cleanUp()
Currently a no-op; this function is reserved for future usage to cleanup the build process automatically.

42
docs/manual/dev/functions/HOST.adoc Normal file
View File

@ -0,0 +1,42 @@
=== `host.py`
These functions are used to perform "meta" tasks such as get information about the build host, find <<the_code_build_ini_code_file,the `build.ini` file>>, and parse your configuration options.

==== getOS()
Returns the distribution of the build host.

==== getBits()
Returns the "bitness" of the build host (e.g. `32bit` or `64bit`)

==== getHostname()
Returns the hostname of the build host.

==== getConfig(_conf_file_ = '/etc/bdisk/build.ini')
Returns a list of:

. the default configuration file
. the user-specified configuration file

===== conf_file
This is a full/absolute path that is searched first. If it exists and is a file, it is assumed to be the "canonical" <<the_code_build_ini_code_file,`build.ini` file>>.

==== parseConfig(_confs_)
This function parses the configuration file(s) and returns a list of:

. A ConfigParser object
. The configuration as a dictionary

It performs some additional things, such as:

* Converts "boolean" operations to true Python booleans
* Tries to automatically detect the version if one isn't provided
* Establishes the build number (this is a number that should be local to the build host)
* Forms a list of the <<code_multiarch_code,architectures>> to build
* Validates:
** The bootstrap tarball mirror
** The rsync destination (if <<code_rsync_code,enabled>>)
** The iPXE remote URI (if <<code_ipxe_code,enabled>>)
** That <<code_basedir_code>> is correctly set
* Makes prerequisite directories

===== confs
A list of configuration files. See <<getconfig_em_conf_file_em_etc_bdisk_build_ini,getConfig()>>.

22
docs/manual/dev/functions/IPXE.adoc Normal file
View File

@ -0,0 +1,22 @@
=== `ipxe.py`
This file handles building the "mini" ISO via iPXE.

==== buildIPXE(_conf_)
This function builds the iPXE core files.

===== conf
See <<conf>>.

==== genISO(_conf_)
This function builds the mini ISO (if <<code_iso_code,enabled>>). Returns a dictionary of information about the built ISO file (see <<iso>>).

===== conf
See <<conf>>.

==== tftpbootEnv(_conf_)
This function configures a TFTP boot/root directory for traditional PXE setups.

NOTE: This function currently is a no-op; it will be implemented in future versions.

===== conf
See <<conf>>.

52
docs/manual/dev/functions/PREP.adoc Normal file
View File

@ -0,0 +1,52 @@
=== `prep.py`
This contains functions that download the base tarball releases, preps them for <<code_bchroot_py_code>>, builds necessary directory structures, and performs the overlay preparations.

==== dirChk(_conf_)
This function creates extra directories if needed.

===== conf
See <<conf>>.

==== downloadTarball(_conf_)
This function downloads the tarball (<<code_mirrorfile_code>>) from the <<code_mirror_code>>, and performs verifications (SHA1 and GPG signature <<code_mirrorgpgsig_code,if enabled>>). Returns the full/absolute path to the downloaded tarball.

===== conf
See <<conf>>.

==== unpackTarball(_tarball_path_, _build_, _keep_ = False)
This function extracts the tarball downloaded via <<downloadtarball_em_conf_em,downloadTarball()>>.

===== tarball_path
The full/absolute path to the downloaded tarball.

===== build
See <<build>>.

===== keep
`True` or `False`. Whether we should keep the downloaded tarball after unpacking/extracting. If your upstream tarball changes often enough, it's recommended to set this to `False`. However, setting it to `True` can speed up the build process if you're on a slower Internet connection.

==== buildChroot(_conf_, _keep_ = False)
This incorporates <<downloadtarball_em_conf_em,donwloading>> and <<unpacktarball_em_tarball_path_em_em_build_em_em_keep_em_false,extracting>> into one function, as well as applying the <<pre_build_d>> directory (and the <<pre_build_d_2,pre-build.d templates>>).

===== conf
See <<conf>>.

===== keep
See <<keep>>.

==== prepChroot(_conf_)
Returns a modified/updated <<build>>. This function:

. Prepares some variables that <<changing_the_build_process,pre-build.sh>> needs inside the chroot(s)
. Builds <<version_info_txt_j2,the VERSION_INFO.txt file>>
. Updates the build number
. Imports the <<code_mygpgkey_code,signing GPG key>>

===== conf
See <<conf>>.

==== postChroot(_conf_)
This function applies the <<overlay_2>> directory (and the <<overlay,overlay templates>>).

===== conf
See <<conf>>.

83
docs/manual/faq/ALTERNATIVES.adoc Normal file
View File

@ -0,0 +1,83 @@
== I don't like BDisk. Are there any other alternatives?
First, I'm sorry to hear that BDisk doesn't suit your needs. If you want any features you think are missing or encounter any <<FURTHER.adoc#bug_reports_feature_requests, bugs>>, please report them!

But yes; there are plenty of alternatives! I encourage you to search for yourself, but I've tried to be as impartial as I can for the below.

NOTE: Only *currently maintained projects* are listed here.

=== https://wiki.archlinux.org/index.php/archboot[Archboot^]
Written in Bash
[frame="topbot",options="header,footer"]
|======================
|Pros|Cons
|Highly featureful|Arch-only live media
|Includes an assisted Arch install script|Inaccessible to non-Arch users
|Can create tarballs too|Not very customizable by default
|Supports hybrid ISOs|Infrequent stable releases
|Supports PXE-booting infrastructure|Requires a systemd build host
|Supports SecureBoot|Not a secure setup by default
|Supports GRUB2's "ISO-loopback" mode|Builds a much larger image
|Official Arch project|Some graphical bugs
||Much more disk space is necessary for the tool itself
||*Only* runs in RAM, so not ideal for RAM-constrained systems
||Based on/requires an Arch build host
||Requires an x86_64 build host
||Has a large amount of dependencies
||Manual intervention required for build process
||Minimal documentation
||
|======================

=== https://wiki.archlinux.org/index.php/archiso[Archiso^]
Written in Bash.
[frame="topbot",options="header,footer"]
|======================
|Pros|Cons
|Used to build the official Arch ISO|Requires an x86_64 build host
|Supports custom local on-disk repositories|Not very featureful as far as customization goes
|Supports arbitrary file placement in finished image|Requires an Arch build host
|Supports hybrid ISOs|Has odd quirks with package selection
|Supports Secureboot|Manual intervention required for build process
|Official Arch project|Does not start networking by default
|Can run in RAM or from media|Very minimal environment
||Arch-only live meda
||Documentation is lacking
||
|======================

=== Debian's https://wiki.debian.org/Simple-CDD[Simple-CDD^]
Written in Bash (some Python).
[frame="topbot",options="header,footer"]
|======================
|Pros|Cons
|Supports custom packages to be installed|Very limited -- no customization beyond package listing
|Lightweight; quick to set up|Takes a long time for preparation; requires a clone of many .deb packages first.
||Doesn't seem to work as according to https://wiki.debian.org/Simple-CDD/Howto[the documentation^]
||Documentation is sparse
||Full featureset unknown due to ISO not building on Debian Jessie (8.0)
||
|======================

=== Fedora's https://fedoraproject.org/wiki/Livemedia-creator-_How_to_create_and_use_a_Live_CD[Livemedia-creator^]
Written in Bash.
[frame="topbot",options="header,footer"]
|======================
|Pros|Cons
|Somewhat customizable|Requires manual initialization of chroot(s) via https://github.com/rpm-software-management/mock/wiki[mock^]
|Uses kickstart configurations|*Requires* a kickstart configuration in order to be useful
|Simple/easy to use|Full featureset unknown; documentation is sparse
||Limited configuration/customization
||
|======================

=== https://github.com/rhinstaller/livecd-tools[LiveCD Tools^]
Written in Python 2, some Bash.
[frame="topbot",options="header,footer"]
|======================
|Pros|Cons
|Can use kickstarts|*Requires* a kickstart configuration
|Simple/easy to use to use|Limited configuration/customization
|Automatically builds chroots|Full featureset unknown; documentation is sparse
||
|======================

3
docs/manual/faq/GETVERSION.adoc Normal file
View File

@ -0,0 +1,3 @@
== How do I get the version/build of an ISO?
This can be found in a multitude of places. The full-size ISO file should have the version right in the filename. If you want more detailed information (or perhaps you renamed the file), you can mount the ISO as loopback in GNU/Linux, *BSD, or Mac OS X/macOS and check `/path/to/mounted/iso/VERSION_INFO.txt`. Lastly, within the runtime itself (especially handy if booting via iPXE), you can check `/root/VERSION_INFO.txt` to get information about the build of the currently running live environment.

5
docs/manual/faq/INDEX.adoc Normal file
View File

@ -0,0 +1,5 @@
include::WHYARCH.adoc[]
include::LONGTIME.adoc[]
include::ISOBIG.adoc[]
include::GETVERSION.adoc[]
include::ALTERNATIVES.adoc[]

5
docs/manual/faq/ISOBIG.adoc Normal file
View File

@ -0,0 +1,5 @@
== Why is the ISO so large?
This actually entirely depends on what <<changing_the_installed_software,packages you have chosen to install>> (and if you're building a <<code_multiarch_code,multiarch ISO>>). The default list is quite large.

If you build a minimal ISO (i.e. only the necessary components required for booting and nothing else, single-arch), the ISO is only about 570MB (but work is being done to make this even smaller).

70
docs/manual/faq/LONGTIME.adoc Normal file
View File

@ -0,0 +1,70 @@
== Why does building take so long?
This typically occurs when you're building from within a LiveCD/LiveUSB situation, in a VM/container/etc., or on a headless server. If this is the case, you may run into what appears to be "stalling", especially while keys are generating for the chroots. Thankfully, there is an easy fix. You can install http://www.issihosts.com/haveged/[haveged^] and run it (this can be done safely while a build is executing). This will show an immediate and non-negligible improvement for the above contexts. If you have extra processing power to throw at the build process (or are using a dedicated build box) as well, I recommend enabling <<code_its_full_of_stars,`its_full_of_stars`>>. BDisk will then be more aggressive with its resource consumption.

=== Running a local mirror
Keep in mind also that the more packages you opt to install, the longer the build process will take. This process will also use quite a fair bit of bandwidth. If you plan on building regular images (e.g. nightly builds, etc.) or are undergoing some custom change testing, I recommend running a private repository mirror on-site. For Arch-based builds, this will not store AUR packages, as those will still be fetched and built (documentation on working around this is TODO) but setting up a local mirror is quite quick and easy. We'll of course use Arch as an example since that's the default guest environment (though I have a https://git.square-r00t.net/OpTools/tree/centos/repoclone[script^] for CentOS as well).

First, you'll need at least 90Gb of free disk space. Let's say our repository clone will be at `/srv/repo/arch/`.

You'll also need to find an Arch mirror, ideally one close to you that is up-to-date. The https://www.archlinux.org/mirrorlist/[mirrorlist generator^] and https://www.archlinux.org/mirrors/[mirror list^] will assist you here greatly.

NOTE: You'll need to find a mirror that supports _rsync_.

TIP: You can use ANY distro to run a repository mirror, as long as it has _rsync_ installed!

==== Set up the sync

I have https://git.square-r00t.net/OpTools/tree/arch/repoclone.py[written a script^] that does the heavy-lifting! https://git.square-r00t.net/OpTools/plain/arch/repoclone.py[Download it^] and mark it as executable (`chmod +x repoclone.py`). Make sure you read the --help option and edit `~/.config/optools/repoclone/arch.ini`.

Assuming you want to run the sync script every 6 hours, this is the cron entry you would use (`crontab -e`):

0 */6 * * * /path/to/repoclone.py

The first sync can take quite a while, but subsequent runs shouldn't take more than five minutes or so (depending on how many updates are available).

==== Configuring the local mirror
You'll need a way to serve this local mirror in a way pacman can understand. Luckily, it's fairly easy. I recommend using https://www.nginx.com/[nginx^] as it's available by default in many operating systems. You can of course use others such as https://www.lighttpd.net/[lighttpd^], https://httpd.apache.org/[apache/httpd^], etc. For the example configuration here, we're going to use an nginx configuration file.

```
server {
listen [::]:80;
access_log /var/log/nginx/repo.access.log main;
error_log /var/log/nginx/repo.error.log;
#error_log /var/log/nginx/repo.error.log debug;

autoindex on;

root /srv/repo/arch;
}
```

The configuration may vary according to your distribution's provided nginx default configuration, but you'll want this configuration to be served as the default (or set an appropriate `https://nginx.org/en/docs/http/server_names.html[server_name]` directive which you would then use in `<profile><build><paths><base>/etc/pacman.d/mirrorlist`).

==== Configuring BDisk

You'll then want to configure BDisk's chroots to use your local mirror first. However, if you want to use a LAN resource mirror, when doing so you run into an issue -- in the built image, install operations will take longer than they need to because the local mirror likely won't be available! This is a small issue as it's unexpected that you'll need to install software within the live environment, but I've run into cases where it was a necessity once or twice.

There is an https://devblog.square-r00t.net/articles/libvirt-spoof-domains-dns-records-redirect-to-another-ip[easy workaround^] if you're using libvirt to build -- you can simply tell your build VM to resolve to the IP address of the box that is running the mirror for the same FQDN that the "preferred" "real" mirror on the Internet and set that mirror at the top of `<profile><build><paths><base>/etc/pacman.d/mirrorlist`. However, that's not always feasible- most notably if you're building on a physical box and it's the same host as the repository clone. In that case you can set the specific local resolution -- e.g. `http://127.0.0.1/` -- at the top of `<profile><build><paths><base>/etc/pacman.d/mirrorlist` and then set a mirrorlist WITHOUT that entry in `<profile><build><paths><overlay>/etc/pacman.d/mirrorlist`. For more information on using these type of overrides, see <<advanced_customization>>.

If you're using the libvirt workaround, remember to configure nginx (or whatever you're using) with a virtual host and location block that matches the "real", upstream mirror. In our example below, we use *http://arch.mirror.square-r00t.net* as the mirror.

```
server {
listen [::]:80;
access_log /var/log/nginx/repo.access.log main;
error_log /var/log/nginx/repo.error.log;
#error_log /var/log/nginx/repo.error.log debug;

server_name arch.mirror.square-r00t.net;

autoindex on;

root /srv/repo/arch;

location /archlinux {
autoindex on;
rewrite ^/archlinux(/.*)$ /$1;
}
}
```

5
docs/manual/faq/WHYARCH.adoc Normal file
View File

@ -0,0 +1,5 @@
== Why Arch Linux as the Recommended Guest?
Because it's a very easy-to-use, simple, https://wiki.archlinux.org/[well-documented^] distro. It's no-frills and incredibly flexible/customizable, and can be made rather slim (and is out of the box, in fact). It's also very friendly to run as a chroot inside any other distro or as a chroot host to any other distro.

Plus they release monthly tarball snapshots that are fairly small and create quick bootstrap environments.

18
docs/manual/further/BUGS.adoc Normal file
View File

@ -0,0 +1,18 @@
== Bug Reports/Feature Requests
NOTE: It is possible to submit a bug or feature request without registering in my bugtracker. One of my pet peeves is needing to create an account/register on a bugtracker simply to report a bug! The following links only require an email address to file a bug (which is necessary in case I need any further clarification from you or to keep you updated on the status of the bug/feature request -- so please be sure to use a valid email address).

=== Bugs
If you encounter any bugs in *BDisk*, you can file a bug report https://bugs.square-r00t.net/index.php?do=newtask&project=2&task_type=1[here^].

If you encounter any bugs (inaccurate information, typos, misformatting, etc.) in *this documentation*, you can file a bug report https://bugs.square-r00t.net/index.php?do=newtask&project=8&task_type=1[here^].

=== Feature Requests
If you have any features you'd like to see or you think would help *BDisk* become even more useful, please file a feature request https://bugs.square-r00t.net/index.php?do=newtask&project=2&task_type=2[here^].

If you have any suggestions on how to improve *this documentation* or feel it's missing information that could be useful, please file a feature request https://bugs.square-r00t.net/index.php?do=newtask&project=8&task_type=2[here^].

=== Patches
I gladly welcome https://www.gnu.org/software/diffutils/manual/html_node/Unified-Format.html[patches^], but I deplore using GitHub (even though I https://github.com/johnnybubonic/BDisk[have a mirror there^]). For this reason, please follow the same https://www.kernel.org/doc/Documentation/SubmittingPatches[patch/pull request process^] for the Linux kernel and email it to bts@square-r00t.net.

Alternatively, you may attach a patch to a <<bugs,bug report>>/<<feature_requests,feature request>>.

10
docs/manual/further/CONTACT.adoc Normal file
View File

@ -0,0 +1,10 @@
== Contact the Author
If you have any questions, comments, or concerns, you can use the following information to get in touch with me.

I am available via mailto:bts@square-r00t.net[email]. If you use GPG, you can find my pubkey and other related info https://devblog.square-r00t.net/about/my-gpg-public-key-verification-of-identity[here^] (and on most keyservers).

I occasionally write howto articles, brief tips, and other information in my https://devblog.square-r00t.net[dev blog].

I am on IRC as *r00t^2*, and am usually in the irc://irc.freenode.org/#sysadministrivia[Sysadministrivia channel on Freenode]. Which reminds me, I run a podcast called https://sysadministrivia.com[Sysadministrivia^].

I am on Twitter as https://twitter.com/brentsaner[@brentsaner^], though I don't tweet very often. (I usually tweet from my https://twitter.com/SysAdm_Podcast[podcast's twitter^].)

95
docs/manual/further/PASSWORDS.adoc Normal file
View File

@ -0,0 +1,95 @@
== Passwords
NOTE: If you're specifying passwords, be sure to use a https://www.schneier.com/blog/archives/2014/03/choosing_secure_1.html[strong password^]!

=== `build.ini` Password Value Examples
Passwords work a little interestingly in BDisk. These aspects all apply to both <<code_root_password_code,the root password>> and <<code_password_code,the user password>> (if you enable a regular user).

CAUTION: DO *NOT* USE A PLAINTEXT PASSWORD IN THE `build.ini`! This is _by design_; plaintext passwords are much more insecure. If you use a plaintext password, it *will not work*.

WARNING: Remember to <<escaping_the_salted_hash,escape your hash>> before placing it in your `build.ini`!

.Password Value Scheme
[frame="topbot",options="header,footer"]
|======================
|If you have...|BDisk will...
|the string `BLANK`|give the user a blank password, allowing you to just hit `<Enter>` to log in
|nothing set|lock the account (e.g. no non-SSH login is possible)
|a properly hashed, salted, and escaped string|set the account to the password used to generate that hash.
||
|======================

.Password Value Examples
[frame="topbot",options="header,footer"]
|======================
|If the value is...|Then BDisk...
|`root_password = BLANK`|will let you log into the TTY as the root user by just hitting the `<Enter>` key.
|`root_password =`|will not allow the root user to log into the TTY at all.
|`root_password = <some salted, hashed, escaped string created from 'test'>`|will let you log into the root user on a TTY with the password `test`.
||
|======================


NOTE: I specify "TTY login" because SSH login may still be possible. By default, SSH will allow password logins for non-root users (root user SSH password login is prohibited by default; only pubkey login for root is allowed.) -- this can be overridden, however, by customization.

=== Generating a Password Salt/Hash
First, if you are not familiar with a http://man7.org/linux/man-pages/man3/crypt.3.html#NOTES[salted hash^] that GNU/Linux uses, you may want to learn about it.

That said, there are utilities in `extra/bin/` that should generate a salted hash for you. Currently only `hashgen.py` is distributed, but additions/examples for other languages are welcome.

....
$ ./hashgen.py
What password would you like to hash/salt?
(NOTE: will NOT echo back!)
Your salted hash is:
$6$t92Uvm1ETLocDb1D$BvI0Sa6CSXxzIKBinIaJHb1gLJWheoXp7WzdideAJN46aChFu3hKg07QaIJNk4dfIJ2ry3tEfo3FRvstKWasg/
....

The password `test` was used above. In `crypt(3)`-salted hashes, there are specific sections separated by USD dollar symbols (`$`). The first section (containing `6`) marks the *hash algorithm* -- in this case, _SHA512_. (The http://man7.org/linux/man-pages/man3/crypt.3.html#NOTES[crypt man page^] mentions all supported hash types and their corresponding ID.) The next section, `t92Uvm1ETLocDb1D`, is the *salt*. The last section is the *hash*. How salted hashes work is an original piece of data is given (in our case, the word `test`). This data is then sent through a one-way cryptographic process that generates a new string that makes it difficult to know what the original data was. THEN a salt is added- a random string- and the process repeats. In our format, this is done _5000_ times in a row. When you log in with your password, the salt is fetched and the same process is done again- predictably, the data that process goes through should then match the salted hash string stored in the password system (in this case, the https://linux.die.net/man/5/shadow[`/etc/shadow`] file).

There are other ways to generate the salted hash as well. These include:

==== Debian's `mkpasswd` Utility
Part of the https://packages.debian.org/jessie/whois[whois^] package, available in the AUR as https://aur.archlinux.org/packages/debian-whois-mkpasswd/[debian-whois-mkpasswd^].

mkpasswd --method=sha-512 <password>

==== Perl
The following Perl one-liner will generate a salted hash string (using the salt `aBcDeFgHiJ`):

perl -e 'print crypt("PASSWORD","\$6\$aBcDeFgHiJ\$") . "\n"'

==== `grub-crypt`
Legacy GRUB ("GRUB v1") includes `grub-crypt`, which will let you generate a salted hash:

/sbin/grub-crypt --sha-512

=== Escaping the Salted Hash
One last thing, and this is *very* important -- failure to perform this step will cause all sorts of strange Python errors -- is to escape the salted hash. Thankfully, however, this is a lot easier than it sounds.

So we have our salted hash: `$6$t92Uvm1ETLocDb1D$BvI0Sa6CSXxzIKBinIaJHb1gLJWheoXp7WzdideAJN46aChFu3hKg07QaIJNk4dfIJ2ry3tEfo3FRvstKWasg/`. In order to get it into a usable format, we need to make sure the configuration parsing won't try to read sections of it as variables. To do this, we do something called *escaping*.

All you need to do is take the salted hash and replace every `$` you see -- there should be exactly three -- with `$$`. That's it! Count them to be sure; you should now have *6* `$` symbols present instead of three. Once you've escaped the salted hash, you're ready to roll.

=== Cheating/The Easy Way
Feeling overwhelmed? There's an easy way to do all of this.

First, while logged into your local computer, change your password to what you want ether `root_password` or `password` to be:

passwd

NOTE: Remember, changing your password won't echo the password back on the screen for security reasons!

Then get your shadow entry. This has to be done with sudo, as only the root user has access to the hashed passwords on the system. The following command will combine all steps necessary; the string it returns will be a string you can use directly in your `build.ini`.

sudo grep "^${SUDO_USER}:" /etc/shadow | awk -F':' '{print $2}' | sed -e 's/\$/$$/'

Don't forget to change your password back to what it was before!

passwd

That's it!

BIN
docs/manual/images/fig1.1.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 270 KiB

128
docs/manual/netboot/HOWTO.adoc Normal file
View File

@ -0,0 +1,128 @@
== How to Netboot BDisk
I update this server with images and iPXE images you can use to netboot my personal spin of BDisk.

You can https://bdisk.square-r00t.net/download/bdisk-mini.iso[download] a demo of the iPXE functionality. Note that your computer needs to be connected to a valid Internet connection via ethernet and be able to get a DHCP lease for it to work.

NOTE: Advanced users, you can https://www.gnupg.org/gph/en/manual/x135.html[verify^] it against the GPG signature (https://bdisk.square-r00t.net/download/bdisk-mini.iso.asc[ASC], https://bdisk.square-r00t.net/download/bdisk-mini.iso.sig[BIN]). Please see https://square-r00t.net/gpg-info[this blog post^] for information on fetching my keys and such. Note that while this project is in flux, I may be signing with temporarily-generated throwaway keys.

Once downloaded, you can follow the appropriate steps based on your operating system:

=== Windows
==== CD/DVD
Simply put a blank CD/DVD-R (or RW, RW+, etc.) in your optical media drive. Find where you downloaded the above file (it should be named `bdisk-mini.iso`). Right-click and select *Burn disc image*.

==== USB
You'll most likely want to https://svwh.dl.sourceforge.net/project/usbwriter/USBWriter-1.3.zip[download] a program called https://sourceforge.net/projects/usbwriter/[USBWriter^]. Unzip it (or just open it via double-clicking) and copy the `USBWriter.exe` program somewhere you'll remember- your desktop, for instance.

Next, make sure your USB thumbdrive is inserted in your computer and https://support.microsoft.com/en-us/help/17418/windows-7-create-format-hard-disk-partition[formatted/"initialized"^] already.

WARNING: Formatting a disk/partition will *destroy* any and all data on that device! Make sure there is nothing on your USB drive you want to keep, as formatting BDisk to it *will* delete any data on it.

Now right-click on the USBWriter icon and select *Run as administrator*. You may get a warning pop up asking for permissions for USBWriter. It's safe to click Yes.

Select the proper USB flash drive from the *Target device* dropdown menu. If your USB drive isn't showing up, try clicking the Refresh button and looking again. (If it still doesn't show up, you may need to reboot your computer.)

Click the *Browse...* button and find where you saved `bdisk-mini.iso`. Once you've found it, double-click it. Then click *Write*. It might take a little bit of time depending on how fast your USB interface is, so give it some time. When it finishes, click *Close*. You now have a bootable USB thumbdrive.

==== Booting
Booting differs depending on each and every hardware, but *typically* you should get a message when you first start up for "_Setup_" and/or "_Boot options_" or the like. The terminology differs here. It will probably be an *F__#__* button (usually `F2`, `F4`, `F10`, or `F12`) or the *Delete* key. While rebooting, try to hold or press repeatedly this key and you should come across an option somewhere with a list of devices to boot from or an order you can set. Make sure the USB (or CD/DVD, whichever media type you're using) is set as first, and save.

=== Mac OS X/macOS
==== CD/DVD
Unfortunately, the OS X/macOS Disk Utility doesn't work with hybrid ISOs (what `bdisk-mini.iso` is). At all. You're out of luck, I'm afraid, unless you happen have a spare USB thumbdrive handy.

==== USB
We'll need to get a little messy with this one.

Open Applications => Utilities => Terminal. A black box should pop up.

Insert your USB thumbdrive now (if you haven't already) and run the following command:

diskutil list

You should see an entry, probably near the bottom, that looks something like this:

(...)
/dev/disk42 (external, physical):
#: TYPE NAME SIZE IDENTIFIER
0: *8.2 GB disk42
(...)

CAUTION: *Be sure* to find the disk that matches the size of your thumbdrive! If you use the wrong disk identifier, it will break your OS X/macOS install at best and delete all your data at worst!

Now that you've found which disk your USB device is (the `/dev/disk__#__` part), we can continue. Make sure that it is the disk ID *right above* the line that contains your flash drive size! For our example, I will use `/dev/disk__42__` as an example as it's highly unlikely you'll have that many disk IDs, but be sure to replace this in the following commands with the proper disk ID you found above.

Then we need to unmount the disk, in case it's already mounted.

diskutil unmountDisk /dev/disk42

Assuming you saved BDisk Mini to your Desktop, you can do:

sudo dd if=~/Desktop/bdisk-mini.iso of=/dev/disk42

NOTE: The above command may prompt you for a password. This is the same password you use to log into your Mac (and unlock the screensaver, etc.). No characters will show up when you type (for security reasons, in case someone is behind you watching your screen) so it may take you a couple tries.

This will run for a couple seconds. When it finishes, you should see something similar to (but not necessarily the same numbers as) this:

0+1 records in
0+1 records out
169 bytes transferred in 0.000530 secs (318865 bytes/sec)

At this point you _may_ get a popup warning you _"The disk you inserted was not readable by this computer."_ If you do, just click the *Ignore* button.

One last step. Still in Terminal:

diskutil eject /dev/disk42

You can then close Terminal.

==== Booting
The instructions here don't differ too much than from Windows, though it's always the same key. From it being in a shutdown state, power on your Macbook Pro (or whatever it is you have) and hold the *Option* key (or the *Alt* key on non-Apple keyboards). The *Option/Alt* key should bring up a boot menu that will let you select a USB device to boot from.

Strangely enough, you should still be able to _boot_ a BDisk Mini CD/DVD, you just can't *burn* one. I'm tempted to make a cheap dig at Apple, but I'll refrain.

=== GNU/Linux
==== CD/DVD
Easy. Most (if not all) of https://wiki.archlinux.org/index.php/Optical_disc_drive#Burning[these^] should support burning `bdisk-mini.iso` to disc (I'm partial to _cdrecord_). If you prefer a GUI, try some of https://wiki.archlinux.org/index.php/Optical_disc_drive#Burning_CD.2FDVD.2FBD_with_a_GUI[these^] instead (I like _k3b_).

==== USB
Very similar to OS X/macOS in approach. First open a terminal emulator- the ways of navigating to it depends on your window manager/desktop environment, but it's usually under a System or Utilities menu.

Now we need to find which disk our USB thumbdrive is. Insert your USB thumbdrive now, if you haven't already, and run in the terminal:

sudo fdisk -l

You should see a device matching your USB thumbdrive's size. In our example, I use */dev/sdz* as it's unlikely you have that many disks attached to a system, but be sure to replace this in the following commands with the proper disk ID you find.

(...)
Disk /dev/sdz: 7.6 GiB, 8178892800 bytes, 15974400 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
(...)

CAUTION: *Be sure* to find the disk that matches the size of your thumbdrive! If you use the wrong disk identifier, it will break your GNU/Linux install (or possibly Windows install if you're dual-booting, etc.) at best and delete all your data at worst!

Make sure it isn't mounted:

umount /dev/sdz

You should get a message that says `umount: /dev/sdz: not mounted`. If it was mounted before, it's unmounted now.

Next, simply dd over the ISO file.

sudo dd if=~/Desktop/bdisk-mini.iso of=/dev/sdz

NOTE: The above command may prompt you for a password. This is the same password you use to log in (and unlock the screensaver, etc.). No characters will show up when you type (for security reasons, in case someone is behind you watching your screen) so it may take you a couple tries.

This will run for a couple seconds. When it finishes, you should see something similar to (but not necessarily the same numbers as) this:

75776+0 records in
75776+0 records out
38797312 bytes (39 MB, 37 MiB) copied, 9.01915 s, 4.3 MB/s

If you get a popup from your desktop environment (assuming you're using one) about not being able to mount a disk, or that it's unformatted, etc. and it prompts you to format, ignore/cancel/close it- do *not* format it! This would erase the BDisk Mini image on it.

==== Booting
Exactly the same as those for Windows. (Unless you're running GNU/Linux on Mac hardware, in which case follow the booting instructions for Mac instead.)

14
docs/manual/user/ADVANCED.adoc Normal file
View File

@ -0,0 +1,14 @@
== Advanced Customization
If the <<the_code_build_ini_code_file,`build.ini`>> file doesn't provide enough customization to your liking, I don't blame you! It was designed only to provide the most basic control and is primarily only used to control the build process itself.

Luckily, there are a lot of changes you can make. For all of these, you'll want to make a copy of the <<code_basedir_code,`basedir`>> directory somewhere and change the basedir configuration option in the <<the_code_build_ini_code_file,`build.ini`>> file to point to that directory.

This section isn't going to cover every single use case, as that's mostly an exercise for you -- I can't predict how you want to use BDisk! But we'll cover some common cases you can use and in the process you'll know how to implement your own customizations.

include::advanced/SSH.adoc[]
include::advanced/VPN.adoc[]
include::advanced/SOFTWARE.adoc[]
include::advanced/BUILDING.adoc[]
include::advanced/AUTOLOGIN.adoc[]
include::advanced/DESKTOP.adoc[]

13
docs/manual/user/BUILDING.adoc Normal file
View File

@ -0,0 +1,13 @@
== Building a BDisk ISO
So you finally have <<the_code_build_ini_code_file,configured>> BDisk (and perhaps added further <<advanced_customization,customizations>>. Now you're ready to build!

Building is, thankfully, the easiest part!

NOTE: Due to requiring various mounting and chrooting, BDisk must be run as the *root* user (or via _sudo_).

To initiate a build, simply run `<basedir>/bdisk/bdisk.py`. That's it! Everything should continue automatically.

If you're using a packaged version you installed from your distro's package manager, you instead should run wherever it installs to. Most likely this is going to be `/usr/sbin/bdisk`. (On systemd build hosts that have done the https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/[/usr merge^], you can use `/usr/sbin/bdisk` or `/sbin/bdisk`.)

If you encounter any issues during the process, make sure you read the documentation -- if your issue still isn't addressed, please be sure to file a <<bug_reports_feature_requests,bug report>>!

598
docs/manual/user/BUILDINI.adoc Normal file
View File

@ -0,0 +1,598 @@
== 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 https://docs.python.org/3/library/configparser.html[ConfigParser^] for the parsing engine, and you can do some https://wiki.python.org/moin/ConfigParserExamples[more advanced^] things with it than I demonstrate in the default.

It's 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 it's in the same section; otherwise, `${section:value}` can be used.

If you want to use your own `build.ini` file (and you should!), the following paths are searched in order. The first one found will be used.

* `/etc/bdisk/build.ini`
* `/usr/share/bdisk/build.ini`
* `/usr/share/bdisk/extra/build.ini`
* `/usr/share/docs/bdisk/build.ini`
* `/usr/local/etc/bdisk/build.ini`
* `/usr/local/share/docs/bdisk/build.ini`
* `/opt/dev/bdisk/build.ini`
* `/opt/dev/bdisk/extra/build.ini`
* `/opt/dev/bdisk/extra/dist.build.ini`

We'll 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. It's not really shown anywhere end-user visible, but we need a consistent name that follows some highly constrained rules:

. Alphanumeric only
. 8 characters total (or less)
. No whitespace
. ASCII only
. Will be converted to uppercase if it isn't already

==== `uxname`
This value is used for filenames and the like. I highly recommend it be the same as `<<code_name_code,name>>` (in lowercase) but it doesn't need to be. It also has some rules:

. Alphanumeric only
. No whitespace
. ASCII only
. Will be converted to lowercase if it isn't already

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

. *Can* contain whitespace
. *Can* be mixed-case, uppercase, or lowercase
. ASCII only

==== `ver`
The version string. If this isn't specified, we'll try to guess based on the current git commit and tags in `<<code_basedir_code,build:basedir>>`.

. 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 `<<code_pname_code,pname>>` apply.

. *Can* contain whitespace
. *Can* be mixed-case, uppercase, or lowercase
. 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.

. *Can* contain whitespace
. *Can* be mixed-case, uppercase, or lowercase
. ASCII only

==== `uri`
What is this project's URI (website, etc.)? Alternatively, your personal site, your company's site, etc.

. Should be a valid URI understood by curl


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

Please see <<passwords,the section on passwords>> for information on this value. In the <<example,example above>>, the string `$$6$$t92Uvm1ETLocDb1D$$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 it's short.

==== `user`
*Default: no*

This setting specifies if we should create a regular (non-root) user in the live environment. See the section <<code_user_code_2,`[user]`>> for more options.

NOTE: If enabled, this user has full sudo access.

[options="header"]
|======================
2+^|Accepts (case-insensitive) one of:
^m|yes ^m|no
^m|true ^m|false
^m|1 ^m|0
|======================

=== `[user]`
This section of `build.ini` controls aspects about `bdisk:user`. It is only used if <<code_user_code,`bdisk:user`>> is enabled.

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

. ASCII only
. 32 characters or less
. Alphanumeric only
. Lowercase only
. No whitespace
. Cannot start with a number

==== `name`
What comment/description/real name should be used for the user? For more information on this, see the https://linux.die.net/man/5/passwd[passwd(5) man page^]'s section on *GECOS*.

. ASCII only

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

Please see <<passwords,the section on passwords>> for information on this value. In the <<example,example above>>, the string `$$6$$t92Uvm1ETLocDb1D$$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 it's 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 https://wiki.archlinux.org/index.php/Install_from_existing_Linux#Method_A:_Using_the_bootstrap_image_.28recommended.29[bootstrap tarball^] as the build process is highly specialized to this (but <<bug_reports_feature_requests,patches/feature requests>> are welcome for other built distros). You can find a list of mirrors at the bottom of Arch's https://www.archlinux.org/download/[download page^].

. No whitespace
. Must be accessible remotely/via a WAN-recognized address
. Must be a domain/FQDN only; no paths (those come later!)

==== `mirrorproto`
What protocol should we use for the <<code_mirror_code,`mirror`>>?

|======================
^s|Must be (case-insensitive) one of: ^.^m|http ^.^m|https ^.^m|ftp
|======================

==== `mirrorpath`
What is the path to the tarball directory on the <<code_mirror_code,`mirror`>>?

. Must be a complete path (e.g. `/dir1/subdir1/subdir2`)
. 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.

. No whitespace
. Must be the full path
. Don't include the mirror domain or protocol

==== `mirrorgpgsig`
*[optional]* +
*default: (no GPG checking done)* +
*requires: <<optional,_gpg/gnupg_>>* +
*requires: <<code_gpgkey_code,`gpgkey`>>*

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

If you specify just `.sig` (or use the default and don't 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: <<optional,_gpg/gnupg_>>*

What is a key ID that should be used to verify/validate the <<code_mirrorgpgsig_code,`mirrorgpgsig`>>?

. Only used if <<code_mirrorgpgsig_code,`mirrorgpgsig`>> is set
. 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: <<optional,_gpg/gnupg_>>*

What is a valid keyserver we should use to fetch <<code_gpgkey_code,`gpgkey`>>?

. Only used if <<code_mirrorgpgsig_code,`mirrorgpgsig`>> is set
. The default (blank) is probably fine. If you don't specify a personal GPG config, then you'll most likely want to leave this blank.
. 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 <<code_gpg_code_2,`[gpg]`>> section.

[options="header"]
|======================
2+^|Accepts (case-insensitive) one of:
^m|yes ^m|no
^m|true ^m|false
^m|1 ^m|0
|======================

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

WARNING: If you manage your project in git, this should not be checked in as it has many large files that are automatically generated!

. No whitespace
. Will be created if it doesn't exist

==== `chrootdir`
Where the bootstrap tarball(s) extract to, where the chroots are built and prepped for filesystems on the live media.

WARNING: If you manage your project in git, this should not be checked in as it has many large files that are automatically generated!

. No whitespace
. Will be created if it doesn't exist

==== `basedir`
Where your <<extra,`extra/`>> and <<overlay,`overlay/`>> directories are located. If you checked out from git, this would be your git worktree directory.

. No whitespace
. Must exist and contain the above directories populated with necessary files

==== `isodir`
This is the output directory of ISO files when they're created (as well as GPG signatures if you <<code_gpg_code,enabled them>>).

WARNING: If you manage your project in git, this should not be checked in as it has many large files that are automatically generated!

. No whitespace
. Will be created if it doesn't exist

==== `srcdir`
This is where we save and compile source code if we need to dynamically build components (such as iPXE for mini ISOs).

. No whitespace
. Will be created if it doesn't exist (and is needed)

==== `prepdir`
This is the directory we use for staging.

. No whitespace
. Will be created if it doesn't exist

==== `archboot`
This directory is used to stage boot files.

WARNING: This directory should not be the exact same path as other directives! If so, you will cause your ISO to be much larger than necessary. A subdirectory of another directive's path, however, is okay.

. No whitespace
. Will be created if it doesn't exist

==== `mountpt`
The path to use as a mountpoint.

. No whitespace
. Will be created if it doesn't exist

==== `multiarch`
*default: yes*

Whether or not to build a "multiarch" image- that is, building support for both x86_64 and i686 in the same ISO.

[options="header"]
|======================
s|In order to... 3+^|Accepts (case-insensitive) one of:
s|build a multiarch ISO ^m|yes ^m|true ^m|1
s|build a separate ISO for each architecture ^m|no ^m|false ^m|0
s|only build an i686-architecture ISO ^m|i686 ^m|32 ^m|no64
s|only build an x86_64-architecture ISO ^m|x86_64 ^m|64 ^m|no32
|======================

==== `ipxe`
*default: no*

Enable iPXE ("mini ISO") functionality.

NOTE: This has no bearing on the <<code_sync_code,`[sync]`>> section, so you can create an iPXE HTTP preparation for instance without needing to sync it anywhere (in case you're building on the webserver itself).

[options="header"]
|======================
2+^|Accepts (case-insensitive) one of:
^m|yes ^m|no
^m|true ^m|false
^m|1 ^m|0
|======================

==== `i_am_a_racecar`
*default: no*

This option should only be enabled if you are on a fairly powerful, multicore system with plenty of RAM. It will speed the build process along, but will have some seriously adverse effects if your system can't handle it. Most modern systems should be fine with enabling it.

[options="header"]
|======================
2+^|Accepts (case-insensitive) one of:
^m|yes ^m|no
^m|true ^m|false
^m|1 ^m|0
|======================

=== `[gpg]`
This section controls settings for signing our release files. This is only used if <<code_gpg_code,`build:gpg`>> is enabled.

==== `mygpgkey`
A valid key ID that BDisk should use to _sign_ release files.

. You will be prompted for a passphrase if your key has one/you don't have an open and authorized gpg-agent session. Make sure you have a working pinentry configuration set up!
. If you leave this blank we will use the key we generate automatically earlier in the build process.
. We will generate one if this is blank and you have selected sign as yes.

==== `mygpghome`
The directory should be used for the above GPG key if specified. Make sure it contains a keybox (`.kbx`) your private key. (e.g. `/home/username/.gnupg`)

=== `[sync]`
This section controls what we should do with the resulting build and how to handle uploads, if we choose to use those features.

==== `http`
*default: no*

If enabled, BDisk will generate/prepare HTTP files. This is mostly only useful if you plan on using iPXE. See the <<code_http_code_2,`[http]`>> section.

[options="header"]
|======================
2+^|Accepts (case-insensitive) one of:
^m|yes ^m|no
^m|true ^m|false
^m|1 ^m|0
|======================

==== `tftp`
*default: no*

If enabled, BDisk will generate/prepare TFTP files. This is mostly only useful if you plan on using more traditional (non-iPXE) setups and regualar PXE bootstrapping into iPXE.

[options="header"]
|======================
2+^|Accepts (case-insensitive) one of:
^m|yes ^m|no
^m|true ^m|false
^m|1 ^m|0
|======================

==== `git`
*requires: <<optional,git>>* +
*default: no*

Enable automatic Git pushing for any changes done to the project itself. If you don't have upstream write/push access, you'll want to disable this.

[options="header"]
|======================
2+^|Accepts (case-insensitive) one of:
^m|yes ^m|no
^m|true ^m|false
^m|1 ^m|0
|======================

==== `rsync`
*requires: <<optional,rsync>>* +
*default: no*

Enable rsync pushing for the ISO (and other files, if you choose- useful for iPXE over HTTP(S)).

[options="header"]
|======================
2+^|Accepts (case-insensitive) one of:
^m|yes ^m|no
^m|true ^m|false
^m|1 ^m|0
|======================

=== `[http]`
This section controls details about HTTP file preparation/generation. Only used if <<code_http_code,`sync:http`>> is enabled.

==== `path`
This directory is where to build an HTTP webroot.

WARNING: MAKE SURE you do not store files here that you want to keep! They will be deleted!

. No whitespace
. If blank, HTTP preparation/generation will not be done
. If specified, it will be created if it doesn't exist
. Will be deleted first

==== `user`
What user the HTTP files should be owned as. This is most likely going to be either 'http', 'nginx', or 'apache'.

. No whitespace
. User must exist on build system

|======================
^s|Can be one of: ^.^m|username ^.^m|http://www.linfo.org/uid.html[UID]
|======================

==== `group`
What group the HTTP files should be owned as. This is most likely going to be either 'http', 'nginx', or 'apache'.

. No whitespace
. Group must exist on build system

|======================
^s|Can be one of: ^.^m|group name ^.^m|https://linux.die.net/man/5/group[UID]
|======================

=== `[tftp]`
This section controls details about TFTP file preparation/generation. Only used if <<code_tftp_code,`sync:tftp`>> is enabled.

==== `path`
The directory where we want to build a TFTP root.

WARNING: MAKE SURE you do not store files here that you want to keep! They will be deleted!

. No whitespace
. Will be created if it doesn't exist
. Will be deleted first

==== `user`
What user the TFTP files should be owned as. This is most likely going to be either 'tftp', 'root', or 'nobody'.

. No whitespace
. User must exist on build system

|======================
^s|Can be one of: ^.^m|username ^.^m|http://www.linfo.org/uid.html[UID]
|======================

==== `group`
What group the TFTP files should be owned as. This is most likely going to be either 'tftp', 'root', or 'nobody'.

. No whitespace
. Group must exist on build system

|======================
^s|Can be one of: ^.^m|group name ^.^m|https://linux.die.net/man/5/group[UID]
|======================

=== `[ipxe]`
This section controls aspects of iPXE building. Only used if <<code_ipxe_code,`build:ipxe`>> is enabled.

==== `iso`
*default: no* +
*requires: <<optional,_git_>>*

Build a "mini-ISO"; that is, an ISO file that can be used to bootstrap an iPXE environment (so you don't need to set up a traditional PXE environment on your LAN). We'll still build a full standalone ISO no matter what.

[options="header"]
|======================
2+^|Accepts (case-insensitive) one of:
^m|yes ^m|no
^m|true ^m|false
^m|1 ^m|0
|======================

==== `uri`
What URI iPXE's EMBED script should use. This would be where you host an iPXE chainloading script on a webserver, for instance. See iPXE's example of http://ipxe.org/scripting#dynamic_scripts[dynamic scripts^] for an example of the script that would be placed at this URI.

NOTE: If you require HTTP BASIC Authentication or HTTP Digest Authentication (untested), you can format it via `https://user:password@bdisk.square-r00t.net/boot.php`.

NOTE: This currently does not work for HTTPS with self-signed certificates.

. *Required* if <<code_iso_code,`iso`>> is enabled

==== `ssldir`
Directory to hold SSL results, if we are generating keys, certificates, etc.

. No whitespace
. Will be created if it does not exist

==== `ssl_ca`
Path to the (root) CA certificate file iPXE should use. See http://ipxe.org/crypto[iPXE's crypto page^] for more information.

NOTE: You can use your own CA to sign existing certs. This is handy if you run a third-party/"Trusted" root-CA-signed certificate for the HTTPS target.

. No whitespace
. Must be in PEM/X509 format
. *Required* if <<code_iso_code,`iso`>> is enabled
. If it exists, a matching key (ssl_cakey) *must* be specified
.. However, if left blank/doesn't exist, one will be automatically generated

==== `ssl_cakey`
Path to the (root) CA key file iPXE should use.

. No whitespace
. Must be in PEM/X509 format
. *Required* if <<code_iso_code,`iso`>> is enabled
. If left blank or it doesn't exist (and <<code_ssl_ca_code,`ssl_ca`>> is also blank), one will be automatically generated
. *Must* match/pair to <<code_ssl_ca_code,`ssl_ca`>> if specified/exists
. MUST NOT be passphrase-protected/DES-encrypted

==== `ssl_crt`
Path to the _client_ certificate iPXE should use.

. No whitespace
. Must be in PEM/X509 format
. *Required* if <<code_iso_code,`iso`>> is enabled
. If specified/existent, a matching CA cert (<<code_ssl_ca_code,`ssl_ca`>>) and key (<<code_ssl_cakey_code,`ssl_cakey`>>) *must* be specified
.. However, if left blank/doesn't exist, one will be automatically generated
. *Must* be signed by <<code_ssl_ca_code,`ssl_ca`>>/<<code_ssl_cakey_code,`ssl_cakey`>> if specified and already exists

==== `ssl_key`
Path to the _client_ key iPXE should use.

. No whitespace
. Must be in PEM/X509 format
. *Required* if <<code_iso_code,`iso`>> is enabled
. If left blank/nonexistent (and <<code_ssl_ca_code,`ssl_ca`>> is also blank), one will be automatically generated

=== `[rsync]`
This section controls aspects of rsync pushing. Only used if <<code_rsync_code,`sync:rsync`>> is enabled.

==== `host`
The rsync destination host.

. Must resolve from the build server
. Can be host, FQDN, or IP address

==== `user`
This is the remote user we should use when performing the rsync push.

. User must exist on remote system
. SSH pubkey authorization must be configured
. The destination's hostkey must be added to your local build user's known hosts

==== `path`
This is the remote destination path we should use for pushing via rsync.


NOTE: You'll probably want to set <<code_user_code_3,`http:user`>> and <<code_group_code,`http:group`>> to what it'll need to be on the destination.

. No whitespace
. The path *must* exist on the remote host
. The path MUST be writable by <<code_user_code_5,`user`>>

==== `iso`
Should we rsync over the ISO files too, or just the boot files?

[options="header"]
|======================
2+^|Accepts (case-insensitive) one of:
^m|yes ^m|no
^m|true ^m|false
^m|1 ^m|0
|======================

91
docs/manual/user/GETTING_STARTED.adoc Normal file
View File

@ -0,0 +1,91 @@
== Getting Started

=== Downloading
If it isn't in your distro's repositories (It *is* in Arch's AUR! Both https://aur.archlinux.org/packages/bdisk/[tagged release^] and https://aur.archlinux.org/packages/bdisk-git/[git master^].), you can still easily get rolling. Simply visit the project's https://git.square-r00t.net/BDisk/[source code web interface^] and download a tarball under the *Download* column:

image::fig1.1.png[cgit,align="center"]

If you know the tag of the commit you want, you can use curl:

curl -sL https://git.square-r00t.net/BDisk/snapshot/BDisk-4.0.0.tar.xz | tar -xf -

or wget:

wget -O - https://git.square-r00t.net/BDisk/snapshot/BDisk-3.11.tar.xz | tar -xf -

You can use `https://git.square-r00t.net/BDisk/snapshot/BDisk-master.tar.xz` for the URL if you want the latest working version. If you want a snapshot of a specific commit, you can use e.g. `https://git.square-r00t.net/BDisk/snapshot/BDisk-5ac510762ce00eef213957825de0e6d07186e7f8.tar.xz` and so on.

Alternatively, you can use https://git-scm.com/[git^]. Git most definitely _should_ be in your distro's repositories.

TIP: If you're new to git and want to learn more, I highly recommend the book https://git-scm.com/book/en/v2[Pro Git^]. It is available for free download (or online reading).

You can clone via https:

git clone https://git.square-r00t.net/BDisk

or native git protocol:

git clone git://git.square-r00t.net/bdisk.git BDisk

The git protocol is much faster, but at a cost of lessened security.

NOTE: I also have a mirror at https://github.com/johnnybubonic/BDisk[GitHub^], but I don't like GitHub very much and since it's a mirror repository, it's possible it will be out of date. For this reason, it's recommended that you use the resources above.

=== Prerequisites
This is a list of software you'll need available to build with BDisk.

TIP: Your distro's package manager should have most if not all of these available, so it's unlikely you'll need to install from source.

NOTE: Some versions may be higher than actually needed (especially _gcc_).

CAUTION: You will need at least about *15GB* of free disk space, depending on what options you enable. Each architecture chroot (i.e. x86_64, i686) is about 3.5GB after a build using the default package set (more on that later), each architecture release tarball (what we use to build the chroots) is approximately 115MB each, and each squashed image per architecture is 1.1GB (if you use the default package set). If you don't understand what this means quite yet, don't worry- we'll go into more detail later on. Just know that you'll need a fair bit of free disk space.

==== Build Environment
* GNU/Linux (relatively recent release of preferred distro)
** Building on FreeBSD and other +*BSDs+ *may* be possible via the use of https://www.freebsd.org/doc/handbook/jails.html[jails^]. This is entirely untested and no support nor testing will be offered by the author (me). If you would like to offer documentation for this, please <<contact_the_author,contact me>>.
** Building on Windows *may* be possible via the use of the https://docs.microsoft.com/en-us/windows/wsl/install-win10[WSL (Windows Subsystem for Linux)^]. This is entirely untested and no support nor testing will be offered by the author (me). If you would like to offer documentation for this, please <<contact_the_author,contact me>>.
** Building on macOS is simply not supported, period, due to chroots being necessary to the build functionality of BDisk (and macOS not being able to implement GNU/Linux chroots). You'll need to run a build VM.
* https://www.python.org/[Python^] (>=3.6)

==== Necessary
These are needed for using BDisk.

* https://github.com/dosfstools/dosfstools[dosfstools^]
* http://libburnia-project.org[libisoburn^]
* http://squashfs.sourceforge.net[squashfs-tools^] (>=4.2)

These are required Python modules:
// TODO: double-check/update these.

* https://pypi.python.org/pypi/humanize[Humanize^]
* http://jinja.pocoo.org/[Jinja2^]
* https://pypi.python.org/pypi/psutil[PSUtil^]
* https://pypi.python.org/pypi/validators[Validators^]

==== Optional
While not strictly necessary, these will greatly enhance your BDisk usage. I've included some reasons why you might want to install them.

NOTE: If you do not wish to install any of these or cannot install them, be sure to disable the relevant options in the `build.ini` file (we'll talk about that later). The default `extra/dist.build.ini` should be sane enough to not require any of these.

* http://gcc.gnu.org[gcc (multilib)^] (>=6.x)
** Needed for building iPXE.
* http://gcc.gnu.org[gcc-libs (multilib)^] (>=6.x)
** (Same as _gcc_.)
* https://git-scm.com/[git^]
** For autodetection of version, automatically making commits for your project, checking out source code, etc.
* https://www.gnupg.org/[gpg/gnupg^] (>=2.1.11)
** For automatically signing releases, verifying downloaded files from the Internet as part of the build process, etc. It's okay if you don't have a key set up!
* https://rsync.samba.org/[rsync^]
** For syncing built ISOs to a fileserver, syncing to a remote iPXE server, syncing to a traditional PXE/TFTP server, etc.

These are optional Python modules:

* https://pypi.python.org/pypi/GitPython[GitPython^]
** (Same reasons as _git_)
* https://pypi.python.org/pypi/pygpgme[PyGPGME^]
** (Same reasons as _gpg/gnupg_)
* https://pypi.python.org/pypi/patch[Patch^]
** For branding iPXE environments per your `build.ini`.
* https://pypi.python.org/pypi/pyOpenSSL[PyOpenSSL^]
** To set up a PKI when building iPXE; used to create trusted/verified images.

51
docs/manual/user/IMPORTANT_CONCEPTS.adoc Normal file
View File

@ -0,0 +1,51 @@
== Important Concepts
If this is your first foray into building live distros, there are some terms and concepts we need to understand first. This will simplify the process later on.

=== Terms
An *operating system*, or OS, is what your programs (email client, web browser, etc.) run on.

There are two basic types of booting systems that communicate between the *hardware* (the physical computer itself and its components) and the operating system: https://en.wikipedia.org/wiki/BIOS[*BIOS*^] (Basic Input/Output System) which has been around for quite some time and the newer https://en.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface[*UEFI*^] (Unified Extensible Firmware Interface). Don't worry, you don't need to memorize what they're acronyms for and there won't be an exam -- just remember that BIOS is an older technology and UEFI is the newer one (and that they operate differently).

*GNU/Linux*, sometimes just referred to as _Linux_ (And there is a difference between the terminologies, but it's nuanced. You are welcome to https://www.gnu.org/gnu/linux-and-gnu.en.html[read up on it^] though!), is an example of an operating system. Other examples include _Windows_, _macOS_ (previously _OS X_), _iOS_, _Android_, and a whole slew of others. There are many types of GNU/Linux offerings, called _distributions_, _flavors_, or _distros_.

A *live distro*, *live CD*, *live DVD*, *live USB*, and the like are a way of booting an operating system without installing it on the hard drive- this means the computer doesn't even need a hard drive installed, or it doesn't matter if the installed operating system is broken. Typically they are Linux-based, but there are several Windows-based live releases out there (usually they're focused on rescuing broken Windows systems, so they're not very flexible).

*Hybrid ISOs* are ISO files that can be burned to optical media (CDs, DVDs, etc.) and also be _dd_'d directly to a USB thumbdrive (for computers that support booting from USB). That means one file, multiple media types.

*Architectures* are different hardware platforms. This mostly refers to the CPU. Common implementations are *64-bit* (also known as *x86_64* or *AMD64* for ones that support running both 64-bit and 32-bit software, or *IA64* or *Itanium* for processors that only support 64-bit) and *32-bit* (or *i686* and the older *i386* and *i486* implementations). Most consumer PCs on the market today are x86_64.

*Chroots*, *chrooting*, and the like are variants on the word *chroot*. A *chroot* is a way of running a GNU/Linux install "inside" another GNU/Linux distro. It's sort of like a virtual machine, or VM, except that it's a lot more lightweight and it doesn't do any actual virtualization- and uses the host's kernel, memory mapping, etc. It's very useful for development of operating systems.

*PXE*, or Pre-boot eXecution Environment, is a way of booting operating systems over a local network.

*iPXE* is a http://ipxe.org/[project^] that builds a very small Linux kernel, UNDI (traditional PXE) images, and the like that allow you to essentially use PXE over the Internet. It's very flexible and customizable, and supports a custom scripting engine and such.

=== Why live media is necessary/Why you might want BDisk
"But Brent," I hear you ask in a voice which most likely is nothing close to what you actually sound like and entirely in my head, "Why would I need a live CD/USB/etc.? And why BDisk?"

Elementary, my dear imaginary reader! I touch on some reasons why one might want live media in the beginning of the <<USER.adoc#user_manual,User Manual>>, but here's why you might want BDisk specifically as opposed to another live distro (or <<FAQ.adoc#i_don_t_like_bdisk_are_there_any_other_alternatives,live distro creator>>).

* Fully customizable
* Works with a multitude of GNU/Linux distros -- both for the host build system and as the guest. (Still under development!)
* It performs optimizations and compression to help you get the smallest ISO possible.
* In addition to building hybrid ISOs, it supports building iPXE hybrid ISOs (meaning you only need a very small file; the rest of the operating system boots over the Internet).
* It supports both BIOS and UEFI systems- both the full image and the iPXE images.
* It supports multiple architectures (x86_64, i686, possibly IA64 -- untested) on the same ISO.
* It supports automatically syncing to a web mirror, PXE boot server, etc. via rsync upon successful build.
* It supports SecureBoot (untested!).
* It is 100% compatible with both the https://wiki.archlinux.org/index.php/installation_guide[Arch installation guide^] and the https://wiki.gentoo.org/wiki/Handbook:AMD64#Installing_Gentoo[Gentoo installation guide^].
* It allows for non-interactive/automated building (i.e. nightly images).
* It supports arbitrary file inclusion in a defined path on the ISO itself, not via some arbitrary directory as a separate partition on the media.
* It can automatically build an accompanying "mini" ISO using iPXE -- which is also a hybrid, UEFI-supported ISO.
* Automatic versioning based on git tags (optional).

=== Who might want to use BDisk?
* System builders/hardware testers
* System Administrators/Engineers/Architects
* Information Security professionals
* Computer repair shops
* Technology Consultants
* Hobbyists
* Home GNU/Linux users
* Technology enthusiasts

81
docs/manual/user/PROJECT_LAYOUT.adoc Normal file
View File

@ -0,0 +1,81 @@
== Project Structure
The following is a tree of files and directories in a BDisk root directory. Note that yours may not look quite like this, as BDisk supports some directory relocation to aid in packaging for distros. These will be examined in-depth in the coming sections.

<BDisk root directory>
├── bdisk
│   ├── bchroot.py
│   ├── bdisk.py
│   ├── bGPG.py
│   ├── bSSL.py
│   ├── bsync.py
│   ├── build.py
│   ├── host.py
│   ├── ipxe.py
│   └── prep.py
├── docs
│   ├── COPYING
│   ├── LICENSE -> COPYING
│   ├── manual
│   │   └── (...)
│   ├── README
├── examples
│   └── HTTP
│   └── (...)
├── extra
│   ├── bdisk.png
│   ├── bin
│   │   └── (...)
│   ├── dist.build.ini
│   ├── external
│   │   └── (...)
│   ├── mirrorlist
│   ├── pre-build.d
│   │   ├── (...)
│   │   ├── i686
│   │   │   └── (...)
│   │   └── x86_64
│   │   └── (...)
│   └── templates
│   ├── BIOS
│   │   ├── isolinux.cfg.arch.j2
│   │   └── isolinux.cfg.multi.j2
│   ├── EFI
│   │   ├── base.conf.j2
│   │   ├── loader.conf.j2
│   │   ├── ram.conf.j2
│   │   ├── uefi1.conf.j2
│   │   └── uefi2.conf.j2
│   ├── GPG.j2
│   ├── iPXE
│   │   ├── BIOS
│   │   │   └── isolinux.cfg.j2
│   │   ├── EFI
│   │   │   ├── base.conf.j2
│   │   │   └── loader.conf.j2
│   │   ├── EMBED.j2
│   │   ├── patches
│   │   │   ├── 01.git-version.patch.j2
│   │   │   └── 02.banner.patch.j2
│   │   └── ssl
│   │   └── openssl.cnf
│   ├── overlay
│   │   ├── (...)
│   │   ├── i686
│   │   ├── x86_64
│   ├── pre-build.d
│   │   ├── (...)
│   │   ├── i686
│   │   ├── x86_64
│   ├── VARS.txt.j2
│   └── VERSION_INFO.txt.j2
└── overlay
├── (...)
├── i686
└── x86_64

include::fslayout/BDISK.adoc[]
include::fslayout/DOCS.adoc[]
include::fslayout/EXAMPLES.adoc[]
include::fslayout/EXTRA.adoc[]
include::fslayout/OVERLAY.adoc[]

10
docs/manual/user/advanced/AUTOLOGIN.adoc Normal file
View File

@ -0,0 +1,10 @@
=== Automatic Login (TTY)
If you don't want to have to log into the TTY on boot, BDisk can automatically log in for you with a given username.

If, for example, you want a terminal to auto-login on TTY1 with the root user, you would create the following file at `<basedir>/overlay/etc/systemd/system/getty@tty1.service.d/autologin.conf`:

[Service]
Type=idle
ExecStart=
ExecStart=-/usr/bin/agetty --autologin root --noclear %I 38400 linux

3
docs/manual/user/advanced/BUILDING.adoc Normal file
View File

@ -0,0 +1,3 @@
=== Changing the Build Process
If you want to make modifications that can't be managed by arbitrary file inclusion or changing the software package lists, you may want to introduce additional changes to the image configuration that's run during the chroot. This is fairly easy to do. Simply modify `<basedir>/extra/pre-build.d/root/pre-build.sh` with the changes you desire. Note that this has a `.sh` file extension, but it can be any type of script you want -- Bash, Perl, Python, etc. -- it just needs the shebang line at the beginning of the script.

30
docs/manual/user/advanced/DESKTOP.adoc Normal file
View File

@ -0,0 +1,30 @@
=== Starting a Desktop Environment
You can install any desktop environment or window manager you would like via <<changing_the_installed_software,package lists>>! From there, it's simply a matter of setting the correct Systemd unit to start automatically. The https://wiki.archlinux.org/index.php/[Arch wiki^] has a lot of useful information here. As an example, I'll include http://lxde.org/[LXDE^] instructions here.

Simply create a symlink for the target. In the `<basedir>/overlay/etc/systemd/system/` directory:

ln -s /usr/lib/systemd/system/lxdm.service display-manager.service

==== Autologin (LXDE)
Many desktop environments even offer an automatic login feature directly through the desktop manager (LXDM, in LXDE's case).

Again, using LXDE as an example, create a file at `<basedir>/overlay/etc/lxdm/lxdm.conf`:

[base]
autologin=bdisk
greeter=/usr/lib/lxdm/lxdm-greeter-gtk
[server]
arg=/usr/bin/X -background vt1
[display]
gtk_theme=Adwaita
bottom_pane=1
lang=1
keyboard=0
theme=Industrial
[input]
[userlist]
disable=0
white=
black=

LXDE will then automatically log in with the user `bdisk` (note the second line, right under `[base]`) whenever started.

20
docs/manual/user/advanced/SOFTWARE.adoc Normal file
View File

@ -0,0 +1,20 @@
=== Changing the Installed Software
BDisk comes with a large https://bdisk.square-r00t.net/packages/[list of software^] installed in the build instance by default, ranging from data recovery (such as _foremost_, _scalpel_, _ddrescue_, etc.), security and data wiping (_nwipe_, _scrub_, etc.), penetration testing (_wifite_, _aircrack-ng_, etc.) and a slew of others. Seriously, if you're looking for a tool, changes are it's on it.

However, this leads to a fairly long build time- even with a local repository mirror (many of the packages are from the AUR). You may want to replace the list with a smaller subset.

The `iso.pkgs.\*` files are not files you should modify- they contain software necessary to the building of BDisk and are the basic necessary files to build a bootable image. However, the `packages.*` files are where you would add or remove software to be installed.

NOTE: The package lists can contain both https://www.archlinux.org/packages/[Arch repository packages^] *and* https://aur.archlinux.org/[AUR^] packages.

NOTE: Blank lines are ignored, and you can comment out lines by prefixing the line with the `#` character.

==== `<basedir>/extra/pre-build.d/i686/root/packages.arch`
This list contains packages to *only* be installed for the i686 image.

==== `<basedir>/extra/pre-build.d/x86_64/root/packages.arch`
This list contains packages you *only* want installed in the x86_64 image.

==== `<basedir>/extra/pre-build.d/root/packages.both`
This file contains packages for both architectures (i686 and x86_64).

74
docs/manual/user/advanced/SSH.adoc Normal file
View File

@ -0,0 +1,74 @@
=== SSH Pubkey Authentication
To start with, you'll want to secure SSH a little more than normal.

I highly recommend https://stribika.github.io/2015/01/04/secure-secure-shell.html[this article^], which we'll be following in this process.

First, create a file: `<basedir>/overlay/etc/ssh/sshd_config` using the following. Comments and blank lines have been stripped out for brevity.

PermitRootLogin prohibit-password
HostKey /etc/ssh/ssh_host_ed25519_key
HostKey /etc/ssh/ssh_host_rsa_key
AuthorizedKeysFile .ssh/authorized_keys
PasswordAuthentication no
PermitEmptyPasswords no
ChallengeResponseAuthentication no
UsePAM yes
PrintMotd no # pam does that
Subsystem sftp /usr/lib/ssh/sftp-server
KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-ripemd160-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,hmac-ripemd160,umac-128@openssh.com

We'll also want to implement a more secure `ssh_config` file to avoid possible leaks. The following is `<basedir>/overlay/etc/ssh/ssh_config`:

Host *
KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256
PasswordAuthentication no
ChallengeResponseAuthentication no
PubkeyAuthentication yes
HostKeyAlgorithms ssh-ed25519-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-ed25519,ssh-rsa
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-ripemd160-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,hmac-ripemd160,umac-128@openssh.com

We'll want to create our own moduli. This can take a long time, but only needs to be done once -- it doesn't need to be done for every build. The following commands should be run in `<basedir>/overlay/etc/ssh/`:

ssh-keygen -G moduli.all -b 4096
ssh-keygen -T moduli.safe -f moduli.all
mv moduli.safe moduli
rm moduli.all

Then we generate hostkeys. This isn't strictly necessary as the live media will create them automatically when starting SSH if they're missing, but this does provide some verification that the host you're SSHing to is, in fact, running the BDisk instance that you yourself built. The following commands should be run in `<basedir>/overlay/etc/ssh/`:

ssh-keygen -t ed25519 -f ssh_host_ed25519_key -N "" < /dev/null
ssh-keygen -t rsa -b 4096 -f ssh_host_rsa_key -N "" < /dev/null

Make sure you have keys on your host workstation generated so you can SSH into BDisk. If you don't have any ED25519 or RSA SSH keys, this will create them for you. The following should be run as the host (build machine, or what have you) user you want to be able to SSH into BDisk as:

ssh-keygen -t ed25519 -o -a 100
ssh-keygen -t rsa -b 4096 -o -a 100

The defaults are fine. Adding a password to your private key is not necessary, but recommended (though note that doing so will inhibit automated SSHing). You should now have in `~/.ssh/` the following files (assuming you kept the defaults above):

id_ed25519
id_ed25519.pub
id_rsa
id_rsa.pub

WARNING: The files ending in *.pub* are _public_ -- they can be published anywhere. However, the ones that are not appended with *.pub* are your _private keys_ and should not be shared with anyone, whether they're password-protected or not!

Now you'll want to get the public key of your SSH keys so you can add them to your BDisk build. The following commands should be run in `<basedir>/overlay/`:

mkdir -p root/.ssh
chmod 700 root/.ssh
touch root/.ssh/authorized_keys
chmod 600 root/.ssh/authorized_keys
cat ~/.ssh/id_{ed25519,rsa}.pub > root/.ssh/authorized_keys

If you decided to <<code_user_code,enable a regular non-root user>> in your build, you'll want to perform the same steps above for the regular user as well (or forego the above and just enable SSH for the user you create). Remember to replace `root/` with `home/<<_code_username_code,<username>>>/`!

Lastly, we need to enable SSH to start on boot. Run the following command in `<basedir>/overlay/etc/systemd/system/multi-user.target.wants/`:

ln -s /usr/lib/systemd/system/sshd.service sshd.service

You should now have SSH automatically start once the instance boots.

13
docs/manual/user/advanced/VPN.adoc Normal file
View File

@ -0,0 +1,13 @@
=== VPN Configuration
For this example we'll set up an https://openvpn.net/[OpenVPN^] client to start automatically on boot.

Setting up an OpenVPN server is outside the scope of this section, but there are a https://openvpn.net/index.php/open-source/documentation/howto.html[multitude^] of https://openvpn.net/index.php/open-source/documentation/examples.html[useful^] https://wiki.archlinux.org/index.php/OpenVPN[documentation^] https://wiki.gentoo.org/wiki/Openvpn[sources^] out there that will help you with that.

However, once you have your client .ovpn file (in our example, we'll call it `client.ovpn`) you can add it to the build relatively easily.

Copy `client.ovpn` as `<basedir>/overlay/etc/openvpn/client/client.conf` -- note the changed file extension. Then, in the `<basedir>/overlay/etc/systemd/system/multi-user.target.wants/` directory, issue these commands:

ln -s /usr/lib/systemd/system/openvpn-client\@.service openvpn-client\@client.service

OpenVPN will then start on boot in the built BDisk instance.

13
docs/manual/user/fslayout/BDISK.adoc Normal file
View File

@ -0,0 +1,13 @@
=== bdisk/
This directory contains the "heart" of BDisk. It essentially is a Python module package. It contains several python "subpackages" split into different files that provide different functions for BDisk. Chances are you won't ever need to touch anything in here.

* <<code_bchroot_py_code>>
* <<code_bdisk_py_code>>
* <<code_bgpg_py_code>>
* <<code_bssl_py_code>>
* <<code_bsync_py_code>>
* <<code_build_py_code>>
* <<code_host_py_code>>
* <<code_ipxe_py_code>>
* <<code_prep_py_code>>

15
docs/manual/user/fslayout/DOCS.adoc Normal file
View File

@ -0,0 +1,15 @@
=== docs/
This directory contains various documentation and other helpful text.

==== COPYING
This contains BDisk's license, the GPLv3.

==== LICENSE
This is simply a link to `COPYING`.

==== manual/
This directory contains the documentation source you're reading right now! It's written in http://asciidoc.org/[asciidoc^] (well, to be more precise it's written in/has some http://asciidoctor.org/[asciidoctor^]-isms). I'd recommend reading the rendered version, as the source (while perfectly human-readable) is written in a very modular fashion so it may be inconvenient to read each source file and following include directives.

==== README
This is a placeholder for common convention; it simply tells you to read the manual (and where to find it/build it).

3
docs/manual/user/fslayout/EXAMPLES.adoc Normal file
View File

@ -0,0 +1,3 @@
=== examples/
This directory contains example filesystem layouts for e.g. your webserver (for iPXE), or your PXE server via TFTP.

21
docs/manual/user/fslayout/EXTRA.adoc Normal file
View File

@ -0,0 +1,21 @@
=== extra/
This directory contains multiple "support files" for BDisk building.

==== bdisk.png
This file is used for bootloader graphics. If you change the name of the project, this can be named something different -- see <<code_uxname_code,the section on uxname>>.

==== bin/
This directory contains sample code or extra tools that don't have anything to do with BDisk normal operation but are useful in building a BDisk distribution.

==== dist.build.ini
This is the "source-provided"/upstream example <<the_code_build_ini_code_file,`build.ini`>>. It will be sourced for any missing configuration options or the like.

==== external/
This directory contains external source code for use with extra features in BDisk that would otherwise be inconvenient to fetch and build dynamically.

==== pkg.build.ini
This is the recommended default <<the_code_build_ini_code_file,`build.ini`>> file for packagers of distro repositories to use when packaging BDisk for inclusion in a package manager.

include::PREBUILD.adoc[]

include::TEMPLATES.adoc[]

13
docs/manual/user/fslayout/OVERLAY.adoc Normal file
View File

@ -0,0 +1,13 @@
=== overlay/
This directory follows similar rules to the <<pre_build_d,pre-build.d/>> directory, except it is applied *after* the chroots are prepared (as it is designed to be user-centric rather than core functionality). We'll go more into this later in-depth, as this is where most of your customizations will be done.

For files that should be included in both chroots, simply recreate the path with the desired file. For instance, if you want a file `/etc/foo/bar.conf` to exist in both i686 and x86_64 versions, it would exist as the path `overlay/etc/foo/bar.conf`.

It follows the following structure:

==== i686/
This contains modifications that should be applied to the i686 version only. If you wanted a file to exist only in the i686 version at `/etc/a/b.conf`, it would be placed in `overlay/i686/etc/a/b.conf`.

==== x86_64/
This contains modifications that should be applied to the x86_64 version only. If you wanted a file to exist only in the x86_64 version at `/etc/z/y.conf`, it would be placed in `overlay/x86_64/etc/z/y.conf`.

13
docs/manual/user/fslayout/PREBUILD.adoc Normal file
View File

@ -0,0 +1,13 @@
==== pre-build.d/
This file contains a "core" overlay. Generally these files shouldn't be modified unless you know what you're doing, but there are some interesting things you can do in here. Generally speaking, though, you'll want to place your modifications in the <<overlay_2,`overlay/`>> directory.

For files that should be included in both chroots, simply recreate the path with the desired file. For instance, if you want a file `/etc/foo/bar.conf` to exist in both i686 and x86_64 versions, it would exist as the path `pre-build.d/etc/foo/bar.conf`.

It follows the following structure:

===== i686/
This contains modifications that should be applied to the i686 version *only*. If you wanted a file to exist only in the i686 version at `/etc/a/b.conf`, it would be placed in `pre-build.d/i686/etc/a/b.conf`.

===== x86_64/
This contains modifications that should be applied to the x86_64 version *only*. If you wanted a file to exist only in the x86_64 version at `/etc/z/y.conf`, it would be placed in `pre-build.d/x86_64/etc/z/y.conf`.

48
docs/manual/user/fslayout/TEMPLATES.adoc Normal file
View File

@ -0,0 +1,48 @@
==== templates/
This directory contains dynamic templates used for dynamic configuration building and other such things. They are written in http://jinja.pocoo.org/[Jinja2^]. If you haven't used Jinja2 before, the http://jinja.pocoo.org/docs/dev/templates/[templating documentation^] will prove to be very useful.

This allows you to customize low-level behaviour of BDisk without modifying the source.

===== BIOS/
The `isolinux.cfg.arch.j2` template controls boot options for the single-arch versions of BDisk. In other words if you only build an i686 or only an x86_64 version, this is the template that would be used for BIOS boot mode.

The `isolinux.cfg.multi.j2` is used for multi-arch. It manages booting for both i686 and x86_64 versions.

These files will let you change the behaviour of booting in BIOS systems. The menu colour, the menu entries, the menu default, etc.

===== EFI/
The files in here are https://www.freedesktop.org/wiki/Software/systemd/systemd-boot/[systemd-boot^] configurations. The distributed defaults are:

`base.conf.j2`, which controls the "main"/default entry.

`loader.conf.j2`, the meta configuration file which tells the loader which entry to load by default and which entries to include.

`ram.conf.j2` which allows BDisk to run entirely from RAM.

`uefi1.conf.j2` which provides a UEFI shell (for older UEFI systems).

`uefi2.conf.j2` which provides a UEFI shell (for newer UEFI systems).

===== GPG.j2
This file contains default parameters for the https://www.gnupg.org/documentation/manuals/gnupg/Unattended-GPG-key-generation.html[GPG key generation], if we need to automatically generate a key.

===== iPXE/
This directory holds templates for iPXE/mini builds.

The `BIOS/` directory is similar to <<bios, BIOS/>> mentioned above, but it only needs one configuration file and is a much more minimal design (since its entire purpose is to chainload to the iPXE loader).

The `EFI/` directory is similar to <<efi, EFI/>> above also, but needs fewer configuration files (its only purpose is to bootstrap iPXE).

`EMBED.j2` is the iPXE http://ipxe.org/scripting[embedded script^] (http://ipxe.org/embed[more info^]). This is what chainloads the remote resources (kernel, intird, squashed filesystem images, and so forth).

The `patches/` directory largely control branding of the mini ISO. They are in https://www.gnu.org/software/diffutils/manual/html_node/Unified-Format.html[unified diff^] (or "patch") format.

===== overlay/
This directory contains *templated* overlays. These are intended to be templated by the user. See <<overlay, the overlay section>> for more information on how to use this. Remember to suffix your template files with the `.j2` extension.

===== pre-build.d/
This directory contains *templated* overlays. These are intended to not be managed by the user, as they handle configuration necessary for building an ISO. See <<pre_build_d, the pre-build.d section>> for more information on this.

===== VERSION_INFO.txt.j2
This template specifies a VERSION_INFO.txt file placed in various locations throughout the builds to help identify which version, build, etc. the ISO is.