DevCentral

20 Lines or Less #15

Colin Walker — Thu, 09 Oct 2008 00:29:05 GMT

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.

Finally back into the swing of the 20LoL, I'm happy to give you the 15th edition of this blog series. Today's offering is brought to you by me, F5, and the power of iRules (tm). Okay, not really (tm), but it sounded cool. I still find myself on a journey to seek out the coolest iRule tidbits that I can in hopes of bringing them to you and showing off just how much power you can pack into a minute amount of code in an iRule. This week's examples are nothing less than that, and hopefully you'll find at least one interesting, if not useful.

Advanced URI Rewriting

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

In this example of rewriting a URI we go well past a simple directory change or query rewrite. This example goes a little further into the realm of the possible to show you how to rewrite a UID that is a portion of a complex URI. Thanks to hoolio and the other iRulers that contributed.

when RULE_INIT {
   # Set a couple of test query strings
   #set source {a=123&k=456&uid=toto&h=789}
   #set source {uid=toto&a=123&k=456&h=789}
   set source {a=123&k=456&h=789&uid=toto}
   # Split the string into a list on the delimiter &
   log local0. "\[split \$source\ &]: [split $source &]"
   # Create a new query string
   set new_query_string ""
   # Loop through the list and create an array of parameters and values
   foreach param_value_pair [split $source &] {
      log local0. "\$param_value_pair: $param_value_pair"
      # If the current param value pair starts with uid=, then prepend it to the list of query string parameters
      if {$param_value_pair starts_with "uid="}{
         set new_query_string ${param_value_pair}${new_query_string}
      } else {
         set new_query_string ${new_query_string}&${param_value_pair}
      }
      log local0. "\$new_query_string: $new_query_string"
   }
   set new_query_string hxs=1&${new_query_string}
   log local0. "\$new_query_string: $new_query_string"
}

HTTP to HTTPS redirect on 401

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

This iRule is built for a very specific deployment scenario which displays some ... interesting behaviors. The requirement was to redirect back to the proper HTTPS URL for the site if authorization was required. This is done to ensure that things are secure where they need to be before allowing people to enter auth information. I know it's not the most straight-forward way of doing things, but this particular deployment didn't have another workaround, so iRules came to the rescue.

when HTTP_REQUEST {
   set host [HTTP::host]
   set uri [HTTP::uri]
}
when HTTP_RESPONSE {
   if {[HTTP::status] == 401]}{
      HTTP::redirect "https://$host/$uri"
   }
}

Multi-Host HTTP Redirection with Switch

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

This example is a slightly trimmed version of the one provided (by hoolio, yet again) in the forum post. It shows some great ways to use a single switch to match many different domains or partial domains when doing a redirect based on a host. The individual pieces are all pretty straight-forward, but it's a great example of how to build a single, elegant logic flow rather than a bulkier if/else chain.

when HTTP_REQUEST {
   log local0. "[IP::client_addr]:[TCP::client_port]: New HTTP request to [HTTP::host][HTTP::uri]"
   switch -glob [string tolower [HTTP::host]] {
      "*newlifepubs.com" {
         log local0. "[IP::client_addr]:[TCP::client_port]: Matched 1"
         HTTP::redirect "http://www.example.com/nlp"
      }
      "*mpd.example.org" {
         log local0. "[IP::client_addr]:[TCP::client_port]: Matched 2"
         HTTP::redirect "http://staffweb.example.org/mpd/index.aspx"
      }
      "staff.example.org" {
         HTTP::redirect "http://staffweb.example.org/"
      }
      "*movementseverywhere.example.com" {
         HTTP::redirect "http://www.example.org/"
      }
      default {
         log local0. "[IP::client_addr]:[TCP::client_port]: No match"
         discard
      }
   }
}

There's another 20LoL for your coding pleasure. Hopefully I've been able to fuel your desire to run out and whip up some awesome iRules yourself. Check back next week for more cool code!

Technorati Tags: 20 Lines or Less,HTTP Redirect,401 Auth Required,HTTPS redirect,Colin Walker

#Colin

A Groundswell of support...

Colin Walker — Fri, 12 Sep 2008 17:47:37 GMT

If you've listened to the podcast this week, or seen the blogs, or haven't been hiding under a rock, then you've heard that we here at DevCentral have entered our community into Forrester's Groundswell awards. We're very excited to be able to add our hat to the ring, as it were, and it's really thanks to all of you out there in DCLand.

We've entered in the "Supporting" category, and that's really all about how much the awesome community we get to be a part of is out there helping each other every day. The direct quote is "SUPPORTING. Help customers support each other to solve each other's problems." If that isn't DC to a T, then I don't know what is.

