Forum Discussion
iApp object lose their app-service attribute
Hi,
could anyone tell me under which circumstances an iApp could lose it's relationship to the iApp objects? I have the following setup:
- two BigIP instances in a HA cluster.
-
1 x iApp creating
- ~10 Virtual Servers
- plus Pools, Traffic Policies, etc.
- shared Monitors, Profiles, iRules, etc are all in /Common and not part of the iApp in question.
After a while (and I can't pinpoint the particular step as yet) an number of Virtual Server no longer have the
app-service myApp.app/myApp
attribute set and I cannot delete the iApp.
A work-around until now has been:
- set strict-updates -> disabled
- modify all objects under myApp.app/ missing the app-service attribute, re-adding the iApp in question.
- set strict-updates -> enabled
...but I would like to the reason for this and how I can avoid it.
Steps performed after the iApp has been created include things like:
- renew/change the certificates used in a underlying shared client-ssl profile.
- reconfiguring the iApp.
- changing the content/attributes of the underlying shared monitors.
Both servers with and without client-ssl profiles are affected so I think changing the underlying certificates can be ruled out as the cause.
Is this known to anybody and are there any known pitfalls to help avoid such an issue?
Thanks, Steve
6 Replies
- Fred_Slater_856Historic F5 Account
Steve- This sounds like a bug. A virtual should not lose its app-service property any more than it should lose its profiles or any other properties that are associated with it. I assume that strict-updates was enabled at the time this occurred? What version of TMOS are you running? Is this an F5 iApp or one of your own? -Fred
- lostinberlin_11
Nimbostratus
Hi Fred, thanks for the prompt reply. Version (11.6 with the latest Hotfix). Strict-updates were enabled. It is one of our own in-house iApps made from an in-house template. The template uses a utils cli script with some common procedures. I will add an extract of the main functionality to the main question (we will have formatting then). Thanks, Steve - lostinberlin_11
Nimbostratus
Okay, for some reason the edit Answer -> Save button is not working (I'm on Ubuntu 12.04. Tried with Firefox and Chrome if it's any help), so here the edit I would have added. **EDIT (04.08.2015): Answers to Fred comment:** - Version: 11.6.0 (HF5) - Strict-updates: enabled - In-house iApp template. Version **** Version (11.6 with the latest Hotfix): Sys::Version Main Package Product BIG-IP Version 11.6.0 Build 5.0.429 Edition Hotfix HF5 Date Thu Jun 18 17:57:52 PDT 2015 Extract from iApp Template and Utils file. ******** TEMPLATE ******** set myType myApp set mySyncPrefix ${myEnv}${myType}2 get config objects set myInternalIP [getMandatory $myEnv $myType internalIP ] iapp::debug "Creating pools..." set syncNodes [iapp::get_items -filter NAME =~ "^${mySyncPrefix}" ltm node ] createPool "${mySyncPrefix}" 6557 "monitor M-HTTP-8000_isAlive" $syncNodes $myExcludedNodes createPool "${mySyncPrefix}" 9000 "monitor M-HTTP-8000_isAlive" $syncNodes $myExcludedNodes createPool "${mySyncPrefix}" 9050 "monitor M-HTTP-8000_isAlive" $syncNodes $myExcludedNodes iapp::debug "Creating internal VS..." INTERNAL-6556 set vsName ${mySyncPrefix} set vsDestination $myInternalIP set vsPort 6556 set vsPersistence "" set vsPolicies "" set vsProfiles "tcp-default { }" set vsRules "" set vsPool ${mySyncPrefix}-6557 createVS $vsName $vsDestination $vsPort $vsPersistence $vsPolicies $vsProfiles $vsRules $vsPool ******** UTILS ******** proc createPool {myPrefix poolPort customAttrs nodes {excludedNodes ""}} { set poolName "${myPrefix}-${poolPort}" set defaultAttrs "service-down-action reselect reselect-tries 1" set default if not found if { [string first " slow-ramp-time" [string tolower $customAttrs]] == -1 } { set defaultAttrs "${defaultAttrs} slow-ramp-time 30" } iapp::conf "create ltm pool ${poolName} { ${customAttrs} ${defaultAttrs} }" foreach node $nodes { if {[expr {[lsearch -exact $excludedNodes $node] >= 0 }]} { iapp::debug " Excluding node $node" } else { iapp::debug " Adding node $node" iapp::conf "modify ltm pool ${poolName} members add { $node:$poolPort }" } } } proc createVS { vsName vsDestination vsPort vsPersistence vsPolicies vsProfiles vsRules vsPool } { if {$vsPolicies != "" } { set vsPolicies "policies replace-all-with { $vsPolicies }" } if {$vsProfiles != "" } { set vsProfiles "profiles replace-all-with { $vsProfiles }" } if {$vsPool == "" } {set vsPool none } iapp::conf "create ltm virtual ${vsName}-${vsPort} { \ destination ${vsDestination}:${vsPort} \ ip-protocol tcp \ mask 255.255.255.255 \ $vsPersistence \ $vsPolicies \ $vsProfiles \ rules { \ $vsRules \ } \ pool $vsPool source 0.0.0.0/0 \ source-address-translation { type automap } \ vlans-disabled \ }" } - lostinberlin_11
Nimbostratus
Hi Fred, Okay, I have narrowed it down to the merging of bigip config files which seems to be the problem. We have snippets of bigip config which we keep in SVN in order to track the changes. This test only applies to the iRules used in a virtual server. However, my guess is that the shared SSL configs do the same. Example: - iRule definition (kept in subversion to allow traceability). - myApp.app/myAppIntern-443 uses this iRule - iRule merged into the config. - myApp.app/myAppIntern-443 loses app-service **** iRule config file ****** steve@(myBigIP)(cfg-sync In Sync)(Active)(/Common)(tmos) bash [steve@myBigIP:Active:In Sync] ~ cat /tmp/irules.conf ltm rule ir-myApp-webstart { when HTTP_REQUEST { $Header: http://subversion/path/to/file/irules.conf 83700 2015-07-30 13:31:20Z steve $ if { [string tolower [HTTP::uri]] starts_with "/webstart/" } { HTTP::uri [string replace [HTTP::uri] 1 12 myAppwebstart] } } } **** Servers BEFORE ****** sbl@(lb1a)(cfg-sync In Sync)(Active)(/Common)(tmos) list ltm virtual myApp.app/myApp app-service rules ltm virtual myApp.app/myAppIntern-9000 { app-service /Common/myApp.app/myApp rules { ir-myApp-admin } } ltm virtual myApp.app/myAppIntern-443 { app-service /Common/myApp.app/myApp rules { ir-encrypt128bits ir-myApp-webstart ir-myApp-admin } } ltm virtual myApp.app/myAppExtern-back-80 { app-service /Common/myApp.app/myApp rules none } ltm virtual myApp.app/myAppExtern-front-80 { app-service /Common/myApp.app/myApp rules { _sys_https_redirect } } ltm virtual myApp.app/myAppExtern-front-443 { app-service /Common/myApp.app/myApp rules { ir-encrypt128bits } } **** Merge ****** steve@(myBigIP)(cfg-sync In Sync)(Active)(/Common)(tmos) load sys config file /tmp/irules.conf merge Loading configuration... /tmp/irules.conf **** Servers AFTER ****** sbl@(lb1a)(cfg-sync In Sync)(Active)(/Common)(tmos) list ltm virtual myApp.app/myApp app-service rules ltm virtual myApp.app/myAppIntern-9000 { app-service /Common/myApp.app/myApp rules { ir-myApp-admin } } ltm virtual myApp.app/myAppIntern-443 { app-service none rules { ir-encrypt128bits ir-myApp-webstart ir-myApp-admin } } ltm virtual myApp.app/myAppExtern-back-80 { app-service /Common/myApp.app/myApp rules none } ltm virtual myApp.app/myAppExtern-front-80 { app-service /Common/myApp.app/myApp rules { _sys_https_redirect } } ltm virtual myApp.app/myAppExtern-front-443 { app-service /Common/myApp.app/myApp rules { ir-encrypt128bits } }
- Fred_Slater_856Historic F5 Account
Your merge sleuthing is good, but still points to a bug. Please call this in to F5 Support. They will be able to document it and refer it to the right people on our development staff.
- lostinberlin_11
Nimbostratus
Okay, I'll open a support case as soon as I get the support account from our operations guys. Thanks again, Steve
Recent Discussions
Related Content
* Getting Started on DevCentral
* Community Guidelines
* Community Terms of Use / EULA
* Community Ranking Explained
* Community Resources
* Contact the DevCentral Team
* Update MFA on account.f5.com