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...
Anonymous
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. :)