What could you do with your code in 20 Lines or Less? That's the question I ask every week, and every week I go looking to find cool new examples that show just how flexible and powerful iRules can be without getting in over your head.

Here we go again, three more examples of the powerful and interesting things you can do with iRules in less than 21 lines. Dipping again into the forums, with a few tweaks here and there (don't worry, I stayed honest to the rule, just took out comments and extra case comparisons, that kind of thing), we've got an action packed 20LoL this week.  Here we go:

SSL iRule on a non-SSL VIP

http://devcentral.f5.com/Default.aspx?tabid=53&forumid=5&postid=26299&view=topic

This is a great example of using a single iRule for both HTTP and HTTPS traffic. In the forum post Deb shows a cool trick to allow us to sneak SSL commands past the iRule interpreter so that they are there when we need them, if a cert is found, but aren't used when the connection turns out to be straight HTTP.  Pretty cool stuff.

when HTTP_REQUEST {
  HTTP::header replace ClientIP [IP::remote_addr]
  if {[PROFILE::exists clientssl] == 1} {
    set cname "SSL::cipher name"  
    set cbits "SSL::cipher bits"  
    set cver "SSL::cipher version"  
    HTTP::header replace SSLCipher [eval $cname]:[eval $cbits]-[eval $cver]  
    if { [SSL::cert count] > 0} {
      HTTP::header replace SSLSubject [b64encode [X509::subject [SSL::cert 0]]]
      HTTP::header replace SSLClientCert [b64encode [SSL::cert 0]]
      HTTP::header replace WebProtocol "HTTPS-auth"
    } else {
      HTTP::header replace WebProtocol "HTTPS"
    }
  } else {
    HTTP::header replace WebProtocol "HTTP"
  }
}

 

Extracting DHCP Info

http://devcentral.f5.com/Default.aspx?tabid=53&forumid=5&postid=25727&view=topic

This example for extracting DHCP info is very specific. It's looking for option 82 (Support for Routed Bridge Encapsulation) which may not be particularly useful to everyone out there, but the example stands as a great display of how iRules can help you tear into almost any kind of data, even DHCP data, and make intelligent decisions or actions based on that. Sure, it might take some re-working for your purposes, but what a cool example to get started with!

when CLIENT_DATA {
  binary scan [UDP::payload] x240H* dhcp_option_payload
  set option 0
  set option_length [expr {([UDP::payload length] -240) * 2 }]
  for {set i 0} {$option != 52 && $i < $option_length} {incr i [expr { $length * 2 +2 }]} {
    binary scan $dhcp_option_payload x[expr $i]a2 option
    incr i 2
    binary scan $dhcp_option_payload x[expr $i]a2 length_hex
    set length [expr 0x$length_hex]
  }
  if { $i < $option_length } {
    incr i -[expr { $length * 2 -2 }]
    binary scan $dhcp_option_payload x[expr $i]a2 length_hex
    set length [expr 0x$length_hex]
    incr i 2
    binary scan $dhcp_option_payload x[expr $i]a[expr { $length * 2 }] circuit_id
  } else {
    drop
  }
}

 

URI re-writing based on Load Balancing decision

http://devcentral.f5.com/Default.aspx?tabid=53&forumid=5&postid=25791&view=topic

Talk about a chicken and egg demonstration. Hearing the title, you might think I have it backwards. When making this kind of decision in an iRule, the URI is often used to help make the load balancing decision. In this case, it's just the opposite. In this example we're letting the BIG-IP make a load balancing decision, then going back and updating the URI based on that decision, before the request is sent to the servers.  Very cool stuff!

when HTTP_REQUEST_SEND {
  set uri [string tolower [clientside {HTTP::uri}]]
  log local0. "[IP::client_addr]:[TCP::client_port]: selected server details: [LB::server] - \$uri: $uri"
  if {[IP::addr [LB::server addr] equals 10.207.225.101] or [IP::addr [LB::server addr] equals 10.207.225.102] or [IP::addr [LB::server addr] equals 10.207.225.103] }{
    log local0. "[IP::client_addr]:[TCP::client_port]: matched server check for .3 or .4"
    switch -glob [HTTP::uri] {
      "*/gsfo/gsfopub*" {
        clientside {HTTP::uri "/Async/CMReceive.ashx"}
        log local0. "[IP::client_addr]:[TCP::client_port]: updated URI to /Async/CMReceive.ashx"
      }
      "*/era/erapub*" {
        clientside {HTTP::uri "/Async/ERAReceive.ashx"}
        log local0. "[IP::client_addr]:[TCP::client_port]: updated URI to /Async/ERAReceive.ashx"
      }
      default {
        log local0. "[IP::client_addr]:[TCP::client_port]: didn't match URI checks"
      }
    }
  }
}

 

There you have it, the forums deliver yet again. I have to say I love checking out all these cool, new, compact examples of iRules goodness. Many thanks to the awesome DevCentral community for their continued contributions. I'll see you next week for another 20 Lines or Less.

#Colin

So it looks like Joe and I are going to have to take a trip down to San Fran to check out Nick's Crispy Tacos with Jason Hoffman, CTO and co-founder of Joyent. Jason puts on a "Taco Tuesday" on the third Tuesday of just about every month.  We've been invited down to check it out and geek out over the hawesome iRules/iControl/Ruby/*Nix/geeky stuff they're doing. Yeah...I'm not completely geeking out and excited, honest. Don't worry though, we'll try to make the best of it.

We got a fantastic opportunity today to talk with Jason about Joyent, what they're doing, their architecture, their background, etc. and how they're heavily leveraging F5 technology to make it all happen.  For those of you that don't know, Joyent is a long-time F5 customer that provides a wickedly cool, scalable, flexible cloud infrastructure to users ranging anywhere from the Mom and Pop size to truly robust Enterprise level applications. You may have seen Joe's blog post about Joyent hosting LinkedIn's BumperSticker Facebook app that recently surpassed a billion page views per month. That spurred an offer to chat, and Jason was more than happy to oblige.

It was absolutely fantastic to talk to Jason who himself is an avid engineer that's got a long history with Unix and many of the flavors of coding that go along with it. As one of the first major adopters of Ruby and, in fact, the very first person to check in source to the Rails source control system, he definitely knows what he's talking about when it comes to *Nix programming, Ruby, and RoR. It turns out we even share a common love for and history with FreeBSD, go figure.

Over the course of our discussion we got to chat with Jason about his role at Joyent, what they're delivering to users, why it's unique and powerful, obstacles they faced along they way, how they got around them which, I'm happy to say, largely included F5 technology and specifically iRules and iControl, and many other such things impressively full of win. From many of their security policies relying on iRules instead of FireWalls, to iControl being an integral part of their provisioning system, to building iRules as solutions to countless customer problems or requirements, these guys are definitely power users and avid DevCentral members, I'm happy to say.

We also got to talk about the modern application, how it's architected, how the old school ways of thinking don't apply anymore and the massive benefits that can come from allowing yourself to see the possibilities with a modern, flexible, layered architecture. This architecture with powerful caches, application aware network devices serving large portions of the application functionality, and scalable, interchangeable back ends thanks to the load balancing that also occurs at that tier is hugely powerful and really more and more of a "must have" as things continue to progress in the application and application delivery world. Pretty darn cool stuff to hear from a PhD helping to run a hugely popular and successful hosting company. How's that for real world application?

This is the exact message I (we) have been pushing for a long time. Every time I talk about "preaching the good word", this is what I'm talking about. Times have changed, technology has improved, and F5 can be a big part of building a powerful, flexible, scalable, reliable architecture if you just let yourself think about things in the new, more modern world that Jason and Joyent have fully embraced. It's allowing them to be as powerful and usable as they are at extremely reasonable costs with incredible scalability as needed.

Check out the podcast to get more of the details. Obviously I'm excited, and am currently trying to refrain from a big squeeeee of geekitude, but that's just how I get when I get to riff about awesome technology with even more awesome people.

Stay tuned for the follow up where Joe and I tear into some tacos, margaritas and hopefully some iControl/Ruby/iRules with Jason down in his neck of the woods. Not that it's been approved yet or anything, but hey, I can hope, right?

Thanks again Jason for the great chat, and keep up the killer work.

#Colin

This week's Top5 takes you from Application Health Monitoring to queues formed by CS students. The team has been hard at it, as always, and there's plenty to dig through on DevCentral this week. Choosing just five things to talk about seems to be an increasingly difficult task thanks to the mounds of content out there every week, but that's a good problem to have. Here are this week's Top picks:

Scaling Ruby on Rails to 1 Billion Page Views a Month

http://devcentral.f5.com/weblogs/Joe/archive/2008/07/15/scaling-ruby-on-rails-to-1-billion-page-views-a.aspx

Joe talks about Joyent's successful scaling of their Ruby on Rails deployment for Linkedin's "BumperSticker" Facebook app to a billion page views a month. That's some pretty serious traffic, and an awesome accomplishment to be able to tout. It's doubly important due to the naysayers out there that would have you believe that Ruby on Rails doesn't scale for high traffic situations. Joe talks about some of the finer details of this recently announced achievement as well as inviting them to jump on a DC podcast with us, which I'm pleased to say they agreed to. Definitely keep an eye out for that chat!

Storage - Where do we go from here?

http://devcentral.f5.com/weblogs/dmacvittie/archive/2008/07/14/3449.aspx

It's no surprise to anyone that's been around computers even a short while that data storage is growing at an amazing rate, as is the demand for storage space due to increased use of media and more and more users of resources already in place. Don shows off some of his in-depth experience in the storage arena by delving into a discussion of different issues facing the storage community these days. He talks about stale data, data tiering, high-speed filers and more. Discussing about different methods of using and dealing with each, this post is definitely worth a read.

20 Lines or Less #11

http://devcentral.f5.com/weblogs/cwalker/archive/2008/07/16/20-lines-or-less-11.aspx

Back on track with three examples each weighing in under 21 lines, this week's 20LoL continues to demonstrate the power you can pack into easily written and managed, short iRules. Feel free to drop in a request for an iRule you need written to solve a certain problem or requirement and who knows, your solution might just be featured in the next 20 Lines or Less. Take a peek and tune in every week as we continue on our exploration of the possibilities that iRules offers to deliver compact yet powerful solutions.

DC Post of the Week - Application Health Monitors: Alternate Ports

http://devcentral.f5.com/weblogs/dctv/archive/2008/07/17/3461.aspx

Deb dives into the Post of the Week yet again to highlight a question asked in the forums, giving an in-depth answer and example to go with it. This week she's addressing Health Monitors and trying to monitor a member of a pool on a port not configured for the pool. Tune in for a walk-through and discussion of how this can be done, benefits, caveats and more.

A queue is a (a) line (b) a pony tail (c) a data structure

http://devcentral.f5.com/weblogs/macvittie/archive/2008/07/14/3448.aspx

In our only multiple choice blog post of the week Lori agrees with a fellow blogger's assertion that "The most agile developers, however, are those who approach programming with a firm grounding in computer science." I suppose that means I'm off that list, but I won't hold that against her. This insightful and interesting post discusses the way that programming has evolved and works in today's world, and why those computer science degrees that actually focus on, well, computer science, might be more valuable than some people think. Take a look inside to see why.

Safely through another five awesome topics from DevCentral, here we are, at the end of this week's Top5. I'll be back next week with more DC goodness. Until then, feel free to drop me any feedback you might have.

#Colin

What could you do with your code in 20 Lines or Less? That's the question I ask every week, and every week I go looking to find cool new examples that show just how flexible and powerful iRules can be without getting in over your head.

This week's 20LoL comes care of both the codeshare and the forums alike.  I got to deal with a couple of particularly cool forum posts this week, one of which made the list, as did an iRule from the infamous hoolio himself. Dealing with HTTP and ranging from spiders to working around a work-week, these examples are yet more ways you can leverage iRules in less than 21 lines. Here we go:

Rate Limiting Search Spiders

http://devcentral.f5.com/Default.aspx?tabid=53&forumid=5&postid=26064&view=topic

Spiders on the web aren't the same pests as spiders in your house, but they can certainly have adverse effects if they're making an inordinate number of requests to your web-servers, and driving the load up.  Here's a cool example of how to avoid just that scenario. We've seen something similar a long time ago on DevCentral for Network Computing, but this is a good refresher.

when RULE_INIT {
  array set ::active_crawlers { }
  set ::min_interval 1
}

when HTTP_REQUEST {
  set user_agent [string tolower [HTTP::header "User-Agent"]]
  # Logic only relevant for crawler user agents
  if { [matchclass $user_agent contains $::Crawlers] } {
    # Throttle crawlers.
    set curr_time [clock seconds]
    if { [info exists ::active_crawlers($user_agent)] } {
      if { [ $::active_crawlers($user_agent) < $curr_time ] } {
        set ::active_crawlers($user_agent) [expr {$curr_time + $::min_interval}]
      } else {
        reject
      }
    } else {
      set ::active_crawlers($user_agent) [expr {$curr_time + $::min_interval}]
    }
  }
}

Compression During the Work Week

http://devcentral.f5.com/Default.aspx?tabid=53&forumid=5&view=topic&postid=25992

Coming through with a great example of how to have compression enabled only from 8AM-5PM, otherwise known as the normal US Workday, citizen_elah shows of his iRules kung fooery to help a fellow community member out. This same logic could be applied to almost anything else, besides compression, making this a great iRule to keep around in your back pocket.

 when HTTP_RESPONSE { 
   set time_r [split [clock format [clock seconds] -format {%H:%M} ] " "] 
   set time_f [expr [expr [lindex $time_r 0]*100] + [lindex $time_r 1]] 
   if { not(($time_f >= 0800) && ($time_f <= 1700)) } { 
     COMPRESS::disable 
   } 
 } 

I then came through and offered some optional optimization, so I guess this could be considered your bonus-rule for the week.  It's easy when someone like elah does the legwork up front. ;) Check the link to see the extra example.

Fully Decode URI

http://devcentral.f5.com/wiki/default.aspx/iRules/FullyDecodeURI.html

Representing the last leg of this HTTP tri-ath-a-post is an entry from our illustrious iRules CodeShare. This example shows how to be sure you're FULLY decoding your URI before processing. It correctly points out that sometimes encoded characters can contain encoded characters can contain encoded characters can contain....well, you get the point. See how one person decided to work around such issues in a scant 11 lines of code.

when HTTP_REQUEST {
  # decode original URI.
  set tmpUri [HTTP::uri]
  set uri [URI::decode $tmpUri]

  # repeat decoding until the decoded version equals the previous value.
  while { $uri ne $tmpUri } {
    set tmpUri $uri
    set uri [URI::decode $tmpUri]
  }
  HTTP::uri $uri

  log local0. "Original URI: [HTTP::uri]"
  log local0. "Fully decoded URI: $uri"
}

There you have it, three more choice examples of iRules goodness in 20 Lines or Less. Tune in again next week!

#Colin

After a Friday off for the holiday here in the states, we're back at it again, and DevCentral is as busy as ever.  There's been some great content and some really fantastic banter alike on the site this week. Today we'll dive into cookie security, go back in time with iControl, and more, but not to worry, I'll step you through it all so you don't get lost in the white water of information rushing through DevCentral. Please keep all hands inside the raft, here's this week's Top5:

Persistent and Persistence, What's the Difference?

http://devcentral.f5.com/weblogs/macvittie/archive/2008/07/11/3443.aspx

Two words that can often times be incorrectly used interchangeably are discussed and defined by the esteemed Lori Macvittie. In this useful and in-depth blog post Lori delves into the intricacies of each term, why they should be clearly separate in your mind, and some uses and advantages of each.  If ever you had some doubt as to what each term meant, now's the time to clear it up, and this is the place to do it.

DC Post of the Week - Application Health Monitors : Response Strings

http://devcentral.f5.com/weblogs/dctv/archive/2008/07/10/3440.aspx

If you're one of the many people out there looking at just the status code of your HTTP responses to determine the health of your application, you may want to take a look at this week's Post of the Week. Deb talks about why it's sometimes important to do more in-depth, application appropriate monitoring to get a look at what's really going on, and the experience users are actually getting. Blank web-pages being served efficiently doesn't do anyone any good.

Tech Tip: Cookie LoJack via iRules

http://devcentral.f5.com/Default.aspx?tabid=63&articleType=ArticleView&articleId=251

This week I got to write about an awesome iRule submitted by Aidan Clark, one of our many awesome engineers in the field.  This outstanding example of iRules usage shows how you can add an additional layer of security to your cookies, even if they're already being encrypted. There is much hawesome and cool contained in the rule, so make sure you take a look at yet another way that iRules are changing the game, every day.

iControl 101 - #19 - Time Conversions

http://devcentral.f5.com/Default.aspx?tabid=63&articleType=ArticleView&articleId=252

I was convinced that time travel was something relegated to fiction novels and white-haired professors with DeLoreans, but Joe has proved me wrong it seems. Joe goes through the iControl methods that allow you to return system time, along with many formatting methods and options for those methods. In this way you can truly be in control of time, and make sure you're getting the results you need. Yet another cool example of just how in-depth and robust iControl really is.

3 Reasons not to use Apache mod_rewrite

http://devcentral.f5.com/weblogs/macvittie/archive/2008/07/07/3428.aspx

And now for the most hotly debated blog post on DC in recent memory, and possibly ever. Take a look inside as Lori gives her view on Apache mod_rewrite and why you are likely better served by offloading that functionality to an Application Delivery Controller, possibly even via an iRule.  She makes some excellent points and definitely stirs the pot. Check out the excellent post and the impassioned and interesting follow-up comments.

There's another Top5 for you. As always, keep in mind that DevCentral has a lot more than I can put in just one distribution a week, so be sure to poke around yourself. Feedback is welcomed and encouraged.

Thanks!

#Colin

There I was, poised on the precipice of doom, fighting back the hordes of upgrade gremlins with naught but my wit, my savage faith in my distro, and these two hands when all of a sudden there was a blinding light and silence overwhelmed me. I was warm. I was calm. All was well. Ubuntu had delivered me into the safety of my new version, running smoothly with all of my settings, configurations, scripts and cookies wrapped with a shiny new v8.04 bow, ready to be played with.

I swear that's how it happened. That's my story, and I'm sticking to it.

I'm relieved pleased to report that the daunting, multi-version upgrade of my Linux system here at DCHQ went swimmingly. I really have to hand it to those guys over at Ubuntu. They've completely changed my experiences with Linux distro "auto-upgrades" for the better. I'm sure this is a common thread amongst distros, as I know how closely tied they all are (especially since Ubuntu is really lipstick on Debian ... I know, I know...) but I can't help but feel just that much more impressed by and committed to this particular offering now that it's served me so faithfully.

So there you have it, in case any of you are wondering my recommendation for which (at least desktop) Linux distro to choose, I say go with Ubuntu. It gets my seal of approval.

#Colin

So here I sit, working away on my windows box, watching my Ubuntu system churn away, fetching packages for the impending upgrade.  I saw that 8.04 LTS was released, so I figured it was time to move from my old and dusty, previous LTS release to this presumably hot and tasty new offering.  After downloading a scant 1530 packages, I'll be ready to start installing the upgrades. I'll try to bite back my overwhelming sense of exuberance so as to not cause a monsoon like wave of jealousy to wash over you as you behold in sheer awe induced stupor the phantasm of a life that I lead, bereft of all menial tasks.

I know this would take less time if I upgraded more often, but frankly, that idea induces a shrieking howl from the very core of my being. The sharp sting of the pain caused by the uncertainty I've long felt while waiting, with bated breath, for a system upgrade to complete could most aptly be compared with a thunderous Chuck Norris roundhouse to the face. I mean to say that I'm not exactly a fan of the upgrade process, in general. Waiting for long periods of time while unseen servants whisk packages to and fro, rending from the stable walls of my environment the old, only to just as urgently fill the gaping space suddenly left by the absence of the once merrily functioning piece of a larger framework with a new, polished, yet vastly unknown version, claiming to be better, faster, stronger, is not my ideal day at the park, as it were.

It is with blind faith normally reserved for some ghostly, floating deity that I sit idly by while this rampant demolition and reconstruction of a vitally important tool, used for my very livelihood is performed. This is more apt than expected, as many a time have muttered prayers and pleadings with any and all such omnipotent figures that may be listening left my lips in hopes of somehow swaying their will to spare but an ounce of their unbridled power to ensure the safe and successful upgrade of the system currently undergoing renovation.

On deaf ears these pleas have fallen for too long. That is, until I found Ubuntu. Long had I roamed countless deserts and wastelands in search of a system that would move from one version to the next swiftly and easily, without raining down terror and destruction on my carefully tuned settings and automation devices. Ubuntu has filled that void, much to my relief.

Yet, even given its flawless (knock on wood) track record of successful upgrades, I can't help but squirm and shiver a bit from time to time as I watch the blinking light telling me that the whirring sound I hear is indeed my beloved hard drive spinning at a frantic pace in a desperate attempt to keep up with the rapidly fluxing data as the upgrade trudges ever onward. The very same hard drive on which I've faithfully stored countless files, folders and even tiny fragments of my very soul for safe keeping. Logically I'm confident and sure that the upgrade will go smoothly, but somehow there is a chilling, unrelenting horror bottled inside somewhere, gurgling just beneath the surface of my currently calm demeanor, threatening to overwhelm. I only hope that my faith in the automated upgrade process that has served me well before is still soundly placed.

Well, if you need me, I'll be the one in the corner, muttering.

#Colin

Well it's a short week for me here in DCLand. I'm trying to figure out where it's gone, suddenly realizing it's already 4:30 on Wednesday evening, and I'm soon to be gone for the week. I'm not in tomorrow in preparation/celebration, since Friday is the 4th of July. I'm looking forward to it this year as it's going to mean a BBQ out at the fam's place and blowing things up that turn into big, shiny, sparkly things. That's always fun, no?

The most fun part of the event for me is going to be showing all the younglings what it's like to set off fireworks, some for their first time. Don't worry, I start them all out with only small stacks of explosives and those stick lighters with extra long handles.  You know, for safety. It's not until they're 11 or 12 that I pass out the butane torches.

This week has been a busy one for me, at work and outside it. I've had some fun at the Dr. recently, my car's tags expired which was an ordeal I won't even get into, and I've been trying to tie up a few things at work before I leave. I'm sure I'll be checking in over the weekend at least a little, but that's only because I'm addicted to this place in no small way, which is good, right?

So, for those of you out there also celebrating the 4th this week, play safe, enjoy, and I'll see you next week.  For those that aren't ... well ... be safe, enjoy, and I'll see you next week, too. I leave you all with an image of Seattle's beloved Space Needle, bursting into flames fireworks. Booyakasha.

#Colin

With the amount of content washing constantly across the pages of DevCentral it can sometimes be impossible to keep up with everything, or to know what to read first. It's because of this that I started the Top5 series.  The intent is to allow me to act as your guide and lead you by the hand to point out the Top 5 things that I would choose to make sure you saw amongst the many awesome things gracing the DC pages in a given week. Broadening the reach of this series, I'm going to start making it a part of my blog, so you'll always be able to access the entries from weeks gone by. You'll also be able to access it easily to forward on the link to others or to re-view it as it will be a permanent fixture on my personal page in the about the team section.

In any event, you'll be able to check here each week to look for the Top5 highlights of DC goodness throughout the week, hand-picked by yours truly or an esteemed guest writer when I'm not available. Please feel free to let me know what you think. Things you'd like to see in coming weeks, comments, questions, and all other non-encoded communiqué can be delivered by way of comment directly here. Without further adieu, this week's Top5:

Election Hash Load Balancing

http://devcentral.f5.com/weblogs/dctv/archive/2008/06/26/3399.aspx

In this interview, Deb talks with one of our talented Field Engineers, Nathan, and discusses just what Election Hash Load balancing is, what makes it tick, why it's valuable, and why it's something that's fairly tricky to implement - unless you have iRules.  They get pretty detailed about just how the LB decisions are made and how this unique setup can be of immense value in certain situations like fronting large caches. Take a peek to see one heck of a cool iRule at work, discussed by the brain behind it, and one of DC's very own brains.

 iControl Apps - #02 - Local Traffic Summary

http://devcentral.f5.com/Default.aspx?tabid=63&articleType=ArticleView&articleId=245

Joe's at it again, scripting up cool and useful new iControl toys. In this most recent addition to the iControl Apps series Joe talks about the Network Map component in the GUI of the BIG-IP, and how to replicate some of the functionality contained within by use of, you guessed it, iControl.  Joe lays out some great examples of iControl and Powershell command usage, and gives you some very handy bits of code, as well as a link to the complete picture in the iControl codeshare.  Take a look and see what kind of useful numbers you can pull to get a bigger picture of your BIG-IP and what it's doing.

On Walden's (very secure) Web

http://devcentral.f5.com/weblogs/macvittie/archive/2008/06/25/3388.aspx

In this post to Lori's popular blog she talks about Web Application Firewalls and Web Application Security in general.  I enjoy the discussion she has about what it would take for a developer to "truly" secure an application, especially requirement #10. She touches on some important elements of Web Security and some of the issues that are faced today. This one's definitely worth a read.

Selective DNS Persistence on GTM

http://devcentral.f5.com/Default.aspx?tabid=63&articleType=ArticleView&articleId=243

Persistence is a concept that's been around for a long time now. Most of use are probably pretty comfortable with the term and what it means, as well as using it in our deployments where necessary.  What about DNS Persistence, though? In this Tech Tip you'll get a peek at how iRules on your GTM device can allow you to selectively enable DNS level persistence.  Read more to find out when this might be useful, and see an example of the simple iRule that can get you there.

Making Use of kSOAP2 at Dr. Dobbs

http://devcentral.f5.com/weblogs/dmacvittie/archive/2008/06/24/3385.aspx

It's a banner day when one of our very own here at DC get published in a publication like Dr. Dobbs. Our esteemed colleague Don MacVittie has done just that this month, and the article is well worth a look. Inside he'll talk to you about the use of kSOAP2, how it can be a boon in an ever increasingly mobile world, and how iControl and kSOAP2 can play nice together to build some wicked cool remote apps for your mobile device. Remote management of the BIG-IP via a mobile device? Why sure, we can do that, just ask Don. The link above is to his blog mentioning this awesome achievement, here's a direct link to the Dobbs article.

That's it for this week's Top5. Check back every Friday for another edition, and I'll help you keep an eye on what I think you need to know.  There's plenty more where this came from, though, so don't be afraid to dig in yourself, and take in the rest of the awesome content DC has to offer.

#Colin

What could you do with your code in 20 Lines or Less? That's the question I ask every week, and every week I go looking to find cool new examples that show just how flexible and powerful iRules can be without getting in over your head.

With another three examples of cool iRules, this week's 20 Lines or Less shows even more things you can do in less than 21 lines of code. I still haven't heard much from you guys as to the kinds of things you want to see, so make sure to get those requests in.  I can build all sorts of neat iRules if you just let me know what would be helpful or interesting.  Otherwise I might just make iRules that make iRules. Scary.

This week we've got a couple forum examples and a contribution to the codeshare. Here's your epic, 10th edition of the 20LoL:

HTTP Headers in the HTTP Response

http://devcentral.f5.com/Default.aspx?tabid=53&forumid=5&postid=25423&view=topic

Dealing with HTTP headers is one of the most common tasks we see in iRules. One of the things that I've seen floating about the forums and elsewhere lately is the question of how to access that information in the Response portion of the HTTP transaction. Some people have had a problem with this, as many of those headers no longer exist (like, say, the host). It's a simple solution though, as you can see below...just use a variable to get you there.

when HTTP_REQUEST {
  # Save the URI
  set uri [HTTP::uri]
}
when HTTP_RESPONSE {
  if {([HTTP::header Cache-Control] eq "private, max-age=3600") and ($uri ends_with “.html”)} {
    HTTP::header replace Cache-Control "public, max-age=3600"
  }
}

Persistence equality in RDP sessions

http://devcentral.f5.com/Default.aspx?tabid=53&forumid=5&postid=25271&view=topic

This example solves an issue with mixing Linux and Windows based RDP sessions across a persistence enabled virtual Apparently there's an issue with trying to persist based off of the user string as some clients include user@local.host and others just include the username. That's a bit of an issue.  iRules to the rescue, as always.

when CLIENT_ACCEPTED {
  TCP::collect
} 

when CLIENT_DATA { 
  TCP::collect 25 
  binary scan [TCP::payload] x11a* msrdp 
  if { [string equal -nocase -length 17 $msrdp "cookie: mstshash="] } { 
    set msrdp [string range $msrdp 17 end] 
    set len [string first "\n" $msrdp] 
    if { $len == -1 } { TCP::collect } 
    if { $msrdp contains "@" } { 
      if { $len > 5 } { 
        incr len -1 
        persist uie [getfield $msrdp "@" 1] 10800
      } 
    } else { persist uie $msrdp 10800 } 
  } 
  TCP::release 
}

Pool Selection based on File Extension

http://devcentral.f5.com/wiki/default.aspx/iRules/PoolBasedOnExtension.html

Taking a page from the codeshare, this iRule lets you build a correlation of file extensions and pools that serve those particular file types. This can be quite handy when dealing with large scale image servers, media systems, and especially systems that do things like dynamically generate watermarks on images and the like. Take a peek.

when HTTP_REQUEST {
  switch -glob [HTTP::path] {
    "*.jpg"        -
    "*.gif"        -
    "*.png"        { pool image_pool }
    "*.pdf"        { pool pdf_pool }
    default        { pool web_pool }
  }
}

There you have it; three more examples in less than 60 lines of code. I hope you're still finding this series helpful. As always, feel free to drop me a line for feedback or suggestions. Thanks!

#Colin

Wired delivers an article that has a truly shocking image.  Make sure you read the text in order from smallest to largest.  What a great way to give a perspective of the kind of data that we're processing these days. That's a lot of bytes!

I remember when downloading a 3 Mb file took "forever", and browsing the web I'd get really annoyed at how many images many pages forced me to load.  Okay, I still get annoyed at that one, but that's not their fault. With the pipes getting bigger and the technology ever advancing, we're pushing more and more data for average connections to just about anything these days. That doesn't even take into account all the new ways we're using bandwidth and pushing data since a decade ago: online radio, online gaming, myspace, youtube, etc.

It's amazing to think that F5 boxes sit in the middle of lots of the fabrics of the clouds doing all of this computing at different companies around the world. It really is a feeling of being part of something major; a next step if you will. Pretty cool stuff, really.

Just thought I'd share on a Tuesday afternoon, as it made me grin.

#Colin

It's probably not much of a mystery, for those of you following along at home, that I'm a bit of a music guy.  I play in a band, love music, listen to all sorts of it all the time, etc. etc.  Not much of a logical leap from that is that I tend to also be a bit of an Audio/Video nut.  I have a pretty decent home stereo, love the stuff, geek out about balanced inputs vs. 5-way bindings, speaker sensitivity, the pros vs. cons of working at a lower overall impedance, etc. That said, there is a particular piece of audio gear that is often overlooked by the non-audio-geek types. We even have a special name for it, the "interconnect". 

An interconnect is just a cable. In this case it usually refers to an audio cable that attaches either your devices to each other or the pre-amp/amp in your system, or the amp to the actual speakers. Interconnects tend to get pretty darn pricey, in the high-end audio world, because they get more and more refined. Thicker, higher grade copper, more shielding, more stringent standards, etc. This is because you're often dealing with an analog signal in the audio world, and an analog signal can be distorted by very minute variations along the way as it's being sent, say, from your amp to your speakers. In the digital world, this isn't such an issue. If the data gets there, it gets there, period. It's either a 1 or  a 0, right? So who cares if it's a little fuzzy around the edges, if the receiving system can tell that it's a 1 or a 0, all is well.

Denon, among many other audio manufacturers, seems to be intent on ignoring that little fact. Denon is one of many companies seeking to continue cashing in on high priced cables in the audio arena, even as more and more of the source devices become digital (DVD players, DVRs, etc) and don't require them. They don't seem to care that the digital signals aren't as fragile, and don't require the amazingly high-priced cables that may be seen as "necessary" elsewhere.  They build their cat5 cables to the same standard, and then try to charge the same prices, even though there really isn't any need. How else could one explain paying hundreds of dollars for a patch cable? Even if it is "high purity copper" and "high performance connection parts".

What cable am I speaking of, you ask? Well, in particular, I'm speaking of a 1.5m patch cable that's going for a mind-boggling $499. That's right, folks, I give you the most expensive patch cable in the world.  This is the part where I pause for every geek to shed a few tears, throw their stuffed tux across the room, or stop screaming at the monitor.

I know there is a reason to pay top dollar for some of these parts, but unless I'm painfully mistaken, this is one heck of a service charge for not doing your homework. This happens in every market, not just audio. There are plenty of people out there saying they can deliver the same as the best in class solution when they can't, or promising all sorts of gimmicks and wiz-bang features that you don't need or don't even make a difference, just to charge a few extra bucks, or win the sale.

Don't listen to them. Do your homework, find out what's best for you, and go with that. That's one of the best parts about working here at F5. I never have a problem telling people to just go with the best, because I really think that's us.

#Colin

What could you do with your code in 20 Lines or Less? That's the question I ask every week, and every week I go looking to find cool new examples that show just how flexible and powerful iRules can be without getting in over your head.

This week I've got a combination of entries from our awesome forum users, and a rule I wrote a while back to meet a certain need at the time. We're almost at 10 editions of the 20LoL, and I'm looking forward to many more. Hopefully you're still finding it interesting and useful. Shoot me a line and let me know what's good, what's bad, what can be better and what you want to hear about.

In the meantime, here's this week's 20 Lines or Less

Multi-Conditional Redirect

http://devcentral.f5.com/Default.aspx?tabid=53&forumid=5&postid=25219&view=topic

Hoolio delivers this short and sweet iRules in the forums to show how you can use multiple pieces of data to decide when to perform a redirect.  Not only does he make use of a normal string comparison, but also an IP::addr comparison against the client's IP address. So in one line you're getting two comparisons on two different pieces of data. This is a good example for someone looking to redirect only a small subset of people, based on multiple pieces of data.

when HTTP_REQUEST {
   if { [string tolower [HTTP::path]] ends_with "/_grid/print/print_data.aspx" \

   and (not ([IP::addr [IP::client_addr]/8 equals 10.0.0.0]))} {
      HTTP::redirect "http://google.com"
   }
}

Syslog Priority Rewriting

This is a variation on some actual code I wrote a while back to translate the syslog priority numbers when needed.  Depending on the different syslog configurations, these numbers may not line up. This can be a problem when you're trying to aggregate many syslog systems into one main log server. This iRule shows how you can catch these messages inline and modify them with whatever equation fits your environment.

when CLIENT_DATA {
  set pri [regexp -inline {<\d+>} [UDP::payload] ]
  set newPri [expr ( ($pri - (($pri / 6) * 8) ) ) ]
  regsub $pri [UDP::payload] $newPri newPayload
  UDP::payload replace 0 [UDP::payload length] $newPayload
}

Duplicate Cookie Definitions

http://devcentral.f5.com/Default.aspx?tabid=53&forumid=5&postid=25215&view=topic

Going back to the forums, it seems that hoolio is at it again. In this cool example he shows a fellow community member how to check for and remove multiple Set-Cookie entries with the same name.  This way they can ensure that there is only one cookie present, regardless of how many times different apps may have tried to set it. This one looks a little long, but remove the comments and some of the white space, and it's under 20 lines...I checked.

 when HTTP_RESPONSE {   
  
    # Insert some test response headers 
    HTTP::header insert Set-Cookie {SESSIONID=AAAAAAAA; domain=.domain.com; path=/path/1} 
    HTTP::header insert Set-Cookie {keeper=don't delete; domain=.domain.com; path=/path/2} 
    HTTP::header insert Set-Cookie {SESSIONID=BBBBBBBB; domain=.domain.com; path=/path/3} 
    HTTP::header insert Set-Cookie {SESSIONID=CCCCCCCC; domain=.domain.com; path=/path/4} 
  
    log local0. "Set-Cookie header values: [HTTP::header values Set-Cookie]" 
    log local0. "First Set-Cookie header which starts with SESSIONID: \
      [lsearch -glob -inline [HTTP::header values Set-Cookie] "SESSIONID*"]" 
    log local0. "Last  Set-Cookie header which starts with SESSIONID: \
      [lsearch -glob -inline -start end [HTTP::header values Set-Cookie] "SESSIONID*"]"
  
    set set_cookie_header [lsearch -glob -inline -start end [HTTP::header values Set-Cookie] "SESSIONID*"] 
    log local0. "\$set_cookie_header: $set_cookie_header" 
     
    # Remove all SESSIONID cookies 
    while {[HTTP::cookie exists SESSIONID]}{ 
       HTTP::cookie remove SESSIONID 
    } 
    log local0. "Set-Cookie values: [HTTP::header values Set-Cookie]" 
  
    # Re-insert the last SESSIONID Set-Cookie header	 
    HTTP::header insert Set-Cookie $set_cookie_header 
     
    log local0. "SESSIONID cookie: [HTTP::cookie SESSIONID]"    
 }

There you have it, 3 more examples in under 60 lines of code. Keep checking back every week to see what cool things can be done in just a few keystrokes. Many thanks to the awesome community and the people posting these examples. You're truly making DC a great place to be.

#Colin