How to Debug Localhost - This Site Can't Be Reached - linux

I setup LAMP on my MacOS computer using the https://getgrav.org/blog/macos-mojave-apache-upgrade-homebrew tutorial series.
It works for a month or two and then suddenly (without any changes made to config) it will stop working.
This site can’t be reached
localhost refused to connect.
ERR_CONNECTION_REFUSED
The last time this happened I gave up and re-installed from scratch. I don't want to have to do this each time it stops working.
Here is what I've tried so far this time:
jackrobson$ ps -aef | grep httpd
501 84635 459 0 5:03pm ttys000 0:00.00 grep httpd
jackrobson$ sudo apachectl -k restart
jackrobson$ tail -f /usr/local/var/log/httpd/error_log
[Sun Sep 16 14:43:22.548017 2018] [mpm_prefork:notice] [pid 74] AH00173: SIGHUP received. Attempting to restart
[Sun Sep 16 14:43:22.635379 2018] [mpm_prefork:notice] [pid 74] AH00163: Apache/2.4.34 (Unix) PHP/7.0.31 configured -- resuming normal operations
[Sun Sep 16 14:43:22.635437 2018] [core:notice] [pid 74] AH00094: Command line: '/usr/local/opt/httpd/bin/httpd -D FOREGROUND'
My /usr/local/etc/httpd/extra/httpd-vhosts.conf looks like:
<VirtualHost *:80>
DocumentRoot "/Users/jackrobson/Projects"
ServerName localhost
</VirtualHost>
As you can see, the last error was over two weeks ago. No errors today even though I'm getting the ERR_CONNECTION_REFUSED error.
Any suggestions will be greatly appreciated.

Got it working, these are the commands that I did before it worked:
jackrobson$ sudo apachectl stop
jackrobson$ sudo launchctl unload -w /System/Library/LaunchDaemons/org.apache.httpd.plist 2>/dev/null
jackrobson$ brew services restart httpd
==> Successfully started `httpd` (label: homebrew.mxcl.httpd)

Related

Intermittent Service not available Error in Elasticbeanstalk application

We are using a webserver with ElasticBeanstalk from 2019.,
the platform is
tomcat 8.5 with java8 running on 64 bit Amazon Linux. httpd as proxy
recently (from Jan 30th) we started getting Service Unavailable issues if go to the endpoint from time to time. and if we refresh 2-3 times it will get resolved on its own.
then I download full logs. under elasticbeanstalk-error_log I can see
[Mon Feb 28 10:00:58.338035 2022] [proxy:error] [pid 14882:tid 139757313533696] (13)Permission denied: AH02454: HTTP: attempt to connect to Unix domain socket /var/run/httpd/ (localhost) failed
[Mon Feb 28 10:00:58.338078 2022] [proxy_http:error] [pid 14882:tid 139757313533696] [client <private-ip-here>:12566] AH01114: HTTP: failed to make connection to backend: httpd-UDS, referer: http://<custom-end-point>/1/<name.jsp>?s=sec$$4P!&refresh=300
[Mon Feb 28 10:43:40.663468 2022] [proxy:error] [pid 14882:tid 139757120071424] (13)Permission denied: AH02454: HTTP: attempt to connect to Unix domain socket /var/run/httpd/ (localhost) failed
[Mon Feb 28 10:43:40.663518 2022] [proxy_http:error] [pid 14882:tid 139757120071424] [client <private-ip-here>:21136] AH01114: HTTP: failed to make connection to backend: httpd-UDS
repeated multiple times from Jan30th.
and when I look at access.log
I can see 503 error log exactly at the same time when permission denied error logs in elasticbeanstalk-error_log
And I looked at the running process using ps -aux | grep HTTPd and ps -aux | grep tomcat
both are running from 2019 and have no restarts.
what more I can do to troubleshoot these issuesWe are running a web application written in Java(tomcat8) hosted in AWS ElastcBeanStalk
Some weeks back we started getting 503 error randomly
When we checked the elasticbeanstalk-erorr_logs
[Thu Mar 03 13:22:12.906144 2022] [proxy:error] [pid 14882:tid 139757338711808] (13)Permission denied: AH02454: HTTP: attempt to connect to Unix domain socket /var/run/httpd/ (localhost) failed
[Thu Mar 03 13:22:12.906202 2022] [proxy_http:error] [pid 14882:tid 139757338711808] [client 172.31.17.0:61382] AH01114: HTTP: failed to make connection to backend: httpd-UDS, referer: http://our-domain.com/1/callBackLog.jsp
The error logs are suggesting connection error with backend unix socket
When we checked in /var/run/httpd/ folder, there were no unix sockets(.sock files)
But in apache httpd config
<VirtualHost *:80>
<Proxy *>
Require all granted
ProxyPass / http://localhost:8080/ retry=0
ProxyPassReverse / http://localhost:8080/
ProxyPreserveHost on
ErrorLog /var/log/httpd/elasticbeanstalk-error_log
the proxy backend is ip address not unix socket
As per the config httpd should connect to backend ip address(localhost:8080) but why is it complaining about unix socket
Have anyone faced similar issues?
============= UPDATE
The error logs are suggesting connection error with backend unix socket
When we checked in /var/run/httpd/ folder, there were no unix sockets(.sock files)
But in apache httpd config
<VirtualHost *:80>
<Proxy *>
Require all granted
ProxyPass / http://localhost:8080/ retry=0
ProxyPassReverse / http://localhost:8080/
ProxyPreserveHost on
ErrorLog /var/log/httpd/elasticbeanstalk-error_log
the proxy backend is ip address not unix socket
As per the config httpd should connect to backend ip address(localhost:8080) but why is it complaining about unix socket
Have anyone faced similar issues?

