Rancid “Really Awesome New ConfIg Differ” is a very cool little suite of scripts that monitor the configurations on routers or other devices and keeps them in a version control system. If you admin more than a few such devices I highly recommend it. Not only is it a lifesaver to have the configs backed up and diffed automatically, but it can be fun to abuse some of the internals like the “clogin” script to push out changes or the like.

Rancid is full of very good expect scripts that know how to get all kinds of info from Cisco routers and a slew of other devices.

But I wanted to use it the same way with my vyatta routers too. I had great hopes of writing excellent expect scripts to do it, there was just one problem. I don’t know how to do that

Fortunately in addition to the preconfigured device types, someone figured out that rancid can also be set up with a “wrapper” device where you can just throw in any ugly script and it will point it at your device and throw whatever comes back into CVS just like it was one of the carefully parsed and sanitized configs.

The proof-of-concept code for that was a perl script called vpn3k written by Michael Stefaniuc at Red Hat, that could scp configs for Altera’s VPN 3000 concentrators. So I hacked it up a little bit to grab a couple snmp strings and then scp over the written config. That’s pretty sub-optimal since you only get the saved config, not the running config. Also Mr. Stefaniuc warns that the script may eat babies. But it works, and I don’t have to set up seperate cronjobs or CVS and the like. It all gets taken care of by rancid just like the non-free routers.

wrancid

Is the actual wrapper code that sits in $RANCID_HOME/bin in lieu of a good expect script and calls the perl script:

vyatta_rancidwrapper

Which you copy to $RANCID_HOME/share/wrapper/vyatta (note the name change) where it will make a new device type of wrapper.vyatta available for you to use in your router.db file:

someciscorouter.promisedlan.org:cisco:up
opencorevyatta.promisedlan.org:wrapper.vyatta:up

You do have to set up scp to work unattended also. I recommend you do it with authorized_keys, though the other rancid scripts can store plain text passwords (for telnet!) in the .cloginrc file, so you can be just as insecure as you’d like.

I told you there would be more, Turns out it’s 175 more:

img.mnoble.net

She cracks me up, we saw her taking dozens or hundreds of photos of the thermal features with no people or context in them. I was sure they would be amateurish at best. But instead she wound up getting tons of gorgeous little still lifes like that one. The girl sure has an eye for composition and color.

So you may know we took an _amazing_ (if miserable) trip to Yellowstone National Park this summer.

The kids had saved up and bought their own first cameras, so they are the official documenters.

Owen has gotten his set posted already so check ‘em out:
http://img.owenclyde.com

I’m sure Binty’s will be following shortly.

Snickers has passed away.
See our goodbyes here…

R.I.P. Over Easy Cafe

Thursday was the last day for Over Easy Cafe. Practically breaks my heart.

And then the trusty old breadbox breaks down too!

Not a great day.

Today inspired by some wise words from one of my ettiquette coaches,

I’ve decided to take a little different direction with my “online presence” such as it is.

This will be the last post from my autonomously hosted website. In the future if you’re interested in seeing what I’m up to please visit my new website:

I’m also on twitter, and foursqualor.com ( The second most popular site on the internet!)

So if you also have no concerns about who owns and controls your personal data”>concerns about who owns and controls your personal data, I encourage you to join me in using whichever thing that’s a lot like the World Wide Web but is less powerful has some php doodads, and includes spying for free, that is popular this year.

BTW, does anyone have a gmail invite I could get? Thanks.

That’s been the case so far for chromium, the open source browser sposored by google. But I’ve been wanting to try it. So I went ahead and used the chromium-daily source repository from the Ubuntu PPA and built an amd64 package for Debian testing.

It seems to work fine:

Though I have’nt exactly put it through it’s paces yet. And it took me a minute to find how to make it use the local gtk theme (brown of course!).

Also debuting today is:
repo.thepromisedlan.org

You can follow the instructions there to add the tpl repository to your sources.list, or feel free to just grab the binaries:
chromium-browser
and
chromium-codecs-ffmpeg

Well, I needed to send a brief message to all of the modem users, so I needed a way to translate a few dozen of the lines above into something I could paste into the bcc: bar of my mua. Also a few of them were not using their real email usernames for the modem.
So given a handy local copy of the mail servers passwd file, here’s what I came up with:
grep username modemconfigfile |cut -d " " -f 2 | for USER in `cat`; do grep $USER passwd > /dev/null; echo $USER $?; done |grep 0 |cut -d " " -f 1 | sed s/$/@ourdomain.com/g | tr '\n' ','

Which does indeed spit out a list of verified email addresses comma seperated, and ready to be pasted. It is still missing the real addresses of those users with different usernames, but there were only a few so I looked them up manually with the output of
grep username modemconfigfile |cut -d " " -f 2 | for USER in `cat`; do grep $USER passwd > /dev/null; echo $USER $?; done |grep -v 0
as a starting point.

