Schlagwort-Archive: hosting


as i had the wish to play with more then one server, i felt the need to configure the domain-name-service ( dns ) much more, then before.

my provider, where the usual webspace resides gave me access to the dns-infrastructure he had. that was cute, as i wasnt a reseller by fact and the need to maintain such things where another level of hosting configuration.

with that tool, to register a-records within the dns, i was able to build the cluster to cloud, with the ability to handle different sites for the different machines/server. i played with and other subdomains as the dataflow where handed-over between different services. several services were to handled by ip-addresses before, now i made that more niceley with names. that was a big step toward the idea of a cloud as the complexity was raising with each service and each instance.

the amount of subdomains and service-aliases raised quickly and i reduced them as i i wanted to keep the overview over the different things, that were hidden behind that curtain.


as i have the rootServer, i can try and play niceley with my own coded stuff in java, running on tomcat. as the default-webserver just having the php stuff on it, i was looking for my own machine ( or at least for the chance to deploy my stuff ) since a long time.

with no big experience in the hosting field, iam not sure to put the tomcat naked onto the web, so i decide to hide the service behind a proxy/router. after i looked into the given examples, apache could be used therefore. thats to easy, i thought and i remembered some lighthttpd from my school, that one professor took for his page.

configuring the ports and the reverse-proxy was done quite quick, but having more then one subdomain means more then a single config-file. another thing is, that i want to play with load-balancing, so the config was done in three parts.  as example, the workflow of a domain like

part 1: to localhost:80. the gateway with round-robbin load-balancing on a virtual host (server-0) in berlin and redirect to the server-1 in jena.

part 2:

redirect from port 80 on server-0 to server-1 port 80, where another lighty was running.

part 3:

redirect from port 80 to port 8080, where tomcat was running and targeting the servlet-path like http://server1:8080/reporteer/

caching on each layer for different filesizes and different file-types was done that way. as the commong filesize on the http level is mostly below 64 kilobyte ( to measure ) i passed files from the servlet between 64kb and 1mb as java-cache, smaller files on the lighty-instances, separated for images and js/css.  so, some css and some javascript ( lets say up to 8 ) per request was reasonable. a unbounded amount of images where handled by the servlet, beside tiny pictures, like thumbnails and icons.

so i felt a bit save for my tomcat, that exploits or my shity code wont run into a desaster for external incomming requests on port 80.  „the evil hacker“, who wanted to get inside the machine would have to overcome the multiple redirect-layers on the plain/vanilla web-server, to catch the tomcat. beside the fact, that i didnt used any php/cgi nor sql-engine, the chance to fail to quick was not my point anymore.

but the main aspect is, that i can run active code now on the machine. before that, i just made passive / xml based stuff with gwt to run on the vhost i had. now remote-procedure-calls ( rpc ) are possible, beside general httpRequest.