I'm blown away every single day as we get more and more new users, more posts to the forums, more wiki updates, and more questions being asked just about everywhere...and yet the community keeps stepping up to the plate, and helping out where needed. There's no way we could do what we do without as much involvement, commitment and as many contributions as you all provide, and that's just hawesome. So from me, and all of us, a great big "Thanks, Dudes!".

To submit for the contest we had to come up with a submission page that showed a lot of what's going on in the community. I have to say I was honestly shocked when we got most of it on one page. Holy cow is there a bunch of stuff happening, all the time! You can check it out here. As you'll see on that page, we could really use your votes to make sure everyone knows what's going on here with DC, and how amazing it is. So...vote now! We really appreciate it.

I don't really know what else to say, to be honest. You guys rock. You let us do what we're doing, and you're excited about it the entire time. Thank you for being such rockstars and making DC what it is. It's pretty amazing when I stop and think about the last few years, and what's happened. Let's keep the train rolling, and turn the people that never thought this "community" thing made sense, especially for F5, on their ears.

Technorati Tags: DevCentral,Forrester,Groundswell,Colin Walker

#Colin

DevCentral Top5 8/29/08

Colin Walker — Fri, 29 Aug 2008 19:43:33 GMT

Goodness it's been a while since we've had a Top5, hasn't it? The past couple months have been insane for vacations/medical leave/paternity leave, etc on the DC team. Hopefully things are settling down now, and we can get back to our normal routine. Regardless, here I am, your faithful guide through the oceans of content on DevCentral, committed to bringing you a weekly sampling of the Top5 coolest new things that showed up on DevCentral. Even with parts of the team out, there's been lots of content, so buckle up, here's your Top5:

Dear Data Center Guy

http://devcentral.f5.com/weblogs/macvittie/archive/2008/08/29/3572.aspx

Sometimes the things I pick for the Top5 are the most informative pieces I can find. Other times they're the most exciting and interesting because of some new announcement or content. This one is, well, just plain hawesome. Go check out Lori waxing away from the perspective of a lonely, forlorn BIG-IP. Follow this plea to the "Data Center Guy" and find out why it is that there's more than meets the eye to the BIG-IP, and why it's worth investing some more time getting to know yours.

Crack open the books, it's iRule time

http://devcentral.f5.com/weblogs/Joe/archive/2008/08/29/crack-open-the-books-its-irule-time.aspx

Exciting news from the training group! F5's stellar training team now officially offers and is booking iRules training! This is fantastic news. Up until now the aspiring iRuler had to rely only on their wits, their browser, and the ever-faithful DevCentral. Now there's an organized, formal way to get some hands-on, classroom instruction to get your iRuling experience jump started. This is something that's been a long-time request of the DC members, and I'm very, very pleased to be able to share this great news. Make sure you take a look and read the course description for more info.

iControl Apps - #08 - System IP Statistics

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

Check out Joe flexing those iControl muscles yet again in this continuation of the iControl Apps series. In this edition Joe will walk you through how to query yet more fun statistics type stuff (very technical term) from the BIG-IP via iControl. If you ever wondered how to get access to aggregate, IP based statistics in a programmatic fashion, well, then this is the one you've been waiting for. Even if that hasn't been your dream since high school, this post is definitely worth checking out for more firepower to add to your iControl arsenal.

20 Lines or Less #14

http://devcentral.f5.com/weblogs/cwalker/archive/2008/08/29/20-lines-or-less--14.aspx

In our second week back on track with the 20LoL I manage to find still more cool examples of iRules fu that are byte sized at most. In less than 21 lines you can learn how to distribute email to the appropriate pools based on IP address. If that's not enough, we're doing HTTP inspection without HTTP profiles, too. Confusing? It won't be if you click through and take a gander. Good ole' TCP commands to the rescue. Take a peek, send some comments, add a suggestion.

DevCentral Weekly Roundup Episode 52 - The Road to 100

http://devcentral.f5.com/weblogs/dcpodcast/archive/2008/08/29/3575.aspx

Last, but never least, is this week's DevCentral Roundup. This is a special edition of the podcast this week, because this week we wrapped up our 52^nd chat about DCLand, IT in general, and all sorts of other wacky stuff. With a year's worth of podcasts behind us, it's time to set our sights on 100 and keep on trucking, because there's plenty to talk about every week, that's for sure. This week listen to Don and Joe talk about all sorts of cool iControl applications and twitter and the like, and Colin try to keep up and explain that he's almost caught up from being out for 3+ weeks….honest. The Roundup is always a great way to get a dose of what we've been up to in a short amount of time, without even having to do any of that reading stuff. Have a listen and let us know what you think.

There you have it, your Top5 for this week from DevCentral. It's good to be back, and hopefully you faithful readers out there have been eager for this to get fired back up. If you've got questions or comments please feel free to drop me a line, as always. See you next week.

