from:"Michael D. Schleif"


Mike Noyes wrote:
 
 On Sun, 2003-02-09 at 09:45, Mike Noyes wrote:
  Everyone,
  It has come to my attention that our leaf-user list volume is
  discouraging some/many users from using it. We have a variety of options
  to address this issue.
 
  a) Keep things as they are.
 
  b) NNTP support (news.gmane.org and/or nntp.sourceforge.net)
 
  c) Web support (SF forums for each LEAF release/branch) (note: we
 already use SF support trackers)
 
  d) New LEAF release/branch specific MLs.
  leaf-bering
  leaf-dachstein
  leaf-lince
  leaf-oxygen
  leaf-packetfilter
  leaf-wisp-dist

Add to d) leaf-general, or some such.  If this is divvied up to fine,
then how will the generalists lend support?

 e) Split leaf-user by adding
 leaf-user-new

-- 

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 . . .


---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com

___
leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-devel] ML volume


Mike Noyes wrote:
 
 On Sun, 2003-02-09 at 10:16, Lynn Avants wrote:
  On Sunday 09 February 2003 11:45 am, Mike Noyes wrote:
 
   b) NNTP support (news.gmane.org and/or nntp.sourceforge.net)
 
  I like NNTP, but it doesn't necessarily address the volume problem at all.
 
 Lynn,
 Correct. It just provides another way to look at the posts.
 
   d) New LEAF release/branch specific MLs.
   leaf-bering
   leaf-dachstein
   leaf-lince
   leaf-oxygen
   leaf-packetfilter
   leaf-wisp-dist
 
  This would address the issue for most of the discouraged users, but
  would be a real PITA for NNTP front-ends. Seperating the mailing-lists
  this way might be the better route and make life easier for subscribers
  of multiple lists IMHO.
 
 The question is how many people that provide support, like you, will
 join each list. A list that never receives replies to support requests
 isn't very useful.

This is part of my point.

And, previously:

 It has come to my attention that our leaf-user list volume is
 discouraging some/many users from using it. We have a variety of
 options to address this issue.

To be honest, I fail to see the magnitude of the problem.  If somebody
is going to install this stuff, then yank it because support involves a
high volume list service, do we really care much about such people?

How hard is it to subscribe to the list, ask questions, get the problem
resolved and un-subscribe?

Also, without a generic list, leaf-dachstein questions, for example,
will lose out on bering, et al. subscribers' opinions.

Frankly, I've saved all 24400+ posts from the last (3) years and do not
consider this volume to be without value . . .

-- 

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 . . .


---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com

___
leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: Light a candle, curse the glare (was: Re: [leaf-devel] ML volume)


Vladimir I. wrote:
 
 Mike Noyes wrote about Re: Light a candle, curse the glare (was: Re: [leaf-devel] 
ML volume):
 
  Ray,
  One of our project members sent me a message off-list expressing a
  concern over leaf-user list volume. I have no idea how many of our users
 
 No need to keep it secret - that developer was me. I receive
 about 50% of my support requests via e-mail. That's not much and
 the total traffic would be much lower than leaf-user's. However,
 I don't want to force those people to subscribe to the mailing
 list and at the same time I don't like to answer the same
 questions again.

snip /

In such a case, you could start your own list -- yahoo groups come to
mind -- and leaf-user requests can be deflected your way, similar to
rcf, c.

-- 

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 . . .


---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com

___
leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-devel] ML volume


Ray Olszewski wrote:
 
 At 11:03 AM 2/9/03 -0800, Mike Noyes wrote:
 On Sun, 2003-02-09 at 10:39, Ray Olszewski wrote:
   It would be easier to develop an (informed) opinion on this if we (or at
   least I) knew a bit more about what causes you to bring it up as a
  concern.
   There is a big difference between some users and many users, since
   some people will be dissatisfied with any approach.
 
 Ray,
 One of our project members sent me a message off-list expressing a
 concern over leaf-user list volume. I have no idea how many of our users
 are affected by the volume on leaf-user. Any enlightenment on this is
 appreciated.
 
 Glad I asked, since my initial reaction was based on an incorrect guess
 about the source of the concern.

Me, too . . .

 Asuming the individual involved is the lead person on a branch, I'd very
 much recommand providing *that* branch with a separate
 leaf-something_or_other list and modifying (a) the SR FAQ and (b) that
 branch's main page within LEAF to refer questions there. More generally,
 I'd make this decision on a branch-by-branch basis, being guided by the
 lead developer's preference.
 
 Really, it need not be all or nothing here; fairness does not enter into
 it.

snip /

I second this motion . . .

-- 

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 . . .


---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com

___
leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-devel] Template system [was Webconfiguration]

2003-02-01 Thread Michael D. Schleif


Lynn Avants wrote:
 

snip /

 I see either this concept can be embraced or ridiculed, but if you don't
 see it as necessary in the future you plainly haven't followed the desires
 on list for the last year or two. Packetfilter, apkg (Oxygen), LINCE,
 Mosquito, and individual systems are proof that it is time to move on.
 I'll write a new system myself if no else feels this way, it may never be
 complete or ideal, but I imagine that it will be integrated sometime in the
 future if not now. I don't want to try and save an old system for
 compatibility, Oxygen, Eiger, DachsteinCD, Bering, PacketFilter, WISP,
 LINCE, Coyote and many others weren't too concerned with compatibility.
 If this ends up as a new variant, so be it. it shouldn't be necessary;
 PacketFilter was proof of this if anyone spent the time to actually look into
 that 'package' as well. I see this as a extension of Serge's concept(s),
 which I don't feel were ever understood due to the way he presented them.

Please, allow me to offer a suggestion from a slightly different
perspective.

One of my biggest challenges in supporting nearly one dozen DachsteinCD
installations is the update process.

A year ago, Serge and I jousted a bit over means to coalesce basic LEAF
distributions and packages into standardized ``containers''.  I've not
had time to fully explore PacketFilter; but, it is coming time for me to
decide what is to wholesale replace each of our DCD installations.

Yes, Bering is probably mature enough for us to move in that direction. 
However, its current instantiation leaves me with same old problem: how
to upgrade packages across many different deployments?

I hacked my own system: zzz.lrp.  In that case, I have hand-tweaked each
and every *.bktype, *.conf, *.list,  *.local file in /var/lib/lrpkg/
such that /etc/init.d/zzz produces one (1) zzz.local file that lists
*ONLY* configuration files, files that will change from one system to
another, irrespective of package.  zzz.lrp files, then, on partial
backup become system-specific configuration file archives, and are the
_only_ LRP file required on writeable media!  We run many packages and
no zzz.lrp is larger than 100kB.

So, reason for my emergence from hibernation is this: Please, consider
making something similar standard in any new packaging system.

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 . . .


---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com

___
leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-devel] glibc packages fix vulnerabilities in resolver

2002-11-08 Thread Michael D. Schleif


Another reason to use djbdns . . .

Greg Morgan wrote:
 
 FYI,
 
 Greg Morgan
 
 Red Hat Network Alert wrote:
 
  Security Advisory - RHSA-2002:197-09
  --
  Summary:
  Updated glibc packages fix vulnerabilities in resolver
 
  Updated glibc packages are available to fix a buffer overflow in the
  resolver.
 
  Description:
  The GNU C library package, glibc, contains standard libraries used by
  multiple programs on the system.
 
  A read buffer overflow vulnerability exists in the glibc resolver code in
  versions of glibc up to and including 2.2.5.  The vulnerability is
  triggered by DNS packets larger than 1024 bytes and can cause applications
  to crash.
 
  All Red Hat Linux users are advised to upgrade to these errata packages
  which contain a patch to correct this vulnerability.
 
  This errata has been updated to work with programs querying DNS from
  extremely small stack sizes, such as MySQL.
 
  References:
  http://www.kb.cert.org/vuls/id/738331

-- 

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 . . .


---
This sf.net email is sponsored by: See the NEW Palm 
Tungsten T handheld. Power  Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en

___
leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-devel] RE: Bering - included libraries

2002-09-21 Thread Michael D. Schleif



Eric B Kiser wrote:
 
 You must mean inside that really obvious directory named /lib. Urgh, it is
 now probably a moot point to mention that I am a newbie. Your patience is
 appreciated.
 
 Here is where I am now. I execute the command #zebra -d to start the zebra
 process running as a daemon and I get the following message back.
 
 zebra: error in loading shared libraries
 libcrypto.so.2: cannot open shared object file: No such file or directory

snip /

There is a very real difference between these two (2) libraries:

libcrypt
libcrypto

The latter is part and parcel of openssl; perhaps, also some other
libraries.

How are you compiling zebra?  On what describe system?  With what
libraries?

You probably need to do what we have done for openssh, which is to
statically link libcrypto during openssh compile . . .

-- 

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 . . .


---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

___
leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [leaf-devel] RE: Bering - included libraries

