Nov 062013
 

I’ve been drinking Diet Mt. Dew for about 15 years now. During this time I’ve been able to study its effects on my body both inside and out.

Here is a quick list of some of these benefits:

1. Color

It’s very green. Shine some light through it and your emotional state will improve under an circumstance. As the light traverses the liquid it illuminates the various shades of beautiful green. This feature alone makes it worth its weight in tarnished silver.

2. Energy Efficiency

Who can possibly argue the energy boost you get when you down a few litres of the magical caffeine infused potion? Mt. Dew is the original energy drink. Diet Mt. Dew gives you all the benefits of the original Mt. Dew without that nasty sugar. Food coma? Afternoon crash? Just drink more!

3. Aspartame(tm?)

FKA NutraSweet this sweet substance is not just any sweetener. A purely accidental chemical that is 200, yes, two hundred times sweeter than the natural alternative; sucrose. That natural stuff makes you fat while Aspartame just causes pre-mortem embalming which saves the funeral home some work when you finally succum to its sweet toxins. Stay away from natural alternatives at all costs.

4. Availability

It’s a little known fact that Diet Mt. Dew is more readily available world wide than clean water. In some countries Diet Mt. Dew is used to wash clothes, clean dishes, and for general hygienic reasons. Regular Mt. Dew cannot be used because all natural sugar gets sticky when wet. Yet another reason to avoid the natural alternatives at all costs.

5. Lower Risk of Death

No wars have ever been fought over the substance. This is a fact that cannot be disputed.

 

These are only a few of the many benefits provided by Diet Mt. Dew.

Drink up and prosper.

Drink green for a better world.

Save your heart, drink a Diet Dew.

Keep Calm and Go Green!

 Posted by at 9:14 pm
Jul 102011
 

I just migrated this blog to WordPress. I’m using one of Site5′s cool premium (yet free) WordPress themes.

All comments have been lost in the transition, but the posts made it. I’d really like to rewrite the Juniper VPN stuff but I don’t even use that VPN any more so it would be difficult to test.

 Posted by at 11:44 pm
Dec 072009
 

I finally got around to putting this old code on github here: freebsd-impersonation.

It’s unlikely that it’ll be of much to use to anyone in the real world but every now and then I see someone fetch the uimp.pdf file that this describes. Just this weekend I re-discovered the code on an old hard drive and thought it might be nice to preserve it, even if it did turn out to be pretty much useless.

 Posted by at 2:06 pm
Nov 122009
 

Okay, so developing in Windows is just not any fun. As I mentioned before, Vim is my weapon of choice. Vim runs just fine in Windows but not with my workflow. I need bash beneath it for things to work right. And Cygwin just doesn’t cut it. Nor does MSYS.

So I’m back to using Linux when I’m writing code. I use Thunderbird for email with Lightening for the calendar. If I need to deal with real appointments from real people and that sort of thing I’ll boot into Windows and fire up Outlook. Or I’ll use one of the ‘community’ servers we have set up and RDP into that.

Alternatively I can run Linux in VirtualBox pretty well. Unfortunately VirtualBox is rather limited and doesn’t utilize dual monitors yet (at least not that I can see). Maybe VMWare. Dunno yet.

Or someone could volunteer to buy me one of those dandy new 27″ iMacs and I’ll be right where I belong. You know, a premium OS that looks and feels right with *nix underneath. The best of all worlds.

I miss my mac.

 Posted by at 3:34 am
Nov 092009
 

Linux is annoying the heck out of me again.

Why? Because I really want to make it work as my primary desktop environment. The reason I want to do this is because it’s either that, or Windows.

Given the choice, I’d be running OSX but I can’t get my copy of Leopard (legitimate!) to run on my laptop so I’m stuck with either a Windows or Linux variant. Lucky me.

I very much prefer a UNIX based system but I have certain needs that just aren’t fulfilled by any of the desktop OS’s out there, with the exception of OSX. Why is that?

Why isn’t there a plugin or wrapper or something for Thunderbird that will allow it to connect natively to an Exchange server? With EWS (Exchange Web Services) it seems like it should be a fairly simple thing. Evolution does it (but Evolution is a flying turd), and Mail.app in Snow Leopard does it as well. But the one email client I actually enjoy has no signs of ever supporting such a thing. All I *really* care about is Calendar integration. The email part I can do with IMAP. That is so bloody annoying.

What is it about a UNIX environment that I so enjoy? Well, it begins with ksh, csh, or bash. I get along quite nicely with all three. I am also quite addicted to vi, or nowadays vim. Vim is my main weapon of choice. When coding in C, vim and Makefiles are all you really need. Right? These days I am lucky though because I get to write Ruby (more specifically, JRuby) code all day. Well, mostly. Sometimes I have to work with PL/SQL on Oracle. Those days are a bit like Arthur Dent and Thursdays.

