rvt

Be warned that the .2 address is that of heliohost.org, not of your site here. You should use the IP 216.218.192.170 for your site.

Surely if you are operating a store where you are making money you can pay for hosting. Running a business where uptime controls your profit on free hosting is just stupid.

Overselling just doesn't apply to those hosts who offer "unlimited" space/bandwidth. Every host out there oversells because they have to; even HelioHost oversells. Let's look at facts. Let us say that a server has 1TB of disk space. This is equal to 1,000GB or 1,000,000MB. Now let us say that a user gets 250MB. This means that a server with 1TB of disk space can accommodate 4,000 users. For the majority of web sites out there, they will never use the amount of space allocated to them. In a simple example, I have a 20GB drive for web sites and I give each site 2GB of space. Therefore, I can fit 10 sites on my server. But, maybe each site really only need 1.5GB. This means that there is 5GB of space on my server that isn't being used that I could sell to someone else. So, of course, I'm going to sell it because the goal of any business is to make money. I think, the best thing for you to do, is to think about the amount of disk space you will actually need. Be realistic based on what you want to put on your site. Once you've done that, multiply by 1.5 so that you have a bit of extra space "just in case" and then report back. With hard numbers (5GB, 10GB, etc) I can try and make recommendations based on that information. If you are truly looking for "unlimited" then your best bet is to go paid and for that I would recommend HostGator. They offer unlimited space/bandwidth and they have some of the best support around. I have a couple sites there with them and have been thoroughly pleased.

Not just you. Happens when server is under high load (which, sometimes, is a lot of the time).

Does anyone really think that even entertaining this idea is a good idea? :rolleyes:

If people don't know that the "beta" directory exists, then why would they try and access it? I agree that security is important but this seems to be borderline on paranoia. You can try asking your question here: http://www.thehosthelpers.com as I know there are people there who can give you the htaccess for this.

Many thanks. Glad we could get things worked out.

Absolutely positive. Set as a parked domain in cPanel for my account and NS records points to IP: 216.218.192.170 which is correct. I'm suspecting the issue might be that your name servers have "lost" my extra domain as they seem to hold no records for it. I seem to recall a number of months ago when I parked the domain here this was an issue so I just set up my own DNS and it has worked great since. Apache has to know about my extra domain because it loads properly when you visit the site and therefore must be properly configured in regards to VirtualHost settings. If it helps any, the main domain on my account is thh1.heliohost.org but I pretty much publish my parked domain and just use the helio domain for my own testing purposes. Also, I tried creating another A record for my domain in the DNS Zone Control Panel and now your NS seem to be resolving it when I query them so hopefully you can find it now. Thanks for your help.

Hi Piotr. Running your own DNS FTW!

Any update on this? I understand everyone is busy but can I get an estimate as to when this will happen? Thanks.

Umm...I've seen it happen before. It all depends how much they investigate/take the matter. Technically, ***.heliohost.org all falls under the heliohost.org domain and therefore anything that happens on ***.heliohost.org can affect other heliohost.org domains. Don't believe me, look at Google Adsense. Google Adsense got blocked on all ***.heliohost.org domains because of a problem on just 1 (or a few) heliohost.org subdomains. In regards to the "not their fault..." comment. Again, this is not the view that these companies take. Anything that falls under the heliohost.org domain or is on the Helio server falls back to djbob's responsibility. That is the way these things work. This is why other hosting companies put their accounts on a different domain then their main site; because people abuse the ***.mainsite.com and get it blacklisted thus hurting the ability for the company to bring in new customers. In regards to the "google would suspend all COM domains". Again, this is a completely different situation then what is happening here. The difference is that ***.somedomain.com is a subdomain of somedomain and therefore falls to the owner of somedomain. COM is a domain extension and there is no such thing as a ".com subdomain". What you can relate this to is if people with co.cc domains get all ***.co.cc domains blocked. This is because the domain extension is .cc and you are simply getting a subdomain of co.cc

I would like to request a dedicated IP address for my site in order to allow me to use SSL. Username: rvtrav Domain: thh1.thehosthelpers.com I already have a certificate so that should not be an issue. Many thanks.

Can you provide links to the pages that are giving you this message? I've looked through a bunch of sites hosted here and haven't seen anything out of the ordinary.

In my opinion, it doesn't matter about account privileges. Privileges can be escalated with a little work on the attackers part and then it could be a major issue. What could be more of a concern is if Google, Yahoo, and other website security sites decide to warn users that the heliohost.org domain is serving malware to visitors. That would severely hurt heliohost's ability to get new customers and keep their current customers.

