VanDyke Software Forums

VanDyke Software Forums (https://forums.vandyke.com/index.php)
-   Scripting (https://forums.vandyke.com/forumdisplay.php?f=14)
-   -   Log File Issues (https://forums.vandyke.com/showthread.php?t=13230)

tjh 08-27-2018 03:41 PM

Log File Issues
 
I have a script that is basically five sub-scripts. When 4 of the 5 sub-scripts run, logging works normally. However, when the final sub-script runs, a log file builds, but only for certain people. A number of my co-workers can generate the resulting output file, but a few can't.

I've tried checking the software versions; and they are all over the place. Here is an abbreviated version list:

Working: Version 8.1.0 (x64 build 1294)
Broken: Version 8.1.4 (x64 build 1443)
Broken: Version 8.0.4 (x64 build 1252)

The only major difference between the sub-scripts, is that the 4/5 that work flawlessly on all machines don't have the need to append; while the 1 sub-script that works only on some machines logs into multiple devices, and appends the output to one file. I verified that I start logging with the following statement:

crt.Session.Log True, True

...and I precede that statement with this one to turn off any existing logs:

If crt.Session.Logging Then
crt.Session.Log False
End If

However, I still can't get the proper output on these two machines. Any ideas why?

ekoranyi 08-27-2018 04:20 PM

Hi tjh,

I'm sorry you're having trouble. To get a better idea of what may be causing the problem can you provide a complete copy of the script that is having trouble. Please be sure your script does not contain any sensitive data and attach it as a .txt file for review.

To help eliminate any configuration issues I would like to see if the problem is still present if we use a known working session configuration on a machine you're currently having trouble with.

If machineA is working and machineB is not take the following steps:
  1. On machineA navigate to Options > Global Options > Configuration Paths
  2. Take note of the location of the Config folder
  3. Navigate to the Config folder and open the Sessions folder inside
  4. Locate the .ini for the known working session and create a copy
  5. Locate the Sessions folder on machineB
  6. Place the copy of the session ini file inside machineB's Sessions folder
  7. Restart SecureCRT

In SecureCRT use the new session to connect to your device. Does running your script now work as expected? Does it behave in the same way it did on the known working machine?

tjh 08-28-2018 11:23 AM

Thanks for your reply.
 
Thanks for your prompt reply.

I'll have to see about sending the entire script. It'll take me some time to scrub it of all sensitive information.

I can try the running the script with the ini of someone that has it fail, but I need to confirm which ini to use. My script doesn't call a specific session, because I couldn't rely on the fact that everybody would have the same session name. I call all of my sessions as an ad hoc session with the following command:

crt.Session.Connect("/TELNET " & siteListArray(iCount,1) & " 23")

The siteListArray contains a list of all sites that I need to connect to, and I use iCount to iterate through the list. In cases where there is only one IP address, then I call the address directly. I presume that the default.ini might be the default session, but I'd like to confirm with you before swapping them.

Thanks in advance.

ekoranyi 08-28-2018 01:00 PM

tjh,

You are correct that all ad-hoc connection will use the default session as a template, and yes that would be the Default.ini found inside the Sessions folder. Rather than overwriting the existing Default.ini I would suggest closing all instances of SecureCRT, renaming the current file to Default-bak.ini, then placing the copied Default.ini in place. This would allow you to revert if needed.

I look forward to hearing your results.

tjh 08-28-2018 06:00 PM

ini Test
 
My coworker, who previously wasn't able to generate the log, was able to run it successfully after I copied my default.ini to his machine. This confirms my suspicion that something in his default session is breaking the logging. Any ideas on what that might be? Would it help if I provided a copy of both default.ini files?

ekoranyi 08-29-2018 08:17 AM

tjh,

I would be happy to take a look at both ini files and see if I can determine what may be causing the difference.

To avoid exposing potentially private data on the forums please provide both files via email. Please attach both files and send an email to Support@VanDyke.com with "Attn: Eric Forum Post 13230" in the subject line.

tjh 08-29-2018 09:59 AM

Sent
 
I've sent both ini files to you, according to your instructions. If you need anything else, please ask.

tjh 08-29-2018 05:22 PM

Possible Solution
 
My script was setting a specific log file at the beginning, and then connecting to multiple sessions. If you don't have a default log file, it works perfectly. However, if you did, whenever someone connected to the first session, it overwrote the log file settings that I set in the very beginning. I changed my script to set the log file parameters after the connection initiates. This way, I overwrite the default for people that have automatic logging.

In any case, my coworker placed his default.ini back in the config directory, and ran the script. It worked just fine. I do miss some output that happens during the connection (motd & login dialog), but I don't really need that information. I'm happy with the outcome.

Thanks to Eric for working with me on this.


All times are GMT -6. The time now is 10:21 PM.