[horde] Using hooks to permanently set from_addr and fullname

[Kevin Myer]

Quoting Chuck Hagenbuch <chuck at horde.org>:
> Are you sure this is from preferences hooks? The check on line 707 of
> Prefs.php:
>
>        if (!is_null($this->_hooksCalled) && !Auth::getAuth()) {
>            return;
>        }
>
> ... looks suspicious to me - should that be && Auth::getAuth(), instead
> of ! ? Anyone?

Well, I can't comment on the need for the negate operator or not, but I 
can say
that it was definitely related to the two users doing a calendar import.  And
when it became unresponsive, they opened another session and imported their
calendars again.  Four Apache processes, using 200-350Mb of RAM by the end of
their running, and each running 25 minutes or more before completing.  I
reached as high as 40000 network connections in TIME_WAIT state (made for a
very interesting morning).

Based on the filter that my LDAP server shows, there are only three 
places that
generate that search:

1) $conf['auth']['params']['uid'] is set to mail, so initial login,
2) _prefs_hook_fullname uses #1, and
3) _prefs_hook_from_addr uses #1

So something is iteratively calling #1, whether its #2, #3, or some 
other Horde
code unrelated to either of my hooks.  Trying to sync my own calendar 
yesterday
resulted in very slow syncing performance, that eventually timed out and I'm
beginning to wonder if somewhere in that whole calendar sync/import/export
process, there isn't some code that is iteratively calling an expensive lookup
function, and that might be related to some of the performance issues with
syncing.

I'm going to modify both of my hooks to include a limited attribute set to
search for (should be doing that anyway), then import a calendar and see which
of the hooks, if either, is tickling the excessive lookups.

>> How can I optimize this - add caching to my two hooks?  Add a
>> pref->write within the hooks?
>
> If you do a write then the hook will never be called again (i.e., the
> user will have to change it themself from then on). If that's alright
> that'd certainly be an optimization.

Definitely fine to do a write, as this is a locked pref.  We don't want users
specifying a from_addr or fullname, for obvious ease-of-spoofing reasons they
can create, hence the original desire to pull this from a "official" read-only
source and set it.  Part of an internal name change procedure currently is
converting the userid for horde_prefs for that user, so that would be easy to
modify to delete both from_addr and fullname on a name change and have them be
recreated on an initial login with the user's new userid.

But if there is a bug, where something is not being cached, or there's some
iterative lookup occuring that shouldn't be, I want to nip that too, as it
could otherwise be a silent performance killer.

Kevin
-- 
Kevin M. Myer
Senior Systems Administrator
Lancaster-Lebanon Intermediate Unit 13  http://www.iu13.org