Just to go in to detail a bit for other users. This issue isn't just "server" related. This issue is present on your own computer as well. One of the issues with any programming language is how to implement it. For example, Java, C, C++, etc are designed such that you have to COMPILE code in to a "machine language" in order to run it. By doing this, you could in theory speed up the time needed for execution because the computer has already "translated" your code in to something it can understand. However, programs in languages like these suffer from the same bottlenecks djbob talks about. The CPU can process this "machine code" very quickly but it can't transfer quick enough from the hard drive to RAM thus slowing program execution time down. On the flip side, some people think that in order to be "efficient" code should be compiled at run time (such as PHP, ASP, etc). The problem here is that every time you use a method in code like that it has to open up another file to get the code for that method. So, in theory, your single file PHP script could require 5-10+ files to be opened and interpreted by the computer. If your script accesses a database, that is another set of files that has to be opened up. HTML pages only require 1 file be opened - that HTML file (and any files it includes like CSS and Javascript). Thus fewer 500 errors occur with just HTML sites because they don't require as many file accesses. To sort of bring this "full circle", you tend not to notice this problem as much on your computer because there is just 1 of you. However, there are thousands of accounts here which means thousands of times the file accesses as your computer at home. Hence, the increased I/O. Now, some people could say that in order to fix the "downtime" issue the swap should be disabled to prevent the I/O spike but then the server is going to have RAM issues and I suspect lots of people will start getting "FATAL ERROR: XXXXX BYTES EXHAUSTED (TRIED TO ALLOCATE XXX BYTES)" which essentially means all the RAM is full and there is no where else to put anything. Which would bring a whole other slew of complaints.

@Wizard: I know you can't ditch cPanel. Believe me, I know the hassles of keeping features like this and such. And I know you are putting up a new server "Charlie" and I have read the support FAQ. My point is, the current accounts on Stevie need to be split between at least 2 servers and all new accounts go on a new server (#3). Obviously, this is very difficult financially and I don't see it happening. Ultimately, this is a forum where different people offer their opinions. I knew when I posted that my points were difficult to put in to action and probably wouldn't be but they were my opinion which I am entitled to post.

In short, PHP scripts require memory and CPU cycles to interpret your code. Wordpress tends to be a very "heavy" blogging script, even with the base installation. Plus, MySQL based scripts also take extra resources. Why is the server load high? 10,000+ accounts, each serving websites to users = lots of files being accessed at one time = CPU cycles to process those files. All those CPU cycles increase server load and load times. Again, my opinion, but my suggestions to fix the CPU load would be: -Ditch cPanel as it is way to resource intensive and switch to something more light weight. I'd probably use something like LayeredPanel in its place as it doesn't use as many resources. Downside of this is cPanel is name brand web hosts get "respect" for using cPanel and people view them as reputable hosts then. -Divide the accounts here amongst 2 servers to lighten the load. Buy shared hosting somewhere for heliohost.org/helionet.org to be hosted on to increase speed and uptime. -Stop giving out IP's for SSL as every SSL tranfer requires considerably more resources to encrypt/decrypt the content then just a regular connection I had another thought but can't remember it off hand right now. For those people who would like guaranteed uptime for their site (with no 500 errors), I would suggest you investigate paid hosting such as HostGator. They give you unlimited space and bandwidth plus all the cPanel features you get here. You also get a 99.9% uptime guarantee and considerably less server load. As an added bonus, I've created a special coupon just for HelioHost members to use. Enter the coupon code "HelioHost994" at checkout time and we will give you $9.94 off of your hosting package. This is a GREAT deal and will only be available for a limited time. If you have any questions about this, feel free to ask me.

You could certainly code something like this yourself. Create some sort of script (C++, Java, even PHP) that you set to run automatically on your computer. This script simply accesses a web page on your heliohost site that it can pass arguments to (something like myIPupdater.php?ip=MyIP). Then the IP is stored in a database of some sort on your heliohost site. When people go to yoursite.heliohost.org your index.php script gets the IP of your computer from the database and then some how forwards the visitor to your IP (various ways this can be done). All in all, this is very easy to implement and you can even add htpasswd protection to your IP updater script so that only the people with the password can update the IP address.

Surely your username is not "root" as it has to follow the "accountName_DBUsername" format. I imagine that might be where your problem lies.

Just an FYI, seems as if the "account" has been reset and no longer forwards you to the log in page. If this could be fixed it would be much appreciated.

Why don't you try changing your script from storing the username, etc in variables to passing them directly to the mysql_connect function. The error message you report indicates that no password is provided to use when connecting. $con = mysql_connect("localhost", "myusername", "password123");

Does the top Google hit provide any help? http://cadlab.cs.ucla.edu/~kirill/analytics.html Seems to me like the easiest way is to follow Google's instructions and copy/paste it into your files.

Do you have an ".htaccess" file? If so, try renaming it to ht.access and see if that fixes the problem.

I'm fairly certain this is just other email providers blocking HH's emails. If I had to speculate, I'd guess that emails sent to GMail accounts (and in turn Google Apps) let mail through but other providers are stopping them somewhere along the line.

Well, HelioHost doesn't have Java so that code wouldn't work, would it? And the JDBC, I'm pretty sure, is a problem on your end. I remember having this issue when coding for Android that they didn't build JDBC in to the framework. I think some Googling and installing the JDBC drivers to your local machine should fix your problem there.