*** Critical Flaw in Robot Version 7.62 Build 1269 ***

[Daniel Blanco]

Hello,

We discovered a serious flaw in the Nimsoft Robot v7.62 Build 1269 yesterday that I wanted to make the folks in here aware of. 

 

There was a "BAD" build of Robot version 7.62 that was released and then a newer build was publish but no announcemnt was made and the version did not change. Still the same verison v7.62.

 

Please check if you are running robot version 7.62 and if the Build is < 1330 then you must upgrade your robots to the latest Build of 1330.

 

We had Robot v7.62 [Build 7.6.2.1269 July 14 2014] and the issue was, even though the option to [ ] Automatically un-register when robot goes down was NOT CHECKED OFF,  whenever the robot went down:

• Either thru a Services Stop Nimsoft Robot Watcher,
• Or a Computer Shutdown
• Or Crash\BSOD

the robot did automatically un-registered from the hub.

 

Thus no "Robot is Inactive" alert would be generated and the robot entry is removed from the NMS tree. 

 

Wanted to pass this info along since it was not made aware.

[Louis Savage]

Oh if only this kinda of thing was email or a bug tracker was released... Thanks for the heads up.

[Garin Walsh]

A tangential frustrating item here is that there is a complete disconnect between the meaning of version and meaning of build.

 

Engineering will release new builds for the same version with substantial functionality differences from previous builds but the whole nimsoft archive and infrastructure doesn't care about build numbers. So while this hub version might be available on the internet archive, once you download one of the builds of that version, you never see an indication that the build number has changed for that version.

 

Then, even if you notice it and download the updated build, distsrv ignores the change in build number so if you are forwarding packages to other hubs, this new build of the probe doesn't get forwarded. This leaves you with a nice situation where various instances of distsrv have different sets of software cached.

 

There's a nice script that someone wrote and posted that fixes this but it seems like it is something the software should do, not some add-on script that someone wrote.

 

So, being in the software business, build numbers get used in development where you have a targeted version. Once you release something to the public, the build number and version go static. If you have to fix something, you get a new version. That way there's no question that one is different from the other.

 

-Garin

[Daniel Blanco]

If only there was a section on the support site that had "Announcements" for things like this.. hmm.....   

 

http://support.nimsoft.com/Default.aspx?center=portal/announcement

 

 

But anyway I had to update 1400+ robots last night or I should say downgrade. We reverted back to v7.05 and will wait for v7.63 official. 

 

Along these lines does anyone have any suggestions on doing this in a more efficient manner? We have 100+ Customer Hubs (tunnel) and I went about updating just the robots, not the hubs in the follwoing manner:

 

Within IM I have "Show Groups" enabled in the Tools Options. 

I created a bunch of new Groups:  All Robots, Set1, Set2, Set3, All Hubs

I then did a Ctrl+F (FIND) and did a search on ALL ROBOTS. Found the robots that has the bad build, selected those and dragged them in bunches into the different Set#. 

 

I had to then make sure not to select the HUBs since the when distributing if I am updating the hub in the update, while its rebooting the machines that were queued up would fail since no communication could take place. 

 

*Question, is there an easy way to select just the HUB or search by robot and specify just return HUBS. Initiall I don't see a way unless I populated the User Tags with "HUB".

 

Then after making sure that no hubs were in the SET groups I dropped the robot_update v7.05 from the Archive. 5 out of the 1400 were uncessful but it did take > 1 hour to deploy. I made sure to check off the [ ] Update Only check box. Can anyone explain what does that check box actually do and if you dont' check it what does it do then?

 

Anyone have a better method or suggestion when doing mass deployment updates like this? We are not utlizing the Admin Console as we found this not to be very reliable. 

 

[Garin Walsh]

I wrote a script in LUA to do this.

 

replace the strings of XXXX with the appropriate passwords

 

I appologize for the messy code too - but the general idea is to query CM_NIMBUS_ROBOT and CM_NIMBUS_PACKAGE to get the list of possible robots that need updating. Then do the probe callback to the specific controller to get the installed version of the package. Then if necessary, create a job on the distribution server to deploy the updated package.

 

I had to do 1900 controllers and this script took about an hour to do it all.

 

You can manipulate the logic to be more selective - espeially if you have older systems out there running controllers you can't update because the local OS is no longer supported for instance.

 

-Garin

Attachment(s)

DistributePackage_controller.txt   3 KB 1 version

[Garin Walsh]

This is the location of the conversation about the distsrv sync script

 

http://forum.nimsoft.com/t5/Customer-Upload-Archive/NAS-script-to-sync-distsrv/td-p/2021

[Anon Anon]

On a not completely unrelated side note, relating to the question about including/excluding hubs, I've been developing powershell module which takes that into account:

 

PS C:\Users\administrator.NIMSOFTDEV\Desktop\PS2> Get-Hub | ft robotname, domain

robotname domain
--------- ------
fihkinim01 Development


PS C:\Users\administrator.NIMSOFTDEV\Desktop\PS2> Get-Hub | get-robot | ft hub, name

hub name
--- ----
Primary fihkicen01
Primary fihkicen02
Primary fihkiump01
Primary fihkinim01
Primary fihkidc01.nimsoftdev.local


PS C:\Users\administrator.NIMSOFTDEV\Desktop\PS2> Get-Hub | get-robot -ExcludeHubRobot | ft hub, name

hub name
--- ----
Primary fihkicen01
Primary fihkicen02
Primary fihkiump01
Primary fihkidc01.nimsoftdev.local

 

Haven't implemented distribution yet, though.. but I've implemented callbacks, so the basic functionality is there I'm planning on making it public one day.

 

-jon