Saturday, July 28, 2012

Atomic Operations on Enterasys Switches

There are times when you need to perform an operation that consists of a number of sub-operations. At any point that one of the sub-operations fails to complete the parent operation also fails. This is a concept known as atomicity. Cisco administrators have this ability through the use of the configure command. This safety net is not available on Enterasys switches. Once you enter a command it goes live. This is both a blessing and a curse.

I recently experienced one such curse when attempting to change the host VLAN of a switch remotely. Even with the appropriate VLANs egressing, unless the host VLAN matches the uplink interface PVID you can kiss your remote access goodbye. This can be done locally with 2 simple commands.

set host vlan 1234
set port vlan lag.0.1 1234 modify-egress

As stated, this can't be done remotely as once one of the commands is entered, you lose remote access. This might be a bug/feature, however, this let me to wonder, "How do you perform atomic operations on an Enterasys switch?". After some investigation, I discovered a solution. It takes some setting up but becomes quite elegant when you want to push these commands to numerous switches.

Create the Config File

 

First you need a file with the commands you want to run

set host vlan 1234
set port vlan lag.0.1 1234 no-modify-egress
set vlan egress lag.0.1 1234 untagged
clear vlan egress lag.0.1 4321
end

It seems you can't untag the VLAN using the set vlan command when sending a configuration file.

Now place this file in your TFTP directory.

Apply the Config

 

When you're ready to deploy the change simply run the following commands,

copy tftp://1.2.3.4/hostvlan.cfg configs/hostvlan.cfg
configure configs/hostvlan.cfg append
delete configs/hostvlan.cfg

There you have it. I've successfully changed the host VLAN remotely, without taking the switch offline. Use this in conjunction with the Command Script Tool in NetSight or you own expect scripts and it becomes really easy to deploy changes that require atomicity across your entire network.

Thursday, November 17, 2011

Blog URL migration with GAE redirect with nginx rewrite

I am in the process of migrating a number of applications I used to run on my VPS onto the Google Apps framework, mostly because I am lazy. One such application was this blog. Creating and copying the blog entries across was simple enough, but I also wanted to incorporate my static pages. This would require configuring www.die.net.au and die.net.au to make to my home page on the blog. As an extra step I wanted my VPS server to have as little to do as possible. My plan was to get www.die.net.au hosted in the Google Application Engine service then simple do a rewrite for die.net.au on my VPS.

I created a very simple Go app for GAE mapped to www.die.net.au that redirected to my blogs home page.
package page_redirect

import (
        "http"
)

func init() {
        http.HandleFunc("/", root)
}

func root(w http.ResponseWriter, r *http.Request) {
        http.Redirect(w, r, "http://blog.die.net.au/p/home.html", 302)
}

All my VPS needed to do now was redirect web requests for die.net.au to www.die.net.au. This was easily achieved by added a simple server configuration to my nginx front end.
server {
    listen 80;
    server_name die.net.au;
    rewrite ^/(.*) http://www.die.net.au permanent;
}

And that's it. My blog has now been fully integrated into Google for them to spy on with my blessings.

Friday, October 28, 2011

YUM: was supposed to be removed but is not!

I was trying to update a Fedora15 server and got the dreaded error. The top recommended suggesting was the remove, rebuild and clean your yum database. But this wasn't working for me. A verbose run of the yum update didn't reveal much more of interest, except.
Warning: scriptlet or other non-fatal errors occurred during transaction.
Nothing in the logs either. My next course of action was to manually install the RPM files. These are usually located under /var/cache/yum/ but there was nothing there. Why weren't the RPM files getting stored? Then it hit me. The presto plugin uses Delta-RPMs to only download the sections of an RPM that differ from your installed ones. It's quite a nifty feature. But to get the RPM files I needed to disable it.

I think you can see where this is going. Disabling presto and delta-rpms caused yum update to work again. This may have been due to RPM itself being part of the updates. I'm going to re-enable presto again and see what happens next update.

Wednesday, November 11, 2009

Dialog Windows in XMonad

The current implementation for dialog detection only treats transient windows of the parent window as dialogs, and ignores EWMH compliant applications that set the window type to _NET_WM_WINDOW_TYPE_DIALOG

The following code detects EMWH dialog windows:
import XMonad
import Graphics.X11.Xlib.Extras

-- | Float all dialog windows
manageDialogs :: ManageHook
manageDialogs = checkDialog --> doFloat

