How to upgrade Websense iApp that has a bug

I did some digging on this. If I use the following command:

tmsh list sys app service Websense.app/Websense

..then I get the output of the settings for the iapp. Unfortunately, this output is the same from an LTM node with good config and bad config, using the compare plugin for notepad++. The output does not contain the virtual server IP addressing which is at least one part that I know is wrong. The output does include the node IP addressing, ports, and other settings.

This command returns no results either:

tmsh show ltm virtual | grep -i "websense"

So I'm at a loss to even see the specific differences between the working and non-working versions of the config. What's the best way for me to see the specifics about these differences?

Hi Ken, from tmsh you can run "cd Websense.app/", then "list ltm virtual". This should show you only the virtual servers in that iApp folder.

Do you already have the newer version of the template? Can you point me to where you downloaded these so I can have a look?

thanks

iApps are easy to upgrade so long as the new version uses the same APL variable and table names as the old. You can call this the "data model" for the iApp. You will see these variables and tables in a tmsh list sys app service command, but no tmsh commands are needed for an upgrade. From the UI, simply re-parent your iApp from one template to another in the Reconfigure pane by clicking the "change" button next to the template name.

Looking on the community-contributed section of the iApp code share, I found the Websense CG template page, and there is a more recent version, although the author did not post any notes about it fixing your particular issue. If you want to install this, the steps would be: 1. download it; 2. import the new template; 3. re-parent your running iapp to this new template and click "Finished". If the new template does not work for you, simply re-parent back to the one you are using today.

You asked about strictness. Strictness protects the configuration related to your application from being altered from outside the iApp (by using the regular UI or tmsh, for example). You can leave strictness on while re-parenting (upgrading) your iapp, and it should work just fine. If you turn strictness off and begin changing settings outside the iApp, you will have disengaged the sync between the iApp's data and the real system config. If you re-run the iApp at that point, the changes you made outside the iApp may be overwritten. You can avoid making that mistake by re-parenting the iApp to "None - Do not use a template."

Other than learning how to upgrade and downgrate an iapp, my problem is that this app has struct updates disabled, but I do not know what changes were made to the virtual server (or other objects) that make it finally start working (other than the destination IP address settings). So when the iapp upgrades, it's most likley going to break the functionality of t he iapp. So, I need to figure out a way to get all of the running config that the iapp has generated so I can see line by line what config is in place.

I wanted to provide a follow up on how this went. I uploaded the latest (v3) Websense iApp to the LTM. When I went to install it, I got an error message saying (I'm paraphrasing) that the object already existed. When installing, there is a check box to overwrite the existing config. So, I checked than and re-tried the install. That worked.

Actually, it worked brilliantly: All of the existing iapp settings were retained and the problems of the old iapp version were fixed. As far as I could tell, there was no downtime (of course this virtual server handles web browsing traffic, so it's all transient anyhow)

Our LTM-Websense integration has been problematic from the start. It's a seemingly simple process, but the bugs in the old iapp version were a huge problem that clouded the original deployment of things. It's good we're finally getting some positive movement.

The remaining big unknown here is how much load our LTM will see when we have 500 megabits of web browsing traffic running through it. The LTM interfaces in question are 1 GB (LACP pair) so I am not worried about them. I am more worried about the 4200v CPU utilization. We are phasing in a few IP subnets at a time, so we can monitor the load over time and see how the LTM handles it.

The main lesson I learned here is this: Vendors Websense and F5 will both tell you all day that to load balance Websense, that LTM is the officially supported solution. The whitepaper tells you to use the F5 iApp. This is all great, but what I learned is that the original iApp had bugs, and these bugs prevented any of it from working correctly at all. I burned a great deal of time on this problem. When both vendors both point to a certain officially supported piece of technology as the official way to do so something, then it's easy to fall into the trap of assuming that solution will work. As with any software, don't assume it is bug-free, and don't assume the config generated by the iApp is problem free.