Schlagwort-Archive: php

ownCloud

für escii hab ich da grad owncloud installiert. eher durch zufall fiel mir das auf, als ich die verfügbaren softwarepakete bei seinem provider durchsah. also klick-klack gleich mal installiert.

owncloud ist php-basiert und läuft auf nur einer maschine und ist damit nicht wirklich „cloud“ … klingt aber trotzdem toll. es gibt eine community und eine professionell version. die kostenlose v5 hab ich dann gleich mal drauf getan und es lief auf anhieb.

flux ein paar benutzer eingerichtet, plugins nachgeladen und die ersten samples mit ihm geshared. ging alles relativ flott und auch via webdav auf mobilen geräten recht flüssig. bei vielen benutzern kommt jedoch einiges an traffic zusammen, wenn man seine arbeitsverzeichnisse/repositories darüber synchronisieren will. aber für den augenblick war das 1 gigabyte webspace ausgenutzt. also den uralten vertrag beim provider aktualisiert und schon 10 gb gehabt. damit kann er wohl erstmal ne weile leben und brauch keine one-click-hoster mehr, wenn er seine mukke ( tracks oder mixe ) mit anderen teilen möchte.

anotherWebServer

as i patched lighthttpd to work with the servlet and the next patches discontinued over a period, i was somehow motivated to check another services, for the same reason.

i just needed the webserver to redirect and reverse proxy the requests and responses from the different instances/services to the client. no php, just port handling and some folder/path specialties. so i kicked lighty and droped nginx on the system.

the configuration wasnt that re-usable as i hoped, but the plenty examples on the web made it possible to came up with the service after two weekends. nginx performed well in the official benchmark examples and i was happy with the result, ive seen on my own on the examples i made. handling the j-session-id was done with a patch and the round-robbin worked much more smooth, then before.

the delivered pages were quick and the hunger for ram was low, so i raised the caching on the webserver a bit higher and played with different configurations between tomcat and nginx over the next weekends. i was ok with what ive seen, so the need to dive into the apache config was not a topic anymore.

tomcatServer

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 reporteer.ioioioio.eu

part 1:

reporteer.ioioioio.eu 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.