TweezerMan

1. Log format: >64.124.85.72 IP address of machine that made request to server (remote host). Identity of client, determined by identd server on client machine. Highly unreliable and should almost never be used. UserID of person making request, determined by HTTP authentication. Entry of '-' indicates document is not password protected. >[03/Oct/2005:22:45:47 -0400] Date/time that server finished processing request. >"GET /?ID=29 HTTP/1.1" Request line from client, which actually is made of 4 sub-fields: HTTP request method used by client. Typically 'GET' or 'POST'; possibly 'HEAD'. URL path requested by client. >c) ?ID=29 Query string sent by client (parameters sent with 'GET' request). Request protocol HTTP status code sent back to client. Bytes sent, excluding HTTP headers. >"http://nirenjan.com/Blog/post.asp?ID=29" Referer header, sent by client. User-Agent header, sent by client. Technically, yes, the timestamp and the log format can be customized, but such customizations would have to done at the server level (it is not something that you would be able to perform). However, the log formats are in a standardized format across all servers and accounts, known as "NCSA extended/combined log format". This standard format is relied upon by a number of programs that read the server logs (such as AWStats). Changing the log format would most likely break these programs. For these reasons (standardization across accounts/servers and program compatibility), I don't think the Help Desk would be willing to make any changes in the log format. Ultimately, I believe the answer to your last 2 questions would be 'no'.

Welcome to the forums, osoguy!

Welcome to the forums, JT!

PHP scripts run as the user 'nobody'. A typical directory on your account will be owned by your user ID, and you cannot change the owner or group of a directory (this can only be done by the 'root' superuser). To grant a PHP write permissions in a directory owned by you, the only option you have is to set the directory's permissions to 0777 (world-writeable). There is some security risk in this, so you should not set 0777 permissions on more directories than necessary, but this is a "necessary evil" in a shared server environment.

I'd suggest using the following: >/home/myuserid/public_html/calendar/email_reminders.cgi > /dev/null

It's not a matter of advantage (security-related or otherwise) - the host name specifies what machine the MySQL server is running on. When you are running a PHP script on the TCH server, the MYSQL server is on the same machine, so you would specify the MySQL host name as 'localhost' in your connection parameters to reflect this. When you are using DreamWeaver on your home PC, the MySQL server you want to connect to is still on the TCH server. To connect to it, you have to give the domain name of your site so the TCH MySQL server can be found from your home PC. If you specify 'localhost' as the MySQL host name in DreamWeaver, DreamWeaver will try to locate and connect to a MySQL server running on your home PC (not the TCH server). Most home users do not run their own MySQL servers, and their intent is to indeed connect to the TCH MySQL server. The use of 'localhost' and a user's domain name as the MySQL host name is not interchangeable, as each one tells DreamWeaver to try to connect to a MySQL server on different machines.

Welcome to the forums, JTD!

Actually, the MySQL server should be set to 'amfmechanical.com', and as TCH-Andy said, your IP address needs to be added to the 'Access Hosts' section of CPanel / MySQL Databases.

Welcome to the forums, Fabio!

The import file was not uploaded to the server in ASCII mode. It has Windows-style line breaks in it, which the server won't read correctly.

Welcome to the forums, Patrick!

The purpose of creating a cgi-bin directory outside of /public_html is so executable .cgi scripts are segregated from the ordinary web pages on your web site. When this is done on a web server, there will be a ScriptAlias directive in the server's configuration file so the cgi-bin directory can be accessed from a URL. You can create a cgi-bin directory outside of your /public_html directory, but you won't have access to the server configuration file to add the necessary ScriptAlias directive (and this is something the Help Desk most likely would not perform for you either), so the short answer is, no, this is not something that you can do. Having the cgi-bin directory separate from your /public_html directory would only be useful if .cgi scripts can only be executed from your cgi-bin directory. TCH servers are configured so that .cgi scripts can be run from any directory within /public_html. You can restrict the ability of .cgi scripts to be run from directories other than the cgi-bin directory with .htaccess directives, but most people like the convenience of being able to run .cgi scripts from any directory in their web site.

The IP Deny Manager is probably indeed what changed that line when you added a new IP address. You could manually add IP addresses you want to ban to your .htaccess file - all you need to do is add a new 'deny from xx.xxx.xx.xxx' line for each IP address you want to ban.

The Order directive has somehow become the reverse of what I suggested. With 'Order allow,deny' in place, server access is denied by default unless there is a matching allow directive. There are no 'allow' directives in your .htaccess file, so everyone is denied access to the web server. You should be able to restore your server access by replacing the Order directive with "order deny,allow". This configures the server to allow access by default, unless there is a matching deny directive.

I'm not experiencing any problems running queries and displaying the results in phpMyAdmin. Without some more specifics about what query you're trying to run, and what steps you go through to enter and run it in phpMyAdmin, it's hard to say what the problem could be.

Welcome to the forums, vinyl-junkie!

Welcome to the forums, Martin!

Welcome to the forums, Michael!

Welcome to the forums, CharlieT!

You may want to submit a ticket to the Help Desk and ask them about it. The way I read that error message, 'zip' does not appear to be installed on your server.

I believe your problems may stem from the 'include_once' statement you've added to your web pages. With the domain name as you have it, PHP won't see it as a valid URL or file path. I don't believe you want a full URL there, as this will cause PHP to issue a second page request to run your script, and you lose access to the server variables from the first page request (your web page with the included PHP code). I'd suggest using the following: ><?php @include_once /home/cpanelName/public_html/counter.php?>

Try /usr/bin/zip.

I'd probably use mod_rewrite to do what you're asking. Add the following to the .htaccess file in your /public_html directory: >RewriteEngine on RewriteBase / RewriteRule ^Blog/feed\.asp$ /feed/ [NC,R=301,L] RewriteRule ^Blog/(.*)$ /$1 [NC,R=301,L] The 'NC' indicates a 'no-case' (case-insensitive) comparison, the 'R=301' indicates a permanent redirect, and the 'L' indicates 'last rule' (stop processing mod_rewrite rules if this rule is matched). Hope this helps...

Hotlink protection is indeed no guarantee for preventing another site from stealing your content. Hotlink protection works by examining the 'referer' string sent with a page/file request, and this string can be arbitrarily set to any value by the user (including none). It is merely a deterrent - there are a number of well-known ways to get around hotlink protection if the user is willing to go to the trouble. You may be able to block access to your files from programs like 'flashget' by checking UserAgent strings in your .htaccess file, but this is something you'd have to manually set up (you can't do this directly in CPanel). This isn't fool-proof either, but it would be another hurdle that a user would have to get past.

Welcome to the forums, Amanda!