Date: Fri, 17 Mar 2000 14:01:29 -0500 From: Forrest Aldrich <forrie@forrie.com> To: Andrew Gordon <arg@arg1.demon.co.uk> Cc: freebsd-current@freebsd.org Subject: Re: Streamlining FreeBSD Installations Message-ID: <4.3.1.2.20000317135945.00b55150@216.67.12.69> In-Reply-To: <Pine.BSF.4.21.0003171805450.12953-100000@server.arg.sj.co. uk> References: <4.3.1.2.20000317074445.00b60d90@216.67.12.69>
next in thread | previous in thread | raw e-mail | index | archive | help
This wouldn't work in our situation, where we are needing to modify data... so if there were a power outage, imagine the hassle. Good idea, though. Most of our systems have 64 - 128mb of ram. They are doing distributed status monitoring and secondary DNS. So, there would be a bit of changes happening from time-to-time. But again, I doubt this would work for us. From the private emails I've received on this topic, it seems that the consenus is to spiff up sysinstall, which is probably the right place to begin with some of this stuff. Not sure who maintains it. _F At 06:56 PM 3/17/00 +0000, Andrew Gordon wrote: >On Fri, 17 Mar 2000, Forrest Aldrich wrote: > > I was also curious about what people do to keep a fleet of FreeBSD > machines > > up-to-date with CVSup and buildworld. I can't imagine manually going to > > more than 100 machines and doing the same thing manually... how time > consuming. > > > > To summarize again, we are deploying status monitoring machines into POPs, > > across the US. Those machines are identical in terms of hardware, et > > al. We were hoping to find a means by which to streamline the > installation > > process, such that we could create (say) custom boot floppies where you'd > > input minimum information (IP address, hostname, domain, etc.) and it > would > > then go off and perform the installation (from fdisk, newfs... to editing > > packet filters appropriately, which make require a "template" of sorts). > >If the job they are doing is fairly simple, and they have (or could >have) plenty of RAM, have you considered scrapping the disc drives and >having a CD-boot system? > >Although CD drives are not very reliable for heavy-duty use, you should be >able to arrange that the working set gets loaded at start-up and the CD is >then idle in all normal use - this may "just work" through normal caching, >or you may need to copy active files onto an MFS filesystem (you'll need >an MFS for various things anyhow). This has the advantage over pico-BSD >style installations that you can fill the rest of the CD with a fairly >complete FreeBSD installation: in normal use the CD drive is idle, but >you have the full set of tools available for use on rare occasions when >they are needed. > >Obviously the machines need to pick up their identities from somewhere, as >you want to just duplicate a stack of identical CDs. If the machines can >rely on their environment, DHCP is the obvious way to go; if not, one >technique I've used is to key it on the MAC address of the ethernet card >(in /etc/rc I pick up the MAC address with ifconfig and then have a big >case statement to set up the different characteristics of the machines). > >Obviously this doesn't suit every application, but I have found it highly >advantageous when I want to put down a BSD machine in a location with no >local BSD skills to fix things if they go wrong. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4.3.1.2.20000317135945.00b55150>