[cisco-voip] CUCM services log files paths

[Wes Sisk]

Ovidiu,

Thanks for the background. That may prove to be the difference.

MLA authentication is completely dependent on the database. That is why 
I started with questions in that direction.  Restore replaces the 
database so the entire MLA feature *shouldn't* be affected by anything 
in the OS.

That said, MLA authentication is failing for some reason.  Is there 
anything in security logs about authentication failure?  Perhaps the IMS 
logs give indication:

file list activelog syslog/*
file list activelog tomcat/logs/*

Regards,
Wes

On 6/9/2011 4:59 PM, Ovidiu Popa wrote:
> Wes,
>
> Just wanted to add some details to the problem:
>
> - Installed CUCM and CUC cluster on UCS
> - Restored the Production backup on the new virtual machines
> - Both CUCM and CUC have the same behaviour
>
> While installing I did some tests and used the same application 
> username albeit with a different password than the production servers.
> CCMADMIN login with the installation username/password worked before 
> the restore
> CCMADMIN login with the production username/password worked after the 
> restore
>
> I'm wondering if there is some information that is written in the CUCM 
> OS by the installation process and not replaced by the restore process 
> :does MLA have some configuration files in the CUCM OS e.g. passwords 
> in tomcat configuration files? Am I on the right track ?
>
> Thanks,
>
> Regards,
> Ovidiu
>
>
> On Thu, Jun 9, 2011 at 5:40 PM, Ovidiu Popa <ovi.popa at gmail.com 
> <mailto:ovi.popa at gmail.com>> wrote:
>
>     yes to both.
>
>     On Thu, Jun 9, 2011 at 5:32 PM, Wes Sisk <wsisk at cisco.com
>     <mailto:wsisk at cisco.com>> wrote:
>
>         So TCP comes up and it attempts MLA login. Usually that means
>         database is offline.  Can you login to CCMAdmin/user pages? 
>         Can your 'run sql....' commands from the CLI?
>
>         Regards,
>         Wes
>
>
>         On 6/9/2011 11:04 AM, Ovidiu Popa wrote:
>>         Wes,
>>
>>         If got the popup that said the certificate is not trusted so
>>         TCP should be good. After the popup I see in the wireshark
>>         some communications and then it stops for exactly 1 minute
>>         (exactly as seen in the logs).
>>
>>         Regards,
>>         Ovidiu
>>
>>         On Thu, Jun 9, 2011 at 4:13 PM, Wes Sisk <wsisk at cisco.com
>>         <mailto:wsisk at cisco.com>> wrote:
>>
>>             Ovidiu,
>>
>>             This looks like a problem with TCP/IP connectivity form
>>             your client to the CUCM server.  What does a packet
>>             capture show?
>>
>>             RTMT connects to servers on TCP port 8443.  You can view
>>             a list of required port connectivity in Unified OS
>>             Administration under Show->IP Preferences.
>>
>>             Regards,
>>             Wes
>>
>>
>>
>>             On 6/9/2011 7:03 AM, Ovidiu Popa wrote:
>>>             Hello everyone
>>>
>>>             Does someone know where we can find a list with the
>>>             correlation between CUCM services (network and feature)
>>>             and their corresponding log files paths?
>>>
>>>             I'm having problems logging into RTMT, it stops with the
>>>             message that it cannot reach the cluster. The PC log
>>>             files are not very specific and I wanted to see on the
>>>             CUCM side what is the problem.
>>>
>>>             2011-05-30 12:30:42,000 [SplashThread] INFO
>>>              rtmt.control - validMLALogin():  inside isSecureEnabled
>>>             2011-05-30 12:31:42,515 [SplashThread] ERROR
>>>             rtmt.control - validMLALogin(): caught
>>>             java.lang.Exception, e=java.net.SocketTimeoutException:
>>>             Read timed out
>>>
>>>             According to this
>>>             http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/service/8_5_1/rtmt/rtintro.html#wp1278618
>>>             the Cisco Communications Manager servlet handles RTMT
>>>             and the problem is what is the path for the logs for
>>>             this service...
>>>
>>>             I wasn't able to find any information about these paths.
>>>             It seems we should blindly trust RTMT to collect the
>>>             files but they don't say what should we do when we need
>>>             to debug RTMT itself?
>>>
>>>             Thanks for the input.
>>>
>>>             Regards,
>>>             Ovidiu
>>>
>>>
>>>             _______________________________________________
>>>             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/20110610/337d038b/attachment.html>