This week I bring to you a full house of content, docs over blogs. To say there have been more than a few pairs on DevCentral lately though would be an understatement. The rush of content could be likened to an avalanche but without the messy death and destruction bits to deal with. From interviews to tech tips to blog posts to original songs pertaining to cloud computing (no, I'm not joking, and no, the link isn't in here…go find it yourself), DevCentral never seems to sleep these days, which is just how we like it. In case you're overwhelmed and looking for a place to get started, here are my Top5 picks for the week:
Citrix XenApp 5.0 Implementation Tips
http://devcentral.f5.com/Default.aspx?tabid=63&articleType=ArticleView&articleId=1082335
Naladar, one of the esteemed MVPs of the DevCentral community, comes to us with this piece on XenApp this week. He's looking to share his recent experiences and given his track record, he's the kind of person you want to listen to when he decides to share something with the community. While there are deployment guides out there for Presentation Server 4.5, Naladar takes the time to walk you through the differences in implementation that you'll need to pay attention to for v5. With some almost immediate positive feedback it's obvious that other people out there have found this one useful already. Combine that with the fact that I'm always eager for a chance to show off how awesome our users are, even to the point of contributing killer content for the masses, and this one had to be my top pick this week.
Configuring a multi-tier Testing Environment with VMware Teams and BIG-IP LTM VE
http://devcentral.f5.com/Default.aspx?tabid=63&articleType=ArticleView&articleId=1084344
There have been many a post about LTM VE over the past few weeks, many of them very cool, but Don took a slightly different angle by showing you how to set up a VMware team so you can spin up and down your entire test team (VE, client, server) with the push of a single button. Pretty neat stuff. Not only that, but he goes into enough detail with screenshots and step by step instructions that you should be able to re-create the environment pretty easily if you're still looking for a way to get up and running with your VE deployment. Whether you were waiting for the right walk-through on setting up LTM VE to come along or you're just interested in seeing yet another way of doing things, this article was a goodie.
BIG-IP Logging and Reporting Toolkit - part two
http://devcentral.f5.com/Default.aspx?tabid=63&articleType=ArticleView&articleId=1084341
The second installment of Joe Malek's awesome Logging and Reporting Toolkit series is out, and worth a read. Here he talks about the two vendor options he investigated when looking into advanced options for BIG-IP logging and reporting, Splunk and Q1 Labs. He talks a bit about each of their offerings, their strengths and what to expect from them. He then goes onto give us an extensive list of the different information these systems are going to be made to handle in the soon to come resolution to this technological tease wherein we'll finally get to see the results of his testing, his analysis of the options, and some fun charts. If you didn't catch the first installment yet, I highly recommend going and checking that one out as well.
If I Had a Hammer…
http://devcentral.f5.com/weblogs/macvittie/archive/2010/03/10/if-i-had-a-hammer.aspx
Despite the title Lori does not go on to talk about carpentry or construction. Instead she fills us in on her take on Carr's analogy and why the "pay as you use" model is really more like a "pay for the minimum required in CASE you need it" model. It's not a negative slant on things, just realistic, to remember that there is an inherent cost in things that have to be running before requests actually come in. To fool ourselves into thinking that we're paying only for what we use, like electricity, when we're paying a set cost just to have the resources available when needed is..well..just that, fooling ourselves. I like her points here and thought it was worth passing on. The cloud can be awesome and effective and even cheap for many people, but don't get caught off-guard thinking it's going to be free until you need it while really being billed.
20 Lines or Less #37 - Hex, HTTPS, and SNATing
http://devcentral.f5.com/weblogs/cwalker/archive/2010/03/12/20-lines-or-less-37.aspx
I'm so sorry, 20LoL, I didn't mean to leave you out last time, there was just too much good stuff! I never meant to hurt you, you know how I love you, I just couldn't justify bumping one of the other hawesome topics for your iRuley goodness. You're back, though, this week, with 3 more examples of iRules fu at its finest. *cough* Check out what the forums & samples section have to offer this week in less than 21 lines of code. We've got payloads being converted to hex, yet another take on https redirection and some pretty nifty snating stuff happening. These are always a cool look at what people in the community are up to, so check it out.
Well, there it is, another week, another 5 from DC. Hopefully you liked reading as much as I liked writing. Come back next week for more, and feel free to drop me a line with any feedback.
#Colin
What could you do with your code in 20 Lines or Less? That's the question I ask (almost) every week for the devcentral community, 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.
I bring to you your weekly dose of short yet cool iRule goodness. Check out what these iRule fu masters have crammed into less than 21 lines of code. This week we’ve got hex translation of HTTP payloads, intelligent redirection including port handling, and some snat intelligence in just a few lines of code. Dig it.
Log binary HTTP payload in hex
http://devcentral.f5.com/wiki/default.aspx/iRules/Log_binary_HTTP_payload_in_hex.html
Here’s one that we touched on briefly in the podcast last week. Hoolio decided that it would be fun or handy or…something, to convert and log the entire HTTP payload in hex for every response. I couldn’t tell you when this would be needed, but it was a pretty darn cool thought, and I thought I’d share it. Maybe he’ll come tell us what it was for. ;)
when HTTP_REQUEST {
# Log debug? 1=yes, 0=no
set debug 1
# Collect up to the first 1MB of POST data
if {[HTTP::method] eq "POST"}{
set clength 0
# Check if there is a content-length header and the value is set to less than 1Mb
if {[HTTP::header exists "Content-Length"] && [HTTP::header Content-Length] <= 1048576}{
set clength [HTTP::header Content-Length]
} else {
set clength 1048576
}
if {[info exists clength] && clength > 0} {
if {$debug}{log local0. "[virtual name]: Collecting $clength bytes"}
HTTP::collect $clength
}
}
}
when HTTP_REQUEST_DATA {
# Log the payload converted to hex
binary scan [HTTP::payload] H* payload_hex
if {$debug}{log local0. "[virtual name]: $payload_hex: $payload_hex"}
}
SNAT based on incoming IP
http://devcentral.f5.com/Default.aspx?tabid=53&forumid=5&postid=1170490&view=topic
Matt dished out a great little example of how to effectively control which snat address a connection is assigned based on the IP range the request is coming in from. It’s simple, it’s efficient, it’s effective, and it’s short. Those are a few of my favorite things in iRules, so here you go.
when CLIENT_ACCEPTED {
if { [IP::addr [IP::client_addr] equals 10.9.9.0/26] }{
snat 1.1.1.1
} elseif { [IP::addr [IP::client_addr] equals 10.9.9.65/26] }{
snat 2.2.2.2
} elseif { [IP::addr [IP::client_addr] equals 10.9.9.128/26] }{
snat 3.3.3.3
} else {
forward
}
}
Intelligent HTTP to HTTPS redirection…now with port handling!
http://devcentral.f5.com/Default.aspx?tabid=53&forumid=5&postid=1168453&view=topic
This is a topic (HTTP to HTTPS redirection) that I’ve shown off at least a few times in the 20LoL, but that’s because it comes up so darn often in the forums and elsewhere. Here is yet another take on how to do it, and a darn good one at that. Note the use of string map, which I heart, and the fact that this one can actually handle requests that specifically have the port declared in the hostname. If you try to redirect to HTTPS but still have a :80 in your host, things might not go as swimmingly as you’d like.
when HTTP_RESPONSE {
# Check if server response is a redirect
if { [HTTP::header is_redirect]} {
# Log original and updated values
log local0. "Original Location header value: [HTTP::header value Location],\
updated: [string map -nocase "http:// https:// :80/ /" [HTTP::header value Location]]"
# Do the update, replacing http:// with https:// and :80/ with /
HTTP::header replace Location \
[string map -nocase "http:// https:// :80/ /" [HTTP::header value Location]]
}
}
There you go, 3 more examples of iRules goodness in 20 Lines or Less each. See ya next time.
#Colin
