[cisco-voip] CUCM hostname case-only change?
Chris Ward (chrward)
chrward at cisco.com
Fri Jul 6 09:54:51 EDT 2012
Someone who is still in TAC can correct me if I am wrong, but I was under the impression that a DRS restore had to be done with the same IP/hostname as with what the backup was taken with. So while I understand the argument about hostnames being cap-agnostic, I think we all know how seriously the linux operating system takes capitalization.
You can absolutely change hostnames on your CCMs (I probably would have too, so I won't judge), you just have to do it in the proper method.
http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/install/8_6_1/ipchange/ipchg861.html
I would probably revert back (DRS restore on same IP/hostname) and then follow the method outlined in the link to change the hostname. Who knows what else isn't set to what it is supposed to be set to right now in the system.
+Chris
Unity Connection TME
-----Original Message-----
From: cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Beck, Andre
Sent: Friday, July 06, 2012 5:55 AM
To: cisco-voip at puck.nether.net
Subject: [cisco-voip] CUCM hostname case-only change?
Hi,
when upgrading a CUCM cluster all the way from 6.1.2 to 8.6.latest, I found the original cluster members named as CCM1 and CCM2, yes, with all caps in the names. Given hostnames are considered to be case insensitive and all-caps hostnames are a pot-ugly Windows meme that tends to infect Unix platforms, I tried whether changing them to lower case would be feasible. The change was performed by DRF backup (on 8.6.2a), fresh installation of a new 8.6.2a cluster named ccm1 and ccm2, followed by DRF restore. The actual naming in the CUCM configuration is completely name-agnostic and uses IP addresses only (and the platforms have no DNS resolver configured either). Initially, nothing broke.
Later I recognized a number of certificates were now "doubled", the "old ones" for CCM1/2 still existed and new ones for ccm1/2 had appeared in addition. So my next step was to remove all the all-caps certificates.
Even after that, nothing seemed broke regarding call handling.
Then I recognized DRF was dead. Essentially, the DRF Local process would not come up and always log certificate issues. Trying to configure anything in DRF would just freeze/time out, not presenting the expected pages.
To make the long story short, I would like to ask: How bad of an idea was the name fix (it isn't really a name change, given they are semantically equivalent, but not every component seems to think the same way)? Is there a way to correct that? Or should I consider keeping the original names even down to the specific casing mandatory for a supported upgrade?
As all this was just a test for the actual upgrade path, I still have a chance to return to the all-caps names. The only issue will be licensing, as (of course, who would have thought otherwise) the License MAC creation algorithm is one of the components that deals with host names in a case sensitive way. Let's see how often I can rehost that licenses again...
Thoughts on this? Warnings? Outright declarations of me being stupid wasting time on a cosmetic issue?
TIA,
Andre.
--
Cool .signatures are so 90s...
-> Andre Beck +++ ABP-RIPE +++ IBH IT-Service GmbH, Dresden <-
_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip
More information about the cisco-voip
mailing list