giving /var/www/site1 to www-data:www-data crashes all WP sites on server

-- See Tl;dr below for a short version --
On my ubuntu-16.04 droplet apache2 and php7 both use the user www-data. At some point all three installations of wordpress-4.7.2 seemingly without reason started asking for FTP credentials, indicating they don't have sufficient rights. Each wp instance has it's own mysql database.
I tried to solve this for /site1 with
sudo chown www-data:www-data /var/www/site1/* -R
which shouldn't change anything as this is how the permissions were set already. For whatever reason this caused the browser to return a
HTTP ERROR 500
for the sites in /var/www/site1, /var/www/site2 and /var/www/site3 – nothing works anymore.
The only way I've found to get out of this is to restore the droplet. But each time I try to get the permissions right, I end up with all sites down again.
These are the current permission settings:
drwxr-xr-x 14 root root 4096 Feb 3 XX:14 /var/
drwxrwxr-x 8 www-data www-data 4096 Mar 5 XX:27 /var/www/
drwxr-sr-x 3 www-data www-data 4096 Mar 5 XX:13 /var/www/site1/
drwxrwxr-x 3 www-data www-data 4096 Feb 25 XX:51 /var/www/site2/
drwxrwxr-x 3 www-data www-data 4096 Feb 28 XX:06 /var/www/site3/
The sudo user is member of www-data:
user1#droplet:~$ members www-data
www-data user2 user1
A freshly installed Theme on /site1 caused dozens of PHP Fatal errors like this one:
[Sun Mar 05 19:24:04.003189 2017] [:error] [pid 5632] [client 31.10.138.238:50870]
PHP Fatal error: Uncaught Error: Call to undefined function mysql_escape_string()
in /var/www/site1/html/wp-content/themes/gloria/functions.php:60\nStack trace:\n#0
/var/www/site1/html/wp-settings.php(425): include()\n#1 /var/www/bw/html/wp-config.php(89):
require_once('/var/www/site1/htm...')\n#2 /var/www/bw/html/wp-load.php(37):
require_once('/var/www/site1/htm...')\n#3 /var/www/bw/html/wp-admin/admin.php(31):
require_once('/var/www/site1/htm...')\n#4 /var/www/bw/html/wp-admin/themes.php(10):
require_once('/var/www/site1/htm...')\n#5 {main}\n thrown in
/var/www/site1/html/wp-content/themes/gloria/functions.php on line 60
After deleting the theme, /site1 went back online. I have no idea why. The first two times I ended up restoring the droplet because of
HTTP ERROR 500
this theme wasn't involved. Even though /site1 is back up, /site2 and /site3 remain stuck with
HTTP ERROR 500
Since the removal of the theme in /site1 the Apache Error Log doesn't have any suspicious entries:
[Sun Mar 05 19:56:35.456584 2017] [mpm_prefork:notice] [pid 1671] AH00171: Graceful restart requested, doing restart
[Sun Mar 05 19:56:35.662742 2017] [mpm_prefork:notice] [pid 1671] AH00163: Apache/2.4.18 (Ubuntu) configured -- resuming normal operations
[Sun Mar 05 19:56:35.662765 2017] [core:notice] [pid 1671] AH00094: Command line: '/usr/sbin/apache2'
Any ideas?
Edit: An instance of ActiveCollab in /var/www/site2/activecollab/ never stopped working during the whole issue. All connection and permission checks done by ActiveCollab for it's own files, folders and database are positive.
Tl;dr: WP1 asks for FTP, I say
sudo chown www-data:www-data /var/www/site1/* -R
WP1, WP2 and WP3 tell the browser to
HTTP ERROR 500
while ActiveCollab in a subfolder of WP2 doesn't give a sh*t and keeps running.
Try these
sudo chmod -R 774 /var/www/yourwordpressfolder
And then
sudo chown -R www-data:www-data /var/www/yourwordpress
Finally
sudo chmod -R 777 /var/www/yourwordpressfolder

Linux/Debian Apache2 mod_rewrite internal error

i have some problems to setup my mod_rewrite for my Joomla-Site.
Im using Apache 2.2.22 on Debian.
Website is on Directory: /home/web/beta/
What i did:
1) Commands:
sudo a2enmod rewrite
sudo mkdir -p /var/run/apache2
sudo chown -R www-data /var/run/apache2
sudo a2enmod actions
sudo /etc/init.d/apache2 force-reload
2) Then i setup following file: /etc/apache2/sites-enabled/000-default
<Directory /home/web/>
Options Indexes FollowSymLinks MultiViews
AllowOverride FileInfo
3) The htaccess file at path /home/web/beta/.htaccess i set:
RewriteEngine On
(I took the .htaccess from this site: http://www.joomla-security.de/downloads.html)
Ok, now the Problem.
As long as i set the AllowOverride to FileInfo i get following error message:
Internal Server Error
The server encountered an internal error or misconfiguration and was
unable to complete your request.
Please contact the server administrator, webmaster#localhost and
inform them of the time the error occurred, and anything you might
have done that may have caused the error.
More information about this error may be available in the server error
log. Apache/2.2.22 (Debian) Server at XXXXXXX.com Port 80
What i did wrong?
Can you help me please?
EDIT: Error Log:
[Wed Nov 11 19:21:56 2015] [notice] caught SIGTERM, shutting down
[Wed Nov 11 19:21:57 2015] [notice] Apache/2.2.22 (Debian) PHP/5.4.45-0+deb7u2 configured -- resuming normal operations
[Wed Nov 11 19:21:57 2015] [alert] [client XX.XX.XX.198] /home/web/beta/.htaccess: Options not allowed here
[Wed Nov 11 19:21:58 2015] [alert] [client XX.XX.XX.198] /home/web/beta/.htaccess: Options not allowed here
[Wed Nov 11 19:21:59 2015] [alert] [client XX.XX.XX.144] /home/web/beta/.htaccess: Options not allowed here
It seems, from the errors you've posted, that you are trying to use the Options directive in .htaccess. To do that, you need to add Options to the AllowOverride directive in 000-default (cf. https://httpd.apache.org/docs/2.2/mod/core.html#options).
So change:
AllowOverride FileInfo
to
AllowOverride FileInfo Options
in 000-default.
Edit:
And if the above doesn't work, try changing it to:
AllowOverride All
And if that doesn't work then it could mean that other configuration files are getting loaded after 000-default and overwrite some of the directives.

Apache/httpd /var/www/html/ .cgi scripts throw 500 internal server error

I installed a new CentOS 7 x86_64 LAMP server today.
I compiled a simple CGI script in c and i called it test.cgi, and I enabled the AddHandler for .cgi scripts. However everytime i try to load the /test.cgi page from my /var/www/html directory any simple .cgi script will throw me a 500 internal server error page.
I tested that the script is working fine from the /var/www/cgi-bin directory.
My server is running selinux and apache/httpd is using suEXEC.
EDIT: also I didn't create any extra users after the lamp installation so here I'm using root to do everything for now. However I tried to fix giving the /var/www/html directory ownership to the apache user, that didn't fix sadly.
Here's the error log, as you can see it gives me a 'Permission Denied' error:
[Mon Jul 21 15:28:14.336626 2014] [core:notice] [pid 22704] SELinux policy enabled; httpd running as context system_u:system_r:httpd_t:s0
[Mon Jul 21 15:28:14.339766 2014] [suexec:notice] [pid 22704] AH01232: suEXEC mechanism enabled (wrapper: /usr/sbin/suexec)
[Mon Jul 21 15:28:14.495631 2014] [auth_digest:notice] [pid 22704] AH01757: generating secret for digest authentication ...
[Mon Jul 21 15:28:14.498690 2014] [lbmethod_heartbeat:notice] [pid 22704] AH02282: No slotmem from mod_heartmonitor
[Mon Jul 21 15:28:14.765072 2014] [mpm_prefork:notice] [pid 22704] AH00163: Apache/2.4.6 (CentOS) OpenSSL/1.0.1e-fips PHP/5.4.16 configured -- resuming normal operations
[Mon Jul 21 15:28:14.765186 2014] [core:notice] [pid 22704] AH00094: Command line: '/usr/sbin/httpd -D FOREGROUND'
[Mon Jul 21 15:28:16.027553 2014] [cgi:error] [pid 22706] [client 192.168.0.68:52930] AH01215: (13)Permission denied: exec of '/var/www/html/index.cgi' failed
[Mon Jul 21 15:28:16.030595 2014] [cgi:error] [pid 22706] [client 192.168.0.68:52930] End of script output before headers: index.cgi
[Mon Jul 21 15:45:01.586229 2014] [mpm_prefork:notice] [pid 22704] AH00170: caught SIGWINCH, shutting down gracefully
This is my /var/www/html apache config:
<Directory "/var/www/html">
#
# Possible values for the Options directive are "None", "All",
# or any combination of:
# Indexes Includes FollowSymLinks SymLinksifOwnerMatch ExecCGI MultiViews
#
# Note that "MultiViews" must be named *explicitly* --- "Options All"
# doesn't give it to you.
#
# The Options directive is both complicated and important. Please see
# http://httpd.apache.org/docs/2.4/mod/core.html#options
# for more information.
#
Options ExecCGI FollowSymLinks
#
# AllowOverride controls what directives may be placed in .htaccess files.
# It can be "All", "None", or any combination of the keywords:
# Options FileInfo AuthConfig Limit
#
AllowOverride All
#
# Controls who can get stuff from this server.
#
Require all granted
</Directory>
And of course I activated CGI using: AddHandler cgi-script .cgi .pl
This is my simple test.c file:
#include <stdio.h>
int main(void) {
puts("Content-Type: text/html; charset=ISO-8859-1\n");
fputs("Hello, World!", stdout);
return 0;
}
The output is correctly: Content-Type: text/html; charset=ISO-8859-1\n\nHello, World!
Also i compiled it with gcc and then gave it permissions 777 to test.cgi
Do you know what I need to do to fix this?
Thanks in advance,
Zorgatone
I'm not sure if this is a viable solution for you, but I got it working by changing SELinux to permissive. Here are the steps in case you're interested.
vi /etc/selinux/config
Change the following line:
SELINUX=enforcing
to:
SELINUX=permissive
I just solved reinstalling the server and doing all over again, disabled selinux and iptables, because I have already an external firewall.
Thanks to anyone who helped me out ;)
This is most likely an SELinux issue (which Tom Sweeney answer provides a solution to use a permissive SELinux and your own accepted answer which you indicated to disable SELinux entirely). An alternative approach is to configure appropriate SELinux types for your CGI files (and possibly other policy changes).
To start off, install the SELinux Policy Management tool (if not already done):
sudo yum install policycoreutils-python
Assuming you want to permit all CGI-based files in your /var/www/html directory, you can use the following command to apply the httpd_sys_script_exec_t context to your current and future CGI files:
sudo semanage fcontext -a -t httpd_sys_script_exec_t '/var/www/html(/.*)?/.*\.cgi'
Next, restore the content for any existing CGI files:
sudo restorecon -Rv /var/www/html/
You will also need to permit Apache to allow CGI scripts to be executed using the following:
sudo setsebool -P httpd_enable_cgi 1
You should be done. Note that if your CGI scripts need to read/write content from other files in your system, you'll have to also apply the httpd_sys_rw_content_t context to those files as well (see below for an example).
Just experienced this issue attempting to install Bugzilla (which uses CGI) on a CentOS 7 (x86_64) system. The following error was observed when monitoring my httpd error log (sudo tail -f /var/log/httpd/error_log):
[cgi:error] [pid 1825] [client ...:56481] AH01215: (13)Permission denied: exec of '/var/www/html/bugzilla/index.cgi' failed
[cgi:error] [pid 1825] [client ...:56481] End of script output before headers: index.cgi
Examining the context's applied to my Bugzilla installation, I see the following:
$ ls -Z /var/www/html/bugzilla/
...
-rwxr-x---. apache apache unconfined_u:object_r:httpd_sys_content_t:s0 index.cgi
...
I then use the following commands to permit execution for Bugzilla's CGI scripts as well as access for said CGI scripts to read content inside the ./data directory:
sudo yum install policycoreutils-python
sudo semanage fcontext -a -t httpd_sys_script_exec_t '/var/www/html/bugzilla(/.*)?/.*\.cgi'
sudo semanage fcontext -a -t httpd_sys_rw_content_t '/var/www/html/bugzilla/data(/.*)?'
sudo restorecon -Rv /var/www/html/bugzilla/
sudo setsebool -P httpd_enable_cgi 1
Examining the applied context's show the desired results:
$ ls -Z /var/www/html/bugzilla/
...
-rwxr-x---. apache apache unconfined_u:object_r:httpd_sys_script_exec_t:s0 index.cgi
...
Bugzilla should be usable now. There may be additional policies to apply for all capabilities provided by Bugzilla; however, I'm unknown if any additional policies are required.
This is SELinux permission issue, it's not recommended to disable the SELinux.
Please check if your application worked in the permissive mode of SELinux then it's SELinux issue.
Find the below URL to check the exact issue and we will get blocking content from /var/log/audit.log
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/using_selinux/troubleshooting-problems-related-to-selinux_using-selinux

(13)Permission denied: access to /cgi-bin/test.cgi denied

I am trying out CGI-scripts for the first time but without success. I have read many tutorials and followed may threads in different forums but I can not make it work.
I am using a appache web server on a Fedora 10 machine.
I always have problem with
[Wed Oct 21 20:47:36 2009] [notice] SELinux policy enabled; httpd running as context unconfined_u:system_r:httpd_t:s0
[Wed Oct 21 20:47:36 2009] [notice] suEXEC mechanism enabled (wrapper: /usr/sbin/suexec)
[Wed Oct 21 20:47:36 2009] [notice] Digest: generating secret for digest authentication ...
[Wed Oct 21 20:47:36 2009] [notice] Digest: done
[Wed Oct 21 20:47:36 2009] [notice] Apache/2.2.11 (Unix) DAV/2 PHP/5.2.9 mod_ssl/2.2.11 OpenSSL/0.9.8g configured -- resuming normal operations
I need help.
This is what my environment looks like.
uname -a
Linux localhost.localdomain 2.6.27.5-117.fc10.i686 #1 SMP Tue Nov 18 12:19:59 EST 2008 i686 i686 i386 GNU/Linux
ls -l /var/www/cgi-bin/
total 36
-rwxrwxrwx 1 root root 106 2009-10-21 18:29 index.html
-rwxr-xr-x 1 root root 11089 2009-02-24 20:11 squidGuard.cgi
-rwxr-xr-x 1 root root 5720 2009-02-24 20:11 squidGuard-simple.cgi
-rwxr-xr-x 1 root root 5945 2009-02-24 20:11 squidGuard-simple-de.cgi
-rwxrwxrwx 1 root root 110 2009-10-21 17:38 test.cgi
apachectl -v
Server version: Apache/2.2.11 (Unix)
Server built: Mar 6 2009 09:12:25
perl -version
This is perl, v5.10.0 built for i386-linux-thread-multi
Copyright 1987-2007, Larry Wall
My script
cat test.cgi
#!/usr/bin/perl
print "Content-Type: text/html\n\n";
print "Hello, world!\n";
The error message I gen when I try to access the web page server "http://192.168.50.29/cgi-bin/test.cgi" looks like this:
[Wed Oct 21 21:00:27 2009] [error] [client 192.168.50.69] (13)Permission denied: access to /cgi-bin/test.cgi denied
I have added the line:
ScriptAlias /cgi-bin/ "/var/www/cgi-bin/"
to /etc/httpd/conf/httpd.conf
I just can not make it work.
Can anyone help me?
Check your os permissions for test.cgi and be sure the user or group you are using to run your apache it has read access.
EDIT - The problem is with permissions, but not with read permissions, as you are using SELinux, you need to worry about your file context. Check this thread at fedora forums, it explains quite a few options to solve your problem.
1.FIRST CHECK THE HTTPD.CONF FILE.Set the script directory as follows in the httpd.conf.
Here you'd need to make sure you find the right httpd.conf file.For example, in my Debian, the default httpd.conf is /etc/apache2/sites-avaialbe/default.
<Directory "dir_name">
Options All
AllowOverride All
Order allow,deny
Allow from all
<Directory>
OR you could just use the default /cgi-bin folder.
2.Set the execute permission for the test script.
chmod +x script_name
check your fstab if the mounted filesystem have permission to execute
UUID=xxx-xxx-xxx-xx-xx /mnt/mountpoint ext4 rw,user,exec 0 0
the exec part is important
SELinux prevented Apache from accessing the cgi script in my case.
A quick-n-dirty fix that worked for me was turning off SELinux:
vim /etc/sysconfig/selinux
set "SELINUX=disabled"
reboot

Resources