Is there anyway to bind a program on Mac OS to :80 without root privilege, like on Linux for exemple having user www to be able to do so.
Any ideas ? Thanks
Is your concern that you don't want nginx running as root or that you don't have root access?
Nginx has a user config option which will drop root after binding to the port.
If you don't have root access the best solution I know of on OS X is to use pf to setup ip redirection to a non-priviliged port, however you'll still need to get someone with root access to do this.
The config for pf is stored in /etc/pf.conf - I believe that you can simply add rules to this file and reload pf for them to take effect.
rdr pass inet proto tcp from any to any port 80 -> 127.0.0.1 port 8080
rdr pass inet proto tcp from any to any port 443 -> 127.0.0.1 port 8081
Then reload pf with sudo pfctl -F all -ef /etc/pf.conf and configure nginx to listen on the ports to redirected to.
Related
I am using route 53 and an Ubuntu instance on ec2.
My domain is example.com and my web app can be found at example.com:8080/my-webapp-name
I want example.com to bring me right to my web app. How do I do this?
How to setup Route 53 for your domain is detailed in the AWS documentation
You'll need to create an A record and point it to your the IP address of your EC2 instance, I would recommend using an ELB or an Elastic IP on that EC2 instance for production.
https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record-sets-creating.html
Just change your application listening port from 8080 to 80, and after that, you should access to your application from example.com/my-web-app-name
(don't forget to open the port 80 on your ec2 firewall)
If you want access to your app without your application directory, change the home directory on your web server/virtual host to your web app directory.
You should redirect requests for port 80 to your app! iptables will work...
$ iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 8080
Ubuntu wont let any app just listen on port 80, so thats why you have to redirect. You canuse crontab to run a script with this command in it everytime the machine starts up.
I have a vagrant box with xdebug installed, running on OSX, but Im struggling to get the Atom xdebug plugin (php-debug) to connect to it.
I pasted the phpinfo(); data into the xdebug validation site and it said all was good. And you can see all the xdebug settings.
I have mapped port 9000 in the vagrant file.
config.vm.network :forwarded_port, guest: 9000, host: 9000
The vagrant box has host only network that exposes 192.168.10.100 as the IP of the server.
And I've tried all manner of different xdebug options, the ones on the ATOM plugin site suggest..
xdebug.remote_enable=1
xdebug.remote_host=127.0.0.1
xdebug.remote_connect_back=1
xdebug.remote_port=9000
xdebug.remote_handler=dbgp
xdebug.remote_mode=req
xdebug.remote_autostart=true
But that is a slightly confusing as remote_connect_back=1 means xdebug will ignore the remote_host setting - so not sure why both are in there - neither work.
I've restarted apache / php after each time I change the options, and check they are loaded with phpinfo();
If I check who is listening on port 9000
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
Atom\x20H 10656 Matt 28u IPv6 0x321cb0a96ba5b593 0t0 TCP *:cslistener (LISTEN)
VBoxHeadl 10889 Matt 19u IPv4 0x321cb0a981a71433 0t0 TCP *:cslistener (LISTEN)
You can see both vagrant (virtual box) and Atom. Although Atom is IPv6 which is odd....
But enabling the debugger in ATOM, setting a breakpoint and hitting the site, nothing happens - ATOM never connects.
Any ideas? Anyone got this to work?
But that is a slightly confusing as remote_connect_back=1 means xdebug will ignore the remote_host setting
You are correct -- that option is not needed there -- it better be set to 0
xdebug.remote_host=127.0.0.1
This is wrong (unless you will be doing debugging via SSH tunnel). It must be an IP where debug client (Atom in your case) is running. It's xdebug who connects to client and NOT other way around: https://xdebug.org/docs/remote
This also means that the IP must be as seen from that Vagrant machine. Possibly the easiest way of getting it -- look at what $_SERVER['REMOTE_ADDR'] has.
I have mapped port 9000 in the vagrant file.
config.vm.network :forwarded_port, guest: 9000, host: 9000
You do not need to expose 9000 port in Vagrant -- nobody will be connecting to it (like you do with port 80 for web server) -- it's xdebug from VM/guest OS will be connecting outside to your "real"/host OS.
If anything -- you should be allowing outgoing connections on that port instead of incoming.
If I check who is listening on port 9000
This one means that Atom is unable to receive incoming xdebug connection over TCPv4 .. which xdebug will try to use by default (unless you specify IPv6 address in xdebug.remote_host).
If anything -- collect xdebug log (xdebug.remote_log) and see where it tries to connect etc.
#LazyOne already answered this question, but issue I had was caused by antivirus (MCAfee) which was blocking incoming traffic. Maybe this will help someone in the future.
I am currently running a docker machine in local network that its IP & port is 192.168.99.100:8080
right now. I want to connect this machine from somewhere out of the local network and access it, so the best way I found is to NAT the sent request from my laptop computer to docker machine.
In other words, each request that has been sent to my laptop computer will be sent to the docker machine on its own IP and port!
I use pfctl to do this but when I check the port 8585 to find out which service is listening to this port, I can't find anything and it sounds like the requests do not arrive(get to) the destination!
I did as below:
1- csrutil disable
2- my pf role :
/etc/pf.anchors/mazafard:
rdr pass on en0 inet proto tcp from any to 192.168.20.203 port 8585 -> 192.168.99.100 port 8080
3- my pf conf
/etc/pf-mazafard.conf
rdr-anchor "forwarding"
load anchor "forwarding" from "/etc/pf.anchors/mazafard"
and
sudo pfctl -vnf /etc/pf.anchors/mazafard
pfctl: Use of -f option, could result in flushing of rules
present in the main ruleset added by the system at startup.
See /etc/pf.conf for further details.
rdr pass on en0 inet proto tcp from any to 192.168.20.203 port = 8585 -> 192.168.99.100 port 8080
and
sudo pfctl -evf /etc/pf.anchors/mazafard
fctl: Use of -f option, could result in flushing of rules
present in the main ruleset added by the system at startup.
See /etc/pf.conf for further details.
No ALTQ support in kernel
ALTQ related functions disabled
rdr pass on en0 inet proto tcp from any to 192.168.20.203 port = 8585 -> 192.168.99.100 port 8080
pfctl: pf already enabled
and
telnet 192.168.20.203 8585
Trying 192.168.20.203...
telnet: connect to address 192.168.20.203: Operation timed out
telnet: Unable to connect to remote host
My OSX v: 10.11.4
Docker version 1.9.1, build a34a1d5
Boot2Docker version 1.11.0-rc3, build
I want to open a tcp port (5432) on a mac server to remotely using sql.
I installed psql9.4 using brew.
Initially I tried:
Open /etc/pf.conf in a text editor.
Add a line like this:
pass in proto tcp from any to any port 5432
Save the file.
Load the changes (and test them) with:
sudo pfctl -vnf /etc/pf.conf
Reboot.
I used network utility to check if the port was opened. But no luck.
Then I downloaded IceFloor.
I added custom Rules:
pass on en0 net photo tcp from any to any port =5432 flags S/SA keep state
Also added a new custom service to PFLists Service Database:
service name: PSQL
ports 5432
Still no luck...
Any suggestions?
Thank you
I am currently testing if my developing environment will run on the new upcoming Mac OS 10.11 and if I can upgrade as soon as it's released. On my test machine I am currently running the Beta Preview 3. Everything seems to be running fine.
I just can get pfctl to forward my ports. I use Vagrant and Parallels Desktop to run a Debian system for my local web server. Vagrant forwards port 8080 on the host to 80 on the guest. So 127.0.0.1:8080 works fine. But in some projects I want to have the exact same domain local as it will be in production. (without the :8080) Also I just like it more. ;-)
To do that I use pfctl to forward 80 to 8080 on the host. Here are my config files:
~/port-forwarding/pf.conf
rdr-anchor "forwarding"
load anchor "forwarding" from "/Users/nick/port-forwarding/rules.conf"
~/port-forwarding/rules.conf
rdr pass on lo0 inet proto tcp from any to any port 80 -> 127.0.0.1 port 8080
rdr pass on lo0 inet proto tcp from any to any port 443 -> 127.0.0.1 port 4433
To enable it, I run:
sudo pfctl -vnf ~/port-forwarding/pf.conf
sudo pfctl -evf ~/port-forwarding/pf.conf
This gives me this:
pfctl: Use of -f option, could result in flushing of rules
present in the main ruleset added by the system at startup.
See /etc/pf.conf for further details.
rdr-anchor "forwarding" all
Loading anchor forwarding from /Users/nick/port-forwarding/rules.conf
rdr pass on lo0 inet proto tcp from any to any port = 80 -> 127.0.0.1 port 8080
rdr pass on lo0 inet proto tcp from any to any port = 443 -> 127.0.0.1 port 4433
pfctl: Use of -f option, could result in flushing of rules
present in the main ruleset added by the system at startup.
See /etc/pf.conf for further details.
No ALTQ support in kernel
ALTQ related functions disabled
rdr-anchor "forwarding" all
Loading anchor forwarding from /Users/nick/port-forwarding/rules.conf
rdr pass on lo0 inet proto tcp from any to any port = 80 -> 127.0.0.1 port 8080
rdr pass on lo0 inet proto tcp from any to any port = 443 -> 127.0.0.1 port 4433
pf enabled
logout
Saving session...completed.
sudo pfctl -s nat says:
No ALTQ support in kernel
ALTQ related functions disabled
rdr-anchor "forwarding" all
So far it looks good, I think. But it just does not work.
127.0.0.1:80 - no connection
127.0.0.1:8080 - works
I use the same files on Yosemite and it works fine there.
Does anyone know if there's been a change on how to use pfctl or if I am doing something wrong or if there's a bug which can be reported.
Thanks a lot
Nick
This only applies to OSX 10.11 - El Capitan - Public Beta 1
x-post from: https://superuser.com/questions/938999/osx-10-11-el-capitan-beta-pf-conf-behaviour-changed/943981#943981
In the latest 10.11 beta, 127.0.0.1 is blocked. The solution? Use 127.0.0.2. To do this:
First add 127.0.0.2 to the loopback alias
sudo ifconfig lo0 alias 127.0.0.2 up
Modify your pf rule to use the the new alias.
rdr pass proto tcp from any to any port 80 -> 127.0.0.2 port 8080
From the command line, without using a file:
echo "rdr pass proto tcp from any to any port {80,8080} -> 127.0.0.2 port 8080" | pfctl -Ef - <-- Be sure to add this last tick, you're piping in STDIN)