-- | Check if window is DIALOG window
checkDialog :: Query Bool
checkDialog = ask >>= \w -> liftX $ do
                a <- getAtom "_NET_WM_WINDOW_TYPE"
                dialog <- getAtom "_NET_WM_WINDOW_TYPE_DIALOG"
                mbr <- getProp a w
                case mbr of
                  Just [r] -> return $ elem (fromIntegral r) [dialog]
                  _ -> return False

-- | Helper to read a property
getProp :: Atom -> Window -> X (Maybe [CLong])
getProp a w = withDisplay $ \dpy -> io $ getWindowProperty32 dpy a w
It's then just a matter of adding the manageDialogs hook to your manageHooks, here is my manageHooks:
myManageHook :: ManageHook
myManageHook = composeAll
               [ manageDocks
               , manageDialogs
               , manageHook defaultConfig
               ]

Thursday, July 30, 2009

Introducing the Yocto Package Manager (yPkg)

Many times I've needed a newer version of a library or a tool not provided on the computer labs at university. Rather than pester the admin, I would generally install software into $HOME/.local and go on my merry way. This was fine until I started hitting my quota and had to manually clean out my installed software. So I decided to write a simple package manager with a minimal set of features to allow me to more easily install and remove software, a micro package manager. I was going to call it µPkg, but the aim it to have the smallest package manager possible and the smallest official SI prefix is y (yocto). Hence the name yPkg

Features it does not have:
  • Build scripts
  • Package upgrades
  • Regression tests
  • Checksums
You get the software yourself, you validate it yourself, you build it your self. All it does it create a simple environment to build in, creates a package and generates a footprint. The footprint can then be later used to remove the package.

Here is an example of how to use it:
~ $ ypkg init hello
(ypkg) ~/.ypkg/hello $ wget http://ftp.gnu.org/gnu/hello/hello-2.4.tar.gz
(ypkg) ~/.ypkg/hello $ tar zxf hello-2.4.tar.gz
(ypkg) ~/.ypkg/hello $ cd hello-2.4
(ypkg) ~/.ypkg/hello $ ./configure --prefix=$HOME/.local
...
(ypkg) ~/.ypkg/hello $ make
...
(ypkg) ~/.ypkg/hello $ make DESTDIR=$PWD/../pkg install
...
(ypkg) ~/.ypkg/hello $ exit
~ $ ypkg build hello
~ $ ypkg gen_footprint hello
~ $ ypkg install hello
~ $ ypkg list
/home/lucas/.ypkg/hello
~ $ cat ~/.ypkg/hello.footprint
/home/lucas/.local/usr/bin/hello
...
~ $ ypkg uninstall hello
The source is available here http://git.die.net.au/cgit/ypkg

Saturday, July 25, 2009

Upgrading to CRUX 2.6 on Slicehost

I'm one of those sadists that like to upgrade CRUX releases from ports rather than release packages. I've been testing the CRUX 2.6 branch on my home PC for some time now without any problems, so I've decided to upgrade my VPS as I am no longer maintaining my multilib branch of 2.5.

libarchive and pkgutils

First get yourself a copy of the 2.6 core repo, either from git or rsync. If you rebuilt libarchive while lzma was installed, you will need to remove lzma and rebuild/install libarchive manually.

You will then need to install xz then upgrade libarchive. Follow this by upgrading pkgutils and ports. Now you can upgrade your ports and begin rebuilding the toolchain.

Rebuilding the Toolchain

The only issue I encountered here was that the Slicehost kernel is too old to be built with the new glibc. This is easily fixed by changing one line in core/glibc/Pkgfile, change
--enable-kernel=2.6.27
to,
--enable-kernel=2.6.24

e2fsprogs and util-linux-ng

libuuid and libblkid has moved from e2fsprogs to util-linux-ng. You will need to remove e2fsprogs, update util-linux-ng then reinstall e2fsprogs.
Everything else should go fine after that. It's simply a matter of doing a sysup, checking for missing libraries via revdep and rebuilding where appropriate.

Friday, June 19, 2009

BOM Weather Observations Available in JSON

When I discovered that BOM weather observations were available in JSON, I had to have a play. Initially I tried doing something with jQuery, but cross site request are only supported through JSONP. Then I had a better idea, let my server collect and cache the observations, this then allowed me to process the observations on the server side and do cool things like make pretty graphs.

After an hour or so of mucking around, I now have a weather page.

The graph is generated using matplotlib and the data is smoothed using numpy.

In the future I might play with this more, allowing more observation stations, and add support for other BOM products. But I suppose I better get back to studying for exams.