I have a deprecated config source from LM that collects from FortiGate Firewalls, collects a config, and it keeps having a difference check on lines with #conf_file_ver=. We have kept this deprecated...
I am starting to think this is a feature, that maybe LM doesnt have a later version of the Config that wasnt considered a change.
I abandoned my script clone that printed out fake (but changing) data, and went back to the first clone that really reads from the device, and I made the diff check for that item to just ignore changes to any line that has conf_file_ver= on the line. I changed the apply to false() and back to my 3 target test devices, just to clear out any old configs or alerts.
It ran on all 3 devices around 8:33 am today, and collected every hour. At some point I saw 13:33 or whatever as the most recent check, but the config was just showing the most recent update as being from 8:33 still. So I thought it hadnt changed. But on a whim, I did a manual pull of the config and it HAS changed.
So I waited until 14:33 and after LM checked again (and I reloaded the page) and it STILL shows the data from 8:33 am and thats the only existing config. So I'm guessing LM doesnt actually store a newer version of the config, if the items that flag it as a change, wouldnt otherwise make the config be considered a change.
At least, it seems that way to me. If thats the case then my difference test is now working and I'll just see what changes happen naturally over the weekend, and if they have all changed on that one line and LM is still only providing the one from 8:33 am today but has still been checking, then I'll feel sure about it, at which point I'll edit the original.
Cheers!
Anonymous
3 months ago
Lewis_Beardwrote:
LM doesnt actually store a newer version of the config, if the items that flag it as a change, wouldnt otherwise make the config be considered a change.
That's what i was poorly explaining before. When LM pulls the config, unless an "important" part of the config has changed, it doesn't register a new version of the config.
Well, except now I'm more confused than ever. 2 of the configs across the 3 servers in my applies-to conditions have have changed, specifically that line. LM has polled them both since they changed, and the one I was referring to above still hasnt thrown a difference error, so I thought my difference check was finally working.
But that second one that changed, the same line changed, and it shows it as a diff. So its back to the drawing board. Good grief.
I dont see why this difference check wouldn't work, and even less certain why LM decided to cache one of them and give no alert, but change the other and show an alert, even though both have changed and both I can see the last check was after the change.
If I could get this cleared up I'd knock 900 warnings off my portal. I dont get it. I almost wonder if LM is oracle database under the hood and its treating those underscores, which I'm assuming should be literals, as some kind of wildcard like oracle does with underscores. Surely not. Makes no darned sense to me.
And this isnt my first rodeo. I've successfully done difference tests on custom configs several times and tested then and they worked. So I got no idea why editing an existing one is being weird.
I suppose I may as well try regex looking for "conf.file.ver= or something, with the . matching any 1 character in an attempt to avoid the underscores.
Grr. I know I'm not doing something stupid. But I think I'm doing something stupid. :)
I also just remembered MySQL also treats underscores as wildcards for a single character. Which technically would make me think it should still work. But maybe if the compare is done in the DB itself somehow .... I'm clearly grasping at straws and its Friday so I'm tired. :)
Wish me luck on:
Otherwise I guess I'm living with 900 warnings. :)
Anonymous
3 months ago
What has support said? In the past, when i start talking config sources, i get glassy eyes, and "that particular way of doing it is totally allowed in the UI, but not supported"