TweezerMan

The risk of tools such as curl is that it provides malicious hackers with an easy means to upload content, scripts, and tools of their choice to your site once it has been compromised. I don't believe that the people at Wordpress are "not aware" of this risk. The risk faced by Wordpress servers is not the same as the risk faced by TCH servers. When you set up a free Wordpress blog on wordpress.com, who controls the actual hosting account? Wordpress does. Who controls your TCH hosting account? You do. With the increased freedom you have with your own hosting account at TCH, this also includes the freedom to configure your account in a way that could allow it to be exploited, or upload a file to your account that could be compromised. This is not a rare occurrence at TCH, and when it does occur, every hosting account on the server is susceptible to being compromised as well. TCH tries to mitigate this risk by limiting how much damage a malicious hacker can do once an account has been compromised. One way was to limit access to server tools that would allow a hacker to gain more control over a comproised account, or the server it was located on. This is the reason tools such as curl, lynx, GET, etc., were disabled. As far as I know, you can't upload and run scripts that have been compromised in the past on TCH servers such as phpMyChat or phpBB to a free Wordpress blog account. With those kinds of restrictions, compromise of a free Wordpress blog account is much less likely, and the risk posed by the availability of tools such as curl is greatly reduced. Evidently, the people at Wordpress think the risk is low enough that they can justify allowing access to curl. But just because Wordpress thinks its okay for them doesn't automatically mean that it's okay for TCH. TCH has to make that decision based on its own evaluation of the situation, which as noted above, is not the same as Wordpress'. Hope this helps...

CGI scripts (perl or python) can be placed in your /public_html directory (same as /www) or any subdirectory below it. If you like the extra security offered by the /public_html/cgi-bin directory, you can place them there, but you don't have to. If you decide to place the file somewhere within /public_html but outside of the /public_html/cgi-bin directory, you should rename the file to test.cgi so the web server will recognize it as a file to be executed instead of displayed.

Not to mention that the last I heard, access to command line browsers (such as lynx) was supposed to be removed from all servers. If your script has to be called through a browser, TCH-MikeJ described the proper method for doing this (same forum topic as linked above), using a second script to call your script with a PHP include.

I would suspect that something in your template is triggering a mod_security filter on the server. You can submit a ticket to the Help Desk and ask them if this is the case, and if so, to fix it for you. (mt.cgi needs to be exempted from mod_security filtering.) The only other possibility I can think of is that your computer / IP address has been blocked at the server (blocked in an .htaccess file, or a server config file). It is not a file permission problem, as I can access the mt.cgi login page without issue. Either way, I think a Help Desk ticket is the way to go. P.S. You might want to think about upgrading MT on your site - 2.64 is pretty old.

There's more than one way to do this. 1) mysql_field_flags() function in PHP If the field is indexed, the string returned by mysql_field_flags() will contain "primary_key", "unique_key", or "multiple_key". I'd suggest searching the returned string for "_key" (common to all 3). 2) 'SHOW INDEX FROM table_name' query You could run a SHOW INDEX query on the table containing your field (which returns a table), and search for a record containing your field (by examining the 'Column_name' field of each record). If the field is indexed, it will be present, and if it is not, it won't. 3) 'DESCRIBE table_name field_name' query You could run a DESCRIBE query on the table and field, which will return a single record containing information about your field. If the field is indexed, the "Key" column will contain "PRI", "UNI", or "MUL". Otherwise, the "Key" column will be empty. To get a better idea of what SHOW INDEX and DESCRIBE queries return, you can run them in the SQL tab in phpMyAdmin and view the results in your browser. Hope this helps...

From what I can tell by reading the instructions and looking at the reblog code (I do not have reblog installed on my site): 1) reblog.pl is not meant to be called directly, such as from a cron job. The first thing that any script calling on MT needs to do is tell perl where MT's /lib and /extlib directories are, and reblog.pl does not have any code which does this. This is the direct cause of the error message you're seeing. (MT.pm is in your public_html/mt/lib directory, but perl can't locate it because public_html/mt/lib isn't in perl's library search path.) 2) reblog.pl should be located in your plugins directory (public_html/mt/plugins), not your MT directory (public_html/mt). The purpose of reblog.pl is to provide the necessary plugin hooks into MT, which it can only do from MT's /plugins directory (because that's the only place where MT looks for plugin code). 3) If you were going to try to call a reblog script in a cron job, it looks to me like reblog_import.pl would be the one to use (which should be in your MT directory (public_html/mt)). reblog_import.pl does have the necessary code to tell perl where MT's /lib and /extlib directories are. To use reblog_import.pl: 1) reblog_import.pl needs to be executable (its permissions set to 0700 or 0755). 2) There are two parameters in the script that you need to edit before you can use the script: a) Line 7 - RB_BLOG_ID - the ID number of the blog you want to import into Line 10 - RB_AUTHOR_NAME - the MT login name of the user you want to import new entries as 3) Cron job should be set up with following command line: >cd /home/cpanelName/public_html/mt; ./reblog_import.pl (where cpanelName is your CPanel username). This script does produce output, pretty much like what you see in your browser when you do a manual import. Cron will interpret this as an error message and e-mail you whatever the script outputs every time it runs. If you would prefer not to receive these e-mails, set up your cron job with the following command: >cd /home/cpanelName/public_html/mt; ./reblog_import.pl > /dev/null Hope this helps...