2002-09-21 Thread Michael D. Schleif



Eric B Kiser wrote:
 
 I am using David's zebra.lrp package and trying to get it to run on
 Bering_1.0-rc3. I wanted to check out what he did before I got started on
 mine. I will, however, be using UML_slink to do my compiling.
 
 You bring up an interesting question regarding ssh having the libraries
 statically linked. I expect to have both ssh and zebra running on the same
 system. Would it be better to use the libssl as suggested by H. D. Lee. That
 is, assuming that there is an ssh.lrp without libcrypto statically linked.
 Strictly for the purpose of conserving space.

I do not know which version is David's libssl.lrp -- it is big.  I am
sure that it is several versions behind the most current openssl-0.9.6g,
which I use in my openssh packages.

As you know, the recent linux worm hoopla is aided and abetted by older
versions of openssl.  How much of this affects zebra, I do not know.

Due to the enormous size of openssl, and also to the limited need for it
across a wide gamut of leaf packages, static linking openssl libraries
into other packages appears to be the norm.

Everytime that I have poo-poo'd size constraints -- I use dcd -- I am
reminded that a large portion of our audience is constrained by floppy
sizes.

Everything developed for this project is based on well thought out trade
offs.  Zebra will be no different.

 Along this same line of thought, does anyone know whether it would cause
 problems to use ssh.lrp with the statically linked libcrypto on the same
 system as using libssl.lrp. I am in unfamiliar terrain here so any help is
 appreciated.

No problem.

I have been meaning to do the zebra thingy for over a year.  Obviously,
the need has not been great enough to coax me into it.

I wish you good fortune in this endeavor and am anxious to play with the
results.  If I can help, please, let me know . . .

snip /

-- 

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 . . .


---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

___
leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [Leaf-devel] Redundancy in /var/log files

2002-08-02 Thread Michael D. Schleif



Jacques Nilo wrote:
 
 Hi Everyone
 I have been  asking myself for quite some time why there was so much
 redundancy in the content of  /var/log files in a LEAF distro.
 A typical example is when your ports are being scanned, that is when your
 iptables messages starts increasing. You will find them in :
 1/ kernel.log
 2/ syslog
 3/ messages
 and your /var/log will get big, big,...
 
 Which all boils down to the structure of /etc/syslog.conf which is attached
 at the end of this message (this is the one used in Bering but leasily copied
 from the one in Dachstein).
 
 Has any one some ideas about the optimal way to setup this? I'll welcome
 any feedback on this issue.

snip /

Not yet perfect, but better -- this is mine:

# cat ./etc/etc/syslog.conf
#  /etc/syslog.conf Configuration file for syslogd.
#   For more information see syslog.conf(5) manpage.

# Facility is one of the follOwing keywords:
#   auth
#   authpriv
#   cron
#   daemon
#   kern
#   local0 -- local7
#   lpr
#   mail
#   mark (internal use *only*)
#   news
#   security (deprecated; same as auth)
#   syslog
#   user
#   uucp

# Priority is one of the following keywords, in ascending order:
#   debug
#   info
#   notice
#   warning
#   warn (deprecated; same as warning)
#   err
#   error (deprecated; same as err)
#   crit
#   alert
#   emerg
#   panic (deprecated; same as emerg)

#
# Log everything remotely. The other machine must run syslog with '-r'.
# WARNING: Doing this is unsecure and can open you up to a DoS attack.
#
*.crit  @loki
kern.*  @loki

#
# First some standard logfiles.  Log by facility.
#
*.warning;auth,authpriv.none/var/log/syslog
auth,authpriv.* /var/log/auth.log
cron.*  -/var/log/cron.log
daemon.*-/var/log/daemon.log
kern.*  /var/log/kern.log
local1.*-/var/log/local1.log
local2.*-/var/log/local2.log
local3.*-/var/log/local3.log
local4.*-/var/log/local4.log
local5.*-/var/log/local5.log
local6.*-/var/log/local6.log
local7.*-/var/log/local7.log
lpr.*   -/var/log/lpr.log
mail.*  -/var/log/mail.log
news.*  -/var/log/news.log
syslog.*-/var/log/syslog
user.*  -/var/log/user.log
uucp.*  -/var/log/uucp.log

#
# Some `catch-all' logfiles.
#
*.=debug;\
auth,authpriv,\
news,mail.none  -/var/log/debug

*.=info;*.=notice;\
auth,authpriv,cron,\
daemon,mail,news.none   -/var/log/messages

# ppp
local2.*-/var/log/ppp.log

# portslave
local6.*-/var/log/pslave.log

#
# Emergencies are sent to everybody logged in.
#
*.emerg *

-- 

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 . . .


---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [Leaf-devel] Compiling ssh secutity issue

2002-08-01 Thread Michael D. Schleif



Manfred Schuler wrote:
 
 this is another topic.
 
 Your link reports vulnerabilities in openssl.
 
 This information is about a trojan in the openssh source tarball.
 The trojan opens a backdoor when compiling ssh.
 
 It is no security issue for leaf, only a hint for those people compiling ssh.
 
 Mike Noyes schrieb:
 
  Manfred,
  Michael addressed this issue is already.
 
  Re: [leaf-user] FORW: CERT Advisory CA-2002-23 Multiple Vulnerabilities
  In OpenSSL
  http://www.mail-archive.com/leaf-user%40lists.sourceforge.net/msg08584.html

Please, re-read the last three (3) lines posted therein:

 I want to ask, if we can shure the version in your leaf-cvs isn't affected?

 # md5sum ./openssh-3.4p1.tar.gz
 459c1d0262e939d6432f193c7a4ba8a8  ./openssh-3.4p1.tar.gz

Obviously, the homework is left to the aspiring user to verify that that
md5sum indicates that the source from which my packages are compiled is
*NOT* affected by the trojan ;

hth

-- 

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 . . .


---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [Leaf-devel] Perl help



Mike Noyes wrote:
 
 Anyone,
 Will removing the following lines from enforce_naming leave the perl
 script functional?

Yes, absolutely yes; provided that either all of the lines are
completely _removed_ or completely commented out.

  # Verify that all files are lowercase, except Makefiles
 if ((substr($_, 0, 8) ne Makefile) and (lc($_) ne $_)) {
 print All filenames must be completely lowercase except ;
 print Makefiles. ($directory/$_)\n;
 $exit_val = 1;
 }
 
 leaf/CVSROOT/enforce_naming rev 1.3
 http://cvs.leaf-project.org/cgi-bin/viewcvs.cgi/leaf/CVSROOT/

Also, remove the lone `next;' at end of for loop, since the for loop
does that automatically, by design ;

-- 

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 . . .


---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [Leaf-devel] Perl help



Mike Noyes wrote:
 
 On Wed, 2002-07-17 at 08:58, Michael D. Schleif wrote:
  Mike Noyes wrote:
  
   Anyone,
   Will removing the following lines from enforce_naming leave the perl
   script functional?
 
  Yes, absolutely yes; provided that either all of the lines are
  completely _removed_ or completely commented out.
 
 Hmm, then what did I do wrong in rev 1.2? I used vi to dd out the lines
 below, and you ended up with a broken pipe from the server last night.
 
 Any enlightenment is appreciated.

Previously, you said that _cvs import_ somehow bypasses case checking,
or this script.  Since all I did last night was _cvs import_, and
because there is nothing in enforce_naming (no version in cvs) that
would result in broken pipe errors, I believe the culprit is
elsewhere.

# Verify that all files are lowercase, except Makefiles
   if ((substr($_, 0, 8) ne Makefile) and (lc($_) ne $_)) {
   print All filenames must be completely lowercase except ;
   print Makefiles. ($directory/$_)\n;
   $exit_val = 1;
   }
  
   leaf/CVSROOT/enforce_naming rev 1.3
   http://cvs.leaf-project.org/cgi-bin/viewcvs.cgi/leaf/CVSROOT/
 
  Also, remove the lone `next;' at end of for loop, since the for loop
  does that automatically, by design ;
 
 Is this true for older versions of perl too? The SF cvs server may not
 have the newest perl release on it.

