AWS applications and domain hosting

AWS applications and domain hosting

[Martin Dowie]

If I wanted to buy a domain name (e.g. www.<my_domain>.co.uk) and wanted 
to run an AWS application within it, what should I ask for when 
purchasing such a domain from a web hosting company?

Cheers

-- Martin

Re: AWS applications and domain hosting

[Adrian Knoth]

Martin Dowie <martin.dowie@btopenworld.com> wrote:

> If I wanted to buy a domain name (e.g. www.<my_domain>.co.uk) and wanted 
> to run an AWS application within it, what should I ask for when 
> purchasing such a domain from a web hosting company?

I guess your AWS application does the socket handling on its own?
Then you surely cannot use some kind of "CGI-enabled webspace",
as you usually can't bind to your application-specific ports (i.e. 80
which will probably already be in use by the hoster's apache)

You should look for something like a root-server or at least some kind
of user-mode-linux. Anything will suffice if it offers you the ability
to create own processes with own port bindings.


-- 
mail: adi@thur.de  	http://adi.thur.de	PGP: v2-key via keyserver

nichts auf Erden ist so schwer zu halten wie der Mund.

Re: AWS applications and domain hosting

[Jacob Sparre Andersen]

Martin Dowie wrote:

> If I wanted to buy a domain name (e.g. www.<my_domain>.co.uk) and
> wanted to run an AWS application within it, what should I ask for
> when purchasing such a domain from a web hosting company?

The domain name itself is a completely independent "product".

What you want from your hosting company is probably:

 a) Access to run your own network daemons.

 b) A platform you also run "at home" or access to compile your
    daemons locally.

 c) A webserver running as a proxy in front of your own daemon - and
    maybe also serving plain documents.

As long as you have access to run your own network daemons on the
server and to configure the proxy server, you shouldn't need root
access on the machine.

I run a system like that at <http://da.speling.org/random_words/>
using Apache as the front end proxy server.

Greetings,

Jacob
-- 
"Preserve wildlife, pickle a duck."

Re: AWS applications and domain hosting

[Larry Kilgallen]

In article <d9lsv1$i85$1@nwrdmz03.dmz.ncs.ea.ibs-infra.bt.com>, Martin Dowie <martin.dowie@btopenworld.com> writes:
> If I wanted to buy a domain name (e.g. www.<my_domain>.co.uk) and wanted 
> to run an AWS application within it, what should I ask for when 
> purchasing such a domain from a web hosting company?

You purchase domains from domain registrars.

You buy web hosting from web hosting companies.

Bundling the two can confuse things and reduce your flexibility.

Re: AWS applications and domain hosting

[Marius Amado Alves]

On 26 Jun 2005, at 10:36, Martin Dowie wrote:

> If I wanted to buy a domain name (e.g. www.<my_domain>.co.uk) and 
> wanted to run an AWS application within it, what should I ask for when 
> purchasing such a domain from a web hosting company?

This subject greatly interests me too, as I plan to deploy AWS-based 
websites soon. I'll add what little I know, and join the original 
poster in asking for help.

As others have told, yes, domain and hosting are formally separate. But 
many hosts offer registration, e.g. Yahoo!, and often the package price 
beats buying the two things separately.

Anyway, the information related to AWS belongs to the hosting part only.

I think that, unlike someone else said, a separate web server, or proxy 
(Apache), is neither required nor useful. The host system only has to 
open a port (?) to AWS sockets, right? And allow the AWS-based 
executable to run with the right 
parameters/permissions/ownership/priorities...

It is these (currently, to me, slightly fuzzy) elements that I'd love 
to see well described.

They are in the realm of the operating system, or at the most of some 
network software (IP?), but in any case below the level of webserving 
or Apache, right?

Re: AWS applications and domain hosting

[Jacob Sparre Andersen]

Marius Amado Alves <amado.alves@netcabo.pt> writes:

> This subject greatly interests me too, as I plan to deploy AWS-based
> websites soon. I'll add what little I know, and join the original
> poster in asking for help.
> 
> As others have told, yes, domain and hosting are formally
> separate. But many hosts offer registration, e.g. Yahoo!, and often
> the package price beats buying the two things separately.

That's not my experience.

> Anyway, the information related to AWS belongs to the hosting part
> only.

Yes.

> I think that, unlike someone else said, a separate web server, or
> proxy (Apache), is neither required nor useful. The host system only
> has to open a port (?) to AWS sockets, right? And allow the
> AWS-based executable to run with the right
> parameters/permissions/ownership/priorities...

The benefit of running through a proxy are:

 a) You don't have to implement plain handing out of static files
    yourself.

 b) Your daemon doesn't have to run as "root" (which is the case, if
    you want it to bind directly to port 80 on the system).

