Sure Joe. I will create Jira tickets for those processors . I am also working on to move groovy lib dependency to parent nar level to keep processor nars sleek. Sumo
Sent from my iPhone > On Nov 30, 2015, at 7:25 AM, Joe Percivall <joeperciv...@yahoo.com.INVALID> > wrote: > > Hey Sumo, > > I don't know much about this use-case but just taking a quick look the > processors in that github repo they seem to be potentially a great addition > to NiFi! > > I think you should consider creating a Jira and working this there. It would > a lot easier to get feedback and have a record of it on Jira than just on the > Dev list. > > Joe > - - - - - - > Joseph Percivall > linkedin.com/in/Percivall > e: joeperciv...@yahoo.com > > > > > On Wednesday, November 25, 2015 2:12 PM, Sumanth Chinthagunta > <xmlk...@gmail.com> wrote: > I have first-cut implementation of ExecuteRemoteProcess processor at: > > https://github.com/xmlking/nifi-scripting/releases > <https://github.com/xmlking/nifi-scripting/releases> > > I tried to provide all capabilities offed by groovy-ssh > (https://gradle-ssh-plugin.github.io/docs/ > <https://gradle-ssh-plugin.github.io/docs/>) to ExecuteRemoteProcess user. > it takes three attributes: > 1. SSH Config DSL (run once on OnScheduled) > remotes { > web01 { > role 'masterNode' > host = '192.168.1.5' > user = 'sumo' > password = ‘fake' > knownHosts = allowAnyHosts > } > web02 { > host = '192.168.1.5' > user = 'sumo' > knownHosts = allowAnyHosts > } > } > 2. Run DSL ( run on each onTrigger) > ssh.run { > session(ssh.remotes.web01) { > result = execute 'uname -a' > } > } > 3. User supplied Arguments which will be available in Run DSL > > anything that is assigned to ‘result’ in RunDSL is passed as flowfile to > success relationship. > > Any suggestions for improvements are welcome. > > -Sumo > > >> On Nov 24, 2015, at 8:19 PM, Adam Taft <a...@adamtaft.com> wrote: >> >> Sumo, >> >> On Tue, Nov 24, 2015 at 10:27 PM, Sumanth Chinthagunta <xmlk...@gmail.com> >> wrote: >> >>> I think you guys may have configured password less login for SSH (keys?) >>> >> >> Correct. I'm using SSH key exchange for authentication. It's usually >> done password-less, true, but it doesn't necessarily have to be (if using >> ssh-agent). >> >> >> >> >>> In my case the edge node is managed by different team and they don’t >>> allow me to add my SSH key. >>> >> >> Yikes. Someone should teach them the benefits of ssh keys! :) >> >> >> >>> I am thinking we need ExecuteRemoteCommand processor (based on >>> https://github.com/int128/groovy-ssh) that will take care of key or >>> password base SSH login. >>> >> >> +1 - this would be a pretty nice contribution. Recommend building the >> processor and then posting here for review. I'm sure this would be a useful >> processor for many people. >> >> >> ExecuteRemoteCommand should have configurable attributes and return command >>> output as flowfile >>> >>> host : Hostname or IP address. >>> port : Port. Defaults to 22. >>> user : User name. >>> password: A password for password authentication. >>> identity : A private key file for public-key authentication. >>> execute - Execute a command. >>> executeBackground - Execute a command in background. >>> executeSudo - Execute a command with sudo support. >>> shell - Execute a shell. >>> >>> >> As we do for SSL contexts, it might make sense to bury some of these >> properties in an SSH key controller service. I'm thinking username, >> password, identity might make sense to have configured externally as a >> service so they could be reused by multiple processors. Unsure though, >> there might not be enough re-usability to really get the benefit. >> >> Also, I'm thinking that the "background", "sudo" and "shell" options should >> possibly be a multi-valued option of the processor, not separate >> properties, and definitely not separate "commands." i.e. I'd probably >> recommend property configuration similar to ExecuteCommand, with options >> for specifying the background, sudo, shell preference. >> >> Good idea, I hope this works out. >> >> Adam
