My Recommended Development/Testing environment for -current
Matt Dillon writes:
> * On my -STABLE box I build the -current world. I usually
> try to build it -DNOCLEAN but if that fails I just rebuild it from
> scratch. NOTE!!! DO NOT ACCIDENTLY TRY TO INSTALL THE -CURRENT WORLD
> ON YOUR STABLE BOX!!!
>
> stable> cd /FreeBSD/FreeBSD-current/src
> stable> make -DNOCLEAN -j 10 buildworld
>
> * On my -STABLE box I build the -current kernel. Again I try to use
> -DNOCLEAN to reduce [re]compilation times, but just build it from
> scratch too some times. NOTE!!! DO NOT ACCIDENTLY TRY TO INSTALL
> THE -CURRENT KERNEL ON YOUR STABLE BOX!!!
>
One problem - in such testing you newer see problems building world on
-CURRENT, so without below patch world not builds on my -CURRENT
--- src/gnu/usr.bin/perl/Makefile.inc.orig Thu May 31 15:04:52 2001
+++ src/gnu/usr.bin/perl/Makefile.inc Fri Sep 7 13:22:09 2001
@@ -41,7 +41,7 @@
done ;\
for i in `cd ${PERL5SRC}; find $${d} -type f | grep -v CVS` ;\
do \
- ln -s ${PERL5SRC}/$${i} $${i} ;\
+ ln -sf ${PERL5SRC}/$${i} $${i} ;\
done ;\
done
@ln -sf ${PERL5SRC}/ext/File/Glob/Glob.pm lib/File/Glob.pm
Sometime I am use a bit different scheme, on my -STABLE box I have cvsup and
source tree, it mounted through NFS to -CURRENT box read-only, and above it
mounted unionfs tree for building and changing sources.
> -Matt
--
TSB Russian Express, Moscow
Vladimir B. Grebenschikov, [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
RE: My Recommended Development/Testing environment for -current
On 28-Aug-01 Matt Dillon wrote: > I'm posting this as an aid to everyone doing freebsd-current development > and testing and may not realize how easy it is to setup a development > environment. Nice stuff and close to what I do (I just share a development sys tree over NFS now). One thing I do in regards to kernels is this, /boot/kernel/kernel is a clean kernel, i.e. from a clean current source, not any of my development trees. Kernels in development trees use stuff like this: makeoptions KERNEL=smpng in their kernel config files so I have /boot/smpng/kernel, /boot/test/kernel, /boot/preempt/kernel, etc. for my development tree kernels. This avoids needing to keep a kernel.good around, as /boot/kernel/kernel is always ok. -- John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: My Recommended Development/Testing environment for -current
On Tue, 28 Aug 2001, The Anarcat wrote: >On Tue, 28 Aug 2001, Brandon D. Valentine wrote: > >> On Tue, 28 Aug 2001, Matt Dillon wrote: >> >[snip of diskless comments] > >You wouldn't happen to have sample configs around, wouldn't you? :) >> Am-utils (the contrib source for our amd) has been kicking around autofs >> support for a while now but still does not appear to have anything >> release quality. > >Am-utils, while being a quite complex piece of software, does fullfil >the task of "autofs". It does need extra configuration compared to >Linux's autofs though. For the record, I automount my cdr, cdrom, zip >and floppy drives (both in ufs and msdos mode) using this configuration >files: I do believe you have misunderstood. My complaint is that am-utils requires the type of config files you pasted here. Most every other unix operating system, Linux and the commercial unices, now comes with an autofsd/automountd which uses the auto.master/auto.* config file format which requires far less configuration and is *interoperable* in a heterogenous environment. On each of the SGIs and the Linux box here I have an /etc/auto.master that does little more than +auto.master which includes a NIS map that works everywhere. This is not nearly as easy with the standard BSD amd. -- "Never put off until tomorrow what you can do today. There might be a law against it by that time." -- /usr/games/fortune, 07/30/2001 Brandon D. Valentine To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: My Recommended Development/Testing environment for -current
On Tue, 28 Aug 2001, Brandon D. Valentine wrote: > On Tue, 28 Aug 2001, Matt Dillon wrote: > [snip of diskless comments] You wouldn't happen to have sample configs around, wouldn't you? :) > I will say though, on the subject of NFS, that one of the things that > I'm almost annoyed enough with to start hacking on is the BSDs lack of > autofs support. Linux now has a kickass autofs automounter. The BSDs > are, to the best of my knowledge, the only OS left without one. Wrong. > Am-utils (the contrib source for our amd) has been kicking around autofs > support for a while now but still does not appear to have anything > release quality. Am-utils, while being a quite complex piece of software, does fullfil the task of "autofs". It does need extra configuration compared to Linux's autofs though. For the record, I automount my cdr, cdrom, zip and floppy drives (both in ufs and msdos mode) using this configuration files: ---8<--- Cut here [amd.mnt] -8< cdr type:=cdfs;fs:=/cdr;dev:=/dev/cd0c;opts:=ro,nodev,nosuid cdrom type:=cdfs;fs:=/cdrom;dev:=/dev/acd0c;opts:=ro,nodev,nosuid fat type:=pcfs;fs:=/fat;dev:=/dev/fd0;opts:=nosuid,nodev flp type:=ufs;fs:=/flp;dev:=/dev/fd0;opts:=nosuid,nodev zip type:=ufs;fs:=/zip;dev:=/dev/afd0;opts:=nosuid,nodev zap type:=pcfs;fs:=/zap;dev:=/dev/afd0s4;opts:=nosuid,nodev ---8<--- Cut here [amd.mnt] -8< ---8<--- Cut here [amd.conf] -8< [ global ] normalize_hostnames =no print_pid = no restart_mounts = yes #auto_dir = /n log_file = /var/log/amd log_options =all #debug_options = all plock = no cache_duration =6 dismount_interval = 20 selectors_on_default = yes # config.guess picks up "sunos5" and I don't want to edit my maps yet os = sos5 # if you print_version after setting up "os", it will show it. print_version = no map_type = file search_path = /etc/amdmaps:/usr/lib/amd:/usr/local/AMD/lib:/etc browsable_dirs = yes [ /mnt ] map_name = amd.mnt ---8<--- Cut here [amd.conf] -8< I think I will dare opening a pr making this default config files. :) > It's a nuisance to have to run special scripts to > parse your auto.* maps into stuff amd can understand in an NIS > environment. I am not sure I completely understand that, but you must expect having to reconfigure stuff to accomodate new software... I guess you want to port autofs to fbsd, eh? :) A. PGP signature
Re: My Recommended Development/Testing environment for -current
On Tue, Aug 28, 2001 at 11:14:29AM -0700, Matt Dillon wrote: > Delivered-To: [EMAIL PROTECTED] > Delivered-To: [EMAIL PROTECTED] > Date: Tue, 28 Aug 2001 11:14:29 -0700 (PDT) > From: Matt Dillon <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: My Recommended Development/Testing environment for -current > List-ID: > List-Archive: <http://docs.freebsd.org/mail/> (Web Archive) > List-Help: <mailto:[EMAIL PROTECTED]?subject=help> (List Instructions) > List-Subscribe: <mailto:[EMAIL PROTECTED]?subject=subscribe%20freebsd-current> > List-Unsubscribe: ><mailto:[EMAIL PROTECTED]?subject=unsubscribe%20freebsd-current> > X-Loop: FreeBSD.ORG > Precedence: bulk > > I'm posting this as an aid to everyone doing freebsd-current development > and testing and may not realize how easy it is to setup a development > environment. Extremely helpful and well written, thanks. Is this posted any place in a publicly available form such as a tutorial or article? -sc -- Sean Chittenden PGP signature
Re: My Recommended Development/Testing environment for -current
On Tue, 28 Aug 2001, Matt Dillon wrote: >I'm posting this as an aid to everyone doing freebsd-current development >and testing and may not realize how easy it is to setup a development >environment. I found this very helpful Matt, thank you. I would only add one thing that I do in addition to some of these NFS tricks. The only machines at home which I presently keep hard drives in are my file server, firewall, and desktop. Everything else netboots off of the file server. This is very convenient because I can keep multiple NFS roots around and simply edit a text file, HUP a daemon, and power cycle a machine to alter which OS and/or OS revision it's running. Switched fast ethernet is more than enough to keep up with this on the 10 or so machines I have up and running at any given time. It works quite well. I will say though, on the subject of NFS, that one of the things that I'm almost annoyed enough with to start hacking on is the BSDs lack of autofs support. Linux now has a kickass autofs automounter. The BSDs are, to the best of my knowledge, the only OS left without one. Am-utils (the contrib source for our amd) has been kicking around autofs support for a while now but still does not appear to have anything release quality. It's a nuisance to have to run special scripts to parse your auto.* maps into stuff amd can understand in an NIS environment. -- "Never put off until tomorrow what you can do today. There might be a law against it by that time." -- /usr/games/fortune, 07/30/2001 Brandon D. Valentine To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
My Recommended Development/Testing environment for -current
I'm posting this as an aid to everyone doing freebsd-current development and testing and may not realize how easy it is to setup a development environment. The number one thing is: Don't put the CVS tree or source code on the -current box itself, except for testing purposes. This is what I do: * On my -STABLE box I cvsup the CVS tree nightly (/home/ncvs) from cron: stable> /usr/local/bin/cvsup -g -r 20 -L 2 -h cvsupXXX.freebsd.org /usr/share/examples/cvsup/cvs-supfile * On my -STABLE box I use 'cvs checkout' and 'cvs update' as appropriate to keep a -current source hierarchy up to date. In my case: stable> cd /FreeBSD stable> mkdir FreeBSD-current stable> cd FreeBSD-current stable> cvs -d /home/ncvs checkout src I do the cvs updates manually, depending on what I am testing: stable> cd /FreeBSD/FreeBSD-current/src stable> cvs update * On my -STABLE box I build the -current world. I usually try to build it -DNOCLEAN but if that fails I just rebuild it from scratch. NOTE!!! DO NOT ACCIDENTLY TRY TO INSTALL THE -CURRENT WORLD ON YOUR STABLE BOX!!! stable> cd /FreeBSD/FreeBSD-current/src stable> make -DNOCLEAN -j 10 buildworld * On my -STABLE box I build the -current kernel. Again I try to use -DNOCLEAN to reduce [re]compilation times, but just build it from scratch too some times. NOTE!!! DO NOT ACCIDENTLY TRY TO INSTALL THE -CURRENT KERNEL ON YOUR STABLE BOX!!! stable> cd /FreeBSD/FreeBSD-current/src stable> make [-DNOCLEAN] buildkernel KERNCONF=BLAHBLAH * On my -CURRENT box I install via *** READ ONLY *** NFS mounts. The setup for this is typically: current> mount stable:/FreeBSD /FreeBSD current> mount stable:/usr/obj /usr/obj current> rm -rf /usr/src current> ln -s /FreeBSD/FreeBSD-current/src /usr/src Actual installation of world: current> cd /usr/src current> make installworld Actual installation of kernel: current> cd /usr/src current> make installkernel KERNCONF=BLAHBLAH Note that the development environment is on your -stable machine... that is where you are doing the builds. The only thing you need to do on your -current box is to install them via NFS. * To test the -CURRENT box, i.e. running buildworld on the -current box as a test, I simply unmount /usr/obj and do a buildworld. The source is still NFS mounted from the -STABLE box, but the actual compile runs on the -current box and the results are 'throw away' (meaning that it doesn't screw up the development environment sitting on my -stable machine). current> umount /usr/obj current> cd /usr/src current> /usr/bin/time make -j 30 buildworld - KEEPING AN EMERGENCY BACKUP KERNEL When you have a -current kernel that is able to successully installworld and installkernel, and seems to be relatively crash free, you should make a backup of it so you can boot from it. I usually do this: current> cp /kernel /kernel.bak I do not rely on 'kernel.old' since multiple installkernel's will overwrite it. Also, don't rely on KLD's since the backup kernel may not be compatible with the most recently installed module directory. FIREWALL SHOULD BE OPEN BY DEFAULT ON THE CURRENT MACHINE If your -current kernel config is turning on firewall support, aka IPFIREWALL, you should also make the filter permissive by default, aka IPFIREWALL_DEFAULT_TO_ACCEPT. If you don't do this and your (backup) kernel and the ipfw binary get out of sync, you won't be able to use ipfw to open up holes for NFS and such and your backup kernel will be S.O.L. NFS-BASED SOURCE AND NFS-BASED /USR/PORTS ENVIRONMENT STABLE MACHINE "/etc/exports": The export contains non-proprietary data and is read-only, so it is fairly safe to export it generally. If you do not have anything proprietary installed in /usr (e.g. in /usr/local), you can export /usr -alldirs to allow clients to pickup /usr/obj and /usr/ports. /FreeBSD -ro -maproot=root: -network 10.0.0.0 -mask 255.0.0.0 /usr -ro -alldirs -maproot=root: -network 10.0.0.0 -mask 255.0.0.0 # if /usr/obj a separate mount pt on your box #/usr/obj -ro -maproot=root: -network 10.0.0.0 -mask 255.0.0.0 STABLE MACHINE "/usr/ports" topology. This allows you to export /usr/ports read-only via NFS and still allow each client to build and install its own ports: stable> cd /usr/ports stable> rm -rf distfiles stable> ln /usr/ports.distfiles distfiles stable> mkdir
