[leaf-devel] Bering-uClibc: qmail ???

[Michael D Schleif]

I am very surprised that I cannot find qmail for Bering-uClibc.

What am I missing?

Can somebody, please, make a Bering-uClibc qmail.lrp ???

TIA

-- 
Best Regards,

mds
mds resource
877.596.8237
-
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 . . .
--


signature.asc
Description: Digital signature

Re: [leaf-devel] modutils testing

[Michael D Schleif]

* Charles Steinkuehler <[EMAIL PROTECTED]> [2004:05:10:11:17:09-0500] scribed:


> IIRC, the IPSec scripts don't try to load any modules unless IPSec 
> support isn't already enabled.  I simply load all required modules at 
> boot.  If you really want, you can add new modules to /etc/modules at 
> runtime and simple "svi modutils" to load them.
> 
> I understand the difference of opinion here, but would like to make one 
> request:
> 
> - Can the Bering crew make sure any code that mounts (and leaves 
> mounted) a CD-ROM or other device containing modules be restricted to 
> the modules package?  This would allow me (and anyone else who doesn't 
> like permanently mounting the CD-ROM and symlinking to it) to replace 
> just the modules package with a custom version.  I really don't want to 
> have to run a hacked version of initrd to leave the CD-ROM unmounted.

As a longtime Dachstein-CD user, with dozens of deployed boxen, I cannot
stress strongly enough how much I *DO* concur with Charles.

How difficult can it be to copy those needed modules from the CD modules
directory to /etc/modules at bootup?  Since not all modules will need
this facility, /etc/modules should be kept to a minimum size.  At least
from my experience with DCD, system memory is never a shortcoming, so
copying *ALL* modules to /etc/modules would not hurt my feelings any.

However, keeping CD always mounted is definitely a no-no in my book.

Just my 2? . . .

-- 
Best Regards,

mds
mds resource
877.596.8237
-
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 . . .
--


signature.asc
Description: Digital signature

Re: [leaf-devel] Dachstein-CD -> Bering ???

[Michael D Schleif]

* Charles Steinkuehler <[EMAIL PROTECTED]> [2004:04:29:11:36:11-0500] scribed:
> Michael D Schleif wrote:
> >I have noticed in recent months that Charles is migrating from DCD to
> >Bering, and that migration has entailed some sleight-of-hand over
> >straight Bering.
> >
> >Charles, have you published your DCD-Bering ``distribution''?
> >
> >What do you think?
> 
> Well, I'm not much of a 'magician', but I am upgrading to Bering (at 
> least on my local firewall...I've still got a bunch (6+) of Dachstein 
> based machines in production at various other locations).
> 
> I have not yet released a version of my Bering-CD for a few reasons:
> 
> - I want to make sure there are no additional changed required to my new 
> /linuxrc mods
> 
> - I haven't yet tried the 2.4.24 kernel I want to upgrade to that I 
> built from the uClibc branch but patched with the Bering version of IPSec
> 
> - I haven't fixed everything related to removing /dev/boot (ie: 
> packaging scripts), but I don't think there are any problems from this 
> other than harmless warnings when manually installing packages.
> 
> - General lack of time
> 
> While I am running a 'tweaked' Bering, the main things I modified are 
> available from my posts to leaf-devel.  Other than that, I'm running 
> Shorewall 1.4.10c (direct from the Shorewall site, unmodified for 
> 'out-of-the-box' masquerading), and a bunch of packages from DCD (with 
> newer ssh & bering versions of IPSec).
> 
> I can post a 'release-candidate' iso of what I'm currently running in 
> production online, if anyone's interested.

Yes, I am interested.  I am in no hurry; but, the reason for my post is
that I, too, have many DCD's deployed, and I would like to move up to a
newer kernel and iptables.

When you have time, I will appreciate your work.

Thank you.

-- 
Best Regards,

mds
mds resource
877.596.8237
-
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 . . .
--


signature.asc
Description: Digital signature

[leaf-devel] Dachstein-CD -> Bering ???

[Michael D Schleif]

I have noticed in recent months that Charles is migrating from DCD to
Bering, and that migration has entailed some sleight-of-hand over
straight Bering.

Charles, have you published your DCD-Bering ``distribution''?

What do you think?

-- 
Best Regards,

mds
mds resource
877.596.8237
-
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 . . .
--


signature.asc
Description: Digital signature

Re: [leaf-devel] New linuxrc mods ready for testing

[Michael D Schleif]

* Charles Steinkuehler <[EMAIL PROTECTED]> [2004:03:13:21:51:06-0600] scribed:
> Michael D Schleif wrote:
> >`not be hard-coded' is _exactly_ what I am referring to.
> >
> >I don't know how you are doing this; but, I can see value in having some
> >arbitrary director(y|ies) persist across reboots -- in some applications.
> >
> >So, unless I am misunderstanding the previous dialog on this matter, I
> >am suggesting that, instead of limiting this to `/var/log' and `/tmp',
> >you may consider creating this so that an admin can also do same with
> >`/home', or some other arbitrary directory.
> >
> >Am I making any sense?
> 
> OK, I'm understanding what you're after now.  I probably wouldn't have 
> thought about this, but it should be fairly easy to support, espeically 
> if I fold /tmp into the processing for /var/log (although the syntax 
> might be a bit cryptic...probably a shell variable to indicate which 
> directories are to be mounted).
> 
> Note that it's probably better to mount things like /home using the 
> normal init scripts, rather than linuxrc.

NOTE: I do not -- at this moment -- have a real application for this.
Needing some example directory, /home is the first non-system directory
that came to mind, and that also made some sense in this context.

> To increase the overall flexability of the new leaf.cfg file, it would 
> probably be good to make some 'hooks' (shell functions) that get called 
> once the root filesystem is mounted, and maybe before & after extracting 
> packages.  That would allow a custom leaf.cfg file to do things like 
> mount arbitrary filesystems wherever desired in the heirearchy (ie: 
> /usr, /var, or even /etc, if desired).

I believe that the additional work to accomplish this extends the
flexibility of the overall system, which adds value.

-- 
Best Regards,

mds
mds resource
877.596.8237
-
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 . . .
--


signature.asc
Description: Digital signature

Re: [leaf-devel] New linuxrc mods ready for testing

[Michael D Schleif]

* Charles Steinkuehler <[EMAIL PROTECTED]> [2004:03:13:19:12:31-0600] scribed:
> re-sent (forgot to include the list)
> 
> Michael D Schleif wrote:
> >* Charles Steinkuehler <[EMAIL PROTECTED]> 
> >[2004:03:13:16:47:02-0600] scribed:
> >
> >
> >>I propose making log_mnt a new leaf.cfg variable (could also come in via 
> >>the kernel command line).  Rather than the format you used, however, I 
> >>would like to use the existing PKGPATH/LEAFCFG format (dev[:filesystem).
> >>
> >>If the log_mnt variable is set, linuxrc would mount the log_mnt device 
> >>directly to /var/log, and skip making the tmpfs ramdisk.  If log_mnt is 
> >>unset or null, the current behavior would result.  Does this seem 
> >>acceptable to everyone?
> >>
> >>Also, any reason (or drawback) to handling /tmp exactly the same way?  I 
> >>realize /tmp doesn't need to be persistent, but someone might want to be 
> >>able to mount /tmp on something other than a ramdisk, and I might be 
> >>able to save some space (or at least not grow /linuxrc much) if I fold 
> >>togheter the /var/log and /tmp processing.
> >
> >Need it be hard coded?  Could it be variable-ized, such that I can
> >specify some arbitrary directory (e.g., /home) during initial
> >configuration?  That way, other future exceptions are handled in stride.
> >
> >Notice that I ask this out of ignorance of what is required to
> >accomplish this ;>
> 
> Um...if "it" refers to where the log files reside, currently it *IS*
> hard-coded.  We're discussing making the log partition not be
> hard-coded, and I'm wondering if we should go ahead and make /tmp work
> the same way.
> 
> If I'm mis-understanding your question, please clarify.

`not be hard-coded' is _exactly_ what I am referring to.

I don't know how you are doing this; but, I can see value in having some
arbitrary director(y|ies) persist across reboots -- in some applications.

