[Pkg-cacti-maint] error in cacti

[Luk Claes]

Hi Paul

The release.debian.org bug is used in the release process, while the
other one is the actual bug in cacti.

The order of the arguments only matters when changing either the calls
of the function or the definition of the function. It does not matter
for the use of max_oids within the function.

Cheers

Luk

On 01/22/2012 08:56 PM, Paul Gevers wrote:
> Luk,
> 
> 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.
> 
> Paul
> 
> 
> 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
>> 
>>