I figured that a reboot would work, but TAC told me it wouldn't... and rather than experimenting, I just did what they said to do :) Besides, deactivating TFTP is trivial and in a properly laid out deployment should have 0 impact.
On Wed, Nov 30, 2016 at 8:28 AM, NateCCIE <natec...@gmail.com> wrote: > A reboot does work. What the deal is the new https version of tftp (port > 6972) does not restart with the service restart. So it continues to use > the old cert. But it does stop and start with a service deactivation and > reactivation. Before cucm 11 the tftp over http was only plain text (port > 6970) > > > Sent from my iPhone > > On Nov 30, 2016, at 1:12 AM, James Buchanan <james.buchan...@gmail.com> > wrote: > > Hello, > > If I remember right, it actually has to be deactivated under Service > Management. It's not just restarting the service. > > Thanks, > > James > > On Tue, Nov 29, 2016 at 11:36 PM, Derek Andrew <derek.and...@usask.ca> > wrote: > >> Would a simple reboot accomplish the same as deactivating and activating? >> >> On Mon, Nov 28, 2016 at 2:19 PM, Nick Barnett <nicksbarn...@gmail.com> >> wrote: >> >>> I just thought I would share what happened with this, even though it is >>> super old. Changing the node names to FQDN was mostly painless. The one >>> thing that bit me was bug CSCuy13916. After changing the names of the >>> nodes, the TFTP service needs to be DEACTIVATED and then re-activated in >>> order to fully update the certificates. Before taking those steps, I kept >>> getting certificate errors from CuciLync, but afterwards, everything worked >>> as designed. >>> >>> Other than that, any CTI route points (and any other device as well) >>> that exist will fall to another node in the CMG. Not a big deal, just >>> something to be aware of. >>> >>> Thanks, >>> Nick >>> >>> On Wed, Aug 31, 2016 at 3:13 PM, Nick Barnett <nicksbarn...@gmail.com> >>> wrote: >>> >>>> We are on 10.0 and this cluster has been upgraded over the years from >>>> 8.0 to 8.6 to 10.0. I know it used to be common practice to rip the host >>>> name out of a new node and put in the IP address. That's how we are set >>>> up... but now that I need to do some work with certs so that jabber and >>>> cucilync work properly, it's time to fix this. >>>> >>>> Is there anything I should watch out for? Anything that may bite me in >>>> rare cases? We have CER, CVP, CUC, UCCE and a rarely used IMP. >>>> >>>> I checked that each node has DNS enabled by looking at "show network >>>> eth0" on each sub. I also then looked up each FQDN from each node and they >>>> all resolve properly. As far as I know, that's about it. >>>> >>>> Thanks in advance! >>>> >>>> nick >>>> >>> >>> >> >> >> -- >> Copyright 2016 Derek Andrew (excluding quotations) >> >> +1 306 966 4808 <(306)%20966-4808> >> Communication and Network Services >> Information and Communications Technology >> Infrastructure Services >> >> *University of Saskatchewan*Peterson 120; 54 Innovation Boulevard >> Saskatoon,Saskatchewan,Canada. S7N 2V3 >> Timezone GMT-6 >> >> Typed but not read. >> >> >> >> >> _______________________________________________ >> cisco-voip mailing list >> cisco-voip@puck.nether.net >> https://puck.nether.net/mailman/listinfo/cisco-voip >> >> > _______________________________________________ > cisco-voip mailing list > cisco-voip@puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-voip > > > _______________________________________________ > cisco-voip mailing list > cisco-voip@puck.nether.net > https://puck.nether.net/mailman/listinfo/cisco-voip > >
_______________________________________________ cisco-voip mailing list cisco-voip@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-voip