netfilter firewalling problems and solutions

Robert Connolly cendres at videotron.ca
Thu Feb 19 20:51:40 PST 2004


I sent this 45 minutes ago without seeing it posted, maybe it was lost, maybe 
not. Sorry if this is a duplicate.

On February 19, 2004 07:32 pm, 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'm not recommending any specific
> package manager because anything that can turn a bunch of binaries into
> a single file that you can drop into other machines will do the trick
> for the purposes of rollbacks.  As to the other point you made...

I'm not saying this is where hlfs is going, its just what I think.

LFS wasn't designed to have its binaries copied to several machines. It shows 
how to install one machine. You have to keep in mind we don't use cflags; 
many packages auto detect your arch and optimize for it... so a standard 
build (without specific cflags) will not be stable on machines different then 
your host; i686 bins on a 486 wont be stable. You can follow the crosscompile 
hint with lfs, but thats not lfs anymore, thats distributed-lfs. I am 
interested in crosscompiling instructions in general though, to support x86 
to strongarm, etc, not for distributing but for cross building chap5 to setup 
the target for a native build in chap6.
As for package systems, I would like a human readable cataloge/database of the 
entire system for accounting reasons. This same database can be used by 
deinstall scripts. I have no faith that any package system or source package 
will have any reliable guildines to follow. For sanity there has to be 
assurance that packages are not writting on top of eachother, so I'm thinking 
something like, after a make install the filesystem is rescanned, new files 
are marked as part of that package, perhaps add some logic for new files in /
tmp and /var/log, and all the files are marked as read-only (no write) even 
by root, unless its manualy switched. I dont know what filesystem feature 
does this yet, chattr +i might be overkill. More logic for files in /etc too. 
When a package is reinstalled, it should be deinstalled first. With packages 
like libc the system should boot an initrd to upgrade, so the deinstall 
doesn't break running the system. A framework like this can still be used by 
rpm, apt-get, etc, or just simple tarballs and a few commands.

> "...don't think the book should default to removing the compiler..."
>
> 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.

I've also considered installing chap5 to /stage1, and chap6 tools to /tools. 
So the compilers can be unmounted, or network mounted. This could work well 
with crosscompiling too. And if non-root users build packages, it might help 
to let user lfs own /tools on the finished system, while root still owns the 
real system.

> 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 needs to be completely rewritten. There were complaints a while ago about 
having to follow several hints and a book and a wiki at the same time, so to 
help testers I modified the lfs book. Since 99% of it is original LFS I 
didn't change the acknowlegements, credits or copyright. I'm pretty sure I 
stayed within my rights in the lfs copyright.




More information about the hlfs-dev mailing list