Hipchat ova startup-scripts are not executing iptables update

[Jason Mueller]

We are trying to bypass Chef-configuration in the HipChat .ova provided by Atlassian. We have developed software that communicates to the HipChat server over certain ports. I've worked with Atlassian regarding updating the iptables rules directly thru the shell, which caused problems and we were told we can modify iptables this way. 

There is a location for scripts to be run on startup of the HipChat server to override these blocks (/home/admin/startup_scripts/routes) which we dropped our iptables update commands, and restarted HC. However the ports are still blocked, and when reviewing iptables rules, the updates are not there. 

Example:

/usr/bin/sudo /bin/dont-blame-hipchat -c "iptables -A INPUT -p tcp -s <IP_ADDRESS_OTHER_SERVER> --dport #### -m state --state NEW,ESTABLISHED -j ACCEPT"

Upon checking 'iptables -L', the rules are NOT present. Does anyone know how the /startup_scripts/routes are implemented in HipChat .ova and what could be wrong here?

[wdehaan]

Hi JFM,

This is working well for me. Can you try the following?

echo "/usr/bin/sudo /sbin/iptables -A INPUT -p tcp -m tcp --dport 1234 -m state --state NEW -j ACCEPT" > ~admin/startup_scripts/firewalltest
chmod +x  ~admin/startup_scripts/firewalltest
hipchat upgrade --restart 

Note that restart action won't upgrade your system but will restart services and apply ~admin/startup_scripts 

[Jason Mueller]

Hi Will,

Thank you greatly for your response. I have been coordinating across multiple channels/parties during this process, (those on our team testing locally in Italy vs. those that are testing on client side). Unfortunately I've not had time to setup a test server myself w/current workload.

Before reading on, we've made a very relevant discovery today. All ours & Atlassian's test have been done in Atlassian Hipchat 1.3 build 1.3.7, but our client environment is running Atlassian HipChat 2.0 build 1.4.2. So ultimately we are testing for HipChat 2.0, build 1.4.2.

Just inquire further as to implementing your command above....We've been placing these in /startup_scripts/routes...so you're essentially just applying/testing this in the shell? There are a total of 3 iptables rules + sed command. Ultimately the script in /routes looks something like this:

/usr/bin/sudo /bin/dont-blame-hipchat -c "iptables -A INPUT -p tcp -s <IP_ADDRESS_SERVER> --dport #### -m state --state NEW,ESTABLISHED -j ACCEPT" 

/usr/bin/sudo /bin/dont-blame-hipchat -c "iptables -A INPUT -p tcp -s <IP_ADDRESS_SERVER> --dport #### -m state --state NEW,ESTABLISHED -j ACCEPT"
 
/usr/bin/sudo /bin/dont-blame-hipchat -c "iptables ....etc.
 
/usr/bin/sudo /bin/dont-blame-hipchat -c  "sed -i 's/.*bind-address.*/bind-address = x.x.x.x/' /etc/mysql/my.cnf"

I'm just not very familiar with the order/function of these startup_scripts in the boot process with Chef in the mix. 

[Jason Mueller]

I do think the chmod +x is a good idea however, and come to think of it, the script commands were copy/pasted, which i know introduces bizarre quirks in the character encoding in Linux...have seen this before. Will try to chmod +x /routes, + ensure they are straight typing, or at least dropping in notepad before pasting, to the shell.

[wdehaan]

Well that looks like it should work. I believe the HCS2 1.4.0 build overwrote the example script names, though that's fixed in build HCS2 1.4.2. Double check the contents of the routes script to see if they were clobbered by an upgrade; or simply rename it (with no filename suffix allowed)