DNS: Setup bind9 DNS Server in chroot environment

– Install Bind
# yum -y install bind bind-chroot bind-libs bind-utils caching-nameserver

-Confgure Permision
# chmod 755 /var/named/
# chmod 775 /var/named/chroot/
# chmod 775 /var/named/chroot/var/
# chmod 775 /var/named/chroot/var/named/
# chmod 775 /var/named/chroot/var/run/
# chmod 777 /var/named/chroot/var/run/named/
# cd /var/named/chroot/var/named/
# ln -s ../../ chroot
# cp /usr/share/doc/bind-9.3.6/sample/var/named/named.local /var/named/chroot/var/named/named.local
# cp /usr/share/doc/bind-9.3.6/sample/var/named/named.root /var/named/chroot/var/named/named.root
# touch /var/named/chroot/etc/named.conf

– Setting RNDC
# cd /var/named/chroot/etc
# rndc-confgen > rndc.conf
# chown root:named rndc.conf

– Edit File rndc.key:
# nano /var/named/chroot/etc/rndc.key

# Start of rndc.conf
key "rndckey" {
algorithm hmac-md5;
secret "QXkk0JXZDrgi0dJ0DrETKQ==";

#options {
# default-key “rndckey”;
# default-server;
# default-port 953;
# End of rndc.conf

# Use with the following in named.conf, adjusting the allow list as needed:
# key “rndckey” {
# algorithm hmac-md5;
# secret “xwINl5E9kGDva0PcJWCZjQ==”;
# };
# controls {
# inet port 953
# allow {; } keys { “rndckey”; };
# };
# End of named.conf

– Configure /var/named/chroot/etc/named.conf

# nano /var/named/chroot/etc/named.conf

// Red Hat BIND Configuration Tool
// Default initial "Caching Only" name server configuration
// we include the rndckey (copy-paste from rndc.key created earlier)
// include "/var/named/chroot/etc/rndc.key";
key "rndckey" {
algorithm hmac-md5;
secret "QXkk0JXZDrgi0dJ0DrETKQ==";

// assume our server has the IP serving the subnet
controls {
inet allow {; } keys { “rndckey”; };
inet allow {; } keys { “rndckey”; };

options {
directory “/var/named”;
pid-file “/var/run/named/named.pid”;

recursion yes;

allow-recursion {;;

// these are the opendns servers (optional)
forwarders {;;;;

listen-on {;;

* If there is a firewall between you and nameservers you want
* to talk to, you might need to uncomment the query-source
* directive below. Previous versions of BIND always asked
* questions using port 53, but BIND 8.1 uses an unprivileged
* port by default.
// query-source address * port 53;

// so people can’t try to guess what version you’re running
version “REFUSED”;

allow-query {;;

server {
keys { rndckey; };

zone “.” IN {
type hint;
file “named.ca”;

//forward zone
zone “example.net” IN {
type master;
file “data/example.net.zone”;
allow-update { none; };
// we assume we have a slave dns server with the IP
allow-transfer {; };

//reserve zone
zone “0.168.192.in-addr.arpa” IN {
type master;
file “data/192.168.0.zone”;
allow-update { none; };
// we assume we have a slave dns server with the IP
allow-transfer {; };

-Setting Forward Lookup Zone
# cd /var/named/chroot/var/named/data/
# touch example.net.zone
# nano example.net.zone

-Edit File example.net.zone:

$ttl 38400
example.net. IN SOA ns.example.net. admin.example.net. (
2012011501 ; Serial
10800 ; Refresh after 3 hours
3600 ; Retry after 1 hour
604800 ; Expire after 1 week
86400 ) ; Minimum TTL of 1 day
example.net. IN NS ns.example.net.
ns.example.net. IN A

– Setting Reverse Lookup Zone
# cd /var/named/chroot/var/named/data/
# touch 192.168.0.zone
# nano 192.168.0.zone

-Edit File 192.168.0.zone :

$TTL 86400
0.168.192.in-addr.arpa. IN SOA ns.example.net. admin.example.net. (
3600 )

0.168.192.in-addr.arpa. IN NS ns.example.net.-Restart Bind Service & Setting run level

# service named restart
# chkconfig named on

-Make sure it’s running :
# rndc status

If it is not running link /etc/rndc.conf with /var/named/chroot/etc/rndc.conf and restart named

-Edit /etc/resolv.conf & Restart service
# nano /etc/resolv.conf

search example.net

-Testing DNS Query:
# nslookup google.com


Perform SSH Login Without Password Using ssh-keygen

you probably log in and out of a half dozen remote servers (or these days, local virtual machines) on a daily basis. And if you’re even more like me, you have trouble remembering all of the various usernames, remote addresses and command line options for things like specifying a non-standard connection port or forwarding local ports to the remote machine.

Shell Aliases

Let’s say that you have a remote server named dev.example.com, which hasnot been set up with public/private keys for password-less logins. The username to the remote account is fooey, and to reduce the number of scripted login attempts, you’ve decided to change the default SSH port to 2200 from the normal default of 22. This means that a typical command would look like:

$ ssh fooey@dev.example.com -p 22000
password: *************

Not too bad.

We can make things simpler and more secure by using a public/private key pair; I highly recommend using ssh-copy-id for moving your public keys around. It will save you quite a few folder/file permission headaches.

$ ssh fooey@dev.example.com -p 22000
# Assuming your keys are properly setup…

Now this doesn’t seem all that bad. To cut down on the verbosity you could create a simple alias in your shell as well:

$ alias dev=’fooey@dev.example.com -p 22000′
$ # To connect:
$ ssh dev

This works surprisingly well: Every new server you need to connect to, just add an alias to your .bashrc (or .zshrc if you hang with the cool kids), and voilà.


However, there’s a much more elegant and flexible solution to this problem. Enter the SSH config file:

# contents of $HOME/.ssh/config
Host dev
    HostName dev.example.com
    Port 22000
    User fooey

This means that I can simply  $ ssh dev, and the options will be read from the configuration file. Easy peasy. Let’s see what else we can do with just a few simple configuration directives.

Personally, I use quite a few public/private keypairs for the various servers and services that I use, to ensure that in the event of having one of my keys compromised the dammage is as restricted as possible. For example, I have a key that I use uniquely for my github account. Let’s set it up so that that particular private key is used for all my github-related operations:

Host dev
    HostName dev.example.com
    Port 22000
    User fooey

Host github.com
    IdentityFile ~/.ssh/github.key

The use of IdentityFile allows me to specify exactly which private key I wish to use for authentification with the given host. You can, of course, simply specify this as a command line option for “normal” connections:

 $ ssh -i ~/.ssh/blah.key username@host.com

but the use of a config file with IdentityFile is pretty much your only optionif you want to specify which identity to use for any git commands. This also opens up the very interesting concept of further segmenting your github keys on something like a per-project or per-organization basis:

Host github-project1
    User git
    HostName github.com
    IdentityFile ~/.ssh/github.project1.key

Host github-org
    User git
    HostName github.com
    IdentityFile ~/.ssh/github.org.key

Host github.com
    User git
    IdentityFile ~/.ssh/github.key

Which means that if I want to clone a repository using my organization credentials, I would use the following:

$ git clone git@github-org:orgname/some_repository.git

Going further

As any security-conscious developer would do, I set up firewalls on all of my servers and make them as restrictive as possible; in many cases, this means that the only ports that I leave open are 80/443 (for webservers), and port 22 for SSH (or whatever I might have remapped it to for obfuscation purposes). On the surface, this seems to prevent me from using things like a desktop MySQL GUI client, which expect port 3306 to be open and accessible on the remote server in question. The informed reader will note, however, that a simple local port forward can save you:

$ ssh -f -N -L 9906: coolio@database.example.com
# -f puts ssh in background 
# -N makes it not execute a remote command

This will forward all local port 9906 traffic to port 3306 on the remotedev.example.com server, letting me point my desktop GUI to localhost ( and have it behave exactly as if I had exposed port 3306 on the remote server and connected directly to it.

Now I don’t know about you, but remembering that sequence of flags and options for SSH can be a complete pain. Luckily, our config file can help alleviate that:

Host tunnel
    HostName database.example.com
    IdentityFile ~/.ssh/coolio.example.key
    LocalForward 9906
    User coolio

Which means I can simply do:

$ ssh -f -N tunnel

And my local port forwarding will be enabled using all of the configuration directives I set up for the tunnel host. Slick.


There are quite a few configuration options that you can specify in~/.ssh/config, and I highly suggest consulting the online documentation or the ssh_config man page. Some interesting/useful things that you can do include: change the default number of connection attempts, specify local environment variables to be passed to the remote server upon connection, and even the use of * and ? wildcards for matching hosts.

I hope that some of this is useful to a few of you. Leave a note in the comments if you have any cool tricks for the SSH config file; I’m always on the lookout for fun hacks.

GIT: Setting up a remote repository and doing an initial “push”

There is a great deal of documentation and many posts on Git out there, so this is more of a note to self as I keep forgetting the steps needed to set up a remote repository and doing an initial “push”.

So, firstly setup the remote repository:

ssh git@example.com
mkdir my_project.git
cd my_project.git
git init --bare
git-update-server-info # If planning to serve via HTTP

On local machine:

cd my_project
git init
git add *
git commit -m "My initial commit message"
git remote add origin git@example.com:my_project.git
git push -u origin master


Team members can now clone and track the remote repository using the following:

git clone git@example.com:my_project.git
cd my_project


To have your terminal prompt display what branch you are currently on in green, add the following to your ~/.bash_profile:

function parse_git_branch_and_add_brackets {
  git branch --no-color 2> /dev/null | sed -e '/^[^*]/d' -e 's/* \(.*\)/\ \[\1\]/'
PS1="\h:\W \u\[33[0;32m\]\$(parse_git_branch_and_add_brackets) \[33[0m\]\$ "

GIT: Pushing changes to remote repo

You can simply convert your remote repository to bare repository ( There is no working copy in the bare repository – the folder contains only the actual repository data ) .

Execute following command in your remote repository folder:

git config --bool core.bare true 

Then delete all the files except .git in that folder. and then you will be able to perform git push to the remote repository without any errors.

GIT: Common Aliases

Common Aliases

git statusgit addgit commit, and git checkout are such common commands that it is useful to have abbreviations for them.

Add the following to the .gitconfig file in your $HOME directory.

FILE: .gitconfig

  co = checkout
  ci = commit
  st = status
  br = branch
  hist = log --pretty=format:\"%h %ad | %s%d [%an]\" --graph --date=short
  type = cat-file -t
  dump = cat-file -p

Python: Returning Rows as Dicts in MySQLdb

Do you want to return a row of data from your database as a dict rather than a tuple? Using MySQLdb? Then here’s how you do it. The traditional way to retrieve a row from a table is;

>>> import MySQLdb
>>> myDb = MySQLdb.connect(user=’andy47′, passwd=’password’, db=’db_name’)
>>> myCurs = myDb.cursor()
>>> myCurs.execute(“SELECT columna, columnb FROM tablea”)
>>> firstRow = myCurs.fetchone()
>>> firstRow
(‘first value’, ‘second value’)

But using the DictCursor cursorclass we get;

>>> import MySQLdb
>>> import MySQLdb.cursors
>>> myDb = MySQLdb.connect(user=’andy47′, passwd=’password’, db=’db_name’, cursorclass=MySQLdb.cursors.DictCursor)
>>> myCurs = myDb.cursor()
>>> myCurs.execute(“SELECT columna, columnb FROM tablea”)
>>> firstRow = myCurs.fetchone()
{‘columna’:’first value’, ‘columnb’:’second value’}

Note the extra import at the beginning, without it Python doesn’t know about MySQLdb’s cursors module. You should also be wary of guessing the order that the items in each row of the DictCursor are returned in. There is no guarantee, for instance, that “columna” will always be the first key and “columnb” the second. When using the DictCursor you should always access values directly by their key. When using the normal cursor class you can access the returned values in sequence (make sure never to use “SELECT *”) as that’s the only way you can associate a value with the column it has come from.