I'm using a Debian VPS on DreamHost and wanted to install a feature-rich customer issue-tracking system (not for software development like Bugzilla). OTRS made my shortlist and I followed the Installation Instructions through the "Web Server Configuration" step (/etc/init.d/apache2 restart), but the restart step reported failure. Nevertheless pgrep apache showed it was running. In fact, it turned out that although www.mysite/otrs/installer.pl was running, my regular website showed a page claiming it had no content (but when I looked in the website's folder, its content was fine, just not being served).
DreamHost Support was very helpful, but explained that they don't use the standard Debian Apache server for hosting websites and instead use their own. Specifically, the Debian server is in /etc/apache2, but the DreamHost server is in /dh/apache2. DreamHost Support determined that the OTRS installation instructions were configuring the usual Debian Apache location which somehow prioritized that server instead of the DreamHost server. They tried moving the otrs.conf file into /dh/apache2, but though the regular website was working again, the OTRS page wasn't.
Has anybody had success installing OTRS on a DreamHost VPS?
I've consulted one of our admins on this, and these are our suggestions:
You will either need to:
Adapt DreamHost's Apache build to incorporate the OTRS modifications
Get Debian Apache up and running
Both options will require an admin user and some knowledge of Linux command line and Apache management tools. You will also need to set your VPS to UNMANAGED, which means that any changes in the DH Web Panel to any of your domains will have no effect whatsoever. Just make sure the DNS records for any domains are pointing to your server. You will also need to be able to manage your own Apache configurations.
NOTE: This will also essentially mean that DreamHost support cannot and will not troubleshoot your domains. Unmanaged means unsupported in any way!
There are a few core differences between DreamHost's apache2 configuration and the default Debian build. The first issue I observe is that DreamHost's configuration does not allow for extra configuration files to be loaded in the manner that the OTRS documentation suggests. This means if choosing option 1, you will need to manually insert the OTRS directives into DreamHost's configuration files, which may prove difficult.
I would recommend moving or otherwise disabling the /dh folder entirely after setting your VPS to unmanaged. This will not allow DH-default Apache to start when the VPS starts. You may also need to remove the DH Apache startup script in /etc/rc3.d/S02httpd2 and the actual script at /etc/init.d/httpd2.
Once you have your own version of Apache running successfully, you might consider copying the VirtualHosts that were previously at /dh/apache2/apache2-ps/etc/httpd.conf into your own domain configuration files in your conf.d directory, or you can shuffle your website files around and configure your Apache to your desire.
Once you've got your own flavor of Apache running, you should be able to implement the OTRS instructions per their wiki. :)
Related
Backstory: A couple of years ago my group changed the server on which coldfusion runs to Apache instead of IIS. I changed my dev environment to run CF on Apache httpd and everything was fine. Later we changed the session variables to j2ee, but I have never been able to get j2ee to work on dev so I am still using regular session variables on dev. Lately I am getting session persistence failure on test but I can't reproduce on dev. In looking for differences in CF server settings between test and dev I discovered that test is running on Tomcat while dev is running on Apache httpd.
My problem real problem is how to get j2ee session vars to work on dev. My question right now is how do I change my server from Apache httpd to the Tomcat that is built in with CF 10? Is there a way to do this without starting over with a fresh install of CF 10 as those are the only instructions I can find?
System: Windows 7
IIS and Apache are not (for Coldfusion, anyway) application servers. They are your front-end web servers. Your 'application server' in this setup is the software running the "application" of Coldfusion via servlets, and that's Tomcat.
While it is possible to use CF's builtin Tomcat server as your front-end web server, it isn't advisable, and it's almost certainly got nothing to do with your problem. Apache is more than capable of doing what you need and a problem with J2EE session variables is going to be related either to your JVM (are you using more-or-less the same version as your production server?) or to Tomcat itself.
Think about how J2EE sessions work. A request comes in and hits your front-end server (httpd), which, presumabl through mod_proxy or mod_jk, hands that connection over to Tomcat. Until this happens, that your system is even running a JVM isn't relevant -- neither Apache nor IIS care about Java. I wouldn't go so far as to say that it's impossible for an Apache problem to be monkeying with your session variables, but it would be pretty low on my list of suspects.
Once Tomcat (and then CF) get involved, then your JVM is doing all the work, so that's where I'd look. I'd also have a look at CF logs and Tomcat logs.
To properly answer your question, though, if you want to remove Apache from the loop, you're looking at Tomcat's server.xml and web.xml in /cfusion/runtime/conf - you'd need it running on port 80 (or else reconfigure Apache to just pass all requests to Tomcat instead of only CFML, but that doesn't really do what you asked about since Apache is still involved). You'd also have to reproduce your entire Apache configuration in Tomcat, which I've never done and wouldn't recommend, but that's the direction you'd need to investigate.
Much better to work on solving your session problem. Killing Apache is just collateral damage here.
I would like to setup mod_security as a stand alone instance protecting Tomcat instances against web application attacks. Would anyone know the pros and cons of doing this via installing mod_security as an Apache module versus installing mod_security on a reverse proxy? Has anyone implemented mod_security in either of these fashions? And if so is one preferred over the other?
There's really no difference in your two options. What non reverse proxy would you install the module on to protect Tomcat?
The question doesn't really make sense as they are both the same to you.
If you already have an Apache server, then you install ModSecurity in one of two ways:
In embedded mode by installing ModSecurity as module in the existing Apache instance you already have. The advantages are that you won't have to set up a separate Apache instance, and that the ModSecurity will have access to the environment that Apache runs under (so can see environment variables for example or log to same log files).
In a reverse proxy mode. This involves setting up a separate Apache instance, with ModSecurity on it only, and funnel all requests through it, before sending on the requests to your normal Apache. The advantages here are a dedicated web server just for ModSecurity, so you will not share resources with your existing version of Apache, if it is already resource hungry. Disadvantages are that it doubles your infrastructure and the complications that brings.
Personally I prefer option 1.
However, as you want to set up a dedicated web server in front of TomCat, the two options are identical for you. The new instance of Apache (or Nginx) that you set up will be running it in embedded mode and will act as a reverse proxy to your Tomcat server.
Personally I always think it's best to run a dedicated web server like Apache in front of any app server like Tomcat - especially on a public facing website. Granted Tomcat does include a pretty good web server (called Coyote), which may serve most of your web server needs, but a dedicated web server like Apache is more geared towards serving static content and contains other features for performance and security which make it a better end point server (including the ability to run ModSecurity for example!).
And just in case there is any confusion, Apache is actually short for Apache HTTP Server, and is sometimes called Apache httpd after the process that it runs. It is Apache's most popular bit of software hence why the name gets shortened, but Apache actually have lots of bits of software (including Apache Tomcat - usually shortened just to Tomcat).
I've got a question: I came across Apache Solr as requirement for a module I'm installing and even after reading the documentation on Apache Solr's official homepage I'm still not sure whether Apache runs alongside regular Apache or does it require it own server? If it does work alongside Apache, is there any known issues/problems that I should be aware of? How would this architecture (Apache and Apache Solr) in terms of file system and serving pages? I'm sorry if the question might sound silly but I'm very new to the whole server-side programming/setup world.
You will need to install Tomcat or some other container to install Solr on a Linux box. Tomcat and Solr can be installed along side regular Apache web server, or you can use a different server.
I have done both, installed Solr on same server as well as use different server. Both work fine. It comes down to your scale, requirements, budget and other factors.
In the attached diagram1 Solr runs under Tomcat on same server as Apache web server
In the attached diagram2 Solr runs under Tomcat on different server than Apache web server. Here we have a separate server for Solr.
Let me know if you have any more questions about architecture.
I'm migrating a lot of websites from Resin 3 to Tomcat 7 (centos 4/apache 2.20) and I'm struggling to determine what type of configuration matches my requirements. In particular:
proxy_ajp vs mod_jk vs mod_proxy for passing requests to Tomcat/Railo
automating deployment of new sites
putting WEB-INF outside the site roots (to simplify cloning sites)
using apache itk with tomcat so each vhost runs as a different user and process
having a single shared railo server administrator config
support for SES URLs with no extension (ie: /path/to/page)
SSL support required
I've read a lot of howtos already but most are out of date or provide conflicting advice. I would like to see some examples from people who run many railo vhosts and deploy them automatically or programmatically. In general I'd prefer efficiency/speed over simplicity as I want to get the most out of limited resources.
I could have asked these questions separately but I want to be sure any answers take into account all the above factors (assuming the requirements are actually compatible).
firstly, check out the vivotech installers - they are a hosting company, so use their installers as your base, they are flawless. (it uses tomcat)
railo 3.3 makes it a lot easier to deploy contexts from admin, so scripting this shouldn't be that hard.
web-inf should be automatically put into a site when it is defined in tomcat
if you give each user a new context-root, then they will have their own admin
every webserver (apache/iis2k8/even tomcat) supports url-rewrite
everything supports ssl
you might also want to look at how you're going to tune your jvm's for this senario, then do some load testing to see how they fare.
drop an email to sean corfield, google railo and his name and you'll get his email.
Recently our Software Analytic provider (NETTRACKER) sent us a plugin in order to be able to capture visitors in a better way. This plugin is for Apache 1.x and Apache 2.x. They said and I quote
that since Apache Tomcat is built on Apache HTTP server the configuration of the plugin should be the same.
I have looked for a httpd.conf in our tomcat deployment but we cannot find one, the only configuration that is similar to that one is the server.xml under the /conf directory.
If someone has better information regarding these two incredible products (Apache HTTP server and Apache Tomcat) I will greatly appreciate to draw the differences.
EDIT:
In case you are curious we know that Apache Web Server and Tomcat can work together using the mod_jk option and other proxys. But this will be too complex for our deployment.
Apache Tomcat and Apache HTTP are completely different server technologies. It is impossible to use a plugin for Apache HTTP server with Tomcat.
Apache HTTP server is developed in C and so are the plug-ins. On the contrary Tomcat is now completely developed in Java. Tomcat doesn't only serve static content, but it can also serve JSP pages and servlets.
Tomcat is used for hosting Java Web Applications. It can sure serve static content - you can host a web application using only Tomcat. Secure connections are supported and the performance is also very good (comparable with the performance of HTTP server).
A plain installation of Apache serves static content. Using the appropriate plug-ins, HTTP requests can be redirected to an application server (Tomcat, JBoss, Glassfish) or a script language interpreter (PHP). With this way dynamic content can be generated. The big advantages of Apache are the numerous plug-ins available, which allows administrators to configure and monitor web sites any way they want and that is the most widespread server available. This makes it the most secure solution, since it is thoroughly tested and any discovered flaw is corrected very quickly.
The best solution would be to use Tomcat proxied by an Apache server. It isn't so difficult to set up. If you can't do this, then you can't take advantage of Apache's plug-ins.
You see this confusion all the time. Many people think that Apache is a web server where in reality it is the name of an organization that has a web server project called "The Apache HTTP Server Project". In short the web server is called HTTPD (D as in daemon or Unix process).
Tomcat is another Apache project. This project implements a Java servlet engine to serve JSP pages and servlets. Tomcat and HTTPD have nothing to do with each other. However, you can set up HTTPD and Tomcat so that they work together. This way you can have HTTPD serve all static content, do URL rewriting and much more fancy stuff that the built in Tomcat web server can't do (or can't do very well). Whenever a JSP page is requested, HTTPD will pass the request on to Tomcat. Tomcat will process the request and will hand the output back to HTTPD which in turn will send it to the client.
Apache has many interesting projects. E.g. there is also a project called Geronimo which is a Java Enterprise server (J2EE). You can e.g. choose to embed Tomcat inside Geronimo to handle requests for JSP's and servlets where Geronimo does the more enterprisy stuff (LDAP, Messaging etc.). And you guessed it probably already, you can use HTTPD as a static content server for Geronimo as well.
totally bogus. Apache httpd plugins are written in C, Tomcat is pure Java.
Tomcat is a Java servlet engine. It can be hosted under Apache or IIS or quite a number of other external facing web servers. It sounds like you may be currently running your Tomcat instance standalone...
If you serve the JSP/servlets off of port 8080 and have it do things standalone, on the same host machine that Apache is running on, this can allow you to have them loosely coupled. Having multiple web servers fielding independent requests is not recommended, especially if you want to use server-based authentication along with Apache. Typically, you have one outside facing server that shepherds everything through it... Apache does this quite well, and the plugin you mention probably relies on this type of setup (everything gets wired through Apache) for its features/capabilities, based on your brief description of it.
If you would like to serve up your Tomcat servlets under Apache, you could configure apache to forward a class of URIs to your tomcat server instances. you could achieve this type of forwarding through mod_rewrite. this is a slower option performance-wise, as it adds slight overhead on everything you server up. You could also proxy incoming requests via a CGI mechanism similarly, from Apache to Tomcat.
mod_jk will simplify deployment and increase performance for placing Tomcat into an Apache server config. It is pretty painless to configure if you follow the docs, so I am not sure what you mean by "too complex" for your deployment -- if you want Apache and have Tomcat already, it would seem only a matter of slight config changes to get mod_jk downloaded and installed.