And a side-effect of b) is that you may be able to get a cheaper
solution since you don't need a complete (virtual) computer just for
your site.

> It is these (currently, to me, slightly fuzzy) elements that I'd
> love to see well described.

In Unix you have to be "root" to act as a server on any port in the
range 0-1023.  IIRC, Apache is started as "root", but downgrades its
privileges as soon as it has grabbed port 80.  I don't know exactly
how it is done.  Anybody who wants to put a service directly on the
network should understand how to run it with minimal privileges.

Although Apache isn't perfect, it is good enough for most of my needs,
so I can't see the point in reimplementing all of Apache, just because
I want to solve some particular problems which Apache can't handle.

Jacob
-- 
"You've got to build bypasses!"

Re: AWS applications and domain hosting

[Randy Brukardt]

"Jacob Sparre Andersen" <sparre@nbi.dk> wrote in message
news:m2mzpc20tu.fsf@hugin.crs4.it...
...
> The benefit of running through a proxy are:
>
>  a) You don't have to implement plain handing out of static files
>     yourself.

That's such a trivial task (assuming that AWS includes appropriate handling
of HTTP commands) that's it's pretty silly not to include it and avoid extra
failure points.

>  b) Your daemon doesn't have to run as "root" (which is the case, if
>     you want it to bind directly to port 80 on the system).

That must be one of the few advantages of Windows. :-) I run the AdaIC.com
server as a service under a heavily restricted user account (it does not
have permission to access most of the disk or other partitions or systems).
No special permissions changes needed.

While Apache is a fine program, if you're doing light-duty work (and almost
all web programs outside of Google are light-duty), an all-Ada solution will
perform adequately and will be much less likely to break. After all, I
believe in security by not having unused services on the system. Generalized
systems like Apache simply provide too many "features" of little value to be
safe. "Turning off" unused services via a configuration file is much less
safe (someone could rewrite the configuration file) than not having the
services around in the first place. And every additional program will
provide an additional failure point.

                        Randy.

Re: AWS applications and domain hosting

[Pascal Obry]

"Randy Brukardt" <randy@rrsoftware.com> writes:

> >  a) You don't have to implement plain handing out of static files
> >     yourself.
> 
> That's such a trivial task (assuming that AWS includes appropriate handling
> of HTTP commands) that's it's pretty silly not to include it and avoid extra
> failure points.

This is indeed one of the AWS example. A static file server is built in AWS
using a 10 lines procedure callback:

<<
   function Get (Request : in AWS.Status.Data) return AWS.Response.Data is
      URI      : constant String := AWS.Status.URI (Request);
      Filename : constant String := URI (2 .. URI'Last);
   begin
      if OS_Lib.Is_Regular_File (Filename) then
         return AWS.Response.File
           (Content_Type => AWS.MIME.Content_Type (Filename),
            Filename     => Filename);

      else
         return AWS.Response.Acknowledge
           (Messages.S404, "<p>Page '" & URI & "' Not found.");
      end if;
   end Get;
>>

This handles the 404 message too. Note that such routine is provided by AWS,
see AWS.Services.Page_Server. If this is not sufficient there is another
hight level service which also handles directory browing, see
AWS.Services.Directory.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: AWS applications and domain hosting

[Jacob Sparre Andersen]

Pascal Obry wrote:
> Randy Brukardt wrote:

> > >  a) You don't have to implement plain handing out of static
> > >     files yourself.
> > 
> > That's such a trivial task (assuming that AWS includes appropriate
> > handling of HTTP commands) that's it's pretty silly not to include
> > it and avoid extra failure points.
> 
> This is indeed one of the AWS example. A static file server is built
> in AWS using a 10 lines procedure callback:
> 
> <<
>    function Get (Request : in AWS.Status.Data) return AWS.Response.Data is
>       URI      : constant String := AWS.Status.URI (Request);
>       Filename : constant String := URI (2 .. URI'Last);
>    begin
>       if OS_Lib.Is_Regular_File (Filename) then
>          return AWS.Response.File
>            (Content_Type => AWS.MIME.Content_Type (Filename),
>             Filename     => Filename);
> 
>       else
>          return AWS.Response.Acknowledge
>            (Messages.S404, "<p>Page '" & URI & "' Not found.");
>       end if;
>    end Get;
> >>

I wasn't aware of the AWS.Response.File function.  Does this it stream
the file?  Or do you have to load it into memory first?  If AWS knows
how to stream files, my point about handing out files is clearly not
valid.

How about handling of content negotiation?  Can AWS also do that for
me?  (yes, I _could_ read the manual) Or will I get the pleasure of
implementing that myself?

My example, <http://da.speling.org/random_words/>, will continue to
run as described, since we have many different web sites on that
machine, and I wouldn't like to force the other administrators to use
AWS just because I run a small service implemented with AWS. - And
restarting the whole HTTP daemon every time I feel like tweaking my
toy isn't healthy either. -- But with what I've learnt now, I might
try to implement a proper (for my purposes) web server using AWS for
my own site.

Jacob
-- 
"Computer Science is to Science, as Plumbing is to Hydrodynamics"

Re: AWS applications and domain hosting

[Pascal Obry]

Jacob Sparre Andersen <sparre@nbi.dk> writes:

> I wasn't aware of the AWS.Response.File function.  Does this it stream
> the file?  

No this routine does not stream the file but it does not read all the file in
memory. It reads bit of it at a time and send it over. See the
AWS.Net.Buffered.

> Or do you have to load it into memory first?  If AWS knows
> how to stream files, my point about handing out files is clearly not
> valid.

It knows too. See AWS.Resources.Streams.Disk, AWS.Resources.Streams.Disk_Once,
AWS.Resources.Streams.Memory, AWS.Resources.Streams.Memory,
AWS.Resources.Streams.Memory.Zlib. Is that enough ?

A Streams.Memory read/create byte directly from memory. Disk is obvious,
Disk_Once read the file and then delete it (useful when sending over a file
created from the user for example, you really want to delete it when sent).

It is also possible to create your own stream method by deriving from
AWS.Resources.Streams...

And there is much much more ! Be sure to read the manual :)

