I am somewhat new to OpenBSD but not systems and/or
systems programming as a whole. Please excuse any errors
I may have made in my observations and desires. Please
also feel free to pick and choose between the aspects of
this that appear to be valuable. (I can provide my versions
of the scripts indicated below if that is of assistance however
many of these may be obvious in their content to experienced
OpenBSD people that follow this group. These scripts may be
missing some desirable error checking code)
Security is one of the stated objectives of OpenBSD yet the current
build process appears to be difficult to secure largely because the
build directories are numerous and mixed in with directories for
general machine operation. (also difficult to backup/restore if the
user desires to maintain multiple machine configurations using this
process. While the content of these directories is publicly
available, the specific contents for each configuration is NOT
as are the security requirements to protect the contents for EACH
SPECIFIC configuration. The directories for many of the operations
appear to be "hard coded" in some of the make scripts to specific
directories. I even experienced indications that the directory /CVS
seems to be assumed to be a repository that can not be used for
checkout, in my various attempts to do this with the existing code base.
My suggestion for improvement and simplification include maintaining
a completely separate directory structure(s) for the build process
from normal machine operation. See below for hierarchy and
description:
/bld root directory for build operation
(no data this directory/mount only other
directories except for the
shell scripts and logs)
/bld/sh shell scripts to complete various build processes
(see list below)
/bld/sh/log location to store logs from build scripts
from the following basic command
sh build_script
>log/build_script.log
/bld/sh/logrlse? release version of the logs for diff compare
/bld/sh/logprior? prior version of the logs for diff compare
/bld/cvs (no data in this directory)
/bld/cvs/src (src.tar.gz current /usr/src)
/bld/cvs/src/sys (sys.tar.gz current /usr/src/sys)
/bld/cvs/ports (ports.tar.gz current /usr/ports)
/bld/cvs/xenocara (xenocara.tar.gz current /usr/xenocara)
/bld/obj (no data in this directory)
/bld/obj/kernel? (kernel obj current ?)
/bld/obj/userland (userland obj current /usr/obj)
/bld/obj/xenocara (xenocara obj current /usr/xobj))
/bld/dest/ (no data in this directory)
/bld/dest/userland (output current /usr/dest)
/bld/dest/xenocara (output current /usr/xdest?)
/bld/rlse (no data in this directory)
/bld/rlse/src (*.tar.gz for cvs_preload(, etc - /bld/sh?))
/bld/rlse/{ver}/{arch} release binary files
I imagine in the above directory structure only /bld/rlse/... would be
optionally required to grant outside read access for tasks like NFS
or HTTP or FTP, etc. (Perhaps the /bld/rlse directory should be
named /rlse for that reason alone}.
The remaining directories would be tied to root access only with
appropriate sudo setup for a user to perform the necessary tasks.
none of these have been created and I would need to do some
real research to achieve any of these scripts as defined. The user,
if specified in the install should be setup with the appropriate sudo
rights as part of the install.
ie. it would be nice if you could
sudo build {script)
and have the above command execute in one task
sh /bld/sh/{script} >/bld/sh/log/{script}.log
and in another task tied to the console window
tail -f /bld/sh/log/{script}.log
with this task returning the command prompt
upon closing of the log file (based on the
end of the first task).
sudo log {script} {log | logrlse | logprior} {file}
would be used to copy
/bld/{log | logrlse | logprior}/{script}.log
to a user accessible file -- to edit and/or
submit as documentation for errors
requiring assistance.
sudo diff {flags} {script} {logrlse | logprior}
diff {flags} /bld/sh/log/{script}.log \
/bld/sh/{logrlse | logprior}/(script}.log
note based on the above
sh /bld/sh/{script} >/bld/sh/log/(script).log
does not currently place all messages into the log file some
continue to appear on the console -- another item that would
need to be changed. (cvs is one of the offenders here -- I am
not sure if this is reasonably possible to change).
PS automated error checking for OpenBSD staff could be possible
by processing diff against various versions of the log files as changes
are made to the source(s). Likewise for the users to check the initial
install if the logs are included on the full install CD as noted. Scripts
could be added to perform the diff operation on script content -
a second log directory logrlse and a third logprior may be desirable
in /bld/sh to support this function.) This process would address
questions about errors in the build process by those trying to debug
errors -- eliminating those classed as acceptable and highlighting
those that are significant on most occasions.
I like mount points for the following based on the above config
(I would also allocate them in the following order as /bld/rlse is more
likely to be used for non build purposes
- optimize arm motion on the disk))
The estimates below could be revised or added to document
requirements for the complete build of OpenBSD with most/
all ports extracted.
Current estimate of size
Mount Point 50% utilization for -stable
/bld/rlse (1792m)
/bld/dest (1792m)
/bld/cvs/src/sys (256m)
/bld/obj (2560m)
/bld/cvs (3580m)
I suggest slices l - p for these.
Note because
cd /bld/cvs/sys
tar cvzfX /bld/rlse/src/src.tar.gz
does not exclude the sys subdirectory
(note mount point above)
so I wrapper the commands with
umount /dev/{?}
cd /bld/cvs/src
tar cvzf /bld/rlse/src/src.tar.gz
mount /dev/{?} /bld/cvs/src/sys)
I have created all of the following scripts except as noted
and could probably create the remaining scripts --
however I have had problems noted above in making this
work.
Script on current install CD (release, stable or custom)
install_rlse - copies /mnt/{ver}/{arch} from CD
to /bld/rlse/{ver}/{arch}
- this may not be desirable
(opinions anyone?)
Script on new source CD (release, stable or custom)
CD contents - script install_src (see below)
- /bld/sh or sh.tar.gz (shell scripts (and logs?))
- /bld/rlse/src (*.tar.gz - various sources)
install_bld - copies /mnt/src from CD
to /bld/rlse/src
- copies from /mnt/sh or
tar extract from sch.tar.gz
to /bld/sh
/bld/sh probable scripts in stated processing order
tune_bld - sets average file size to 8192? for
/bld/dest
/bld/cvs/src/sys,
/bld/obj,
/bld/cvs,
- should be edited as appropriate for
the user's installation
cvs_preload - tar extract from /bld/rlse/src
to /bld/cvs ... as appropriate
- edit as desired
cvs_checkout - checkout of the CVS source to /bld/cvs
- edit for anoncvs server
- edit for directories
cvs_update - update of the CVS source to /bld/cvs
- edit for anoncvs server
- edit for directories
bld_kernel - build a new kernel
install_kernel - install new kernel
{reboot}
bld_userland - build userland
bld_release - construct release components for userland
chk_release - check the userland release
- create index.txt
bld_xenocara - build xenocara (X)
bld_releasex - construct release components for xenocara
- create updated index.txt
src_release - construct release sources
for existing release components
- (backup / transfer)
- edit for /dev/? unless tar X or another
option can do this.
- create index.txt
(I have not created these yet, but I probably could, if desired)
clear_shlogs - rm -rf /bld/sh/log/*
copy_shlogs - copy /bld/sh/log to /bld/sh/logprior
(all of the following could reflect specific user configurations
of OpenBSD for various machine propagations.)
iso_net_release - create a networked ISO for release binaries
iso_full_release - create a full ISO for release files, etc
- include /bld/sh/logrlse or
logrlse.tar.gz
(shell scripts and logs - if space allows)
iso_source - create an ISO of source tar files, etc
- includes shell scripts (and logs?) /bld/sh
burn_net_release - burn the network ISO - backup, etc
burn_full_release - burn the full ISO - backup, etc
burn_source - burn the source ISO - backup, etc
There could even be a DVD ISO that contains both the release
(or stable or custom (pkg or code)) binaries, sources and logs.
Thanks for reading this. I hope it is considered valuable.
