Re: [Leaf-devel] Re: Standards and due process :-)
Hello Michael,
Glad to be of service!
I am confused ;
[1] Shouldn't your sed process:
sed -e /^etc/d -e /^[/]etc/d -e /^[.][/]etc/d \
${pkg} ${pkg}.light
actually be this?
sed -n /^[./]*etc/p ${pkg} ${pkg}.light
I am only concerned with deleting lines that start with etc..., /etc..., and
./etc... (Note that this will match a directory like /etcold but I don't
care). So the first attempt is to produce a new file list that does not have
any of those lines.
[2] How do you account for ${pkg}.exclude.list?
${pkg}.exclude.list is a proper substring of ${pkg}.list and therefore gets
included in the for loop.
[3] How do you account for CONF files that do not reside under /etc?
This particular code snippet treated /etc one way and /var a completely
different way. I could integrate both by producing a different exclusion
list for the default store. I'll think about it.
[4] Where do you get `cmp'?
cmp is a busybox applet. If don't have Andersen kit at hand, there is a
rather plump busybox on the discussion.img disk that I referred to earlier
this week. O'Reilly Linux in a nutshell has proper documentation for it.
Regards,
Serge Caron
___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Re: Standards and due process :-)
Serge Caron wrote:
Glad to be of service!
I am confused ;
[1] Shouldn't your sed process:
sed -e /^etc/d -e /^[/]etc/d -e /^[.][/]etc/d \
${pkg} ${pkg}.light
actually be this?
sed -n /^[./]*etc/p ${pkg} ${pkg}.light
I am only concerned with deleting lines that start with etc..., /etc..., and
./etc... (Note that this will match a directory like /etcold but I don't
care). So the first attempt is to produce a new file list that does not have
any of those lines.
This is where I get lost. When you said:
``When I want to backup, I simply remove the write protect tab on the
floppy. I can assure you that it takes a lot of config data to fill
1.6Mb of compressed space.''
I thought that you were backing up *only* config data. How does your
sed process facilitate this quoted intent of yours?
By-the-by, this is considerably faster:
sed -e /^[./]*etc/d ${pkg} ${pkg}.light
[2] How do you account for ${pkg}.exclude.list?
${pkg}.exclude.list is a proper substring of ${pkg}.list and therefore gets
included in the for loop.
Yes, I know; but, how does including excluded data facilitate your
needs?
[3] How do you account for CONF files that do not reside under /etc?
This particular code snippet treated /etc one way and /var a completely
different way. I could integrate both by producing a different exclusion
list for the default store. I'll think about it.
Yes, or similarly . . .
[4] Where do you get `cmp'?
cmp is a busybox applet. If don't have Andersen kit at hand, there is a
rather plump busybox on the discussion.img disk that I referred to earlier
this week. O'Reilly Linux in a nutshell has proper documentation for it.
I know that it is available; but, it is *not* included in DCD -- is it
included in Oxygen? I do not argue against its usage; rather, I am
often frustrated by lack of real awk, sed and sort -- not to mention cmp
and diff ;
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
Re: [Leaf-devel] SF changes TOS
Um...aprox SQRT(2)/2 No, no, I didn't mean rms mirrors :) Not RMS mirrors, just a shoot from the hip estimate of how much of our SF content is actually archived off-site. I figure it's some irrational number between 1/2 and 1, hence the above. :) 5) How long does it take to backup the whole schmegegy? A lot of setup time... Time I don't know about, but I do have a nifty 33/66 GB 8mm tape backup that's LVD and can store a large amount of content, safely, in boiling hot coffee. http://www.tapelibrary.eu.com/ecrix-04.htm drool The closest I come is a couple DLT drives, and I don't have space to be backing up my personal servers. Plus, I don't know if they've been through the coffee test, although I've never had problems with the tapes (unlike DAT, Exabyte, Qic, etc). Interested (in a dry backup) anyone? This would be a good thing IMHO. I'm going to try to put up a live mirror, but until I personally buy a DLT 4000 or 8000, or someone sees fit to give me a decent tape drive (xmas present hint! :-), I won't be doing a tape rotation (although I do have all online drives mirrored or raided). Once configured, the developer content will rsync quickly, the mySQL data isn't that large (apx 200K), so will go quickly, and I have no idea about either CVS backups or extracting the SF meta-data... I grabbed the leaf project directory last night...it's about 1.5 Gig. I have some of the SQL backups Mike runs, so I should be able to re-build the mySQL database and get our phpwebsite online. Anyone know offhand how to backup the CVS archive or the SF site content? Does SF still have a freely available version of their site software? I know in the old days of a year or two ago, you could grab the SF code and create your own SF site...anyone think this level of mirroring is necessary, or is the project directory, website, and CVS data enough? Anything else I'm missing? Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] SF Mirror
I have the first workings of a SF mirror online at: http://leaf.steinkuehler.net/ I still need to: - Experiment with database permissions to prevent site updates from the mirror (which will just get lost anyway...might as well have them error out immediately so folks don't expect their changes to stick) - Setup scripts to periodically grab updated content (both mySQL database info, and project files) - Look into mirroring our CVS content, downloads directory, and SF meta-data Mirroring the LEAF project directory, and getting the phpWebSite running were both pretty easy...anyone with a fairly modern linux install with apache, php, and mySQL should be able to run a mirror. Holler if anyone wants details... Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] SF Mirror
At 2002-02-14 10:28 -0600, Charles Steinkuehler wrote: I have the first workings of a SF mirror online at: http://leaf.steinkuehler.net/ Charles, EXCELLENT! I still need to: - Experiment with database permissions to prevent site updates from the mirror (which will just get lost anyway...might as well have them error out immediately so folks don't expect their changes to stick) Let me know how you do this, and I'll add the instructions to the mirror FAQ. - Setup scripts to periodically grab updated content (both mySQL database info, and project files) - Look into mirroring our CVS content, downloads directory, and SF meta-data The XML-Export is a problem. I have an open support request with SF to automate the process with curl/wget. https://sourceforge.net/tracker/?func=detailaid=508639group_id=1atid=21 Mirroring the LEAF project directory, and getting the phpWebSite running were both pretty easy...anyone with a fairly modern linux install with apache, php, and mySQL should be able to run a mirror. Holler if anyone wants details... Great news. Thanks for doing this Charles. :-) -- Mike Noyes [EMAIL PROTECTED] http://sourceforge.net/users/mhnoyes/ http://leaf.sourceforge.net/content.php?menu=1000page_id=4 ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Re: Standards and due process :-)
Hello again,
This is where I get lost. When you said:
``When I want to backup, I simply remove the write protect tab on the
floppy. I can assure you that it takes a lot of config data to fill
1.6Mb of compressed space.''
I thought that you were backing up *only* config data. How does your
sed process facilitate this quoted intent of yours?
Actually, the process is more like *I don't backup program binaries* :-).
Because of the subset of programs I work with, taking care of /etc and
/var - /var/log - /var/adm - /var/lib/lrpkg - /var/run - /var/lock -
/var/spool -/var/tmp } gives me what I want. YMMV :)
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 :). 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
This is part of a startup script that runs a few times a year. I am more
concerned with exactness than speed of execution. Your method is
_definitely_ faster but does not gives me exactly what I want.
[2] How do you account for ${pkg}.exclude.list?
${pkg}.exclude.list is a proper substring of ${pkg}.list and therefore
gets
included in the for loop.
Yes, I know; but, how does including excluded data facilitate your
needs?
Sorry for taking your question litterally :). I will presume that you
understand that the set of files destined for the default store is the set
of all files on the machine minus the set of all the files enumerated in
each of all other packages and minus the set of files excluded for the
default store.
Suppose the default store is named gizmo and some other package exclude
/etc/thisthat. The backup code in LRP, Dachstein, Oxygen, etc concatenate
all the file lists for all packages other than gizmo in a single exclusion
list. Therefore, if something is excluded from one package, it is also
excluded from all other packages.
When I want a snapshot of my machines, I want _everything_ in etc. Life is
like that :-)
[3] How do you account for CONF files that do not reside under /etc?
This particular code snippet treated /etc one way and /var a completely
different way. I could integrate both by producing a different exclusion
list for the default store. I'll think about it.
Yes, or similarly . . .
Like I said above, I do not handle /var the same way as I handle etc. The
programs I use store their data in /etc or /var or both. It can be extended
to anything else. Eventually, the need to run write-protected will change.
However, this solution works today.
[4] Where do you get `cmp'?
[snip]
I know that it is available; but, it is *not* included in DCD -- is it
included in Oxygen? I do not argue against its usage; rather, I am
often frustrated by lack of real awk, sed and sort -- not to mention cmp
and diff ;
Gee, I really had a push-button mind when I answered you. Michael, bear with
me for a few more seconds.
For one of his shows, Ed Sullivan had invited a lion tamer who usually put
his entire head in the lion's mouth at the end of his act. It was explained
to him, in writing, that the act took 10 minutes. By showtime, due to
overbooking and delays, Sullivan tells the lion tamer that once the curtain
rises, he has two minutes for his act. OK, says the lion tamer, but YOU
explain it to the lion. :-)
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.
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.
Regards,
Serge Caron
___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Re: Standards and due process :-)
Serge Caron wrote:
This is where I get lost. When you said:
``When I want to backup, I simply remove the write protect tab on the
floppy. I can assure you that it takes a lot of config data to fill
1.6Mb of compressed space.''
I thought that you were backing up *only* config data. How does your
sed process facilitate this quoted intent of yours?
Actually, the process is more like *I don't backup program binaries* :-).
Because of the subset of programs I work with, taking care of /etc and
/var - /var/log - /var/adm - /var/lib/lrpkg - /var/run - /var/lock -
/var/spool -/var/tmp } gives me what I want. YMMV :)
[ snip ]
Let me reduce my confusion to its firstmost problem: How does your sed
process facilitate ``*I don't backup program binaries*''?
AFAIK, ${pkg}.list files -- _minus_ ${pkg}.exclude.list files -- define
which files comprise the ${pkg} package -- correct?
Once you eliminate all files under etc, /etc and ./etc from ${pkg}.list
files, what you have left is ``a bunch of binaries'' -- am I wrong?
Wouldn't you reach this same end if all files under etc, /etc and ./etc
were only listed in ${pkg}.exclude.list files?
Until I fully understand this premise of yours, I do not know how to
proceed . . .
--
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
[Leaf-devel] Re: Standards and due process :-)
Message: 1 Date: Wed, 13 Feb 2002 13:54:34 -0800 From: Matt Schalit [EMAIL PROTECTED] Subject: Re: [Leaf-devel] Re: Standards and due process :-) To: [EMAIL PROTECTED] Hey Serge, Hello Matt, First, the important stuff: or any of us lacked passion. That's kind of insulting. And what Please accept a direct apology from me to you for no other reason than the fact that your feelings were hurt. It's plenty interesting to read your threads and see the breadth of your opinions. I've said before that it's always refreshing to Thank you. Please DO NOT PUT your flame thrower away! exactly happened three weeks ago? You showed up? And you tore the low level guts out of Dachstein and want to call that PacketFilter? And My posts are polite and as factually true as I can make them. PacketFilter is a 60kb file that cannot contain Dachstein. If you read the manual, Charles is directly credited for allowing this 60kb file to be distributed with his stuff. Further, as pointed out to David elsewhere, I do not intend to make a distribution just for the purpose of providing an environment in wich to run PacketFilter. This leaves you with very little material to support your opinion that I want to promote a dumb filtering device to the level of Dachstein. you don't like our file structure and our documentation? You think we make stupid decisions in our quaint little space and that comlicates your life? Indeed. As you acknowledged in the beginning of your message, you have collected things out of context. The onus is on you to support your comments. Regards Serge Caron --__--__-- Message: 9 Date: Wed, 13 Feb 2002 22:34:18 -0600 From: David Douthitt [EMAIL PROTECTED] Subject: Re: [Leaf-devel] Re: Standards and due process :-) To: LEAF Development [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] On 2/13/02 at 8:16 PM, Serge Caron [EMAIL PROTECTED] wrote: How's this different from Oxygen and Dachstein and how they read their configuration data from the floppy? I can create a package which contains nothing but configuration files, put it onto a floppy disk, and boot the Oxygen Bootable CDROM using that configuration The point is that this default store is loaded last, overwriting anything loaded from ANY package. It is not package specific and it is all inclusive (as far as /etc and /var go). And I DON'T have to rewrite all of the packages... Neither do I. As a matter of fact, I cannot rewrite stuff on CD when the package writer did not provide a partial backup list for Charles partial backup code. I also do not want to load binaries frow write-enabled media, as much as I can avoid it :-). Last, but not least, I will retain SOME system functionality when the default store goes belly up or missing. For booting purposes the use of root.lrp is dead; however, a script to convert root.lrp to a root.gz is practically a neccessity. The LRP patches can't be used on any kernel newer than 2.4.5 last I heard; so this kills the use of a *.tar.gz file for booting. Am I to understand that this will be a ONE-TIME script, run as part of an installation procedure, or is this a viable option that users sticking with 2.2 kernels will have in the long run? a real Repository would be with hyperlinks, descriptions, home pages, etc and requires a new package extension. I've not done as much as I ought, but it mainly uses a new file /var/lib/lrpkg/pkg.desc which contains all of the information Grrreat! Here is the dope for http://leaf.sourceforge.net/devel/scaron/nistnet.lrp The second one is nistnet 2.0.10, the National Institute of Standards and Technology network emulator and here's the dope from their homepage at http://www.antd.nist.gov/itg/nistnet/ The NIST Net network emulator is a general-purpose tool for emulating performance dynamics in IP networks. The tool is designed to allow controlled, reproducible experiments with network performance sensitive/adaptive applications and control protocols in a simple laboratory setting. By operating at the IP level, NIST Net can emulate the critical end-to-end performance characteristics imposed by various wide area network situations (e.g., congestion loss) or by various underlying subnetwork technologies (e.g., asymmetric bandwidth situations of xDSL and cable modems). Regards, Serge Caron ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] Re: SF changes TOS
Message: 2 From: guitarlynn [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: [Leaf-devel] SF changes TOS Date: Wed, 13 Feb 2002 15:48:07 -0600 Canadian would be great, but legally you can't contribute from the US to their projects as I understand it. As a Canadian citizen, I do not know what you are taking about. We have NO restrictions on cryptography and our copyright laws are pretty much in sync with the international community. ISPs all over the world are seeking the protection granted to carriers such as telcos rather than the burden of being the publisher. The former are immune from what you say on the line: they lease wires... The later are responsible for everything YOU do, unless they can prove that you deceived them. Easier said than done. Usually, people are looking for venture capital from ANY source :-) and I don't see why an open source project based in Canada would not be able to accept contributions from the US or anywhere else. Theo de Raadt has a lot of success with OpenBSD, distributed from Calgary, Canada. Here is some dope on the Canadian Export Control List (http://axion.physics.ubc.ca/ECL.html). However, if you have specifics, I will have a lawyer research this. Regards, Serge Caron ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Re: SF changes TOS
On Thursday 14 February 2002 15:45, Serge Caron wrote: As a Canadian citizen, I do not know what you are taking about. We have NO restrictions on cryptography and our copyright laws are pretty much in sync with the international community. snip Here is some dope on the Canadian Export Control List (http://axion.physics.ubc.ca/ECL.html). However, if you have specifics, I will have a lawyer research this. OK, thanks for that info. Around six months ago I was looking into helping a couple of Canadian-based projects and they implictely stated that due to the US laws on cryt., they appreciated the offer but wished to decline due to the possible conflict. Things may not be true for any other projects and they may have changed their minds, but since some of these laws have passed within the US I have to respect their concerns :) Thanks once again for enlightening my concern! -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Re: Standards and due process :-)
Hello Michael,
[ snip ]
Let me reduce my confusion to its firstmost problem: How does your sed
process facilitate ``*I don't backup program binaries*''?
AFAIK, ${pkg}.list files -- _minus_ ${pkg}.exclude.list files -- define
which files comprise the ${pkg} package -- correct?
Once you eliminate all files under etc, /etc and ./etc from ${pkg}.list
files, what you have left is ``a bunch of binaries'' -- am I wrong?
Wouldn't you reach this same end if all files under etc, /etc and ./etc
were only listed in ${pkg}.exclude.list files?
Until I fully understand this premise of yours, I do not know how to
proceed . . .
OK, so lets process this from the start. Here is the contents of
/var/lib/lrpkg/bindc.list, an old BIND 8.something package:
etc/init.d/bind
etc/named.conf
usr/sbin/named
usr/sbin/ndc
var/lib/lrpkg/bindc.*
var/named
Only concentrate on those two etc entries. The package author did not define
a .local file to backup just part of the package. The package is running off
CD and I can't rewrite it there :-). Finally, even if I could, I DO NOT WANT
to. I want to keep this package in whatever form it was delivered for the
entire duration of its useful life.
Once the package is LOADED, I delete the two etc lines from the list. This
means that any other package can now claim these two files. If these files
were enumerated in, say, /var/lib/lrpkg/bindc.exclude.list, they would be
excluded from every other package AND bindc.lrp. This is important, please
stop here if it is not clear.
Now, by removing these lines, I can either backup these files in the default
store (root.lrp if you are using Dachstein) or I could create a
configuration package. If I did this, I could be missing out on other stuff.
If I were to run on a hard disk, the persistent nature of the storage medium
hides the problem: eveything you left will be there when you power the
machine up again.
What I want is the entire contents of etc (and other stuff) as if I was
working with persistent storage without affecting each package.
Dachstein loads the default store BEFORE anything else and this is not
helping your understanding. If etc/named.conf is in both root.lrp and
bindc.lrp, the later MUST overwrite the former because the package loading
code is in root.lrp. By separating the default store from the boot loading
code, you can load the default store in the order YOU chose :-) Cool!
I suggest you try the discussion.img floppy which has a default store
separate from root. Perhaps by experimenting with this disk, it will become
clearer? If you get confused by the alternating kernels, I can package
something more obvious.
Regards,
Serge Caron
___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Re: Standards and due process :-)
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
Re: [Leaf-devel] Re: Standards and due process :-)
Voilà!
Serge Caron wrote:
Let me reduce my confusion to its firstmost problem: How does your sed
process facilitate ``*I don't backup program binaries*''?
AFAIK, ${pkg}.list files -- _minus_ ${pkg}.exclude.list files -- define
which files comprise the ${pkg} package -- correct?
Once you eliminate all files under etc, /etc and ./etc from ${pkg}.list
files, what you have left is ``a bunch of binaries'' -- am I wrong?
Wouldn't you reach this same end if all files under etc, /etc and ./etc
were only listed in ${pkg}.exclude.list files?
Until I fully understand this premise of yours, I do not know how to
proceed . . .
OK, so lets process this from the start. Here is the contents of
/var/lib/lrpkg/bindc.list, an old BIND 8.something package:
etc/init.d/bind
etc/named.conf
usr/sbin/named
usr/sbin/ndc
var/lib/lrpkg/bindc.*
var/named
Only concentrate on those two etc entries. The package author did not define
a .local file to backup just part of the package. The package is running off
CD and I can't rewrite it there :-). Finally, even if I could, I DO NOT WANT
to. I want to keep this package in whatever form it was delivered for the
entire duration of its useful life.
OK, now I see! Somehow, if you explicitly stated this before, I cannot
find it in your previous posts. Dear me, I am too literal, again ;
Actually, I faced this same dilemma many months ago; but, I conquered it
in quite a different manner -- I keep my own DCD development tree and
have finely tuned *ALL* LIST and LOCAL files to my particular needs. In
fact, now that I have successfully attained a leaf developer site, I
have been thinking about publishing what I believe to be the correct
LIST and LOCAL files for those packages included in DCD and those else
that I use. Is this a case for convention and standards, or is
willy-nilly construction of these files adequate to the task?
Your process has the added benefit of placing *ALL* LIST elements in one
(1) file -- something I have on my todo list; but, have not taken time
to achieve, especially in light of Charles' musings on redoing the
entire package thingy anyway. O, that is what we are discussing, huh?
Two (2) questions, at this point:
[1] The *only* way to make your ${pkg}.list modifications stick is to
perform a backup -- right? Since your example, bindc.lrp, includes *NO*
LIST file and you have no time to create one, then you need to backup
the *entire* package, just to enforce persistence of this modification
-- right? If so, what do you gain? Hopefully, it is not a large
package, nor that you have only that floppy on which to store it ;
Perhaps, this is a calling for creation of this file:
/var/lib/lrpkg/*.list
[2] Now, I must ask, again, how do you account for configuration files
that reside elsewhere, say /usr/share/snmp/snmpd.conf? It seems to me
that exceptions -- remember, the more the merrier! -- are quite costly
and speak loudly in support of those issues that I take with your
previous statement:
``there should not be a baseline specification''
Once the package is LOADED, I delete the two etc lines from the list. This
means that any other package can now claim these two files. If these files
were enumerated in, say, /var/lib/lrpkg/bindc.exclude.list, they would be
excluded from every other package AND bindc.lrp. This is important, please
stop here if it is not clear.
Yes, good point. Nevertheless, this is, perhaps, the most pernicious
flaw in the current system.
Did anybody say that the current system is perfect? Notwithstanding,
the convention-al, standard-ness to its essence? No, I am not flaming
the current system, nor any part thereof; rather, it is this learning
process that begs for elucidation, regardless whether or not you like
the terms 'convention' and 'standards'! If the current system changes
-- I guarantee that it will -- the convention is to publish those
changes to the user community, such that users of the system can use the
system in the proscribed manner.
Now, by removing these lines, I can either backup these files in the default
store (root.lrp if you are using Dachstein) or I could create a
configuration package. If I did this, I could be missing out on other stuff.
If I were to run on a hard disk, the persistent nature of the storage medium
hides the problem: eveything you left will be there when you power the
machine up again.
[1] If they reside in root.lrp -- *always* the FIRST package loaded! --
then, your laziness in not creating bindc.list bites you in the a**,
because bindc.lrp just over-wrote your precious configuration files!
[2] If you are going to ``create a configuration package'', then why
bother with this kludge at all? Why not build a better mousetrap and be
done with it?
What I want is the entire contents of etc (and other stuff) as if I was
working with persistent storage without affecting each package.
Yes, we all do -- at minimum cost.
Re: [Leaf-devel] Re: Booting Flash on PCMCIA follow-up
Johan Ugander wrote: I'm not using 2.4.x for other reasons. I'd really like to get this to work under 2.2... Matt, THANK YOU! This cleared up a lot. I feel reeeally close to a solution. So close, yet so far. Any ideas? /johan Well, apparently, he tried a few things that didn't work. I wonder if he read the following: http://pcmcia-cs.sourceforge.net/ftp/doc/PCMCIA-HOWTO-5.html It explains the low level driver details of how the CardBus bridge attempts to get a PCI interrupt. It'd be better to hash through those easy options like specifying irq's and port address or reserving irq's for ISA use in the BIOS rather than getting into edge triggered vs level triggered interrupts, and hacking at ide.c. It'd be nice if we could have seen the dmesg output from the system boot. Matt ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Re: Standards and due process :-)
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
Re: [Leaf-devel] Re: Standards and due process :-)
-Original Message-
From: Michael D. Schleif [EMAIL PROTECTED]
To: Serge Caron [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED] [EMAIL PROTECTED]
Date: February 14, 2002 6:20 PM
Subject: Re: [Leaf-devel] Re: Standards and due process :-)
Voilà!
[snip]
Only concentrate on those two etc entries. The package author did not
define
a .local file to backup just part of the package. The package is running
off
CD and I can't rewrite it there :-). Finally, even if I could, I DO NOT
WANT
to. I want to keep this package in whatever form it was delivered for the
entire duration of its useful life.
OK, now I see! Somehow, if you explicitly stated this before, I cannot
find it in your previous posts. Dear me, I am too literal, again ;
Actually, I faced this same dilemma many months ago; but, I conquered it
in quite a different manner -- I keep my own DCD development tree and
have finely tuned *ALL* LIST and LOCAL files to my particular needs. In
fact, now that I have successfully attained a leaf developer site, I
have been thinking about publishing what I believe to be the correct
LIST and LOCAL files for those packages included in DCD and those else
that I use. Is this a case for convention and standards, or is
willy-nilly construction of these files adequate to the task?
OK. You build /var/lib/lrpkg/xyz.local files with your choice of files that
have dynamic contents and should be included in a partial backup and your
choice of files that have static contents (tables, binaries, ...) and should
only be included in a full backup. Then you use lrcfg (or some other tool)
to specify for each package wheter you want a partial or a full backup.
Finally, you also specify, per package, the destination device.
So, if you run 10 packages on CD, you may end up with 7 partial packages on
floppy. This is Charles design and there is NOTHING wrong with it.
Your process has the added benefit of placing *ALL* LIST elements in one
(1) file -- something I have on my todo list; but, have not taken time
to achieve, especially in light of Charles' musings on redoing the
entire package thingy anyway. O, that is what we are discussing, huh?
My process, as you put it, is simply to dis-associate some files with the
original package they came from. One of the difficulty in LRP is that you
CANNOT have exact same file name in two different packages. Both packages
will load, the last one overwritting the first one. If you backup either
package, the file is dropped because the filelist of one package is the
exclusion list of the second one.
Breaking this association removes the difficulty entirely. I can then, if I
want to, backup to whole lot in package gizmo.lrp if that is what I fancy.
Two (2) questions, at this point:
[1] The *only* way to make your ${pkg}.list modifications stick is to
perform a backup -- right? Since your example, bindc.lrp, includes *NO*
LIST file and you have no time to create one, then you need to backup
Oops! Did I go wrong somewhere? Here is what I sent you: Here is the
contents of
/var/lib/lrpkg/bindc.list, an old BIND 8.something package:
etc/init.d/bind
etc/named.conf
usr/sbin/named
usr/sbin/ndc
var/lib/lrpkg/bindc.*
var/named
Since the contents of /var/lib/lrpkg/bindc.list is explicitly listed, there
is a LIST file.
the *entire* package, just to enforce persistence of this modification
-- right? If so, what do you gain? Hopefully, it is not a large
package, nor that you have only that floppy on which to store it ;
If I modify the contents of the list file and I were to do a backup, then I
would loose some contents of the original package. However, I am explicit in
giving the example that I run from a CD (I would prefer ROM :) and that,
regardless of the storage media, I do NOT want to modify the original
package. In other words, there are packages for which I will never backup.
Perhaps, this is a calling for creation of this file:
/var/lib/lrpkg/*.list
The file is already there, per above.
[2] Now, I must ask, again, how do you account for configuration files
that reside elsewhere, say ? It seems to me
that exceptions -- remember, the more the merrier! -- are quite costly
and speak loudly in support of those issues that I take with your
previous statement:
``there should not be a baseline specification''
I gave as an example a code snippet for /etc from a rather specific machine
down the hall for which we wanted write-protection at all times. Again, my
personnal experience with LEAF/LRP is that there will be new dynamic
contents every time you introduce a new package in a configuration. Your
package likes /usr/share/snmp/snmpd.conf and BIND likes /var/named. /etc is
easier to do than /usr.
To be specific, if a package maintains dynamic contents in /usr/sbin then I
HAVE to backup the original package (full or partial). However, I currently
do not run such packages and, I my experience, most package developers have
behaved. Do you have a different
[Leaf-devel] Re: SF changes TOS
Message: 5 From: guitarlynn [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: [Leaf-devel] Re: SF changes TOS Date: Thu, 14 Feb 2002 15:41:38 -0600 [snip] OK, thanks for that info. Around six months ago I was looking into helping a couple of Canadian-based projects and they implictely stated that due to the US laws on cryt., they appreciated the offer but wished to decline due to the possible conflict. Things may not be true for any other projects and they may have changed their minds, but since some of these laws have passed within the US I have to respect their concerns :) Ha! Now I understand. If, for example, you pickup an Intel PRO/100S nic with 168-bit encryption (Made in Malaysia if my memory serves me right) you should read on the label Unlawful to export outside US or Canada except under an approved US Dept of commerce export or applicable license exception. You will find the exact same warning on a Microsoft high encryption pack and on different encryption products. You, as a US citizen will break the law if you do export it to Europe, for example. I, as a Canadian citizen, am under license not to re-export this product. It cannot even go back to the US. (No refund policy :) Trust me, the terms of the license are basically a direct contract between me and the US government. As I stated before, we have no restrictions on cypher strengh, algorithms and the like. Since you, as a US citizen, implicitly have access to technology that cannot be exported, these people protected themselves. It used to be the same thing with France, up until 2 years ago I believe (Jacques could tell us). There, you could not even 40-bit encrypt a dial-in connection. Importing the stuff was a crime against the state and I dare not think what they did to suppliers. On older Microsoft development CDs, for example, you have French NT Server and then France NT Server. The former for Canada, Africa, etc. The later for France and its territories. So I guess some of these people mean business. Regards, Serge Caron ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Re: Standards and due process :-)
On 2/14/02 at 8:05 AM, Michael D. Schleif [EMAIL PROTECTED] wrote: I know that it is available; but, it is *not* included in DCD -- is it included in Oxygen? I do not argue against its usage; rather, I am often frustrated by lack of real awk, sed and sort -- not to mention cmp and diff ; As far as I know, both Oxygen and Dachstein use GNU sed; Oxygen just happens to use sed 3.0 and Dachstein something older I think. mawk.lrp is available, as is diff.lrp. I think busybox comes with sort - 0.60.2 anyway, in Oxygen... But cmp? Who needs that? -- David Douthitt UNIX Systems Administrator HP-UX, Unixware, Linux [EMAIL PROTECTED] ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Re: Standards and due process :-)
On 2/14/02 at 4:28 PM, Serge Caron [EMAIL PROTECTED] wrote: Date: Wed, 13 Feb 2002 22:34:18 -0600 From: David Douthitt [EMAIL PROTECTED] Subject: Re: [Leaf-devel] Re: Standards and due process :-) To: LEAF Development [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] On 2/13/02 at 8:16 PM, Serge Caron [EMAIL PROTECTED] wrote: How's this different from Oxygen and Dachstein and how they read their configuration data from the floppy? I can create a package which contains nothing but configuration files, put it onto a floppy disk, and boot the Oxygen Bootable CDROM using that configuration The point is that this default store is loaded last, overwriting anything loaded from ANY package. It is not package specific and it is all inclusive (as far as /etc and /var go). The Oxygen config.lrp is the same exact thing - except instead of pulling from /etc and /var, it pulls all configuration files. Just like yours, it is loaded LAST. That's what makes it a configuration file; it doesn't matter where in the boot process it is found; it is still loaded last (saved in /tmp and loaded from there...) For booting purposes the use of root.lrp is dead; however, a script to convert root.lrp to a root.gz is practically a neccessity. The LRP patches can't be used on any kernel newer than 2.4.5 last I heard; so this kills the use of a *.tar.gz file for booting. Am I to understand that this will be a ONE-TIME script, run as part of an installation procedure, or is this a viable option that users sticking with 2.2 kernels will have in the long run? Neither. This would be general purpose script to be used this way: # cd /tmp # apkg -c root # mkfs.image root | gzip -c - /mnt/floppy/root.gz ...or some variation. The script I'm refering to is here called mkfs.image. a real Repository would be with hyperlinks, descriptions, home pages, etc and requires a new package extension. I've not done as much as I ought, but it mainly uses a new file /var/lib/lrpkg/pkg.desc which contains all of the information Grrreat! Here is the dope for http://leaf.sourceforge.net/devel/scaron/nistnet.lrp The file I mentioned would be included in nistnet.lrp, and would be similar to: Name: nistnet Version: 2.0.10 URL: http://www.antd.nist.gov/itg/nistnet/nistnet-2.0.10.tar.gz Description: A Network Emulator from the US NIST Group: Network/Diagnostics ...and so forth. I'm going from memory; check http://leaf.sf.net/pub/oxygen/development/ for more information. As I said, it needs work. -- David Douthitt UNIX Systems Administrator HP-UX, Unixware, Linux [EMAIL PROTECTED] ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Re: Standards and due process :-)
On 2/14/02 at 3:34 PM, Serge Caron [EMAIL PROTECTED] wrote:
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 :). Following
your intervention, the original sed command now reads
...I just LOVE a good sed challenge :-)
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
First, with GNU sed:
sed -e '..' -e '..' -e '...'
can be written as:
sed '; .; .'
...also, it would appear that your matches are overlapping... why
not:
sed '/\.*\/*etc/{
/^etc[ ^I]*$/d
/^\.\/etc[ ^I]*$/d
/^\/etc[ ^I]*$/d
/^etc\//d
/^\.\/etc\//d
/^\/etc\//d
}' $pkg $pkg.light
The first line matches only those things that contain etc with any
number of periods and slashes (in that order) - which means you've
just ruled out a TON of things. Should be faster - only one match...
Using \. instead of [.] will save you one '.' - and it is probably
faster to use a single character instead of a set.
You don't need curly brackets ${} unless it is unclear where the name
starts and ends so ${pkg} is unnecessary, as is ${pkg}.light
(period stops the name) - but ${pkg}light and ${pkg}2 are necessary
if you want pkglight and pkg2 for names...
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.
netstat was also removed from Oxygen a while back; I think Linux in
general has made plain that netstat / route / ifconfig are to be
considered old and one is to use ip instead.
Oxygen dumped all three when space got tight; they are available as
packages.
--
David Douthitt
UNIX Systems Administrator
HP-UX, Unixware, Linux
[EMAIL PROTECTED]
___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] U.S. Export Laws and Crypto
On 2/14/02 at 3:41 PM, guitarlynn [EMAIL PROTECTED] wrote: On Thursday 14 February 2002 15:45, Serge Caron wrote: As a Canadian citizen, I do not know what you are taking about. We have NO restrictions on cryptography and our copyright laws are pretty much in sync with the international community. OK, thanks for that info. Around six months ago I was looking into helping a couple of Canadian-based projects and they implicitly stated that due to the US laws on crypto, they appreciated the offer but wished to decline due to the possible conflict. Things may have changed with the new laws... Under the old laws, U.S. citizens could not export strong crypto outside of the United States. The author of PGP got into a heaping big lot of trouble over this as his web site allowed non-US citizens to download his code. The author of a crypto algorithm book got into trouble when he put his code on disk - the disk could not be exported, but the book could (go figure) OpenBSD took its development to Canada just for this very reason - because U.S. export laws were so restrictive. Many U.S. based products (at one time) had a U.S. version and an Export version, again, for this very reason - and the Exportable version had lightweight crypto that could be exported, and the U.S. version had strong crypto. This got the software makers into heaps of public relations trouble as the international community wanted to be safe from weak crypto that could be broken (some quite easily in the end) and wanted STRONG crypto. Even the Linux kernel - all crypto code for the Linux kernel was hosted in Finland I think it was, again for this reason - but this has changed in recent years. -- David Douthitt UNIX Systems Administrator HP-UX, Unixware, Linux [EMAIL PROTECTED] ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] Re: Standards and due process :-)
On 2/14/02 at 4:36 PM, Michael D. Schleif [EMAIL PROTECTED] wrote: For example, /var/log is the standard residence of logfiles. Is it? Only in Linux apparently; my Unixware and HP-UX systems use /var/adm/syslog. For example, the root directory (/) should be residence to directories *only* or, at least, *no* ordinary nor executable files -- or, should it? Many UNIXes (most?) use / as root's home directory. 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? ...and what about /var/state and /var/spool/cache? Not only is standardization impossible, but the little variances are what makes a distribution individual and perhaps better than others. I could list variance after variance - both within Linux distributions and out: * ip vs. ifconfig/netstat/route * /etc/init.d ; /etc/rc.d/init.d ; /sbin/init.d ... * /var/log ; /var/adm/syslog * apkg v. lrpkg * /usr/local/bin ; /opt * / vs. /root (home dir) * BSD /etc/rc vs. SysV /etc/rc.d/S000script ... * Some system binaries were commonly put into /etc... * System administration tools: linuxconf, webadmin, sysadm, sadm, smit, sam * vi vs. anything else (emacs?) * Package management: pkgadd; swinstall; rpm; debpkg; etc.. * Compression: compress; gzip; bzip2; zip... I don't think we can force standardization - it's this sort of thing that makes the djbtools license so offensive... -- David Douthitt UNIX Systems Administrator HP-UX, Unixware, Linux [EMAIL PROTECTED] ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
