Serge Caron wrote:
>
[ snip ]
> mds said:
> >By-the-by, this is considerably faster:
> >
> > sed -e "/^[./]*etc/d" ${pkg} > ${pkg}.light
>
> Linux people are usually more intelligent than I am. Your sed mask allows
> for stuff like ...etc and ../../../etc and all kinds of ganes that I prefer
> not to play :).
Nevertheless, since all backup operations are performed from root (/) --
a very sound *convention* and *standard*, yes? -- what is the actual
difference between our regex's, other than doing everything in one (1)
call to shell?
> Following your intervention, the original sed command now
> reads
> sed -e "/^etc[[:space:]]*$/d" -e "/^[/]etc[[:space:]]*$/d" \
> -e "/^[.][/]etc[[:space:]]*$/d" \
> -e "/^etc[/]/d" -e "/^[/]etc[/]/d" -e "/^[.][/]etc[/]/d" \
> ${pkg} > ${pkg}.light
If you must:
sed -e "/^etc[[:space:]]*$/d
/^[/]etc[[:space:]]*$/d
/^[.][/]etc[[:space:]]*$/d
/^etc[/]/d
/^[/]etc[/]/d
/^[.][/]etc[/]/d" ${pkg} > ${pkg}.light
Or:
sed -e "/^[.]\{0,1\}[/]\{0,1\}etc[[:space:]]*$/d
/^[.]\{0,1\}[/]\{0,1\}etc[/]/d" ${pkg} \
> ${pkg}.light
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 ;>
[ 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 . . .
[ 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.
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.
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!
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.
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.
For example, /var/log is the standard residence of logfiles. Looking
under that directory, I should never find executable files -- or, should
I?
For example, the root directory (/) should be residence to directories
*only* or, at least, *no* ordinary nor executable files -- or, should
it?
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 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!
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; 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.
> 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 . . .
What do you think?
--
Best Regards,
mds
mds resource
888.250.3987
Dare to fix things before they break . . .
Our capacity for understanding is inversely proportional to how much we
think we know. The more I know, the more I know I don't know . . .
_______________________________________________
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel
