Recently while working on some node or instance automation using RightScale I needed to have some extra iptables rules created automatically when a new node booted. Initially I was just trying to do this via iptables commands which I note below but it would never work. After digging through the logs I realized that the iptables commands created by RightScale for the ServerTemplate I was using flushed iptables at the very end of the boot process and thus wiped out the iptables entries created by the RightScript I had created. To accomplish permanent iptables entries for a RackSpace node via RightScale you need to output the iptables command to a file in the location where the boot process picks them up after flushing the current ruleset. Below I describe my first attempt followed by the correct way to have iptables entries picked up by RightScale.
Earlier today I needed to find the quickest and easiest way to monitor all traffic to and from a specific device on my network. The goal was to see how much bandwidth based on a specific amount of time that the device was using. My initial hope was that I could configure port monitoring on my WRT54G running DD-WRT firmware however I quickly found out this is not an option. I eventually settled on adding a couple iptables commands that would send all traffic destined for or sourced from a specific IP address to another IP address. Follow the directions below to add the iptables commands to a router running DD-WRT firmware and then to capture the traffic on a computer running Wireshark.
Yesterday a colleague at my company was doing some testing with a potential partner and they needed to open a TCP port on one of our development servers so an application could bind to that port. At first I wasn’t sure how I should do this since the port didn’t need to do anything but listen for incoming connections and the remote application would simply connect to that port. To get something up immediately for them I simply had our web server listen on the requested port which worked however I did not want the web server running on this port for long so I needed to come up with another solution to simply open the port, listen for connections, and possibly log those connections so we could troubleshoot if necessary. I ended up finding an application called tcpsnoop which I explain how to compile and use below.
The btmp log keeps track of failed login attempts. I have seen on a default linux setup with logrotate configured where the btmp log is left out of rotation and eventually grows out of hand. So first you want to make sure that the btmp log is rotated using logrotate with the below information.
To rotate the btmp log add the below to the logrotate.conf file located in the /etc directory.
On initial installation of PostgreSQL typically you will also download and install pgAdmin III on your local PC to assist in Postgres management. The pgAdmin GUI will assist in viewing database information quickly, etc. In one of my installations I was not able to connect to the new Postgres installation via pgAdmin and I was not receiving errors. Typically the issues I might have are related to the password not being correct or various GRANT permissions.
I had configured all of the initial items that I usually do which included the below.