Re: Brooklyn Daemon Solution

Fri, 29 Jan 2016 09:52:13 -0800 


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 <[email protected]> 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 <
[email protected]> 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 <[email protected]> wrote:


[bumping so aleks can see the thread]

On Thu, 28 Jan 2016 at 16:41 Andrew Kennedy <
[email protected]> 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 <
[email protected]>
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

Reply via email to