netfilter firewalling problems and solutions

Archaic archaic at
Thu Feb 19 17:05:28 PST 2004

On Thu, Feb 19, 2004 at 06:32:21PM -0600, Dagmar d'Surreal wrote:
> I can tell you from personal experience once you get above five or six
> boxes, it becomes increasingly problematic to maintain them by building
> packages on the hosts themselves.

I don't disagree. I just see it as more gray than black and white. Some
people will want a compiler on their machine at all times. This book
shouldn't cater to just the guy admining dozens of boxes (of course it
shouldn't ignore that guy, either).

> Basically, I don't think it's entirely necessary to remove the compiler,
> but rather more efficient to never install one when building the
> filesystems for production machines.  Someone maintaining more than one
> LFS machine will likely find it not particularly difficult to build the
> initial development environment, and then use it to create the
> production filesystem to copy it to wherever.

Yeah, Robert was hoping for just such a thing as well so nothing (in the
initial building of the system) ever gets overwritten byu another
package and for zero fragmentation. It would obviously be a lot easier
if everything recognized DESTDIR...

> From what I saw this morning of the CVS, we're kind of treading on
> Gerard's toes a bit in the current format, and we'd probably be better
> off taking (in part) the approach that an HLFS filesystem is being
> deployed _from_ that to make a new system.

I didn't intend for a mirror image of the book, but it became rather
necessary the more Robert built the toolchain. We just have to go
through a "chap5" in order to produce the desired effect. Sure, it would
be nice to avoid that and just start with a chap6 with LFS assumed as
the host (original goal) but it didn't hold up in reality. So, no matter
what little fancy methods we throw in, we're still basically building
LFS with a bunch of patches and some modified commands. The real
difference isn't that, anyway, but rather the extensive education on
particular security-related topics. Nevertheless, I will talk to Gerard
and get his reaction to it. I never intended to (and still don't)
compete with LFS. It's merely an extension. We go beyond LFS, just like
BLFS, just with many of same packages. And this project is still run
under the permission and services of

> (You know, like pop another drive or more partitions in,
> put the hardened filesystem on those, and then start booting that or
> move it into a new chassis.)

I don't see that as necessary, nor would I consider it different if all
else was the same. If it is indeed treading on toes, this change would
only be a facade to the fact that it still was treading on those toes.

> So far LFS doesn't really address much of anything in the way of change
> management, which becomes important when you've got people who actually
> depend on your facilities to get their work done.  Maintenance windows
> and service levels tie into that so I'll also begin outlining those as
> well in the next several days.  (Not to put into the book, but so that
> the people reading and wanting to help will have an idea of what these
> entail... I'm very sure we've got a lot of nod-and-smile going on when
> people say things like RBAC and MAC.)

Might as well write it as if it was going in the book, because it may
very well. This won't be a small book if peoples' visions for it are
fulfilled. Basic admin practices are intended to be taught here. We're
trying to teach and give a well rounded (if somewhat simplistic)
education on which people can later extend with more specific reading.
I.E. we should look to be a good 'foundation' of starting knowledge that
people new to this venture can grasp enough to get basic ideas.

> On another front, I'm about two days away from being really sure of the
> netfilter stuff I've put together, BTW.  I came very close to creating a
> hooks script for dhclient to do some of the work until I went back and
> re-read the RFC on DHCP and spotted some reasons why I shouldn't.  I've
> mainly got disaster and minor break tests (netfilter suddenly missing,
> etc) to do to be sure I can recommend both sane and elegant solutions to
> tying things together.

Good stuff, Dag. All your work is greatly appreciated. I'm trying to put
together the xml pieces now, though there is some uncertainty about the
newxml (which is what I was trying to write). If things keep going this
quickly, I'll just dump the newxml stuff and port the lfsxml over to our


"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are, by
definition, not smart enough to debug it."

- Brian Kernighan

More information about the hlfs-dev mailing list