I have a problem, I had apache Solr installed and it uses localhost for access on webserver...
now I have installed Apache and startet httpd.exe and I get the warning / error:
Could not reliably determine the server’s fully qualified domain name, using 127.0.1.1 for ServerName"
when I stop solr, I can start and use localhost for apache httpd...
but I want to have the possibility to use both webservices, how can I configure Apache to do that? and get access to service not with localhost, but with another domain name or some configuration in httpd.conf
I tried to change the line "ServerName www.example.com:80" in httpd.conf file but no effect,
sorry but I'm pretty new to webservers and Apache, how should I configure that?
You have several things mixed here:
Installing Solr should in no way be related to other questions, unless it is configured to run on port 80. If that is the case, you simply can not run two services on the same port so you have to pick, or just move Solr to 8080 or whatever.
Could not reliably determine... is just a friendly warning and will not prevent any functionality, and it should disappear when you add ServerName www.example.com:80 in httpd.conf
With default settings, Apache will respond to any http request that comes to port 80, so you don't have to configure anything there (and if you want to modify that, use VirtualHost). You can achieve reaching your webserver by other hostnames by editing hosts file on your machine. If you want others to be able to do that, you have to configure DNS (which is separate issue)
Couldn't find anywhere the answer to question that bothers me for a few days:
According to Apache documentation in virtual host files I should write this:
ProxyPassMatch ^/(.*\.php(/.*)?)$ unix:/path/to/socket.sock|fcgi://127.0.0.1:9000/path/to/your/documentroot/
But Do I have to use another fcgi port for other sites? e.g.
...socket2.sock|fcgi://127.0.0.1:9001...
...socket3.sock|fcgi://127.0.0.1:9002...
Or
...socket2.sock|fcgi://127.0.0.1:9000...
...socket3.sock|fcgi://127.0.0.1:9000...
It works both ways – no errors in logs or on screen. I know that if I would use TCP not UNIX sockets I should use different port for each site (and also it would throw an error if I use the same port) but I'm not sure I understand this Apache syntax.
It all depends how you configure your workers pools for php-fpm.
On centos 7 for example, you will find a www.conf in /etc/php-fpm.d/
This is generally the configuration for port 9000.
You can use the same port for all your virtualhost without any issue.
But if by design you want to use a different port for different virtualhosts, you can just duplicate the www.conf, rename it and edit the file.
Make sure you change the name of the pool at the top. You will find the default name to be [www]. You can edit it to [your_preferred_pool_name]
Then in the listen option you can change the port to what you want.
After restarting php-fpm you will have your [www] pool and your [your_preferred_pool_name] pool.
To configure a virtualhost to use the new pool, just update the ProxyPassMatch configuration by updating the port to your newly defined port in the conf file.
But again, using the same pool (port) for all your virtualhosts should work without any issue.
So we use chef for our servers and in the process of setting up munin, the munin cookbook now requires both nginx and apache2.
We also have our own recipes for setting up sites using the web_app definition.
If the server only has nginx or apache2 it works fine but as soon as both are required in the run list the web_app definition gets called in both apache2 and nginx this of course fails because you can't have two servers running on port 80.
Without modifying the cookbooks which is bad how can I get around this or scope to only apache or nginx. Btw we need both.
There's a bit of confusion going on there... Only the apache2 cookbook has a web_app definition. The nginx cookbook uses a nginx_site definition.
That said, your issue seems to come from the fact that you have two different processes trying to listen on the same port on the same node. To fix that, you have to tell either apache or nginx to listen on a different port.
To configure apache, you have to override node[:apache][:listen_ports] to exclude 80.
For nginx, you probably have to set your virtual hosts not to listen on port 80.
I just looked through our commit logs and turns out its my own fault :-( I ported the web_app definition from apache over to port our own cookbooks from apache to nginx.... fail
EDIT: renamed web_app in the nginx recipe to nginx_app which solves the problem
I am running apache2.2 on my WinXP PC.
I want no body but a specified IP access the site.
I already use httpd.conf to deny other request.
But that's not enough, I now want to set apache to send no response, not 403.
To be simple, I want to hide my server, I don't want others know I am running a webserver.
You could bind the Apache server to localhost only. I've not tested it, but in ports.conf, you could change:
Listen 80
to
Listen 127.0.0.1:80
That would make apache bind to the IP address 127.0.0.1, which is only available from the machine itself.
This is clearly something very easy to do with a firewall, so you should try to install and configure a firewall.
On the apache side the only thing you could try is using mod_security with the "drop" action. Check this servfault answer for example. But if the connection is closed by apache an attacker could still see the connection was first accepted, so your web server is not really hidden.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I've got a customer trying to access one of my sites, and they keep getting this error > ssl_error_rx_record_too_long
They're getting this error on all browsers, all platforms. I can't reproduce the problem at all.
My server and myself are located in the USA, the customer is located in India.
I googled on the problem, and the main source seems to be that the SSL port is speaking in HTTP. I checked my server, and this is not happening. I tried the solution mentioned here, but the customer has stated it did not fix the issue.
Can anyone tell me how I can fix this, or how I can reproduce this???
THE SOLUTION
Turns out the customer had a misconfigured local proxy!
The link mentioned by Subimage was right on the money for me. It suggested changing the virtual host tag, ie, from <VirtualHost myserver.example.com:443> to <VirtualHost _default_:443>
Error code: ssl_error_rx_record_too_long
This usually means the implementation of SSL on your server is not correct. The error is usually caused by a server side problem which the server administrator will need to investigate.
Below are some things we recommend trying.
Ensure that port 443 is open and enabled on your server. This is the standard port for https communications.
If SSL is using a non-standard port then FireFox 3 can sometimes give this error. Ensure SSL is running on port 443.
If using Apache2 check that you are using port 443 for SSL. This can be done by setting the ports.conf file as follows
Listen 80
Listen 443 https
Make sure you do not have more than one SSL certificate sharing the same IP. Please ensure that all SSL certificates utilise their own dedicated IP.
If using Apache2 check your vhost config. Some users have reported changing <VirtualHost> to _default_ resolved the error.
That fixed my problem. It's rare that I google an error message and get the first hit with the right answer! :-)
In addition to the above, these are some other solutions that other folks have found were causing the issue:
Make sure that your SSL certificate is not expired
Try to specify the Cipher:
SSLCipherSuite ALL:!aNULL:!ADH:!eNULL:!LOW:!EXP:RC4+RSA:+HIGH:+MEDIUM:+SSLv3
The solution for me was that default-ssl was not enabled in apache 2.... just putting SSLEngine On
I had to execute a2ensite default-ssl and everything worked.
In my case I had to change the <VirtualHost *> back to <VirtualHost *:80> (which is the default on Ubuntu). Otherwise, the port 443 wasn't using SSL and was sending plain HTML back to the browser.
You can check whether this is your case quite easily: just connect to your server http://www.example.com:443. If you see plain HTML, your Apache is not using SSL on port 443 at all, most probably due to a VirtualHost misconfiguration.
Cheers!
In my case I had forgot to set SSLEngine On in the configuration. Like so,
<VirtualHost _default_:443>
SSLEngine On
...
</VirtualHost>
http://httpd.apache.org/docs/2.2/mod/mod_ssl.html#sslengine
If you have the error after setup a new https vhost and the config seems to be right, remember to link in sites-enabled too.
Old question, but first result in Google for me, so here's what I had to do.
Ubuntu 12.04 Desktop with Apache installed
All the configuration and mod_ssl was installed when I installed Apache, but it just wasn't linked in the right spots yet. Note: all paths below are relative to /etc/apache2/
mod_ssl is stored in ./mods-available, and the SSL site configuration is in ./sites-available, you just have to link these to their correct places in ./mods-enabled and ./sites-enabled
cd /etc/apache2
cd ./mods-enabled
sudo ln -s ../mods-available/ssl.* ./
cd ../sites-enabled
sudo ln -s ../sites-available/default-ssl ./
Restart Apache and it should work. I was trying to access https://localhost, so your results may vary for external access, but this worked for me.
Ask the user for the exact URL they're using in their browser. If they're entering https://your.site:80, they may receive the ssl_error_rx_record_too_long error.
In my case, I had the wrong IP Address in the virtual host file. The listen was 443, and the stanza was <VirtualHost 192.168.0.1:443> but the server did not have the 192.168.0.1 address!
My problem was due to a LOW MTU over a VPN connection.
netsh interface ipv4 show inter
Idx Met MTU State Name
--- --- ----- ----------- -------------------
1 4275 4294967295 connected Loopback Pseudo-Interface 1
10 4250 **1300** connected Wireless Network Connection
31 25 1400 connected Remote Access to XYZ Network
Fix:
netsh interface ipv4 set interface "Wireless Network Connection" mtu=1400
It may be an issue over a non-VPN connection also...
You might also try fixing the hosts file.
Keep the vhost file with the fully qualified domain and add the hostname in the hosts file /etc/hosts (debian)
ip.ip.ip.ip name name.domain.com
After restarting apache2, the error should be gone.
Please see this link.
I looked in all my apache log files until I found the actual error (I had changed the <VirtualHost> from _default_ to my fqdn). When I fixed this error, everything worked fine.
I had a messed up virtual host config. Remember you need one virtual host without SSL for port 80, and another one with SSL for port 443. You cannot have both in one virtual host, as the webmin-generated config tried to do.
In my case the problem was that https was unable to start correctly because Listen 443 was in "IfDefine SSL" derective, but my apache didnt start with -DSSL option. The fix was to change my apachectl script in:
$HTTPD -k $ARGV
to:
$HTTPD -k $ARGV -DSSL
Hope that helps somebody.
I had the same problem in some browser to access to my SSL site.
I have found that I had to give to fireFox the right proxy (FireFox was accessing directly to internet).
Depending of the lan configuration (Tunneling, filtering, proxy redirection), the "direct access to internet" mode for FireFox throws this error.
For me the solution was that my ddclient was not cronning properly...