Man I really need to learn perl or something. I couldn’t even fit that in an Identi.ca posting.

Update: DOH!, keen observers will have noticed that until this update, the above created output like user1.ourdomain.com, user2.ourdomain.com
Which of course are not email addresses. So s/./@/ and we’re back on track.
I guess that’s what I get for hours of DNS updating just previous.

I also saw them a little over a year ago, they were playing a free show at the Civic Plaza in Albuquerque. That show I really didn’t enjoy. I had the strong sense that they were just dialing it in. But I made lots of excuses for them, how the crowd was not really made up of their fans, how the venue is sub-par etc.

But last night was different, I _think_ the band put on a fine show. But it still just made me feel old, hanging around a bunch of 30+ year old dorks, reliving their teens, and realizing I was one of them

I still may pick up the new album though…

Apparently if you turn the volume down in Mac OS it saves a similar volume as an nvram setting in the EFI. So if you’re dual-booting or somesuch, you can just turn the volume down.

But what about those of us who wiped out the legacy OS in the first few minutes of owning the thing and never looked back?
Well only a few years later with the help of the mactel-linux-user list I can now turn off that blasted noise.

With new improved silence!

It goes like this:
#Boot EFI shell (from rEFIt, I don’t have rEFIt installed so i used a CD)
#spend 30 minutes finding the paginate switch for help
Shell>help -b

#cd to a writable partition (fs0 was the rEFIt CD, so fs1 was the 100MB fat/efi partition)
Shell>fs1:
fs1:\>

#dump the nvram variable
fs1:\>dmpstore SystemAudioVolume -s sav.txt

#edit the the dumped variable with a hexeditor (probably wiser to keep
the original dump and edit a copy)
fs1:\>hexedit sav.txt

#load the new nvram variable
fs1:\>dmpstore SystemAudioVolume -l sav.txt

#exit to refit and reboot
fs1:\>exit

Enjoy the BONGless restart.

So for a while it wasn’t apparent what value to change with the
hexeditor, and tbh, not being familiar with any hexeditor, I’m not sure
I got it right. Further experimentation indicates I may have just borked
it, but apparently that also serves to make it shut up.

The dmpstore’d files (now back in Debian) look like this:

$ cat SystemAudioVolume.txt
$SystemAudioVolume(and some illegible characters with no new line)

$ hexdump -C SystemAudioVolume.txt
00000000  24 00 00 00 53 00 79 00  73 00 74 00 65 00 6d 00  |$...S.y.s.t.e.m.|
00000010  41 00 75 00 64 00 69 00  6f 00 56 00 6f 00 6c 00  |A.u.d.i.o.V.o.l.|
00000020  75 00 6d 00 65 00 00 00  10 61 43 7c 2a ab bb 4b  |u.m.e....aC|*..K|
00000030  a8 80 fe 41 99 5c 9f 82  07 00 00 00 01 00 00 00  |...A.\..........|
00000040  71                                                |q|
00000041

(In hexedit.efi the 00000041 line did not appear.)

Since running dmpstore SystemAudioValume by itself returned output
something like:
00000: 71 “q”
I took a guess and replaced the 71 with 80 (as suggested on the mailing list.) getting:

$ hexdump -C SystemAudioVolume80.txt
00000000  24 00 00 00 53 00 79 00  73 00 74 00 65 00 6d 00  |$...S.y.s.t.e.m.|
00000010  41 00 75 00 64 00 69 00  6f 00 56 00 6f 00 6c 00  |A.u.d.i.o.V.o.l.|
00000020  75 00 6d 00 65 00 00 00  10 61 43 7c 2a ab bb 4b  |u.m.e....aC|*..K|
00000030  a8 80 fe 41 99 5c 9f 82  07 00 00 00 01 00 00 00  |...A.\..........|
00000040  80                                                |.|
00000041

Which turned off the bong and I’m happy. But for kicks I also tried 32
(for 25% more BONG)

$ hexdump -C sav.txt
00000000  24 00 00 00 53 00 79 00  73 00 74 00 65 00 6d 00  |$...S.y.s.t.e.m.|
00000010  41 00 75 00 64 00 69 00  6f 00 56 00 6f 00 6c 00  |A.u.d.i.o.V.o.l.|
00000020  75 00 6d 00 65 00 00 00  10 61 43 7c 2a ab bb 4b  |u.m.e....aC|*..K|
00000030  a8 80 fe 41 99 5c 9f 82  07 00 00 00 01 00 00 00  |...A.\..........|
00000040  32                                                |2|
00000041

But that also gave me silence, so I think I’m doing it ‘wrong.’
However reloading the original (71) file did bring back the bonging. So
I don’t think any of this is particularly dangerous for those who may
want to here the noise again someday.