So, unless I am misunderstanding the previous dialog on this matter, I
am suggesting that, instead of limiting this to `/var/log' and `/tmp',
you may consider creating this so that an admin can also do same with
`/home', or some other arbitrary directory.

Am I making any sense?

-- 
Best Regards,

mds
mds resource
877.596.8237
-
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 . . .
--


signature.asc
Description: Digital signature

Re: [leaf-devel] New linuxrc mods ready for testing

[Michael D Schleif]

* Charles Steinkuehler <[EMAIL PROTECTED]> [2004:03:13:16:47:02-0600] scribed:


> I propose making log_mnt a new leaf.cfg variable (could also come in via 
> the kernel command line).  Rather than the format you used, however, I 
> would like to use the existing PKGPATH/LEAFCFG format (dev[:filesystem).
> 
> If the log_mnt variable is set, linuxrc would mount the log_mnt device 
> directly to /var/log, and skip making the tmpfs ramdisk.  If log_mnt is 
> unset or null, the current behavior would result.  Does this seem 
> acceptable to everyone?
> 
> Also, any reason (or drawback) to handling /tmp exactly the same way?  I 
> realize /tmp doesn't need to be persistent, but someone might want to be 
> able to mount /tmp on something other than a ramdisk, and I might be 
> able to save some space (or at least not grow /linuxrc much) if I fold 
> togheter the /var/log and /tmp processing.

Need it be hard coded?  Could it be variable-ized, such that I can
specify some arbitrary directory (e.g., /home) during initial
configuration?  That way, other future exceptions are handled in stride.

Notice that I ask this out of ignorance of what is required to
accomplish this ;>

What do you think?

-- 
Best Regards,

mds
mds resource
877.596.8237
-
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 . . .
--


signature.asc
Description: Digital signature

Re: [leaf-devel] LEAF Platform

[Michael D. Schleif]

Also sprach Erich Titl (Tue 22 Jul 02003 at 07:29:23PM +0200):
> Hi everybody
> 
> I am just about to port Bering to a new embedded piece of hardware, except 
> for a few keyboard errors quite successfully. I believe this platform could 
> be very interesting for anyone contemplating a distribution of a 
> standardized HW platform.
> 
> Here is the link.
> 
> http://www.pcengines.ch/wrap.htm

This is interesting.

What are you using for an enclosure?  Perhaps, enclosure specifications
are on the website, but I didn't see them . . .

-- 
Best Regards,

mds
mds resource
877.596.8237
-
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 . . .
--


pgp0.pgp
Description: PGP signature

Re: [leaf-devel] SF.net Tip of the Week

[Michael D. Schleif]

Also sprach Mike Noyes (Tue 04 Mar 02003 at 07:46:00AM -0800):
> On Tue, 2003-02-25 at 07:58, Mike Noyes wrote:
> > This breakdown of the url may make things easier to understand. Please
> > let me know if further explanation is necessary.
> > 
> > Standard prefix:
> > 
> > http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/leaf/
> 
> Everyone,
> K.-P. notified me that Konqueror has a problem with this URL. Please try
> this substitution, and let me know if it works properly. Thanks.
> 
> http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/%2Acheckout%2A/leaf/

Works OK from here . . .

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


pgp0.pgp
Description: PGP signature

Re: [leaf-devel] compact flash ???

[Michael D. Schleif]

Also sprach David Douthitt (Thu 20 Feb 02003 at 04:25:07PM -0600):
> On Wed, 19 Feb 2003 19:25:28 -0600
> "Michael D. Schleif" <[EMAIL PROTECTED]> wrote:
> 
> > Are you booting off of this?  How?  Any special preparation to
> > boot off of USB?
> 
> You could say I am.  It's a three-media startup: install CDROM,
> boot off of that.  Put the floppy configuration disk in the
> floppy drive, and the USB device on the USB chain.
> 
> Then tell the floppy to use the floppy configuration (in reality,
> a shell script sourced off of floppy).  This floppy script then
> runs a script on the USB device which does all of the work.

I want to eliminate both floppy and cdrom.  So, we will need to boot
directly from the flash . . .

-- 
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: SlickEdit Inc. Develop an edge.
The most comprehensive and flexible code editor you can use.
Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
www.slickedit.com/sourceforge

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

Re: [leaf-devel] compact flash ???

[Michael D. Schleif]

Also sprach David Douthitt (Wed 19 Feb 02003 at 05:28:55PM +0100):
> On Wed, 19 Feb 2003 17:11:36 -0600
> "Michael D. Schleif" <[EMAIL PROTECTED]> wrote:
> 
> > [1] Are we limited to IDE?  Does anybody have USB working?
> 
> I've been using USB quite a lot with Knoppix (a CDROM distro); it works
> well.  However, it requires SCSI support.
> 
> > [2] What types of media are actually working well?  Has anybody
> > tried the new XD?
> 
> I use the SanDisk Cruzer with SecureDigital cards.  Works well.


Are you booting off of this?  How?  Any special preparation to boot off
of USB?

-- 
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: SlickEdit Inc. Develop an edge.
The most comprehensive and flexible code editor you can use.
Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
www.slickedit.com/sourceforge

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

[leaf-devel] compact flash ???

[Michael D. Schleif]

Certainly, after all this time some of you have been using this stuff
with LEAF, there must be a HOWTO?

Anyway, I am about to embark down that road and I'm hoping that we can
start a thread to consolidate the DO's and DONT's for using this type of
media with LEAF.

Some of the first questions that come to mind, for which I did not find
answers in the archives:

[1] Are we limited to IDE?  Does anybody have USB working?

[2] What types of media are actually working well?  Has anybody tried
the new XD?

[3] What are the best media readers/adapters?  Are there brands and/or
models to be avoided?

[4] What about this write protect issue?  Is it safe to assume that
_all_ units have this facility?  What is the nomenclature to communicate
this requirement to vendors?

I am sure that I will have more questions.  Perhaps, unless there
already is one that I've overlooked, perhaps, I can write a HOWTO in a
few months . . .

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: SlickEdit Inc. Develop an edge.
The most comprehensive and flexible code editor you can use.
Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial.
www.slickedit.com/sourceforge

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

Re: [leaf-devel] ML volume

[Michael D. Schleif]

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.



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: Light a candle, curse the glare (was: Re: [leaf-devel] ML volume)

[Michael D. Schleif]

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



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

[Michael D. Schleif]

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: [leaf-devel] ML volume

[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] Template system [was Webconfiguration]

[Michael D. Schleif]

Lynn Avants wrote:
> 



> 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

[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

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



-- 

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

[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



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

[Leaf-devel] openssl: flurry of changes ???

[Michael D. Schleif]

Anybody care to shed light on the flurry of changes in openssl since
last week?

First, there was this on July 30:

openssl-0.9.6e

Then, yesterday:

openssl-0.9.6f

Now, today:

openssl-0.9.6g

I'm trying to keep ontop of these, since they impact packages that I
maintain:

net-snmp

openssh

I've gone to , which has become very slow,
ostensibly hit by people like me who remain clueless, since that site
contains nothing that I can find to shed light on how these changes
affect my packages.

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] Redundancy in /var/log files

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



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

[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] CVS structure ???

[Michael D. Schleif]

David Douthitt wrote:

[ snip ]

> My model has been the following:
> 
> archives/
>   .tar.gz
>   .bz2
>   ...
> 
> iproute2/
>   distinfo
>   Makefile
>   patches/
> .diff
> .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}
> 
> /
> ...
> 
> My current lrp "package" setup was to have the following:
> 
> iproute2-/
>   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/.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 structure ???

[Michael D. Schleif]

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] Current CVS Oxygen Tree

[Michael D. Schleif]

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 

[ 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] Perl help

[Michael D. Schleif]

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

[Michael D. Schleif]

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] cvs commit directory structure ???

[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

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

[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

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

[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

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

[Michael D. Schleif]

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] dcd: cleanup issues ???

[Michael D. Schleif]

"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

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

[Michael D. Schleif]

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] CVS structure ??? [LONG]

[Michael D. Schleif]

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=HEAD&content-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.1&content-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

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

[Michael D. Schleif]

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

[Leaf-devel] CVS structure ???

[Michael D. Schleif]

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. 
 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 
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] OpenSSH security

[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

[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

Re: [Leaf-devel] OpenSSH security

[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] Development Annoyances...

[Michael D. Schleif]

David Douthitt wrote:
> 
> There's an annoyance that comes up only in development,
> and I was wondering how others handle it.
> 
> The problem is this: a development cycle (for me, anyway)
> goes like this: boot, fiddle, doesn't work fix,
> reboot, fiddle, fiddle, reboot, fiddle... NOW it works...
> 
> However. NOW the disk image is configured for my
> environment, and needs to be cleaned out.
> 
> The usual way is to go back through ALL configurations,
> reading and using grep, et al.
> 
> Isn't there a better way?
> 
> I was wondering... what if you set up some sort of new
> .cf (for configuration files) or .sane (for sane
> configuration :) file (or whatever it is) that allows you to
> ERASE those files entirely.  This would assume that the
> configuration files are matched by -dist
> files for example...

This is pretty much where Serge Caron came in with `enclosures' . . . at
least, part of his enclosure construct does exactly what you describe .
. .