> How about handling of content negotiation?  Can AWS also do that for
> me?  (yes, I _could_ read the manual) Or will I get the pleasure of
> implementing that myself?

Don't know what you are calling "content negotiation" ?

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: AWS applications and domain hosting

[Jacob Sparre Andersen]

Pascal Obry wrote:
> Jacob Sparre Andersen <sparre@nbi.dk> writes:

> It knows too. See AWS.Resources.Streams.Disk,
> AWS.Resources.Streams.Disk_Once, AWS.Resources.Streams.Memory,
> AWS.Resources.Streams.Memory, AWS.Resources.Streams.Memory.Zlib. Is
> that enough ?

I think so. :)

> And there is much much more ! Be sure to read the manual :)

I thought I had done that already.  It must be to long ago.

> > How about handling of content negotiation?  Can AWS also do that
> > for me?  (yes, I _could_ read the manual) Or will I get the
> > pleasure of implementing that myself?
> 
> Don't know what you are calling "content negotiation" ?

It is specified somewhere in the HTTP 1.1 RFC.  It means that the HTTP
server chooses between different documents depending on the language
and file type preferences of the client.

Jacob
-- 
"Sleep is just a cheap substitute for coffee"

Re: AWS applications and domain hosting

[Pascal Obry]

Jacob Sparre Andersen <sparre@nbi.dk> writes:

> It is specified somewhere in the HTTP 1.1 RFC.  It means that the HTTP
> server chooses between different documents depending on the language
> and file type preferences of the client.

I would say no. It does that for compressed vs. non-compressed document if the
client support it. You could certainly do the same by requesting the proper
header filed received from the client.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: AWS applications and domain hosting

[Randy Brukardt]

"Jacob Sparre Andersen" <sparre@nbi.dk> wrote in message
news:m23bqzcrew.fsf@hugin.crs4.it...
> Randy Brukardt wrote:
...
> > While Apache is a fine program, if you're doing light-duty work (and
> > almost all web programs outside of Google are light-duty), an
> > all-Ada solution will perform adequately and will be much less
> > likely to break. After all, I believe in security by not having
> > unused services on the system. Generalized systems like Apache
> > simply provide too many "features" of little value to be
> > safe. "Turning off" unused services via a configuration file is much
> > less safe (someone could rewrite the configuration file) than not
> > having the services around in the first place. And every additional
> > program will provide an additional failure point.
>
> Changing the configuration file is slightly easier than dumping in a
> modified binary - but not so much that I think it is a fair critique.
>
> Still, you're right that with a system like Apache you're more likely
> to have a few more features activated than you need. - On the other
> hand; you reduce the risk of implementing new security holes, when you
> use code more people have looked at, and my web server would still be
> off-line, if I had had to implement it using AWS instead of just
> installing and configuring Apache [1].

