[Pkg-cacti-maint] error in cacti

Paul Gevers paul at climbing.nl
Sun Jan 22 19:56:23 UTC 2012


Fine with me, but still. Your argument was that back ports would be
easier, but I believe you make it slightly more difficult, as the
arguments are now all there, but in different order than in newer
upstream code. I think that will be very difficult to catch if somebody
needs to catch it. But then again, this is more compatible to additions
that people might have made locally.

By the way, why a new bug? The problem described in the bug is 100% the
same as #656613.

And of course, thanks for taking care.


On 22-01-12 20:27, Luk Claes wrote:
> Paul
> Please have a look at #656816, I just put the max_oids argument as
> last argument as not having it is worse than having it as the one but
> last argument IMHO.
> Cheers
> Luk
> On 01/22/2012 04:47 PM, Paul Gevers wrote:
>> Oops, the mail was not meant to be sent yet. Finished here.
>> On 22-01-12 16:39, Paul Gevers wrote:
>>>> Ok. I agree that it is cleaner, but in newer upstream code, the
>>>> max_oid argument is not the last argument of the function. I am
>>>> not so much into php that I can tell if the order of your
>>>> arguments make a difference, but as the arguments are unnamed,
>>>> I expect that you can not add extra arguments in front of
>>>> existing argument without careful checking. The point is, I am
>>>> afraid of introducing even more regressions. That is why I
>>>> prefer to revert to the hardcoded value. But as I am not so 
>>>> experienced in these kind of things in security fixes, I am
>>>> willing to make the changes as you propose today, but can
>>>> somebody check them? Please let me know a.s.a.p.
>> Hmm, I really don't see how this can be done without changing quite
>> some of the code not fully in line with upstream. cacti_snmp_walk
>> is called in 5 files:
>> ./lib/data_query.php ./scripts/ss_host_cpu.php 
>> ./scripts/query_host_cpu.php ./scripts/query_host_partitions.php 
>> ./scripts/ss_host_disk.php
>> And as upstream put the max_oids argument as the next-to-last
>> argument we need to change all those calls. But what to put in that
>> field? The max_oids is not available from somewhere as-is (see e.g.
>> upstream bug 1882 [1]). My *guess* is that we *could* add a 
>> read_config_option("max_get_size") to all the calling functions, or
>> even a zero, and add the following check to cacti_snmp_walk:
>> /* determine default max_oids */ if (($max_oids == 0) ||
>> (!is_numeric($max_oids))) { $max_oids =
>> read_config_option("max_get_size"); if ($max_oids == "") $max_oids
>> = 10; }
>> Do we want this? I prefer to have your response before I continue.
>> Paul
>> [1] http://bugs.cacti.net/view.php?id=1882

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-cacti-maint/attachments/20120122/69f253bd/attachment.pgp>

More information about the Pkg-cacti-maint mailing list