-- 

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 Inc.
Don't miss the IM event of the season | Special offer for OSDN members! 
JabberConf 2002, Aug. 20-22, Keystone, CO http://www.jabberconf.com/osdn

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

[Leaf-devel] DCD: ipfilter.conf patch

[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

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

[Michael D. Schleif]

Charles Steinkuehler wrote:
> 
> > Although there are already several other ntpclient.lrp's out there, this
> > one is different:
> 
> 
> 
> > 
> >
> > 
> 
> 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:









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

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





-- 

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

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

[Leaf-devel] Access to developer sites ???

[Michael D. Schleif]

As I recall, prior to the recent changes to
, 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] Identifying the top requirements for Embedded Linux systems

[Michael D. Schleif]

Some may find this article interesting:



-- 

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 Do I Troubleshoot Security Problems?

[Michael D. Schleif]

Mike Noyes wrote:
> 
> Subject was: Re: [Leaf-user] martians on internal network ???
> 
> Michael,
> I moved this to the devel list, so we can discuss possible
> additions/modifications to our existing FAQs.
> 
> At 2002-03-09 14:01 -0600, Michael D. Schleif wrote:
> >For me, from my humble experience, when I do not know something, it
> >works best to try to summarize what it is that I know, especially when
> >I am asking for help.
> >
> >Either this is an erroneous process on this list or I did a very poor
> >job of communicating, or both . . .
> 
> >Also, I, for one, learn alot regarding where to go and what to do next
> >by probing List Services (>20!), not the least of which is this one.  I
> >do not and cannot know everything, so I ask questions, starting simple
> >and progressing in complexity as need arises.  Is this a bad process?
> 
> >Perhaps, this is ``old news'' to you; but, not to me -- hence, my
> >question.  Again, I do not find this in the troubleshooting docs, nor
> >did I find such in the archives.  Please, point me to the documentation
> >and I will rtfm . . .
> 
> Did you have a chance to read the new version of the "How Do I Ask For
> Help? FAQ? Is there something you think we should change?
> http://www.mail-archive.com/leaf-devel%40lists.sourceforge.net/msg04608.html

Yes, I read that message and much of that thread.  I still do not see my
issues as setup/configuration related; which appears to be the gist of
this thread.

Regarding additions, I believe it remains to be seen where this issue
goes and how it is resolved -- perhaps, then suggested additions shall
be in order.

> Is there something we could add to "FAQs sec09: Security & Firewall
> Questions Answered" that would have helped you?
> http://sourceforge.net/docman/index.php?group_id=13751

Again, from where I sit, it remains to be seen.

> Is our Web Links section on Security Audits lacking?
> http://leaf-project.org/links.php?op=viewlink&cid=6

This is a new one to me.  I will review it and include it in subsequent
investigations.

Thank you.

-- 

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

[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

[Leaf-devel] DCD & /etc/init.d/netstd_misc ???

[Michael D. Schleif]

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

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

[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 understand

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

[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 

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

[Michael D. Schleif]

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

[Michael D. Schleif]

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

[Michael D. Schleif]

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

[Michael D. Schleif]

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

[Michael D. Schleif]

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

[Michael D. Schleif]

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 a

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

[Michael D. Schleif]

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 file

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

[Michael D. Schleif]

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

[Michael D. Schleif]

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

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

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

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




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

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




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



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.



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

Re: [Leaf-devel] More on dates

[Michael D. Schleif]

David Douthitt wrote:
> 
> On 2/8/02 at 5:23 AM, Mike Noyes <[EMAIL PROTECTED]>
> wrote:
> 
> > At 2002-02-08 00:43 -0600, David Douthitt wrote:
> >
> > >So how important is setting the time/date with date?  Is rdate
> > >(or ntpclient) enough?
> 
> > I think it's important to have the correct date. My ISP
> > NOC wont accept abuse reports without valid time stamps in
> > syslog.
> 
> That doesn't answer my questions
> 
> > I use rdate on my current floppy to set the time on boot.
> > rdate connects a server on my lan, and my server connects
> > to a timeserver on the Internet with xntpd. I use this
> > setup for two reasons. One, I feel it's more secure than
> > having the router/firewall accessing a time server on the
> > Internet. Two, rdate connections are refused by most
> > timeservers on the Internet.
> 
> WIth rdate, I'd say that's the way to go for all the reasons you
> mentioned.  So - can you do without "date -s" ?

Frankly, managing nearly ten leaf/lrp systems, I do not have any problem
with keeping time within one (1) second across all of them, using rdate.

So, no -s is OK with me.

However, since we are limited to shell scripting and my recent work on
leaf has required me to compare dates and times, a working-as-advertised
-d operation would simplify alot for me . . .

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

[Michael D. Schleif]

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

[Michael D. Schleif]

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

[Michael D. Schleif]

Matt Schalit wrote:
> 
> Jack Coates wrote:
> >
> 
> > Hm, so the backup process checks the list files of all other .lrps?
> 
> Yup. That's how it works.  Include everything listed in the .list
> while excluding everything listed in every other .list.  Creative
> things like this keep LEAF interesting.  I'm pretty certain that's
> how it's hobbled together.  You can see the impetus for a new
> packaging system :)

Hence, my interest in filesystem and file location standards  . . .

-- 

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

[Michael D. Schleif]

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

[Michael D. Schleif]

David Douthitt wrote:
> 
> On 2/7/02 at 7:32 PM, Michael D. Schleif <[EMAIL PROTECTED]> wrote:
> 
> > Is there some kind of standard whereby, when building a new LEAF
> > package, we know *where* particular files belong?
> 
> The trouble is, there's no true standard at all.  I administrate 4 or
> 5 varieties of UNIX at work; they have binaries in:
> 
> /bin
> /sbin
> /usr/bin
> /usr/sbin
> /usr/local/bin
> /usr/contrib/bin
> /opt//
> /etc
> 
> ...and they have configurations in:
> 
> /etc//
> /etc/
> /etc/sysconfig/
> /etc/rc.config.d/
>
> Not to belabor the point - but these UNIXes have their kernels in:
> 
> /
> /stand
> /boot
> 
> ...see?

Yes -- been there done that.  However, is that any excuse for us to be
lackluster and careless?!?!

> I try to stick to putting things in /usr, and configs in /etc unless
> there are tons, in which case I put things in /etc//

If we cannot standardize, while dealing with a small, embeddable
platform, what hope is there for the rest of the world?

Of course, as I'm finding with net-snmp, it is not always easy --
possible? -- to put files wheresoever we like ;<

-- 

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] Why are my libraries so large ???

[Michael D. Schleif]

OK, first off, with my recent problems with netsnmpd.lrp, I need to roll
my own ;>

So, off I goto my slink development box and start compiling.

[1] For the life of me, I cannot figure out how the libraries grew 300%
between v4.2.1 and v4.2.3!

This is the current netsnmpd.lrp:

# ls -al `find /usr/lib -type f | grep 'snmp\|ucd'`
-rwxr-xr-x1 root root   293868 Jul 16  2001
/usr/lib/libsnmp-0.4.2.1.so
-rwxr-xr-x1 root root48364 Jul 16  2001
/usr/lib/libucdagent-0.4.2.1.so
-rwxr-xr-x1 root root   286852 Jul 16  2001
/usr/lib/libucdmibs-0.4.2.1.so

This is my current roll-your-own:

# ls -al `find /usr/lib -type f | grep 'snmp\|ucd'`
-rwxr-xr-x   1 root root   804790 Feb  7 22:09
/usr/lib/libsnmp-0.4.2.3.so
-rw-r--r--   1 root root  1082086 Feb  7 22:09
/usr/lib/libsnmp.a
-rwxr-xr-x   1 root root  706 Feb  7 22:09
/usr/lib/libsnmp.la
-rwxr-xr-x   1 root root   180385 Feb  7 22:10
/usr/lib/libucdagent-0.4.2.3.so
-rw-r--r--   1 root root   233854 Feb  7 22:10
/usr/lib/libucdagent.a
-rwxr-xr-x   1 root root  734 Feb  7 22:10
/usr/lib/libucdagent.la
-rwxr-xr-x   1 root root   979796 Feb  7 22:10
/usr/lib/libucdmibs-0.4.2.3.so
-rw-r--r--   1 root root  1593630 Feb  7 22:10
/usr/lib/libucdmibs.a
-rwxr-xr-x   1 root root  727 Feb  7 22:10
/usr/lib/libucdmibs.la

I take it that I need *only* the *.so files; but, even so, look at the
size?  Is there a `strip' for library files?  Of course, I did this:

# ./configure --prefix=/usr --enable-shared

[2] I fiddled with configure, config.h and Makefile; but, I cannot get
snmpd to work with /etc/snmp/snmpd.conf, unless it is a symlink.  So,
I've left it in the default ${prefix}/share/snmp.

[3] net-snmp is really three (3) different pieces:

snmp  -- apps & tools to do everything snmp
snmpd -- facility to accept queries & send traps
snmptrapd -- facility to receive snmp traps

It seems to me that these ought to be kept in separate packages, albeit
dependent on installing the snmpd package.  Although, it is common to
want to remotely manage a firewal/router, I find it doubtful that these
ought to receive/manage incoming traps; nor, may it be too common to
want to query other hosts from the firewall?

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

[Michael D. Schleif]

Is there some kind of standard whereby, when building a new LEAF
package, we know *where* particular files belong?

>From my brief experience, it appears that most LRP packages are built
with non-default file locations.  For example (not to pick on you,
Andrew ;), netsnmpd.lrp puts configuration files under:

/etc/snmp/

whereas the configure defaults are to put everything under:

/usr/local/

If there isn't a standard, there *SHOULD BE* -- no?

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] dachstein CD - backup dest

[Michael D. Schleif]

Charles Steinkuehler wrote:
> 
> > I studied why Charles coded this the way it is and decided that this
> > simple rc script is probably the best way.  Since the current mechanism
> > bases the backup destination on whence the package last came -- this is
> > a good thing -- I don't see an easy fix.  Without some manual
> > configuration, how will the system know -- at startup -- where you
> > prefer to backup packages?
> >
> > Of course, it is possible that the post-startup backup process can test
> > backup destinations for write-ability.  Is this complication really
> > warranted?
> 
> > I wonder what Charles has up his sleeve?
> 
> You pegged why the existing system currently works the way it does.
> 
> The best I've come up with for changing it is a slight modification of your
> recommendation, above.  The initrd script would look at where the package
> was last loaded from (ie the existing default backup path).  If that
> location was *NOT* writable, the package path would be traversed to find the
> first writable location, which would be used as the default backup path.

Since I have already written code to do this for the diskfree routine --
if only I can complete registration to leaf/sourceforge and publish it!
-- I can certainly do this, as well.

Actually, I thought of that; but, stopped short, not knowing where you
thought to go and not daring assume that simple sort -- regardless of
incoming order -- of writeable devices was sufficient . . .

-- 

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] dachstein CD - backup dest

[Michael D. Schleif]

KP Kirchdörfer wrote:
> 
> Am Samstag, 2. Februar 2002 00:52 schrieb Michael D. Schleif:
> > KP Kirchdörfer wrote:
> > > the backup destination of packages points by default to cdrom,
> > > which is write-protected by technology...
> > >
> > > Could this be changed easily to default to /dev/fd0?
> > >
> > > Cosmetic change, I know, for leaf-die-hards, but something new
> > > user might be disattracted.
> >
> > This is what I do:
> >
> > # cat /etc/init.d/backdisk.update
> 
> Thanks Michael,
> but I didn't ask for a workaround, instead it's been a request for
> Dachstein 1.0.3.
> 
> I'm under the impression this has slipped into the release, even it
> makes no sense; but it might also be related to keep scripts between
> cdrom and floppy version in sync, and therefor isn't easy to change.
> 
> Now, if nothing happens, I'll consider to make use of your
> workaround, better than nothing.

I studied why Charles coded this the way it is and decided that this
simple rc script is probably the best way.  Since the current mechanism
bases the backup destination on whence the package last came -- this is
a good thing -- I don't see an easy fix.  Without some manual
configuration, how will the system know -- at startup -- where you
prefer to backup packages?

Of course, it is possible that the post-startup backup process can test
backup destinations for write-ability.  Is this complication really
warranted?

Since my `solution' _fixes_ reasonable startup defaults and does *not*
break anything for floppy-based users, it is a small, reasonable
solution.  Of course, wherever this script is hardcoded for `msdos',
`fd0', &c., these can be made into variables and also part of the lrcfg
configuration schema.

I wonder what Charles has up his sleeve?

Again, I only offered this as a suggestion.  Enjoy it -- or not -- as
you will . . .

-- 

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] dachstein CD - backup dest

