I've recently been looking at reporting in OpenNMS and it seems that some of the reports require date ranges to be specified in unix time. Now, I don't know about you, but my mental ability to translate "April 26, 2011 15:00 UTC" to 1303830000 is sadly lacking. So, here are some useful commands to convert from unix time to date and vice versa:

Date to Unix time:

# current timestamp
date +%s

# specific timestamp
date -d '2011-04-26 15:00:00' +%s

# same thing but UTC
date -u +%s
date -u -d '2011-04-26 15:00:00' +%s

Unix time to date:

date -d @1303826400

# same thing but UTC
date -u -d @1303826400

I  ran into an odd issue today – my firewall build script was failing on our account master node.

It turns out that I was trying to use a chain name in iptables that exceeded the maximum length allowed. I wanted to use "REMOTE_ACCOUNT_SLAV ES_ASHEVILLE" (31 chars) and the limit is 30 chars.

You can see this in /usr/include/linux/netfilter_ipv4/ip_tables.h and /usr/include/linux/netfilter/x_tables.h:



This was on CentOS 5.6.

Having grown up with CVS then moved on to svn, I find git amazingly powerful. However, I don't use it enough to learn some of the more powerful features. This is just a post to document a couple of useful things I learned recently.

I was working on a project on github, adding a missing command-line option. But, while editing, I got carried away and made a load of additional trivial changes, cleaning up the man page text, making capitalisation consistent, etc. All good stuff, but I didn't want to commit both sets of changes in the same commit.

What I needed to do was to select which changes to commit. The command to do that is:

git add --patch

To show the changes that have been added to the staging area, ie. those that will be commited:

git diff --cached

If you mistakenly add a change and want to remove it from the staging area:

git reset --patch

Finally, commit the change:

git commit

Optionally, push the change back to github:

git push origin master

Nifty stuff.