brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aleksandr Vasilev <aleksandr.vasi...@cloudsoftcorp.com>
Subject Re: Brooklyn Daemon Solution
Date Fri, 29 Jan 2016 17:57:49 GMT
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.heneveld@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 <john@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.vasilev@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 <john@johnmccabe.net> wrote:
>>>>
>>>> [bumping so aleks can see the thread]
>>>>>
>>>>> On Thu, 28 Jan 2016 at 16:41 Andrew Kennedy <
>>>>> andrew.kennedy@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.heneveld@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
>>>>>>
>>>>>>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message