[Michael D. Schleif]

KP Kirchdörfer wrote:
> 
> the backup destination of packages points by default to cdrom, which
> is write-protected by technology...
> 
> Could this be changed easily to default to /dev/fd0?
> 
> Cosmetic change, I know, for leaf-die-hards, but something new user
> might be disattracted.

This is what I do:

# cat /etc/init.d/backdisk.update
#! /bin/sh
# /etc/init.d/backdisk.update
# Update /var/lib/lrpkg/backdisk not to backup to cd-rom
#
# $Id: backdisk.update 0.1 2001/12/02 16:30:00 mds Exp $
#

RCDLINKS="1,S99 2,S99 3,S99"

PATH="/sbin:/bin:/usr/sbin:/usr/bin"

FILE=/var/lib/lrpkg/backdisk
TMP=/tmp/backdisk.$$

# Modify FILE
if [ -s $FILE ]
then
sed 's!iso9660!msdos!; s!cdrom\|hda!fd0!' $FILE > $TMP
if [ -s $TMP ]
then
cp $TMP $FILE
fi
rm $TMP
fi

exit 0


-- 

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] DCD, busybox & date -d ???

[Michael D. Schleif]

I have reviewed
; but, I cannot
get date -d to work:

date

date [OPTION]... [+FORMAT] 
Displays the current time in the given FORMAT, or sets the system date.

Options:

