[cisco-voip] firmware COP files - TFTP server only? or all nodes?

Tue Sep 12 12:42:59 EDT 2017

That’s very interesting information about the image and reboot/reset icon.

Unfortunately, I know it’s hard to go back to update documentation when newer versions of software are released, but it would be good to know exactly when a device pack is necessary. For example, if the device pack for the particular version of software is older than the latest SU patch, I’m pretty sure it’s not. So rather than updating the documentation for firmware files, at least updating the documentation for the device pack when new patch files are released would be good. Or include information in the release notes that say, “this release includes device pack xyz, no need to install it”

And of course, someone’s gonna tell me that that information _is_ included in the release notes next. ☺

---
Lelio Fulgenzi, B.A.
Senior Analyst, Network Infrastructure
Computing and Communications Services (CCS)
University of Guelph

519-824-4120 Ext 56354
lelio at uoguelph.ca
www.uoguelph.ca/ccs
Room 037, Animal Science and Nutrition Building
Guelph, Ontario, N1G 2W1

From: cisco-voip [mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Ryan Ratliff (rratliff)
Sent: Tuesday, September 12, 2017 11:41 AM
To: Dave Goodwin
Cc: cisco-voip list
Subject: Re: [cisco-voip] firmware COP files - TFTP server only? or all nodes?

In some cases the device definitions (e.g. support for new model or new product specific configuration settings) need to be updated. I believe that is another reason that *some* devpacks need to be installed on all nodes rather than just TFTP nodes.

There are three basic pieces required to add new device support to the cluster.

  1.  The device definition xml files. These contain the information that will be added to the varions database tables (typemodel, productsupportsfeature, etc) that tell the various processes about the new device.
  2.  The image that CCMAdmin uses for the icon on the Device->Phones page.
  3.  The firmware files associated with the model.

Number 1 only happens on the publisher, because it’s a change in the database tables. The subscribers pick up the changes through dbreplication, and in 11.5 the ccm process picks up the new model through change notification on those db tables. Because the process to load the device xml files into the database isn’t selective there is too much change on the publisher’s database for change notification to work so you still have to restat the Cisco CallManager process on the publisher to pick up new devices.

Number 2 is often overlooked (because it’s cosmetic), but is why a device pack for a new model should be installed on all nodes. Most people ignore this part and I bet never notice it because they don’t use CCMAdmin on subscribers. You must restart Cisco Tomcat on each node after the device pack is installed for it to display the icon correctly. I’ve seen it once or twice where after a reboot the icon doesn’t load correctly until the next Tomcat restart.

Number 3 is optional since new devices will ship with their first release version (mostly). It is pretty common these days for the device pack that adds a new device to not include the release software, and for some endpoints we never package firmware in a device pack. If you are loading software then for this to work the device pack must be installed on all TFTP servers.

-Ryan

On Sep 11, 2017, at 5:20 PM, Dave Goodwin <Dave.Goodwin at december.net<mailto:Dave.Goodwin at december.net>> wrote:

In some cases the device definitions (e.g. support for new model or new product specific configuration settings) need to be updated. I believe that is another reason that *some* devpacks need to be installed on all nodes rather than just TFTP nodes.

If you are concerned about the Device Defaults being updated when you install the devpack on the publisher (a good thing to be thinking about), one thing you could consider doing is as follows. Prior to doing anything, take a snip of the Device Defaults and then stop Cisco TFTP on the TFTP nodes (or de-activate under Service Activation, since these installs sometimes call for a reboot in the docs). Then after your devpack install is complete, go to Device Defaults and change anything back to the pre-devpack state if that is your wish. Then you can start up Cisco TFTP again. After that, you may wish to initiate an all-devices restart by hand or through BAT. Especially if any of the devpack updates affects your existing devices.

Just keep in mind, sometimes the product specific configuration updates that are provided with devpacks actually require new device firmware to be installed. So you could get into a state where you try to configure something in UCM with a setting in there, but you can't make the config take effect if you prevent the phone from actually updating to a firmware version that recognizes the new setting flag.

-Dave

On Mon, Sep 11, 2017 at 2:57 PM, Ryan Huff <ryanhuff at outlook.com<mailto:ryanhuff at outlook.com>> wrote:
The only reason I add to all nodes for firmware (versus just tftp) is because and in case, you decide to change how the nodes are used or function in the cluster at some point; then you don't have to worry about what is or is not on the node; just activate the service and go :).

Thanks,

Ryan

On Sep 11, 2017, at 2:37 PM, Lelio Fulgenzi <lelio at uoguelph.ca<mailto:lelio at uoguelph.ca>> wrote:
This was my understanding from the last couple of times. We don’t have any alternate TFTP servers so they just attempt to grab it from the one server.

I don’t even like adding it to the publisher since it updates the device defaults page. And we want to do that in a controlled way.

---
Lelio Fulgenzi, B.A.
Senior Analyst, Network Infrastructure
Computing and Communications Services (CCS)
University of Guelph

519-824-4120 Ext 56354<tel:(519)%20824-4120>
lelio at uoguelph.ca<mailto:lelio at uoguelph.ca>
www.uoguelph.ca/ccs<http://www.uoguelph.ca/ccs>
Room 037, Animal Science and Nutrition Building
Guelph, Ontario, N1G 2W1

From: bmeade90 at gmail.com<mailto:bmeade90 at gmail.com> [mailto:bmeade90 at gmail.com] On Behalf Of Brian Meade
Sent: Monday, September 11, 2017 2:33 PM
To: Lelio Fulgenzi
Cc: voyp list, cisco-voip (cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>)
Subject: Re: [cisco-voip] firmware COP files - TFTP server only? or all nodes?

That's correct.  If you don't install the COP file on the publisher, you'll need to manually update the Device Defaults as well.  Otherwise, you just need this on servers running the TFTP service.

On Mon, Sep 11, 2017 at 2:24 PM, Lelio Fulgenzi <lelio at uoguelph.ca<mailto:lelio at uoguelph.ca>> wrote:

Just checking the documentation for COP files for firmware and it says to install to all nodes.

I recalled that if the COP file was just for firmware, we only needed to install it on the TFTP server.

It's only the devpaks that need to be installed on all nodes since they may likely make database changes.

Thoughts?

---
Lelio Fulgenzi, B.A.
Senior Analyst, Network Infrastructure
Computing and Communications Services (CCS)
University of Guelph

519-824-4120 Ext 56354<tel:519-824-4120%20Ext%2056354>
lelio at uoguelph.ca<mailto:lelio at uoguelph.ca>
www.uoguelph.ca/ccs<http://www.uoguelph.ca/ccs>
Room 037, Animal Science and Nutrition Building
Guelph, Ontario, N1G 2W1

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20170912/96402e9c/attachment.html>