Hosting - How low can you go?

acidweb · 24-06-2001 08:51PM #1

Hi everyone!

I'm starting a new company which will provide web hosting facilities to a mainly Irish market. I have put together this hosting package and I was wondering what you think. Visit: http://www.acidwebsolutions.com/

I wanted the cost (£60/year) to be as little as possible, while not compromising the quality of the deal ie: Unlimited Webspace, 3GB Transfer, PHP4 + mySQL etc.

Looking forward to your reations!

Regards,

Peter Denham

http://www.acidwebsolutions.com/
post@acidwebsolutions.com

Nietzschean · 25-06-2001 12:33AM

himm looking at what you are offering i'm guessing linux/unix box...so that cuts out the many ASP fanatics that seem to be on theese fourms

n also 3gb/yr thats not alot if ye have any ammount of traffic/dl's on the site really...n webspace unlimited is there a limit on each file's size?...and does the 3gb/yr include ftp access?

acidweb · 25-06-2001 12:58AM

Thanks for the reply Serialkiller!

I too was an ASP fanatic until I couldn't hack taking the abuse that the PHP programmers seem to hurl at us saying how unsecure the Windows platform is etc. etc...

Are you joking? Even I wouldn't take a webhost with only 3GB/yr! I must make that clearer on the site so. It's actually 3GB/Month of bandwidth(which is quite substantial), and no that doesn't include FTP, cos there's no limit on the FTP usage.

Anyone else care to scrutinize?

Regards,

Peter Denham

http://www.acidwebsolutions.com/
post@acidwebsolutions.com

teac! · 25-06-2001 10:59AM

Originally posted by acidweb:
Thanks for the reply Serialkiller!
I too was an ASP fanatic until I couldn't hack taking the abuse that the PHP programmers seem to hurl at us saying how unsecure the Windows platform is etc. etc...

Personally I'm wondering how you can possibly give people PHP4 access on a machine that hosts your webpages.

You must have a lot of trust in your customers. I'm at odds with this problem, because it presents a dilemma, one that happens frequently in business.

For anyone not really knowing what I'm talking about I'll explain.

PHP is generally implemented as an Apache Module, i.e it's compiled into apache and the parsing of PHP files takes place IN apache (Yes, I know about DSO's, but let's keep this simple).
Now, it is safe to assume therefore that PHP runs as the user of the webserver (apache is running as user www say) This will generally give users privileges to another account (and most webpages are owned by the exact same user that apache runs at).

A workaround is to change the ownership of any files to a user other than www. However, this can cause more problems.

If www (the user) needs to be able to read them and doesn't own the files, that generally means that your files are going to have to be readable by everyone. If you're accessing databases with passwords in your PHP scripts, this is a bad idea. I've seen it happen on different places.