-R  Outputs RFC-822 compliant date string
-d STRING   display time described by STRING, not `now'
-s  Sets time described by STRING
-u  Prints or sets Coordinated Universal Time

For example:

# date -d "2002/01/26 22:12:27" +%s
1012104747

This works on my potato; but, *not* under DCD.

Anybody know how to grab dates, say, from /var/state/dhcp/dhcpd.leases
and _compare_ them to some other date, say the current time?

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] [dachstein] lrp.conf/multicron Spacecheck problem

[Michael D. Schleif]

Charles Steinkuehler wrote:
> 
> > > I will at least apply the one line fix in the next release.  For the
> future,
> > > I'd like to see support for a configuration directory.  There would be
> some
> > > default entries, while add-on packages could drop entries into the
> > > "/etc/purge.d" (or whatever) directory, with customizations for any
> large
> > > temporary files the particular package generates.
> >
> > Do you anticipate that the program (e.g., checkfreespace()) must decide
> > on which filesystem purge-able files reside, or do you see this as a
> > manual, pre-configuration issue for the system administrator?
> 
> Hmm...
> 
> I think ideally, checkfreespace would have to determine which filesystem the
> purge-able files reside on.  One of my major goals for a new distribution is
> to gracefully support flexible mount-points.  While the purge-able files may
> not change, and so could be included as part of the package itself, there's
> no way for a package to know ahead of time exactly which file-system the
> files will reside on.

I didn't want to assume; but, that direction makes sense if packages are
to contain purgeable file definitions.

Is it fair to say that *all* applicable filesystems are ramdisks and,
therefore, can be identified according to form: /dev/ramX ?

The tools available are busybox grep and sort, and real sed?

Once I define the requirements, then I can build 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] [dachstein] lrp.conf/multicron Spacecheck problem

[Michael D. Schleif]

KP Kirchdörfer wrote:
> 
> Am Dienstag, 22. Januar 2002 19:21 schrieben Sie:
> > KP Kirchdörfer wrote:
> > > Am Montag, 21. Januar 2002 15:54 schrieb Charles Steinkuehler:
> > > > I will at least apply the one line fix in the next release.
> > > > For
> > >
> > > I've done the "one line" fix, which is indeed a two-line fix in
> > > lrp.conf and multicron.
> >
> > [ snip ]
> >
> > What is the second line?  What do you change in /etc/lrp.conf?  My
> > initial proposal requires only one (1) line modification and only
> > in multicron . . .
> 
> I've added
> lrp_CHK_PART=/
> 
> to lrp.conf and used this variable in multicron, for the reasons I've
> explained in the mail you're referring to.

As you know, this does nothing to address the issues regarding *which*
files to purge.

Besides, Charles was replying to my one-line proposal . . .

What do you make of my most recent proposal that completely resolves
both your mailspacelow() issue, as well as the file purge issues?

-- 

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] [dachstein] lrp.conf/multicron Spacecheck problem

[Michael D. Schleif]

Charles Steinkuehler wrote:
> 
> > For instance, just because your /var/cache maybe full, do you want to
> > arbitrarily purge /var/log files?
> >
> > Not for an instant do I suggest that such complexity is insurmountable;
> > rather, it should be clear that this is far more involved and requires a
> > new paradigm, other than:
> >
> > lrp_SC_DEL_L1="/var/log/*[4-9].gz"
> > lrp_SC_DEL_L2="/var/log/*[1-3].gz"
> > lrp_SC_DEL_L3="/var/log/*.gz"
> > lrp_SC_DEL_L4="/var/log/*.0"
> > lrp_SC_DEL_L5="/var/log/wtmp"
> >
> > Also, do not forget, I do not recommend my solution for its
> > completeness; rather, I recommend it because it more accurately
> > addresses the *default* DCD distribution, can be done by changing one
> > (1) line in the current distribution and does *not* require considerable
> > development and testing time.
> 
> I will at least apply the one line fix in the next release.  For the future,
> I'd like to see support for a configuration directory.  There would be some
> default entries, while add-on packages could drop entries into the
> "/etc/purge.d" (or whatever) directory, with customizations for any large
> temporary files the particular package generates.

Do you anticipate that the program (e.g., checkfreespace()) must decide
on which filesystem purge-able files reside, or do you see this as a
manual, pre-configuration issue for the system administrator?

> Long Term:
> I'd also like to see the configuration directory approach taken to logrotate
> (similar to my RedHat distributions, which already do this), and even inetd
> (switch to xinetd?).  Using files in a configuration directory makes the
> seperation of configuration information into packages much easier, ideally
> avoiding any pre/post package install/remove configuration required (or at
> least limiting it as much as possible).

Yes, this appears reasonable.  I do not know these features of Redhat --
is there anything similar on Debian?

Anyway this goes, as you know from my latest proposal, I have already
done the work to get checkfreespace() to df *all* filesystems.  That was
very simple.

Now, we need to decide on the the management system for purge-able
files.  Once the line is drawn in the sand, I can develop the
infrastructure to make appropriate data available to checkfreespace().

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] [dachstein] lrp.conf/multicron Spacecheck problem

[Michael D. Schleif]

KP Kirchdörfer wrote:
> 
> Am Montag, 21. Januar 2002 15:54 schrieb Charles Steinkuehler:
> 
> > I will at least apply the one line fix in the next release.  For
> 
> I've done the "one line" fix, which is indeed a two-line fix in
> lrp.conf and multicron.

[ snip ]

What is the second line?  What do you change in /etc/lrp.conf?  My
initial proposal requires only one (1) line modification and only in
multicron . . .

-- 

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] [RFC] DCD checkfreespace() vs. multiple filesystems

[Michael D. Schleif]

[RFC] DCD checkfreespace() vs. multiple filesystems

There has been some debate regarding /etc/cron.daily/multicron-d and one
of its functions, checkfreespace(), the default configuration for which
does *not* recognize nor act on multiple filesystems.

What follows is my proposed modification to that one function and a
change in the purge list paradigm for /etc/lrp.conf, which completely
resolves this challenge.

First, currently, /etc/lrp.conf contains this, by default:

lrp_SC_DEL_L1="/var/log/*[4-9].gz"
lrp_SC_DEL_L2="/var/log/*[1-3].gz"
lrp_SC_DEL_L3="/var/log/*.gz"
lrp_SC_DEL_L4="/var/log/*.0"
lrp_SC_DEL_L5="/var/log/wtmp"

I propose *replacing* those with the likes of these:

purge_ram0_L1="/tmp/*"
purge_ram0_L2="/var/cache/*[1-9].gz"
purge_ram0_L3="/var/cache/*.gz"
purge_ram0_L4="/var/cache/*.0"
purge_ram0_L5="/var/cache/*"

purge_ram1_L1="/var/log/*[4-9].gz"
purge_ram1_L2="/var/log/*[1-3].gz"
purge_ram1_L3="/var/log/*.gz"
purge_ram1_L4="/var/log/*.0"
purge_ram1_L5="/var/log/wtmp"

Notice, each ramdisk now *must* be configured separately for the five
(5) purge levels.

The new checkfreespace() automatically checks *ALL* filesystems known to
`df'.  Currently, in DCD, all of these must take the following form:

/dev/ramX

where X is some number from 0 to an unidentified upper limit.  Need we
account for mounted cdrom and floppy?

/etc/cron.daily/multicron-d -- proposed modification to function [Beware
of inadvertent line wrap!]:

checkfreespace () {

ckfree () {
[ $bfree -le ${lrp_SC_MINKB:--1} ] && return 1
[ $pfree -le ${lrp_SC_MINPER:-101} ] && return 1
return 0
}

cleanlevel () {
eval F="\$purge_$@_L$cklevel"
for f in $F
do
[ ! -f "$f" ] && continue   # Bug in expansion?
: > $f
done
}

mailspacelow () {
{
echo
echo "date: $(date)"
echo "src : $HOSTNAME"
echo "filesystem: /dev/$@"
echo "level: $cklevel   freeKB: $bfree   free%: $pfree"
echo
} | mailadmin "Freespace Low!"
}

updatefree () {
IFS="$SP$TAB%"
set -- $(df /dev/$@ | sed -n 2p)
IFS=$OIFS

bfree=$4
pfree=$((100 - $5))
}

[ "$lrp_SPACECHECK" != "YES" ] && return 0

# NOTE: *BOTH* character classes contain *both* space and tab !?!?
fslist=`df | sed '1d;s!^/dev/\([^   ]*\)[   ]*.*$!\1!'`
for fs in $fslist
do
cklevel=0
while [ $cklevel -lt 5 ]
do
updatefree $fs
ckfree && break
cklevel=$(($cklevel + 1))
cleanlevel $fs
done
[ $cklevel -ge ${lrp_SC_MAIL_LEVEL:-1} ] && mailspacelow $fs
done

log checkfreespace
}


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] [dachstein] lrp.conf/multicron Spacecheck problem

[Michael D. Schleif]

