CentOS 7.3.1611
Apache httpd-2.4.6-45.el7.centos.x86_64
I need to replace the default Apache noindex page ("Testing 123..") with a config page for a dev environment.
I tried deleting it but it seems to have permanently cached itself somewhere on the server and I can't get rid of it. I've deleted /etc/httpd/conf.d/welcome.conf as well as the entire /usr/share/httpd/noindex/ directory.
I've rebooted the server and verified it's not the client (same result on different client computers and browsers).
Is there some caching mechanism responsible for this? How do I clear it?
Attempting to change Apache's noindex processing is not a good idea. A better way to do it might be redirecting requests for "/" with a LocationMatch directive in httpd.conf
<LocationMatch "^/$">
Redirect "/" "/config.php"
</LocationMatch>
Related
I have Googled around a lot looking for a working example of blocking all xmlrpc.php requests on my cpanel server. I've tried CSF option which seems to work only if the requests come from the same ip (which they do not), I've tried modsecurity option which everyone seems to think works, but it doesnt do anything, requests still come in and are processed for xmlrpc.php... Also tried apache config changes for "Files" with "deny" and all that, also does not work... requests are always still allowed and still processed....
does anyone out there have a working example of how to totally disable xmlrpc.php on all sites on a cpanel server with cloudlinux and cagefs?
I use a pre-main global include (WHM -> Service Configuration -> Apache Configuration -> Pre-Main Include -> All Versions) to block xmlrpc server-wide:
<IfModule mod_alias.c>
RedirectMatch 301 /xmlrpc.php http://127.0.0.1/
</IfModule>
I'm managing a Centos 7.7 server with apache 2.4 working fine so far. I hace SSL configured and running, and all my pages are served without problem (all of them through https).
Now I have to run a site which is badly coded and doesn't show correctly through https, because mixed content errors block css. The problem is that http is not working, there is a 301 Redirect to https that I'm unable to find in the configuration files. There are no Rewrites, Redirects or ProxyPass in the configuration files (grep -r Rewrite or Redirect in apache directory couldn't find anything), except this ones:
ProxyPassMatch ^/foo/(.*.php)$ fcgi://127.0.0.1:9000/mnt/data/foo/$1
ProxyPassMatch ^/foo2/(.*.php)$ fcgi://127.0.0.1:9000/mnt/data/foo2/
for using php7 only for this sites.
I have a default:443 and a default:80 VirtualHost and I cannot see anything strange.
Also I checked firewalld in case there is a Port redirection, whith no luck.
Any idea? Thanks in advance.
I solved it by myself. It turns out that firefox was doing nasty things, and clearing site preferences as pointed in
Firefox redirects to https
solved the issue.
I have a server server.example.com which serves Tomcat on port 80 via a ProxyPass/ProxyPassReverse to 8080 and a Drupal site on the same box at server.example.com:8001. If I enter in the port 8001 explicitly, the Drupal site behaves properly, but I need to make it accessible via server.example.com/blog so I created a ProxyPass/ProxyPassReverse for /blog http://server.example.com:8001 which serves the initial page for the Drupal site correctly, but once the form on the home page of Drupal is filled out and submitted, which POSTs to /, the site changes to the Tomcat site, presumably because the / is not relative to the current host on post :8001. How can I get the ProxyPass for /blog to remain persistent so that all subsequent requests remain within the :8001 VirtualHost (Drupal site)?
One thing I tried was with mod_rewrite:
RewriteCond %{HTTP_REFERER} /^blog/.*$
RewriteRule (.*) %{HTTP_HOST}:8001/$1 [L,P,NC]
But that did nothing at all as far as I can tell. I was hoping that if the initial request was for /blog then the referrer would be as well and I could keep requests on the :8001 virtualhost. Perhaps someone can explain why that is flawed.
The problem you are very likely running into is that the documents returned by Drupal include generated links that all reference / instead of /blog. mod_rewrite and proxypass don't do anything to the contents of documents -- they only act upon the request (or, in the case of ProxyPassReverse, on links such as Location: headers in returned content).
To make an application that normally expects to be installed as / operate on a different URL, you need either to :
(a) Configure the application to be aware of the proper base URL. Many applications include such a setting in order to support exactly the situation you have described.
(b) Install some sort of filtering proxy that can modify the content of returned documents. For Apache, mod_proxy_html is made to do exactly this. This is included natively in Apache 2.4 but may need to be installed separately for 2.2.
My problem is, that I recently set up a Tomcat7 application container with Apache2.2 Frontend. As the project is still under development I am controlling access by an IP whitelist set up in .htaccess for the domain.
I set up mod_jk via AJP13 to Tomcat, it works absolutely fine, except the fact that .htaccess doesn't block the forward for Tomcat. In other words if you enter www.mydomain.com from a "black" IP, you get forwarded to the error page but if you enter www.mydomain.com/AppContext you slip through Apache into Tomcat
I started messing with urlrewritefilter with Tomcat, but for some reason it didn't work.
I am wondering if there is any way to set up .htaccess or apache instead to block requests forwarded to Tomcat similarly to request for Apache?
Also noticed a dramatic speed decrease when using it like that, us that common when using Apache as a frontend?
.htaccess files will work only when Apache is using a <Directory> based configuration (in httpd.conf). In case of mod_jk, matching requests (as specified by JkMount directive) will simply be forwarded to the AJP connector.
Use <Location> to control access instead:
<Location "/AppContext">
Order Deny,Allow
Deny from all
Allow from .myCompany.local
</Location>
See <Location> Directive> for details.
I faced the same problem and found a solution which may solve your case too.
Use a reverse proxy server like Nginx or Squid to redirect the traffic Apache Tomcat. Both of them can use htpassword for authentication and hence, will serve your need. If you want to use Apache as frontend then backend can be nginx which in turn will redirect to Tomcat after proper authentication. It may have a performance hit, though.
https://www.digitalocean.com/community/tutorials/how-to-set-up-http-authentication-with-nginx-on-ubuntu-12-10
I've set up a host with apache to serve static pages and to use Tomcat to serve my web application (See this question). The static pages are server from
"http://myhost.com"
and the dynamic (tomcat) pages are server from
"http://myhost.com/myapp"
The mod_proxy makes sure the "http://myhost.com/myapp" are forwarded to tomcat server running on "http://myhost.com:8080".
The problem is that now you get the standard Tomcat introduction page on "http://myhost.com/myapp" but if you click on a local link (e.g. 'Status') on the left, it generates an URL
"http://myhost.com/manager/status" while it should generate: "http://myhost.com/myapp/manager/status"
(The same is true for webapps installed under tomcat)
What should be changed in my configuration (apache, tomcat?) to redirect my tomcat links to the right place?
Have you set the ProxyPassReverse setting in your httpd.conf. This will overwrite the HTTP Header an you'll get to the correct request on the side of tomcat.
Your URLs are mapped from:
http://myhost.com/myapp -> http://myhost.com:8080
This means that accessing the above URL will be mapped to the ROOT application in Tomcat. The ROOT application will generate pages that contain links from Tomcat's root context.
In other words, if you go to:
http://myhost.com:8080
you will get a page that contains links to
http://myhost.com:8080/manager/status
This link will work. However when that page is given back to a browser that requested it via Apache, the full URL then looks like: http://myhost.com/manager/status
I assume that you intend to deploy an application called 'myapp' to Tomcat? If that is the case the Tomcat URL for this app will be
http://myhost.com:8080/myapp
Which will also work be mapped correctly when accessed via Apache.
If you absolutely must access Tomcats root application in this way you'll have to rewrite the URLs it outputs in the pages it returns.
I've had the most success with mod_proxy_ajp. It requires mod_proxy, but works over ajp. Using it instead, your conf file looks similar
ProxyPass / ajp://localhost:8009/
See my similar question and also the answer to this question. The only fault in mod_proxy_ajp that I've found is that if I need to restart tomcat I have to force an apache restart too.