I had been running Linux as my primary desktop for a good month point five before I finally threw in the towel. The catalyst seems to be a composition of things from slow and ugly java applications to extreme hackery just to log into the VPN and work unencumbered. Throw in a dab of email issues with a pinch of Microsoft Marketing and you have me back on Windows. Windows 7.

Yep. I gave up again. I’m certainly capable of making it work but it takes so much out of me that I just don’t feel the desire to do so. So I installed Windows 7.

Windows 7. My only real hatred for you is CMD.EXE. Oh how I hate thee. And Powershell, while it may be powerful, is just too much for my aging brain to deal with right now. Luckily there is a well known cure for that. And it isn’t Cygwin. MSYS 1.0 with TDM MinGW mixed with Console2 and we are ready to rock.

I hope.

 Posted by at 4:55 am
Oct 282009
 
UPDATE!! 2011-09-02

A recent post at ubuntuforums.org demonstrates a much easier way to log into a Juniper VPN with 64 bit Linux. I suggest trying this method before reading ANY MORE of this article.

* Direct link: http://ubuntuforums.org/showthread.php?p=11189826#post11189826

Thank you Eccentric.Ash for bringing this to my attention in the comments. The approach in the linked forum post is much much easier to implement. And a special shout out to dvo over at ubuntuforums.org for sharing this solution.


Useful script: I received an email from a nice fellow, also named Scott, who produced some code to automate this process a bit. With his permission I am sharing the link to his Google Code project here: juniper-vpn.

I’ve been running the 32-bit version Linux Mint 7 for the past month. To date it’s been the most straight forward “everything just works” Linux distribution that I’ve used. And it wasn’t ugly either. But, not quite everything “just works” the way it should. Pulseaudio and the ALSA sound driver for snd-hda-intel just didn’t work very well.

One thing that I was really shocked to see working perfectly, without any intervention on my part was the SSL VPN client from Juniper. It just worked and it worked very well

B+ for Linux Mint and A+ for Juniper. Good job folks!

Er, not so fast. 32-bit Linux is getting kind of dated. My machine is a Core2 Duo, 64-bit, so it’s kinda silly not to take advantage of that. And to top it off, Unbuntu 9.10 Beta was just released.

I installed it. It went quite well. I installed it right over the Windows XP partition I had been saving for absolutely no sensible reason. Later Windows!

Then I tried to log into the VPN.

It did nothing.

I felt sad.

So I put on my hacker hat and started digging. Starting, of course, with a Google search that turned me onto a nice solution that some other gentleman had worked out. Unfortunately it wasn’t quite enough. We use a two-phase auth scheme and this only supports a one phase. We need a username, password, and RSA token. This script assumes you only use a PIN+RSA token as a single password. The fortunate part is that his script really identified all of the key pieces so I could eventually solve the puzzle. But it wasn’t as obvious as it should have been.

Here’s how the Juniper SSL VPN client works (for Linux):

You:
  1. Log into a secure web site
  2. Click the Start button for the SSL VPN client
They:
  1. This launches a Java applet that in turn launches a Java webstart app
  2. Downloads some files (into $HOME/.juniper_networks directory)
  3. Explodes a jar file (into $HOME/.juniper_networks/network_connect)
  4. Checks for the tun device
  5. Extracts the actual VPN client software
  6. Prompts you for superuser password
  7. chowns root:root the VPN client software
  8. chmods 4775′s the VPN client software
  9. Runs the VPN client software, communicating with the Java app via IPC. It’s … fascinating.

In a 32-bit Linux system this works wonderfully well. It’ll also auto update which is very cool.

In a 64-bit Linux system not so much. It pretty much just chokes when the dynamic linker tries to pull in a file called libncui.so, which happens to be a 32-bit ELF binary.

But the show doesn’t end here. The application is still present in $HOME/.juniper_networks/network_connect.

By now you are either very bored or you are thinking, well hey, why not just run the application and give the DSID! If so, then you are pretty much on the same page as I was at the time. But get this. There is *no* way, to my knowledge, to give that stinking DSID to that stinking ncsvc application without jumping through the same IPC hoops as the Java app. Well, I’m not about to try and debug *that*. No thank you!

But wait a minute… Doesn’t the Mad Scientist’s script mentioned above work? It must be providing that DSID right? Not quite. The ncsvc application actually does provide some command line switches that are really useful. Here’s what the usage string looks like:

usage: ./ncsvc -h host -u user -p passwd -r realm -f cert_file [-L log_level] [-g] [-U sign_in_url]
       ./ncsvc -v
       ./ncsvc -K

    log_level : 0 : Log Critical messages only
                1 : Log Critital and Error messages
                2 : Log Critital, Error and Warning messages
                3 : Log Critital, Error, Warning and Info messages(default)
                4 : Log All Verbose messages
                5 : Log All messages
    -v : Print version information and quit
    -g : Zip and upload logs to host
    -K : Kill all running ncsvc services

