Mailing-List: contact dev-help@brooklyn.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@brooklyn.apache.org
MIME-Version: 1.0
In-Reply-To: 
 <CAJT5MU9OeLUuhL_BZL5WgMfOkGmLsVnJwfK9zdYa+KLAZrhN1g@mail.gmail.com>
References: 
 <CAK4K4E8sjCH-NeAU0T6xxVOy8Q9KFAZnOaHnD3dXj7Dw7fo+SQ@mail.gmail.com>
	<56AA42FF.2020902@CloudsoftCorp.com>
	<CAEK0Ph1gv=r=TyELeqZzEbd5V+3KXkc1OaYVabt=wCwGEU4zpw@mail.gmail.com>
	<CAJT5MU8tMhpa2OWOKrjBayKEYDKNJKVntMzvGcf7_ESXm-TuCA@mail.gmail.com>
	<CAK4K4E_BZ5UKHE_RWai5_OX3cKF1MGWd+6UWOWsKLAxZtJPZNg@mail.gmail.com>
	<CAJT5MU9OeLUuhL_BZL5WgMfOkGmLsVnJwfK9zdYa+KLAZrhN1g@mail.gmail.com>
Date: Fri, 29 Jan 2016 18:58:32 +0300
Message-ID: 
 <CAK4K4E_MFxckykf+RPWkvr9YeGU+owPrnOOPHRQfxDZPFKnimw@mail.gmail.com>
Subject: Re: Brooklyn Daemon Solution
From: Aleksandr Vasilev <aleksandr.vasilev@cloudsoftcorp.com>
To: dev@brooklyn.apache.org
Content-Type: multipart/alternative; boundary=001a1130c8a06db9c4052a7b1bb6

--001a1130c8a06db9c4052a7b1bb6
Content-Type: text/plain; charset=UTF-8

> 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
> > > >
> > >
> >
>

--001a1130c8a06db9c4052a7b1bb6--