Alex, In this case, I agree that wrapping java command in a service script may be the best choice.
Best Regards, Aleksandr Vasilev DevOps Engineer | Cloudsoft Corporation On 29 January 2016 at 20:50, Alex Heneveld <alex.henev...@cloudsoftcorp.com> wrote: > > Aleksandr, > > Is there anyone who needs this level of security? In my experience a > service calling a shell script is common, and in the cases where someone > needs something stronger they can build it. They possibly have custom > requirements there in any case. Bear in mind a daemon is going to > introduce a lot of complexity (many different OS's) so it would need to > offer major benefits to users or it's just not worth it, in my view. > > OTOH hopefully this is being considered as part of putting together RPM's > and DEB's and Docker images, as part of the Brooklyn build. In which case > the sooner we have that the better, because people do want those. Even > installing as a service I think is optional. > > FWIW Tomcat *suggest* the use of jsvc at [1] but they leave it for users > to implement. In practice I mainly see service scripts calling the > catalina start shell script which uses java -- not jsvc. > > Best > Alex > > [1] https://tomcat.apache.org/tomcat-7.0-doc/setup.html > > > > On 29/01/2016 15:58, Aleksandr Vasilev wrote: > >> Regarding the security implications when using a script vs a binary, >>> >> could you explain? >> It's not the difference between binary vs script, it's the different >> approach at launching the process. In my daemon I make sure child process >> is detached from the parent and can't get hold of any terminal sessions, >> so >> an attacker can't get any additional privileges. >> >> with file descriptor redirection, beyond stderr, stdout what are you >>> considering >>> >> here? >> Nothing more unless any other file descriptors are opened by Brooklyn. The >> daemon makes sure to close them all. >> >> are you intending this to be used outside of init? we'd have the config >>> >> set externally to the daemon >> Not at all, just suggesting it can be used in any type of service script >> >> we don't have to wrap a script surely? the init script doesn't have to >>> >> call the brooklyn script. >> Agreed, we can wrap java command, calling Brooklyn's Main class. Again I'm >> not sure this solution detaches the child process properly. >> >> >> Best Regards, >> Aleksandr Vasilev >> DevOps Engineer | Cloudsoft Corporation >> >> >> On 29 January 2016 at 18:45, John McCabe <j...@johnmccabe.net> wrote: >> >> Hi Aleksandr, >>> >>> 1. Proper detaching from the parent process, making daemon more secure >>>> 2. Proper detaching from any TTYs, making daemon even more secure >>>> >>> Regarding the security implications when using a script vs a binary, >>> could >>> you explain? >>> >>> 3. Proper redirection of all file descriptors, helps with debugging and >>>> logging >>>> >>> with file descriptor redirection, beyond stderr, stdout what are you >>> considering here? >>> >>> 5. More flexible solution: ability to run Brooklyn with any arguments, >>>> service script will have "brooklyn launch" part hardcoded and will >>>> >>> require >>> >>>> to edit the code each time you need to run it with the new args. >>>> >>> are you intending this to be used outside of init? we'd have the config >>> set >>> externally to the daemon >>> >>> Overall I see the native daemon solution as more traditional and >>>> >>> compliant >>> >>>> to Linux standards than just wrapping bash script in yet another script. >>>> >>> we don't have to wrap a script surely? the init script doesn't have to >>> call >>> the brooklyn script. >>> >>> All the best, >>> John >>> >>> On Fri, Jan 29, 2016 at 2:58 PM, Aleksandr Vasilev < >>> aleksandr.vasi...@cloudsoftcorp.com> wrote: >>> >>> Hi Alex, >>>> >>>> The advantages of having a native daemon in my opinion are: >>>> 1. Proper detaching from the parent process, making daemon more secure >>>> 2. Proper detaching from any TTYs, making daemon even more secure >>>> 3. Proper redirection of all file descriptors, helps with debugging and >>>> logging >>>> 4. More portable solution, as the daemon can be used in any type of >>>> >>> service >>> >>>> scripts or even on its own, not only systemd script >>>> 5. More flexible solution: ability to run Brooklyn with any arguments, >>>> service script will have "brooklyn launch" part hardcoded and will >>>> >>> require >>> >>>> to edit the code each time you need to run it with the new args. >>>> >>>> Overall I see the native daemon solution as more traditional and >>>> >>> compliant >>> >>>> to Linux standards than just wrapping bash script in yet another script. >>>> >>>> Best Regards, >>>> Aleksandr Vasilev >>>> DevOps Engineer | Cloudsoft Corporation >>>> >>>> On 29 January 2016 at 17:30, John McCabe <j...@johnmccabe.net> wrote: >>>> >>>> [bumping so aleks can see the thread] >>>>> >>>>> On Thu, 28 Jan 2016 at 16:41 Andrew Kennedy < >>>>> andrew.kenn...@cloudsoftcorp.com> wrote: >>>>> >>>>> Or what about running a Brooklyn Docker image as a systemd service! >>>>>> >>>>>> - >>>>>> >>>>> http://container-solutions.com/running-docker-containers-with-systemd/ >>>> >>>>> - https://github.com/ibuildthecloud/systemd-docker >>>>>> >>>>>> Andrew. >>>>>> >>>>>> On Thu, 28 Jan 2016 at 16:34 Alex Heneveld < >>>>>> alex.henev...@cloudsoftcorp.com> >>>>>> wrote: >>>>>> >>>>>> Hi Aleksandr- >>>>>>> >>>>>>> What's the advantage of a native daemon over just wrapping it as a >>>>>>> >>>>>> linux >>>>> >>>>>> service script ? >>>>>>> >>>>>>> Best >>>>>>> Alex >>>>>>> >>>>>>> >>>>>>> On 28/01/2016 11:32, Aleksandr Vasilev wrote: >>>>>>> >>>>>>>> Hello everyone! >>>>>>>> >>>>>>>> I spent last few days looking at the solution to run Brooklyn >>>>>>>> >>>>>>> process >>>> >>>>> as >>>>>> >>>>>>> a >>>>>>> >>>>>>>> daemon and found two options: >>>>>>>> 1. Run daemon via Apache Commons Daemon (jsvc) >>>>>>>> 2. Write a custom daemon in C >>>>>>>> >>>>>>>> Both solutions has its own pros and cons, so let's look at what I >>>>>>>> >>>>>>> think >>>>> >>>>>> they are: >>>>>>>> >>>>>>>> JSVC: >>>>>>>> Pros: >>>>>>>> - Ready to use solution. Running a daemon via jsvc is very >>>>>>>> >>>>>>> similar >>> >>>> to >>>> >>>>> running java application from the command line with similar >>>>>>>> >>>>>>> arguments >>>> >>>>> passed. >>>>>>>> - Builds as usual in Maven >>>>>>>> >>>>>>>> Cons: >>>>>>>> - Still requires you to write daemon code, which in my opinion >>>>>>>> >>>>>>> kills >>>> >>>>> the >>>>>> >>>>>>> out-of-the-box usability >>>>>>>> - Has tons of bugs, including: not been able to find classes in >>>>>>>> >>>>>>> classpath, >>>>>>> >>>>>>>> not been able to run by non-root users, not been able to run on >>>>>>>> >>>>>>> several >>>>> >>>>>> *nix systems (Mac OS, BSD) >>>>>>>> - The codebase hasn't changed since 2013 and seems abandoned >>>>>>>> - SVN repo often isn't accessible for some reason, right now the >>>>>>>> >>>>>>> webserver >>>>>>> >>>>>>>> returns 503 error code: >>>>>>>> http://svn.apache.org/viewvc/commons/proper/daemon/trunk/ >>>>>>>> >>>>>>>> Custom Daemon (written in C): >>>>>>>> Pros: >>>>>>>> - Cross-platform, runs on any *nix system supported by Brooklyn >>>>>>>> - Very little code to maintain >>>>>>>> - Independent from third-party solutions, requires only gcc to >>>>>>>> >>>>>>> build >>>> >>>>> - Easy to make LSB-compliant init scripts to control the daemon >>>>>>>> >>>>>>>> Cons: >>>>>>>> - Requires some overhead to build C code in Maven >>>>>>>> >>>>>>>> Having all these options considered, I propose writing daemon for >>>>>>>> >>>>>>> Apache >>>>>> >>>>>>> Brooklyn in C language and use gcc compiler to build it. It will >>>>>>>> >>>>>>> require >>>>>> >>>>>>> introducing some changes to Maven build process, but there are >>>>>>>> >>>>>>> plenty >>>> >>>>> of >>>>>> >>>>>>> solutions for doing this, such as Maven NAR plugin, which is >>>>>>>> >>>>>>> actively >>>> >>>>> maintained: >>>>>>>> https://github.com/maven-nar/nar-maven-plugin >>>>>>>> >>>>>>>> Best Regards, >>>>>>>> Aleksandr Vasilev >>>>>>>> DevOps Engineer | Cloudsoft Corporation >>>>>>>> >>>>>>>> -- >>>>>>> >>>>>> Andrew Kennedy ; Founder clocker.io project ; @grkvlt ; Cloudsoft >>>>>> >>>>>> >