Technorati Tags: DevCentral,Top5,Colin Walkerer

#Colin

20 Lines or Less #13

Colin Walker — Fri, 22 Aug 2008 23:35:17 GMT

After a couple of weeks out of the office, I'm back at it with your weekly dose of iRules goodness in under 20 lines. This week's 20LoL comes from the forums as well as the codeshare. We've got some great examples here, including one iRule that can be used to help augment an already existing LTM module and give it some extra functionality...cool stuff!

Blocking Content with iRules

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

This is a good example of a robust, logified way to block certain URI parameters from being allowed through to the back-end servers. Aaron's gone to the trouble to both document the code and the output heavily. That might not be the fastest possible solution in production, but it sure is nice for testing.

 when HTTP_REQUEST { 
  
    # Log a debug message with client IP:port and the class contents 
    log local0. "[IP::client_addr]:[TCP::client_port]: class \$::badStrings: $::badStrings" 
  
    # Check if the client IP is part of the hosts datagroup 
    if { [matchclass [IP::server_addr] equals $::Hosts]}{ 
  
       # Log a debug message indicating the client IP matched the Hosts class 
       log local0. "[IP::client_addr]:[TCP::client_port]: matched Hosts class \$::Hosts: $::Hosts" 
  
       # Check if the requested URI contains any known bad strings 
       if { [matchclass [string tolower [HTTP::uri]] contains $::badStrings]}{  
  
          # Log a debug message indicating the client matched the Host class and had a bad string in the URI 
          log local0. "Matched server IP and found bad string in [HTTP::uri]: \
entry# [matchclass [string tolower [HTTP::uri]] contains $::badStrings]"  
  
 	 # Drop the TCP connection	  
 	 drop  
       } 
    } 
 }

MSM Whitelisting

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

This codeshare entry shows how you can use an iRule to get even more out of MSM on your LTM. Oh how I love TLAs. By creating a whitelist of known good IP addresses in this iRule, you can skip MSM processing and wring even more performance out of your BIG-IP...nice!

  priority 1
  when CLIENT_ACCEPTED {  
    if { [matchclass [IP::client_addr] equals $::white_list] } {  
            log local0. "client: [IP::client_addr] found in white_list directed to http_test_pool"  
          pool http_test_pool  
          event disable all  
    }  
    elseif { [matchclass [IP::client_addr] equals $::black_list] } {  
              log local0. " client: [IP::client_addr] found in black_list directed to http_test_pool_2"  
          pool http_test_pool_2   
                     # or discard  
          event disable all  
    }  
  }

Search and Replace via iRule

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

This example shows some of the things that can be done via the stream profile and selectively enabling replacements via iRules. The stream profile gives you plenty of ability to do data swapping in-line with even more speed than writing out the logic by hand in an iRule. Definitely good stuff.

when HTTP_REQUEST {
set replace_content 0
if {[HTTP::uri] contains "/atoz/"} {
    set replace_content 1
}
}
when HTTP_RESPONSE {
if {$replace_content equals "1"} {
    # Disable the stream filter by default
    STREAM::disable
    # Check if response type is text
    if {[HTTP::header value Content-Type] contains "text" and [HTTP::header "User-Agent"] contains "***"}{
      # Replace
      STREAM::expression "@123@xyz@ @456@xyz@"
      # Enable the stream filter for this response only
      STREAM::enable
    }
}
}

There you have it, three more examples of iRules goodness in less than 20 lines each. See you next week.

Technorati Tags: 20 Lines or Less,iRules,HTTP,Colin Walker

#Colin

20 Lines or Less #12

Colin Walker — Thu, 24 Jul 2008 22:51:31 GMT

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.

Technorati Tags: DevCentral,20 Lines or Less,iRules,DHCP,URI Rewriting,SSL Information,Colin Walker

#Colin

20 Lines or Less #11

Colin Walker — Thu, 17 Jul 2008 00:08:58 GMT

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 CLIENT_ACCEPTED {    
  set time_r [split [clock format [clock seconds] -format {%k:%M} ] " "]  
  set time_f [expr {[expr {[lindex $time_r 0]*100}] + [lindex $time_r 1]}]     
  if { not(($time_f >= 800) && ($time_f <= 1700)) } {     
    set compression "off"    
  }    
}    
        
