Agility 2020 - you're invited!
In-person event for Agility 2020 has been cancelled. Please see the Agility Event Page for more details. (Update 2/28/2020) In an abundance of caution for our customers, partners and employees, we have made the tough decision to cancel our in-person event for Agility 2020 due to the escalating travel and safety concerns related to the global COVID-19 (Coronavirus) outbreak. While we are disappointed to miss sharing ideas and solving problems with customers and partners from around the globe in person, we believe this is the best decision for everyone's welfare. We are rapidly developing an alternative to Agility as a virtual experience in the near term to deliver valuable Lab, Break-out Session, Certification and Keynote content to our customers and partners. Check back regularly for more details on the virtual event or email F5Agility@F5.com for additional information. <Professor Farnsworth imitation>Good news, everybody!</Professor Farnsworth imitation> As you know, there was no Agility 2019. This was in part so that we could reset the time of year for the conference from August to March. Agility 2020will be held from March 16-19, 2020 at theSwan & Dolphinin Orlando, Florida. Orlando, and Disney, and putt-putt golfing... That's right, *puts on ears* we're going to Disneyworld - and you are all cordially invited to participate in labs and breakouts, meet fellow F5 users, talk with F5 and partner subject-matter experts, learn to develop and deploy applications in days instead of months, secure your apps at scale in a multi-cloud environment, and hear about our vision for the future of F5 and NGINX. Registration is now open! The DevCentral team will be busy as usual that week. We areallflying over, and will be: hosting our usual booth and giving out swag in the expo hall, hosting a walk-in Nerdery zone next to our booth, where folks can drop in to speak with one of our subject-matter experts, presenting breakout sessions, hanging out at Geekfest, connecting community, enjoying the exclusive community area at the final night party, and of course, spoiling the dev/central MVPs during the joint 2019-20 MVP Summit at Agility with special sessions and activities. If you'd like to do more than pick up all the knowledge being dropped, if you have some cool technical stories or lessons-learned to share, please stay tuned for the open call for proposals which should go live in early December - so please start getting those great breakout, lightening round, and open talk ideas ready. Hope to see you there!
Issues with incremental config sync cache || Unable to do incremental sync, reverting to full load for device group
I received an error similar to below : notice mcpd[2789]: 0107168e:5: Unable to do incremental sync, reverting to full load for device group /Common/syncgroup1device%cmi-mcpd peer-/Common/ltm1.example.comfrom commit id { 4 6390393316259868817 /Common/ltm1.example.com}to commit id { 3 6391877370007482801 /Common/ltm2.exmample.com}. Here, changes pertaining to commit id 3 got executed on the peer device. Undesired change like disabled pool member was enabled which caused impact to the business. The recommended action says to reduce the size and frequency of the configuration changes made to the BIG-IP system. You may also be able to mitigate this issue by increasing the size of the incremental ConfigSync cache. While I see the explanation below saying if incremental sync cache size exceeds 1024, the BIG-IP performs a full sync which is not happening in my case. In theMaximum Incremental Sync Size (KB)field, retain the default value of1024, or type a different value.This value specifies the total size of configuration changes that can reside in the incremental sync cache. If the total size of the configuration changes in the cache exceeds the specified value, the BIG-IP system performs a full sync whenever the next config sync operation occurs. Can anyone help me understand the below concerns. Q. Why the full sync doesn't happen if the incremental sync cache size goes beyond 1024. Also it caused an impact to the traffic by configuring changes specific to commit-id 3. Also I checked below command, show cm device-group <sync_group> incremental-config-sync-cache It shows multiple commit id and related configuration, Q. Is there a procedure to only keep the recent commit-id and flush the old ones so the cache doesn't go beyond default 1024KB. Q. Can the modify the cache value to the suggested 2048 and will there be any impact of it ? And will it require increasing it in future if say again the cache fills up ? modify cm device-group <sync_group> incremental-config-sync-size-max ? Specifies the maximum size (in KB) to devote to incremental config sync cached transactions. Range: 128-10240. Default:1024. Q. Is there a way we can monitor this proactively (leaving aside the preventive measures of reducing size and frequency of config changes). Hope I will get answers to the above concerns. thank DevCentral Community in advance !!!Manage BIG-IPs in Azure using Terraform Cloud
Introduction In this article I’ll outline a suite of demonstration resources designed to help you and your IT team explore the possibilities of applying DevOps practices in your own environments. The demonstration resources described below show how tools likeGit, HashiCorpTerraform, HashiCorpSentinel, ChefInspecand F5'sAutomation Toolchaincan be used to introduce some of the practices listed above to F5 BIG-IPs and the IT services they help deliver. By following along with theREADMEin thedemonstration repositoryand the video walk-throughs listed below, you should be able to run this demonstration on your own. Software Delivery Key Practices IT Industry research, such asAccelerate, shows improving a company's ability to deliver software has a significant positive benefit to their overall success. The following practices and design principles are cornerstones to that improvement. Version control of code and configuration Automation of Deployment Automation of Testing and Test Data Management "Shifting Left" on Security Loosely Coupled Architectures Pro-active Notification Caveats These repositories use simplifying demonstration shortcuts for password, key, and network security. Production-ready enterprise designs and workflows should be used in place of these shortcuts. DO NOT ASSUME THAT THE CODE AND CONFIGURATION IN THESE REPOSITORIES IS PRODUCTION-READY The particular source control approach shown in this demonstration is one of many. Before using this approach to support your Infrastructure as Code and Configuration Management assets and workflows, you should learn aboutdifferent patterns of source code managementand determine what best fits your team's needs. A variety of tools are used in this demonstration. In most cases they are not exclusively required and can be replaced with other similar tools. The demonstration uses a licensed version of Terraform Cloud in order to demonstrate the capabilities of HashiCorp Sentinel. If you are using the free version of Terraform Cloud you won't be able to try the policy compliance use-cases, and the rest of the demonstration code should work as expected. Setting up your demonstration automation host Before running the demonstration code, you'll need to set up the IDE host and the Azure account. Instructions for those steps arehere Video walk-throughs Fork the repository and open it in Visual Studio Code (1m36s) Once the tools are installed, you can create your own copy of the repository and open it in your IDE. In the videos, Visual Studio Code is used as the IDE. In order to follow along, you'll need to create your own repository in order to set up the Terraform Cloud configuration and make your own adjustments to build configuration (e.g. the number of application servers deployed) Set up a Terraform Cloud workspace (1m38s) Before running the Terraform Cloud workflow, a Terraform Cloud workspace is required. This video steps you through manually configuring the workspace and linking it to your cloned repository. Programmatically set up Terraform Cloud workspaces for production, test, and development (10m40s) Setting up the workspaces programmatically has the benefits of rapid consistent results and executable knowledge in the form of scripts and configuration files. In this video we step you through programmatically building workspaces for production, test, and development environments usingthis repository. We also programmatically configure simple source-controlled compliance Sentinal policies. Initial build of production, test, and development (7m59s) Everything should be ready for the first build of your production, test, and development environments. In this video, we step you through manually triggering Terraform Cloud builds. In addition, we'll see the impact of Sentinel policies in use, how to override policies that have been triggered, and the audit trail that results. Automated testing of production (4m18s) Once your environment builds have completed, it's critical to validate that they are fit for use. In this video, we step you through a simple set of tests that validate the readiness of the F5 BIG-IPs built by the Terraform Cloud workflow. These tests are not comprehensive, but demonstrate the benefits of an executable "definition of done." The source of an updated version of the Inspec tests used in the demonstration ishere. Manual inspection of production (2m45s) In this video, we walk through the BIG-IPs that were built in the production environment. We inspect the virtual servers and their associated pools, noting the number of application servers that were built and joined to the pool. Programmatically add application servers and include them in the BIG-IP virtual server (8m6s) In this video, we explore the use-case of expanding the pool in the previously built production environment, using a simple change in source control. We'll see the Terraform Cloud workflow automatically trigger a new build based on a merge commit to your cloned repository. New application servers will be built and automatically added to the pool by F5'sService Discovery iApp. Update WAF from a source control repository(no video walk-through) We leave it as an exercise for the reader (or possibly an updated video) to look for the WAF deployed with the virtual server. The WAF is retrieved from source controlhere. In addition, you can experiment with changing the version of the WAF in theAS3 templatein the stanza shown below. Usable values for versions are 0.1.0, 0.1.1, 0.2.0, and 0.2.1. If you choose to do this, follow the same workflow shown in the previous video about scaling the number of application servers. "ASM_Policy": { "class": "WAF_Policy", "url": "https://github.com/mjmenger/waf-policy/raw/0.1.1/asm_policy.xml", "ignoreChanges": false } What's next? If you've followed along through the all of the use-cases in the demonstration repository, you have seen the following: Source-controlled build of an application environment, including BIG-IPs, virtual servers, pools, and WAF policies. Managed changes with logging of authoring and approvals. Automated scaling of application resources and BIG-IP configuration. Automated updates to BIG-IP WAF policies. If you want to realize the benefits of these practices for your IT service delivery, please reach out to your F5 account team.Agility 2020 Call for Proposals now open!
In-person event for Agility 2020 has been cancelled. Please see the Agility Event Page for more details. (Update 2/28/2020) In an abundance of caution for our customers, partners and employees, we have made the tough decision to cancel our in-person event for Agility 2020 due to the escalating travel and safety concerns related to the global COVID-19 (Coronavirus) outbreak. While we are disappointed to miss sharing ideas and solving problems with customers and partners from around the globe in person, we believe this is the best decision for everyone's welfare. We are rapidly developing an alternative to Agility as a virtual experience in the near term to deliver valuable Lab, Break-out Session, Certification and Keynote content to our customers and partners. Check back regularly for more details on the virtual event or email F5Agility@F5.com for additional information. This is the announcement that the open call for proposals for Agility 2020 breakout and lightening talk sessions is now open! The next Agility conference will be March 16-19, 2020 in Orlando, FL. We here at DevCentral officially invite our outstanding user community to submit abstracts for 50-minute breakout sessions and/or 15-minute lightening talks. Do you have unique first-hand technical insights and real-world best practices to share? Are you an innovative user of F5 technology? Want to present for 60 minutes or just throw your hat in the ring for 15 minutes’ worth of a lightening round? Submit your proposal abstract(s) via this form for an opportunity to share your expertise with other F5 practitioners at Agility 2020. When submitting your abstract, please choose one of the following tracks that most closely aligns with your proposed talk(s): ·App Protect ·Modern Application Development ·Deployment Modernization ·Open Source We strongly recommend reading “Why Your Excellent Conference Talk Was Rejected” by Sarah Gray for tips on getting your proposal added to the agenda. Potential presenters may submit more than one abstract, with one proposal per submission. Submit your proposal abstract(s) by January 13th via this form. Why present? ·Complimentary conference registration ·Because you have something interesting to say ·Professional recognition by your peers ·Help your fellow users ·Increased networking opportunities ·Awesome shirt Deadline for proposal submission: 11:59pm PST January 13, 2020 Please emailLeslie Hubertusat l.hubertus (at) f5 d0t com with any questions.
F5 with python ?.
Hello, Could you kindly assist how to install the f5 library in python so that i can write the codes. Appreciate for your kind reply. https://creditcardsupportx.com/lord-and-taylor-credit-card/ https://creditcardsupportx.com/pep-boys-credit-card/ https://creditcardsupportx.com/rooms-to-go-credit-card/ thanks jackyjoyProgrammability in the Network: Blue-Green Deployment Pattern
#gluecon #devops Intelligent handling of requests whether for testing or migration or upgrades requires programmability in the network. Cory von Wallenstein, CTO of Dyn Inc, gave a great presentation at Glue 2013 on upgrading infrastructure. If you weren't at Glue (or were and missed his presentation) you can check it out on SlideShare. The premise of Dark Architecture is based on Martin Fowler's Blue/Green deployment pattern. Developers will recognize this DevOps pattern as similar to A/B testing patterns. Martin sums up in his Blue/Green Deployment Pattern blog: The fundamental idea is to have two easily switchable environments to switch between, there are plenty of ways to vary the details. One project did the switch by bouncing the web server rather than working on the router. Another variation would be to use the same database, making the blue-green switches for web and domain layers. Cory's application of this pattern, which he calls Dark Architecture, engenders a continuous deployment pattern capable of transitioning from an existing architecture to a new (and potentially in-progress) architecture while retaining the ability to rapidly rollback (or fallback, whichever you prefer). In both Dark Architecture and A/B testing patterns, the idea is to slowly siphon off some identifiable portion of traffic. In some cases this may be to test a new version of an API or to enable migration to the new API and client by matching appropriate versions on both the client and the server-side application (or API). In both cases, the match should optimally be made in real-time, meaning as the requests arrive some "thing" in the network figures out which version of the < API | Application | Architecture > should handle each request. This requires programmability in the network; the ability to programmatically inspect requests as they flow through the network and determine based on layer 7 (application layer) properties how the request should be handled. This requires programmability because the specific information on which you want to base the decision - API version, URI, client device or version, etc... - is likely unique to your application. You need to be able to programmatically extract certain pieces of data from the request and then use them to inform infrastructure elements such as load balancers or proxies on how to direct every request. This kind of capability is critical to enabling agile business and operations because nothing is as constant as change, and it is nearly impossible today to forklift upgrade hundreds or thousands or more consumers (or employees) across multiple devices to a new version of the application. But you still have to do it, somehow, unless you're going to bloat the application (or API (or both)) by always and forever, amen, enabling backwards compatibility. To version before 1.0. That's not feasible in today's rapidly evolving and fast-paced application ecosystems. APIs mature rapidly and often deprecate calls. This same pattern can be used to manage the transition from deprecated API methods to more current methods - including transforming data if necessary. That's because programmability in the network enables a programmatic, development-oriented means of dealing with traffic in a real-time manner. This is not the programmability often referenced with respect to SDN, which is more about enabling the development of applications that perform a specific task on traffic as it is inspected by the controller. Nor is it the programmability that enables management and automation of network devices through control plane APIs. This is programmability in the data path, while data is flowing, in real-time. It's about routing at layer 7 (application layer), enabling a dynamic, robust and intelligent network capable of directing traffic based on application details. Programmability in the network is a critical component for devops and developers looking to enable continuous delivery of applications, APIs, and architectures.Agility 2020 registration now open!
As you may have seen in Peter Silva's teaser video, Agility 2020 is back! Registration is now open for the May 12-14 keynotes, demos, and breakout sessions. We will have information about registration for the June labs at a later date. Please visithttps://www.f5.com/agilityfor more information.F5 Agility Chicago 2017 Is Just Around The Corner!
Hi everyone, Here’s your friendly local reminder that F5 Agility 2017 is coming to Chicago, IL this July 31st through August 3rd! This year we’re expanding the scope of Agility and offering more breakout sessions for you, our technical community. Recap of Agility 2017 features: 20 hours of hands-on labs Over 60 technical breakout sessions Lounge featuring DevCentral, F5 Labs, and the F5 Store Solution Expo featuring technology application partners UPDATES: Keynote speakersinclude: Jason Silva Pablos Holman F5 Connects Women lunch featuring McKinsey consulting partnerKara Sprague Closing celebration at Chicago’s House of Blues, featuring comedian Jay Mohr, U2 tribute band L.A.vation, and EDM duo DJs From Mars DevCentral Challenge game open to all DevCentral members Come to the DevCentral booth in the Lounge and say hello! For more information on reserving your place, go toF5 Agility 2017F5 Friday: You’ll Catch More Bees with Honey(pots)
Catching bees with honey(pots) means they’re preoccupied with something other than stinging you. Pop quiz time…pencils ready? Go. Is it good or bad to block malicious requests? If your answer was “that depends on a lot of different factors” then pat yourself on the back. You done good. It may seem counterintuitive to answer “it’s bad block malicious requests” but depending on the attacker and his goals it may very well be just that. MISSION IMPOSSIBLE No security solution is a 100% guaranteed to prevent a breach (unless we’re talking about scissors) and most are simply designed to accomplish two things: buy you time and collect enough information that you can address the underlying vulnerability the attacker is attempting to exploit. Some solutions buy you more time than others, and some solutions provide the ability to collect more data than others, but in the end an attacker – like an application developer - with enough time and money and information will find a way to breach security. This is particularly true for new vulnerabilities and attack methodologies with which infosec professionals may be not familiar because, well, they’re newly discovered (or pre-discovered – someone has to be victim number one, after all) and there just isn’t a lot of information about it yet. Now, the reason that blocking those malicious requests could actually be serving the miscreant is that over time, a motivated attacker can learn a lot from the security solution, including how it works and what it’s specifically protecting. It can take weeks, but over time the attacker can build a profile of your security infrastructure based on the blocking of requests (mapping parameters and values and paths that caused the request to be blocked) and subsequently find a way around it. This is true regardless of whether the blocking mechanism is implemented in the application itself or in network-deployed security infrastructure. Your new mission then, should you choose to accept it, is to confuse the attacker for as long as possible, essentially buying you time to figure out what they’re trying to do. Then you can patch or deploy or notify the proper authorities and try to put a stop to the attacker as well as the attacks. One of the ways in which you can buy a lot more time for researching and implementing a solution against old or new attack methodologies is to employ a strategy that combines a WAF (web application firewall) and a honeypot. NOT POOH BEAR’S HONEYPOT In almost every story about Pooh Bear he complains about a “rumbly in his tummy” and then laments the fact that his honeypot is nearly empty. The honeypot you want to leverage is one that Pooh Bear would love: it automatically reloads itself to an untouched state on a specified interval. Virtualization has afforded organizations the ability to easily implement honeypots that are exact duplicates of production applications and keep them “pristine” across time by reloading the original virtual image. That comes in handy when it comes to confusing attackers. Imagine their frustration when their last attack appeared to be successful, depositing a file on the web server, and when they try to access it, it isn’t there. Ha! Good times, good times. But in order to accomplish this frustrating and protective strategy you first must have deployed a WAF capable of detecting an attack in progress (hint: it also must be deployed in reverse-proxy mode). And it has to be fairly accurate because you really don’t want to route legitimate users to a honeypot. That’d be frustrating, too, but you’ll get calls about that one. I can almost guarantee (with Heisenberg certainty) that an attacker won’t call you even if they do figure out they’re being routed to a honeypot. F5 BIG-IP Application Security Manager (ASM) can do this thing. Using a combination of techniques it can, with good accuracy, determine when the applications it protects are being attacked. It does so through a combination of inspecting the client, the requests, and the patterns of those requests. Once it is determined that it is under attack it raises an event in the underlying, shared application delivery platform (TMOS) that can be acted upon using F5’s network-side scripting technology, iRules. Using iRules you can do, well, just about anything – including randomly routing requests to a honeypot. The reason I say “random” is that any consistent reaction to a motivated attacker gives them more information upon which they can act to circumvent the security systems. Like timing-based attacks, one of the ways to successfully avoid compromise is to randomly change the response pattern. A simple approach would be to decide that one of every X requests will be randomly routed to the honeypot. Additionally you’d want to apply a rate-limiting policy to the attacker to ensure their attacks don’t overwhelm legitimate traffic. This approach impedes the ability of the attacker to consistently gather information about the underlying architecture and security infrastructure that can be used against you. Such a strategy may in fact hold off the attacker indefinitely, although there are no guarantees. More likely it’s just buying you even more time in which you can gather forensic evidence for the authorities (because you are doing that, right?) and figure out if there is, in fact, a vulnerability for which a solution exists and can be applied before it is exploited in your environment. This approach also works to mitigate bots (web scrapers). Yes, you could – upon detection – simply close their sessions but they’ll just open new ones. Yes, Javascript-based protections can usually detect a bot versus a human being, but it – like all security solutions – is not 100% foolproof. So instead of letting the web scraper know they’ve been caught, direct them to an application in the honeypot that contains a lot of irrelevant data. Assign them to a low rate class to limit their potential impact on the performance of the application, and let them download like there’s no tomorrow. Imagine their faces when they realize they’ve spent hours scraping what turns out to be useless data! Ha! Good times, good times. AGILE SECURITY is a PART of an AGILE INFRASTRUCTURE The ability to determine how best to respond to an attacker using network-side scripting is unique to BIG-IP ASM. The underlying integration with the underlying unified application delivery platform makes it possible for security professionals to take advantage of the core traffic management capabilities available on the BIG-IP platform, such as network-side scripting and rate shaping. Yes, you can leverage standard policies if you like, but the ability to customize if/when necessary makes your entire security infrastructure more agile; it affords the opportunity to respond to attacks and vulnerabilities on-demand without requiring modification to applications or the rest of the infrastructure. Combining the flexibility of virtualization, which provides an affordable mechanism for deploying a mirror image (pun intended) of production apps and thus building out a honeypot, with the ability to dynamically and flexibly route requests based on context atop the capability to detect the complex attack patterns applications are increasingly subjected to makes it possible to better protect data center resources without compromising availability or performance for legitimate users.Agility sessions announced
Good news, everyone! This year's virtual Agilitywill have over 100 sessions for you to choose from, aligned to 3 pillars. There will be Breakouts (pre-recorded 25 minutes, unlimited audience) Discussion Forums (live content up to 45 minutes, interactive for up to 75 attendees) Quick Hits (pre-recorded 10 minutes, unlimited audience) So, what kind of content are we talking about? If you'd like to learn more about how to Simplify Delivery of Legacy Apps, you might be interested in Making Sense of Zero Trust: what’s required today and what we’ll need for the future (Discussion Forum) Are you ready for a service mesh? (breakout) BIG-IP APM + Microsoft Azure Active Directory for stronger cybersecurity defense (Quick Hits) If you'd like to learn more about how to Secure Digital Experiences, you might be interested in The State of Application Strategy 2022: A Sneak Peak (Discussion Forum) Security Stack Change at the Speed of Business (Breakout) Deploy App Protect based WAF Solution to AWS in minutes (Quick Hits) If you'd like to learn more about how to Enable Modern App Delivery at Scale, you might be interested in Proactively Understanding Your Application's Vulnerabilities (Discussion Forum Is That Project Ready for you? Open Source Maturity Models (Breakout) How to balance privacy and security handling DNS over HTTPS (Quick Hits) The DevCentral team will be hosting livestreams, and the DevCentral lounge where we can hang out, connect, and you can interact directly with session presenters and other technical SMEs. Please go to https://agility2022.f5agility.com/sessions.html to see the comprehensive list, and check back with us for more information as we get closer to the conference.
