If you have so many ideas you should go ahead and start your own
project. Good luck building a successfull project based on 'ideas'.
I'm not even going to read to the end.
> 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.
