sshuttle and juju for seamless private network bridging

Suppose you're getting started with juju, but you wish to try this on a VM or separate server dedicated to the task, further suppose you wish to use LXC for development purposes. Once everything is said and done you'll have a working juju service with an ip address you can't reach.

ppetraki@mark21:~/Sandbox/juju-local$ juju status
machines:
  0:
    agent-state: running
    dns-name: localhost
    instance-id: local
    instance-state: running
services:
  mysql:
    charm: cs:precise/mysql-8
    relations:
      db:
      - wordpress
    units:
      mysql/0:
        agent-state: started
        machine: 0
        public-address: 192.168.122.119
  wordpress:
    charm: cs:precise/wordpress-9
    exposed: true
    relations:
      db:
      - mysql
      loadbalancer:
      - wordpress
    units:
      wordpress/0:
        agent-state: started
        machine: 0
        open-ports:
        - 80/tcp
        public-address: 192.168.122.196

The solution? sshuttle.

$ sshuttle -r mark21 192.168.122.0/24

Will use iptables to create a NAT which tunnels over ssh to bridge this network. Now you can visit 192.168.122.196 in your web browser and have full TCP access to that network, all without using openvpn.

enabling modeline support in vim

If you ever wondered why

# vim:ts=4:sw=4:et:

Doesn't work by default is because it's been disabled at the distribution level for security reasons. To get around this add this snippet to your local vimrc or system wide if you're feeling bold.

if exists("+modelines") 
     " the following is required because of SuSE's paranoid /etc/vimrc 
     " and to force 'modeline' on even for root in Vim 7.0.237 and later 
     set modeline modelines=5 
     " the following disables a dangerous modeline in one helpfile 
     if has ('autocmd') 
         au BufReadPost ada.txt setl nomodeline ft=help 
     endif 
endif

crash utility dminfo extension hacking

I had done this a long time ago while triage of multipath based core dumps were a regular occurrence for me. Some of the extra plugins for crash are way out of date and require access to private data structures to reconstitute the view of the subsystem. Here's an example of porting the dminfo plugin for use with Linux 2.6.32.

https://code.launchpad.net/~peter-petrakis/ubuntu/oneiric/crash/dminfo-update

and the diffs

What I would like to do someday is figure out how to "mount" sysfs from crash context and use the device model to obtain these data structures in a deterministic manner. That would make these sort of plugins much more robust.

Ubuntu PDF merge one liner

These are always the best

$ gs -dBATCH -dNOPAUSE -q -sDEVICE=pdfwrite -sOutputFile=output_file.pdf  `ls -x *pdf | sort`

The ls -x incantation ensures everything is on one line to be feed to gs. This really handy when scanning multipage documents so if it jams along the way your entire pdf isn't lost.

Getting Started with Hand Loading

So my first kit is on the way, after about a week of research I settled on something so simple, I didn't think it existed. Hand Loading.

http://leeprecision.com/lee-loader-38-spl.html

All you need is a rubber mallet and the supplies: powder and slugs.

The die set itself costs $26 from midwayusa, a box of 50 38S new runs about $21 here. Initial estimates put the reloading costs at about $10/50, probably cheaper if I use lead rounds. I also purchased associated hand tools for case prepping and a Lee manual. Overall, including shipping the cost to date is $78.

It's about as dirty as cleaning a gun, if not less and I can do it anywhere. Still being an apartment dweller space is a premium.

In the meanwhile I'll get lots of experience with something before I go spend a couple hundred bucks on a fancy press and associated gadgets. Even gathering brass will be easy as I can dump it straight from the gun into the brass bucket. Keep you posted, hope I don't burn my eyebrows off :)

Automating FC SAN failover using pexpect

The code is on github and is fairly straight forward. One of these days I'll figure out how to do this using SMI-S or other XML magic pixie dust. The Cisco MDS is a little obnoxious in that it requires you to entire config mode to toggle vsans. The switch is already configured for pubkey authentication. Here it is in action,

ppetraki@mark21:~/Sandbox/cisco-automation$ ./cisco_pexpect.py 
logging in...
logged in
entered config mode
enable both vsans, wait 30 secs
disable vsan 10, wait 60 secs
enable vsan 10
exit config mode
exit fc switch
terminated True

In a separate window I have 'watch -d multipath -ll' on the client and confirm during the 60 sec sleep that the path group did indeed go out of service and then return.

$ git clone git://github.com/ppetraki/cisco-fc-failover.git

and enjoy!

Determine Linux "sd" names for debugging

The way the Linux SD driver works is it reserves 16 minor 'slots' per block device, the first minor represents the whole disk, and the remaining 15 are reserved for partitions. Knowing this offset one can write a little python code to create an index table that aids debugging, mapping minor numbers back to block device names. This of course presumes that names are being recycled.

# python -c "print zip(range(0,443,16), map(chr, range(97, 123)))" [(0, 'a'), (16, 'b'), (32, 'c'), (48, 'd'), (64, 'e'), (80, 'f'), (96, 'g'), (112, 'h'), (128, 'i'), (144, 'j'), (160, 'k'), (176, 'l'), (192, 'm'), (208, 'n'), (224, 'o'), (240, 'p'), (256, 'q'), (272, 'r'), (288, 's'), (304, 't'), (320, 'u'), (336, 'v'), (352, 'w'), (368, 'x'), (384, 'y'), (400, 'z')]

So sdb would be 8,16 and sdm would be 8,192, sdm1 is 8,193. Now the next time you see something awful like this:

Jul 10 15:08:25 | checker failed path 8:144 in map mpath2 Jul 10 15:08:25 | libdevmapper: ioctl/libdm-iface.c(1740): dm message mpath2 NF fail_path 8:144 [16384]

You can say with confidence that this is device sdj.