Be great to have a feature to run commands over WMI / SMB

Uploads hang and never timesout. No file hash checking after upload either

Make windows SMB optional

When using download with storage jimi simply checks that the storage file exists by name and does not check if the given action acl is allowed access

Convert remote download and upload so that it can only use jimi storage - this would prevent the current issue whereby it can write and read from anywhere on the system

When using remoteUpload against one IP multiple times, you will occasionally be faced with:

 "flowData": {
      "action": {
           "action_id": "608821243022b5a73697b831",
           "action_name": "Upload Package",
           "msg": "File transfer failed - [Errno 32] Broken pipe",
           "rc": 403,
           "result": false
      },

A restart of JIMI resolves the issue.

Plugin does not appear to correctly close handles for SMB and as a result every so often it reports a connection error as the max handle count is exceeded.

Once you have connected or tried to connect a number of times the system no longer permits connections

Using a jimi remote upload if the remote directory path does not exist jimi does not upload the file and returns false. The issue is that no error messages or exit codes tell you that this is the issue.

Within the linux connector it is hard coded to 5000 seconds this should be changed to 10 seconds and/or made to be optional within the action that connects?

Be great to have a builtin option to ensure the connected host matches what is expected before continuing the flow

The powershell code to run as current user is not working on windows 7

If you attempt to connect to the same host multiple times from different flows you get:

smbprotocol.exceptions.SMBException: Server message signature could not be verified: 1488cc7e507ddbf7ee86c5bbd8c4b883 != 75bfdef70950d50774ceba003bc85c75

Integration with native jimiFlow objects so that flow objects can be run remotely without extra work by a developer.

Each flow only supports a single remote connection, it is not possible to connect to more than one system at a time

When using multicommand when you get errors it says they are ok anyway?

               "commands": [
                    {
                         "command": "apt-get update",
                         "data": "Reading package lists...\n",
                         "errors": [
                              "E: Could not get lock /var/lib/apt/lists/lock. It is held by process 1374 (apt-get)\n",
                              "E: Unable to lock directory /var/lib/apt/lists/\n"
                         ],
                         "msg": "Command succesfull",
                         "rc": 100,
                         "result": true
                    },
                    {
                         "command": "apt-get dist-upgrade -y",
                         "data": "",
                         "errors": [
                              "E: Could not get lock /var/lib/dpkg/lock-frontend. It is held by process 1219 (apt-get)\n",
                              "E: Unable to acquire the dpkg frontend lock (/var/lib/dpkg/lock-frontend), is another process using it?\n"
                         ],
                         "msg": "Command succesfull",
                         "rc": 100,
                         "result": true
                    }
               ],
               "errors": "",
               "msg": "All commands ran",
               "rc": 0,
               "result": true

I had experienced an issue whereby debugging a Test Fire Trigger resulted in it being triggered 4 times.

Unknown why it ran 4 times as the number 4 does not reflect number of events, foreachs etc.

I have a use case where I need to rapidly deploy/automate the installation of software for many users. The remote upload command is fine for uploading small software packages but at a large scale this will cause a bottleneck on upload bandwidth.

Adding the ability to have JIMI tell the client to download the software package from JIMI itself over HTTP/S will make this more efficient and usable at a large scale. The current workaround is to send a remote command to the client to do the following:

powershell -noprofile -executionpolicy bypass -command "Invoke-WebRequest -Uri 'http://server.net/Software/Setup.zip' -OutFile 'C:\Windows\Temp\Setup.zip'"

However, it makes more sense to be able to do this all within a plugin that tells the client to download from JIMI itself. This will help complete the functionality of using JIMI to push out the installation of software at scale.

Thanks,
Danny

On every connect, turn off paging by running the command: "terminal monitor 0"

This is a per session command and will remove the requirement of handling the "more" prompt.

As per below, the fix is to add the timeout=None to the command function:

    def command(self, command, args=[], elevate=False, runAs=None):
        self.channel.send("{0}{1}".format(command,"\n"))
        return (0, self.recv(), "")

to

    def command(self, command, args=[], elevate=False, runAs=None, timeout=None):
        self.channel.send("{0}{1}".format(command,"\n"))
        return (0, self.recv(), "")

Reboot and wait for the system to restart before continuing

When running remote in jimi with concurrency actions hang on start, never end and then the trigger notify completes.