[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Phpgroupware-users] Re: Logs messages, session and addressbook problems
[Phpgroupware-users] Re: Logs messages, session and addressbook problems with 0.9.16
Thu, 10 Aug 2006 02:48:17 -0600
Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (darwin)
"Chris Weiss" <address@hidden> writes:
Hi, Chris. Thanks for the response!
> I've heard in the ##php channel that apache 2.2 and php stilll have
> some issues to work out. some people run it with no problems, others
> have problems. phpgw has not been tested in this configuration so I
> can't speak for it's stability. it's possible that your header error
> is related to this.
Could you elaborate on the problems that you overheard? About the
only thing I'm able to come up with on Google ("Apache 2.2.2 PHP
problems") is this:
Since I'm not using Windows and I'm using PHP 5.1.4, I feel safe.
> is the header error new since filling tmp or did it always do this?
> did you restart apache after clearing out tmp? there may be open
> handles or something.
I recall seeing it since day one, but it didn't seem to be causing any
problems, so I ignored it.
I have been doing a lot of Apache configuration, so I have restarted
apache (gracefully) numerous times since I made my post.
> how much temp space depends on what you do with phpgw and how activer
> the users are. if you have "phpgw info array" cache on (see
> Admin->site config) this session files will be notably larger, and the
> more apps you have enabled the larger it will be. at one time emails
> were cached in the sessions too, but I think they are just cached in
> the database now. I can't really make a size recomendation since my
> sites are quite low usage (2-5 users at a time). database session, in
> some tests we did some years ago, had very little perfomance impact.
> the biggest benifit would be if you wanted to scale to a web server
> farm, the sessions would then be accessable from all web servers in
> the farm via tha database master wihtout using NFS.
So what you're saying is that I should consider using a temp space
with a much more liberal quota, and keep an eye on it? ;-)
> what sql server are you using? addressbook does not have good indexes
> on all db's yet. some tweaking might be needed, there might also be
> some info in the list archives and/or bug reports.
Thanks for helping with those 2 issues. I'm still at a total loss as
to why my users can no longer login, however.
After setting error_reporting to E_ALL, the following is syslog'ed 14
times before and 10 times after the mcrypt error when attempting to
PHP Notice: Undefined variable: attachment in
on line 120
Nothing else new turns up. Disabling mcrypt doesn't help. Nor does
enabling DB-backed sessions (after doing so, the phpgw_sessions table
stays mysteriously empty, BTW).
I currently have phpgw authenticating against our LDAP server, with
user accounts stored in SQL (I have been unable to get phpgw to modify
LDAP so far).
I initially created an administrative account, then logged in with my
LDAP account (thus creating the necessary stuff in the SQL backend),
logged in as the administrator, and added my LDAP user to the
administrative group with access to the Admin module. I've since used
my own account to administer phpgw, but I am also affected by the
I cannot login to the old administrative account without switching to
SQL authentication and re-creating the administrative account, thus
deleting all my users from the SQL store. Doing so completely fixes
the problem, but we lose all of our configuration settings. How can I
Anthony Chavez http://anthonychavez.org/
Description: PGP signature