when HTTP_RESPONSE {     
  if { $compression eq "off" } {    
    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!

Technorati Tags: DevCentral,20 Lines or Less,HTTP,Colin Walker

#Colin

DevCentral Top5 06/27/2008

Colin Walker — Fri, 27 Jun 2008 21:12:30 GMT

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.

Technorati Tags: DevCentral,Top 5,Colin Walker

#Colin

20 Lines or Less #9

Colin Walker — Thu, 19 Jun 2008 18:57:25 GMT

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.

Technorati Tags: DevCentral,iRules,20 Lines or Less,Cookies,Redirects,Syslog,UDP,HTTP,Colin Walker

#Colin

Back at it

Colin Walker — Mon, 16 Jun 2008 18:06:09 GMT

I'm back! I know you were all waiting anxiously with baited breath for me to announce my triumphant return to my DevCentral duties, so I wanted to be sure that you could exhale and calm your nerves. Okay, on a more serious note, I'm just excited to be back at it and doing more cool stuff here with the community and the team. I'm rested, I'm recharged, and now I'm ready to get back in the trenches, as it were. I visited with some family, took a nice long drive across some pretty countryside, relaxed, gamed, and generally had a good time, but it's good to be back. As much as I loved having some time to relax and cool my jets, I'm really excited to be back and I'm looking forward to getting back into the rhythm of things here in DC Land.

I want to take a second to say thanks to the community for their support, and to my awesome team for keeping things rolling along and filled with awesomeness as always. It's cool to come back after a while out and see the awesomeness train in full motion.

Anyway, time to jump back in, see you out there...

Technorati Tags: DevCentral,Colin Walker

#Colin

20 Lines or Less #8

Colin Walker — Thu, 29 May 2008 23:30:33 GMT

For this week's 20LoL sampling I've dipped into my own private stash of iRule goodness. Some of these are oldies but goodies, one of them I actually just wrote yesterday as an example for Lori's Blog. As such the newly written example is the only one with a URI. The others will just have a description and the iRule source.

I'm sure I'll be diving back into the Forums and CodeShare in the coming weeks as there just seems to be an endless stream of cool stuff to dig through out there, but I wanted to toss up a few of my own rules this week. Be gentle with comments, some of these are old as I said. ;)

Content Scrubbing for Adobe Flash Exploit

http://devcentral.f5.com/weblogs/macvittie/archive/2008/05/29/3309.aspx

This iRule digs through the contents of the HTTP responses being sent out from your servers and looks for known exploit sites, then blocks those responses from going to your users. In this way it attempts to help protect them from the spread of the Adobe Flash exploit Lori's been talking about.

when HTTP_RESPONSE {
HTTP::collect
}

when HTTP_RESPONSE_DATA {
switch -glob [string tolower [HTTP::payload]] {
    "*0novel.com*" -
     "*dota11.cn*" -
     "*wuqing17173.cn*" -
     "*woai117.cn*" -
     "*guccime.net*" -
    "*play0nlnie.com*" {
      HTTP::respond 200 content "The server is currently unable to serve the requested content. Please try again later."
      log local0. "Adobe Flash exploit infected Server IP: [IP::server_addr]."
    }
}
HTTP::release
}

IP Client Limiting via Array

This iRule was written to deal with a very high-volume need for client limiting. By storing the IPs in an array and accessing them in the most optimized format I could come up with, this rule was able to stand up to some pretty impressive numbers. If memory serves it was somewhere near 200K connections per second with nearly 3 million concurrent connections. Not too shabby!

when RULE_INIT {
array set connections { }
}

when CLIENT_ACCEPTED {
if { [info exists ::connections([IP::client_addr])] } {
    if { [incr ::connections([IP::client_addr])] > 1000 } {
      reject
    }
} else {
    set ::connections([IP::client_addr]) 1
}
}

when CLIENT_CLOSED {
if { [incr ::connections([IP::client_addr]) -1] <= 0 } {
     unset ::connections([IP::client_addr])
}
}

Selective HTTPS Redirect

This is a slight variant on a popular concept. This iRule does a selective redirect to HTTPS by checking a given class to see if the incoming URI is one that should be served via HTTPS. The neat part here is that it also does a port check and a preventative else statement, meaning this iRule should be able to be deployed on a global virtual, serving all ports, where most examples like this require the traffic to be broken up into two VIPS, port 80 and port 443, to avoid infinite looping.

when HTTP_REQUEST {
if { [TCP::local_port] == 80 } {
    log local0. "connecting on HTTP server"
    if { [matchclass [HTTP::uri] starts_with $::secure_uris] } {
      HTTP::redirect "http://[HTTP::host][HTTP::uri]"
    }
}
}

So there you have it, another few examples of what can be done via iRules in less than 21 lines of code. This 20 LoL brought to you from my personal vault, so I hope you enjoy. As always, please let me know if you have any feedback, comments, questions, suggestions, musical recommendations or other pertinent information to share. See you next week.

Technorati Tags: DevCentral,iRules,20 Lines or Less,HTTPS,Client Limiting,Adobe,Flash,Colin Walker

#Colin