The CPanel Error Log is only a web server error log, so your cron job would not record any errors there. (The cron job runs outside of the web server.) It appears that the 'wp_bad_behavior_log' table has become damaged or corrupted, as indicated by the error number included with the error (errno: 145): I'd suggest attempting to repair the table in phpMyAdmin.

The regex does not work as you as intend because as you have it, the regex will match on any substring of 4 to 6 digits. Besides allowing '1234567' to pass, values such as 'xyz1234' and '1234xyz' will also pass, because the test string contains a string of 4 to 6 digits. If you add "^" to the beginning of the regex (regex must match at beginning of string) and "$" to the end of the regex (regex must match at end of string), this will force the regex to match only on the entire string, rather than matching on a substring: >if (!ereg("^[0-9]{4,6}$", $testvalue)) die ("<h3 align=\"center\">The value you entered must be 4-6 digits only.<br />Use the back button and try again.</h3>");

I have Norton Internet Security 2005. The setting that control whether referers are sent or not is under "Norton Internet Security", "Privacy Control". Click the 'Configure' button, then the 'Custom Level' button. The 'Enable Browser Privacy' checkbox will turn referers off and on when it is checked or unchecked. Also, you can click the 'Advanced' button and referer sending can be configured on a global basis as well as per domain (the "Information about visited sites" box)

For what it's worth, I now get a response with telnet.

No, I would not expect a database connection to a TCH server to behave differently. I just tried testing your server with telnet to see if the MySQL server is listening and responding to connection requests, and the connection failed. My TCH domain readily responds to a telnet connection on port 3306. It appears to me that something is not right on the server, and I think you should submit a ticket to Help Desk to have them investigate it.

The database name and database username should be prefixed with your CPanel username (plus an underscore) as you described at the beginning of your post. Your domain name (allenton.co.nz) should be specified as the server to connect to. Assuming everything is running correctly on the server, the most common cause of your error is a firewall blocking the connection from your PC to the server.

"Not Acceptable" is an HTTP 406 error, which is usually an indication that mod_security (a server level filtering module) is blocking the post due to something in your post that matching something in mod_security's filter list. I'd suggest submitting a ticket to the Help Desk and ask them to look into it. They should be able to adjust mod_security's filtering so posts such as your example are not blocked.

