Paul Lesniewski wrote: > On Jan 26, 2008 3:08 AM, Mick <asurfer@xxxxxxxxxxxx> wrote: > >> Paul Lesniewski wrote: >> >>>>>>>>> Quick question: Would anybody know of a reason where Squirrelmail >>>>>>>>> would >>>>>>>>> randomly log a user out during a session? These logouts, when they >>>>>>>>> occur, sometimes happen when clicking on an email in order to read it >>>>>>>>> and at other times, when "Send" is clicked on after an email has been >>>>>>>>> composed. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> Posting guidelines: http://squirrelmail.org/postingguidelines >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> Squirrelmail version: 1.4.9a >>>>>>> Installed Plugins: None >>>>>>> PHP version: 4.3.9-3.22.9 >>>>>>> Web Server version: Apache 2.0.52-38.ent.centos4 >>>>>>> IMAP version: uw-imap 2004g >>>>>>> SMTP version: Sendmail 8.13.1-3.2.el4 >>>>>>> OS: CentOS 4.6 (for i386) >>>>>>> Installation Method: Installed manually i.e. from tar.gz file >>>>>>> Browsers Tried: Internet Explorer 7 >>>>>>> >>>>>>> with regards to any error mesages: That's the exasperating thing: There >>>>>>> is nothing in either the mail logs, the web server logs or the secure >>>>>>> logs to indicate why this problem occurred. All that I have to go on is >>>>>>> that while running tail on the mail log, after logging in, for every >>>>>>> operation thats performed, e.g. going into the Inbox or reading an email >>>>>>> etc, uw-imap logs an associated login and immediate logout. >>>>>>> >>>>>>> Now this particular Squirrelmail installation belongs to a customer of >>>>>>> ours and when he goes to read an email, or after composing an email, >>>>>>> clicks on send, then sometimes - and at random it seems - he finds >>>>>>> himself immediately back at the login screen. >>>>>>> >>>>>>> To date, after 30 minutes of clicking around in that same Squirrelmail >>>>>>> account, neither I, nor the customer's web developer are able to >>>>>>> reproduce the problem. Any ideas would be *greatly* appreciated as this >>>>>>> behaviour is (understandably) driving our customer nuts (pun intended ;)). >>>>>>> >>>>>>> >>>>>>> >>>>>> Maybe a good start would be installing the actual version 1.4.13 (+patch >>>>>> if sending mail doesn't work - see list archives) oder 1.4.14svn (patch >>>>>> already included). Second check the browser for cookie options, maybe >>>>>> there's something wrong on his side, try another browser,... >>>>>> >>>>>> >>>>>> >>>>> There's also a plugin that alerts you if you don't have cookie >>>>> support, although I'm not sure it will work in this case. See the >>>>> Cookie Warning plugin. The OP mentioned the maillog but didn't >>>>> mention specifically if he is watching the web server log and if PHP >>>>> error reporting is turned all the way up. >>>>> >>>>> >>>>> >>>>> >>>> Hi Paul. >>>> >>>> Thanks for your reply. >>>> >>>> >>>> >>>>> The OP mentioned the maillog but didn't >>>>> mention specifically if he is watching the web server log and if PHP >>>>> error reporting is turned all the way up. >>>>> >>>>> >>>>> >>>> Actually, I did: >>>> >>>> >>>> >>>>> with regards to any error mesages: That's the exasperating thing: There >>>>> is nothing in either the mail logs, the web server logs or the secure >>>>> logs to indicate why this problem occurred. All that I have to go on is >>>>> that while running tail on the mail log, after logging in, for every >>>>> operation thats performed, e.g. going into the Inbox or reading an email >>>>> etc, uw-imap logs an associated login and immediate logout. >>>>> >>>>> >>>> BUT, I need a holiday I think. I was looking in the web server's access >>>> logs instead of in it's error logs. Gah. Anyway, lines like the >>>> following are located throughout the error logs: >>>> >>>> [error] [client X.X.X.X] PHP Notice: Undefined variable: rcptaddress >>>> in /var/www/squirrelmail/src/login.php on line 146 >>>> >>>> >>> There is no such variable in the SM code with this name. You might >>> want to explain what modifications you have made to the code and what >>> plugins you are using (you say none, but either you DO have some >>> plugin or code modification in place, or someone has hacked your >>> system). >>> >>> >>> >> Ok. That would be because our servers have the Ensim control panel >> installed on them. Each site runs in a chrooted jail and as such, each >> site has it's own copy of Squirrelmail installed (although they are all >> identical except for the site name in the config.php file being >> different of course). Ensim havve modified Squireelmail, but I was >> > > And of course this means that you should probably go to them to > understand what your problem is, as we cannot support code that > someone else has mucked about with > > Fair enough :) >> under the assumption that the extent of it was simply to add an include >> statement into config.php like so: >> >> include("ensim_config.php"); >> >> with the contents of ensim_config.php being: >> >> <?php >> $org_name = "example.com"; >> $org_title = "example.com"; >> $domain = "example.com"; >> $imapServerAddress = "x.x.x.x"; >> ?> >> >> However, from what you have stated, it appears that ensim also modified >> login.php - reason being that when the login page for Squirrelmail is >> loaded, it automatically inserts @domain (e.g. @example.com) in the >> email field. All that the customer needs to then do is to prepend >> @domain with their username and then login. >> > > They could have just used the Login Manager (vlogin) plugin and not > needed to modify the source code. > That doesn't surprise me. Ensim made a lot of blunders. I really hope that SWSoft do a better job. I'll be installing a single, global installation of Squirrelmail soon and will give that plugin a go. Thanks for that tip. > >> I'll take this particular issue up with Ensim (actually, now with SWSoft >> seeing as Ensim's control panel business was recently acquired by >> SWSoft). However, while on the subject, could I simply stop these >> errors from being logged if I simply declare the variable at the >> beginning of the login function in login.php perhaps? >> > > Yes, set it to an empty string or something, but there may be more > serious problems that need to be addressed that I cannot speak for. > Ok. I'll give that a try. > >>>> and corresponding to when the random logouts occur, are these errors >>>> (one for each random logout): >>>> >>>> [error] [client X.X.X.X] File does not exist: >>>> /home/virtual/site233/fst/var/www/squirrelmail/src/redirect.php3a5def33 >>>> [error] [client X.X.X.X] File does not exist: >>>> /home/virtual/site233/fst/var/www/squirrelmail/src/redirect.php29e09f87 >>>> [error] [client X.X.X.X] File does not exist: >>>> /home/virtual/site233/fst/var/www/squirrelmail/src/move_messages.phpf9f96dfb >>>> [error] [client X.X.X.X] File does not exist: >>>> /home/virtual/site233/fst/var/www/squirrelmail/src/redirect.phpdc6cc80a >>>> >>>> >>> Is the path correct for these (not the filename, the path)? The only >>> thing I can think of off the top of my head is that these are file >>> names for a PHP accelerator/cache that is malfunctioning. If you are >>> running one such application, turn it off and try again. >>> >>> >>> >> Yes. That is the correct path. Each site has the following aliases in >> it's virtual hosting conf file: >> >> Alias /squirrelmail /home/virtual/sitex/fst/var/www/squirrelmail/ >> Alias /webmail /home/virtual/sitex/fst/var/www/squirrelmail/ >> >> where 'x' is the site number. >> >> With regards to a malfunctioning PHP accelerator/cache: The only >> possible candidate for that would be Zend Optimizer (the free version - >> so the decoder basically) that is installed on every site. Could the >> Zend Optimizer possibly be the cause of those hex characters being >> appended to the filenames in the logs? >> > > Might be. You could ask Zend or Ensim or just try deactivating it. > I've posted on the php-general mailing list. Hopefully someone there will know and will answer. Having said that then, please consider this thread to be closed. Many thanks for your assistance. > >>>> (Incidentally, these were all logged with E_ALL & ~E_NOTICE). >>>> >>>> >>> It is always helpful when debugging to use E_ALL and DO NOT suppress >>> E_NOTICE. I think the posting guidelines recommend such. >>> >>> >> Logging has now been changed to E_ALL. I'll see if anything else that >> is related to this problem shows up in the logs as a result. >> > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > ----- > squirrelmail-users mailing list > Posting guidelines: http://squirrelmail.org/postingguidelines > List address: squirrelmail-users@xxxxxxxxxxxxxxxxxxxxx > List archives: http://news.gmane.org/gmane.mail.squirrelmail.user > List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-users > > ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ ----- squirrelmail-users mailing list Posting guidelines: http://squirrelmail.org/postingguidelines List address: squirrelmail-users@xxxxxxxxxxxxxxxxxxxxx List archives: http://news.gmane.org/gmane.mail.squirrelmail.user List info (subscribe/unsubscribe/change options): https://lists.sourceforge.net/lists/listinfo/squirrelmail-users
