EUKHost reaches a new low

[robb]

I'm very disappointed. Not only has EUKHost failed to address my issues, but they now find it necessary to silence me on their forums.

A forum thread will naturally close when the issues contained are resolved. The premature closure of a thread is nothing short of censorship: a dishonest attempt to portray an inaccurate picture to existing and potential customers.

After many problems, EUKHost said they were confident I would find a marked improvement in the services and uptime. So at their request, I gave them the opportunity to demonstrate they could provide a more professional service. I had my doubts, but even I could not have imagined how bad things would get.

In the past few days, five of my sites have gone down (apparently owing to the Application Pool crashing). EUKHost blame the site code - even though at least one of the sites is a low-traffic, single-page, HTML-only site, which could not possibly crash the Application Pool! Nevertheless, EUKHost refuse to accept any possibility that the server is at fault - even though all five sites were on the same server...

They have also compromised the security of this server, without notifying customers of the increased risks.

Not to mention additional issues such as emails going missing...

I'm no newbie. I've been hosting web sites for 15 years - initially myself, more recently through hosting companies such as EUKHost (my business isn't 24/7, so hosting doesn't really fit into its business model.)

I've had problems with other hosting companies - I'd been using another one for about 10 years before their service level dropped so low that I decided to take my business to EUKHost instead. But EUKHost's service has fallen further in the months that I have been with them than my previous provider's did in 10 years...

[John]

Hello,

We are not attempting to censor your posts or hide your issues. If we were, we would have simply deleted the thread and banned you from the forum. Instead, we have closed your thread because there is literally no progress being made in it. The same things were being discussed over and over again, with no end in sight. We have addressed your issues in ticket format and we won't address them again on the forum, especially when you completely disregard what we tell you.

The security of the server has not been compromised. I don't wish to sound patronising, but we are more experienced with running web servers than you. Our decisions are for the good of our customers and we do not leave security holes open. Again, this has been relayed to you in your ticket. I will say it again, the server security has not been compromised.

E-mails going missing can be addressed in the ticket as well. Sufficed to say, there are many reasons why an e-mail can fail to arrive at it's destination. This could be a problem from where it's sent, the server it's receiving, or even your local connection. I suggest you work with the support department to try and find the cause.

This thread will also be closed if it starts to go the same way as the last.

[robb]

I do not disregard what you tell me. Instead, I believe that you disregard what I tell you! And you do not answer the questions that I ask you.

So I hate to have to ask yet again, but you have not explained how a low-traffic single-page HTML-only web site can crash the Application Pool. You claim that it is down to memory usage, but if you check the logs for the site in question, you will see that this could not possibly have been the case. I believe that if you actually looked at that site, you would see that there must be another explanation. I also believe that five sites hosted on the same server going down within days of one another all for the same reason points to a common cause. So we have to look at what is common: and the common factor is the server. Since you tell me you can't actually tell me what caused the Application Pool to crash, it's flabbergasting that you cannot entertain the possibility that there's a problem with ther server.

Yes, you do sound patronising. You have weakened the security of Eurofighter in the past few days (fortunately my application alerts me to the risk). Do you think you also know better than the PHP Security Consortium who say that this is a security risk?

[John]

Hello,

The Application Pool crashing is currently being looked into by our Senior Windows Technicians. This is something that is only effecting you and no other users on the server. When we receive an update from them, we will relay it to you. We have not washed our hands of this.

As for the PHP Security Consortium, take note at what they actually say.

"While it does not represent a security vulnerability, it is a security risk." It then goes on to give examples of why it is a risk and in what situations it is not a risk. Other settings and variables dictate whether it is a vulnerability/risk. With our settings, there is no known vulnerability.

As a non technical example.

If I leave my car unlocked, it's a security risk. However, if I leave my car unlocked while it's in a locked garage, surrounded by guard dogs and an armed guard, it's not a risk.

If you still feel this is a problem for you, you may feel upgrading to a VPS or a Dedicated is preferable. You can then dictate your own settings.

[robb]

Originally Posted by John

The Application Pool crashing is currently being looked into by our Senior Windows Technicians.

OK, that's good to hear. If only someone had said that instead of continually blaming the sites' code, when that clearly wasn't the problem, then I would have felt my issue was being taken seriously. Hopefully, they'll come up with something.

By the way, I had expected the last of my sites that was affected by this to be up by now too, but it still isn't...

Originally Posted by John

As for the PHP Security Consortium, take note at what they actually say.

I've read it well. And you can't possibly say that none of the PHP applications on your server (including customer applications) are vulnerable. Of course, a well written application won't be vulnerable. But then a well written application wouldn't require this less secure setting either....

[John]

Hello,

It also states various options that can be set that totally negate the risk of having global on.

[robb]

Where's that then? All I can find are bits that say "you should always develop and deploy applications with register_globals disabled", and "register_globals should always be disabled"...

[John]

We are starting to go in circles again..

"Initializing $path can mitigate this particular risk, but so does disabling register_globals." Against the only vulnerability he mentioned. The person is also talking about a Dedicated project and not a shared environment..

This really isn't what the forum is for. A forum is a place for discussion and not a place for argument. There has only been us two responding to this thread and we are no further on than what we were from the first post. You disagree with our settings, we agree with them.

You have some very simple options.

1. Upgrade to a VPS or Dedicated, where you can set your own settings.

2. Open a ticket to billing and ask for a refund on your remaining period.

3. Accept that we know what our settings should and shouldn't be.

Thread closed. Your outstanding technical issues will now only be discussed in ticket form. I urge you not to open yet another thread.