Opened 16 years ago
Closed 16 years ago
Last modified 16 years ago
#131 closed task (fixed)
Open Firewall to rsync (tcp port 873) traffic
|Reported by:||warmerdam||Owned by:||sbarnes|
In order to use rsync to anonymously copy data from download.osgeo.org to test.osgeo.net nightly, I would like to have port 873 opened on the firewall. However, I don't know how to do this. Can an OSGeo SAC "firewall admin" take care of this?
Change History (9)
comment:1 by , 16 years ago
comment:2 by , 16 years ago
|Status:||new → assigned|
I've created the ticket with peer1 to open port 873.
comment:3 by , 16 years ago
How long do such tickets normally take to be acted on? It's a bit frustrating that we have a "very tight" firewall, no direct means of management, and "variable speed" service from peer1 to make changes. I presume in an emergency we could put a high priority on such a ticket to get it resolved quickly, right?
comment:4 by , 16 years ago
|Status:||assigned → closed|
My apologies. I thought i had closed this ticket.
Peer1 is quick acting on tickets...the delay was my fault.
Port 873 is open on the firewall.
comment:5 by , 16 years ago
|Status:||closed → reopened|
No problem. Actually, I did test before I asked about the timeline.
Unfortunately, rsync is still not working. I am wondering if it might be an iptables thing on osgeo2. Any idea how to test where things are getting hung up? The test command is "rsync download.osgeo.org::" which if it works will report "download download.osgeo.org contents".
comment:6 by , 16 years ago
|Status:||reopened → closed|
Yes it was iptables that was still blocking rsync.
A new rule for port 873 in the custom filters dir has been added, /etc/sysconfig/iptables-custom/RSYNC
I ran "rsync download.osgeo.org::" and all seems good now.
comment:7 by , 16 years ago
The requirement was actually on osgeo2, not osgeo1, so I have replicated this configuration there and now things are working great.
follow-up: 9 comment:8 by , 16 years ago
For posterity the iptables rule put in place is:
*filter -I INPUT -p tcp -s 184.108.40.206 --dport 873 -j ACCEPT -A OUTPUT -p tcp --dport 873 -j ACCEPT COMMIT
comment:9 by , 16 years ago
Replying to warmerdam:
For posterity the iptables rule put in place is:*filter -I INPUT -p tcp -s 220.127.116.11 --dport 873 -j ACCEPT -A OUTPUT -p tcp --dport 873 -j ACCEPT COMMIT
I don't want to sound harshly, just propose to implement some 'paranoia' that results of several years experience of system administration. I didn't read through all the rules, but this one came to my attention. Personally I'd suggest to add netmasks to _every_ rule and to add destination addresses to OUTPUT rules, where it applies. This would read:
-I INPUT -p tcp -s 18.104.22.168/32 -d <local interface> --dport 873 -j ACCEPT -A OUTPUT -p tcp -s <local interface> -d 22.214.171.124/32 --dport 873 -j ACCEPT
Howard suggested you are familiar with how to file tickets against Peer1 for hardware firewall issues. Could you address this?
Note, I am running the rsync client on osgeo2 to fetch from the rsync daemon on the telascience blade (download.osgeo.org). ie. outbound clients requests to a remote server on port 873.