mysterious open_basedir error referring to incorrect path

as it turns out, i do a 'set-include-path' already - it's inside the first include in the file (in this case, addClient.php).

somehow, php seems to think the 'current allowed path' is /home/myeasyar/ and it won't even load my file, because it's in /home/mydomain.  it never even gets a chance to load the include file.

almost like it's some kind of race condition inside apache, or some virtual machine machinery.

i just rec'd today an email from tech support saying, "Please note that we have made some changes now and can you please check it now."  can't recall just how many of these i've seen....
sigh...

but i'm still open to suggestions tho...  :-)

I would definitely press your host for further investigation.  As a shared client, you will not have access to changing the open_basedir option.  At least, you shouldn't if your host is at all concerned about security.  The option can only be set in php.ini or httpd.conf, both of which should be under their control.  Without examining their environment more closely, I have no ideas why the directive would sometimes be right and sometimes be wrong, but I can say this is their issue to fix.

You can try to use phpinfo() to capture the configuration error when it comes up, providing you can actually read your own file.  :)

Have you mentioned to them about your attempted reversion back to PHP4?

i think you may have missed the point here - there should be no open_basedir violation.  the script i'm trying to load is in my directory hierarchy - php seems to think the current allowed path is somebody else's path even tho it's my turn at the cpu.  

> Have you mentioned to them about your attempted reversion back to PHP4?
sadly, we've had many long conversations about the php4-php5-php4-php5-php4 switches, in addition to many conversations about the stupid basedir problem.

alas, i think they mean well.....

>>> there should be no open_basedir violation.

I didn't miss the point...my advice still stands.  Regardless if there SHOULD be a violation or not, the point is that there IS a violation, even if it is intermittent.  The host is the only party that can affect this.  Without access to the rest of the environment, there's little more that we can actually do to assist.  As I mentioned, I don't think phpinfo() will be much help when the error occurs since the error will keep PHP from actually reading the file.

Since you're using a control panel, the basic support people are going to be hesitant, if not downright scared, to go mess with configurations.  Make sure you get your support request escalated to someone with higher technical expertise.  

1 - Can you also get some information on why this "/home/myeasyar/"

2 - <<as it turns out, i do a 'set-include-path' already - it's inside the first include in the file (in this case, addClient.php).>>
so presumably it should have no chance to execute if Apache/php see the included file as outside of the path... can you test the effect of placing it in the code of the initial script?
Note that the open_basedir and include_path are slightly different animals, so my suggestion for the include path might not be the best!

3 - <<As a shared client, you will not have access to changing the open_basedir option.  At least, you shouldn't if your host is at all concerned about security.  The option can only be set in php.ini or httpd.conf, both of which should be under their control. >>
Some hosts allow you to have you own php.ini... can you test if you can create one in your root directory, with the content below
# ; open_basedir, if set, limits all file operations to the defined directory
# ; and below. This directive makes most sense if used in a per-directory
# ; or per-virtualhost web server configuration file. This directive is
# ; *NOT* affected by whether Safe Mode is turned On or Off.
# ;
open_basedir = /home/mydomain/public_html/xyz

> can you test the effect of placing it in the code of the initial script?
the initial script is a script in somebody else's domain/home dir - when this happens, scripts in my dir don't happen.  back up one page, try it again, all is well.

> Some hosts allow you to have you own php.ini... can you test if you can create one in your root directory
i don't think anyone really wants to execute files outside their domain.

i think you're not understanding the problem - the problem is that something is causing php/apache/?? to have residual data that appears as the "allowed path" when indeed the allowed path should be /home/mydomain.  i have no idea who myeasyar is, and i certainly can't access their scripts.

unless, of course, i've misunderstood your comment.  thanks for replying tho. :-)

You really need to get an answer from your support as to why "myeasyar " is there.
Every effort before this is clarified is, I badly fear, somehow useless.

yep -  since tech support doesn't seem to know what to do, i thought someone here might have seen this thing before.  actually, i tried to get more eyes on this thru using more points, but questions with 'php installation' (among others) as a tag are limited to 500 pts.

as i mentioned earlier, tech sup left a terse msg a day or so ago - we'll see what happens.

thanks to all who replied.  resolution pends...

> the version is 4.4.9 and apache is 2.2.11 runing on linux 2.6.9-42.0.3.ELsmp.
i can't see the php5 version, and i don't feel comfortable switching to 5 to run phpinfo due to interrupting customer usage.  it may be that i have to do this at some point.

