I am starting a new thread for the following question, because my
original "masterplan" mail has a bit too much content I think.
Is there a way to eliminate the necessity of adding virtual host
settings in both Apache/IIS and Tomcat?
And I mean in such a way, that you already have the webserver, and
want to add Railo (with Tomcat) to process cfml.
ACF works like that, and it would be great if we can accomplish such a
thing as well.
How does ACF/Jrun do it? Does it read the webserver's config file?
And is this something that we/I could build, or already exists?
I should be adding this to the JE which will be used for a default
Railo install. That'll be Tomcat right?
I will be able to put some time in this, since it would make Railo
simpler for everyone, which is the masterplan after all :-)
As a disclaimer: I already know about the regex/wildcard host option
for Resin, (and possibly Tomcat as well?), but then you still have
problems with multiple domain names for one host.
Hoping on input, kind regards,
Paul klinkenberg
CF/Jrun achieve it by a magic connector, and only having a single context.
None of the Open methods for going from Apache/IIS -> servlet engine
have the "magic stuff" that mod_jrun has.
Also, it would mean losing the benefits that Railo's multiple contexts
can provide.
But yeah, the concept of a single host config, plus being able to link
multiple domains to multiple contexts, is definitely something I'm in
favour of having (as an option; but not as only way), but it's a
question of finding someone with enough experience with JEE and
connectors and so on to be able to create it.
I've still not had a chance to look at Jordan's installers yet - don't
know if that handles modifying an existing setup, or is it only built
for initial install?
Judah
Judah
Hoogravenseweg 92, 3523 TN Utrecht
06-47474757 / pa...@ongevraagdadvies.nl
www.ongevraagdadvies.nl / www.railodeveloper.com
Paul,
Well there is the third option for the host.xml entry. Check out the wiki here:
http://wiki.getrailo.org/wiki/Tips_And_Tricks#Adding_contexts_in_Resin_3.1.9_%28without_restart%29
Then you don't have to create any change in the resin.conf and you don't have to restart the server…
Greetings from Switzerland
Gert Franz
Railo Technologies Professional Open Source
skype: gert.franz ge...@getrailo.com
+41 76 5680 231 www.getrailo.com
Hmmm…
if I read this:
http://tomcat.apache.org/tomcat-7.0-doc/config/context.html
and this:
http://tomcat.apache.org/tomcat-7.0-doc/config/host.html#Automatic%20Application%20Deployment
I guess even with Tomcat a dynamic context generation is possible. All we would need to do is to trigger any new event in IIS (like creating a new website) and create such a content.xml for it immediately. Then the double virtual host administration wouldn't be necessary anymore…
Or am I wrong?
Greetings from Switzerland
Gert Franz
Railo Technologies Professional Open Source
skype: gert.franz ge...@getrailo.com
+41 76 5680 231 www.getrailo.com
Von:
ra...@googlegroups.com [mailto:ra...@googlegroups.com] Im Auftrag von Paul
Klinkenberg
Gesendet: Freitag, 10. September 2010 00:05
An: ra...@googlegroups.com
Betreff: Re: [railo] Can we eliminate double virtual host
administration?
Hmm, maybe I am overlooking something here, since I haven't used the installers yet (I'm on mac).
Paul,
in our training we stressed contexts enough J
A web context is unique for each web root. So data sources, mappings, the railo admin become separated for all virtual hosts. In Adobe CF you DON’T HAVE THIS FEATURE! There everything is in one big context. You need something like the sandbox security which costs performance and money in order to achieve this. And it needs to be configured as well… so not a thing out of the box…
Greetings from Switzerland
Gert Franz
Railo Technologies Professional Open Source
skype: gert.franz ge...@getrailo.com
+41 76 5680 231 www.getrailo.com
Von:
ra...@googlegroups.com [mailto:ra...@googlegroups.com] Im Auftrag von Paul
Klinkenberg
Gesendet: Freitag, 10. September 2010 00:25
An: ra...@googlegroups.com
Betreff: Re: [railo] Can we eliminate double virtual host
administration?
Hi Peter,
Yeah, someone else can probably explain it better, but my
understanding is that Jrun only has a single web context shared across
all webroots.
The security/isolation of Railo comes from using multiple web
contexts, and so doing the exact same thing as Jrun would break that.
I don't know if there's some way to keep the contexts and "extend
backwards" into the web server, which might enable this - but it
currently seems the other ideas people are mentioning -having an
installer or web server trigger to create the config and refresh the
app server - might be a simpler route.
> I must have missed that thread. That's a shame. There are times like now
> when I'm addicted to checking the list, and there are times when I prefer to
> go fishing :-)
What you need is a mobile device that lets you check the list whilst
you go fishing! :)
Anyhow, here's the thread I was referring to:
http://groups.google.com/group/railo/browse_thread/thread/f2834554a16e9bc6/3126f77ae836fdd8
[I should have answered all the exam questions, shouldn't I?]
Judah
Greetings from Switzerland
Gert Franz
Railo Technologies Professional Open Source
skype: gert.franz ge...@getrailo.com
+41 76 5680 231 www.getrailo.com
Well much better than a scheduled task would be that the Event of adding a website in IIS would automatic trigger the change…
Greetings from Switzerland
Gert Franz
Railo Technologies Professional Open Source
skype: gert.franz ge...@getrailo.com
+41 76 5680 231 www.getrailo.com
Von:
ra...@googlegroups.com [mailto:ra...@googlegroups.com] Im Auftrag von Paul
Klinkenberg
Gesendet: Freitag, 10. September 2010 00:40
An: ra...@googlegroups.com
Betreff: Re: [railo] Can we eliminate double virtual host
administration?
Hi Judah, and all,
The project drives it all.
More specifically, project properties drive it all.
A script does the actual app server / web server configuration, based
on the values of various properties.
I set these properties in a properties file, and then I type things
like "server.install", or "httpd.host.install" (maybe
"server.httpd.host.install" to do "both" at once... eh, you get the
point). There's even a cheesy bat/sh menu driven deal (eventually
there will be a sweet GUI again).
Projects can share hosts, or have separate instances, or whatever-- it
is all based off of the values of various properties (even better,
it's really easy to have various "types" of builds for the same
project, that all use the same "commands", and whatever you specify on
the command line overrides the values in the property files).
It would be easy enough to hook it up to a cron job / at command for
even more automation, but really the issue here isn't so much
automatically deploying new apps, as it is restarting the server for
new hosts to be deployed, which generally means loosing user sessions.
There are several approaches to mitigate / remove that aspect of the
problem (caches, clusters, separate instances (on different IPs is
best), etc.), but then we're really off in oober-user land. =)
Anyways, for my money, scripts are the way to do lots of things based
off of "one" command, versus "listeners" or scheduled tasks.
I can go into more detail on the specifics of the current cfdistro
implementation, if anyone's that curious.
:Den
--
The thing I fear most is fear.
Michel de Montaigne
If all your sites are powered by Tomcat, you could simply tell Apache
to proxy all requests to Tomcat and preserve host headers. That way
you only have to update Tomcat's server.xml file.
It really depends what you actually need Apache to do for you.
--
Sean A Corfield -- (904) 302-SEAN
Railo Technologies, Inc. -- http://getrailo.com/
An Architect's View -- http://corfield.org/
"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood
Either way you'd need to HUP (restart) both of 'em, neh? Not that it
matters much with Apache, but servlet containers are another matter.
At least if you're utilizing different Tomcat hosts. Not sure exactly
what the advantage is... I think they still use the same VM, neh?
One of my pet peeves is folk that use the root context "/" for their
app. (99% of folks ;])
Tho Railo seems fine with mapping / to something, in the web context.
Which is super cool, IMO.
:Den
--
The world is but a perpetual see-saw.
Michel de Montaigne
I am already breeding on a plan for a Railo admin dashboard, ever
since I read your previous mail about cfdistro. I will get back to you
on that. (It's gonna be cool)
I think that your suggestion here is not addressing the question in
this thread. Which is more or less "can we improve Railo in such a
way, that installing it on an existing webserver will automatically
make all websites be powered by Railo, _without_ any extra
configuration".
Kind regards,
Paul klinkenberg
Op 10 sep 2010 om 05:53 heeft denstar <vallia...@gmail.com> het
volgende geschreven:\
Well much better than a scheduled task would be that the Event of adding a website in IIS would automatic trigger the change…
Greetings from Switzerland
Gert Franz
Railo Technologies Professional Open Source
skype: gert.franz ge...@getrailo.com
+41 76 5680 231 www.getrailo.com
<image001.jpg>
Paul
I think a directory listener is definitely something worth investigating. But you need to investigate 2 files only I suppose. And you need to locate them in your application…
If you need anything, let me know…
Greetings from Switzerland
Gert Franz
Railo Technologies Professional Open Source
skype: gert.franz ge...@getrailo.com
+41 76 5680 231 www.getrailo.com
Gesendet: Freitag, 10. September 2010 09:24
An: ra...@googlegroups.com
Sweet!
> I think that your suggestion here is not addressing the question in this
> thread. Which is more or less "can we improve Railo in such a way, that
> installing it on an existing webserver will automatically make all websites
> be powered by Railo, _without_ any extra configuration".
So they'd all use the same instance, but get auto-generated web
contexts per host?
Yeah, I was thinking from the "I don't have any websites besides
localhost, but I want to add http://myapp.internal and have it be
Railo powered".
There's a lot of variables, and not much convention due to that, so...
it's tough to write a general solution. Even with the Adobe
connector, don't you have to add something to each vhost? It's been a
while since I messed with it.
I wonder if we could do something cheesy for Apache and instead of
writing a "real" connector use something like mod_actions?
http://httpd.apache.org/docs/2.0/mod/mod_actions.html
Eh. It's an interesting problem.
:Den
--
There is no desire more natural than the desire for knowledge.
Michel de Montaigne
-Jordan
Check out the AJPv13 extensions proposal:
http://tomcat.apache.org/connectors-doc/ajp/ajpv13ext.html
Under "Proposed add-ons to AJP13", note that it states:
"Extended env vars passed from web-server to servlet engine."
Further down the page, note that these "env vars" include context
information - the kind of thing we currently have to write out when we
modify our server.xml files.
Seems to me this JK connector update just needs to happen before we can
use the JK connector how we want to, and NOT have to update the Tomcat
server.xml file each time we add a new site to IIS/Apache. Note that the
proposal also includes wildcards, like the asterisk: "*".
--
Warm regards,
Jordan Michaels
Vivio Technologies
http://www.viviotech.net/
Open BlueDragon Steering Committee
Railo Community Distributions
Money is overrated. You can see the code tho. ;-)
Judah offered to help me suss out the last bits so I can get an
official release out. I'm typing up the details for him, but mainly
it's a matter of naming things (I say, laughing, as that's one of the
Hard Things to do).
:Den
--
There is no passion so contagious as that of fear.
Michel de Montaigne
I've spent awhile learning to speak Denstar (or at least understand
it) so I'm going to try and do the final
wrangling/documenting/translating as I can. I'm really looking forward
to using cfdistro as well, so it makes it worth my while :)
Cheers,
Judah
http://www.jboss.org/mod_cluster
Nifty stuff! JBoss is bad ass.
After one major burnage (across several sites at once), I try not to
rely on cgi vars much (specifically script_path). Especially with
rewriting and proxying in the mix and whatnot...
I'm finding URLRewriteFilter, with it's rewriting of incoming and
outgoing links, a tempting solution to a lot of stuff.
Eh.
You don't really *have* to update the server.xml file with every site.
If you deploy your web apps with contexts ("/coolapp"), you can take
advantage of the built-in stuff that all the containers support for
automated WAR un/re/deployment, which leaves you modifying just your
web server*.
The stickler seems to be about adding hosts to the container, which
aren't quite the same thing as hosts in Apache or IIS.
*you can do this with cfml apps that expect to live at "/" with a
mapping for "/", but your HTML needs to be flexible-- not relying on
#cgi.script_path#, for example. Or else you use the outbound link
rewriting power of URLRewriteFilter ;).
Of course, I use the plain old AJP or HTTP proxy stuff in httpd, which
only takes one line to "connect" a httpd host with a cfml application,
versus doing the whole workers configuration stuff and whatnot with
mod_jk (which seems to be the most popular way of connecting on IIS).
So much depends on what you want to do, and expect.
:Den
--
There is no pleasure to me without communication: there is not so much
as a sprightly thought comes into my mind that it does not grieve me
to have produced alone, and that I have no one to tell it to.
Michel de Montaigne
Haha... learning to speak "Denster". =P
Okay cool. I look forward to seeing it!
Heh. Names can be rough!
So does it really copy an Apache vhost? Like, parses the config file,
sees a VirtualHost directive, and then parses that to get information?
Or maybe parses the output from -D DUMP_VHOSTS?
You can't be that crazy... :)
> which port the VHost is listening. This port setting is not available in
> tomcat it seems. Now a problem can arrise when you have the following Apache
> setup:
I'm not sure I follow. The port setting isn't available in tomcat?
How are you connecting Apache to Tomcat?
Here's the line from my Apache vhost template that connects it to the
Tomcat server (via mod_proxy http-- ajp13 is almost exactly the same):
RewriteRule ^\/(.+)\.cfm(.+)? http://@server.host@:@server.port.http@@war.contextpath@/$1.cfm$2
[P,QSA,L]
Here "server" referrers to the application server info (tomcat):
@server.host@ is the tomcat host (something like myapp.internal),
@server.port.http@ is the HTTP port Tomcat is listening on, etc..
But you can see that I'm telling it what ports to talk to the tomcat
host on. Tomcat doesn't decide it, Apache does.
> - all hosts, port 80: directory=/sites/defaultsite/. Here, the default site
> says something like "only ssl is allowed on this server. Please go to
> https://...."
> - www.site.com, port 443
> What will happen (in my tomcat setup) when you call www.site.com:80, is:
> - Apache uses the default vhost on port 80
> - Apache wants to return the default file "index.cfm"
> - Apache sends the request to Tomcat
> - tomcat recognizes the host name www.site.com in it's vhosts (meant for
> port 443 only, but does not know it)
> - tomcat will execute the index.cfm of www.site.com, an return the output to
> apache
> - apache sends the wrong content back to the user :-(
> Does anyone know how I can prevent this from happening?
I *think* what you want to do is control this in Apache.
Usually when I have a https only site, I'll redirect any requests for
http to https. I use a rewrite most times, I think, but there's
several ways to do it that prevent any content from being served from
http.
Here's what I generally use inside the port 80 vhost (the @token@
stuff are cfdistro variable placeholders-- you'd replace them with the
real values):
<VirtualHost *:80>
ServerName @httpd.host.servername@
ErrorLog @httpd.log.dir@/@distro.name@-error_log
CustomLog @httpd.log.dir@/@distro.name@-access_log common
RewriteEngine on
RewriteCond %{SERVER_PORT} !^443$
RewriteRule ^/(.*)$ https://@httpd.host.servername@/$1 [L,R]
Redirect "/" "https://@httpd.host.servername@/"
</VirtualHost>
You could modify it to only allow one page, like "please go to ssl
site here...", pretty easy.
Let me know if that's not what you meant. I'm not sure I understand
exactly what's going on.
Also, FWIW, here's what the command line for adding a vhost to tomcat
is using cfdistro:
./cfdistro.bat tomcat.configure -Dtomcat.dir=/path/to/tomcat
-Dtomcat.host=tomcat.host.name -Dwar.target.dir=/path/to/war
You could change the context path with -Dwar.contextpath=/something or
the ajp connector port with -Dtomcat.port.ajp=8109, etc..
Configuring apache is pretty similar.
All of cfdistro is pretty similar to that, actually. =]p
I know it's not automatic, but I don't really have to do it very
often, so it works pretty good for my use case. It can be automated
tho, especially since the cfantrunner tag will run cfdistro targets
from inside Railo... lol. =)
:Den
--
'Tis the sharpness of our mind that gives the edge to our pains and pleasures.
Michel de Montaigne
You wrote a parser for httpd confs? And I thought *I* was crazy! ;-)
Hrm. What if cffile is disabled, or sandboxing type stuff is going
on, or the user running CFML isn't the user running the HTTP process
and doesn't have access (assuming this is run from some CFML code)?
What are the assumptions that you're working under, what level of
control are you targeting?
> To give you (and others) some more insight, this is an extract of my
> httpd.conf (based on this blog post by Sean):
> ----------------------------------------------------------
...
I like the ifModule directives. I should do that instead of a crappy
search for the LoadModule lines.
Since you're doing your proxying outside of the vhosts, you're kinda
screwed. Not really, but sorta.
You could use URLRewriteFilter on the Tomcat side and tell it to do
stuff based on the HTTPS-ness of the request... but you're asking for
trouble by using one global proxy IMO (vs doing the proxying in the
vhosts). I guess the point here isn't about doing stuff "right", but
doing it "easy", neh?
I wonder if that mod_actions deal for adding a "handler" might be
better... even so tho, I'm thinking having the user add a line or
three to the vhost isn't so bad. I think that's even how ACF does
it-- or at least did it, IIRC.
> ------------------------------------------------------------------------
> When I call http://floorplans.local:80/, Apache will use the first
> <Virtualhost> entry, but when it proxies the request to tomcat, tomcat will
> use the 2nd <Host>, because it does not look at the port.
> I hope you now understand my question better :-)
Yeah, I see what's going on 100%. I'd recommend you go ahead and bite
the bullet and move the configuration out of the main httpd conf and
into the vhosts themselves, but I know that goes against your goal of
not having to do anything special in vhosts to leverage CFML.
I just think, especially with SSL in the mix -- which has some quirks
(you can't share IPs, cookie hacks, etc.) -- you'll be asking for hurt
if you roll with an implementation like this. Somebody will ask you
"how to I run site 1 on one instance of tomcat and site 2 on another?"
and you'll be like, "very carefully!" =)p. There's other issues too
(how do I disable CFML handling for a specific site, etc.), but it's
up to you how much maintenance ease you're willing to trade for
initial installation ease.
Anyways, I think I'll roll with "use URLRewriteFilter", as the advice
to solve this specific problem. Watch that long tail tho, my friend!
:Den
--
Virtue rejects facility to be her companion. She requires a craggy,
rough and thorny way.
Michel de Montaigne
Sounds good.
> With the tip that Todd gave, I will now try to find out if I can make a
> conditional "ProxyPassMatch" dependent on the cgi.server_port. If that is
> possible, then I guess I'm almost there...
> To be continued...
>
> Thanks for all the help btw!
No problemo! Unless I'm missing something, that configuration is
/basically/ the same as what you had.
I didn't even think about it, but it would be as easy to use a simple
rewrite condition inside apache, as it would be to use
URLRewriteFilter. Way easier, really, cuz you don't have to set
anything else up. =))
Here's one that should work with your old way of doing it (which takes
into account things like Flex and charting, BTW-- don't forget those,
like I have time and um, again).
Just stick the rewrite condition I mentioned earlier before any of
your proxy requests.
Ex:
RewriteCond %{SERVER_PORT} !^443$
RewriteRule ^/(.*\.cf[cm])$ ajp://localhost:8009/$1 [P,NC]
This says, if it's *not* a https request, pass it on to Tomcat.
Just another idea. Force be with you, man!
:Den
--
We can be knowledgable with other men's knowledge but we cannot be
wise with other men's wisdom.
Michel de Montaigne
Ahhh... I see.
> I am now going to look for a proxyPassCond or something :-)
Heh. You can match on the protocol part of the URL, so something like
<ProxyMatch "^http://.*">
Would do it for you, I think.
:Den
--
A nation may lose its liberties in a day and not miss them in a century.
Baron de Montesquieu
Basically, I *think* this is the argument from the Tomcat camp:
They could have easily added a dynamic host deal, but have chosen not
to. The reasoning being, that multiple hosts shouldn't share tomcat
instances, as if one host has a problem, the entire server has a
problem.
I guess if you don't think of each context as an app, this makes
sense. It's more JEE-centric mentality, maybe-- the various
servlets/contexts on one host sorta comprise one application.
From a CFML perspective, each context is an app, generally. One bad
context (app) can bring down the server it's contained in. So if
you're going to have multiple contexts, might as well have multiple
hosts, is my thinking. Eh. *shrug*
Anyways, it looks like the options are to:
a) add the hosts to the server.xml file, and then leverage the
host-manager servlet to dynamically add them to an (if running)
running Tomcat instance (this is what cfdistro does now)-- to do this
though, you have to add some credentials to the tomcat-users.xml file,
and you want to wrap both operations in a script of some sort.
b) write a servlet that watches the server.xml file for changes, and
then runs the code that host-manager runs (similar to the code in that
link I posted). Hell, we could get fancy and make it work like Resin,
if we wanted, watching directories y todo. Tho Resin actually fires
up individual JVMs for each host (I think, using the watchdog), which
is a pretty big difference right there. :)
c) fire up a Tomcat instance per host. Use a script to set the port
numbers dynamically. (8000 instance might be a bit much. (But this
is theoretically what Resin is doing, I think, which is a little
boggling.))
Eh. Something along those lines.
:Den
--
I am not the born; how can there be either birth or death for me?
Guru Nanak