Update fortinet_ssh.py

[Trasmontinho]

Several commands in Fortinet needs to be in config mode. The idea here is to propose this feature and be able to pass them. I put by default the config global mode but the user should modify this parameter if wants to enter in the config vdom mode.

I've added also the check_config_mode function & modify consequently the exit_config_mode.

All those updates it's basically a copy paste of the functions available on Cisco and modified to be relative to fortinet devices.

Sam

[ktbyers]

So just making sure I am understanding this correctly--so you are switching the behavior here from being a "config mode" behavior to being a "switch vdom behavior". Is that correct?

Kirk

[Trasmontinho]

No, I've just added the config mode and its counterparts check_config_mode and exit_config_mode.

In Fortigate devices, there is a config mode which can be global or vdom and you need to be in that mode to be able to type some commands.

For example in my case, I've got to switch to config global, to be able to type this command : "get system interface physical"

Sam

[refriedjello]

@Trasmontinho Do the changes include the ability to switch to specific VDOMs instead of global mode? I've been playing around with it a bit, but no luck so far.

[Trasmontinho]

Hi @refriedjello,

by default when you’ll type the connection.config_mode() function, you will enter in global config. You can modify this behavior like connection.config_mode(config_command="config vdom”)

[refriedjello]

This is what I am using, to enter a VDOM named "myvdom" :

net_connect.config_mode(config_command='config vdom')
net_connect.config_mode(config_command='edit myvdom')

I get this error back from the FortiGate:

7657: Unknown action 0 Command fail. Return code -1

[Trasmontinho]

The second command should be something like : net_connect.send_command(“edit myvdom”) or net_connect.send_config_set(config_commands=[“ edit myvdom”])

edit is already part of the config mode under VDOM. That’s why I haven’t supply a config mode specific to a vdom. I tried to be the most generic as possible regarding it to be compliant to the other plugins Let me know if it works.

Sam

[refriedjello]

If I try the first way I get this error:

Traceback (most recent call last):
  File "./cmdtemplate.py", line 24, in <module>
    net_connect.send_command('edit myvdom')
  File "/usr/local/lib/python3.6/site-packages/netmiko/utilities.py", line 429, in wrapper_decorator
    return func(self, *args, **kwargs)
  File "/usr/local/lib/python3.6/site-packages/netmiko/base_connection.py", line 1525, in send_command
    search_pattern
OSError: Search pattern never detected in send_command: firewall01.company.com\ \(vdom\)\ \#

Trying the second way, sending a config_command, I get this error:

Traceback (most recent call last):
  File "./cmdtemplate.py", line 19, in <module>
    net_connect.send_config_set(config_commands=[" edit myvdom"])
  File "/usr/local/lib/python3.6/site-packages/netmiko/base_connection.py", line 1872, in send_config_set
    output += self.exit_config_mode()
  File "/usr/local/lib/python3.6/site-packages/netmiko/fortinet/fortinet_ssh.py", line 122, in exit_config_mode
    return super().exit_config_mode(exit_config=exit_config, pattern=pattern)
  File "/usr/local/lib/python3.6/site-packages/netmiko/cisco_base_connection.py", line 46, in exit_config_mode
    return super().exit_config_mode(exit_config=exit_config, pattern=pattern)
  File "/usr/local/lib/python3.6/site-packages/netmiko/base_connection.py", line 1754, in exit_config_mode
    raise ValueError("Failed to exit configuration mode")
ValueError: Failed to exit configuration mode

Here is my entire script in case its helpful:

#!/usr/bin/env python3
from netmiko import Netmiko
from getpass import getpass
password = getpass()
host = 'firewall01.company.com'
net_connect = Netmiko(host=host, username='admin', password=password, device_type='fortinet')
net_connect.find_prompt()
net_connect.config_mode(config_command='config vdom')
net_connect.send_command('edit myvdom')
get_arp = net_connect.send_command('get system arp')
print(get_arp)

[Trasmontinho]

Ok,

I’ll take a look on it and come to you after testing it from my side. You should have answer to your problem tomorrow. I’ll keep you posted.

[Trasmontinho]

Hi,

So basically, I reproduced your issue regarding the first issue (with the send_command) and know why the second way hasn't worked.

For the first try with the send_command : Basically the fact of typing the command "edit myvdom", will modify your host pattern from firewall01.company.com (vdom)# to firewall01.company.com(myvdom)#.

In the send_command there is a parameter that will permit to workaround this problem which will be something like : net_connect.send_command('edit myvdom',auto_find_prompt=False)

The fact is that I haven't found a fix yet for this under config_mode and I'm not sure that it should be integrated under it. 2 reasons to that :

• The expected config_command is a string and not a list
• Allowing a function to do it under such a function can be risky due to the fact that you may create an unwanted vdom if the name is not defined on the Fortigate. I think that sould be something that should be controlled under a specific method from your dev and not part of something generic (but we can discuss this subject).

The second one with the send_config_set: there was here a mistake in the exit_config_mode method (that I've just updated). where :

    def exit_config_mode(self, exit_config="end", pattern=""):
        """No config mode for Fortinet devices."""
        return super().exit_config_mode(exit_config=exit_config, pattern=pattern)

Modifying it will fix the issue and you will be able to type something like :

liste_c=net_connect.send_config_set(config_commands=["edit DEV, get system arp"])
print(liste_c)

Those commands will give you the output below :

edit DEV
current vf=DEV:11

forti_test  (DEV) # get system arp
Address           Age(min)   Hardware Addr      Interface

forti_test (DEV) # end

forti_test  #

I do not recommend to use it to get output by the way but still usable to push config

Regards,

Sam

[refriedjello]

Thank you for looking deeper into this and all of your replies.

Allowing a function to do it under such a function can be risky due to the fact that you may create an unwanted vdom if the name is not defined on the Fortigate. I think that sould be something that should be controlled under a specific method from your dev and not part of something generic (but we can discuss this subject).

I think ideally there would be a dedicated method for FortiGates like .enter_vdom or something. It would:

• accept as argument name of VDOM to enter
• would run "config vdom" and then "edit ?" and check that VDOM you desire to enter exists first
• error out if VDOM specified does not exist
• if VDOM does exist, then enter that VDOM. e.g, "edit myvdom"

[Trasmontinho]

Yes.

I thought about such a thing this morning and can make the pull request.

@ktbyers could you give us your opinion on it ? Do you think it could be acceptable to you ?

Regards,

Sam

[ktbyers]

@Trasmontinho I will try to look at it this week. Just ping me/message me again on this issue if I don't circle back to it by end of day Sunday.

Regards, Kirk

[refriedjello]

@ktbyers Hi Kirk, I was wondering if there was any update on this request?

[Trasmontinho]

Hi @ktbyers,

I've been quite busy lasts weeks and haven't had time to ping you. Anyway, Have you a chance to give us a feedback on it ? It could be cool to supply the config methods for the global part and for the existing vdoms on a fortinet.

Let me know if I can go on it.

Regards,

Sam

[Trasmontinho]

So basically I've been thinking on it all the afternoon. I Think there are 2 ways that could be done to deliver a config mode for both (global and vdom).

First create a config mode method were the config command will not be delivered by default with a config command with variables like :

• config command (wich choice will be "config global" or "config vdom")
• vdom_name which (which will permit to edit the specific vdom)
• new_vdom (which will be by default to False)

The idea behind that is to have a unique method to enter in config mode where we will be able to create a VDOM if necessary or control the fact that we wouldn't like to do it.

Of course those changes should be integrated in a complementary method "send_config_set" that should integrate some control.

The second option is to create specifc methods (not big fan of that) like

• config_mode_global
• config_mode_vdom

Regards,

Sam

[ktbyers]

Sorry for the delay on this...do you think we could step back for a second and just detail the high-level problems with the current Fortinet driver. Basically detail what doesn't work currenlty including detailing the CLI behavior of those interactions on the Fortinet.

I have created this issue as a placeholder for those discussions:

https://github.com/ktbyers/netmiko/issues/2146

Thanks, Kirk

[Trasmontinho]

@refriedjello could you comment and switch in the issue opened by Kirk regarding the working mode for fortinet without vdom configured ? In my company we haven't such case.

Thanks.

[ktbyers]

I have examples with no vdoms so know what I need are examples with vdoms. See my comments in the other issue.

Kirk

[ktbyers]

@Trasmontinho Is this done and ready to go or still pending testing results?

[Trasmontinho]

Hi @ktbyers,

from my side the code is ok and tested over Fortinet devices. But I'm facing some issues with thetest kitThat I haven't had time to troubleshoot.

[Trasmontinho]

@refriedjello have you made some testing from your side with the last pull request which is aa1dd36? ?

[ktbyers]

Is this PR still worth working on?

[Trasmontinho]

Hi @ktbyers,

I’ve been quite busy with other subjects. I’ll try to focus on the test objects next week.

I’ll keep you posted on it.

Sam

[ktbyers]

Closing as this was superseded by some other work.