in looking at the bug report you mention (say, you must really deserve all the accolade on your personal page :-) the issue is almost identical except the allowed path is/appears to be garbage.  but then, it's running on windoze, so a diff environment could account for slightly diff symptoms.

i will fwd the reference to tech support and see what they have to say.

resolution pends...

oh, and thanks.

You may find that your setup allows for .php5 as an extension to make a file be processed by PHP5.

If so, create phpinfo.php5 ...

<?php
phpinfo();
?>

and see what you get.


Either way, the fix is present only in SVN and not yet as an actual release.

So, if this IS the cause (and it really seems likely), then you can either upgrade to a manually recompiled version of the latest SVN or snapshot build (which is essentially a dev, non RC/RTM build) or wait until an official release.

Richard.

thanks, RQ
but phpinfo only gives php4 info.  sorry to take so long to get back - outta town today.  it would seem that if php5 is the base system, maybe the bug happens before php4 gets a whack at it.

i wonder if i can hold off the customer(s) until a new release -

i got a response from tech support -  this is an excerpt:
> If you are still getting error we could try changing your php version to PHP5

sigh...  this would be the 3rd time we've been thru this.  is it possible tech support can be this, er, unobservant?

they say no one else is seeing this problem. i'm thinking, no one else is reporting this error.   i will say the symptoms are slightly diff.  i always see /home/myeasyar.  in the bug report, they say they see random stuff.  also nothing in my logs.  can't see the system logs.

resolution pends...

tnx

Point them to the PHP bug. This is currently under debate on the PHP internals mailing list and a push for a release is being made. I can't give timescales as I'm not a release manager.

done

haven't abandoned you, just waiting for the host to get off the dime and hoping for a new php release...

NP

as it turns out, the current version of php5 is 5.2.10, not even up to 5.3.  sigh...

excerpts from phpinfo():
=====================================
PHP API       20041225
PHP Extension       20060613
Zend Extension       220060519

This program makes use of the Zend Scripting Language Engine:
Zend Engine v2.2.0, Copyright (c) 1998-2009 Zend Technologies
    with the ionCube PHP Loader v3.1.34, Copyright (c) 2002-2009, by ionCube Ltd., and
    with Zend Extension Manager v1.2.2, Copyright (c) 2003-2007, by Zend Technologies
    with Zend Optimizer v3.3.3, Copyright (c) 1998-2007, by Zend Technologies
=================================

i don't think they were originally at 5.3 and moved back to 5.2.10 because we're still seeing the bug.  the bug report doesn't say anything about 5.2

do you have further ideas?  perhaps i'll close this and re-open it after 5.3.1 makes it out and tech support loads it (assuming it's still broken at that point).

i appreciate your help and patience.

in the mean time, what is the status of your problem? do you need some workaround?

yes.  pretty annoying to customers, and whacko annoying to their customers.
thoughts?

Drastic as it may sound, see if you can get your apps onto another host.

i've been investigating hosts.  reading reviews is scary tho - everything from poor service to predatory business tactics.  

if one looks enough, one finds ugly reports about almost everybody, my current host included.  but the current host has been pretty good for me, so i have to believe a lot of the reports i read are the result of a few disgruntled users.  but when i read several sites with similar reports of _really_ ugly behavior...

any update on when (and the likelihood of) a 5.3.1 release?

any ideas on why i'm seeing this with 5.2.10? (remember, i'm using 4.4.9 - no idea how cpanel makes the switch between 5 and 4 and why 5.anything would make a difference)

this open-basedir thing is probably going to be a deal killer, tho.
without too much thread-jacking, got any recommendations?

5.3.1 is at RC1 at the moment (http://qa.php.net/ and http://windows.php.net/qa/)

May I suggest that you simply work around the problem?

1 - Switch back to the correct version of PHP, presumably php 5.2x even if it still has this bug.

2 - Manage to have your included files UNDER the directory of the failing script.
There are 2 aspects to that:
a - placing the files at the right place
b - if needed, make changes to the included and including files so that all needed links work.

I would probably do a/ with a simple stupid copy, which would allow me to keep separate the initial version and the (possibly) changed scripts. Another option would be to do that with a unix-link, but this is not what I'd select.

For b: run and check errors, edit accordingly. I suggest using some source tracking system here...

i'm not sure i completely understand - sorry

> Switch back to the correct version of PHP
for the moment, php4 is the correct version, unless you're suggesting i modify the code to be php5 compliant.

<sidenote>
the app ought to work in php5, i think, except for some legacy magic quote jiz in one app.   there's no dependency on class copying.  i need to determine why the apps complain when run under php5 - thats prob'ly the "right" thing to do.  again, the changes are minimal but the testing effort is pretty big.  and comes at a bad time, surprise, surprise.
</sidenote>

in item 2a), you're suggesting putting the include dir below each of the dirs where the .php files are, correct?

