On Jun 22, 2006, at 3:10 PM, Wes Hardaker wrote:
>>>>>> On Wed, 21 Jun 2006 14:51:55 -0400, Jeff Johnson
>>>>>> <[EMAIL PROTECTED]> said:
>
> Jeff> So I'd like to uncouple net-snmp from rpmlib by invoking
> Jeff> /bin/rpm -qa --queryformat '%{name} %{version} %{release} %
> Jeff> {installtime' when needed (mtime on /var/lib/rpm/Packages
> Jeff> changes) instead of the existing quite deadly embrace. The
> Jeff> 4-tuple is all that the Host Resources MIB has ever needed.
>
> Ugh.
>
> Jeff> Is this the right list to send the patch?
>
> Well, this is the right place to discuss it. The best place to submit
> it is our patches DB where we can't lose it (http://www.net-
> snmp.org/patches).
>
> Jeff> Should I add a 3rd way for net-snmp to extract information
> from a
> Jeff> rpmdb using /bin/rpm, or just rip out the existing and replace
> Jeff> with a rpm-legacy-free helper invocation?
>
> ugh.
>
> Did I say that yet?
>
> Ugh.
>
Hehe, I hear you.
FWIW, I think there's a way for rpm to maintain a directory with a
bunch of 0 length
files containing all the information that the HR MIB needs so that
rpm appears to be just
like any other installer from a net-snmp POV. News at 11 ...
That way you don't have to do anything at all different (than you are
doing for other vendors) for rpmdb.
The trick will be getting linux vendor acceptance, I have my nipple
clamps ready, and if net-snmp (or you) apply
the ball crushers, I suspect we can achieve a looser and more
maintainable coupling to support the HR MIB. ;-)
> You're right that the binding is somewhat painful, but at the same
> time it seems architecturally the right thing to do as well. Invoking
> a command to spit out text which is then parsed by the demon leads to
> an entirely different set of pain. I think it's likely similar to
> breaking a leg to use the bones to splint an arm. Now, as to which
> I'd rather have broken, that's where the "ugh" comes from.
>
Avoiding the exec of the helper is what is architecturally desirable,
yes.
The opendir(3) API is certainly an easier coupling than Berkeley DB
(with NPTL locks) under the hood.
> In all honestly, the binding has worked fairly well up until the point
> that you actually want to apply a non-liberal selinux (or any trusted
> OS) policy to the snmp demon. The SNMP demon, sadly, needs many more
> privileges than you'd like a network daemon to have. But that's
> mostly due to the fact that it needs to access and report on so many
> system pieces.
>
FYI: there's no known issue (yet) with SELinux, I used as an example
only to illustrate
the rather surprising linkage induced by -lrpmlib within net-snmp.
> I don't think ripping the code out is architecturally right. Using
> the APIs, to me, seems like the *right* architecture not the wrong
> one. Exec()ing a program to interpret the output seems like a
> last-resort hack (I've implemented many such last-resort hacks, by the
> way).
>
I suspect we agree that exec needs to be avoided. That was the
original motivation
for ripping out the popen(3) call way back when and doing -lrpmlib.
Meanwhile a opendir(3) should suffice, and the same 0 length name-
version-release.arch with mtime == installtime
can be done outside of both rpmlib and net-snmp for those systems
that truly want/need to use the HR MIB on rpm managed
systems with a different HR MIB implementation.
> In the end, we'd be implementing a different hack to actually hack
> *around* security policies.
Let me generate a patch this week (or weekend, my only hacking time
these days) and see what you
think about using only opendir(3).
Its not like I'm gonna change the rpmdb API or ABI in rpmlib anytime
soon. However, I just got bit by the soname
change in net-snmp between 5.1.3 and 5.3, and had to retrofit
compatibility libbraries into a package to
keep a Big Bucks Binary Only application happy. This is kinda silly
imho ...
The other reason for removing -lrpmlib is that vendors are wary of
updating net-snmp and rpmlib. The
last remaining usage of -lrpmlib is in effect preventing me from ever
changing rpm, even for crucially important
problems.
BTW, I'd drop the rpm-3.x.y API in net-snmp if I were you, its way
past time for certain vendors (IBM, Sun, HP, ...) to update
their rpm software. rpm-3.0.x went end-of-life years ago. Blame me if
you don't want to take the heat ;-)
But that's just noise. Let me send you a patch, see what you think.
73 de Jeff
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Net-snmp-coders mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