In one sense, I'd say it would be hard to argue. But in another sense, I
rather disagree. HTTP is a fairly simple protocol. Since there is no state,
it's pretty hard for it alone to be a security hole. Secondly, when your
application is written in Ada (and you haven't suppressed checks), the
opportunties for bugs causing trouble are quite small. Most bugs in the
AdaIC.com server simply result in a message in the main log and a connect
reset - not a security hole. So that only leaves systematic problems. For
pure file serving, the only real problem is serving files that are outside
of the web root. That isn't too hard to prevent (you do have to look for
funny sequences of ".."), and anything unusual can just be rejected (unlike
Apache's authors, I *know* that there aren't going to be any files with
names including funny characters on our web site!).

The real security problems come from the advanced stuff that you write, but
you'll have those issues in any case if you've written using AWS. (Well, the
worst problems come from Apache running Perl and PHP stuff, but you probably
won't do that.)

Of course, if you have to share the system as you mentioned, certainly use
Apache as a front-end; it's certainly better than not writing your stuff in
Ada in the first place. But if not, you can certainly run an all-Ada web
server as I do for AdaIC.com -- it runs several domains, the spotlight
server, and the Ada search engine without making much a dent in the machine.
(Only the last takes much CPU time.)

                            Randy.

Re: AWS applications and domain hosting

[Björn Persson]

Marius Amado Alves wrote:
> As others have told, yes, domain and hosting are formally separate. But 
> many hosts offer registration, e.g. Yahoo!, and often the package price 
> beats buying the two things separately.

You might want to make sure that it's you and not the hosting company 
who owns the domain, so that you can change the hosting solution without 
losing your domain name.

> I think that, unlike someone else said, a separate web server, or proxy 
> (Apache), is neither required nor useful. The host system only has to 
> open a port (?) to AWS sockets, right? And allow the AWS-based 
> executable to run with the right 
> parameters/permissions/ownership/priorities...

If we're talking web servers, we're talking HTTP. HTTP builds on TCP 
which builds on IP. TCP has the notion of ports. A port is a number that 
serves to keep separate connections distinct. Clients need to know which 
port the server is listening for connections on. HTTP normally uses port 80.

(TCP's "little sister" protocol UDP has an identical but separate set of 
ports.)

In Unixy operating systems, the kernel implements IP and TCP. 
Applications access the network through the sockets API. A program that 
wants to act as a web server opens a listening TCP socket on port 80. 
(This will fail if another process is already listening on port 80. Only 
one process at a time can use a given port number.) When traffic to port 
80 arrives, the TCP layer in the kernel sets up a connection. The 
program recieves a connection socket from its listening socket. Server 
and client can then start speaking HTTP.

To use port numbers below 1024 you must be root in Unixy systems. (There 
might be exceptions.) But programs shouldn't run as root if it can be 
avoided, because then they can do a lot of damage if anything goes 
wrong. The usual solution is to start the program as root, but as soon 
as it has opened its listening socket, the program switches to an 
unprivileged user account and runs as that user from then on. Anyway, 
you need root access to let your program use port 80.

According to what I've read about AWS, it implements HTTP and interfaces 
to the sockets API, so it doesn't need Apache. I can imagine that it 
might be useful to have a regular web server beside an AWS application, 
but then one of them will have to use a nonstandard port. Some kind of 
proxy could of course accept a connection on port 80, open another 
connection to an AWS application on another port, and forward traffic 
between them.

If your application isn't meant to be used by humans through web 
browsers, it may make more sense not to use port 80. IPP for example, 
the Internet printing protocol, is built on top of HTTP but has its own 
port � number 631.

-- 
Bj�rn Persson                              PGP key A88682FD
                    omb jor ers @sv ge.
                    r o.b n.p son eri nu

Re: AWS applications and domain hosting

[Marius Amado Alves]

Bjorn, excellent information about Unix network deamons. Thanks a lot.

> According to what I've read about AWS, it implements HTTP and 
> interfaces to the sockets API, so it doesn't need Apache.

Exactly.

> If your application isn't meant to be used by humans through web 
> browsers, it may make more sense not to use port 80. IPP for example, 
> the Internet printing protocol, is built on top of HTTP but has its 
> own port – number 631.

Human, machine, port number, irrelevant. URLs may include the port 
number. You just redirect your-cool-domain-name.net to 
your-account-at.superduper-hosting.com:12345 and get done with it.

Re: AWS applications and domain hosting

[tmoran]

> ... it may make more sense not to use port 80. ...
  If your traffic is light you might just want to run your own server on
your own computer using either a static IP address or, if dynamic, a
dynamic DNS provider (see for instance the free service from www.dyndns.org).  I do that with a specialized version of smplsrvr.
I do that with an old Windows machine connected via DSL using a modified
version of smplsrvr.  It uses a port other than 80 since it's not intended
for mass usage and the relevant web references can say www.xxx.yyy/aaa:nnnn
I also added a simple SMTP server to smplsrvr on port 25 to receive
and process text messages from my cellphone.