Live Chat Software by Champion Consulting
Knowledgebase : TroubleShooting

The first thing to do is, of course, to search through this help system!

We try very very hard to always keep this up to date and filled with just about everything you'd ever want to know about our system.

It's faster than live support and can even be more comprehensive.

However, we admit there are still some things that really require human intervention and for that we have our world class technical support team!

They are available via the online ticket system 24 hours a day, 7 days a week, 365 days a year. All tech support questions are answered within 24 hours.

We also have phone and live chat support which can help with some issues though we recommend using the ticket system for issues that require more in-depth investigation or upper-level staff.

Tickets also provide a written history we can refer to for future issues.

There is no hard and fast rule. It all depends on your queries.

One bad query can take down the whole server and hang the MySQL server.

So, being a shared server, we have setup the limits at an optimum level so that the server does not crash when one of the user sites is hit with lots of traffic.

If you are getting a "too many connections" MySQL error, then either you are hitting the limits or your code is not closing open MySQL connections before opening new ones.

The only person(s) who can tell you how many queries will make your site work fine is the developer of the code you are using.

They should do a stress test and see how many queries will require how much system resources (CPU, RAM). Depending on that result, we can help you with identifying which dedicated server will fit your needs.

Otherwise, it is just a hit and trial exercise.

Please login to your client area and check the network status.

If your server is up and running, then you need to check for any network problems between your computer and the server.

To help troubleshoot this, you can take a traceroute.

A traceroute will tell us if there is any issue with your router, a particular ISP, with one of the many routes across the Internet to the server, with our backbone provider, or within our system.

To do a traceroute on your Windows computer, please follow this: Click on Start : Programs : Accessories : Command Prompt Once there, enter this command:

tracert YOUR_DOMAIN_COM and tracert YOUR_IP [ where YOUR_DOMAIN_COM is your domain name hosted on the server, and YOUR_IP is the IP your account is hosted on which you can find here: [http:docs.championconsulting.com/iplookup.php]

Please provide the output of the above tracert in a support ticket.

What is your computer IP?

-------------------------

Please also visit www.myipaddress.com and provide your computer IP along with the traceroute results as this will help the techs troubleshoot the problem.

EMERGENCY BACKUP SITE AND EMAIL

-------------------------------

In case our primary DC in Atlanta has any problem, you can check http://backup.championconsulting.com on our Houston DC for updates.

You can also send email to emergency AT backup DOT Champion Consulting DOT com

Server load and bandwidth are two entirely different things. Server load refers to the amount of time the server needs to run in order to process a request.

The more concurrent requests that the server receives, the higher the load. Bandwidth refers to the amount of data that is sent over the network after the request is processed. In the case of a PHP/MySQL web application e.g. forum or portal, the server receives a request for a URL.

It finds the file that maps to the URL and sees that it is an executable file (PHP script, etc.) so it determines what it needs to use to execute the file, executes it (which probably includes connecting to the database and executing several queries), collects the output and then sends this to the requestor. All of this work contributes to the server's load.

The output (which is usually relatively small unless there are large graphics or multimedia content on the page) contributes to bandwidth usage when it is actually sent. In contrast, a simple HTML page or a movie download creates almost no server load because all the server has to do is open the file and send its contents down the pipe.

When you are asked to upgrade to a higher plan, it means your scripts are utilizing more than normal CPU and memory of the server and causing the server load to go high which in turn causes all sites hosted on that server to slow down.

The main reason could be the number of requests to your site or it could be a rogue script or code that needs fine tuning by its developer.

When you upgrade to a higher plan (for example from a shared account to a semi-dedicated), you will be getting more CPU and memory available to your account because semi-dedicated servers hosts fewer accounts as compared to shared servers.

If you are having trouble sending email, it is probably due to the auth scheme needed to allow you access to send mail using the server resources.

What does this mean in english? In an effort to prevent unauthorized users form using the server to spam, there are certain measures taken.

These are, your user needs to check their email before trying to send an email.

This is so the server may retrieve the IP that your user is logged in from thus giving that IP permission to relay email using the server.

To ensure the server authorizes your email, you may need to adjust your email settings like so:

In Outlook go to Tools, Accounts.

- Select Mail.

- Select the email account.

- Select Properties.

- Select the Server tab.

- Down at the bottom of the page is a check box option that says: My Server Requires Authentication

- Select it.

- Click OK and you're done.

Please also refer to this:

This usually indicates that there is a network problem on your end or your ISP (internet provider) is blocking your remote SMTP connections over port 25.

To verify this, you can try this small test:

If you are on Windows XP:

Go to Start : Programs : Accessories : Command Prompt

When you are there, enter this command: telnet YOUR_DOMAIN_NAME 25 If you are on Mac, it comes with an application called Terminal built in to the Operating System.

It's available in the Applications > Utilities folder. Launch Terminal and at the $ sign prompt, type: telnet YOUR_DOMAIN_NAME 25 and check to see if the output is something like this:

Trying 69.73.x.x... Connected to YOUR_DOMAIN_NAME.

Escape character is '^]'. 220-xx.nocdirect.com ESMTP Exim 4.52 #1 Mon, 15 Jan 2007 17:06:45 -0600 220-We do not authorize the use of this system to transport unsolicited, 220 and/or bulk e-mail.

If you do not get this output, then please check with your internet provider if they block remote SMTP connections and ask them for their SMTP server.

You can use their server in your email client software for outgoing email.

You may also try using port 26 instead or secure SSL with port 465.

If you do get that output, and are still unable to send email, please verify that you have SMTP authentication enabled in your email software.

If SMTP authentication is active, please open a support ticket and provide this information:

1) The output of the above test

