This seems dangerous to me as a client could send malicious code for execution to all servers. Geode requires an administrative step to do gfsh> deploy --jar=..., that provides a control step that theoretically should check a malicious client.
As for third-party jars, they do the same as what we're discussing: > "Our suggestion is to include all 3rd party libraries into class path of > every node. This can be achieved by copying your JAR files into the Ignite > libs folder." As for the dynamical loading and running of Spring jars, let's say that timeline pressures and money outweigh a small, temporary network saturation as we distribute Spring jars to the nodes. We then get to the dynamic loading: If class is not locally available, then a request will be sent to the > originating node to provide class definition. Originating node will send > class byte-code definition and the class will be loaded on the worker node. > This happens only once per class - once class definition is loaded on a > node, it will never have to be loaded again. I think it's practical. However, iIsn't this potentially dangerous as a client could intentionally inject malicious code into the grid? Whereas gfsh> deploy --jar=... gives Operations a control check point that theoretically can thwart such an attack. *Wes Williams | Pivotal Advisory **Data Engineer* 781.606.0325 http://pivotal.io/big-data/pivotal-gemfire On Fri, Jan 6, 2017 at 8:46 PM, Roman Shaposhnik <ro...@shaposhnik.org> wrote: > Btw, I'm sure a comparison of capabilities with Ignite will come up at > some point. So here's what > they do in this department (which I personally find really cool): > http://apacheignite.gridgain.org/v1.0/docs/zero-deployment > > Thanks, > Roman. > > On Fri, Jan 6, 2017 at 12:11 PM, Anthony Baker <aba...@pivotal.io> wrote: > > Hmmm, I agree with Udo. I’d like to push a new version of my > application with a single idempotent command. The server should be smart > enough to figure out what's in my bundle and understand how to deploy it > including any dependencies (because who writes dependency-free code?). > > > > I do want some lifecycle hooks to alloc/free resources. This seems > conceptually similar to the “war” model which is pretty familiar to most > Java devs. > > > > Anthony > > > >> On Jan 6, 2017, at 11:37 AM, Udo Kohlmeyer <ukohlme...@pivotal.io> > wrote: > >> > >> In some ways that is a great idea.... but sometimes too explicit... Do > we expect them to have fine grained jars? > >> Also how do we handle dependencies.... as a single util class might be > used by both a cache-listener and a partition listener... is the > expectation that we update the dependent util class for one but not the > other.... > >> > >> It's a very grey area.... > >> > >> On 1/6/17 11:19, John Blum wrote: > >>> How about... > >>> > >>> * deploy function > >>> * deploy cache-listener > >>> * deploy cache-loader > >>> * deploy cache-loader > >>> * deploy resource (jar, xml, properties, etc) > >>> * etc. > >>> > >>> Might as was make it explicit. For instance, I may have a JAR file I > just > >>> deployed (uploaded) that contains Functions, Listeners, Loaders, > Writers, > >>> etc but I only want to deploy functions. > >>> > >>> Having 1 uber "deploy" command with many options gets cumbersome. > >>> > >>> It is a simple matter to introduce multiple command but have those > commands > >>> share similar logic. This would also enable different workflows for > >>> different commands in a more non-convoluted, maintainable way. > >>> > >>> These could be matched with corresponding `undeploy` commands. > >>> > >>> Food for thought, > >>> > >>> John > >>> > >>> > >>> > >>> On Fri, Jan 6, 2017 at 11:11 AM, Kirk Lund <kl...@apache.org> wrote: > >>> > >>>> With appropriate constraints, a copy file type command could be > secure. > >>>> > >>>> 1) don't use Apache Geode without security AND make the command > require > >>>> authorization permissions > >>>> 2) limit the target directory to a directory under the working > directory of > >>>> the remote server > >>>> 3) rename it to "deploy resource" so people don't expect it to copy > to an > >>>> arbitrary target directory on the remote machine > >>>> > >>>> Back to "deploy jar": > >>>> > >>>> The deploy command is only for deploying Apache Geode callbacks > (Function, > >>>> CacheListener, etc). "deploy resource" such Spring jars or Spring xml > files > >>>> or anything similar does not overlap with "deploy jar". There is > continued > >>>> confusion over what "deploy jar" is or does. I propose we rename it to > >>>> "deploy functions" or "deploy callbacks" or something along those > lines to > >>>> end the confusion. > >>>> > >>>> On Fri, Jan 6, 2017 at 8:13 AM, Michael Stolz <mst...@pivotal.io> > wrote: > >>>> > >>>>> So maybe a generic copy command is too insecure, I agree. > >>>>> What we should do is think about exactly what files we think we are > >>>> trying > >>>>> to deploy. > >>>>> > >>>>> 1. I believe that there is a need to deploy dependency jars into > the > >>>>> system classpath. > >>>>> 2. I believe that there is also a desire to be able to deploy > Spring > >>>>> Data Geode xml configuration files. > >>>>> 3. There is also an issue with attempting to deploy Spring Data > Geode > >>>>> functions that we should try to work out. > >>>>> > >>>>> Anything else that anyone is aware of? > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> -- > >>>>> Mike Stolz > >>>>> Principal Engineer, GemFire Product Manager > >>>>> Mobile: 631-835-4771 > >>>>> > >>>>> On Fri, Jan 6, 2017 at 10:59 AM, Jacob Barrett <jbarr...@pivotal.io> > >>>>> wrote: > >>>>> > >>>>>> Agree with Anthony. A copy command would either duplicate what > deploy > >>>>> does > >>>>>> by only putting files within as specific location in the server's > >>>>> directory > >>>>>> or creating a security nightmare if allowed to write anywhere on the > >>>>> host. > >>>>>> > >>>>>> On Fri, Jan 6, 2017 at 7:56 AM Anthony Baker <aba...@pivotal.io> > >>>> wrote: > >>>>>>> I think there are lots of great OS orchestration and automation > >>>> tools. > >>>>>>> I’m not sure I understand the need for `gfsh cp`. If I could > easily > >>>>> grab > >>>>>>> the member hostnames from `gfsh list members` and pipe them into > >>>> mpssh > >>>>>> (for > >>>>>>> example) that would do the job. > >>>>>>> > >>>>>>> I *do* like the idea of an improved `gfsh deploy` that supports hot > >>>>>> deploy > >>>>>>> and reconfiguration. > >>>>>>> > >>>>>>> Anthony > >>>>>>> > >>>>>>>> On Jan 6, 2017, at 2:38 AM, Swapnil Bawaskar < > sbawas...@pivotal.io > >>>>>>> wrote: > >>>>>>>> Some application may need to copy files to all the servers. These > >>>>> files > >>>>>>>> could either be data files or they could be configuration files > >>>>> needed > >>>>>> by > >>>>>>>> the application or they could be jar files (that don't have > >>>> functions > >>>>>> but > >>>>>>>> have say, spring data geode jar files) that need to be on the > >>>>> server's > >>>>>>>> classpath. > >>>>>>>> We could accomplish this by enhancing the current gfsh "deploy" > >>>>> command > >>>>>>> to > >>>>>>>> accept any kind of file and write it to the servers file system OR > >>>>>>> create a > >>>>>>>> new gfsh "copy" command to copy any arbitrary file to the servers. > >>>>>>>> I would personally like to repurpose the deploy command but would > >>>>> like > >>>>>> to > >>>>>>>> hear the community's opinion. > >>>>>>>> > >>>>>>>> Thanks! > >>>>>>> > >>> > >>> > >> > > >
