cvs commit: src/gnu/usr.bin Makefile src/lib Makefile src/sbin Makefile src/usr.bin Makefile src/usr.sbin Makefile

[Peter Jeremy]

On Fri, Aug 29, 2003 at 12:14:17PM -0700, Nate Lawson wrote:
>On Fri, 29 Aug 2003, David O'Brien wrote:
>> On Fri, Aug 29, 2003 at 09:08:35AM -0400, Robert Watson wrote:
>> > On Fri, 29 Aug 2003, Poul-Henning Kamp wrote:
>> >
>> > >   NO_TOOLCHAIN    skips Compilers and Binutils
>> > >   NO_USB          skips USB stuff
>> > >   NO_VINUM        skips Vinum stuff
>> > >   NO_ACPI         skips ACPI stuff
>> >
>> > Great!  I was hoping this would be the outcome of the Minimalist FreeBSD
>> > discussion.
>>
>> Was there a discussion somewhere that most of us missed?
>
>Hmm, missed it also.  In general I'm in favor of this but would prefer to
>see these also defined under a single knob (MINIMAL?). 

I'd like to disagree here.  What you see as essential in a minimal
system might be irrelevant to me and vice versa.  2.x PicoBSD was
probably the first real attempt at 'minimal' and it came in four
versions (including 'custom') to meet different requirements.  If you
take something like PicoBSD as a minimal system, does the 'minimal'
know give you the union or intersection of the various PicoBSD
variants?  In the former case, you have something that's slightly more
than minimal and in the latter case, you need to add a few more bits
to reach a usable system.

At the extreme, 'minimal' amounts to /boot/kernel/kernel.ko,
/sbin/init and /bin/sh with some user-defined shellscripts (ISTR that
/boot/loader is optional again).  This is likely to be too minimalist
for most purposes though.

>  Before we get too many NO_*,
>perhaps people who are actually building commercial and personal small
>distributions could share some of their needs and experiences.

I've adapted a version of 4.x for remote support purposes at work.  A
number of systems are installed in customer premises to provide serial
console logging (using conserver) for the application systems as well
as remote access via modem.  Several systems are also installed in our
DMZs as the 'local' end.  These systems run Apache as a proxy cache to
provide remote GUI management of our application.  Footprint isn't an
issue (the first systems had 9GB disk, the latest ones have 72GB disk)
but security is and I've been hacking out anything that didn't seem
necessary to make the systems as difficult as possible for unauthorised
people to get into or use.

The boxes originally came with a coloured head-covering installed but
even our resident Linux expert didn't feel that he could confidently
secure the boxes.  I pushed for FreeBSD because I was confident I
understood it well enough to produce an adequately secure result.

My approach has been a mixture of customised buildworld (removing
unwanted SUBDIR entries from both Makefile.inc1 and subsidiary
Makefile's) and a hacked combination of 'make installworld' and 'make
release' that includes some judicious 'rm -r' commands.

The actual installation is done using standard sysinstall with a
customised procedure (I thought this would be quicker than developing
a customised install script since we only originally thought we'd have
to build about 6 systems).  This also saved me the pain of building
the boot images.

The resultant install image is about 20MB compressed.  I could make
it smaller but there's no pressure to do so.  I have found that the
removal of tcpdump in particular made debugging some network issues
more difficult and will probably review the approach when I upgrade
the base system.

Peter