Hello again,
-----Original Message-----
From: Michael D. Schleif <[EMAIL PROTECTED]>
To: Serge Caron <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: February 14, 2002 5:34 PM
Subject: Re: [Leaf-devel] Re: Standards and due process :-)
>Nevertheless, since all backup operations are performed from root (/) --
>a very sound *convention* and *standard*, yes? -- what is the actual
AFAIK, it is sound.
>Or:
>
> sed -e "/^[.]\{0,1\}[/]\{0,1\}etc[/[:space:]]*$/d" ${pkg} \
> > ${pkg}.light
>
>I really don't like to see repeated calls to same executable in
>production code -- just part of my process ;>
>
Your code is more than likely correct. However, the metacharacters { and }
are not used in sed according to O'Reilly's Linux in a nutshell (3rd
edition, chapter 9). I have seen different sed implementations in LRP and I
must say I am very conservetive :-). I do not understand your last comment
as sed is loaded only once either way. Perhaps you know something that I
don't.
>[ snip ]
>
>> When I want a snapshot of my machines, I want _everything_ in etc. Life
is
>> like that :-)
>
>Didn't you just *exclude* these same files in your sed process? How do
>you get everything that you just excluded _after_ explicitly excluding
>it?
>
>Clearly, I am missing something profound here . . .
>
I do not exclude these files from any package. I merely delete their
inclusion in specific packages. This is not the same.
>[ snip ]
>
>> Now, to answer your question: you are looking for a baseline
specification
>> :-). David Douthitt is *RIGHT* when he says that there should not be a
>> baseline specification, either explicitly specified for LEAF or
indirectly
>> specified by refering to a "distribution". We are dealing with
unspecidied
>> hardware constraint, some of which are not obvious as in the case of the
>> write-protect switch. As a case in point, Bering does not have netstat, a
>> fixture in this environment since the early LRP days. In the confined
space
>> of a floppy, Jacques Nilo decided something that made sense for his
project
>> and he can revisit his decision at any time. In the meanwhile, you have
>> Bering to play with.
>
>This is where I believe that we really part company. Since you insist
>on this choice of words, I have no choice, but to take you literally:
>
> ``there should not be a baseline specification''
>
>If this is the case and it is *explicitly* enforced, then it follows --
>absolutely -- that nobody can build any package for leaf/lrp and expect
>that it will perform according to any given specification! Period.
>
Thank you. Not only do we not part company, we agree that it is _absolutely_
required to enumerate the exact feature set of this and that "distribution".
However, the environment IS confined. So just saying "load busybox", for
example, is not sufficient. It is required to say, in <fill in your
distribution name> the binaries available are <fill in the list> and the
exact feature set is <one more enumeration>. So, if this distribution is
using the busybox sed instead of the full flavor Debian sed, YMMV. Is this
unreasonable to ask? And don't you want to know it before you assemble
everything in place?
>In fact, a system, such as leaf and lrp, is and always has been founded
>on a -- confusing -- myriad of tacit specifications. It is this implied
>set of conventions that I am addressing -- the fact that these
>specifications are largely unwritten and, therefore, understood by a
>very small minority. I maintain that, without any specification, there
>would be no lrp and no leaf and no List Service on which to debate these
>arcane issues.
>
You are correct again. For example, the fact that I decide to store files
elsewhere than in their original package is definitely going against the
grain. Step 1 in what you say is to identify that the usual practice or
implied convention or tacit specification is to store the file in its
original package. Step 2, is to face reality: you can't do that if you run
from a CD or ROM or write-protected media. Step 3, is to come up with a
reasonable alternative to the problem.
>It is another fact that I cannot, nor can anybody else, willy-nilly
>construct any haphazard package, load it into a running leaf/lrp
>environment and expect that that system will continue to run with its
>baseline integrity; much less, that my package will perform as I
>expect. We are dealing with systems predicated on baseline security and
>integrity -- are we not?
>
>Therefore, I insist that *NOW* is the time to publish an explicit set of
>baseline conventions and standards for leaf -- prior to landing squarely
>in the midst of 2.4.x land!
>
You have my support. However, it is one thing to say "thou shall have
busybox with these xyz applets" and to insist that a distribution has this
or that tool. For example, as Charles notes on his site, ip "sadly"' does
not have a command to place a card in promiscuous mode. The question is not
whether I use busybox ifconfig or the full flavor ifconfig just to place a
card in promiscuous mode. The question is why MUST I budget the space for
either utility in ALL installations. This is the consequence of a rigid
baseline. I think an interesting evolution is to provide a convention that
says here is my framework and here is how you extend it. You can bet that if
everybody complains that they have to recompile busybox just to add cmp, the
baseline will go up.
>Let us take what has been learned from years of LRP, take what has
>worked best, discard what has proven most costly -- however many or few
>those specifications might be -- and make a clean break with the past.
>Draw a line in the sand -- this side is the new land of LEAF and that
>other side is the past and LRP. Again, these clear demarcations --
>devised solely in the spirit of the lean and mean and embeddedness that
>we admire most in LEAF -- can only contribute to the greater good.
>
However, the reality will be mixed. In certain situations, I will want <fill
in your distribution> with wget because the physical security of the machine
is such that I can delete the utility before I enable an "external" link. I
have machines in vaults that are directly connected to a server with a cross
cable: by the time the bad guy gets into the vault, I have other problems.
In other situations, wget is unimportant. In the former situation, wget must
be separate from busybox. In the later, I can use the busybox applet, if I
want to.
If lean and mean is the only way to go, than the onus is always on the
appliance developper to make sure all the pieces he/she has selected will
fit together. These pieces include hardware, loaders, kernels, etc. Again,
by specifying how one can shrink or expand the baseline for a specific
problem at hand, I think we distribute more knowledge of LEAF as a solution
for these problems.
The funny thing here is that LRP/LEAF has all the tools to repackage itself
at any time. Any LRP/LEAF floppy can be extended/shrunk and the methodology
to do so is clearly established. Further, stricly from a scientific point of
view, anybody can say that the minimum amount of code that will successfully
load your packages in memory is what is "lean and mean".
The proposal that is before you does not "break" with the past. It merely
says, in the future the packaging of LEAF "components" is unambiguous.
Unambiguous sounds a lot like "clear demarcations" without saying this or
that belongs to so and so. What do you think?
>NO, I am not advocating any system of commandments and laws,
>transgression of which invokes the ire of the greater community; rather,
>I believe that it is important -- no, critical -- that I, as LEAF user
>and, especially, as LEAF developer -- know what I can expect from a
>small set of system constructs.
>
That is my purpose as well.
>For example, /var/log is the standard residence of logfiles. Looking
>under that directory, I should never find executable files -- or, should
>I?
>
What follows is an opinion. If I want to design an intrusion detection
system, I NEED to know of everything in that machine. If I have to second
guess every package developer out there, I will use some other product. I am
of the opinion that you are making a reasonable assumption for /var/log.
>For example, the root directory (/) should be residence to directories
>*only* or, at least, *no* ordinary nor executable files -- or, should
>it?
>
What follows is another opinion. Are you running from ROM? Is there some
requirement such as putting /linuxrc in root? Do you have a legal
requirement to provide a readme stating that trespassers will be prosecuted
to the full extent of the law? I understand your point. I am trying to apply
the principle that this type of decisions will rest with the OWNER of the
machine and that he will probably do things against my better judgment :-)
>For example, /etc should house, among else, configuration files,
>including a system of symbolic links facilitating system initialization,
>&c. -- but, then, what about /var or /usr/local or /opt?
>
>If I suspect that my leaf system is compromised, I ought to know -- not
>have to lookup on several dozen google searches, nor risk forgetting a
>critical check -- I ought to know how to review my system for
>conformance to a short list of conventions and standards.
>
>I use these examples, because I have many years experience automating
>things. In recent times, I have taken to automating computing processes
>and tasks, not the least of which are checking for free diskspace and
>managing dhcp client addresses inside dns. In order to wisely
>architect, design and implement such automation tools, a near exhaustive
>list of requirements is required. Little code is often necessary to
>achieve baseline functionality; but, much more code is required for
>error checking and to properly handle exceptions to the general rule --
>whatever that is ;>
>
I know where you are coming from. Right now, I am proposing that we supply
an exhaustive and unambiguous enumeration of what we place in the initial
RAM disk before we load the rest of the system. If you will be so kind as to
review the posts for the past three weeks, you will see that this otherwise
sane requirement has been interpreted in just about every way except yours.
Exhaustive and unambiguous does not imply baseline, lean or mean. It simply
says "You want awk for this bit bucket? OK, just put it in with this lot."
Then I can take an MD5 signature of this RAM disk, store it on a server
somewhere, and have the box report its signature every so often as part of
other stuff. Of course, if it no longer matches I have cause for PANIC :-).
>I dare say, if a human can do the task or a set of humans can follow a
>process from inception to conclusion, then I can automate that system.
>However, it is a common trait of humans that they will do these things
>routinely, intuitively and without conscious regard for steps and tasks
>that, together, comprise the entire process. In other words, in an
>environment that is under control, humans tend to perform whatever is
>necessary to achieve the desired result. They do not follow controlled
>if/then nor for/do constructs -- this has been the greatest challenge to
>the AI community!
>
You are threading a very fine line between design and tools. A saw and a
hammer are very different tools; both are effective weapons. I am not sure I
understand everything you are saying.
>Therefore, if we agree that all extraneous baggage ought to be stripped
>from the base system, including bootup and package initialization, as
>you appear to recommend and with which I agree;
Actually, as said before, the proposal if for an exhaustive and unambiguous
enumeration of the contents, not for any kind of explicit or implicit
restriction on this contents...
if we agree that we
>ought to be able to dip into that vast, forthcoming package repository
>and install whatever set of packages that suits our current needs and
>know that they will, at least, not stomp on each other; if we agree that
>we ought to do a better job of monitoring the monitor, realtime manage
>that system to which we entrust our critical networks; then it behooves
>us to better elucidate existing conventions and standards and we need to
>efficiently manage the evolution of LEAF into all of the manifestations
>that it endeavors to take on.
>
...hmmm, my personnal experience is either to build these machines for
extremely specialized configurations or as general purpose "appliances" such
as PacketFilter on which you beat until you understand a given situation. I
must say my personnal experience with most packages has been excellent (if
not outstanding). In rare occasions, such as dhcpcd, we had to go back and
repackage a newer version because of specific problems with suppliers.
Finally, I have to respect the software author: dnscache is a great tool
that I cannot use if I start adding and removing interfaces dynamically. It
must be restarted from scratch every time and this is a severe service
disruption for existing traffic on other interfaces. These conventions are
beyond my reach most of the times.
>> The difficulty here is formalizing your ability to repackage your
"baseline"
>> and go on with your life (or your LEAF :). I think we can overcome this
>> difficulty but I will wait for your comments on the process.
>
>If it is that simple, then I would not have bothered nor gone to these
>lengths to explain myself. Although, you were probably poking fun, I
>must caution against trivialization and over simplification. As you
>know, regardless anybody else's take on these things, process and
>system, including evolution of same, are my bread and butter . . .
>
Thank you. I highly value the effort you have made in stating your goals.
(And yes, I like a pun here and there: a waist is a terrible thing to mind
:-). This being said, I have proposed something that will help you achieve
these goals. Do you have a specific floppy or CD that I could repackage
along my proposal and on which you could beat until you can come up with
(hopefully better) alternatives? If so, just upload you image on your
account and let me know its name.
>What do you think?
>
Regards,
Serge Caron
_______________________________________________
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel
