cnMaestro Temple help - pushing unintended changes

[ninedd]

So, I need some help or advice on cnMaestro templates please.

A couple days ago, I made the template to disable the INSTALLER, HOME, and READONLY users. I was getting ready to push FW 4.7 to all our ePMP, and I wanted to disable those extra accounts.

My template contained just the three sections for those three accounts, and nothing else. I basically cut and pasted from the examples here.

However, after I applied the template everywhere, and then at 3:00 a.m. I applied the 4.7 firmware to everything – and then the next day, we noticed some of our ePMP had different ‘device names’ than they should have.

We noticed it on backhauls and APs (It’s pretty obvious if an F300 was named ‘Kingston-Slave’ And then the next morning it’s named 'Fred Smith).

So, I suspect the ones that were changed, we’re probably radios that we configured months ago for some purpose or did testing, and then changed our minds or reprogram these for where they are now. So it seems like cnMaestro went and now ‘corrected’ what it thought should have been the device names of these devices? It didn’t change SSIDs or IPs or things like that, so nothing really broke… but we ended up with a bunch of radios which The device name are different (and who knows what else?).

So, is this something we did wrong? I’m confident there was nothing else in the template. Is there some other checkbox needed to be checked on, or checked off, to get it to only affect the sections we intended? My biggest concern is what it may have done to hundreds of SM’s. It was pretty obvious to see (and repair) these changes at a glance on the infrastructure devices, but looking through hundreds of SMs for mislabeled ones will be a daunting task.

[Fedor]

Is the new “old” name displayed on cnMestro only?
Or it’s displayed both on device’s UI and cnMaestro?

Thank you.

[ninedd]

@Fedor

displayed both on device’s UI and cnMaestro?

Yes, both. We noticed it in cnMaestro first… looking down our BACKHAULS network in cnMaestro, it was obvious there were some re-named Masters/Slaves. Logging into the radios themselves, the ‘Device Names’ were changed there, although the SSID and IP’s and stuff all seemed correct still.

We then looked in our ‘default’ network, and noticed that some of the AP’s where renamed as well, and we logged into the radios and changed them back. Again, the SSID’s were correct to the IP’s, but the ‘device names’ were incorrect.

So, that was about a half-dozen changes, so not a big deal. My fear is that maybe there might be dozens (or more?) of client SM’s with changed device names now, and I don’t know how we would even find them, or know what to change them back to.

So – I need to apply the SNMP password changes, but I’m afraid to do that now, without understanding what went wrong.

[ninedd]

@ninedd

I’m confident there was nothing else in the template.

This was basically the whole template…

{
	"device_props": {
		"cambiumSysAccountsTable": [{
				"cambiumSysAccountsName": "installer",
				"cambiumSysAccountsHash": "",
				"cambiumSysAccountsUID": "2000",
				"cambiumSysAccountsGID": "100",
				"cambiumSysAccountsDir": "\/tmp",
				"cambiumSysAccountsShell": "\/bin\/false"
			},
			{
				"cambiumSysAccountsName": "home",
				"cambiumSysAccountsHash": "",
				"cambiumSysAccountsUID": "3000",
				"cambiumSysAccountsGID": "100",
				"cambiumSysAccountsDir": "\/tmp",
				"cambiumSysAccountsShell": "\/bin\/false"
			},
			{
				"cambiumSysAccountsName": "readonly",
				"cambiumSysAccountsHash": "",
				"cambiumSysAccountsUID": "4000",
				"cambiumSysAccountsGID": "100",
				"cambiumSysAccountsDir": "\/tmp",
				"cambiumSysAccountsShell": "\/bin\/false"
			},
			{
				"cambiumSysAccountsName": "dashboard",
				"cambiumSysAccountsHash": "",
				"cambiumSysAccountsUID": "5000",
				"cambiumSysAccountsGID": "100",
				"cambiumSysAccountsDir": "\/tmp",
				"cambiumSysAccountsShell": "\/bin\/false"
			}
		]
	}
}

[Fedor]

Thank you for the clarification.
I completely understand your fear.
We are looking into the issue now and I may revert to you for extra details and remote access.

Thank you.

[brubble1]

@ninedd

So, I suspect the ones that were changed, we’re probably radios that we configured months ago for some purpose or did testing, and then changed our minds or reprogram these for where they are now.

If you already changed them back maybe to late but wondering if it did actually revert to old names on the radios then downlaoding the .json would have revealed more than one :

“systemConfigDeviceName”:

I’ve wondered what kind of problems will crop up using cnMaestro to make piecemeal changes to the config and wondered if there would be duplicate settings in the config.

[ninedd]

Well, yes, I think these did revert to Device Names that had been used in testing previously. They were not ‘random’ strings, they all changed to devices names which were ‘familiar’ labels used while testing in the shop years ago or whatnot.

[Au_Wireless]

Following. We are not able to keep Device Names through a power cycle (not a reboot). Since 4.7.0, both Device Name and GPS coordinates will revert back to their pre-4.7.0 state upon a power cycle to the radio. Can reproduce on 100% of our 4.7.0 client radios. Spent considerable man hours fixing radios only to find them revert as soon as the radio was power cycled. Something has changed in the json file and I don’t think it’s writing to the correct field anymore. Lasts through reboots but not power cycles.

[dkeltgen]

We’ve run into this, but we’re running an older version of on-site cn, so maybe this is fixed. The problem, for us, was when we renamed a device that’s already been onboarded in cn via the radio’s web interface. cn will show the new (correct) device name on the main page, however, if you click to the “configuration” tab it will sill show the previous hostname. Then, once you push a config change via cn, the old hostname will get applied to the radio.