FreeBSD vs Linux

[Glenn Dawson]

At 09:23 PM 4/20/2005, Kevin Kinsey wrote:

>Nothing spectacular, to be sure.  I simply noticed that I
>have done a lot of things to set up a server or whatever,
>and they can easily be scripted.  I'm certainly no shell
>scripting expert (A month ago I would have tried this
>in PHP, but there's a little "chicken/egg" problem there,
>and /bin/sh is really made for this stuff).  Here's the rough outline:
>
>1.  Install a base system manually with sysinstall.  Make
>sure that a source tree and ports tree exists by some manual
>means (like the aforementioned sysinstall).  Make sure in BIOS
>that the system will boot with a floppy in the drive (priority to
>HD).
>
>2.  On a floppy I have three scripts, we'll call 'em
>"install", "setup1", "setup2"; and supfiles for
>-STABLE and ports.  Mount the floppy and run
>"install" with a $SERVERTYPE argument ....
>
>3.  "install" copies the supfiles from floppy to
>a location on the machine's filesystem.  It then
>copies "setup1" and "setup2" to /tmp/ and makes
>sure that they are executable.  Having received
>an argument that tells the script what type of
>machine we're setting up, it calls /tmp/setup1
>with that argument....
>
>4.  "setup1" checks for the existence of the
>ports tree, then builds cvsup-without-gui
>from ports.  (This seems to be one Achilles tendon).
>It then runs cvsup on the src tree, builds world,
>builds a generic kernel, installs it, copies root's
>crontab to /tmp/ and adds an "@reboot" command
>pointing to /tmp/setup2 with the server type argument
>to the root crontab.  It then calls "shutdown -r".
>
>5.  When the machine comes back up on the new
>kernel, cron calls "setup2", which sleeps a little
>(?maybe?) and then does some checks and installs
>the newly created world.  I've not decided how to
>handle mergemaster.  Setup2 adjusts make.conf
>and builds a list of ports to be installed based on
>the command line argument.  The ports tree
>gets cvsupped, and each port is installed in
>turn.  The backup copy of root's crontab is
>restored to its proper place so that the script
>isn't called anymore.  The scripts deletes as
>much of my stuff as possible, and exits.
>
>That's about the size of it.  My code isn't pretty,
>as I'm not real experienced with /bin/sh, but
>after some testing I might get it out for viewing,
>although it seems simple enough (to me) that
>anyone could follow this outline and make it
>happen for themselves...IOW, I can't believe that
>somebody out there doesn't have something like
>this already, and I'm quite sure that they do, (unless
>maybe they just image HD's instead?)
>
>And I see no reason why it couldn't be expanded
>to do a lot of other stuff as well.  Scripting is just
>"doing what you'd do yourself" in code, so you can
>do something else, after all...I used to sit at terminals
>and watch "buildworld" happen ... now I'm generally
>past that ;-) although I've not yet been brave enough
>to have my buildworld scripts call "shutdown" for
>themselves on my production boxes....

Most of this seems like it could be much more easily handled with something 
like cfengine (/usr/ports/sysutils/cfengine, and 
http://www.cfengine.org/).  Especially when adding machines to an existing 
network with similarly configured systems.

-Glenn


>Kevin Kinsey
>_______________________________________________
>freebsd-questions at freebsd.org mailing list
>http://lists.freebsd.org/mailman/listinfo/freebsd-questions
>To unsubscribe, send any mail to "freebsd-questions-unsubscribe at freebsd.org"