From owner-freebsd-stable Wed Sep 17 08:09:19 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA17560 for stable-outgoing; Wed, 17 Sep 1997 08:09:19 -0700 (PDT) Received: from obie.softweyr.ml.org ([199.104.124.49]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA17536 for ; Wed, 17 Sep 1997 08:09:13 -0700 (PDT) Received: (from wes@localhost) by obie.softweyr.ml.org (8.7.5/8.6.12) id JAA02121; Wed, 17 Sep 1997 09:12:11 -0600 (MDT) Date: Wed, 17 Sep 1997 09:12:11 -0600 (MDT) Message-Id: <199709171512.JAA02121@obie.softweyr.ml.org> From: Wes Peters To: Robert Withrow CC: stable@freebsd.org Subject: Minor problems with upcomming 2.2.5 In-Reply-To: <199709171412.KAA09701@tuva.engeast.baynetworks.com> References: <199709171412.KAA09701@tuva.engeast.baynetworks.com> Sender: owner-freebsd-stable@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Robert Withrow writes: > I have great hopes of deploying FBSD 2.2.5 widely here in this SUNOS shop. > To do this I would need to be able to have people install and run > FBSD essentially ``out of the box''. To date this has not been possible > for any prior version of FBSD due to various problems in the installation > and in the code, stimulated by our environment---the largest problem > areas have been with NFS and AMD, heavily used here. I don't know that this is really something the FreeBSD team should concern themselves with -- customizing FreeBSD for your site. It seems to me the appropriate way to handle this would be to install the FreeBSD release on a "virgin" machine at your site, configure it exactly how you need it, including building a new kernel, etc., then create your own distribution media from that. You could, for instance, put all of the files on a machine and do ftp installs on all other machines. I've seen the procedure for making your own distribution set documented somewhere, but don't remember where. A search of the archives on the web site should help. > 2) I need the following patch to be made to rc.network. This is because > *all* of our AMD maps are in NIS. Thus my rc.conf.local has a line like > this: > > amd_flags='-c 3600 -l syslog `ypcat -k amd.master`' > > NOTE THE "'" quoting? That is *necessary* because NIS is not up at the > time when rc.conf.local is sourced! The patch addes the necessary extra > level of evaluation at the correct time (when AMD is being started and > NIS is already up): > > *** rc.network~ Sun Sep 14 08:32:10 1997 > --- rc.network Tue Sep 16 15:17:47 1997 > *************** > *** 186,192 **** > > if [ "X${amd_enable}" = X"YES" ]; then > echo -n ' amd' > ! amd -p ${amd_flags} > /var/run/amd.pid 2> /dev/null > fi > > if [ "X${rwhod_enable}" = X"YES" ]; then > --- 186,192 ---- > > if [ "X${amd_enable}" = X"YES" ]; then > echo -n ' amd' > ! eval amd -p ${amd_flags} > /var/run/amd.pid 2> /dev/null > fi > > if [ "X${rwhod_enable}" = X"YES" ]; then Sounds like this patch is needed for any setup using nis to distribute the amd maps to work. I don't think many FreeBSD users are heavily using amd and nis, so this is good test data. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://www.xmission.com/~softweyr softweyr@xmission.com