A few newbie configuration questions
Passthedutchie
I have been having a play with Railo recently, having had a fair few
years of experience of CF (stand alone) and Apache, mainly in the
areas of configuration and administration. I have got Railo running
under Centos with Resin. Installation was tricky but is now working
fine and CF code runs without problems. However, I have a few
questions mainly around architecture and security to which I have not
been able to find the answers, hoping somebody here can help.
What is the correct way of adding a new site? In Apache I now have 1
NameVirtualHost which has 3 virtual hosts on the same IP. Do I also
need to add a new entry for each of these inside the resin.conf file?
Just configuring them at Apache level does not appear sufficient as
they ignore the Apache DocumentRoot directive and use the root-
directory location of the default site. Also, is there a way you can
automatically create these entries when the Apache entry gets added? I
am confused about what you do at application server level and what you
do at web server level.
Is it possible to relocate the WEB-INF folder one level up from the
web root? At the moment it appears to be possible to download the
contents as it lives under the web root. This would be a bit of
security problem.
Can you stop access from certain hosts to the Server Administrator?
Although I understand the benefit of each site having its own Web
Administrator, I would like to restrict individual site access to the
Server Administrator.
Apologies for all these questions, but as a relative newbie to the
Java part I am having a bit of hard time to get my head around all
this. Links to good white papers/documentation also appreciated.
Many thanks.
Sean Corfield
> What is the correct way of adding a new site?
There's lots of "correct" ways...
> In Apache I now have 1
> NameVirtualHost which has 3 virtual hosts on the same IP. Do I also
> need to add a new entry for each of these inside the resin.conf file?
If you name your webroots using a naming convention that matches the
domains, I think you can use a wildcard pattern in Resin. For Tomcat,
you have to have explicit <Host> entries for each different webroot.
Since you are proxying requests to Resin, you can actually use a
wildcard vhost in Apache so you don't need to add new entries for new
sites. I use that approach sometimes where most everything is handled
by Railo (on Tomcat in my case). You can override that with a vhost
that explicitly binds to a ServerName / ServerAlias.
> Just configuring them at Apache level does not appear sufficient as
> they ignore the Apache DocumentRoot directive and use the root-
> directory location of the default site.
Correct. The Apache DocumentRoot only matters if you choose to have
static assets served by Apache and proxy other types of requests
(which is how I normally do it since generally Apache is better at
large file serving).
> Is it possible to relocate the WEB-INF folder one level up from the
> web root?
No. Java Web Applications - which is essentially what your CFML site
is with Railo and Open BlueDragon - have WEB-INF in the webroot.
> At the moment it appears to be possible to download the
> contents as it lives under the web root. This would be a bit of
> security problem.
No. WEB-INF is special and cannot be accessed via the web. This is
fundamental to all Java Web Applications, specifically because of
security concerns.
> Can you stop access from certain hosts to the Server Administrator?
Using Apache, yes, you can block the /railo-context URLs from being
proxied under whatever conditions you need.
> Links to good white papers/documentation also appreciated.
The best documentation for your setup is going to be on the Apache
site and the Resin site. For folks using Tomcat, the Tomcat site is
the best source of documentation. This is a trade off from the world
of Adobe ColdFusion which assumes you're deploying on JRun and so all
of the documentation can come from Adobe (well, you still need to go
to the Apache site for that documentation). In the Railo / Open
BlueDragon world, you're using whichever JEE container you want and
therefore relying on that container's documentation - since Railo /
OpenBD behave much more like standard Java Web Applications.
Hope that helps?
--
Sean A Corfield -- (904) 302-SEAN
Railo Technologies US -- http://getrailo.com/
An Architect's View -- http://corfield.org/
"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood
Passthedutchie
Thanks for that lengthy reply, it has helped to answer a lot of my
questions. Not all, but hey, it wouldn't be fun without the endless
hours of research and experimentation that normally go into trying to
master a new product. I fully understand your point about Railo
behaving like a standard Java application, however, in my opinion it
does raise the bar in terms of knowledge required because I now also
need to learn my Java server of choice. I have seen lots of nice
touches in Railo already and performance looks fantastic, I just can't
help but think that a lot of people will try to use it, find the
configuration too daunting and abandon it or decide that paying Adobe
is well worth the money. All of a sudden we are in Java land and the
ease of use with which we could deploy applications in Adobe CF world
has gone.
Although there is a great community, more formal documentation would
definitely help, as would some articles that describe the basic
architecture for people who know CF but don't have a Java background.
I consider myself to be reasonably technical yet never having used
Java servers before even the basics of the configuration/architecture
are a struggle.
Kind regards
Meint
Sean Corfield
> master a new product. I fully understand your point about Railo
> behaving like a standard Java application, however, in my opinion it
> does raise the bar in terms of knowledge required because I now also
> need to learn my Java server of choice. I have seen lots of nice
Well, yes, there's some truth to that - and that's also why some folks
in the community are working on the click-click-done type installers
that a lot of CFers are used to from the Windows / Adobe world. I
think the folks leading the charge in using Railo (and OpenBD) are
folks who are more experienced with - and more comfortable with -
command lines and Linux and JEE app servers. This is fine for
expanding the CFML market out to the Java / PHP community who have
been raised on Linux and so on - but for offering a nice, easy path
for Windows-based CFers to switch to Railo / OpenBD, the
community-based installers are going to be essential.
> touches in Railo already and performance looks fantastic, I just can't
> help but think that a lot of people will try to use it, find the
> configuration too daunting and abandon it or decide that paying Adobe
> is well worth the money. All of a sudden we are in Java land and the
Or paying Railo Professional Services to help them get up and running
and teach them what they need to know to configure, tune and run a
high-performance, highly-available Railo server...? If you pay Adobe
for the server, you don't learn anything about configuration and
tuning and you may well still need to pay an expert to help you when
you hit performance problems. Why not pay someone to teach you that
knowledge so you are empowered? Just a thought.
> ease of use with which we could deploy applications in Adobe CF world
> has gone.
You only have to get the installation in place once (per server) and
then deploying applications is much the same.
A benefit of the WEB-INF-in-webroot approach is that you can simply
ZIP up your entire webroot, and deploy it on a brand new Resin /
Tomcat server with all its configuration intact (including the Railo
runtime). Of course, that's only a benefit if you're looking to
package / distribute your application - or if you are within a large
organization that is standardizing on Java deployment and then you can
just hand them a WAR file and they know what to do with it (and unlike
Adobe's WAR deployment, you don't need a license for every target
server).
I'll close out by saying something a bit controversial: part of CFML's
bad reputation out there in the greater IT world stems from its
non-standard install/deployment and the fact that many CFers don't
know much about the alternatives (e.g., standard Java WAR deployment,
JEE containers etc). By learning these skills and showing the rest of
the IT world that we do know how this stuff works, we improve the
image of CFML and we will be taken more seriously.
> I consider myself to be reasonably technical yet never having used
> Java servers before even the basics of the configuration/architecture
> are a struggle.
True, they're a struggle for everyone the first few times they have to
deal with them but Java servers are far more numerous in the greater
IT world than CF servers and it's a good skill to master. For those of
us who are experienced with Java servers, we learned what we know from
the documentation that's out there - on each Java server's site - and
trial and error (and, if we were lucky, from knowledgeable peers or
paid consultants / mentors).
Hmm, as I'm writing this (in Gmail) I notice that two of Google's ads
in the right margin are "Think you know Java?" and "Linux for
Beginners"... :)
Todd Rafferty
Michael Offner-Streit
Sean has already everything written that is importend, here only some small addional info
(see comment in text)
/micha
Passthedutchie schrieb:
Hi, I have been having a play with Railo recently, having had a fair few years of experience of CF (stand alone) and Apache, mainly in the areas of configuration and administration. I have got Railo running under Centos with Resin. Installation was tricky but is now working fine and CF code runs without problems. However, I have a few questions mainly around architecture and security to which I have not been able to find the answers, hoping somebody here can help. What is the correct way of adding a new site? In Apache I now have 1 NameVirtualHost which has 3 virtual hosts on the same IP. Do I also need to add a new entry for each of these inside the resin.conf file? Just configuring them at Apache level does not appear sufficient as they ignore the Apache DocumentRoot directive and use the root- directory location of the default site. Also, is there a way you can automatically create these entries when the Apache entry gets added? I am confused about what you do at application server level and what you do at web server level. Is it possible to relocate the WEB-INF folder one level up from the web root? At the moment it appears to be possible to download the contents as it lives under the web root. This would be a bit of security problem.
like sean has written the web-inf folder should be hidden by default by the servlet engine, in addion to protect the WEB-INF/railo folder, railo makes the following:
- railo creates a .htaccess file that deny access to the folder
- railo adds a <cfabort> at top of the file WEB-INF/railo/railo-web.xml.cfm, even when everything else fails you still can not see content of this file.
Can you stop access from certain hosts to the Server Administrator? Although I understand the benefit of each site having its own Web Administrator, I would like to restrict individual site access to the Server Administrator.
Apologies for all these questions, but as a relative newbie to the Java part I am having a bit of hard time to get my head around all this. Links to good white papers/documentation also appreciated. Many thanks.
- open the xml file where the railo servlet is configured.
for railo express this is (Jetty) this is at etc/webdefault.xml
for railo server (Resin) this is at conf/app-default.xml
for a installed WAR it is at WEB-INF/web.xml
- search for the CFML Servlet defintion looks like this
<servlet>
<servlet-name>CFMLServlet</servlet-name>
<description>CFML runtime Engine</description>
<servlet-class>railo.loader.servlet.CFMLServlet</servlet-class>
<init-param>
<param-name>railo-web-directory</param-name>
<param-value>{web-root-directory}/WEB-INF/railo/</param-value>
<description>Railo Web Directory directory</description>
</init-param>
<!-- init-param>
<param-name>railo-server-directory</param-name>
<param-value>./</param-value>
<description>directory where railo root directory is stored</description>
</init-param -->
<load-on-startup>1</load-on-startup>
</servlet>
- change the <init-param> with name "railo-web-directory" as follows
<init-param>
<param-name>railo-web-directory</param-name>
<param-value>c:/tomcat6/railo/config/webs/{web-context-hash}/</param-value>
<description>Railo Web Directory directory</description>
</init-param>
- change the path to a existing path on your system, but leave "web-context-hash" at the end of the path, railo will create a folder for every single context.
in railo server admin on the entry page you can see whitch hash belongs to whitch webcontext.
- in addion you can also relocate the server context with the following defintion
<init-param>
<param-name>railo-server-directory</param-name>
<param-value>c:/tomcat6/railo/config/server/</param-value>
<description>Configuraton directory</description>
</init-param>
-- Michael Offner-Streit CTO Railo Technologies GmbH michael...@railo.ch www.getrailo.com Mailing List (english): http://groups.yahoo.com/group/railo_talk/ Mailing List (german): http://de.groups.yahoo.com/group/railo/ Linked in: http://www.linkedin.com/e/gis/71368/0CF7D323BBC1 Issue Tracker: http://jira.jboss.org/jira/browse/RAILO Blog: http://www.railo-technologies.com/blog
Passthedutchie
to come together. Community support here is really impressive, can't
believe the speed and detail of responses!
Thanks very much, it is much appreciated.
Kind regards
Meint
denstar
Another thing people new to this method of doing stuff don't seem to
grok at first, is that the "web root" and the "application root" have
nothing to do with each other.
There is no reason at all to put things that have stuff like WEB-INF
in them, where the web server can get to them.
That (the separation) is really the only way to be "safe" (and it's
still an illusion =]).
Like, if you've got "Options None" in your httpd config, then it will
ignore the .htaccess file (so would IIS, neh?), and the cfabort will
stop nothing if CF isn't processing the request.
So just don't put the application files where the webserver can serve them. :)
The confusing & sometimes sad part is, that a lot of CF development
mixes the assets (images, CSS, etc.) in with the CFML files. Yuck.
I'm totally guilty of doing it, but still, yuck.
Heh.
|d3n
--
I think many people are terribly afraid of being demoted by the
Darwinian scheme from the role of authors and creators in their own
right into being just places where things happen in the universe.
Daniel Dennett
Sean Corfield
> Another thing people new to this method of doing stuff don't seem to
> grok at first, is that the "web root" and the "application root" have
> nothing to do with each other.
>
> There is no reason at all to put things that have stuff like WEB-INF
> in them, where the web server can get to them.
Bear in mind that the standard Java web application deployment is a
WAR that expands out to the "web root" and all the non-web-accessible
stuff is typically stored inside WEB-INF, precisely because it is a
magic directory that is not web accessible...
CFers "best practice" is often to create a deployment that is a bunch
of stuff with the webroot in a subdirectory - but that doesn't work as
a WAR file.
--
Sean A Corfield -- (904) 302-SEAN
Railo Technologies US -- http://getrailo.com/
An Architect's View -- http://corfield.org/
"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood
denstar
> On Mon, Jan 4, 2010 at 5:53 PM, denstar wrote:
>> Another thing people new to this method of doing stuff don't seem to
>> grok at first, is that the "web root" and the "application root" have
>> nothing to do with each other.
>>
>> There is no reason at all to put things that have stuff like WEB-INF
>> in them, where the web server can get to them.
>
> Bear in mind that the standard Java web application deployment is a
> WAR that expands out to the "web root" and all the non-web-accessible
> stuff is typically stored inside WEB-INF, precisely because it is a
> magic directory that is not web accessible...
Yeah, I think if you're using a JEE server as your web server you're a
lot less likely to accidentally serve out the contents of WEB-INF-- I
should have made more of a point that this is only really a concern
when you're using a separate web server.
Not that a JEE server won't pipe out CFML source as plain text too, of
course. =)
> CFers "best practice" is often to create a deployment that is a bunch
> of stuff with the webroot in a subdirectory - but that doesn't work as
> a WAR file.
Eh. A file servlet or an Ant build script with a regex can fix those
kinds of things up in a jiffy.
No, that's quite alright by me-- what bugs is the stuff, well,
touching. Messily.
"I want my string beans to be quarantined! I like a little fortress
around my mashed potatoes."
Heh. Like I'm one to talk!
But still.
:DeN
--
Every discourse, even a poetic or oracular sentence, carries with it a
system of rules for producing analogous things and thus an outline of
methodology.
Jacques Derrida
Jamie Krug
Order Deny,Allow
Deny from All
</Location>
--
You received this message because you are subscribed to the Google Groups "Railo" group.
To post to this group, send email to ra...@googlegroups.com.
To unsubscribe from this group, send email to railo+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/railo?hl=en.