2) Your email account username/password

3) Any error message you get from your email client software

4) Your computer IP by visiting www.myipaddress.com

Please provide the above information in a support ticket and technical support will be able to troubleshoot and help you further.

Please send an email to sales@championconsulting.com with details of your account and we'll send an email to the contact email address we have on file for you with details of how to access your client area.

There is a security practice guideline posted here.

Please take your time to read through it: (you may need to register there to view it)

This is an evolving guideline and pretty much covers all aspects of security that are your responsibility as a hosting account holder.

If you follow them all, your account will remain secure and not hacked again.

Here is the copy of the same article: Here are some tips to keep your site secure.

This was primarily written in response to a hacked site:

1. First thing you need to do is check all vendor/developer sites for ALL web scripts/applications used in your account for any updates including any mod you may be using in any web application. If you are using any open source web application, that may be the prime suspect. However, you must check all and keep them up to date. Check the database on www.secunia.com for any known exploits released in public.

2. Once you have verified that 100% of the installed scripts are the latest stable version, you will need to go through all files of your account and make sure none were uploaded by hackers before you audited or left by you from an old install of an application. There may be suspicious files in folders you would never imagine and in folders several levels down.

You can use ftp or cPanel file manager to go through all files under public_html and compare them with your local copy. [You should always maintain a local copy for this comparison as well as backup.]

3. Make sure all passwords are a mix of alpha-numeric and not a dictionary word. Just because you thought of a difficult word from the dictionary does not make you safe. Please also use both capitals and lowercase and at least 8 characters.

4. The MySQL database access to all web applications should be using separate db users. Do not ever use your main account user/pass for it. Your main user/pass should never be stored in any file in your account.

5. In your control panel, activate archive option of your web logs in Raw Log Manager. This will give you the opportunity to check how the hacker exploited one of the scripts. Otherwise all raw logs are cleared after generating stats. If you have already been hacked, its too late now but you can archive the logs for future attacks.

6. If you have customized a web application with a mod, make sure it is also the latest stable version. Many popular web application may be stable but one of the addon mods may be exploitable and possibly not maintained any more.

7. If you have written some code yourself, make sure all input variables are sanitized (checked for valid data before using it).

Otherwise a single line of bad code can give access to your entire account. The usual blunder is to include a file based on user input. Again, make sure all input to a script is checked for valid data. All exploits are based on input data. If your site does not take any input, you are 100% safe from web exploits, i.e. if you run 100% static HTML site with no script whatsoever anywhere in your account.

8. For PHP, any application that uses register_globals to be active has more chances of being exploitable. Avoid such applications.

9. If you have some mail script, make sure it is safe from header injection. In essence make sure that email address, subject and other part of data that is being submitted by user does not contain line breaks. Some coding assistance is provided on our forums.

10. Using open source free web applications is great but you have to maintain it by regular updates or you can loose all your data and site if a new exploit is known about it. And as a hosting account owner, it is your responsibility that you have installed only stable applications in your account.

11. If your site has been running fine for years, it does not mean there were no security holes in it. It actually means that exploit was unknown or you were lucky that no one exploited it before.

12. For added security, change the permissions of your configuration files (having database credentials etc.) to 660. You can do that via ftp or file manager. This feature can work on shared hosting servers or if your VPS/dedicated server has phpsuexec through cPanel.

13. For added security, if you can block access to certain administrative sections of your site, do that by giving access to only authorized IP addresses and blocking access for everyone else, Or password protect it.

14. If there is any file upload facility in your account, make sure that only authorized members can use it. Also the uploaded file should not be accessible via web URL directly (i.e. stored outside of public_html) unless a) it is only uploaded by a site admin (responsible person) b) checked and validated to be not exploitable

15. If there is any URL forwarding or Webmail facility for your site membership, make sure it is not given to all without proper authorization or it could be used for spamming.

16. If you're just testing / trying something, which only you need and you know you won't actively keep up to date, just lock it behind a password right away.

17. Since shared/sdx/reseller servers come with suPHP, you do not need any file or folder with world write permissions. The normal folder permissions should not exceed 755. PHP/HTML files can be 644 (or lower through ssh). CGI/Perl scripts should be 755.

18. Anyone who writes web application code, should be familiar with security. I found this book in my local Library particularly on PHP: http://www.oreilly.com/catalog/phpsec/ I recommend it to all.

It covers all aspects of vulnerabilities found today in web applications.

Found this site as well from the book: http://phpsec.org

1) Reporting the spammer to the source network does not usually help.

However, if you really want to report, you can note down the IP of the spammer. [ Your form or application should have the ability to record the IP. If not, please check with the developer of that application. ]

You can then visit www.arin.net and check the owner network by checking the whois record for that IP.

If the owner is apnic, ripe or lacnic, you will need to visit their site to find the owner of that IP.

Here is some relevant information: http://www.arin.net/abuse.html.

Once you have found the abuse email address of the IP owner, you can report the incident to them with full details.

2) The real solution is to protect your site from such attacks.

You can do the following steps: a) Add Captcha on your form to validate that a human is submitting the form. More details at: http://en.wikipedia.org/wiki/Captcha Also check with the developer to add this feature or find a better script that comes with this feature.

Most spamming activity is done by automatic bots, and this will protect against those attacks.

b) Block the IP of the offender from your control panel.

c) Give the ability to add comments to guestbooks/blogs to registered users only or at least set comments to moderated. We recommend solution (a) as the most appropriate, however depending on your own situation and your own decision on the usability of the site, you can do (b) and (c) as well to protect your site.

Some blog scripts such as Wordpress have plugins to add Captcha and catch spam.

We recommend using them.

Help Desk Software by Champion Consulting