right now, the structure looks like this:
/index.php
/includes/*.inc
users/*.php
clients/*.php
...
and php files include files via require_once "../includes/xyz.inc"

and i think 2a) above means
/
users/includes
clients/includes
etc.

via either cp or symlink

correct?  could you explain please how this would fix the problem?  there is no "failing" directory, per se (unless DOCROOT qualifies :)
the failing file is random and the error occurs loading the .php file, not the .inc file.

>>>>>>>>>>> first jump to SNAP below!!

> Switch back to the correct version of PHP
for the moment, php4 is the correct version, unless you're suggesting i modify the code to be php5 compliant.
>>>> no. The less we change the code, the lmess problem we create


<sidenote>
the app ought to work in php5, i think, except for some legacy magic quote jiz in one app.  ...  i need to determine why the apps complain when run under php5 ..
</sidenote>
>>>> yes, that would certinly be useful

in item 2a), you're suggesting putting the include dir below each of the dirs where the .php files are, correct?
>>>> yes

right now, the structure looks like this:
/index.php
/includes/*.inc
users/*.php
clients/*.php
...
and php files include files via require_once "../includes/xyz.inc"

and i think 2a) above means
/
users/includes
clients/includes
etc.
>>>> yes

via either cp or symlink
>>>> yes

correct?  could you explain please how this would fix the problem?  there is no "failing" directory, per se (unless DOCROOT qualifies :)
the failing file is random and the error occurs loading the .php file, not the .inc file.
>>>> as far as I understand (but I may be wrong), problem arises at including php files..

>>>>>>>>>>>>> SNAP!
afterthougt after writing above

maybe your configuration is looking for some prepend and/or append php file...
http://www.webmasterworld.com/apache/3474052.htm

Reference is at page http://fr.php.net/manual/en/ini.core.php
<<  auto_prepend_file  string
    Specifies the name of a file that is automatically parsed before the main file. The file is included as if it was called with the require() function, so include_path is used.
    The special value none disables auto-prepending.>>

You can test the effect of placing
auto_prepend_file=none
in a local 'php.ini' (if your provider anables that)
or
php_value auto_prepend_file none
in a local '.htaccess'

> Try .htaccess first.
done.  

i'll get back in a day or so to let you know the result.

tnx
wmm

hmmmm..........
it's friday.  no errors.
when do we call this success?

4 days without errors. what was your previous record?

If errors were frequent, you might try a better proof, by removing the change and see how long it takes to crash.

Then:
- If it does not crash, then some magic has cured your web server (we all know this kind of things does happen)
- If it crashes "regularly" ie several times in 1 or 2 days, then it seems safe to consider that the system was cured with the change... so restore the curing change!

Period 1: several crashes a day? (is that true)
Event A: a change is made
Period2: no crash for several days (but are there been lots of call to the pages?)
Event B: remove the change
Period3: no crash? several crashes a day?

The problem is of course to be sure that there is no crash. Since the change made is not explicitly referenced as a bug / bug solution, we have no real proof that we have cured.

Before removing the change:
- Use Xenu or some other similar program that spiders a web site, to spider to your site. This launches several page accesses at the same time, slightly increasing the load and thus the chances of evidencing a problem.
- Run the program 1 to 3 times at different hours.
- If no crash-related problem: OK, let's take note

Do the same after removing the change.

This should help to show problems.

> 4 days without errors. what was your previous record?
3 years.  for the last month, several hours.

i'll give it til the middle of next wk, and if no errors, i'll take out the line in htaccess to see if it comes back.

i can write a script using curl or wget, let it run at night when nobody's watching.

> php_value auto_prepend_file none
> in a local '.htaccess'
so far, so good.  good suggestion.

i forgot to mention that i checked the version of both phpinfo(), no change.  so the diff behavior is (prob'ly) not due to a s/w change on their part.  that's good.

well, it's back.
yesterday (090915) morning the error msg started up again.  no change to any s/w that i can detect - php4 and 5 are both at the same rev as they were before.  i checked to ensure the change i made to .htaccess is still there.

i'm working with tech support again.  painful.  

Suspect: your host seems a good candidate. But most probably for some other reason.

1 - Register that it happened on thursay at xxhxx. Restart... and see it it does not happen one week later

2 - Look at all the logs you can access to
-- any clue in the contents at what happened at time T plus or minis 20 minutes?
-- what is the SIZE of the log files? what is the size remaining on your allocated space? on disk?
-- more specifically,look at the /tmp (or equivalent) directory where Apache places your temp files, and to any cache directory ypu might have on disk..

i cant see any of the system logs, only access.log and error.log for my root domain.  today there are some odd errors (but the subject error msg has not happened today)

there are many odd errors of the form
/home/mydomain/public_html/addOnDomain1/xxxx

where xxxx is one of (for example)
http
phpgroupware
wordpress
b2evo
b2
blogtest
blog
blogs
blogs
community
phpgroupware
drupal
wordpress
blog
b2evo
xmlsrv
b2
xmlrpc
blogtest
xmlrpc.php' not found or unable to stat

none of these have a referrer, so must have been directly accessed.  

all times are EDT.

one error is interesting:
[Wed Sep 16 10:17:10 2009] [error] [client 12.101.60.143] File does not exist: /home/mydomain/public_html/addOnDomain1/'+document.location.protocol+'

looks kinda like some js file barf'd.  this line doesn't appear in any php file.  the php files sanitize their POST and GET data pretty thoroughly, altho i guess a hole could exist.  it also appears on Tue Sep 15 18:15:59 2009


the only errors on 15 sep are things i'd expect except for
[Tue Sep 15 18:15:59 2009] [error] [client 99.240.59.246] File does not exist: /home/mydomain/public_html/addOnDomain1/'+document.location.protocol+'

the 'file not found' errors for things like wordpress, blogtest, blog, blogs look like some kind of scan, perhaps.

i wonder if someone outside could have caused this behavior, either by pounding on my files or those of /home/myeasyar

hmmm.....

happened again this afternoon - just got a phone call.  appears to have happened a couple times around 12:30 edt today, none since.

it sure would be nice if one could edit one's postings here...

Lots of information...

Facts:
- you have lots opf queries of type /home/mydomain/public_html/addOnDomain1/xxxx where xxxx are names of common open-source packages
- you have errors that seem related to javascript error
- one of the errors has been issued from this IP http://www.ip-adress.com/ip_tracer/12.101.60.143 which is in Arlington
- the other is in http://www.ip-adress.com/ip_tracer/99.240.59.246 in Canada

Questions:
- are all these addresses corporate addresses? are some of them strange?
- are any of the xxx packages installed on your machine?
- javscript files using document.location.protocol are sometimes lehal (ie, Google Analytics uses it)... but you need to check all your source codes for this string.  if it exists fine.
- unless all addresses are 'normal' I would think that your host is attacked by some scan searching for security holes in common packages, probably with some type of javascript cross scripting mechanism...
- can you check all your files and their access rights, searching for files which would have been hacked or created by a hacker?
- look with phpmyadmin in your mysql tables to check if there has been, some text dats which contain javascriopt code

just noticed something interesting about phpinfo().
in the php 4 version, session.save_path is set to /tmp
in the php 5 version, "no value"

if i create a file phpinfo.php5 (so that it runs as php5)
<?php
session_start();
phpinfo();
?>

it works fine, but when i run my own file (renamed *.php5) i get
Warning: session_start() [function.session-start]: open(/tmp/sess_f5c17c62196a140baaed8db2d2fb7cf6, O_RDWR) failed: Permission denied (13) in /home/mydomain/public_html/abc/demo/index.php5 on line 24

line 24 just says, session_start();

is save_path settable in htaccess?  php manual shows default as PHP_INI_ALL
while that of auto_prepend_file says PHP_INI_PERDIR

altho, the php doc further says,
"If you leave this set to a world-readable directory, such as /tmp (the default), other users on the server may be able to hijack sessions by getting the list of files in that directory."

makes one wonder why it was set in php4.....

1 - so there is a problem with php5 config. It should have some equivalent of the tmp directory. I understand that /tmp is already there. So what is missing is the right parameter to be set up.
2 - the tmp dir is world readable. I usually place in this dir an index.php script that it is not possible to list the files there and to read thos the names of which are known.. This does not prevent someone to find a session by using random names... but finding one will probably take very long.
3 - and of course, never store cleartext of passwords as clear text, so that if a session file name is found and the file opened this will not give the complete password. A simple trick is to store a md5 of the combination of the IP address of the visitor with the password (you might also add the login)

it would seem that since the session data is written to a file readable/writable by the pid of the web server, that the dir (whatever it is) is browsable by a php script, and all the files in it are readable by the same script.  one needs only to guess the location of the session.save_path and do something like

$dir = "/var/lib/php/";  // as a guess - maybe try /tmp or ???
if ($handle = opendir($dir))
    while (false !== ($file = readdir($handle)))
        echo "$file <br/>";

pick a file name, then fopen() and fread() it.  they're all readable.
am i missing something?

what method do you use to get the mysql username/passwd to build the mysql dsn? clearly you don't want to have $_SESSION['dsn'].  read the data from a file somewhere above DOC_ROOT maybe, and build it on the fly each time?  what do you do?

at least my home dir is not readable by the apache pid.
(it is acceded this is off topic :-)

<<pick a file name, then fopen() and fread() it.  they're all readable.
am i missing something?>>
yes and no.
This would work only from a script on the server. Now the trick is for the hacker to upload the script somewhere on your server.

Mysql connection:
- you are doing it for EVERY page, more precisely each php script does it.
- I am not using dsn and rather use mysql_connect
http://www.php.net/manual/en/function.mysql-connect.php
the server, user and password are those of the MySQL database

After that, you issue mysql_select_db to select the db if there are several.
Good practices:
- mysql_connect rather than mysql_pconnect
- place the 2 php lines mysql_connect & mysql_select_db into a php file that you can include from everywhere.
usually this is in suome subdir readable by Apache

> Now the trick is for the hacker to upload the script somewhere on your server.
hmm..  this seems pretty easy if the to-be-hacked pages are on the same shared server as i.   esp if i were just on a fishing expedition.  plus it might get me access to mysql, etc if someone's username/passwd/db_name were in their SESSION file.

also would be pretty easy if the target page didn't sanitize its POST data.

the moral is DON'T put secret stuff in $SESSION - something i need to ensure.  my guess is this is why save_path isn't specified (overtly) in phpinfo() anymore.

> Good practices:
i use pear DB, but the process is basically the same.  i include passwd from a file above DOC_ROOT.  but i'll have to think about your suggestion, it may be a better idea.  resolution pends...

as for the original question, i'm in the process of converting everything to php5.  we haven't seen the open_basedir bug since tues morning, but we're about to expand quite a bit, and i fear having this thing rear up with new customers.  and i also have some legacy files that use pear HTML_Template_IT (which is no longer supported) and they're being especially painful.  maybe SMARTY would have been a better choice.  sigh...  or no templating at all.

i'm hoping after the conversion, we'll not see the open_basedir bug again.  at least if my host doesn't use php 5.3 as pointed out above by RQ.  i'm quite excited to see just what NEW bugs we'll see  :-)

i appreciate your help and patience.

>> if someone's username/passwd/db_name were in their SESSION file
They are NOT in the sesion file, or more precisely there is no need to put them.
As I told, these informations are usually in an included php file which runs for each page and which displays no html code.

>> the moral is DON'T put secret stuff in $SESSION
this is true BUT NOT RELATED to your problem. Discussing that further is interesting but off topic

>>my guess is this is why save_path isn't specified (overtly) in phpinfo() anymore.
NO.
here is what says my phpinfo on a php 5.2.10
session.name      PHPSESSID      PHPSESSID
session.referer_check      no value      no value
session.save_handler      files      files
session.save_path      /tmp      /tmp

this suggests to check that your have session.save_handler set to 'files'
It seems that your phpinfo does not display... so we have no clue here.

>> i include passwd from a file above DOC_ROOT.
be sure that this file is of type *.php so that it cannot be displayed be a simple browse
BUT if you try to access a file above doc_root AND safe_path is in place... it will normally fail, right?

> this suggests to check ...

this is the php 5 version:
  session.name      PHPSESSID      PHPSESSID
  session.referer_check      no value      no value
  session.save_handler      files      files
  session.save_path      no value      no value

this is the php 4 version:
  session.name      PHPSESSID      PHPSESSID
  session.referer_check      no value      no value
  session.save_handler      files      files
  session.save_path      /tmp      /tmp

> >>my guess is this is why save_path isn't specified (overtly) in phpinfo() anymore.
> NO.
sorry, maybe i wasn't clear.  since i can see where session files are kept (in phpinfo), if i were on the same shared host as you, i could read your SESSION files.  pretty sure, anyway - i don't feel comfortable actually testing this on my shared host.  it works on my personal desktop using 4.4.9 tho.
if save_path is not specified, i'd have to guess until i found 'em.

i think we'll prob'ly not solve my root problem - i'm converting everything to php5 now, but i'm having PEAR related issues, way off topic for this thread.  perhaps i'll start another question later after further investigation.

unless you'd like to continue here, i think i'd like to close off.  since none of us has found the real answer, but both you and RQuadling have given me a lot of time and info, would it be ok to split the points between you?  i'm open to suggestions.

to both of you, i sincerely appreciate your time and input.  thank you muchly.

Yes, you are right. At some time we have to recognize it simply does not work§

Just before we conced defeat:

1 - What was the effect of placing

php_value session.save_path /tmp

in your .htaccess file?

2 - What is the result of your checking you scans of your site?

> php_value session.save_path /tmp
what i put in my htaccess was "php_value auto_prepend_file none".  when i added it, the problem went away, but reappeared approx 1 wk later for a few minutes, then has disappeared again.  no idea why.  not even lamont cranston knows this stuff.

> checking you scans ...
i think you mean what did i discover regarding the log entries for 'file not found' entries in the error log (stuff like blog, blogs, blogs).   not much.  i did find out who myeasyar is tho - i found it listed on a hungarian web site (no i don't) where there were listed other sites on the same host/dns.  traffic monitoring site, i think.  i have a hungarian friend - i can let you know  :-)

i whois'd and nslookup'd the ips - dhcp addresses on att.com and some other isp, don't remember.  could be anybody.

]]> php_value session.save_path /tmp
]]what i put in my htaccess was "php_value auto_prepend_file none".
OK. Also add in the htaccess this line
php_value session.save_path /tmp

]] could be anybody.
but they are attempt to intrude your site by searching security holes, so some care and monitoring will be needed.
You can for instance check from which countries the "declared IP" (since it can be spoofed) is coming and that would provide you with a first line of defense).
I'm using a very simple check:

$the_IP = @$_SERVER['REMOTE_ADDR'];
$the_country_code  = trim(' '. @file_get_contents("http://www.ipcheck.fr/api.php?objet=pays&ip=$the_IP&choix=2"));

which returns a 2 letters country code. And for some sensible operations (like registration or comments on some blogs written in French) they are shown only if made from some "white list" countries. Not hackerproof, but removes 99% problems.

> ipcheck.fr
cool!  what objets are available besides 'pays'?
how'd you find this?

for sharing that nifty utility, i'll share another utility site:
http://susjedi.com.hr/rezultati/XXXX
where XXXX is a domain name, like experts-exchange.com

it lists multiple sites with the same ip address (add-on domains of one root)

it's how i found out who myeasyar is.  i think susjedi is a croatian word for 'community', or something like that.

what objets are available besides 'pays' at ipcheck?

B-( normal pages from ipcheck have some php problems in this instant, because of includes problems B-)

As far as I remember there are:
- pays (French for "country")
- ville ("town")
- region (this would be defined differently depening on countries)

you can test the urls directly with the ip of your choice and different values for "choix" (choice), as far as I remember 0 1 and 2

THx for the addres you gave.

no real solution but lots of great information, time and patience

B-) Glad we could help. Thx for the grade and points.

Did you try
php_value session.save_path /tmp
in the htaccess file?

no, not yet.  as i mentioned, the error msg pop'd up one morning this wk, then didn't come back again.  as for tech support, i got the usual "we made some changes, get back to us if you have a problem" email.  

as long as the error msg doesn't appear, i don't think making changes can tell me much.  perhaps if it happens again...

i'm converting the legacy stuff to php5.  we don't get paid to make upgrades, but if users get peeved and go somewhere else, we don't get paid either.  and migrating from php4 to php5 has to be easier than going from php4 to php6.

the code uses the pear templating pkg HTML_Template_IT, which claims to be unsupported but causes some fatal errors.  not sure what i'll do about that.

still, i think it's the right thing to do.

just fyi, host claims to have made adjustments to /home/myeasyar account now.

i have run a script to load the page via curl some 1500+ times in the past 24 hours, no problems.  they won't comment on what they did.  

since it's an https page, i'm assuming caching has little to do with my results. hopefully, anyway.

cheers and tnx again
w