telcor

Wow Are those pages automatically generated by an install script? If so, and you have a proper working backup, it might be easier to modify the installer script to insert your custom path in each file, then reinstall. Otherwise the easiest method might be to download the entire site and use a Programmers editor to do a search replace on each file to put in your custom file path. Which application is this? If it's publically accessible, it might be easier for me to give a better answer by taking a look at it. I don't mean what you have installed on your website, just a pointer to where you found this application.

that's it

Which is why the From: header is the most useless portion of an email when it comes to email tracing. Ignore it, ignore it, ignore it! Capable modern spam scanners ignore it. The envelope headers can also be spoofed, but are more difficult to do so.

Feel free to ask for more help.

Although it is limited to local account privilege escalation, combine it with a security hole in a web app that compromises an account and it's easy to gain the access needed. Or key loggers installed on compromised Windows machines that grab the login info for a hosting account. There are numerous ways to exploit this, without having an account on a cPanel server. I'm not attempting to fear-monger, just providing some examples of attack vectors.

Are any errors output? What tells you it's not working?

It depends upon the location of the included file in relation to the file that calls include. For example, if the calling file is: /home/myname/public_html/index.php And the file you want included is: /home/myname/public_html/includes/library/file.php then you can have index.php include file.php like this: >include_once(dirname(__FILE__).'/includes/library/file.php'); Didn't really save on characters though However, depending upon the security settings you can add /home/myname/public_html/includes to your PHP Path. There are at least two ways to accomplish this: within PHP, or using an .htaccess file. Method #1: >$path = ini_get('include_path'); ini_set('include_path', "/home/myname/public_html/includes:$path"); Now you can include any file within the includes directory tree like so: >include_once('library/file.php'); ... include_once('my_file.php'); Method #2: Within an .htaccess file, you can set the PHP Include like this: >php_value include_path ".:/home/myname/public_html/libraries" This gives the same effect as method #1. Now neither of these are guaranteed to work since it depends upon the security settings of your particular webhost. However, the following option will work with most common security settings. Method #3: Create a constant in the main file of your application. The constant resolves to your include path. Note that the constant must be defined in every file that needs it. A simple way to accomplish this is to define the constant in a configuration.php file and include that file in every PHP file. This method also requires altering all require, include, require_once and include_once statement to use the constant. Here is an example: ><?php //The configuration.php file define(MY_PATH, '/home/myname/public_html/includes'); ?> <?php //Another file: test.php include_once('configuration.php'); include_once(MY_PATH.'/libraries/file.php'); ?> Naturally, the proper, full path to configuration.php must be used when it is included.

Remember: Well-behaved spiders/bots will only look for robots.txt in your root domain (http://www.example.com/robots.txt, rather than http://www.example.com/forum/robots.txt). Poorly coded, or malicious, bots will ignore robots.txt. One "solution" to that is requiring all visitors to login, even to read threads, not just for posting.

Thanks for all the welcomes. I've actually been around quite a while, just never created an account until last night.

That's nice, except how does one define stable? If you visit mysql.com and try to download MySQL, you are directed to 5.0, since MySQL the company considers 5.0 to be stable and recommended, with 4.1 labeled as older and 5.1 as the new beta. 5.0 does offer many advantages, primarily because the database can actually support ANSI SQL Standards, in other words, MySQL 5.0 can almost make the claim of maintaining data integrity and offer proper support for real relational data sets. Upgrading to 5.0 should not be rushed however as one needs to consider the effects upon customers data. Not a fun thing to do. At least 4.1 -> 5.0 should be smoother than 4.0 -> 4.1.

The corollary: why do they need to run MySQl 5? MySQL 5 exports should be relatively compatible with MySQL 4.1, as long as any 5.0 specific stuff is removed. Similar with 4.1 -> 4.0, remove the charset info and it's good. PHPMyAdmin in cPanel does not allow you to create databases, you have the use the simplistic form on the MySQL Account Maintenance page in cPanel. Same goes with DROP DATABASE statements.

http://bugzilla.cpanel.net/show_bug.cgi?id=2220 If you vote for it.... Else how will they know it's important to the customer?

If you can perform other actions within PHPMyAdmin, such as create tables, execute queries, etc, then likely the problem is a difference between MySQL Server versions. If your original server used MySQL 4.1, and the TCH Server is using MySQL 4.0, then chances are the SQL generated by the export is not compatible with the TCH MySQL server. The portion you posted suggests that is the issue. If you still have access to the original server, try performing another export, using only the simplest criteria (for example, don't use extended or complete inserts, they tend to be buggy). If you don't have that access, clean out from the file everythign that is not an INSERT, CREATE or IF NOT EXISTS. Make certain to backup this file before modifying it however.

This uses a form of authentication known as HTTP-AUTH, of which there are two forms: Basic and Digest. Basic is the most common and the simplest to implement, which is what the Protected Directory functionality of cPanel uses. PHP can handle HTTP-AUTH Sessions, but to my knowledge only one browser supports a Log Out method with HTTP-AUTH, that being FireFox. All other browsers retain the information until the browser is closed. If you really want a log out button, you need to use PHP's Session handling support, but in some ways it's not as secure as HTTP-AUTH.