I've been Perl'ing since v4.0x days.  That is the design of a for loop. 
That `next;' does not do anything bad except waste a couple cpu cycles .
. .

-- 

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 . . .


---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [Leaf-devel] Current CVS Oxygen Tree



Mike Noyes wrote:
 
 On Wed, 2002-07-17 at 12:23, David Douthitt wrote:
  I've been looking at some things, and updated
  syslinux and e3 (in the CVS tree) to their apparent
  current versions.
 
  I've noticed that CVS can be a major pain, especially with
  renaming files, or deleting or moving directories.
 
 David,
 Agreed. CVS has no commands for moving files or directories. It also has
 no command for removing directories from a repository.

Look here http://www.cvshome.org/docs/manual/cvs_7.html#SEC69

[ snip ]

-- 

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 . . .


---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [Leaf-devel] CVS structure ???



Jeff Newmiller wrote:
 
 On Wed, 10 Jul 2002, Michael D. Schleif wrote:

[ snip ]

  I am starting to realize that, perhaps, I should take a directory based
  approach to helices' cvs tree.
 
  I have not settled on any particular structure.  However, I am wondering
  about several things:

[ snip ]

 CVS is designed to handle directories full of information... so a
 directory tree of html documents is a natural thing to enter.
 
 An idea...
 
   net-snmp/
 README.txt
 package/
   net-snmp.lrp
 target/
   etc/
 blahblah
   usr/
 bin/
   snmpbinary
   ...
 doc/
   index.html
   images/
 image1.jpg
   ...
 src/
   sourcefiles...

[ snip ]

I took a liking to this structure, which you can see here:

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/leaf/devel/helices/

I appreciate *ALL* feedback on this infrastructure, before I get carried
away with further additions to cvs.

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 . . .


---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [Leaf-devel] CVS structure ???



David Douthitt wrote:

[ snip ]

 My model has been the following:
 
 archives/
   somearchive.tar.gz
   otherarchive.bz2
   ...
 
 iproute2/
   distinfo
   Makefile
   patches/
 somepatchname.diff
 somepatchname2.diff
 ...
   work/ {temporary dir; created and used to compile within}
   binaries/ {temporary dir; created and stores binaries ONLY (no path)}
   world/{temporary dir; created and used to store full paths
  and all files needed within the structure}
 
 otherpkg/
 ...
 
 My current lrp package setup was to have the following:
 
 iproute2-sourcedir/
   lrp/ {created}
 ...
 
 Under lrp/ there is a Makefile which contains all of the targets to make packages, 
etc.
 There is also a directory like world/ above which contains all paths and a Makefile
 in each directory that needs to have a binary in it.
 
 After this lrp/ directory is correctly configured, then the entire directory is
 wrapped up into a *.diff file and saved with the unmodified source archive.  
Examples
 of this can be found in the Oxygen/LEAF Resource CDROM.
 
 Perhaps what I will do is to use this patch as a regular patch in the CVS ports tree
 and add the patch to the source code, then use it to create packages at will.

I've been considering using whatever structure I settle on as my
development environment.  I have cvs setup on my own network and hope to
integrate leaf development into my other development projects.  However,
cvs doesn't lend itself to this end for several reasons:

[1] Each sandbox includes cvs directories under each directory in the
project.  So, rolling up the hierarchy directly into an LRP is
cumbersome.  cvs export only adds to the kludge.

[2] Since cvs does not retain group, mode nor ownership attributes, [1]
is further complicated and requires another kludge to correct directory
and files attributes.

[3] I still have not figured out how to force synchronization between
cvs revision numbers and project source revision numbers.

[4] All of this makes inclusion of package/package/package.lrp an
absolute must!

If anybody has overcome any of these obstacles, I'd appreciate
enlightenment . . .

-- 

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 . . .


---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [Leaf-devel] cvs commit directory structure ???

2002-07-16 Thread Michael D. Schleif



I now believe that all of my cvs study led me to conclude that I was
creating and modifying ``modules''; but, modules can only exist at the
top level under CVSROOT.  Therefore, you are probably correct that cvs
import is the solution here.

In an effort to correct my miscreant behaviour, I tried using cvs
remove.  Under some conditions, cvs remove works as expected.  However,
see failed transaction, at end, to see problems with inability to
generate locked files.

Are there limitations to cvs remove?  What is the cause of the lock
problem?

Mike Noyes wrote:
 
 On Mon, 2002-07-15 at 22:39, Michael D. Schleif wrote:
 
  No matter how hard I try, I cannot commit a directory structure to cvs.
 
  I get lock failures, even when I try to commit them one directory at a
  time.
 
  Clearly, there is some approved process for doing this and I do not know
  what that is.
 
 Michael,
 I looked at your commit messages, and I think I understand what you were
 trying to accomplish. Here is a sequence that I believe would have
 worked.
 
 From a directory out side of your checked out cvs tree (devel/helices).
 Create the directory hierarchy that you wish to add to our repository.
 Then from inside the root of this new hierarchy execute:
 
 $ cvs -d:ext:[EMAIL PROTECTED]:/cvsroot/leaf import \
 -I ! devel/helices/ntpclnt vendor start
 
 Note: naming conventions aren't enforced on imports.
 
 Note: this command will not work now, as there is already a
 directory with that name in our repository.
 
 Would you like me to open a SF support request, and have them clean your
 devel/helices tree out? You can start fresh that way.

Yes, have somebody purge/delete/remove devel/helices/ntpclnt and
everything below that.

[ snip ]

# ls devel/helices/
CVS  netsnmp.lrp  netsnmpd.lrp  nettrapd.lrp  ntpclnt

# cvs -d:ext:[EMAIL PROTECTED]:/cvsroot/leaf remove
devel/helices/ntpclnt
[EMAIL PROTECTED]'s password:
cvs remove: warning: directory CVS specified in argument
cvs remove: but CVS uses CVS for its own purposes; skipping CVS
directory
? devel/helices/ntpclnt/package/ntpclnt.lrp
? devel/helices/ntpclnt/target/etc/ntpclient.conf
? devel/helices/ntpclnt/target/etc/init.d/ntpclient
? devel/helices/ntpclnt/target/var/lib/lrpkg/ntpclnt.bktype
? devel/helices/ntpclnt/target/var/lib/lrpkg/ntpclnt.conf
? devel/helices/ntpclnt/target/var/lib/lrpkg/ntpclnt.help
? devel/helices/ntpclnt/target/var/lib/lrpkg/ntpclnt.list
? devel/helices/ntpclnt/target/var/lib/lrpkg/ntpclnt.local
? devel/helices/ntpclnt/target/var/lib/lrpkg/ntpclnt.version
cvs server: Removing devel/helices/ntpclnt
cvs server: file `devel/helices/ntpclnt/readme.txt' still in working
directory
cvs server: Removing devel/helices/ntpclnt/package
cvs server: Removing devel/helices/ntpclnt/target
cvs server: Removing devel/helices/ntpclnt/target/etc
cvs server: failed to create lock directory for
`/cvsroot/leaf/devel/helices/ntpclnt/target/etc'
(/cvsroot/leaf/devel/helices/ntpclnt/target/etc/#cvs.lock): No such file
or directory
cvs server: failed to obtain dir lock in repository
`/cvsroot/leaf/devel/helices/ntpclnt/target/etc'
cvs [server aborted]: read lock failed - giving up

-- 

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 . . .


---
This sf.net email is sponsored by: Jabber - The world's fastest growing 
real-time communications platform! Don't just IM. Build it in! 
http://www.jabber.com/osdn/xim

___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [Leaf-devel] cvs commit directory structure ???

2002-07-16 Thread Michael D. Schleif



Mike Noyes wrote:
 
 On Mon, 2002-07-15 at 22:39, Michael D. Schleif wrote:
 
  No matter how hard I try, I cannot commit a directory structure to cvs.

[ snip ]

 I looked at your commit messages, and I think I understand what you were
 trying to accomplish. Here is a sequence that I believe would have
 worked.

[ snip ]

Is there some way to *transfer* a cvs module from my own cvs to
sourceforge/leaf cvs?

I have created a cvs environment for my own development.  Since I
already have [many of] my packages situated as local cvs modules, it
would be most convenient if there is some way to move modules from cvs_A
to cvs_B.

Or, need I *export* a module from my own cvs prior to importing it into
sourceforge/leaf cvs?

-- 

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 . . .


---
This sf.net email is sponsored by: Jabber - The world's fastest growing 
real-time communications platform! Don't just IM. Build it in! 
http://www.jabber.com/osdn/xim

___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel

[Leaf-devel] cvs commit directory structure ???

2002-07-15 Thread Michael D. Schleif



No matter how hard I try, I cannot commit a directory structure to cvs.

I get lock failures, even when I try to commit them one directory at a
time.

Clearly, there is some approved process for doing this and I do not know
what that is.

Also, what is this limitation that all files must use *ONLY* lowercase
letters???

Please, enlighten me . . .

-- 

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 . . .


---
This sf.net email is sponsored by: Jabber - The world's fastest growing 
real-time communications platform! Don't just IM. Build it in! 
http://www.jabber.com/osdn/xim

___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel

[Leaf-devel] CVS structure ???



Mike and I were discussing cvs off-list.  Since much of this is
un-structured now, perhaps, we can impose some user-friendly and
consistent form on our cvs tree.

I am starting to realize that, perhaps, I should take a directory based
approach to helices' cvs tree.

I have not settled on any particular structure.  However, I am wondering
about several things:

[1] Should I have separate trees for different underlying versions of
net-snmp?  For example, I committed net-snmp v4.2.4.  I am contemplating
building and committing both v4.2.5 and the totally different
distribution v5.x.  So, one line of thinking is like this:

