small install
Randy Bush
o for a rather small but not pico system, 32m ram and 512m hd
see <http://www.wildlab.com/>
o not have games, compiler, ... but need networking of course
o do the install onto an ibm microdrive on my laptop which i then
push into the tiny machine
are there clues, howto, ... somewhere?
randy
To Unsubscribe: send mail to majo...@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message
Roddy Collins
> so if i want to build/install world
> o for a rather small but not pico system, 32m ram and 512m hd
> see <http://www.wildlab.com/>
> o not have games, compiler, ... but need networking of course
> o do the install onto an ibm microdrive on my laptop which i then
> push into the tiny machine
>
> are there clues, howto, ... somewhere?
I used the steps at http://neon1.net/misc/minibsd.html with great
success to get 4.7-PRE into 14 megabytes onto a flash card for a
firewall.
-Roddy
Andrew Gordon
On Fri, 4 Oct 2002, Roddy Collins wrote:
> On Fri, Oct 04, 2002 at 12:17:42AM -0700, Randy Bush wrote:
> > so if i want to build/install world
> > o for a rather small but not pico system, 32m ram and 512m hd
> > see <http://www.wildlab.com/>
> > o not have games, compiler, ... but need networking of course
> > o do the install onto an ibm microdrive on my laptop which i then
> > push into the tiny machine
> >
> > are there clues, howto, ... somewhere?
>
> I used the steps at http://neon1.net/misc/minibsd.html with great
> success to get 4.7-PRE into 14 megabytes onto a flash card for a
> firewall.
That page has some good stuff on it, but the very first hint is rather
bogus. You don't need a complete separate drive/partition for doing
'installworld' into: you can specify a target directory:
cd /usr/src
make DESTDIR=/some/handy/place installworld
Similarly, if you are doing a separate buildworld to use different make
options (eg. for dynamic linking) you can use MAKEOBJDIRPREFIX to put the
build directory somewhere different if you want to preserve the host
machine's /usr/obj (though I don't usually bother).
Also, I normally specify different make options on the command line
(actually a 2-line shellscript to save typing!) rather than editing
/etc/make.conf - though this is all a matter of personal taste.
Glenn Trewitt
making a jail or some such. I've attached a script that I used to build
kernel/world, and it gets the result (which still has a lot of cruft
that you won't want to copy over) down to 83 MB.
I use environment variables instead of command line options, and set a
whole bunch of "don't build this" variables that are interpreted by the
various Makefiles under /usr/src. Anyway, here's the script...
- Glenn Trewitt
#! /bin/sh
# Change this to suit your needs.
DESTDIR=/s1/soekris
# Just for testing...
#NOCLEAN=1 export NOCLEAN
KERNCONF=SOEKRIS
# Don't build or install kernel modules
NO_MODULES=1 export NO_MODULES
LOCAL_DIRS=/usr/src/release/picobsd/tinyware/simple_httpd
# These I'm not sure about.
NOCRYPT=1 export NOCRYPT
# Broad categories of things to exclude.
NOPROFILE=1 export NOPROFILE
NOGAMES=1 export NOGAMES
NOSHARE=1 export NOSHARE
NOINFO=1 export NOINFO
NO_PORTSUPDATE=1 export NO_PORTSUPDATE
NO_DOCUPDATE=1 export NO_DOCUPDATE
NO_SHAREDOCS=1 export NO_SHAREDOCS
NOMAN=1 export NOMAN
# Specific programs/subsystems to exclude
NO_CXX=1 export NO_CXX
NO_OBJC=1 export NO_OBJC
NO_GDB=1 export NO_GDB
NOLIBC_R=1 export NOLIBC
NO_FORTRAN=1 export NO_FORTRAN
NOPERL=1 export NOPERL
NO_X=1 export NO_X
NO_SENDMAIL=1 export NO_SENDMAIL
NO_MAILWRAPPER=1 export NO_MAILWRAPPER
NOUUCP=1 export NOUUCP
NO_LPR=1 export NO_LPR
NO_I4B=1 export NO_I4B
NO_OPENSSL=1 export NO_OPENSSL
NO_GDB=1 export NO
# Here's where we actually do the work.
cd /usr/src
make buildkernel KERNCONF=$KERNCONF
make buildworld
make installkernel KERNCONF=$KERNCONF
make installworld
Michael Sierchio
> DESTDIR=/s1/soekris
If you're doing IPSec or PPTP or any VPN you may want OpenSSL,
since it's the source of the crypto libs, and hardware support
for the vpn card is available via Sam Leffler's OpenBSD /dev/crypto
patches to -STABLE as of 08/xx/2002. This causes kern_random to
use the HW RBG on the HiFn chip, and the OpenSSL Engine code uses
the crypto functions of the chip.
It seems that ENGINE is not included in the base install of OpenSSL,
which caused some confusion during my first attempt to apply the patch,
but is easily remedied.
I question whether you'd want any compiler at all on a firewall...
Oliver Fromme
> If you're doing IPSec or PPTP or any VPN you may want OpenSSL,
Not necessarily.
> since it's the source of the crypto libs, and hardware support
> for the vpn card is available via Sam Leffler's OpenBSD /dev/crypto
Work has been done to port that to FreeBSD as well.
From the latest status report:
<quote>
Import of this work into the -current tree has started.
A publicly available patch against 4.7 will be released
once 4.7 ships. Integration of this work into the
-stable source tree is planned for 4.8.
</quote>
> I question whether you'd want any compiler at all on a firewall...
Depends. From a security point of view, I think it doesn't
matter (some people have a different opinion, so YMMV).
But it can save quite a lot of space, so it can be a good
idea if you're tight.
On my own embedded system (not a firewall, though) I have
removed the compiler toolchain, all static libraries, perl
and a few other things that weren't needed. All of that
for space reasons, because the machine boots from a 48 MB
compactflash card. I got the size of the system down to
32 MB, even though I installed quite a few "convenience"
tools (a non-standard editor, my favourite shell [zsh],
lsof, strace, cpdup and a bunch of other must-have tools,
as well as OSS which accounts for another 3 MB).
Here's a "du -k" of mine, for comparison:
http://www.secnetix.de/~olli/cantaro/du-k.txt
Regards
Oliver
--
Oliver Fromme, secnetix GmbH & Co KG, Oettingenstr. 2, 80538 München
Any opinions expressed in this message may be personal to the author
and may not necessarily reflect the opinions of secnetix in any way.
"All that we see or seem is just a dream within a dream" (E. A. Poe)
Michael Sierchio
> > since it's the source of the crypto libs, and hardware support
> > for the vpn card is available via Sam Leffler's OpenBSD /dev/crypto
>
> Work has been done to port that to FreeBSD as well.
>>From the latest status report:
Right, pretty much the same jumbo patch, except against 4.7...
> On my own embedded system (not a firewall, though) I have
> removed the compiler toolchain, all static libraries, perl
> and a few other things that weren't needed. All of that
> for space reasons, because the machine boots from a 48 MB
> compactflash card. I got the size of the system down to
> 32 MB, even though I installed quite a few "convenience"
> tools (a non-standard editor, my favourite shell [zsh],
> lsof, strace, cpdup and a bunch of other must-have tools,
> as well as OSS which accounts for another 3 MB).
Do you have a programmatic way of removing these? Again, I still
argue in favor of making everything a package for modularity's
sake, but I don't think I'm winning that battle ;-)
> Here's a "du -k" of mine, for comparison:
> http://www.secnetix.de/~olli/cantaro/du-k.txt
Hey, what's all that ".de" crap? (Versuch an einem Witz).
Dmitry Morozovsky
RC> > so if i want to build/install world
RC> > o for a rather small but not pico system, 32m ram and 512m hd
RC> > see <http://www.wildlab.com/>
RC> > o not have games, compiler, ... but need networking of course
RC> > o do the install onto an ibm microdrive on my laptop which i then
RC> > push into the tiny machine
RC> >
RC> > are there clues, howto, ... somewhere?
RC>
RC> I used the steps at http://neon1.net/misc/minibsd.html with great
RC> success to get 4.7-PRE into 14 megabytes onto a flash card for a
RC> firewall.
It would be very useful for such installations if we could wipe out IPv6
support from the binaries (small/embedded systems rarely need it), so defining
global make.conf knob such as NO_IPV6 seems appropriate to me.
Sincerely,
D.Marck [DM5020, DM268-RIPE, DM3-RIPN]
------------------------------------------------------------------------
*** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- ma...@rinet.ru ***
------------------------------------------------------------------------
Maarten de Vries
I could do with some hints regarding traffic shaping. My homenetwork is
hooked up to an assymetrical (1536/256) ADSL line, using a FreeBSD 4.6
system which provides the usual NAT/Gateway/Firewall services. I'm using
dummynet to control the amount of bandwidth used by certain hosts on the
network, which all works fine. However, I still suffer from latency when the
maximum up- and/or downstream of the line is being utilized. If I understand
it well, this happens because the buffer in the ADSL modem fills up
completely at those occasions. Is there anyway to prevent this from
happening?
Ta,
--
Maarten de Vries
http://unsavoury.net/
Christoph Moench-Tegeder
> I could do with some hints regarding traffic shaping. My homenetwork is
> hooked up to an assymetrical (1536/256) ADSL line, using a FreeBSD 4.6
> system which provides the usual NAT/Gateway/Firewall services. I'm using
> dummynet to control the amount of bandwidth used by certain hosts on the
> network, which all works fine. However, I still suffer from latency when the
> maximum up- and/or downstream of the line is being utilized. If I understand
> it well, this happens because the buffer in the ADSL modem fills up
> completely at those occasions. Is there anyway to prevent this from
> happening?
Limit the maximum usage of your line to about 90% to 95%. This prevents
usage of the queue in your modem. However, this will not work if
queueing on the remote side is the problem (bulk transfers like downloads
come to mind); you are out of luck if the queue on the remote side is too
long.
Regards,
cmt
--
Spare Space
Daniel O'Connor
> Limit the maximum usage of your line to about 90% to 95%. This prevents
> usage of the queue in your modem. However, this will not work if
> queueing on the remote side is the problem (bulk transfers like downloads
> come to mind); you are out of luck if the queue on the remote side is too
> long.
Actually, if you limit incoming TCP it will adapt to the correct speed.
I do this at home without hassle (except the latency in games goes up
from ~40 to ~100 but it is still acceptable)
--
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
"The nice thing about standards is that there
are so many of them to choose from."
-- Andrew Tanenbaum
GPG Fingerprint - 9A8C 569F 685A D928 5140 AE4B 319B 41F4 5D17 FDD5
Christoph Moench-Tegeder
> Actually, if you limit incoming TCP it will adapt to the correct speed.
> I do this at home without hassle (except the latency in games goes up
> from ~40 to ~100 but it is still acceptable)
How much do you have to limit TCP for the desired effect? I never
tried shaping on asymmetric lines, and the traffic ratio for a
single TCP bulk transfer (1500 (or little less in case of PPPoE,
PPTP, etc.) bytes incoming vs. 40 bytes outgoing) does not match
the up/down-ratio of his line (1:6) by any means.
Regards,
cmt
--
Spare Space
To Unsubscribe: send mail to majo...@FreeBSD.org
Matthew Dillon
server), try turning on the experimental bandwidth delay product
code (requires a recent -stable kernel).
sysctl -w net.inet.tcp.inflight_enable=1
sysctl -w net.inet.tcp.inflight_debug=0
This will prevent your local DSL modem's queues from building up
a large backlog of packets.
-Matt
:Hi all,
Matthew Dillon
is not a routing function.. i.e. it only effects tcp connections
originating on the box it is enabled on.
-Matt
Oliver Fromme
> Oliver Fromme wrote:
> > On my own embedded system (not a firewall, though) I have
> > removed the compiler toolchain, all static libraries, perl
> > and a few other things that weren't needed. All of that
> > for space reasons, because the machine boots from a 48 MB
> > compactflash card. I got the size of the system down to
> > 32 MB, even though I installed quite a few "convenience"
> > tools (a non-standard editor, my favourite shell [zsh],
> > lsof, strace, cpdup and a bunch of other must-have tools,
> > as well as OSS which accounts for another 3 MB).
>
> Do you have a programmatic way of removing these?
I'm afraid not, it was pretty much a one-time action.
But I made a pretty simple approach anyway by removing
everything that smelled like perl, compiler tool chain,
all static libs etc. I also removed some large static
binaries that I don't need, such as vinum, ipfstat and
dhclient, each of which are about half an Mbyte.
With a little more effort I guess the space requirement
could be redurced even further, but I had enough air to
breathe on my 48 Mbyte compactflash card.
Regards
Oliver
--
Oliver Fromme, secnetix GmbH & Co KG, Oettingenstr. 2, 80538 München
Any opinions expressed in this message may be personal to the author
and may not necessarily reflect the opinions of secnetix in any way.
"All that we see or seem is just a dream within a dream" (E. A. Poe)
To Unsubscribe: send mail to majo...@FreeBSD.org
parv
wrote Maarten de Vries thusly...
>
> I could do with some hints regarding traffic shaping. My
> homenetwork is
could you please not hijack a thread?
you included reference...
References: <200210050655....@lurza.secnetix.de>
...to "small install" thread when you started "Traffic shaping"
thread ... which has nothing to do w/ the original thread.
more than anything it screws up threading of messages. please be
careful of the headers.
- parv
--
Maarten de Vries
> For connections whos primary data path is outgoing (e.g. like a
> web server), try turning on the experimental bandwidth delay
> product code (requires a recent -stable kernel).
Hmm,
kern.osrevision: 199506
kern.version: FreeBSD 4.6-STABLE #0: Tue Aug 20 11:13:27 CEST 2002
Is not recent enough apparently; it doesn't recognize this option.
> Oh, I should also note that the bandwidth delay product stuff
> is not a routing function.. i.e. it only effects tcp connections
> originating on the box it is enabled on.
Not much use for my situation then, because I want to prevent the
workstations on my network from filling up the buffer.
Ta,
--
Maarten
Peter Jeremy
>## Daniel O'Connor (doco...@gsoft.com.au):
>
>> Actually, if you limit incoming TCP it will adapt to the correct speed.
>> I do this at home without hassle (except the latency in games goes up
>> from ~40 to ~100 but it is still acceptable)
>
>How much do you have to limit TCP for the desired effect? I never
>tried shaping on asymmetric lines, and the traffic ratio for a
>single TCP bulk transfer (1500 (or little less in case of PPPoE,
>PPTP, etc.) bytes incoming vs. 40 bytes outgoing) does not match
>the up/down-ratio of his line (1:6) by any means.
ipfw/dummynet pipes only handle a single flow direction: If you
have something like
ipfw NUMBER pipe 1 ip from any to any via ifX
then both incoming and outgoing traffic share the pipe and you are
limiting the combined uplink and downlink traffic - which probably
isn't what you want.
Instead, you need two pipes with uplink traffic in one and downlink
traffic in the other. Since the pipes are independent, you can set
the uplink and downlink limits to suit your ADSL link:
ipfw pipe 1 config bw UPLINK kbps
ipfw NUMBER pipe 1 ip from any to any out xmit ifX
ipfw pipe 2 config bw DOWNLINK kbps
ipfw NUMBER pipe 2 ip from any to any in recv ifX
Peter
Christoph Moench-Tegeder
> ipfw/dummynet pipes only handle a single flow direction: If you
> have something like
> ipfw NUMBER pipe 1 ip from any to any via ifX
> then both incoming and outgoing traffic share the pipe and you are
> limiting the combined uplink and downlink traffic - which probably
> isn't what you want.
Yes, I see.
My last experience with things like this suffered a little from a
slightly underfunctional implementation of bandwidth control (and
using dummynet/FreeBSD was not an option). I only had control
over the outgoing queue on the external interface, so I tried
slowing down slow start by limiting the acks from teh destination
to the source of the transfer based on calculations with packet
sizes and -rates (which seemed to be more than a little unreliable).
[Perhaps I could construct a scenario with some more interfaces,
where limiting the outgoing rates would be easier, but that would
be too far fetched for now].
So my problem in short: How much do I have to limit acks in the
direction with the lower bandwidth in order to control the
usage of the other direction? This is a little away from the
original thread, but I just would like to know (might come in
handy some time and perhaps I can "ptimize" my old "solution"
a little with other people's experience).
Regards,
cmt
--
Spare Space
To Unsubscribe: send mail to majo...@FreeBSD.org