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.