There are definate workarounds, using chroot or jail (http://docs.freebsd.org/44doc/papers/jail/jail.html), using groups properly, if your OS of choice supports using ACL's, or adding ACL support, using that. However these protections are non-existent in ALL web hosting providers I've seen.

Another option is to use the CGI binary version of PHP (which is more restrictive, and if people have premade PHP scripts, they have to edit them), it can mean a little more hassle, and customers want EASE OF USE.
What do you do? Give them PHP4 and be insecure or have them very restricted or not give it to them and lose out on one of the biggest reasons people choose webhosting?

Phil.

dahamsta · 25-06-2001 11:32AM

Personally I'm wondering how you can possibly give people PHP4 access on a machine that hosts your webpages.

Probably because he's a reseller for a UK company, so he doesn't have to worry about it. Anyway, PHP can be run in safe mode.

You must have a lot of trust in your customers.

You don't have to trust them, most hosting customers don't even think of playing with other people's accounts. If your terms of service are written correctly, if they *do* play with the server, you can take them to the cleaners.

PHP is generally implemented as an Apache Module, i.e it's compiled into apache and the parsing of PHP files takes place IN apache (Yes, I know about DSO's, but let's keep this simple).

A DSO is still "in" Apache. It's just loaded from a separate file when you start httpd.

What do you do?

If you want to be really secure you run the CGI binary in safe mode and use a wrapper, same as you do with Perl. That hammers busy machines though. If you want to be reasonably secure, you run it as a module in safe mode, and hope for the best.

It's a trade off, one you get when you offer customers any sort of interactivity on the server. If you want to be really secure, we'd have to teach our users how to use SC, SSH and PGP by default. Even then, it's just a different level of secuiry. Real security comes from not letting a customer into your box, ever. Not very practical, eh?

If you want to see dodgy, log into an addr.com box. They give you a *telnet* shell and you're not chrooted, you're just "warned". Now *that's* fscking dodgy.

adam

teac! · 25-06-2001 02:46PM

Originally posted by dahamsta:
A DSO is still "in" Apache. It's just loaded from a separate file when you start httpd.

What I said was "compiled in", a DSO is not compiled in, hence it's a DSO.

If you want to be really secure you run the CGI binary in safe mode and use a wrapper, same as you do with Perl. That hammers busy machines though. If you want to be reasonably secure, you run it as a module in safe mode, and hope for the best.

Yes, the CGI binary is a securer way, there's no need for a wrapper, you just use suEXEC. I mentioned that in my post, however your webserver takes a relatively large performance hit and the CGI binary is not as fully featured as your Apache Module, hence if there's features in the module that aren't in the CGI binary, customers might choose someone else over you.
(There was definately a difference in PHP3, however PHP4's CGI binary might not have this problem, however it did, less than 6 months ago anyways, have this annoying problem of printing the hash bang line at the start of an HTML page)

Secondly, the CGI binary needs a hash-bang at the start of the script, which won't be included in pre-made scripts, hence you're going to need to do some tech support for the customer. Most customers in this respect are clueless (or at least aren't experienced with this kind of methodology) so it's not too hard to loose them. Most people like ease-of-use.

My point was, do you sacrifice these customers? (especially if you REALLY need them)

Phil.

dahamsta · 25-06-2001 03:54PM

What I said was "compiled in", a DSO is not compiled in, hence it's a DSO.

Sorry, didn't mean to be anal, I was focusing on the "parsing of PHP files takes place IN apache" bit. With DSO's, it's doing the same thing because the DSO is loaded into the binary when you start httpd. You can delete the DSO if you want, PHP will still be parsed.

Yes, the CGI binary is a securer way, there's no need for a wrapper, you just use suEXEC.

If you know what you're doing.

the CGI binary is not as fully featured as your Apache Module, hence if there's features in the module that aren't in the CGI binary, customers might choose someone else over you.

Well, the only feature you'll really lose is HTTP-AUTH, isn't it? Everything else can be compiled into the CGI binary as normal.

PHP3 ... did, less than 6 months ago anyways, have this annoying problem of printing the hash bang line at the start of an HTML page) Secondly, the CGI binary needs a hash-bang at the start of the script,

Actually you don't, Apache can be configured to execute PHP scripts based on the file extension using ScriptAlias, AddType and Action. There's a fair chance that's why the CGI binary was outputting the shebang; because it was superfluous.

My point was, do you sacrifice these customers? (especially if you REALLY need them)

At the moment, I don't have any customers that require PHP and none will ever get a shell, so it doesn't worry me and I haven't really looked into it. But 99% of the major hosting companies out there are bundling PHP as part of the package, so there has to be a way around it. A quick post on the PHP mailing list will solve it pretty rapidly.

adam

teac! · 25-06-2001 05:53PM

Originally posted by dahamsta:
At the moment, I don't have any customers that require PHP and none will ever get a shell, so it doesn't worry me and I haven't really looked into it. But 99% of the major hosting companies out there are bundling PHP as part of the package, so there has to be a way around it. A quick post on the PHP mailing list will solve it pretty rapidly.

What will solve it is Apache making something like suEXEC for Apache modules, which according to the last Apachecon is on it's way (*Fingers crossed*)

Phil.

dahamsta · 25-06-2001 07:03PM

Yeah, Apache 2.0 is going to be pretty cool I reckon. You off to ApacheCon Europe?

adam

teac! · 26-06-2001 09:39AM

Naturally

irishguy · 26-06-2001 11:46AM

what type of connection is the hosting going to be held on? where is the server located?

acidweb · 26-06-2001 07:42PM

Originally posted by irishguy:
what type of connection is the hosting going to be held on? where is the server located?

200Mbit connection, hosted in UK.

Regards,

Peter Denham

http://www.acidwebsolutions.com/
post@acidwebsolutions.com

moist · 26-06-2001 10:06PM

Originally posted by teac!:

There are definate workarounds, using chroot or jail (http://docs.freebsd.org/44doc/papers/jail/jail.html)
Phil.

Have you actually read about jail ?? Its actually more like a virtual machine where you actually install a complete OS in
the jail. As a result, if you are giving a jail for every user that wants such flexible options, you will be using a good 250M before they even upload their site.

Though having said that, it does look rather interesting

Hosting - How low can you go?

Comments