Based on my testing, it appears that phpMyAdmin is only allowing files to be imported with "LOAD DATA LOCAL INFILE" from specific directories (and the directories in your account aren't among them). The "Errcode: 13" is actually a "permission denied" error, not an actual "file not found" error, and it looks to me that it's something in phpMyAdmin's configuration that is causing the permission denial. You said you were working on a CGI script. I think your best bet would be to post relevant code from the script rather than trying to get the query to work in phpMyAdmin. I am able to get "LOAD DATA LOCAL INFILE" queries to work in both PHP and CGI scripts, but those same queries fail in phpMyAdmin with the exact same error message you're seeing. Here's a quick and dirty example of how a CGI script could do a LOAD DATA LOCAL INFILE query: >#!/usr/bin/perl use DBI; print "Content-Type: text/plain\n\n"; my $dsn = "DBI:mysql:" . "database=cpanelName_dbName;" . "host=localhost;" . "port=3306"; my $dbh = DBI->connect($dsn, 'cpanelName_dbUserName', 'dbPassword') or die $DBI::errstr; my $qry = "LOAD DATA LOCAL INFILE '/home/cpanelName/public_html/cgi-bin/formdata.txt' INTO TABLE registered FIELDS TERMINATED BY ';' LINES TERMINATED BY '\\r\\n'"; my $rows = $dbh->do($qry) or die $dbh->errstr; print "\nDone!\n"; With the above code, your formdata.txt file only needs to have full read permissions (0644) - it does not need (and should not have) 0777 permissions.

Trackback ping throttling is always enabled in MT, even if you don't see any settings that would appear to enable it. Any dynamic script (such as .php and .cgi scripts) can return an HTTP error on its own (such as a 403 error). In the case of a trackback ping that is throttled, it is MT that returns the "403 Throttled" error, not the web server. As noted above, it is not the web server that is returning the "403 Throttled" error, it is MT itself. The configuration settings that control MT's trackback ping throttling are in your mt-config.cgi / mt.cfg file. There are three settings that affect trackback ping throttling: OneHourMaxPings - The maximum number of pings that a weblog can receive in one hour. If this setting is not present, MT uses a default of 10 for this setting. OneDayMaxPings - The maximum number of pings that a weblog can receive in one "day" (with one "day" being determined by the ThrottleSeconds setting below). If this setting is not present, MT uses a default of 50 for this setting. ThrottleSeconds - This setting is the minimum number of seconds between comments from a single IP address. MT also uses this setting when deciding whether to throttle trackback pings with the OneDayMaxPings setting, with one "day" being (4000 * ThrottleSeconds -1) seconds. If this setting is not present, MT uses a default of 20 for this setting. With the default of 20 seconds, one "day" for the OneDayMaxPings setting is a little over 22 hours (80,000 seconds). Yes, the proximate cause would the combination of traffic at your web site and whatever settings MT is using for trackback ping throttling. Another MT weblog would not be able to cause your site to throttle trackback pings. Having MT in an scgi-bin directory would not affect trackback ping throttling. Renaming the script would not be "cheating", but it would have no effect whatsoever on MT's throttling of trackback pings. What you would need to know is the pattern of trackback pings being sent, and what MT is using for the three configuration settings above. Assuming the default for all three settings, even if you receive "only" 20 trackback pings in a single day, receiving one ping per hour for 20 consecutive hours would not trigger throttling by MT. But receiving all 20 within a single hour would cause the last 10 to be throttled, as this would exceed the OneHourMaxPings setting of 10. The OneHourMaxPings and OneDayMaxPings settings are not present in a default mt-config.cgi / mt.cfg file. You can add them to your configuration file if you would like to use settings other than the default. Example: >OneHourMaxPings 50 OneDayMaxPings 200 ThrottleSeconds should be present in your config file, but commented out. If you wish to alter this setting, you would need to uncomment it (remove the "#" from the beginning of the line). Hope this helps...

Way to go, Vivek!

Welcome to the forums, Thomas!

Welcome to the forums, mora!

Welcome to the forums, Rowan! The "Advanced PHP Debugger" (APD) is not available on TCH servers, nor is it something that you can install locally on your account. It requires root access to install, and it may or may not be compatible with other Zend Extensions installed on the server (such as Zend Optimizer, which is installed on TCH servers). You might want to try adding var_dump(debug_backtrace()); to your script at whatever point you're wanting to see a trace.

I just re-read your post and noticed that you posted "2004" for the date that the FTP server is showing. If you really meant "2004" instead of "2005", that would indicate to me the date on the server is not set correctly, and you should probably submit a ticket to the Help Desk and have them look into it.

The times on the FTP server are in UTC, which is (I believe) 8 hours ahead of your local time. At the time of your post (11/30 5:52 PM), UTC time was 12/01 01:52 AM. If you uploaded a new file or modified a file after 4:00 PM local time, the modified date on the server (in UTC) would show 12/01. The date is correct, so there is nothing to fix.

Welcome to the forums, Matt!

From what I've been able to find on the internet, this is a known issue with mod_rewrite that is currently not fixed. Depending on your script, you may be able to work around the issue with one of these options: 1) Double-URL-encode ampersands As you noted above, ampersands ('&') can be encoded in a URL as '%26'. Encode the '%26' as well, with '%' encoded as '%25'. This would result in the ampersand being replaced with '%2526'. Since mod_rewrite only perform one pass in decoding URLs, the string '%2526' will be decoded into '%26', which will then be passed correctly to your script. 2) Change the query string argument separator in PHP In URL query strings, parameters can be separated with '&' or ';'. By default, PHP uses '&' to separate multiple parameters in a URL's query string. You can configure PHP to use ';' instead by adding the following to your .htaccess file: >php_value arg_separator.input ";" 3) Parse the query string yourself The query string that was submitted in the URL to your script will be present in the PHP global variable $_SERVER['QUERY_STRING']. Your script could read the query string directly and parse it into variables in however manner you see fit. Hope this helps...

Welcome to the TCH family, Sam!

That may be a question best directed to Bloglines. I looked at your feeds in Bloglines - they report your FeedBurner feed last updated on Nov. 29 (yesterday), but your RSS and Atom feeds are reported as last updated on Nov. 17. The earliest entry in your blog is dated Nov. 21, so there were apparently no entries in your RSS and Atom feeds on the 17th when Bloglines last checked them. I'd suggest asking Bloglines why they are apparently no longer checking your RSS and Atom feeds for updates.