On Jun 17, 2011, at 10:57 AM, Wes Hardaker wrote: >>>>>> On Fri, 17 Jun 2011 10:12:50 -0400, Jeff Johnson <[email protected]> said: > > ... > JJ> You run the script under cron. >
Caveat: I am _NOT_ saying that you want to do this with cron. I am
saying patch rpm instead. The number of systems that MUSTHAVE a net-snmp
upgrade without an rpm upgrade is a vanishingly small corner case.
But here are the specific answers on typical linux distros that I've used.
> How do you (safely) install a cron script on every platform that has rpm
> installed? How do you select the period at which rpm itself should be
> run?
>
On @redhat flavored linux systems you add a file to the net-snmp
package that drops a script into /etc/cron.d (or does whatever
is needed in a %post). See smolt/systat packaging for whatever
passes for acceptable practice these days (this is serpents a RHEL6 clone)
$ ls /etc/cron.d
0hourly smolt sysstat
And you choose a time as appropriate. On most "enterprise" platforms
upgrades (which changes what HR-MIB would report) happen less often
than daily. And there's no reason that the script cannot be run
at the end of whatever process is in place to do software upgrades,
the cron script is just to pick up odd balls.
This is no different that any other non-rpm system which relies
on de facto info from files regarding the installed software base
needed to populate the HR-MIB.
This includes Debian, and Solaris, and HP-UX and more. Muck with
the files and the HR-MIB WILL lie to you.
> The non-cron way would be to execute the script inside net-snmp on first
> hit or using a net-snmp alarm, and place the results in
> /var/net-snmp/hrmib; this actually seems like a wiser solution to me as
> it avoids the platform specific cron issues and can be internally
> configured for "run only when someone requests data" or "run every X minutes".
>
Again: the better solution for RPM based systems is to maintain the
/var/cache/hrmib/* store synchronously with registering/unregistering
in an rpmdb. Bit that is an RPM, not a net-snmp, issue.
> JJ> I don't see any "user intervention" on the "portable" solution path
> JJ> that are insoluble.
>
> I never intended to imply it's insolvable. But until solved, the patch
> is incomplete and can't be applied because it's not fully self-contained.
>
> JJ> Yes you will need to add to packaging
>
> We need to always support two methods of installation (ok, 3):
>
always? Sure there's a transition phase, but "deprecated" starts
that phase out. Sadly, this HR-MIB issue invariably pops up
on -rcN paths where everyone sea ..
No time, too risky, later later later
> 1) via rpm:
> 1a) rpm -U ...net-snmp.rpm
> 1b) yum install net-smp (taken care of by the vendor)
>
> 2) via make install
> ./configure
> make
> sudo make install
>
Its not a difficult Makefile target to
mkdir -p /var/cache/hrmib
run_10line_script_to_populate_here
compared to the immense amount of AutoFu that is already in
net-snmp to try to guess all possible prerequisites for -lrpm imho.
I mailed the script years ago have lost track. I'd suggest we deal
with the script hardening issues separately, its just a single
loop to remove everything and then touch some files with the only
twist that touch needs to be invoked speshully to set the file
tstamp to the package install time.
> #1 is easy. #2 is what we need to solve *before* applying the solution.
>
Is a Makefile target an acceptable solution or not?
> JJ> All that's needed is to create/unlink a file and stamp the install
> JJ> time onto the file. This is _NOT_ hard code to write, nor is it
> JJ> risky.
>
> That's cool too, and I know modern packages like 'etckeeper' rely on
> those hooks. How far back to do they date? Hopefully far? Is the
> directory to drop the hooks in consistent across all implementations of
> rpm (or determinable easily at runtime)?
>
Heh: FHS is a moving target. I'm told that /var/lib/rpm is
no longer considered acceptable by FHS even though that path has
been in use for like 14 years now.
Go honk at FHS … meanwhile whatever path is chosen just becomes
an additional override in the AutoDu that gets defaulted to
_SOMETHING_ and spewed into a script.in and a Makefile.in. The mechanism
is entirely fear even if the choice for the path is not clear.
> JJ> Its the wrong engineering to link an rpmdb (and Berkeley DB)
> JJ> into net-snmp.
>
> That's probably arguable. I won't argue it, because I agree with you.
Good … "violent agreement" is always confusing to the hop polloi.
> But it shouldn't be wrong to link to a library in general. Else, why
> would it be in a library? The problem is that librpm changes so dang much.
>
Can you say "stale locks"? Do you want a daemon that "hangs"? I've
personally seen net-snmp blocked in rpmdb "stale lock" pile-ups
on enterprise customer sites.
SO its not just a library, but a specific database library with
lots and lots of contention and additional failure cases.
And note that RPM has _NEVER_ had a supportable/maintainable API/ABI.
The code changes slowly and is improving, but if there _WAS_ an API/ABI
of note, then we wouldn't be having this discussion about Yet Another Patch
needed because both F15 and net-snmp have changed a patch is needed Yet Again.
Saying "shouldn't be wrong to link to a library" misses the issues that
are in need of solving:
1) KISS simplicity to make net-snmp HR-MIB code easier to maintain.
2) avoiding database locking and state issues that have obscure
run-time post mortems and can/will cause all of yum/rpm/net-snmp
SoS when something goes awry.
> JJ> I'd say differently: net-snmp does _NOT_ control its own
> JJ> distribution mechanism. Look at "MeeGo" in your example above:
> JJ> that's a distro vendor, not you (as a net-snmp devel), controlling
> JJ> the distribution.
>
> No, we expect #2 above to work mostly anywhere with a devel environment
> (not having looked into meego development much, but I assume they have
> something like a scratchbox that would allow this even if it's not an
> end-device target).
>
ANd so is there an issue with
mkdir -p ${DESTDIR}/var/cache/hrmib
and doing what the script (that I've posted bout don't have on hand atm, its
in the net-snmp archives) does as part of "make install"?
> JJ> What is needed is a direction and a decision to change. That (imho)
> JJ> must come from net-snmp, not from RPM, or from distro vendors, who
> JJ> are entirely free to rematch and do whatever they wish (and vendors
> JJ> WILL do whatever they choose to do …)
>
> We *can't* affect every platform out there, and more importantly, we
> can't assume that every platform will change. Whatever solution we come
> up with *must* be self-contained. We have to make it so 'make install'
> is all that is needed regardless of the platform.
>
No one's asking you to affect every platform. Keep doing -lrpm if
you are unable to change net-snmp because of the burden.
> JJ> I've sent this patch 3 times now. I'd like a clear call that you
> JJ> WILL integrate the patch, and then I can/will generate the patch and
> JJ> the "portable" script and even take on the tedious explaining of a
> JJ> deep dark innocuous change as needed.
>
> I'd happily agree to it, if it solves the issues I'm worried about.
Make a list of issues please so I can respond.
I know of no insoluble issues. In fact this change has been on place
in PLD for years now. Works fine, and simplifies the "dependency hell"
deadlock that -lrpm imposes on vendors.
Its quite difficult when a daemon gets tied to an infrastructure
tool in lockstep and so _BOTH_ need to change together.
> Hopefully I've explained them well enough (it wouldn't surprised me if I
> haven't). I don't have sole authority, however, and thus it needs to be
> a group decision. So others may have different opinions (though if
> they're silent then we'll win :-)
>
An explicit list so that the issues are known please.
Meanwhile, I will reload the neurons and rummage about
to find the 10-20 line script that I wrote like 7 years ago.
ANd I will look at the other major objection that you have which
is
What happens with make install?
SOmeone from FHS would have to be asked, but "/var/cache/hrmib"
isn't outrageously insane or wrong or deranged or anything else.
It will have an impact into "read-only /" and tmpfs and selinux
and …
But that's true for every daemon these days, not just net-snmp.
And there _IS_ an existing known good patch to RPM code that
can be retooled into whichever fork (or vendor patched) RPM
one chooses. Go shop from PLD instead of @rpm5.org if someone
doesn't wish to be tainted by @rpm5.org code.
I'm told that there's also a patch for apt to follow the same
/var/cache/hrmib/* convention for HR-MIB if interested.
(someone @rpm5.org has said they have that patch).
I can/will personally generate the patch for any version of RPM,
on any platform, if asked.
>
> JJ> I have a duty and obligation (in my personal ethic) to try to "fix"
> JJ> a software flaw that I created.
>
> The fault is ours for not interacting with you when you originally
> submitted the patch. I agree: my bad.
Well I *thought* that sending the patch to Dave Shield was sufficient
back in August 2008. My bad for not checking and reminding.
So YES is the answer for a transition to /var/cache/hrmib transition,
with all the usual baggage and deprecation and AutoFu and compatibility and ..
If so, w00t! And I'll try to find some time in the next week to send patches …
hth
73 de Jeff
> --
> Wes Hardaker
> Please mail all replies to [email protected]
smime.p7s
Description: S/MIME cryptographic signature
------------------------------------------------------------------------------ EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev
_______________________________________________ Net-snmp-coders mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
