My original reply still applies to patch dependencies. IMHO if one needs certain patches to address negatively impacting behaviour, one looks into all of the dependencies required, perform the appropriate lab testing, and then deploy if all lab testing and pre-production soak periods have passed without problems. If there are any problems in testing, one has to consider which bugs/behaviours are worse to live with for the time being and make a judgement call. Really it's all about trade-offs, some prefer to take the extra time and be more thorough and others like to take extra risks to be more nimble. I'm more in favor of being as thorough as possible and taking the time to ensure as smooth of a patch rollout as possible to mitigate as much risk as possible relating to new bugs and/or unwanted behaviours. Regards, Justin Randall -----Original Message----- From: voiceops-bounces at voiceops.org [mailto:voiceops-bounces at voiceops.org] On Behalf Of Jason Warner Sent: Wednesday, February 03, 2010 4:11 PM To: David Hiers; VoiceOps at voiceops.org Subject: Re: [VoiceOps] Broadworks Patch Religion The problem with this approach is that you get so far behind on patches that when you need to apply a specific patch you can't because of patch dependencies. You often cannot apply only the patches you want because of this. With as many patches released by Broadsoft, tracking the dependencies and which patches you need to apply in order to apply the patch(es) you need becomes problematic. The longer you wait, the more problematic it becomes. -Jason Warner ----- Original Message ----- From: "Justin Randall" <jrandall at comwave.net> To: "David Hiers" <hiersd at gmail.com>, VoiceOps at voiceops.org Sent: Wednesday, February 3, 2010 12:19:43 PM Subject: Re: [VoiceOps] Broadworks Patch Religion With almost any piece of vendor software, patching always carries the risk of introducing newer (and potentially more harmful) bugs. While Broadsoft does a good job of attempting to document the interfaces impacted by each patch, unless something is not working correctly in your deployment, it's probably best to go by the approach of "if it isn't broken, don't fix it". I know they have an N-2 support policy but this is main release and service pack based so it's not like you couldn't get support or further patches for your issues because you haven't installed the latest patch bundle or AP. AFAIK on R16 you don't even need to upgrade SPs at all and can simply stick with the R16 main release and add whichever patches you require. Regards, Justin Randall -----Original Message----- From: voiceops-bounces at voiceops.org [mailto:voiceops-bounces at voiceops.org] On Behalf Of David Hiers Sent: Tuesday, February 02, 2010 3:00 PM To: VoiceOps at voiceops.org Subject: [VoiceOps] Broadworks Patch Religion For our entire history with BW, we've carefully researched and selected individual patches to apply based on the functions that we use and the issues that we see. BW explicitly states that "customers can pick and choose the patches they want", and they make it easy for us to do so. This process has worked quite well for us so far. It takes a good deal of effort to keep up with over 1 patch per day across the entire BW universe of products, but we've done it and had good results. Recently, the "open you mouth and close your eyes" idea has been advanced, in which we would apply ALL patches, regardless of function or issue. We'd wait 30 days or so to let everyone else find the problems with the contents of the default patch bundle, then just slap the bundle on without any thinking. We'd still test like chimps on crack after patching, of course. Are you picky or promiscuous with your BW patches? Since this discussion is very vendor/version specific, we run BW R14sp9. Thanks, David Hiers _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
We can reason all we want to about this, but there is one large area of unknowns... Patch release notes are imperfect, and embarrassing secrets can exist inside companies and code; one whisper from a trusted Broadsoft employee is enough to nudge me down the "patch everything" (aka "open your mouth and close your eyes") maintenance path. David On Wed, Feb 3, 2010 at 5:24 PM, Justin Randall <jrandall at comwave.net> wrote:
My original reply still applies to patch dependencies.
IMHO if one needs certain patches to address negatively impacting behaviour, one looks into all of the dependencies required, perform the appropriate lab testing, and then deploy if all lab testing and pre-production soak periods have passed without problems. ?If there are any problems in testing, one has to consider which bugs/behaviours are worse to live with for the time being and make a judgement call.
Really it's all about trade-offs, some prefer to take the extra time and be more thorough and others like to take extra risks to be more nimble.
I'm more in favor of being as thorough as possible and taking the time to ensure as smooth of a patch rollout as possible to mitigate as much risk as possible relating to new bugs and/or unwanted behaviours.
Regards,
Justin Randall -----Original Message----- From: voiceops-bounces at voiceops.org [mailto:voiceops-bounces at voiceops.org] On Behalf Of Jason Warner Sent: Wednesday, February 03, 2010 4:11 PM To: David Hiers; VoiceOps at voiceops.org Subject: Re: [VoiceOps] Broadworks Patch Religion
The problem with this approach is that you get so far behind on patches that when you need to apply a specific patch you can't because of patch dependencies. ?You often cannot apply only the patches you want because of this. ?With as many patches released by Broadsoft, tracking the dependencies and which patches you need to apply in order to apply the patch(es) you need becomes problematic. ?The longer you wait, the more problematic it becomes.
-Jason Warner
----- Original Message ----- From: "Justin Randall" <jrandall at comwave.net> To: "David Hiers" <hiersd at gmail.com>, VoiceOps at voiceops.org Sent: Wednesday, February 3, 2010 12:19:43 PM Subject: Re: [VoiceOps] Broadworks Patch Religion
With almost any piece of vendor software, patching always carries the risk of introducing newer (and potentially more harmful) bugs.
While Broadsoft does a good job of attempting to document the interfaces impacted by each patch, unless something is not working correctly in your deployment, it's probably best to go by the approach of "if it isn't broken, don't fix it". ?I know they have an N-2 support policy but this is main release and service pack based so it's not like you couldn't get support or further patches for your issues because you haven't installed the latest patch bundle or AP.
AFAIK on R16 you don't even need to upgrade SPs at all and can simply stick with the R16 main release and add whichever patches you require.
Regards,
Justin Randall
-----Original Message----- From: voiceops-bounces at voiceops.org [mailto:voiceops-bounces at voiceops.org] On Behalf Of David Hiers Sent: Tuesday, February 02, 2010 3:00 PM To: VoiceOps at voiceops.org Subject: [VoiceOps] Broadworks Patch Religion
For our entire history with BW, we've carefully researched and selected individual patches to apply based on the functions that we use and the issues that we see.
BW explicitly states that "customers can pick and choose the patches they want", and they make it easy for us to do so. ?This process has worked quite well for us so far. ?It takes a good deal of effort to keep up with over 1 patch per day across the entire BW universe of products, but we've done it and had good results.
Recently, the "open you mouth and close your eyes" idea has been advanced, in which we would apply ALL patches, regardless of function or issue. ?We'd wait 30 days or so to let everyone else find the problems with the contents of the default patch bundle, then just slap the bundle on without any thinking. ?We'd still test like chimps on crack after patching, of course.
Are you picky or promiscuous with your BW patches?
Since this discussion is very vendor/version specific, we run BW R14sp9.
Thanks,
David Hiers _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
On 08/02/10?08:02?-0800, David Hiers wrote:
We can reason all we want to about this, but there is one large area of unknowns...
Patch release notes are imperfect, and embarrassing secrets can exist inside companies and code; one whisper from a trusted Broadsoft employee is enough to nudge me down the "patch everything" (aka "open your mouth and close your eyes") maintenance path.
By reading between the lines I can only assume that there are serious bugs and security vulnerabilities that are not documented, and quietly fixed in patches. That's a nasty way to hold patches over your head. There are reasons why a software producer should *always* document fixed vulnerabilities. It should be part of the normal release cycle. I shudder at the thought of depending on a software producer that is OK with embarrassing secrets existing inside their code. -- Dan White
I'm just not willing to assume that everyone tells me everything about everything all the time in a perfectly instantaneously, error-free manner. Even if they tried, they couldn't pull it off. David On Mon, Feb 8, 2010 at 8:17 AM, Dan White <dwhite at olp.net> wrote:
On 08/02/10?08:02?-0800, David Hiers wrote:
We can reason all we want to about this, but there is one large area of unknowns...
Patch release notes are imperfect, and embarrassing secrets can exist inside companies and code; one whisper from a trusted Broadsoft employee is enough to nudge me down the ?"patch everything" (aka "open your mouth and close your eyes") maintenance path.
By reading between the lines I can only assume that there are serious bugs and security vulnerabilities that are not documented, and quietly fixed in patches.
That's a nasty way to hold patches over your head. There are reasons why a software producer should *always* document fixed vulnerabilities. It should be part of the normal release cycle.
I shudder at the thought of depending on a software producer that is OK with embarrassing secrets existing inside their code.
-- Dan White
On 08/02/10?08:28?-0800, David Hiers wrote:
I'm just not willing to assume that everyone tells me everything about everything all the time in a perfectly instantaneously, error-free manner.
Even if they tried, they couldn't pull it off.
Trust No One and Verify, Verify, Verify are good security policies, and I don't expect a company to always produce bug free software. However, I do expect a company to document all fixes and security patches. There's no excuse to do otherwise. If they can't hold to that promise, then they should open up their source code for peer review. -- Dan White
participants (3)
-
dwhite＠olp.net -
hiersd＠gmail.com -
jrandall＠comwave.net