search

p4r4n0y1ng / pyfmg

Represents the base components of the FortiManager JSON-RPC interface
Apache License 2.0
27 stars 23 forks source link

Locking ADOM's #1

Closed mwclark4453 closed 6 years ago

mwclark4453 commented 6 years ago

I don't really consider this an issue per se. We've got an environment where the FMG is set to workflow normal so I need to lock the ADOM before I do any updates. I know the URL and can use pyFMG to do the exec but I'm concerned that in the event of an abnormal exit, I'll just logout of the context and not actually unlock the ADOM. What is the correct way to structure the code in order to catch this before a logout is run? A try..except inside the context?

During testing of my code, there have been several times I left unintentionally because of bugs and the context correctly logged out before exiting but I'm worried something will creep in and I'll logout and leave an ADOM locked. Again, not an issue as much as a correct way to handle this exception.

p4r4n0y1ng commented 6 years ago

Hey, great point! Not only did I not think about it, I didn't think anyone would be using this but my team and I, so shock number 2. Before I move on this, I'd like to get your point of view. How about I make the module smart enough so that if it is locked, it looks and runs an unlock......? I think I might be missing something though, and would rather have your input. What say you?

mwclark4453 commented 6 years ago

We luckily do not use workflow for our locking on the FMG that is the target so I did a quick and dirty lock ADOM, set URL, commit ADOM, unlock ADOM hack that is working fine inside the loop for each individual table URL that I'm importing. For a more complicated scenario, I was thinking of the following: Create fortimanager context if the method is set, update, etc., create a Lock ADOM context with a doCommit flag. Do the set commands, checking for the status. If anything other than 0, don't set the doCommit flag on exit, if the doCommit is true, commit it and unlock the ADOM, else unlock the ADOM. I haven't had to work on a complex workflow yet but I thought that framework would lend itself to a more complicated workflow with rollback, etc. I was also thinking that it would allow me to move the lock above the table loop and allow a complete rollback if any of the table updates failed.

mwclark4453 commented 6 years ago

BTW, I found your pyFMG because I was about to publish a module that would allow me to send any parameters over to the API. I've been using Jim Hilving's FortiToolkit but I need to be able to do things like loadsub, filters, etc. and his doesn't support that yet. I'm working with Jim on enhancing the FTK as well.

p4r4n0y1ng commented 6 years ago

I am working on this, but I think we have a flaw here:

if the method is set, update, etc., create a Lock ADOM context with a doCommit flag. Do the set commands, checking for the status. If anything other than 0, don't set the doCommit flag on exit, if the doCommit is true, commit it and unlock the ADOM, else unlock the ADOM.

Here's why - if we hit an error - we have to assume that SOMETHING WENT WRONG and possibly in the middle of some changes that needed to be atomic. I'm going to make this where if an error is hit OR EVEN A LOGOUT is called, pyfmg will just keep track if anything is locked. If it is, it will then unlock all of it prior to the exit finishing and then you're unlocked and back to where you can control the system. Commit will be accomplished either by you calling commit, or I will give the locking context the ability to call a "mass commmit" meaning any ADOM that has ANY changes will just run through and make a commit to it. This ensures you are in control of committing since you may actually NOT want a commit to run for some reason - I don't want to take that out of your hands. However, it will take it out of your hands when it "leaves" because I just can't think of a reason why you'd leave an ADOM locked and logout unless you were just being mean to your coworkers ;)

mwclark4453 commented 6 years ago

That will be perfect. That way we can control the commits and if an error just leaves it unlocked and lose the changes, which should be expected in the event of an error. And yes, coworkers do get rather irritated over scripts leaving the ADOM locked :)

p4r4n0y1ng commented 6 years ago

Done gang. Please check the README. I added quite a bit to help with Workspace/Flow. Seems to work well so far and the README calls out most of what you'll need to play with. You should now not be locked out anymore.

Also, as required by the other comment/issue, I now allow (and actually CAUSE) exceptions to propagate so you can debug/catch on your own and use the information.