[ZendTo] Re: ZendTo ANNOUNCE: Release 4.11

[Jules]

On 08/01/2013 13:21, Achim J. Latz wrote:
> Hello Jules:
>
> On 08/01/2013 13:07, Jules wrote:
>> On 08/01/2013 11:30, Achim J. Latz wrote:
>>>      1) You change/override several sensitive and global parameters in
>>> /etc/php5/apache2/php.ini, such as error_reporting, display_errors,
>>> and apc.slam_defense (which in any case should be 0, not "Off" [1]).
>   >
>> So 0 is on and 1 if off? That sounds unlikely...
>   From [1]: "Setting apc.slam_defense to 75 would mean that there is a
> 75% chance that the process will not cache an uncached file. So, the
> higher the setting the greater the defense against cache slams. Setting
> this to 0 disables this feature."
>
> At the moment, the installation sets slamd_defense to "Off" which I
> believe is not a correct value for that parameter.
Oops! So do I need to set it to 100? Or 0? I don't really know what the 
setting means or what it's for, I just found it in a list of things I 
should set when using apc.
>
>>> I wonder if this is prudent, especially for error_reporting and
>>> display_errors, whose "production value" is hopefully different from
>>> the values that you want to use. Doesn't it make more sense to fix
>>> errors/clean up code rather than adjust error_reporting?
>   >
>> They're just harmless notices. I never saw much point in fixing them as
>> they're just things that PHP should be able to handle quietly anyway.
> I understand that the notices are only minor issues.
>
> I am talking about the installation routine setting the system-wide
> error_reporting and display_errors to a value that is only required for
> "cosmetics" in ZendTo, but might cause problems with other PHP
> applications on the same machine. "display_errors" should certainly be
> Off for all production servers.
On my production servers I leave it on as it's so useful for getting 
useful error reports from users.
>
> Should the installation routine touch those (existing!) values for PHP
> at all, that is the basic question.
As most people tend to run such things in VMs these days, I worked on 
the basis that ZendTo would probably have the OS to itself. We would 
certainly never run multiple services of that scale on the same system/VM.
>
>>>      2) Even WITH the changes above, I still get the following errors:
>>>
>>> /usr/bin/php /opt/zendto/sbin/rrdInit.php
>>> /opt/zendto/config/preferences.php
>>> PHP Notice:  Undefined index: ZENDTOPREFS in
>>> /opt/zendto/sbin/rrdInit.php on line 6
>>> PHP Notice:  Undefined index: SERVER_PORT in
>>> /opt/zendto/lib/NSSDropbox.php on line 41
>>> PHP Notice:  Undefined index: HTTPS in /opt/zendto/lib/NSSDropbox.php
>>> on line 42
>>> PHP Notice:  Undefined index: HTTPS in /opt/zendto/lib/NSSDropbox.php
>>> on line 48
>>> PHP Notice:  Undefined index: SERVER_NAME in
>>> /opt/zendto/lib/NSSDropbox.php on line 48
>>> PHP Notice:  Undefined index: REQUEST_URI in
>>> /opt/zendto/lib/NSSDropbox.php on line 48
>>> PHP Notice:  Undefined index: authIMAPAdmins in
>>> /opt/zendto/lib/NSSIMAPAuthenticator.php on line 36
>   >
>> You need to set error_reporting in /etc/php5/cli/php.ini as well.
> And probably only in cli/php.ini, correct? Since we only use those files
> from cron and not from the web interface?
Yes, but you need it in the web one too as there are similar "notices" 
from that code.
>
> That would also solve the issue with overwriting (customer-facing)
> php.ini for the web applications.
>
>>> 1,2
>>> /usr/bin/rrdtool update /var/zendto/rrd/zendto.rrd 1357340400:2:2:9522.4
>>>
>>> ERROR: /var/zendto/rrd/zendto.rrd: illegal attempt to update using
>>> time 1357340400 when last update time is 1357599600 (minimum one
>>> second step)
>>> 3
>>> /usr/bin/rrdtool update /var/zendto/rrd/zendto.rrd 1357599600:1:3:1128.4
>>>
>>> ERROR: /var/zendto/rrd/zendto.rrd: illegal attempt to update using
>>> time 1357599600 when last update time is 1357599600 (minimum one
>>> second step)
>> That's because of the way that rrdtool works. Whenever ZendTo runs
>> rrdtool to do the update, it attempts to rebuild all the stats data that
>> it possibly can, in case the RRD database got damaged or deleted for any
>> reason. It still has the last month's worth (or whatever you have set
>> the drop-off retention time to) of data, so it tries to write all of
>> that to RRD. RRD complains about any data which it's already got and
>> you're trying to overwrite. So the "ERROR"s from RRD are totally and
>> utterly harmless, there's just no way to suppress them without
>> redirecting all stderr to /dev/null, which I didn't want to do as it
>> does say useful stuff under some circumstances.
>>
>> Just ignore all those errors. It's normally run from a cron job and that
>> output is ditched.
> So how do you (manually) detect the "useful stuff" between a flood of
> errors that can be safely ignored?
I do, I don't necessarily expect others to, I just ask them to send me 
all the output if they're confused/troubled/having problems, and I tell 
them what's going on.
>   Wouldn't it be (conceptually) easier
> to only get notices when something is wrong, and not having to hunt for
> the real errors in a sea of (wrong, cosmetic, false-positive) errors?
In which case please tell the author of rrdtool to add a way of 
eliminating error output when it's just already existing data that is 
being overwritten.

Jules.

>
> Best regards, Achim
>
> [1] <http://php.net/manual/en/apc.configuration.php#ini.apc.slam-defense>
>
> _______________________________________________
> ZendTo mailing list
> ZendTo at zend.to
> http://mailman.ecs.soton.ac.uk/mailman/listinfo/zendto
>
> Jules
>
> -- 
> Julian Field MEng MBCS CITP CEng
>
> Rockall, Malin: Westerly, backing southerly later, 5 to 7, occasionally gale
> 8. Rough or very rough. Showers. Good.
>
> www.Zend.To
> Twitter: @JulesFM
> PGP footprint: EE81 D763 3DB0 0BFD E1DC 7222 11F6 5947 1415 B654