Notice, there is a -p for password? That’s great, but we need two passwords in a two phase auth scheme. There isn’t  a -pp or a –second-password or any other such switch. There just isn’t any bloody way to suff that 2nd password down its throat.

At this point it’s time to start digging through all of the files that are included with the VPN app. There is more to it than just ncsvc. Quite a bit more. Here is the listing:

  • installnc.log
  • missing.info
  • ncsvc
  • version.txt
  • NC.jar
  • installNC.sh
  • libncui.so
  • ncdiag
  • xlaunchNC.sh

Some shell scripts that prove mostly useless and a couple of logs containing anything but useful information.

The files that look interesting are ncsvc (obviously), NC.jar, ncdiag, and libncui.so.

At this point I hadn’t a clue where to look so I started with the NC.jar file. I figure I could jar xf it, javap all of the class files and see if they led me down any interesting paths, I could try to run it withjava -jar NC.jar … Aha! More command line switches, and they look like this:

usage: ncui -h host -u user -p passwd -r realm -f cert_file [-l log_level] [-L log_level]
       ncui -h host -c cookies -f cert_file [-l log_level] [-L log_level] [-U sign_in_url]
       ncui -v
    log_level : 0 : Log Critical messages only
                1 : Log Critital and Error messages
                2 : Log Critital, Error and Warning messages
                3 : Log Critital, Error, Warning and Info messages(default)
                4 : Log All Verbose messages
                5 : Log All messages

Yep, typo’s and all. “Critital” haha… Nice. But isn’t that -c option looking pretty tasty? Yessss! Let’s give it a shot…

bash$ java -jar NC.jar -h myhost -c DSID=nnnnn... -f ssl.crtInvalid parameter -c

Major let down. MAJOR let down. I spent a good while trying to get that parameter accepted. My perseverance finally paid off when a quick strings * revealed the true source of that usage string that NC.jar spewed forth. It was in libncui.so. Now what kind of shared object file has a usage string inside?

DING DING DING! We have a winner!

With little fanfare I continued my hacking until I finally came up with the solution:

  1. Install gcc-multilib for 32bit compiler/linker support
        apt-get install gcc-multilib
  2. Build an executable from libncui.so and call it ncui.
        gcc -m32 -Wl,-rpath,`pwd` -o ncui libncui.so
  3. Chown and chmod that executable to be suid root
        sudo chown root:root ncui
        sudo chmod 4755 ncui
  4. Run it with the same parameters we used when running NC.jar
        ./ncui -h myhost -c DSID=nnnnn... -f ssl.crt

The cursor just blinked at me.

It didn’t fail.

There wasn’t an error message.

Did it work?

Yes! Glorious success! It worked! A quick run of netstat -nr revealed that all of the VPN specific routes were present, I could resolve names, and I could ping the resolved IP addresses. I could access services. Everything looked just a little brighter.

In total I probably spent about 12 hours of my weekend painfully going through all of the motions to finally get to a working VPN client. Next I’ll spend a few hours writing up some dandy ruby code that logs me into the VPN from the command line. No more web browser. Not necessary.

In summary, if you are looking for the final solution it goes exactly like this:

Prerequisites:

  • gcc-multilib installed
        sudo apt-get install gcc-multilib
  • parital install of network connect in $HOME/.juniper_networks/network_connect
        libncui.so ncsvc

First time:

  1. Build your ncui executable:
        cd $HOME/.juniper_networks/network_connect
        gcc -m32 -Wl,-rpath,`pwd` -o ncui libncui.so
  2. Get your HOST SSL certiciate:
        echo |
          openssl s_client -connect (your host):443 2>&1 |
          sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' |
          openssl x509 -outform der > ssl.crt

Every time:

  1. Log into your VPN web site normally and fetch the DSID cookie. In your browsers location bar enter:
        javascript:alert(document.cookie)
  2. Run the VPN client
        cd $HOME/.juniper_networks/network_connect
        ./ncui -h <your host>\
               -c <your cookie>\
               -f ssl.crt
  3. If prompted for a password just press ENTER.
  4. Enjoy the fruits of your labor!
 Posted by at 4:00 am
Oct 272009
 

Mephisto sure was a pain to maintain. It got to a point where I couldn’t even post a message any longer and it was quite possible that you’d get an error if you ever clicked a link that wasn’t on the home page.

So here we go.

Starting fresh. Like opening up ‘vi .plan’ in my home directory, entering :1,$d^M then :wq^M. It’s all gone. POOF!

Where to go from here… Beats me. We’ll just have to wait and see I guess.

 

 Posted by at 4:14 am