TweezerMan
-
Posts
1,763 -
Joined
-
Last visited
Everything posted by TweezerMan
-
Welcome to the forums, Jacques!
-
There is a problem with how your domain is set up, or maybe a problem with the DNS server - when I try a DNS lookup on "leatherandrace.com", the DNS server is reporting back a "Server failure" or "Server failed" error message. You need to submit a ticket to the Help Desk so they can take a look at this for you.
-
Without the actual domain name that you're trying to use, it's hard to say where the problem could be. If you want to browse to your web site using the server's IP address, you need to include "~" plus your CPanel username in the URL: >http://tch-ip-address/~cpanelUsername/ I only see the "There is no website configured at this address" page if you try to browse to the IP address directly, leaving out the "/~cpanelUsername" from the URL. (This is correct behavior on a shared server.) If that's not the problem, then there may be a problem with either your domain name or your TCH account (I'm thinking mis-typed domain name somewhere), which you'd need to resolve by submitting a ticket to the Help Desk.
-
Welcome to the forums, Michael!
-
How To Load Client Side Xml File Using Xmlhttp?
TweezerMan replied to sushilborhade's topic in Scripting Talk
Welcome to the forums, sushilborhade! To browse to a URL on your own machine (http://127.0.0.1/), you'd need 1) a web server of some kind running on your PC, and 2) the port that the web server uses must be open in your PC's firewall. I suspect you're probably not running a web server on your local PC. -
Welcome to the forums, pg07!
-
Congratulations, Dick!!
-
On a shared server, there is only one install of Apache, with one configuration file, that everyone shares. Changes made to the common Apache config file can directly and indirectly affect all other users on that server. With a dedicated server, yes, you would be able to configure the web server however you wanted.
-
Welcome to the forums, Jasmon!
-
The RewriteMap directive can only be used in the main web server config file (httpd.conf) and is not allowed in an .htaccess file. This is a web server (Apache) limitation.
-
Your UFM script is complaining that the ionCube loader (which is included with UFM) isn't installed, or it's not installed where the UFM script can find it. I'd suggest 1) reviewing the installation instructions and make sure you followed them correctly, 2) make sure you uploaded the UFM files in BINARY mode (as the instructions state), and 3) if all else fails, the author of UFM runs a support forum for UFM users. You can find the URL to his support forum in UFM's readme documentation or on the web site where you downloaded UFM.
-
Don't ask me why Gallery can't find it, but jpegtran does appear to be installed at /usr/bin/jpegtran.
-
What I mean is: Wouldn't the destination e-mail address be in the mailto link on the form, available for e-mail spam bots to harvest? I'm thinking this would make the web site owner's e-mail address available to spammers.
-
Wouldn't that be putting a big "spam me" target on the web site?
-
Welcome to the forums, wilfy!
-
Welcome to the forums, drfudd!
-
Wordpress Database Error: [got Error 28 From Table
TweezerMan replied to OwlBoy's topic in WordPress
Welcome to the forums, OwlBoy! -
That .htaccess line is created by installing FrontPage Extensions from CPanel.
-
It would have been nice if your Informant program included a User-Agent string when it made its requests. The User-Agent would show in the logs, and you would have known right away what was hitting your site every minute. I would not recommend checking a cgi script every minute to see if my site was up. Most CGI scripts are written in perl (including MT's), and they invoke a new perl process every time one of them scripts is called. Perl processes are fairly expensive in terms of server resources (CPU and memory usage). Requesting a page every minute uses up quite a bit of bandwidth over time. Your 1,662 byte mt.cgi file, requested every minute for an entire month, uses over 70MB of bandwidth. I would probably 1) check less often, like every 5 or 10 minutes if I really need to know that often, and 2) check an extremely small file on the server created specifically for this purpose. The file could just have this text in it to be a valid HTML file: ><html><body></body></html> 26 bytes instead of over 1,600, which would consume a little over 1MB of bandwidth if you checked this file once a minute for a whole month. Even less if you check less frequently. The amount of bytes sent back doesn't really tell you anything about what CPU and memory resources were required to generate and send those bytes. A drastic example of this would be what occurs when you perform a full rebuild of your weblog, The web server log will only show one page request, and a relatively small number of bytes sent back to the browser. But the log won't show how many weblog pages were actually written by MT, or how much time, CPU power, or memory it took to produce them. I don't know what was seen on the server side, so I don't know if one instance of MT got hung and started consuming lots of CPU, or if one the instances was blocking or interfering with subsequent instances of mt.cgi, or if it was something else. The web server logs just don't show that part of what's going on behind the scenes. I can't speak for TCH-Rick, but I wouldn't be surprised if he extracted only the log entries specifically requesting mt.cgi. You should be able to download a full copy of the web server log from the "Raw Access Logs" in your CPanel.
-
Just had a "duh" moment - the "302" status codes were being sent by the server after your account was suspended, because everything was being redirected to the "Account Suspended" page (which was of course, "found").
-
I'll usually try changing the directory permissions to 0777. If successful, I can then delete all of the files in the directory, then delete the directory if I wish.
-
Welcome to the forums, justnana!
-
The first number in those pairs you list is the HTTP status code sent back to the browser or script requesting the page. A "200" status code is "OK" - the page requested was found on the server and served to the client normally. A "302" status code means "Found". I believe this code indicates that the page has not changed, or that there was a redirection involved in the page request, and the page to be redirected to was "found". If you look at the first set of log entries you posted, the server is currently returning a status code of "500" (Server Error) - because mt.cgi is disabled. The second number in those pairs (the "1662", "140", "309") is the number of bytes the server sent back to the browser or script in response to the page request.
-
I believe the timestamps in the server log are in the server's local time zone. In your case, the "-0400" indicates the timestamp is EDT.
-
I don't believe that is necessarily a valid assumption. I'd suggest examining your server's access logs around the time your account was suspended. (If you don't know the exact time, look at the logs for yesterday and today.) See what IP addresses were accessing mt.cgi, and what mt.cgi activity was triggered by those accesses. (I see that TCH-Rick beat me to this point while I was writing this post! ) The only thing I'm aware of that would cause mt.cgi to use high levels of server resources is rebuilding your weblog. I doubt that spammers compromised your MT installation and then decided to rebuild your weblog. Your weblog's home page says you have almost 8,000 entries in your weblog. Performing a full rebuild of that many entries could put a high enough load on the server to get TCH's attention. Other factors that can add to the server load during a rebuild include ineffeicient template design and the use of plugins that are not server-friendly. Your weblog also indicates there 5 other MT weblogs running on your MT installation. Depending on how these weblogs are set up, it's possible that a rebuild on one of these other weblogs could have caused the server load issues (but I don't think that is likely). 1) Look at the logs TCH-Rick provided to you, to see what really happened (rather than just guess or assume). 2) Assuming that it's a problem with rebuilding, the template design and plugin usage for the weblog that the logs indicate is the problem should be examined, to see what improvements can be made to increase how efficiently they are rebuilt.