Add capability to run script before project load and also on project close.

[ak2766]

Is your feature request related to a problem? Please describe. I normally make use of tap interfaces to connect my simulation environment to my laptop/internet. To this end, I normally have a bash script that I run - tapsup - which sets up all the taps I'll need as well as adding the needed firewall rules. Also, when I'm done, I normally run another script (well, really the same script) that tears down those taps interface - downtaps - that clears up the firewall and brings the interfaces down.

Describe the solution you'd like It would be mighty fine to have ExecStartPre and ExecStopPost entries (or better terms than I can think up right now - I just copied from systemd) associated with a Project where one can add scripts to be executed - either relative to working directory or full path to script.

Describe alternatives you've considered My alternative right now is to remember to run the script - there's no way around it.

[andrei-korshikov]

Do you use different configuration of tap interfaces for different projects? I mean, if configuration of laptop interfaces for all your projects is the same, may be it is easier to just start GNS3 from script? So script will configure the interface(s), then it'll run GNS3, and finally it'll revert changes. By the way, it would be nice to have command line argument to open a project;)

[josephmhiggins]

A serious GNS3 must run a script to 1) start gns3 2) close it down in a normal fashion.

A serious GNS3 user can/should kill gns3 via another script or manually. If a serious GNS3 user has to kill GNS3, then the GNS3 user is bound to act on the reason for killing GNS3.

The reasons why a serious GNS3 must run a script to start GNS3 is that: 1) the gns3 developers messed up the "gns configuration files" for "all" Windows users when they upgraded to GNS3 2.2 to GNS3 2.2.4 approximately. This caused all Windows users making the upgrade from gns3 2.1.21 to 2.2. < gns3version < 2.2.4 to have all their images and, consequently, all of their projects to be wiped out, unless they had a backup of their GNS3 configuration files 2) the gns3 developers have chose to overwrite the gns3 log files when gns3 starts up. Consequently, a gns3 user that does not save the log files before gns3 start up, then loses all the gns3 log files. I have looked at this decision by the GNS3 developers to wipe out the old log files. It is a legitimate design and a totally "legal" one. The log files are 'debug' level logs and not 'critical', 'notice', or 'informational'. So the fact that they are 'debug' level logs gives them legitimacy to wipe out the files.

The reasons why a serious GNS3 must run a script to stop GNS3 is that: 1) You have a working GNS3, you need to save the configuration files because the gns3 developers can break GNS3 when they are closing it down; the GNS3 developers are not to be trused, and 2) When you gns3 I close down smoothly, I can do anything after it closes it down. I can wipe out anything by grabbing the wrong keyboard and hitting the delete button while looking at one monitor, but the other monitor shows that some GNS3 stuff is selected and the keyboard in my hands is controlling the monitor with the GNS3 stuff selected. I can wipe out anything. That sucks; but I have done it. I will probably need to adjust my technique on that and only use 1 keyboard, rather than pick up the GNS3 keyboard and literally carry into another room - I have done that many times.

The GNS3 developers get a pass on all of that.

But ak2766, now that you are aware of the need to run a script, you get no pass. You should save/archive the log files ina place of your choosing and the GNS3 developer should not be finding an archive location for your stuff.

The GNS3 developers could, for Windows users, open a connection to the Windows Event Logs and store their logs there. But "no" Windows user knows how to read the event logs. And I do not want that stuff in there anyway.

..sorry I had to edit ...i put some VBA code in the post by accident.

[josephmhiggins]

Presently, my powershell script only archives the before and after gns3 because: 1) I did know how to get the Process ID of gns3 when I start it. It was too difficult for me to figure out when I wrote the script. It is not so easy to understand the parameters of Start-Process in powershell 2) I only discovered 6 months ago that I needed to save everything before I close GNS3. But, I do not remember why I needed that. But I explained it in a post 3 - 6 months ago on the GNS3 community board.

So, you need a script to handle all 3 situations, excluding everything Andrei brought up. But before you deal with Andrei's perspective, you still should create a script to start GNS3 everytime. It is a real pain for Windows users to start GNS3 from a shell because "all" Windows users never a shell, unless it is DOS.

That's just the way it is. You must remember to start GNS3 from a script; the gns3 developers are not to be trusted, and if you have 2 keyboards, then you should not trust yourself.

[lurendrejer]

This ability would be a nightmare in a hosted/shared environment.

Both windows and linux supports running both pre and post commands when starting a service and using powershell to launch gns3, wait for it to close and then do something is easy. Giving users access to running scripts would make my life a living hell - since GNS3 runs (more or less) as root on a shared system.

[josephmhiggins]

"using powershell to launch gns3, wait for it to close and then do something is easy." - not so easy for me. It took me 40 hours to do it AND it gets worse. Windows 10 Users using VMware Workstation Pro need the script to encompass disabling and reenabling the vmnet interfaces. Disabling and reenabling the vmnet interfaces requires Powershell to be run in administrative mode. I do not run GNS3 in administrative mode because the GNS3 developers designed it not to be run in administrative mode. So, i would have to start pwoershell in administrative mode and then have that open up powershell in regular mode and have it run the script to start gns3. I do not know how to do that. I am sure I can figure it out in a few hours. I have some powershell books. Hopefully one of them will have it.

[lurendrejer]

Bad wording on my part, sorry. Please forgive me :)

If the script is run on the client, I have no problems with that. Except that an awfull person that hosts gns3 could infect clients very easily.

The ability to execute arbitrary code on a front/backend scenario just has so many problems attached to it.

I don't see how this would change the context of which the script is run - it will run in the context of the client anyway, not solving your problem.

[ak2766]

Do you use different configuration of tap interfaces for different projects?

Yes. Depending on what I'm trying to simulate. Also, some simulations require more tap interfaces than others. So, once I setup the script to launch the appropriate number of taps and configure each one in the appropriate subnet, I'd then visit "My proposed project config page" and add the tapsup script to the project pre open section and the downtaps script to the project post close section.

I see this has opened up a debate - not my intention. I'm just looking for a way to make my life easier using GNS3.

EDIT: I thought I'd mention my environment to remove any ambiguity. I'm running locally built GNS3 on Ubuntu desktop.