netfilter firewalling problems and solutions
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
> 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