devel/helices/net-snmp/v4.2.4/netsnmp.lrp
devel/helices/net-snmp/v4.2.4/netsnmpd.lrp
devel/helices/net-snmp/v4.2.4/nettrapd.lrp
devel/helices/net-snmp/v4.2.5/netsnmp.lrp
devel/helices/net-snmp/v4.2.5/netsnmpd.lrp
devel/helices/net-snmp/v4.2.5/nettrapd.lrp
devel/helices/net-snmp/v5.0.2/netsnmp.lrp
devel/helices/net-snmp/v5.0.2/netsnmpd.lrp
devel/helices/net-snmp/v5.0.2/nettrapd.lrp
. . .

[2] Perhaps, my net-snmp package, for instance, should be in cvs in
expanded form, so that when only one (1) or a few file contents change,
that will be directly reflected in cvs?  Under this scenario, when only
a single file -- perhaps, the primary binary? -- is changed, users can
checkout only that file.

[3] Item [2] presents a difficulty when a user wants the whole LRP
package as one (1) LRP file.  Is there some way to properly archive and
compress a cvs directory tree and check that out?

[4] I am still confused on how best to handle package descriptions. 
http://leaf.sourceforge.net/devel/helices/net-snmp/ presents several
TXT files that, once clicked on, present descriptive text regarding the
LRP's that reside in versioned directories below this one.  Another
example is Jacques Nilo's http://leaf.sourceforge.net/devel/jnilo/
wonderful page that links to installation and troubleshooting
information.  How are we to do this under cvs?

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 . . .


---
This sf.net email is sponsored by:ThinkGeek
Two, two, TWO treats in one.
http://thinkgeek.com/sf

___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [Leaf-devel] CVS structure ??? [LONG]



Jeff Newmiller wrote:
 
 On Wed, 10 Jul 2002, Michael D. Schleif wrote:

[ snip ]

  [1] Should I have separate trees for different underlying versions of
  net-snmp?  For example, I committed net-snmp v4.2.4.  I am contemplating
  building and committing both v4.2.5 and the totally different
  distribution v5.x.  So, one line of thinking is like this:
 
  devel/helices/net-snmp/v4.2.4/netsnmp.lrp ...
  devel/helices/net-snmp/v4.2.5/netsnmp.lrp ...
  devel/helices/net-snmp/v5.0.2/netsnmp.lrp ...
 
 This seems quite the wrong direction.  CVS is supposed to manage
 versioning completely independently of the directory structure.

Yes, I agree.  However, I am dealing with somebody else's software and
making it suitable for leaf.  Obviously, I can have several iterations
of net-snmp v4.2.4 that address various leaf concerns.

Also, I must be prepared for somebody else's version upgrades causing
problems that do not exist in previous versions.  For most part,
net-snmp v4.2.5 fixes a number of things a small number of people found
problematic in v4.2.4.  However, v4.2.5 also created problems for a
small number of users that did not exist in v4.2.4.

So, in reality, my package has two (2) versioning systems running in
parallel: somebody else's and leaf/mine.  How can cvs facilitate this
distinction?

  [2] Perhaps, my net-snmp package, for instance, should be in cvs in
  expanded form, so that when only one (1) or a few file contents change,
  that will be directly reflected in cvs?  Under this scenario, when only
  a single file -- perhaps, the primary binary? -- is changed, users can
  checkout only that file.
 
 This sounds good.

I am new to cvs; so, bear with me.

Under this scenario, committing to cvs directory structures, cvs is
responsible for knowing whether or not a specific file or directory has
changed?  Any change, including mod/grp/own?

What happens when I decide that /usr/sbin/ntp_setup actually belongs
/usr/bin/ntp_setup?  Or, /usr/sbin/ntp_setup becomes /usr/bin/setup_ntp?

Clearly, cvs cannot know my intent, in this regard.  When committing a
directory change, under this scenario, how should it be done?

  [3] Item [2] presents a difficulty when a user wants the whole LRP
  package as one (1) LRP file.  Is there some way to properly archive and
  compress a cvs directory tree and check that out?
 
 If possible, but probably not. Probably should use both expanded and
 packaged form.

Yes, I like this, too.

  [4] I am still confused on how best to handle package descriptions.
  http://leaf.sourceforge.net/devel/helices/net-snmp/ presents several
  TXT files that, once clicked on, present descriptive text regarding the
  LRP's that reside in versioned directories below this one.  Another
  example is Jacques Nilo's http://leaf.sourceforge.net/devel/jnilo/
  wonderful page that links to installation and troubleshooting
  information.  How are we to do this under cvs?
 
 After presenting two approaches you use the pronoun this??

I am sorry; but, I lumped these two together to make a generic
documentation point.

During commit, I am presented with an editor session, in which I am
allowed to enter text.  I wonder whether or not this allowance should
rather be a requirement?

What is it that this commit blurb is intended to convey?  Is this
intended to be an introduction to the package?  A simple statement of
my/leaf or somebody else's version upgraded to whatever?

What should I, joe-leaf-user, expect to find while perusing ViewCVS?

 CVS is designed to handle directories full of information... so a
 directory tree of html documents is a natural thing to enter.
 
 An idea...
 
   net-snmp/
 README.txt
 package/
   net-snmp.lrp
 target/
   etc/
 blahblah
   usr/
 bin/
   snmpbinary
   ...
 doc/
   index.html
   images/
 image1.jpg
   ...
 src/
   sourcefiles...
 
 Let CVS deal with versioning.

I rather like this structure.  It is intuitive to navigate, complex
enough to deal with complex packages, and simple enough to maintain.

I worry, however, if every developer goes about creating some adhoc
structure to their liking . . .

OK, yes, it is time to stop worrying about whatever shenanigans some
other might do ;

 David Douthitt has advocated (and it sounds good to me but I haven't done
 it myself) a mechanism whereby sources obtained from other sources are
 kept in original form and a parallel directory containing patchfiles and
 compilation instructions is generated to allow LEAF-specific modifications
 to be maintained separate from the original source tree if
 necessary.  Read the archives... :)

I've been looking at what others have done and when I looked at David's,
I saw a directory structure that didn't mean anything to me and could
not find any files, other than Makefile.  What am I missing?

-- 

Best Regards,

mds
mds resource
888.250.3987

Dare to fix things before they break . . .

Our

Re: [Leaf-devel] CVS structure ??? [LONG]

Mike Noyes wrote:

On Wed, 2002-07-10 at 15:16, Michael D. Schleif wrote:

Jeff Newmiller wrote:

On Wed, 10 Jul 2002, Michael D. Schleif wrote:

[1] Should I have separate trees for different underlying versions of
net-snmp? For example, I committed net-snmp v4.2.4. I am contemplating
building and committing both v4.2.5 and the totally different
distribution v5.x. So, one line of thinking is like this:

devel/helices/net-snmp/v4.2.4/netsnmp.lrp ...
devel/helices/net-snmp/v4.2.5/netsnmp.lrp ...
devel/helices/net-snmp/v5.0.2/netsnmp.lrp ...

This seems quite the wrong direction. CVS is supposed to manage
versioning completely independently of the directory structure.

Yes, I agree. However, I am dealing with somebody else's software and
making it suitable for leaf. Obviously, I can have several iterations
of net-snmp v4.2.4 that address various leaf concerns.

Michael,
CVS retains all previous versions of a file in the repository. You can
specify a specific version for retrieval.

Example:

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/leaf/bin/packages/glibc-2.0/dhclient.lrp

Download version 1.10

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/leaf/bin/packages/glibc-2.0/dhclient.lrp?rev=HEADcontent-type=application/octet-stream

Download version 1.1

http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/leaf/bin/packages/glibc-2.0/dhclient.lrp?rev=1.1content-type=application/octet-stream

Yes, these are our (leaf) _cvs_ versions. However, how can a user
select net-snmp v4.2.4 when my net-snmp version is 1.1?

What happens when I decide that /usr/sbin/ntp_setup actually belongs
/usr/bin/ntp_setup? Or, /usr/sbin/ntp_setup becomes /usr/bin/setup_ntp?

Clearly, cvs cannot know my intent, in this regard. When committing a
directory change, under this scenario, how should it be done?

If we had shell access to the repository, we would hand edit the
structure change. SF doesn't allow us shell access to the cvs server, so
we need to open SF support requests to make changes like this.

If this is all that is available to us -- and, really, such requests
seem to be available to only a few, like you, Mike -- then, it behooves
me to select a good structure now, before I have to request alot of
changes. That is why I belabor this point now.

[ snip ]

What should I, joe-leaf-user, expect to find while perusing ViewCVS?

doc -- released documentation
bin/packages -- released packages sorted by library type/revision

binary files for LEAF release/branch tree (write access controlled
by lead developer)
/bering
/dachstein
/oxygen
/packetfilter
/wisp-dist
/wrp
src -- source code

