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 loaded Apache Web server on Mac OS Mountain Lion with the command
sudo apachectl start
However, when I try to open localhost in Firefox, I get the message
Not Found: The requested URL / was not found on this server. Apache/2.2.21 (Unix) DAV/2 Server at localhost Port 80
I edited both httpd.conf and httpd.conf.default to change
#ServerName www.website.com
to
ServerName localhost
It still doesn't work. Any suggestions?
To verify that a process is listening on port 80, you can use lsof in a terminal window:
$ sudo lsof -iTCP:80 -sTCP:LISTEN
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
httpd 88 root 4u IPv6 0xffffff8018804600 0t0 TCP *:http (LISTEN)
httpd 90 _www 4u IPv6 0xffffff8018804600 0t0 TCP *:http (LISTEN)
httpd 14843 _www 4u IPv6 0xffffff8018804600 0t0 TCP *:http (LISTEN)
This will verify that you successfully enabled apache.
(I have xcode installed, but I think lsof is part of the normal install)
ADDED:
That confirms that apache is listening on port 80. The next step I would take is to look at the access logs, to see what apache logged when you requested '/' as shown in the error apache returned to your browser. This is what mine shows. Note that the http GET request is shown with the return code 200 (success):
bash-3.2# grep 'GET / ' /private/var/log/apache2/access_log
127.0.0.1 - - [12/Sep/2012:16:46:45 -0400] "GET / HTTP/1.1" 200 44
127.0.0.1 - - [12/Sep/2012:16:49:44 -0400] "GET / HTTP/1.1" 200 44
You can also confirm what url your browser is requesting by refreshing your browser window, then confirming that apache logs that new request to the access_log.
You should check the permissions on the folder specified as the "DocumentRoot" in your "httpd.conf", and allow at least read access for the Apache user (which should by "_www" by default).
Otherwise you could do a "sudo chmod 755" on the "DocumentRoot" folder.
By the way, you should only modify the "httpd.conf" file, since the "httpd.conf.default" is a default configuration that you can use if you want to restore the Apache original configuration, by simply overwriting the "httpd.conf" file with the "httpd.conf.default" file.
I suppose that you've not enabled name-based virtual hosts, since when you enable name-based virtual hosts, the document root in the main config is ignored; instead, the root for the matching hostname will be used, and if none match it will default to the first virtual host.
Finally, when you have problems, the first thing to check is always the Apache error log file.
The location of the the error log can be found by looking at the "ErrorLog" directive in the Apache configuration file.
Comment out all of the IfDefine !WEBSERVICE_ON tags, keeping the content within -- there is no WEBSERVICE on Mountain Lion.
Related
I have a server running on port 80, but I do not know what it is or where it came from. When I run
sudo lsof -i :80 | grep LISTEN
I get
httpd 80 root 5u IPv6 0x91f5a9de62859cfd 0t0 TCP *:http (LISTEN)
httpd 694 _www 5u IPv6 0x91f5a9de62859cfd 0t0 TCP *:http (LISTEN)
I have tried to enter get the process name using the PID, but all I ever get in return is "httpd" or "FOREGROUND".
When I kill the PID, the process simply restarts with a new PID. I assume I will have to stop it at launch.
How can I stop this server from running at startup?
If it helps any, I am trying to free up port 80 to use the apache server on MAMP.
This is just a guess, but it might be the built-in version of apache, being launched (& restarted) by launchd (OS X's daemon manager). It's disabled by default, but might've gotten enabled somehow. You can try disabling it with:
sudo launchctl unload -w /System/Library/LaunchDaemons/org.apache.httpd.plist
If that doesn't do it (it'll say something like "Could not find specified service"), you can check to see if it's some other launch daemon item by looking for the PID of the master process (the one running as root, not _www):
sudo launchctl list | grep <masterPID>
That won't necessarily tell you exactly what's going on, but might point you in the right direction.
Like Gordon suggested, that's the built-in version of the Apache web server.
You can stop it with
sudo apachectl stop
btw, the configuration for this webserver can be found in the /etc/apache2/httpd.conf directory.
This happens to me a lot.
As #Gordon Davisson explains it is most likely the launchdeamon process conflicting with the service you have set up.
Definitely stop the apachetl server.
sudo apachetl -k stop
Try to find all the httpd process, they should be the last ones
sudo lsof -i :80 // without grep
Then get the first process (most likely in the 1000s) should also be the lowest one.
sudo kill <firstHttpdPID>
This should kill ALL the processes running that httpd instance and then you get simply start back up your server.
Must stop it first though or it will continue running again.
Mac OSX comes bundled with Apache, however it is deactivated. You might have activated it somehow. In my case, I have previously install XAMPP and configured something in the /etc/apache2/httpd.conf that leads my port localhost:80 to leads to html page with It Works!.
TLDR, the solution is to deactivate the Apache2 server.
Go to your terminal, and type this
sudo apachetl -k stop
In my case, it returns the following:
AH00558: httpd: Could not reliably determine the server's fully qualified domain name, using Shafies-MacBook-Pro.local. Set the 'ServerName' directive globally to suppress this message
httpd (no pid file) not running
if you typed localhost on your browser, the port 80 is not active anymore and you will not see It Works! anymore.
For context, I have deleted XAMPP long time ago and not aware that my localhost:80 is still active. I am not able redirect dummy domain -- posts.com to my localhost port for my kubernetes YAML config files.
This is my ingress-srv.yaml file:
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
name: ingress-srv
annotations:
kubernetes.io/ingress.class: nginx
nginx.ingress.kubernetes.io/use-regex: 'true'
spec:
rules:
- host: posts.com
http:
paths:
- path: /?(.*)
backend:
serviceName: client-srv
servicePort: 3000
and I have tricked the operating system to redirect my posts.com to localhost:80 by adding below line in the hosts file located at /etc/hosts
127.0.0.1 posts.com
by SM
I'm trying out Valet, it looks really nice from what I've heard.
I've been trough the "whole" installation process, Valet is succesfully installed.
But when I cd into my projects file and enter valet park and browse to http://blog.dev, I get "The DNS server address of blog.dev can not be found."
I have no idea what I'm doing wrong. :)
When you run valet install it attempts to install dnsmasq. It requires sudo privileges.
You can check that it's installed and running using
brew services list
You should see something like
dnsmasq started root /Library/LaunchDaemons/homebrew.mxcl.dnsmasq.plist
You may however need to tap brew/services first
brew tap homebrew/services
If it's not there, run
brew install dnsmasq
brew services start dnsmasq
Run valet install again to set up dnsmasq and keep an eye out for any errors. What this should do is append a line to the bottom of /usr/local/etc/dnsmasq.conf similar to
conf-file=/Users/{YOURUSER}/.valet/dnsmasq.conf
/Users/{YOURUSER}/.valet/dnsmasq.conf then should contain
address=/.dev/127.0.0.1
Check that your dns server is responding to requests
dig testing.dev #127.0.0.1
You should see a response like
;; ANSWER SECTION:
testing.dev. 0 IN A 127.0.0.1
To actually ensure that your Mac knows that it should resolve *.dev using your local DNS server, it need to be told to do so. Valet also handles this for you but you can check if it's done it's job by doing the following.
Inside the directory /etc/resolver, there should be a file entitled dev with the following contents
nameserver 127.0.0.1
This creates a custom DNS resolver for *.dev and points all requests at your local DNS server.
Restart dnsmasq with either of the following commands and then give it a try again.
// this
brew services restart dnsmasq
// or this
sudo launchctl stop homebrew.mxcl.dnsmasq
sudo launchctl start homebrew.mxcl.dnsmasq
If this is all working, you should be able to ping anything.dev
ping anything.dev
PING anything.dev (127.0.0.1): 56 data bytes
64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.039 ms
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.081 ms
That ensures the DNS related bits are working.
Ultimately the question is about DNS related problems but as this started off as a here's everything you need to have tried, I'll leave this below. That said, if you're unable to ping something.dev or get an error like "The DNS server address of blog.dev can not be found." as per the OP, it's something above to do with DNS which needs resolving.
Since Caddy serves websites on port 80, you need to ensure that nothing else is running on port 80.
sudo lsof -n -i:80 | grep LISTEN
Ideally this should return caddy if valet is running as expected. You want to see the example below or nothing ideally; nothing because it means we can just start Valet.
caddy 76234 root 3u IPv6 0x4f871f962e84fa95 0t0 TCP *:http (LISTEN)
You may see other webservers, such as Apache or Nginx (and their child processes, _www and nobody) in the example below.
httpd 79 root 4u IPv6 0xf4641199930063c5 0t0 TCP *:http (LISTEN)
httpd 239 _www 4u IPv6 0xf4641199930063c5 0t0 TCP *:http (LISTEN)
nginx 4837 root 6u IPv4 0xf4641199a4e8e915 0t0 TCP 127.0.0.1:http (LISTEN)
nginx 4838 nobody 6u IPv4 0xf4641199a4e8e915 0t0 TCP 127.0.0.1:http (LISTEN)
Assuming you've installed Nginx with homebrew you can run the following to stop it.
brew services stop nginx
OSX ships with Apache installed so you can stop with with the following if it's running.
sudo apachectl stop
At this point you can likely start Valet with valet start and it'll work.
You may get a further error which is caused by PHP being installed without FPM. You can check this using
brew info php70 | grep php70-fpm
Which should yield something along the lines of
The control script is located at /usr/local/opt/php70/sbin/php70-fpm
If it doesn't appear to be installed, use the following.
brew uninstall homebrew/php/php70
brew install homebrew/php/php70 --with-fpm
valet restart
I had the same problem - getting stuck at ping foobar.dev - and fixed it by restarting my Macbook (after valet install). I am sure this is not an exact solution and I reckon there is a way to do this without restarting. Yet, it worked for me. I did not have to do any other steps.
[Edit - Additionally, before restarting I made sure to try the installing with fpm tip, and to follow all brew's suggestions upon installing php70 (tweaking the path, making sure php70 starts on system start. I cannot say whether these things helped, so probably want to try just restarting, first. If it's really just a restart that's required, or some other additional step to properly start services, I think the laravel documentation probably needs some clarification.]
I had the same problem, post installation I got stuck at pinging foo.dev.
I checked for running services.
> brew services list
Name Status User Plist
dnsmasq stopped
nginx stopped
php71 stopped
Started all the three services manually with
> brew services start dnsmasq
> brew services start nginx
> brew services start php71
Ran valet install.
Ping successfully to foo.dev
If you are a Windows user,
Perform the Acrylic Configuration then restart your adapter(Disable and Enable)
http://mayakron.altervista.org/wikibase/show.php?id=AcrylicWindows10Configuration
Worked For Me
I have an EC2 instance which is running with the following security groups:
HTTP - TCP - 80 - 0.0.0.0/0
Custom UDP Rule - UDP - 1194 - 0.0.0.0/0
SSH - TCP - 22 - 0.0.0.0/0
Custom TCP Rule - TCP - 943 - 0.0.0.0/0
HTTPS - TCP - 443 - 0.0.0.0/0
However, when I try to access http://{PUBLIC_IP} or https://{PUBLIC_IP} in the browser, I get a "{IP} refused to connect" error. I'm new to AWS. Am I missing something here? What should I do to debug?
One way to debug this particular class of problem is to use netcat in order to determine where the problem lies.
If you run netcat against port 80 on the public IP address of your instance and just get a hang (no output at all), then most likely your security group isn't allowing traffic through. Here is an example from an EC2 instance that is in a security group that doesn't allow port 80 traffic inbound:
% nc -v 55.35.300.45 80
<just hangs>
Whereas if the security group is changed to allow port 80, but the EC2 instance doesn't have any process listening on port 80, you'll get the following:
% nc -v 55.35.300.45 80
nc: connectx to 52.38.300.43 port 80 (tcp) failed: Connection refused
Given that your browser gave you a similar "connection refused", most likely the problem is that there is no web server running on your instance. You can verify this by ssh'ing into the instance and seeing if you can connect to port 80 there:
ssh ec2-user#55.35.300.45
% nc -v localhost 80
nc: connect to localhost port 80 (tcp) failed: Connection refused
If you get something like the above, you're definitely not running a webserver.
I'm not sure if it's too late to help but I was stuck with a similar issue with my test server
SG Inbound: ssh -> 22
HTTP -> 80
NACL: default allow/deny settings
but still couldn't ping to the server from my browser, then I realize there's nothing running on the server that can serve the request, and I started httpd server (webserver) and it worked.
sudo yum -y install httpd
sudo service httpd start
this way you can test the connectivity if you are playing with SGs and NACLs and of course it's not the only way, just an example if you're figuring your System N/W out.
Have you installed webserver(ngingx/apache) to serve your requests. If so please share your the config files. (So that it will help to troubleshoot)
I think the reason is probably that you did not set up a web server for your EC2 instance, because if you try to access http://{PUBLIC_IP} or https://{PUBLIC_IP}, you need to have a background server to serve the http request as #Niranj Rajasekaran said.
By the way, by simply pinging the {PUBLIC_IP}, you could see if your connection to your EC2 instance is normal or not.
In command prompt or terminal, type
ping {PUBLIC_IP}
In my case, the server was running but available on just 127.0.0.1 so it refused connections from external hosts. To see if this is your situation, you can run
netstat -an | grep <port number>
If it says 127.0.0.1:<port number> instead of 0.0.0.0:<port number>, you have this problem.
Usually there's a flag or an argument in your server code somewhere to set the host to 0.0.0.0:
app.run(host='0.0.0.0') # flask example
However, in my case, I had already set this so I thought that couldn't possibly be the issue, which is how I ended up on this thread, which asks more generally about the problem. Unfortunately, I was using docker, and had set 0.0.0.0 on the container but was mapping that explicitly to 127.0.0.1 on the host in the docker-compose port-mapping:
ports:
- "127.0.0.1:<port number>:<port number>"
Changing that line to remove the host IP specification fixed the problem upon re-deploy:
ports:
- "<port number>:<port number>"
We have to use port 80 for our server. But when I was trying to use it in Mac, it always said that the 80 is used, but I don't know which program uses it.
I searched it in Google, and someone said it's about apache, but I tried, which is not working. I found this: https://gist.github.com/kujohn/7209628 , but seems it's not working visiting our server by IP address.
I really don't know what's going on and how can I find out which program using port 80 and stop it.
Many thanks if anyone can help, I'm new using Mac. Thanks.
To find out what process is using port 80
go to Applications
open utilities.
open Activity Monitor.
click on the Memory tab,
look at the ports and the processes using them. Find port 80 and select it
go to the view on the menu bar and choose Quit process.
This will just kill the process, it will not stop a server instance that is already running from continuing to run.
(Correction: the Ports column shows the number of open ports (and files?), not the port number)
It is not clear if you are using a database management system or not and which one but one method that has worked for me using MAMP is as follows.
stop the server by using sudo apachectl stop command.
then change the port to port 80.
then restart your servers.
type the following in Terminal
sudo lsof -i -n -P | grep TCP
you will get a list - e.g. dropbox listens on 80
you can copy the output to a text editor, etc to search
On Mac ports below 1024 can only be bound by the root user.
Try launching your server as root user (with sudo), or try to use a port above 1024.
You can also try to add root permissions to your user in /etc/sudoers
# root and users in group wheel can run anything on any machine as any user
root ALL = (ALL) ALL
%admin ALL = (ALL) ALL
your_user_here ALL = (ALL) ALL
I was having this issue, apache was disabled via launchctl, but was still tying up port 80 after launch, I could start up apache and it would work, but after unloading it, I couldn't start up anything on port 80. I was using the built in web server for Python as an easy test. It would work on port 81, but not on port 80.
sudo python -m SimpleHTTPServer 80 -- wouldn't work
sudo python -m SimpleHTTPServer 81 -- would work
Here are the symptoms:
$ launchctl unload -w /System/Library/LaunchDaemons/org.apache.httpd.plist
/System/Library/LaunchDaemons/org.apache.httpd.plist: Could not find specified service
$ sudo lsof -i ':80'
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
Python 3353 root 3u IPv4 0xe455777a82799f05 0t0 TCP *:http (LISTEN)
The fix for me (after way too much searching) was simple:
sudo pfctl -F all
This flushed the packet filter, releasing port 80 (and others I assume 8080, 443, whatever ports apache might be tying up)
After that, and relaunching the python server, it came right up.
Might be Skype that is using port 80. If you have Skype installed and running try to change to a different port in the settings.
Port numbers in the range from 0 to 1023 are classified as 'well-known' and port number 80 is reserved for HTTP. Typically you have servers listening on port 80 to handle HTTP requests.
Source:
http://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers
I installed tor and privoxy on my linux 64-bit box. And uncommented the following line in /etc/privoxy/config file.
forward-socks5 / 127.0.0.1:9050 .
Then I started services for both. Now, if I run either of the following commands, I get the same IP address, which is not the real ip of PC. So I conclude both tor and privoxy are running.
curl -x 127.0.0.1:8118 curlmyip.com
curl --socks5 127.0.0.1:9050 curlmyip.com
If I use chrome with --proxy-server localhost:8118 switch, I again get the same anonymized IP address.
The problem is, I cannot use the http proxy, localhost 8118, with firefox/iceweasel. I go to Edit -> Preferences -> Advanced -> Network -> Settings and set HTTP and SSL proxies to localhost 8118. Iceweasel says "The proxy server is refusing connections"
Any solutions?
The use of browsers other than Tor Browser is recommended against. The use of privoxy / polipo has been deprecated by The Tor Project long time ago as well. The current advice is to only use Tor Browser, because only Tor Browser gives you an unified web fingerprint and you won't stand out.
I encountered a similar error where I was trying to use a combination of tor and privoxy on home PC.
The OS used was Kali Linux 2.0.
Steps to replicate issue
Installed tor
sudo apt-get install tor
Started Tor relay
tor
Validated if tor was working
netstat -atnp tor | egrep tor
In the output, observed tor output -- great.
tcp 0 0 127.0.0.1:9050 0.0.0.0:* LISTEN 2401/tor
tcp 0 0 192.168.x.x:44278 xx.xxx.xx.xx:443 ESTABLISHED 2401/tor
Installed privoxy
sudo apt-get install privoxy
Modified default privoxy config file in /etc/privoxy/config as per the instructions here under "How do I use privoxy together with tor" and included the following lines:
forward-socks4a 127.0.0.1:9050 .
forward 192.168.*.*/ .
forward 10.*.*.*/ .
forward 127.*.*.*/ .
Then started privoxy
privoxy /etc/privoxy/config
Ran the command to check if privoxy was working:
netstat -atnp | egrep privoxy
Output showed that privoxy was running (Notice tcp6 which is IPv6 - I didn't pay attention to that initially, but this was the problem):
tcp6 0 0 ::1:8118 :::* LISTEN 3881/privoxy
Then set the SSL and HTTP proxy to 127.0.0.1:8118 and I got the error when surfing internet sites, "The proxy chosen is refusing connections"
Fix:
On reading the privoxy config file carefully, the listen-address stanza displays the following information.
Some operating systems will prefer IPv6 to IPv4 addresses even
if the system has no IPv6 connectivity which is usually not
expected by the user. Some even rely on DNS to resolve
localhost which mean the "localhost" address used may not
actually be local.
**It is therefore recommended to explicitly configure the
intended IP address instead of relying on the operating
system, unless there's a strong reason not to.**
Appears that KALI was preferring to bind to the IPv6 localhost [::1] than IPv4 local host 127.0.0.1 even though I had no IPv6 connectivity.
So I changed listen-address line from
listen-address localhost:8118
to
listen-address 127.0.0.1:8118
and restarted privoxy...
pkill privoxy # kills all processes with privoxy in their name
privoxy /etc/privoxy/config
I then set the SSL, HTTP proxies to 127.0.0.1:8118 and the SOCKS proxy to 127.0.0.1:9050 (Socks 4) in ICEWEASEL. And voila! I was able to connect to internet sites.
For verification, I ran netstat and nmap which showed that privoxy was binding to IPv4 localhost IP..
> netstat -atnp | grep privoxy
tcp 0 0 127.0.0.1:8118 0.0.0.0:* LISTEN 3934/privoxy
> nmap 127.0.0.1 -p 8118
PORT STATE SERVICE
8118/tcp open privoxy
> nmap -6 localhost -p 8118
PORT STATE SERVICE
8118/tcp closed privoxy
Note:
My /etc/hosts file also has the entry for the localhost:
127.0.0.1 localhost
It works for me. Please try downloading a binary version of Firefox:
ftp://ftp.mozilla.org/pub/mozilla.org/firefox/releases/17.0.8esr/linux-i686/en-US/
Following your exact instructions above with this binary on Gentoo worked for me. I'd surmise that you have an off version of Firefox.