Auto-Generation of Missing Data for SecureCRT .ini Files

[bclarke]

Hello!

I am working on a script that does some file manipulations to keep SecureCRT session IP addresses in sync across multiple machines. Our network environment frequently changes so IP Address information tends to get out of date rather quickly. I have a working solution that essentially copies the sessions, removed everything but the 'S:"Hostname"=' line in any given .ini file and sends that to a centralized server. Other machines can then download that file from the centralized server to have the latest update.

I am having an issue with the default values that are populated into a given .ini file - they do not match the values set in the Default.ini file. To test things out I made a .ini file, (outside of SecureCRT), that only has one line: 'S:"Hostname"='. Of course, I put the IP in there and then save the file. When I go to open SecureCRT to test the file it populates the missing lines (which is everything) into the .ini file I created. However, when I look at what was written to the .ini file I see data that does not match the settings in the Default.ini file. For example, there is no output log destination (Log Filename V2) and the scroll back buffers dont match what is set in Default.ini.

Where is this data being generated from? Is there another Default.ini file that I can find? Does the Default.ini only apply to new sessions created inside SecureCRT?

FYI I am running the following SecureCRT Version:
SecureCRT Version 8.5.1 (x64 build 1764)

[jdev]

Hi bclarke,

You've shown some great initiative. Kudos!

Unfortunately, your approach is one that lives on borrowed hope -- the hope that SecureCRT will fill in missing data in a preexisting session by copying that missing data from the Default session. But that's not how SecureCRT works.

Ever wonder where the Default.ini file comes from on a brand new configuration that doesn't have a Default.ini file yet? SecureCRT creates this initial Default.ini from its internal 'default' settings.

If a session already exists (by the presence of a .ini file), but doesn't have settings defined within its .ini file, those settings are not initialized by copying from the Default session. Instead missing settings for sessions read in from existing -- but partial -- .ini files are initialized from SecureCRT's internal 'default' settings.

Your approach fails because you're creating your sessions outside of SecureCRT, rather than using SecureCRT to create your sessions. If you use SecureCRT to create the sessions (rather than filling in missing data for sessions created outside of SecureCRT's awareness), then session settings are inherited from the Default session.

I have created a feature request for you such that (for all but the Default session itself, of course), missing session configuration data can be derived/inherited from the Default session. This is a feature that is not something that has been evaluated for any implementation time frame. As such, there is no ETA as to when if ever it would be implemented. However, if a version of SecureCRT becomes available with this feature that you desire for your specialized case, we can post a notification here should such a day arrive.

In the mean time, if you want to have a common "database" of hosts, the suggested solution is to have a script that -- rather than pulling session .ini files from the the "file" (do you mean a folder?) located on your centralized server -- iterates over that folder structure (or file), reading in Hostname and session name from those .ini files (Hostname by way of the contents of the file; session name by way of the .ini file name itself) and uses SecureCRT's scripting API to create/renew your session hierarchy.

While we don't have a singular script that does exactly what you want, if you have a "Session Master" -- someone who is responsible for having the "right" configuration -- they could potentially use the approach demonstrated in the CSV-targeted version of the "Iterate Over Saved Sessions" example to create a singular CSV file with all the "right" sessions, copying the resulting CSV file to the centralized server location.

Then, the rest of your team could use the approach is demonstrated in the "Import Arbitrary Data from File to SecureCRT Sessions" example script to refresh their existing session hierarchy when desired by running a version of the import script and pointing to the CSV file that has the refreshing data within.

Both example scripts mentioned here are listed within the Script Examples "Sticky".

--Jake

[bclarke]

Ah! I had a feeling that this was the case but I was not 100% certain. This was a lot of great and helpful information! Thank you for creating a feature request- I have a few work around ideas that I was waiting to try (based on the response I received) so I will explore those first. Either way I think this could be useful for others. I will keep my eye out for any updates on this going forward.

I do have a follow-up question about the SecureCRT API that you've mentioned. Are you referring to executing python scripts within SecureCRT to create and renew the session hierarchy?

Based on how I have my script implemented, it would require a significant re-write to make things work as I envisioned in SecureCRT. However, I am willing to give it a try if the ideas I alluded to earlier does not work out.

Thanks for the all the information Jake!

[jdev]

Originally Posted by bclarke

I do have a follow-up question about the SecureCRT API that you've mentioned. Are you referring to executing python scripts within SecureCRT to create and renew the session hierarchy?

Yes. I am referring to running scripts inside of SecureCRT.

SecureCRT's scripting API is not externally available; only SecureCRT can run scripts that use its scripting API.

SecureCRT can be instructed to run a script at startup by specifying the /SCRIPT command line arg. For example, on Windows:

SecureCRT.exe /SCRIPT %APPDATA%\VanDyke\Config\Scripts\MyScript.py

The example scripts I referenced in my earlier post involve running scripts internally within SecureCRT; those scripts leverage some aspects of SecureCRT's internal scripting API. The entirety of SecureCRT's internal scripting API is documented within SecureCRT's built-in help. Help > Help Topics, then select the Contents tab and expand the Scripting and Script Objects Reference chapters.

--Jake

[bclarke]

Got it, thank you for the clarifiction.

You gave me a couple additional ideas with the /SCRIPT example. I'll do some reading on this in the documentation.

Thanks again Jake!