KP Kirchdörfer wrote:
> 
> Am Sonntag, 20. Januar 2002 03:18 schrieb Michael D. Schleif:
> > KP Kirchdörfer wrote:
> > > Am Donnerstag, 17. Januar 2002 04:15 schrieb Michael D. Schleif:
> > > > >
> > > > > I'll probably try to get the script to check *ALL* currently
> > > > > mounted, writable file-systems...maybe with an exclude
> > > > > variable in lrp.conf.  If this doesn't work, I can fallback
> > > > > to the Enhanced solution, above.
> > > >
> > > > /etc/lrp.conf has a variable: lrp_SPACECHECK=YES/NO -- if YES,
> > > > then -- and, only then -- /etc/cron.daily/multicron-d and its
> > > > links can run checkfreespace(), which calls updatefree(), &c.
> > >
> > > There is also mailadmin(), so if /var/something is on the list
> > > and checked, it will send a mail to mailadmin.
> > >
> > > > Suppose, updatefree() returns a value for which ckfree()
> > > > returns 0, then -- and, only then -- cleanlevel() runs and
> > > > prunes applicable files that match the filter:
> > > > $lrp_SC_DEL_L$cklevel
> > > >
> > > > But, *what* files can these be?  In /etc/lrp.conf -- by default
> > > > -- we see exclusively this:
> > > >
> > > >   lrp_SC_DEL_L1="/var/log/*[4-9].gz"
> > > >   lrp_SC_DEL_L2="/var/log/*[1-3].gz"
> > > >   lrp_SC_DEL_L3="/var/log/*.gz"
> > > >   lrp_SC_DEL_L4="/var/log/*.0"
> > > >   lrp_SC_DEL_L5="/var/log/wtmp"
> > > >
> > > > Notice, *ALL* of these files -- by default -- reside in
> > > > /var/log !!!
> > > >
> > > > Since *only* files under /var/log can be pruned -- by default
> > > > -- then, why not modify updatefree() to say this:
> > > >
> > > >   set -- $(df /var/log | sed -n 2p)
> > >
> > > lrp_SC_DEL_Lx could be enhanced to delete other /var/* as well.
> > >
> > > updatefree() isn't the place to determine the dir's, that's what
> > > I think.
> >
> > Agreed, this is not the ultimate solution.  However, it does
> > completely address DCD defaults!
> >
> > Nevertheless, `df /path/to/dir' *always* returns _only_ that
> > information particular to that filesystem on which /path/to/dir
> > resides; therefore, it would be a simple matter to test any variety
> > of applicable dir/filesystem combinations.
> >
> > The truly hard part is, what to do with the information returned?
> > Email somebody is straightforward; but, the complexities in
> > deciding which files to purge becomes exceedingly complex !?!?
> >
> > Besides logfiles, what else on DCD can grow out-of-hand?
> 
> On a common DCD I don't know. On my own /var/logs and /var/cache for
> squid.
> It's easy to decide that a cache can be flushed.

Yes, of course, in and of itself, it is easy to decide whether or not to
purge files in /var/cache.

It is also easy enough to put several df's in a loop in order to analyze
several filesystems.

However, it is not as easy, once a filesystem is found that requires
purging, for the dumb shell script to decide *which* files to purge ;<

For instance, just because your /var/cache maybe full, do you want to
arbitrarily purge /var/log files?

Not for an instant do I suggest that such complexity is insurmountable;
rather, it should be clear that this is far more involved and requires a
new paradigm, other than:

lrp_SC_DEL_L1="/var/log/*[4-9].gz"
lrp_SC_DEL_L2="/var/log/*[1-3].gz"
lrp_SC_DEL_L3="/var/log/*.gz"
lrp_SC_DEL_L4="/var/log/*.0"
lrp_SC_DEL_L5="/var/log/wtmp"

Also, do not forget, I do not recommend my solution for its
completeness; rather, I recommend it because it more accurately
addresses the *default* DCD distribution, can be done by changing one
(1) line in the current distribution and does *not* require considerable
development and testing time.

Enough said . . .

-- 

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] [dachstein] lrp.conf/multicron Spacecheck problem

[Michael D. Schleif]

KP Kirchdörfer wrote:
> 
> Am Donnerstag, 17. Januar 2002 04:15 schrieb Michael D. Schleif:
> > Charles Steinkuehler wrote:
> > > > Following problem:
> > > > Using Dachstein and creating a separate ramdisk /dev/ram1 for
> > > > /var/log malfunctions lrp.conf spacecheck.
> > > > I think the spacecheck intention is to monitor /var/log, cause
> > > > there are the most changes in file size during the routers
> > > > lifetime and running out of space in /var/log causes several
> > > > errors - sshd won't start, pppoe connections won't be
> > > > established after disconnection etc. - all leading to router
> > > > which can't be controlled remotely.
> > > >
> > > > Further investigation showed that multicron-p only looks for /
> > > > when checking free space - which is useless, once you have a
> > > > separate ramdisk for /var/log.
> > > >
> > > > Dummy solution, and this is what I did:
> > > > add a parameter lrp_CHK_PART to lrp.conf and change multicron-p
> > > > to use $lrp_CHK_PART in lrp.conf updatefree()
> > > >
> > > > Enhanced solution:
> > > > lrp_CHK_PART should allow several partitions which will be
> > > > checked and free'ed or at least a sending a mail with
> > > > mailadmin().
> > >
> > > Added to the list of things to fix for Dachstein 1.0.3
> > >
> > > I'll probably try to get the script to check *ALL* currently
> > > mounted, writable file-systems...maybe with an exclude variable
> > > in lrp.conf.  If this doesn't work, I can fallback to the
> > > Enhanced solution, above.
> >
> > Correct me, if I'm wrong -- it won't be the first time today ;>
> >
> > /etc/lrp.conf has a variable: lrp_SPACECHECK=YES/NO -- if YES, then
> > -- and, only then -- /etc/cron.daily/multicron-d and its links can
> > run checkfreespace(), which calls updatefree(), &c.
> 
> There is also mailadmin(), so if /var/something is on the list and
> checked, it will send a mail to mailadmin.
> 
> >
> > Suppose, updatefree() returns a value for which ckfree() returns 0,
> > then -- and, only then -- cleanlevel() runs and prunes applicable
> > files that match the filter:  $lrp_SC_DEL_L$cklevel
> >
> > But, *what* files can these be?  In /etc/lrp.conf -- by default --
> > we see exclusively this:
> >
> >   lrp_SC_DEL_L1="/var/log/*[4-9].gz"
> >   lrp_SC_DEL_L2="/var/log/*[1-3].gz"
> >   lrp_SC_DEL_L3="/var/log/*.gz"
> >   lrp_SC_DEL_L4="/var/log/*.0"
> >   lrp_SC_DEL_L5="/var/log/wtmp"
> >
> > Notice, *ALL* of these files -- by default -- reside in /var/log
> > !!!
> >
> > Since *only* files under /var/log can be pruned -- by default --
> > then, why not modify updatefree() to say this:
> >
> >   set -- $(df /var/log | sed -n 2p)
> >
> > What do you think?
> 
> lrp_SC_DEL_Lx could be enhanced to delete other /var/* as well.
> 
> updatefree() isn't the place to determine the dir's, that's what I
> think.
> 
> sorry kp

Agreed, this is not the ultimate solution.  However, it does completely
address DCD defaults!

Nevertheless, `df /path/to/dir' *always* returns _only_ that information
particular to that filesystem on which /path/to/dir resides; therefore,
it would be a simple matter to test any variety of applicable
dir/filesystem combinations.

The truly hard part is, what to do with the information returned?  Email
somebody is straightforward; but, the complexities in deciding which
files to purge becomes exceedingly complex !?!?

Besides logfiles, what else on DCD can grow out-of-hand?

-- 

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] [dachstein] lrp.conf/multicron Spacecheck problem

[Michael D. Schleif]

Charles Steinkuehler wrote:
> 
> > Following problem:
> > Using Dachstein and creating a separate ramdisk /dev/ram1 for
> > /var/log malfunctions lrp.conf spacecheck.
> > I think the spacecheck intention is to monitor /var/log, cause there
> > are the most changes in file size during the routers lifetime and
> > running out of space in /var/log causes several errors - sshd won't
> > start, pppoe connections won't be established after disconnection
> > etc. - all leading to router which can't be controlled remotely.
> >
> > Further investigation showed that multicron-p only looks for / when
> > checking free space - which is useless, once you have a separate
> > ramdisk for /var/log.
> >
> > Dummy solution, and this is what I did:
> > add a parameter lrp_CHK_PART to lrp.conf and change multicron-p to
> > use $lrp_CHK_PART in lrp.conf updatefree()
> >
> > Enhanced solution:
> > lrp_CHK_PART should allow several partitions which will be checked
> > and free'ed or at least a sending a mail with mailadmin().
> 
> Added to the list of things to fix for Dachstein 1.0.3
> 
> I'll probably try to get the script to check *ALL* currently mounted,
> writable file-systems...maybe with an exclude variable in lrp.conf.  If this
> doesn't work, I can fallback to the Enhanced solution, above.

Correct me, if I'm wrong -- it won't be the first time today ;>

/etc/lrp.conf has a variable: lrp_SPACECHECK=YES/NO -- if YES, then --
and, only then -- /etc/cron.daily/multicron-d and its links can run
checkfreespace(), which calls updatefree(), &c.

Suppose, updatefree() returns a value for which ckfree() returns 0, then
-- and, only then -- cleanlevel() runs and prunes applicable files that
match the filter:   $lrp_SC_DEL_L$cklevel

But, *what* files can these be?  In /etc/lrp.conf -- by default -- we
see exclusively this:

lrp_SC_DEL_L1="/var/log/*[4-9].gz"
lrp_SC_DEL_L2="/var/log/*[1-3].gz"
lrp_SC_DEL_L3="/var/log/*.gz"
lrp_SC_DEL_L4="/var/log/*.0"
lrp_SC_DEL_L5="/var/log/wtmp"

Notice, *ALL* of these files -- by default -- reside in /var/log !!!

Since *only* files under /var/log can be pruned -- by default -- then,
why not modify updatefree() to say this:

set -- $(df /var/log | sed -n 2p)

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] iptraf v2.5 compile problem ???

[Michael D. Schleif]

David Douthitt wrote:
> 
> On 12/16/01 at 7:35 PM, Michael D. Schleif <[EMAIL PROTECTED]> wrote:
> 
> > Nevertheless, I am getting this output:
> >
> > Loki:/home/mds/iptraf-2.5.0/src# make
> > gcc -Wall -O2  -DWORKDIR=\"/var/local/iptraf\"
> > -DLOGDIR=\"/var/log/iptraf\" -DEXECDIR=\"/usr/local/bin\"
> > -I/usr/include/ncurses -DVERSION=\"2.5.0\" -DPLATFORM=\"Linux/i386\"
> > -g-c -o iptraf.o iptraf.c
> > gcc -Wall -O2  -DWORKDIR=\"/var/local/iptraf\"
> > -DLOGDIR=\"/var/log/iptraf\" -DEXECDIR=\"/usr/local/bin\"
> > -I/usr/include/ncurses -DVERSION=\"2.5.0\" -DPLATFORM=\"Linux/i386\"
> > -g-c -o itrafmon.o itrafmon.c
> > In file included from itrafmon.c:27:
> > packet.h:27: warning: `struct sockaddr_ll' declared inside parameter
> > list
> > packet.h:27: warning: its scope is only this definition or
> declaration,
> > packet.h:27: warning: which is probably not what you want.
> > itrafmon.c: In function `ipmon':
> > itrafmon.c:538: storage size of `fromaddr' isn't known
> > itrafmon.c:538: warning: unused variable `fromaddr'
> > make: *** [itrafmon.o] Error 1
> >
> >
> > What do you think?
> 
> Try compiling with glibc 2.1.3 - I would suspect your problems would
> go away :)
> 
> Networking programs have more than the common number of problems when
> compiling with glibc 2.0 - and now both Dachstein and Oxygen are
> moving strongly towards 2.1.3 (seems to me anyway).

How does this help with Dachstein-CD, or other mainstream LEAF/LRP
distributions?  Will packages compiled under glibc 2.1.3 run under these
distributions?

I finally broke down, last week, and built a slink-based development box
;>  I really need to compile some things to run under Dachstein-CD; but,
once I built the system and upgraded the kernel to 2.2.19-3, I find that
I'm still un-able to compile as I need to ;<

I do not claim to be expert in this area; but, I've read the compile
documentation on sourceforge, including yours, and this development box
appears to meet your criteria.  Nevertheless, Andrew Hoying released
iptraf.lrp (v2.40) -- yet, when I try to compile iptraf v2.40, I still
get that `struct sockaddr_ll' warning and it does *NOT* compile!

So, apparently, my development system is lacking something.  Yes,
CONFIG_PACKET=y in my kernel -- and, I'm still having problems with
packet.h !

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] iptraf v2.5 compile problem ???

[Michael D. Schleif]

Current lrp instances of iptraf cannot see anything, except ethernet
devices.

Since I've been working with wanpipe, I've a requirement to debug tcp
issues and want to use iptraf.

iptraf v2.5 documentations states:

``IPTraf 2 requires Linux 2.2.  It now uses the new PF_PACKET socket
family as its capture mechanism.''

``Use of the latest glibc 2.x is also recommended.  But libc5 works
fine.''

So, ostensibly, it can be compiled for current leaf/lrp distributions ;>

Nevertheless, I am getting this output:

Loki:/home/mds/iptraf-2.5.0/src# make
gcc -Wall -O2  -DWORKDIR=\"/var/local/iptraf\"
-DLOGDIR=\"/var/log/iptraf\" -DEXECDIR=\"/usr/local/bin\"
-I/usr/include/ncurses -DVERSION=\"2.5.0\" -DPLATFORM=\"Linux/i386\" 
-g-c -o iptraf.o iptraf.c
gcc -Wall -O2  -DWORKDIR=\"/var/local/iptraf\"
-DLOGDIR=\"/var/log/iptraf\" -DEXECDIR=\"/usr/local/bin\"
-I/usr/include/ncurses -DVERSION=\"2.5.0\" -DPLATFORM=\"Linux/i386\" 
-g-c -o itrafmon.o itrafmon.c
In file included from itrafmon.c:27:
packet.h:27: warning: `struct sockaddr_ll' declared inside parameter
list
packet.h:27: warning: its scope is only this definition or declaration,
packet.h:27: warning: which is probably not what you want.
itrafmon.c: In function `ipmon':
itrafmon.c:538: storage size of `fromaddr' isn't known
itrafmon.c:538: warning: unused variable `fromaddr'
make: *** [itrafmon.o] Error 1


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] Re: [Leaf-user] Re:

[Michael D. Schleif]

Am I the doofus or what?

My only excuse is, when my lrpkg.cfg looks like this, it is easy to miss
one:

etc,local,bash,bwidth22,daemontl,djbutils,dhclient,dhcpd,dnscache,ifconfig,libdb,libm,libpcap,libz,lncurses,lrdline2,mawk,modules,netsnmpd,netsnmpu,ramlog,rsync,sftp,ssh,sshd,tcpdump,tinydns,vim,weblet

Thank you . . .

Charles Steinkuehler wrote:
> 
> > > > Did you see my post about net-snmp? This package requires libdb.so.2
> which
> > > > is not part of the libraries on the Dachstein CD. I found the file on
> the
> > > > Debian web site in the libdb++ package. Did you include it in either
> of
> > > > your net-snmp packages? If not, what do you think about making libdb++
> an
> > > > LRP package?
> > >
> > > I just grabbed David's libdb package and added it to the CD.
> >
> > We're still getting this:
> >
> > ``Starting snmpd: /usr/sbin/snmpd: error in loading shared libraries
> > libm.so.6: cannot open shared object file: No such file or directory''
> >
> > We have loaded libdb.lrp; yet, this:
> >
> > root@trout:/root
> > # ls -al `find / | grep libm`
> > -rw-r--r--1 root root   104192 Feb 20  1999
> > /usr/local/lib/libm-2.0.7.so
> > lrwxrwxrwx1 root root   13 Dec  5 06:59
> > /usr/local/lib/libm.so.6 -> libm-2.0.7.so
> >
> > What to do?
> 
> How about loading libm.lrp?  It's on the CD...

-- 

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: [Leaf-user] Re:

[Michael D. Schleif]

"Michael D. Schleif" wrote:
> 
> Charles Steinkuehler wrote:
> >
> > > Did you see my post about net-snmp? This package requires libdb.so.2 which
> > > is not part of the libraries on the Dachstein CD. I found the file on the
> > > Debian web site in the libdb++ package. Did you include it in either of
> > > your net-snmp packages? If not, what do you think about making libdb++ an
> > > LRP package?
> >
> > I just grabbed David's libdb package and added it to the CD.
> 
> We're still getting this:
> 
> ``Starting snmpd: /usr/sbin/snmpd: error in loading shared libraries
> libm.so.6: cannot open shared object file: No such file or directory''
> 
> We have loaded libdb.lrp; yet, this:
> 
> root@trout:/root
> # ls -al `find / | grep libm`
> -rw-r--r--1 root root   104192 Feb 20  1999
> /usr/local/lib/libm-2.0.7.so
> lrwxrwxrwx1 root root   13 Dec  5 06:59
> /usr/local/lib/libm.so.6 -> libm-2.0.7.so
> 
> What to do?


I should, probably, also listed this:

root@trout:/root
# ls -al `find / | grep libd`
-rw-r--r--1 root root 6492 Dec  5 09:27
/lib/libdl-2.0.7.so
lrwxrwxrwx1 root root   14 Dec  5 06:59 /lib/libdl.so.2
-> libdl-2.0.7.so
-rw-r--r--1 root root55588 May 18  2000
/usr/lib/libdb-2.0.7.so
lrwxrwxrwx1 root root   14 Dec  5 07:00
/usr/lib/libdb.so.2 -> libdb-2.0.7.so
-rw-r--r--1 root root   64 Sep 27  2000
/var/lib/lrpkg/libdb.list

-- 

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: [Leaf-user] Re:

[Michael D. Schleif]

Charles Steinkuehler wrote:
> 
> > Did you see my post about net-snmp? This package requires libdb.so.2 which
> > is not part of the libraries on the Dachstein CD. I found the file on the
> > Debian web site in the libdb++ package. Did you include it in either of
> > your net-snmp packages? If not, what do you think about making libdb++ an
> > LRP package?
> 
> I just grabbed David's libdb package and added it to the CD.

We're still getting this:

``Starting snmpd: /usr/sbin/snmpd: error in loading shared libraries
libm.so.6: cannot open shared object file: No such file or directory''

We have loaded libdb.lrp; yet, this:

root@trout:/root
# ls -al `find / | grep libm`
-rw-r--r--1 root root   104192 Feb 20  1999
/usr/local/lib/libm-2.0.7.so
lrwxrwxrwx1 root root   13 Dec  5 06:59
/usr/local/lib/libm.so.6 -> libm-2.0.7.so


What to do?

-- 

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: [Leaf-user] Testing help needed

[Michael D. Schleif]

Charles Steinkuehler wrote:
> 
> As part of getting a final floppy version released, I have created (yet
> another) new kernel tree .
> 
> http://lrp.steinkuehler.net/files/kernels/2.2.20-1-small/
> http://lrp1.steinkuehler.net/files/kernels/2.2.20-1-small/
> http://lrp2.steinkuehler.net/files/kernels/2.2.20-1-small/
> 
> The existing kernels have problems with reiserfs, which combined with the
> openwall patches seems to cause most loadable filesystem modules to fail
> with unresolved module dependencies.  Since I have to re-compile all the
> kernels anyway, I'm making the jump to 2.2.20 at the same time.

[ snip ]

We are un-clear as to your plans for 2.2.x kernels ;>

Since we have just overcome 2.2.19 issues with Sangoma wanpipe, which
are all kernel version/re-compile related, we want to release the new
wanpipe.lrp for state-of-the-state Dachstein-CD.

Please, share your thoughts and plans . . .

-- 

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: [Leaf-user] Announcing Dachstein CD RC5

[Michael D. Schleif]

Charles Steinkuehler wrote:
> 
[ snip ]
> 
> Rebuilt log.tgz (part of ramlog.lrp) using busybox tar in hopes of
>   eliminating "broken pipe" messages appering on some systems.

Did I tell you that that fixes the problem?

Of course, in my modified instance, it took me quite sometime to figure
out how to un-archive, modify and re-archive in the same manner.

Thank you . . .

-- 

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: [Leaf-user] Announcing official release of Dachstein-CD

[Michael D. Schleif]

Charles Steinkuehler wrote:
> 
> > As always, this is truly superb stuff!  Bravo, Charles !!!
> >
> > Couple questions, even though these items appeared in RC5:
> >
> > [1] What is the purpose of the ``leaf'' user?
> 
> It was in Jacques' example passwd file...I added it mainly as a 'stub' entry
> for pointing to if someone wanted to add/create a new user account.  It
> should not be used in most instances (having actual user accounts on your
> firewall isn't necessarily all that useful or prudent), so I changed the
> /etc/shadow entry for this user to dis-allow logins by default.
> 
> > [2] Should /home/leaf exist -- provided that we agree that such an user
> > ought to exist?
> 
> Probably, but let's see if I can rationalize my way out of an
> oversight...Hmm...making a directory isn't that hard, and other than a
> .profile entry, which isn't really necessary, it's just a place-holder
> taking up space in /root...if we add a .profile entry, it takes up even more
> space...but perhaps the best excuse..er reason it's not there, is you
> shouldn't really create user accounts in the first place, and I did really
> intend the leaf user to be either a stub entry you'd modify, or or a default
> entry for any non-root owned files you might want to put in a package (so
> they don't come up as user 100 on ls -l listings).

As I studied these /etc/passwd inclusions, trying to decide their
ultimate fate, it occured to me that if I made root unable to login and
put leaf into a high numbered GID, subscribed to nothing, and an
isolated home directory, then the only way to gain login access would be
through this account and then su to root . . .

Obviously, I, too, am not persuaded -- what are the merits and dangers
of such logic?

Perhaps, as you say, this is only an example to be followed by those
adventurous enough to really want user accounts -- ought this passwd
entry rather be:

# leaf:x:100:1000:Default User:/home/leaf:/bin/sh

-- 

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: [Leaf-user] Announcing official release of Dachstein-CD

[Michael D. Schleif]

Charles Steinkuehler wrote:
> 
> > Interestingly enough, logged in as leaf, I *cannot* su - root
> > su: Incorrect password
> >
> > What gives?  Trust me, I know the root password ;>  But, I cannot
> > eliminate root login if I cannot su to root . . .
> 
> Hmm...does su have the setuid bit set?  It has to inherit root privliges to
> be able to change your UID to root...

Aha!  Good catch ;>

-- 

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: [Leaf-user] Announcing official release of Dachstein-CD

[Michael D. Schleif]

"Michael D. Schleif" wrote:
> 
> Charles Steinkuehler wrote:
> >
> > The official release (v1.0.1) of Dachstein-CD is now available for download
> > from the usual places:
> > slow:
> > http://lrp.steinkuehler.net/files/diskimages/dachstein-CD/
> > fast:
> > http://lrp1.steinkuehler.net/files/diskimages/dachstein-CD/
> > http://lrp2.steinkuehler.net/files/diskimages/dachstein-CD/
> >
> > There was a 'silent' release of v1.0.0 for internal use yesterday.  Changes
> > from the last release candidate include configuration tweaks (dnscache and
> > ipsec), the inclusion of the ipsec binaries patched for x.509 certificate
> > support, and fixes to a couple minor bugs (a problem with the POSIXness cut
> > command, and setting custom backup destinations didn't work properly).
> 
> As always, this is truly superb stuff!  Bravo, Charles !!!
> 
> Couple questions, even though these items appeared in RC5:
> 
> [1] What is the purpose of the ``leaf'' user?
> 
> [2] Should /home/leaf exist -- provided that we agree that such an user
> ought to exist?

Interestingly enough, logged in as leaf, I *cannot* su - root
su: Incorrect password

What gives?  Trust me, I know the root password ;>  But, I cannot
eliminate root login if I cannot su to root . . .

-- 

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: [Leaf-user] Announcing official release of Dachstein-CD

[Michael D. Schleif]

Charles Steinkuehler wrote:
> 
> The official release (v1.0.1) of Dachstein-CD is now available for download
> from the usual places:
> slow:
> http://lrp.steinkuehler.net/files/diskimages/dachstein-CD/
> fast:
> http://lrp1.steinkuehler.net/files/diskimages/dachstein-CD/
> http://lrp2.steinkuehler.net/files/diskimages/dachstein-CD/
> 
> There was a 'silent' release of v1.0.0 for internal use yesterday.  Changes
> from the last release candidate include configuration tweaks (dnscache and
> ipsec), the inclusion of the ipsec binaries patched for x.509 certificate
> support, and fixes to a couple minor bugs (a problem with the POSIXness cut
> command, and setting custom backup destinations didn't work properly).

As always, this is truly superb stuff!  Bravo, Charles !!!

Couple questions, even though these items appeared in RC5:

[1] What is the purpose of the ``leaf'' user?

[2] Should /home/leaf exist -- provided that we agree that such an user
ought to exist?

-- 

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: [Leaf-user] Dachstein

[Michael D. Schleif]

Hilton Travis wrote:
> 
> Rocks.  I just changed from Tel$tra cable to Optus@home cable, downloaded
> Dachstein RC2, and installed it fine.  works a treat.
> 
> I'll be making images for Tel$tra BigPond and Optus users, and replacing my
> earlier images on http://quarkau.cjb.net when I get back from camping next
> week.

Please, consider a post-RC release . . .

-- 

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: [Leaf-user] Dachstein-CD-rc3 available: bash.lrp error

[Michael D. Schleif]

Charles Steinkuehler wrote:
> 
> > > > > I haven't tried bash.lrp since pre-release.  There used to be two
> (2)
> > > > > bash-related problems; now, I find one (1):
> > > > >
> > > > > Mounting local filesystems...
> > > > > ramdisk.pkg: Uncompressing archives -
> log.tgz/etc/rcS.d/S36ramdisk.pkg:
> > > > > line 33:
> > > > > 1001 Broken pipegunzip -c "$pkgdir/$pkg"
> > > > > 1002 Done   | qt tar -x
> > > > > -Finished.
> > > > >
> > > > > I'm not sure what is wrong here -- I do not see wrong with the
> scripts.
> > > > > log.tgz *does* get un-archived and bash is working.
> > > > >
> > > > > Nevertheless, this is some kind of error -- hopefully *not* to
> manifest
> > > > > itself elsewhere . . .
> > > >
> > > > P.S.  I am using ramlog.lrp -- *not* ramdisk.lrp . . .
> 
> I still don't know why this is happening...what happens if you run the
> script manually?  (ie "svi ramdisk.pkg start").  There *was* a problem like
> this early on, reflecting differences between different busybox versions of
> gzip, if memory serves, but I haven't seen a problem like that for a
> while...

I thought that I found the cause to this problem; but ...

I have narrowed this down to a busybox issue.  After complete boot, I
scp log.tgz to /tmp, then:

root@trout:/tmp
# gunzip -c /tmp/log.tgz | tar -x
Broken pipe

Of course, in /etc/init.d/ramdisk.pkg, you wrap the tar -x in qt(),
which effectively erases *all* output from that command -- so, that
error must be coming from gunzip, which is linked to busybox.

Perhaps, it is my particular log.tgz ???  It is not exactly yours.  I
won't attach it here; but, if you're willing to test it, request it and
it's yours . . .

-- 

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: [Leaf-user] Openssh 2.9.9p2 available -- Dachstein-CD ???

[Michael D. Schleif]

Jacques Nilo wrote:
> 
> I have updated openssh packages to their latest 2.9.9p2 version.
> They are compiled statically against openssl-0.9.6b and dynamically
> against zlib-1.1.3
> See:
> http://leaf.sourceforge.net/devel/jnilo

Excellent!

Charles, is this that version that you are adding to Dachstein-CD ???

-- 

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