Ugh sorry that I don't read it till end, but even first part looks ugly for me. No, I'm not a programmer, I'm just fuc..... newbie in programming because first years I focused on learning and using all types of systems so that I can be good sysadmin (maybe) later. I end with my discoveries on OpenBSD because it's clean, intelligent, stable, secure, has well documentation and its developers really know what they are doing and why they are doing it so. From time of start with OpenBSD I just cry when I use some other systems because they aren't so good even if they are better for some use.
OpenBSD has very good filesystem hierarchy http://www.openbsd.org/cgi-bin/man.cgi?query=hier&apropos=0&sektion=0&manpath =OpenBSD+Current&arch=i386&format=html , not something like mmm this can be here in /usr/bin, this will be in /usr/local/bin. this will be in /opt, this will be here and here and here and here and ou I'm a developer so place something here (eg. directly to /) just because I'm developer and I want to reinvent wheel like on other systems. Eg. I like OpenSolaris too, but its hierarchy is quite crazy for me in some cases http://docs.sun.com/app/docs/doc/819-2252/filesystem-5?l=en&a=view it's because of mix of System V and BSD and some other additions sometimes to find something is like adventure game :-) Reagarding CVS... OpenBSD use it's own AnonCVS and I think that it works well for its purpose. You can read in-deep info here http://www.openbsd.org/papers/anoncvs-paper.ps , quite old, but I read it last week and it was very descriptive and useful for me. Style of kernel is described well here http://www.openbsd.org/cgi-bin/man.cgi?query=style&apropos=0&sektion=0&manpat h=OpenBSD+Current&arch=i386&format=html There are manuals how to build ISO either for CD-ROM or USB flash disk so you don't need something special. Just read FAQ and if you want you can make shell scripts for those purposes or write some app with language which is in base and if it will be ok maybe it will end in base system. Eg. http://www.openbsd.org/faq/faq14.html#flashmemLive So in short there are good tools available right now and system is prepared too. In fact it's quite boring in production because it just works and works and works and works so you don't need to fight fight it like with other systems (of course that bugs are even in OpenBSD, but main source of bugs with OpenBSD is between keyboard and chair). Maybe you have good idea in some points, but it's not good idea to have too much multiple tools on one task. I tested DragonflyBSD right now and they have 5(!) tools for packgae installation anyway no one from them was able to install Xorg correctly (maybe problem of VM). I don't think that this mess will help somehow to sysadmin, developer or user. On Sat, Dec 26, 2009 at 9:48 PM, David Shuman <d.shu...@att.net> wrote: > I am somewhat new to OpenBSD but not systems and/or > systems programming as a whole. B Please excuse any errors > I may have made in my observations and desires. B Please > also feel free to pick and choose between the aspects of > this that appear to be valuable. B (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. B 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. B The directories for many of the operations > appear to be "hard coded" in some of the make scripts to specific > directories. B 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 B B B B B B B B B B B root directory for build operation > B B B B B B B B B B B B B B B B B (no data this directory/mount only other > B B B B B B B B B B B B B B B B B directories except for the > B B B B B B B B B B B B B B B B B B B B shell scripts and logs) > /bld/sh B B B B B B B B shell scripts to complete various build processes > B B B B B B B B B B B B B B B (see list below) > /bld/sh/log B B B B B B location to store logs from build scripts > B B B B B B B B B B B B B B B B from the following basic command > B B B B B B B B B B B B B B B B B B B B sh build_script >log/build_script.log > /bld/sh/logrlse? B B release version of the logs for diff compare > /bld/sh/logprior? B prior version of the logs for diff compare > /bld/cvs B B B B B B B B (no data in this directory) > /bld/cvs/src B B B B B (src.tar.gz B B B B B current /usr/src) > /bld/cvs/src/sys B B (sys.tar.gz B B B B B current /usr/src/sys) > /bld/cvs/ports B B B (ports.tar.gz B B B current /usr/ports) > /bld/cvs/xenocara (xenocara.tar.gz current /usr/xenocara) > /bld/obj B B B B B B B B (no data in this directory) > /bld/obj/kernel? B B (kernel obj B B B B current ?) > /bld/obj/userland B (userland obj B B B current /usr/obj) > /bld/obj/xenocara (xenocara obj B B current /usr/xobj)) > /bld/dest/ B B B B B B B (no data in this directory) > /bld/dest/userland B (output B B B B B B B current /usr/dest) > /bld/dest/xenocara (output B B B B B B B current /usr/xdest?) > /bld/rlse B B B B B B B B (no data in this directory) > /bld/rlse/src B B B B B (*.tar.gz for cvs_preload(, etc - /bld/sh?)) > /bld/rlse/{ver}/{arch} B 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. B (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. > B ie. it would be nice if you could > B B B sudo build {script) > B B B and have the above command execute in one task > B B B B B B B B sh /bld/sh/{script} >/bld/sh/log/{script}.log > B B B and in another task tied to the console window > B B B B B B B B tail -f B /bld/sh/log/{script}.log > B B B B B B B B with this task returning the command prompt > B B B B B B B B B B upon closing of the log file (based on the > B B B B B B B B B B end of the first task). > > B B B sudo log {script} {log | logrlse | logprior} {file} > B B B would be used to copy > B B B B B B B /bld/{log | logrlse | logprior}/{script}.log > B B B B B B B to a user accessible file -- to edit and/or B B B B B B B submit > as documentation for errors > B B B B B B B requiring assistance. > > B B B sudo diff {flags} {script} {logrlse | logprior} > B B B B B B diff {flags} /bld/sh/log/{script}.log B \ > B B B B B B B B /bld/sh/{logrlse | logprior}/(script}.log > > note based on the above > B B 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). B Likewise for the users to check the initial > install if the logs are included on the full install CD as noted. B 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.) B 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 > B - 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. > B B B B B B B B B B B B B Current estimate of size > Mount Point B B B B B 50% utilization for -stable > /bld/rlse B B B B B B B B (1792m) > /bld/dest B B B B B B B (1792m) > /bld/cvs/src/sys B B (256m) > /bld/obj B B B B B B B B (2560m) > /bld/cvs B B B B B B B B (3580m) > > I suggest slices l - p for these. > Note because > B B cd /bld/cvs/sys > B B tar cvzfX /bld/rlse/src/src.tar.gz > does not exclude the sys subdirectory > B B (note mount point above) > B B so I wrapper the commands with > B B B B B B umount /dev/{?} > B B B B B B cd /bld/cvs/src > B B B B B B tar cvzf /bld/rlse/src/src.tar.gz > B B B B B B 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 B - copies /mnt/{ver}/{arch} from CD > B B B B B B B B B B B B B to /bld/rlse/{ver}/{arch} > B B B B B B B B - this may not be desirable > B B B B B B B B B B B B (opinions anyone?) > > Script on new source CD (release, stable or custom) > CD contents B B - script install_src (see below) > B B B B B B B B B B B - /bld/sh or sh.tar.gz (shell scripts (and logs?)) > B B B B B B B B B B B - /bld/rlse/src (*.tar.gz - various sources) > install_bld B B B B - copies /mnt/src from CD > B B B B B B B B B B B B B B B B to /bld/rlse/src > B B B B B B B B B B B - copies from /mnt/sh or > B B B B B B B B B B B B B B B B B B tar extract from sch.tar.gz > B B B B B B B B B B B B B B B B to /bld/sh > > /bld/sh B probable scripts in stated processing order > > tune_bld B - sets average file size to 8192? for > B B B B B B B B B B B /bld/dest > B B B B B B B B B B B /bld/cvs/src/sys, > B B B B B B B B B B B /bld/obj, > B B B B B B B B B B B /bld/cvs, > B B B B B B B - should be edited as appropriate for > B B B B B B B B B B B the user's installation > > cvs_preload B - tar extract from /bld/rlse/src > B B B B B B B B B B B B B B B B B B B B B to /bld/cvs ... as appropriate > B B B B B B B B B B - edit as desired > > cvs_checkout - checkout of the CVS source to /bld/cvs > B B B B B B B B B B - edit for anoncvs server > B B B B B B B B B B - edit for directories > > cvs_update B B - update of the CVS source to /bld/cvs > B B B B B B B B B B - edit for anoncvs server > B B B B B B B B B B - edit for directories > > bld_kernel B B B - build a new kernel > > install_kernel B - install new kernel > > {reboot} > > bld_userland B B - build userland > > bld_release B B B - construct release components for userland > > chk_release B B B - check the userland release > B B B B B B B B B B B - create index.txt > > bld_xenocara B - build xenocara (X) > > bld_releasex B B - construct release components for xenocara > B B B B B B B B B B B - create updated index.txt > > src_release B B B - construct release sources > B B B B B B B B B B B B B B B B B for existing release components > B B B B B B B B B B B - (backup / transfer) > B B B B B B B B B B B - edit for /dev/? unless tar X or another > B B B B B B B B B B B B B B B option can do this. > B B B B B B B B B B B - create index.txt > > (I have not created these yet, but I probably could, if desired) > > clear_shlogs B B B - rm -rf /bld/sh/log/* > > copy_shlogs B B B - 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 B - create a networked ISO for release binaries > > iso_full_release B - create a full ISO for release files, etc > B B B B B B B B B B B B - include /bld/sh/logrlse or > B B B B B B B B B B B B B B B B B B B logrlse.tar.gz > B B B B B B B B B B B B B B B (shell scripts and logs - if space allows) > > iso_source B B B B - create an ISO of source tar files, etc > B B B B B B B B B B B - 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 B B B B - burn the source ISO - backup, etc > > > There could even be a DVD ISO that contains both the release > B (or stable or custom (pkg or code)) binaries, sources and logs. > Thanks for reading this. B I hope it is considered valuable. > > -- http://www.openbsd.org/lyrics.html