Is that like Jeff's earlier directory structure outline, or is this
referring to the text to include in the cvs commit blurb?

I worry, however, if every developer goes about creating some adhoc
structure to their liking . . .

Think of the devel tree as individual repositories, and the doc, bin,
and src trees as community resources. Did that help?

Right now, I'm only thinking about what goes under my devel/helices
tree. How that gets tied into dcd, bering, or whatever, is another
issue, which I've decided to ignore for the moment. Remember, this all
started with your request to me to commit my net-snmp packages. I
committed the LRP's only, and since I've begun to plan committing
several other items. It's this planning that has me hung now; but, I'd
really like to put that behind me ;

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 . . .

---
This sf.net email is sponsored by:ThinkGeek
Two, two, TWO treats in one.
http://thinkgeek.com/sf

___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel

[Leaf-devel] dcd: cleanup issues ???



Several months ago, Charles and I had an off-list discussion regarding
several dcd related issues.  I know that he has his todo list, to which
I've contributed possible solutions; but, I also have issues with which
I've struggled on my own.

One thing that Charles and I want to do is remove all user configurable
parameters from all init scripts.  To that end, I have reviewed all
/var/lib/lrpkg/*.conf, based on this list of packages that I use:

bash, bwidth22, daemontl, dhclient, dhcpd, djbutils, dnscache, etc,
ifconfig, ipsec, iptraf, libdb, libm, libpcap, libz, lncurses, local,
lrdline2, mawk, modules, netsnmp, netsnmpd, nmbd-207, ntpclnt, qmail,
ramlog, root, rsync, sftp, ssh, sshd, tcpdump, tinydns, vim, weblet

I am left with three (3) init scripts that require attention, listed
here with my recommendations:

[1] /etc/init.d/netbase (re: /sbin/portmap  inetd)
remove references to portmap; leave inetd

[2] /etc/init.d/netstd_init (re: /usr/sbin/routed)
remove file entirely

[3] /etc/init.d/netstd_misc (re: /usr/sbin/bootparamd)
remove file entirely

My removal recommendations are based on functionality currently included
dcd v1.0.2.

What am I missing?

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 . . .


---
This sf.net email is sponsored by:ThinkGeek
Two, two, TWO treats in one.
http://thinkgeek.com/sf

___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [Leaf-devel] dcd: cleanup issues ???



Michael D. Schleif wrote:
 

[ snip ]

 One thing that Charles and I want to do is remove all user configurable
 parameters from all init scripts.  To that end, I have reviewed all
 /var/lib/lrpkg/*.conf, based on this list of packages that I use:

[ snip ]

 My removal recommendations are based on functionality currently included
 dcd v1.0.2.

Also, in standard dcd v1.0.2, what program uses /etc/rpc?

-- 

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 . . .


---
This sf.net email is sponsored by:ThinkGeek
Two, two, TWO treats in one.
http://thinkgeek.com/sf

___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [Leaf-devel] dcd: cleanup issues ???



guitarlynn wrote:
 
 On Wednesday 10 July 2002 20:06, Michael D. Schleif wrote:
 
  Also, in standard dcd v1.0.2, what program uses /etc/rpc?
 
 NFS and SUN login. I think a few people are using this style
 of access on LEAF boxes.

O, now I see it:

/etc/init.d/mountnfs.sh

OK, /etc/rpc needs to stay . . .

-- 

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 . . .


---
This sf.net email is sponsored by:ThinkGeek
Two, two, TWO treats in one.
http://thinkgeek.com/sf

___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [Leaf-devel] OpenSSH security

2002-07-03 Thread Michael D. Schleif



Nathan Angelacos wrote:
 
 I'm curious about /etc/group modification?
 
 I've upgraded two (2) potato's and two (2) woody's.  Yes, there is a
 new user in passwd/shadow; but, I do not have any new group for
 sshd.
 
 Yes, I have seen the instructions for installing manually; but, I
 cannot find a reason for the special group.
 
 What do you think?
 
 Good question.  I wondered the same thing, figured 'cause Theo said
 so.. and dismissed it.  But after you asked, I checked the source...
 :-)
 
 sshd.c in privsep_preauth_child does a setgid() from the sshd's
 primary group (in passwd) when setting up the chroot jail.  The
 manual instructions make sure that the uid:gid is sshd:sshd.
 So I guess 'cause Theo said so works. :-)
 
 I'm curious though, on your debian systems, what is the gid for the
 sshd user?  The sshd.c source seems to indicate that sshd will fail
 if the group doesn't exist.

OK, here is the debian position:

[a] # grep ssh /etc/passwd
/etc/passwd:sshd:x:103:65534::/home/sshd:/bin/false

[b] # grep 65534 /etc/group
nogroup:x:65534:

[c] According to the openssh sshd.8 manpage:

   /var/empty
chroot(2) directory used by sshd during privilege separation in
the pre-authentication phase.  The directory should not contain
any files and must be owned by root and not group or world-
writable.

[d] debian changed this at compile time to: /var/run/sshd

[e] So, there is *NO* requirement for group sshd.

[f] There is a requirement for an existing directory to which to chroot
-- he default is /var/empty .

Therefore, in my ssh v3.4p1 distribution for LEAF, I adding the sshd
user and using the debian nogroup group.  Regardless which way to go, an
*empty* /var/empty directory *MUST* exist!

hth

-- 

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 . . .


---
This sf.net email is sponsored by:ThinkGeek
No, I will not fix your computer.
http://thinkgeek.com/sf

___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [Leaf-devel] OpenSSH security

2002-07-02 Thread Michael D. Schleif



Jacques Nilo wrote:
 
[ snip ]

  At this point, a default compile of OpenSSH will use privilege separation
  with the sshd user.  For new LEAF installations/releases, do we want to
  deviate from the (new) OpenSSH standard, or accomodate it and move on?
 
 I have a clear position on this: we should stick to the new default openssh
 config which implies privilege separation an therefore the creation of a sshd
 user and group (Debian does this, Mandrake as well)
 I will update Bering accordingly for the final release and update my openssh
 package suite accordingly.

I'm curious about /etc/group modification?

I've upgraded two (2) potato's and two (2) woody's.  Yes, there is a new
user in passwd/shadow; but, I do not have any new group for sshd.

Yes, I have seen the instructions for installing manually; but, I cannot
find a reason for the special group.

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 . . .


---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel

Re: [Leaf-devel] OpenSSH security

2002-07-02 Thread Michael D. Schleif



Nathan Angelacos wrote:
 
 I'm curious about /etc/group modification?
 
 I've upgraded two (2) potato's and two (2) woody's.  Yes, there is a
 new user in passwd/shadow; but, I do not have any new group for
 sshd.
 
 Yes, I have seen the instructions for installing manually; but, I
 cannot find a reason for the special group.
 
 What do you think?
 
 Good question.  I wondered the same thing, figured 'cause Theo said
 so.. and dismissed it.  But after you asked, I checked the source...
 :-)
 
 sshd.c in privsep_preauth_child does a setgid() from the sshd's
 primary group (in passwd) when setting up the chroot jail.  The
 manual instructions make sure that the uid:gid is sshd:sshd.
 So I guess 'cause Theo said so works. :-)
 
 I'm curious though, on your debian systems, what is the gid for the
 sshd user?  The sshd.c source seems to indicate that sshd will fail
 if the group doesn't exist.

Precisely my point!  sshd is working without incident on all of these
boxen.  I thought the same as you, that this should fail of give me some
kind of error log; but, I haven't found anything wrong and I've been
using it for nearly a week now ;

How can I check which gid it's using, since once it's successfully
logged in it resorts to root?

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 . . .


---
This sf.net email is sponsored by:ThinkGeek
No, I will not fix your computer.
http://thinkgeek.com/sf

___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel

[Leaf-devel] DCD: ipfilter.conf patch

2002-05-06 Thread Michael D. Schleif



Here is a patch for /etc/ipfilter.conf [DCD, v1.0.2], the need for which
I discovered while researching my multiple external interface challenge:

# diff -bu ipfilter.conf ipfilter.conf.OLD
--- ipfilter.conf   Mon May  6 16:30:20 2002
+++ ipfilter.conf.OLD   Mon May  6 16:10:14 2002
@@ -171,11 +171,8 @@
   local DST_PORT=${5:-$3}

# For internal connections
-   for NET in $INTERN_NET; do
$IPCH -A forward -j MASQ -p $1 -s $DMZ_NET $DST_PORT \
-  -d $NET -i $INTERN_IF
-###   -d $INTERN_NET -i $INTERN_IF
-   done; unset NET
+-d $INTERN_NET -i $INTERN_IF

   if [ $OUTBOUND_ALL != YES ]; then

@@ -774,14 +771,7 @@
walk_list DMZ_SERVER $INIT_INDEX port_forward

# Masquerade internal network to DMZ network
-   for NET in $INTERN_NET; do
-###$IPCH -A forward -j MASQ -p all -s $INTERN_NET -d
$DMZ_NET -i $DMZ_IF
-   $IPCH -A forward -j MASQ -p all -s $NET -d $DMZ_NET -i
$DMZ_IF
-   done; unset NET
-   $IPCH -A forward -j MASQ -p all -s $net -d $DMZ_NET -i $DMZ_IF
-
-   done
-   unset net
+   $IPCH -A forward -j MASQ -p all -s $INTERN_NET -d $DMZ_NET -i
$DMZ_IF

if [ $DMZ_OUTBOUND_ALL = YES ]; then

@@ -800,7 +790,6 @@
-o $MASQ_SWITCH = yes ]; then
for NET in $INTERN_NET; do
$IPCH -A forward -j MASQ -p all -s $NET -d 0/0 -i
$EXTERN_IF
-
done; unset NET
 fi


-- 

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 . . .

___

Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: [EMAIL PROTECTED]

___
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel

[Leaf-devel] ANN: ntpclient.lrp v3.45

2002-04-26 Thread Michael D. Schleif



Although there are already several other ntpclient.lrp's out there, this
one is different:

[1] It is the smallest that I've found:

# ls -al ntpclient.lrp
-rw-r--r--1 helices  leaf 7651 Apr 26 09:32 ntpclient.lrp

[2] It includes an init script starting, stopping and configuring the
daemon:

/etc/init.d/ntpclient

[3] It includes standard complement of /var/lib/lrpkg/ntpclient.* files.

Look here:

http://leaf.sourceforge.net/devel/helices/ntpclient/ntpclient.txt

http://leaf.sourceforge.net/devel/helices/ntpclient/ntpclient.lrp

-- 

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] ANN: ntpclient.lrp v3.45

2002-04-26 Thread Michael D. Schleif



Charles Steinkuehler wrote:
 
  Although there are already several other ntpclient.lrp's out there, this
  one is different:
 
 snip
 
  http://leaf.sourceforge.net/devel/helices/ntpclient/ntpclient.txt
 
  http://leaf.sourceforge.net/devel/helices/ntpclient/ntpclient.lrp
 
 I'm finally getting around to doing some work on Dachstein, and I'm looking
 at adding this package.  I'm wondering how you dealt with the fact that the
 package name is more than eight characters...

Good catch!  My bad ;

Anyway, this also prompts me to include the actual init script that I'm
using -- one that works ;

Obviously, I forgot what happens when you put LRP files on a floppy disk
in dos format . . .

So, to clear things up, I've decided to rename the LRP: ntpclnt.lrp

However, I am leaving the internal files labelled: ntpclient -- nine (9)
letters long:


http://leaf.sourceforge.net/devel/helices/ntpclient/

http://leaf.sourceforge.net/devel/helices/ntpclient/ntpclnt.lrp

http://leaf.sourceforge.net/devel/helices/ntpclient/ntpclient.txt


Thank you, for the constructive and helpful criticism.  Any other ideas?

-- 

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] Access to developer sites ???

2002-04-05 Thread Michael D. Schleif



As I recall, prior to the recent changes to
http://leaf.sourceforge.net/, there was a link to a developer's site
via the main menus on the leftmost side to this page.

Perhaps, I am thinking of the Main Menu | Developer Content link.

However, would it be valuable to put these links under Sourceforge
Project | Developers, somewhere in that matrix to the right of the
developer's name?

In fact, now that I look closer, some names, themselves, are linked to
the user summary page, as well as the usernames.

Perhaps, those names under Developer column could actually link to the
developer's leaf site?

I, for one, would find that helpful.

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

[Leaf-devel] Past Articles repository ???

2002-04-05 Thread Michael D. Schleif



Recently, I have seen several posts regarding searches for items seen in
LEAF articles quite in the past.

I also have found myself looking for something that I'd swear I had seen
on the main ttp://leaf.sourceforge.net/ page, or in the rightmost Past
Articles column.

Would it be valuable to archive *all* of these articles on some other
page, perhaps linked to at the bottom of the current Past Articles
column?

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] DCD /etc/init.d/netstd_misc ???

2002-03-07 Thread Michael D. Schleif



Likewise:

/etc/init.d/netstd_init ???

Michael D. Schleif wrote:
 
 Why does this file exist?  It does nothing and wastes space . . .
 
 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] Re: Standards and due process :-)

2002-03-01 Thread Michael D. Schleif



Charles Steinkuehler wrote:
 
  It sounds almost like you want a minimal set of enumerated binaries and
  functions, and then Oxygen would add set X and Dachstein would add set Y.
 
  Nope. No. Nein. Niet. Non. :-)
 
  There is NO baseline.
 
  There is one standard: the formation of a package.
 
  The final decision on a configuration always rest with the user and she
  expects the tools to do her job.
 
 There actually *IS* a baseline implicit in the above.  *SOMETHING* has to
 get linux booted, create/mount a root filesystem, and load the proverbial
 package.  This implies some sort of boot-strapping code, as well as some
 sort of package format.

Yes -- the bounds to which are the objects of my lines of questioning .
. .

[ snip ]

 Once the packaging system is smart enough to know which files are
 configuration files (and maybe even able to tell which files have changed),
 it becomes much easier to support a variety of potentially complex issues,
 allowing users, developers, or the in-between tinkerers to setup backups
 and the loading of configuration data the way they want.

Believe it or not, this is the end to all of my lines of questioning. 
Once we know this and know what can be expected -- and, corrallarily,
what cannot be known -- then, and only then, can that system be ``in
control'' and we can say that we are managing that system.  Until that
time, there is simply too little known about that system to quantify the
degree of certainty that we can claim.

Perhaps, this is where David parts company, since he is not interested
in building firewalls; rather, his interest -- imho -- lies more in
pushing various limits of these creatively designed systems.  Yes, that
is admirable creativity and inventiveness -- kudos, David!  However, my
primary interest in LEAF is management, monitoring and security based. 
I, for one, do *not* see these priorities as mutually exclusive; rather,
I believe that these, and others equally different, views can coexist
and grow and flourish together under the aegis of LEAF . . .

 Lots of nifty ideas about this, but not enough time to jot everything down,
 and I don't want David getting mad at me again ;-)
 
 Seriously, I hope to have some time next week to begin to get some of the
 ideas bouncing around in my head out into the open, where they can grow and
 develop from everyone's input (or maybe they'll shrink back and be killed by
 the light).

I look forward to new ideas . . .

-- 

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] Re: Standards and due process :-)

2002-02-19 Thread Michael D. Schleif



Serge Caron wrote:
 
 I apolologize for leaving in the middle of an important conversation.
 Unfortunately, this will happen from time to time. Life gets in the way :-)

I, too, have been erstwhile distracted and now is not the best time to
take on all detractors.

It is disconcerting when one's words are taken other than literally and
totally out of context.  Never let it be said that that, alone, stopped
me ;

Nevertheless, now that Serge is back online, a few comments are in line:

[ snip ]

 It is emotions and feelings that will drive Mike to discount his opinion
 because he is not producing code and it is emotions and feelings that
 prompt Charles to put value where value is due. I entirely support the
 expression of these emotions and feelings (which includes humor: I guarantee
 that if you can laugh at yourself, you will NEVER cease to be amused :).
 
 My personal experience is that you ride change, much like a horse, sometimes
 just for fun, sometimes to get from point A to point B.

Sometimes, I ride the horse, because I am a horseman and horsemanship
(change management) is a job at which I excel.

 In this case, I have submitted an idea supported by a bunch of definitions.
 The idea is that the contents of our initial RAM disks be unambiguously
 enumerated which imply that root (/) be moved to any other package (your
 choice!) which I call the default store.

``Unambiguous enumeration'' sounds precipitously close to defining
convention, since convention, by definition, is ``General agreement or
concurrence; arbitrary custom; usage; conventionality.''  When you
distill a process down to its basic steps, then you have discovered that
process's standard mode of operation.

O, my!  There is that dangerous word: standard.

Nowhere in this process of discovery have I mentioned stricture,
restriction, preclusion, obstruction, commandment, law, edict -- nor any
other synonym for boundary, imposition nor limitation.  That, dear
readers, is intentional.

[ snip ]

 I have seen this idea mocked and the discussion go all over the map from
 intents of imposing a de facto standard to attempts of restricting the
 expression of individuality of developers. Yet, given the fact that Oxygen
 1.9+ may be compatible with tar.gz and plain gz ramdisks, and given the fact
 that the default store always retain the standard LRP format, I can only
 see benefits from this idea for Oxygen. Because it is an idea, it can be
 implemented by anybody in the form of their choice and does not have to BE
 part of a product offering. It can be documented and left at that. In my
 case, I wanted to use the product NOW and I choose to edit the two files.
 Further, when Oxygen 1.9+ becomes available, I will drop my home.lrp on the
 new kit and reboot with all my stuff intact. Instant upgrades are always
 interesting :).

And, they are *possible*, because you have discovered the conventions
and standards inherent in Oxygen 1.9+.  If that is all that you have
accomplished, that would be enough to illustrate my point.  However,
your theses are far more extensible than that, which prompts me to
pursue this further . . .

 Not only do I think that David Douthitt is wright when he says there is no
 baseline, I aim to write my code for a minimalist implementation of
 everything (including sed :). My baseline is lower than his. However,
 Michael Schleif is also wright when he says 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. 

To distill a set of foreign processes into a common set of shared
conventions and standards *IS* a baseline!

If there is nothing in common between any two LEAF distributions, then
there could not be such camaraderie as evidenced by this List Service. 
Fact is, there is more in common between these several distributions
than there is between any two developers themselves.  The fact that this
genre, if you will, ``a class of artistic endeavor having a
characteristic form or technique'', otherwise known as Linux Embedded
Appliance Firewall, has a future and is moving from the status quo
toward mainstream 2.4x kerneldom, tells me that this dialectic is a
process in motion.

What longterm purpose does it serve to keep these specifications arcane?

 I believe that it is possible to have these specifications without a
 baseline. When told that it was impossible to abstract something that would
 be common to 2.2 and 2.4 kernels, I actually produced a floppy on which
 people can comment. To quote from my February 11 post:
 You CAN voice your opinion and submit suggestions WITHOUT spending long
 hours in quality control. And so can anyone else. There is a disk at
  http://leaf.sourceforge.net/devel/scaron/discussion.img. It contains one
 boot loader, two kernels, four

Re: [Leaf-devel] Re: Standards and due process :-)

2002-02-19 Thread Michael D. Schleif



Serge Caron wrote:
 

[ snip ]

 In the long term, I want to be able to run from secure media. In the short
 term, I use CD for write protected storage and floppy for write-enabled
 storage (wich I write-protect between sessions :). Suppose a package
 designer stores something in /etc/mypackage (which is either a file or
 directory, your choice). This designer has many choices:
 1- claim /etc/mypackage as part of this package
 2- rely on an unwritten standard or tacit convention that /etc belongs to
 another package (presumably etc.lrp)
 3- rely on the user's knowledge of the LEAF standard that his file will end
 up in the default store.
 
 If /etc/mypackage is also a directory, the package designer can optimize
 the backup operation by omitting certain temporary files (enumerated in
 xyz.anything.list).
 
 Suppose that the system of partial backups is finely tuned so that modified
 files always end up in write-enabled storage. Suppose also that packages
 from read-only storage are always loaded before packages from write-enabled
 storage, eg, you don't loose modifications. Finaly, presume the goodwill of
 the package developer, eg, package xyz claims nothing out of its immediate
 territory.
 
 This above set of conventions places the entire burden of protecting this
 package in the hands of the package designer with no support from the LEAF
 appliance it is supporting or the user operating the machine. This is
 precisely Michael's line of questioning. If there is a standard, then the
 user knows what is going on and backup is one of the user's many
 responsibilities. However, we all know that history has been written before
 us and that pppd uses /etc/ppp and dhcpd uses /var/state, etc: addressing
 the problem from this angle IS next to impossible, especially if we try to
 make a sysadmin out of the user.

Yes.  Again, that a system successfully boots up is great!  That I know
what to expect in a system long after bootup is quite another thing ;

Perhaps, once we understand how the system works, it might be possible
to agree on silly little things like location of configuration files. 
If it contributes to better system performance, better system security,
c., perhaps it may not be out of line to suggest that /var/state/dhcp
be a symbolic link to /etc/dhcp?  Such a thing is trivial to a package
developer; but, no such step will likely be taken, unless there is some
convention that lends credence and bestows value to this decision.

 This user is also subject to constraints of his own. The readme file in /
 stating that trespassers will be prosecuted to the maximum extent of the law
 is a real life example. The file belongs to the user and even he can't
 choose the location. Another example is dropped files. You and I may find
 that dropping /var/run/xyz.pid files is OK. Unfortunately, it does not match
 many audit policies, including those of my organization.
 
 None of these things are issues if the filesystem is persistent storage such
 as hard disk. When it is not, you have to expect that somebody else than
 LEAF will select which files goes to write-enabled storage. As of now, I am
 doing OK by rewriting most lists (on the fly!) and saving the default store.
 
 This system is far from perfect and this is why I am supporting Michael's
 quest :-)

Building on your notion of ``unambiguous enumeration'', let it be said
that the more that we know about a running system, the more that we
understand the processes in motion that comprise that system, the more
secure we can be.  What is security?  Part of it is knowing that a
system is performing according to a specific set of specifications. 
Knowing which files, in what state and allowable contents, c. we should
expect on the running system is, itself, a specification.  As such, that
specification is also a standard by which we can measure such
interesting Events as system load, performance, intrusion, c.

[ snip ]

 I am less excited by the building of the LEAF components themselves at this
 point (No! I do NOT like Red Hat 5.2 :-). I am certain that we can come up
 with an unambiguous way of specifying the whole system, even if we have to
 point out all the gotchas one by one. Then I will be excited for anything
 else I can put in there :-)

Once we arrive at this ``unambiguous way of specifying the whole
system'', then we have blown the lid off of previous limitations. 
Developers can concentrate on creating packages even better suited to
the LEAF environment.  As it is, we grab some off-the-shelf source,
compile it on our slink over there in the corner and figure out how to
shoehorn it into an LRP file.  There is much more that many more people
can do to contribute to the greater good of this project, once the
system is understandable to outsiders . . .

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

Re: [Leaf-devel] Re: Standards and due process :-)



Correction: my bad . . .

Michael D. Schleif wrote:
 
 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.

[ snip ]

 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
  
  This should read: LOCAL

 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 ;

-- 

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] Re: Standards and due process :-)



Correction #2: my bad . . .

Michael D. Schleif wrote:
 
 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.

[ snip ]

 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
   
   This should be `local'

-- 

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] Re: Standards and due process :-)



David Douthitt wrote:
 
 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.

Sorry, I was running off at the keyboard and forgot to check this:

# /bin/sed -V
GNU sed version 2.05

 mawk.lrp is available, as is diff.lrp.  I think busybox comes with
 sort - 0.60.2 anyway, in Oxygen...

The point is, it is one thing to get a basic system to boot and
initialize -- it is quite another to manage the running system.

I agree that [mn]*awk is a luxury that may not be warranted in a base
system.

However, to manage the running system, it may be prudent to monitor
changes to that running system, especially since one of the primary
reasons for that system is to guard and protect the rest of the network
on which it resides.

In that spirit, I believe that real sort, cmp and possibly diff are
warranted.

 But cmp?  Who needs that?

Besides the it's size?

# uname -a
Linux Loki 2.2.19 #1 Sat Oct 20 18:09:49 EST 2001 i686 unknown

# ls -l /usr/bin/cmp /usr/bin/diff
-rwxr-xr-x1 root root 9336 Aug 23 05:58 /usr/bin/cmp
-rwxr-xr-x1 root root62076 Aug 23 05:58 /usr/bin/diff

-- 

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] Re: Standards and due process :-)



David Douthitt wrote:
 
 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.

I am sorry that you always miss my point.

We are on the LEAD List Service and happen to be discussing LEAF
issues.  However interesting it maybe to discuss AIX, HP-UX, Irix, c.,
these are non sequitur to this particular discussion.

  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.

In your opinion, is that a `good' choice?

  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?

Precisely my point!

 Not only is standardization impossible, but the little variances are
 what makes a distribution individual and perhaps better than others.

Nothing is impossible.

In fact, your dependent clause, again, is my point!  We have something
in LEAF that is unique and worth defining better.

 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...

Again, what is your point in context of LEAF?

 I don't think we can force standardization - it's this sort of thing
 that makes the djbtools license so offensive...

How many times need I state: ``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.''

To take statements out of context does not make your arguments stronger.

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] Re: Standards and due process :-)



Serge Caron wrote:
 

[ snip ]

 I am waiting for a plane and cannot do that right now. I suggest you visit
 http://leaf.sourceforge.net/devel/scaron/leaf.htm with a fresh eye and mess
 around with the discussion.img floppy.
 
 Please take apart root.lrp before you start (just for fun!). If I remember
 correctly, the floppy is designed to loose klogd if you backup root before
 you edit /bin/busybox.links to remove the line /sbin/klogd. So you can
 experiment either way. Don't flame me if it's too simple :-)

I didn't realize that you had a webpage and formal presentation of your
theses.  Clearly, I entered this discussion through some later portal ;

Where is this `discussion.img floppy'?  I cannot find it referenced on
your site . . .

-- 

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] 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] 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

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: Standards and due process :-)

2002-02-13 Thread Michael D. Schleif



Serge Caron wrote:
 

[ snip ]

 By formulating the concept of a default store and that of an exclusion list,
 here is _what_I_do_today_ : I boot from a CD which gives me all the storage
 I need for the job at hand. I define my default store to be on the _floppy_.
 So far, so good? Then I have this code snippet as part of the boot sequence:
 
 for pkg in /var/lib/lrpkg/*.list; do
   sed -e /^etc/d -e /^[/]etc/d -e /^[.][/]etc/d \
   ${pkg}  ${pkg}.light
   cmp -s ${pkg} ${pkg}.light
   if [ $? = 0 ]; then
 rm ${pkg}.light
   else
 echo ${pkg}
 mv ${pkg}.light ${pkg}
   fi
 done

[ snip ]

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

[2] How do you account for ${pkg}.exclude.list?

[3] How do you account for CONF files that do not reside under /etc?

[4] Where do you get `cmp'?

-- 

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] Introduction: mds

2002-02-12 Thread Michael D. Schleif



Hello

Finally, I am a card carrying member of your elite group of raconteurs! 
Hopefully, the stories I tell will be of some value to somebody here ;

Although, most of you are very private and hold your credentials close
to your chest, I've been around the horn several times in more than
thirty years of architecture, design, implementation and management of
systems and processes.  The diligent among you will find my curriculum
vitae and the rest won't care to -- I am mds (aka, helices).

Anyrate, I have moved some files to:

leaf.sourceforge.net:/home/groups/l/le/leaf/devel/helices

Obviously, I do not yet have any fancy webpage; but, the files are
extant and follows a brief summary:

deny_stats.sh

I email myself this summary of DENY'ed packets every 4 hours

dhcp_2_dns.sh

I use this to manage dhcpd hosts in the tinydns.lrp data file

diskfree.sh

I use this as a replacement for checkfreespace() in /etc/multicron-p
I believe that this satisfies the requirements discussed in this
thread:


http://www.mail-archive.com/leaf-devel@lists.sourceforge.net/msg04022.html

netsnmp.lrp

NET-SNMP, v4.2.3, cli applications that can be used to query and act on
remote SNMP agents

netsnmpd.lrp

NET-SNMP, v4.2.3, agent that binds to a port, awaits requests from SNMP
management software  broadcasts snmp traps according to its known MIB's

nettrapd.lrp

NET-SNMP, v4.2.3, receives and logs snmp trap messages sent to the
SNMP-TRAP port (default udp 162) on the local machine.

sangomaWanpipe.tgz

I worked with Sangoma for two months to get this working and optimized
under DCD, v1.0.2.  We still experience some spurious error messages
during bootup; we have not been able to prevent them and they may not
show up on all hardware; but, I agree with Sangoma that these are
spurious and do not affect functionality.  We are going to release
another version soon.  Included in this TGZ are four (4) modules that
must be used *instead* of those included with DCD:

/lib/modules/net/sdladrv.o
/lib/modules/net/syncppp.o
/lib/modules/net/wanpipe.o
/lib/modules/net/wanrouter.o
wanpipe.lrp

Anybody know why DCD puts this one here?

/lib/modules/misc/wanrouter.o


I am here for the long haul.  Suggestions, bug reporting and
constructive criticism are encouraged -- preferably in the public forum
of this List Service.

Thank you, for inviting me into your fold . . .

-- 

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 :-)

2002-02-12 Thread Michael D. Schleif


Serge =

Serge Caron wrote:
 
 I got my first paycheck from a computer center (as they were called then :)
 in September 1970. You do the math. It is obvious that your message below
 was heathfelt and the product of a long experience. I respectfully request
 that you humor me into reading this message to the end.

[ snip ]

Please, trust that I am not ignoring you and that my passion is, indeed,
genuine.

I have read your post a couple times and, although I first thought that
you are critical of my position, I am interested in pursuing this
dialectic.

Nevertheless, I am in a bit of a crunch right now and ask that you grant
me a brief reprieve until later this week . . .

-- 

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: netsnmp

2002-02-09 Thread Michael D. Schleif


kp =

I am releasing -- to you, per your request -- my three (3) leaf/lrp
packages based on NET-SNMP.  Descriptions for each package follow.

For whatever reason, I cannot get cvs access
http://leaf.sourceforge.net/devel/helices -- anybody know what I need
to do to become a card carrying leaf developer?

Notice, I have successfully tested substantial functionality of netsnmp
and netsnmpd; but, I have no current infrastructure to adequately test
nettrapd.

Also, notice that I do not believe in community string `public'.  Hence,
users *must* edit /usr/share/snmp/*.conf _prior_ to successfully doing
anything with any of these packages!

As always, constructive feedback and bug reports are welcome and
invited.

What do you think?


netsnmp.lrp

SNMP toolkit provides a suite of command line applications
that can be used to query and act on remote SNMP agents.

http://net-snmp.sourceforge.net/#Documentation
http://net-snmp.sourceforge.net/man/snmpcmd.html

NOTE: netsnmpd.lrp *MUST* be installed prior
  to installing netsnmp.lrp



netsnmpd.lrp

SNMP agent which binds to a port, awaits requests from SNMP management
software  broadcasts snmp traps according to its known MIB's

http://net-snmp.sourceforge.net/man/snmpd.html

NOTE: This package *MUST* be installed prior to installing these:
netsnmp.lrp
nettrapd.lrp



nettrapd.lrp

SNMP application that receives and logs snmp trap messages sent to
the SNMP-TRAP port (default udp 162) on the local machine.

http://net-snmp.sourceforge.net/man/snmptrapd.html

NOTE: netsnmpd.lrp *MUST* be installed prior
  to installing nettrapd.lrp



KP Kirchdörfer wrote:
 
 Am Freitag, 8. Februar 2002 19:55 schrieben Sie:
  KP Kirchdörfer wrote:
   Hello Michael;
  
   I'm preparing a new build of dachstein-1.0.2-CD with glibc 2.1.3.
  
   How far has your work with netsnmp grown?
  
   I'm interested to replace the defect packages by your's if you
   feel they're usable.
  
   What is your timeframe?
 
  It builds and it works on my testing through 3AM this morning.
 
  I have five (5) LEAF firewalls that I'm monitoring with MRTG.  I
  was starting to use MRTG to monitor else than interface traffic
  when I discovered the glitches.
 
  I am confident that it is currently workable and should be
  packageable be end of this weekend.  Of course, that depends on
  whether or not I can actually submit anything to leaf/sourceforge
  and when . . .
 
  What do you think?
 
 I think that this more than the previous package, well done.
 
 And if you can package it, send the lrp's as attachment if you have
 to wait for sourceforge.
 
 I planned to get a release out today, but will wait...

-- 

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] How to gzip only a new application's files ???



Surely, all of you experienced LRP'ers have tackled this one!

OK, I build a new application on a slink development box.  Once I do
`make install', how do I know an exhaustive list of *ALL* files to turn
into the LRP file?

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] How to gzip only a new application's files ???



Matt Schalit wrote:
 
 And remember, mds,  there's:
 
  make -n install
 
 to output the commands but not execute them.

Cool!  I didn't know that one . . .

-- 

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] Preferred package/filesystem location ???



David Douthitt wrote:
 
 On 2/8/02 at 1:08 PM, Michael D. Schleif [EMAIL PROTECTED] wrote:
 
  Hence, my interest in filesystem and file location standards  . . .
 
 This is exactly the reason for the restrictive djbtools license - he
 wants his code to be in EXACTLY the SAME place in EVERY SYSTEM, and
 wants his code to work EXACTLY the SAME way EVERYWHERE.  Go read his
 explanation...
 
 This is also the reason for the Linux Filesystem Standard (LFS).
 
 I've already described how there are multiple standards - where does
 the kernel go, for example?  Where do new add-on packages go?
 
 Under HP-UX every new package goes in /opt/pkg/ and new libraries,
 manpages, and binaries get their paths added to the appropriate files.
 The PATH and MANPATH are quite long
 
 Also under HP-UX, the use of /usr/local is discouraged; one is
 encouraged to use /usr/contrib
 
 I don't place a lot of faith in standardizing on binary locations...

I'm a devout believer in systems and process.

We are dealing with a very small system with LEAF.  The process of
reaching consensus on conventions, such as filesystem management and
program location, may seem trivial and without value to some; but, as
this system grows, I guarantee that willy-nilly file placement is going
to result in some application stomping on some namespace or another that
some other application insists is its own ;

Having dealt with systems and processes for more than thirty (30) years,
I place a high value on convention and standards.  I am *NOT* talking
about blind restrictions and stricture that chokes the creative spirit;
rather, some simple, commonsense rule-of-thumb that guides the creative
spirit.  It's that spirit that brought me to this venture -- how about
you?  Personally, I have enough to do putting out fires in the bigger
world, I do not have any compulsion to spend countless hours begrudging
LEAF any type of quality control at all!

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] More on dates