tsunami-udp: faster than rsync

1. build
1. sudo apt-get install git gcc
2. sudo apt-get install automake autoconf
3. git clone git://github.com/rriley/tsunami-udp.git
4. cd tsunami-udp
5. ./recompile.sh
6. sudo make install
2. run
1. you'll need a port open to allow direct connection from client to server
1. unfortunately, this doesn't work through NAT firewalls alone
2. firewall / port forwarding
1. to server, TCP, 46224 by default
2. to client, UDP, 46224 by default
2. start up server
1. tsunamid myfile.gz
3. connect with client
1. tsunami set rate 5M connect myserver.domain.com get myfile.gz
2. it will flood your connection if you dont set rate properly
3. documentation
1. http://tsunami-udp.cvs.sourceforge.net/viewvc/tsunami-udp/docs/USAGE.txt
2. splits files automatically
3. allows wildcards when running server and client commands, "*", namely
1. client will auto-find all files served, one after the next
2. use forward-slash, i.e. get \*, for client command 
1. so bash doesn't intrepret the asterisk
4. undocumented
1. doesn't do subdirectories, better tar that up and have plenty of disk space

Check if a UDP port is open through a firewall

1. nmap -sU -p4569 remotehost

JMX ports to open in firewall for jconsole to Cassandra

1. Port 7199
1. Used for about a dozen packets when JMX connection first made
1. A handshake of sorts
2. Probably sets up the agreement on which high port to connect to, used below
1. Similar to SIP
2. Similar to old FTP
2. Not used again after initial handshake
2. Port range 55000 to 55999
1. To see these packets, on JVM server
1. tcpdump -nn ! port 22 and host <jconsole client IP> (not literal, replace this)
3. If jconsole starts showing graphs, you are connected

To run jconsole directly on the server via VNC, see this article: http://sysadminandnetworking.blogspot.com/

Tricks and Tips

1. If you don't want to expose 1000 ports to the world for some reason
1. Open all ports on firewall in front of JVM server
2. On JVM server: tcpdump -nn ! port 22 and host <jconsole client IP>
3. Start jconsole connection on client machine
4. Watch to see which port JVM server is trying to reach jconsole client via
5. Close all but that port in the firewall, will be between 55000-55999
2. Do a local experiment to a local JVM JMX-able application if unsure of good jconsole connection result
3. Get your external IP from where you are running jconsole client
1. CLI: curl http://ipaddr.me
2. Or web browser: http://ipaddr.me

Debugging pfsense firewall rules clearly and easily

1. Status -> System logs -> Settings
1. Make sure Log packets blocked by the default rule is not checked
2. Check Show log entries in reverse order
3. Increase to 500 Number of log entries to show
2.  Status -> System logs -> Settings -> Firewall 
1. Dynamic View
1. You don't have to hit refresh
2. Normal View
1. Make sure to hit refresh if you expect a rule was triggered by your or others actions
3. Firewall -> Rules
1. Under the interface(s) you want to debug
1. Create a default deny rule at the end of the rule list
1. Choose Log packets that are handled by this rule
2. Give the rule a very unique name
2. For other rules you want to debug
1. Choose Log packets that are handled by this rule
2. Give the rule a very unique name
4. Hang out on Status -> System logs -> Firewall -> Dynamic View
1. Tweak rules until you see the result you desire
1. Packets blocked that should be blocked
2. Packets allowed that should be allowed
2. Click on the red/green blocked/accepted icons
1. Will show a pop-up for the rule triggered, showing the unique name you gave to the rule
1. If necessary, go back and give more unique names to rules to distinguish them from one another