[cisco-voip] CUCM hostname case-only change?

[Jason Burns]

That was my old DRS bug. The restore would work, but the CAR database
wouldn't be restored because of the case mismatch. The developers fixed
that CAR defect and tested that restores are case insensitive now, but I
wouldn't recommend it. As a colleague always says "You don't want to be the
ONLY person trying to do a certain thing."

Who knows what lurks in uncharted territory. That's where your certificate
problems probably came from. We fixed the case insensitive part of the CAR
database script, the CAR developers marked it as passed and life moves on.
Now every other component of the product needs to be validated and tested
with case mismatched restores. I'm certain that was never done.

CSCsx45626    6.1.2 DRS restore to different case hostname causes CAR DB
drop

If you REALLY want to change your server to a lower case name (and I
wouldn't recommend it because the cost in risk and time outweighs the
benefit) the safest way might  be a double change

SERVER1 -> newserver1 -> server1

Going straight from SERVER1 -> server1 is going to expose you to all sorts
of fun untested scenarios. If you enjoy finding defects and working with
TAC (and have lots of extra time) then go for it and let us know if it
works!

-Jason

On Fri, Jul 6, 2012 at 12:31 PM, Ryan Ratliff <rratliff at cisco.com> wrote:

> I'd agree with Chris on all points.  At the least you exposed a DRF bug
> because it allowed the restore to complete.  If such a restore is to be
> allowed then you've exposed a bug with the duplicate certs.
>
> If this is a test cluster you can play with then I'd open a TAC SR and
> work to figure out exactly what happened and get some things fixed.  If you
> need it back 100% operational then do your restore on the caps hostnames
> and then change them using the correct procedure.   If you go this route
> pay attention to the certs after the hostname change to see if they also
> broke there.
>
> -Ryan
>
> On Jul 6, 2012, at 9:54 AM, Chris Ward (chrward) wrote:
>
> 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
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
>
> _______________________________________________
> cisco-voip mailing list
> 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/20120713/2cf05537/attachment.html>