[wildfly-dev] Embedding a WF instance in the CLI

Brian Stansberry brian.stansberry at redhat.com
Wed Feb 11 11:11:07 EST 2015 

Agreed. OK, I won't worry about this; thanks.

On 2/11/15 8:47 AM, Darran Lofthouse wrote:
> TBH that sounds correct, if a user should not have super user access
> they should not have read/write access to the server configuration
> anyway and to run the server they have that access.
>
> IMO embedded in CLI is just an alternative way to edit the config file
> and editing that config directly is super user access.
>
> The $local authentication mechanism can still be configured with
> appropriate file system permissions so that other users on the same
> machine can auth locally with reduced permissions but for that to be
> effective those users should not have read/write access to the actual
> config.
>
> Regards,
> Darran Lofthouse.
>
>
> On 10/02/15 21:22, Brian Stansberry wrote:
>> One other issue I forgot to mention: security
>>
>> A user running the CLI this way essentially has RBAC SuperUser rights.
>>
>> To use this, the user would have to have access to the local system,
>> with necessary read/write filesystem permissions. Such a user would have
>> other means to mess with the server config, but still, this is another.
>>
>> This is somewhat like the case with $local authentication. But with
>> that, the user organization can modify the config and turn of that
>> authentication mechanism. Perhaps we can do something similar here; e.g.
>> an "embeddable" setting in the config, which if false will cause boot
>> abort in an embedded server.
>>
>> On 2/10/15 3:12 PM, Brian Stansberry wrote:
>>> I had some time over the holidays and on planes to progress quite a bit
>>> on this. A standalone server protype is at [1]. A fairly in depth
>>> description is on the WildFly Development wiki at [2].
>>>
>>> I tried pretty hard to have clean commits on that branch, one per issue
>>> I faced. So looking at the commits is worthwhile to get a better
>>> understanding of particular aspects.
>>>
>>> Some notes on what I did / issues to discuss:
>>>
>>> 1) I semi-ported the "embedded" module from WildFly full to WildFly
>>> Core. "Semi" in the sense that the code is now in both places, under
>>> different maven GAVs and ending up in differently named modules in full.
>>> We need to regularize this; decide if there's any point in a "full"
>>> version of embedded, decide what to do about any APIs we don't want in
>>> the core version. (There are some deprecated methods, and one method
>>> "Context getContext()" that doesn't mean much in core, which has no
>>> JNDI.)
>>>
>>> 2) The CLI's use of stdio needed to be tweaked a bit to make it possible
>>> to control what the embedded server does with stdout. That's in the
>>> "Remove direct use of System.out by most CLI code" commit at [1].
>>>
>>> 3) I needed to deal with some general embedding issues in the server;
>>> i.e. things that would probably pop up in any embedded use case:
>>>
>>> a) controlling the LogContext so the embedded server logging can be
>>> managed independent of the embedding app. See "Let apps that embed
>>> WildFly control the LogContext" commit at [1].
>>>
>>> I don't think this is real solid though. For example, I expect CLI-side
>>> loggers that happen to get created after the embedded server starts will
>>> end up using the server LogContext.
>>>
>>> b) the server was calling System.exit in some places. See "[WFCORE-528]
>>> Use SystemExiter, not System.exit" commit at [1].
>>>
>>> c) the embedded server code didn't deal with reload, leaving behind a
>>> broken ModelControllerClient. See "[WFCORE-511] Support reload in the
>>> embedded server" commit at [1].
>>>
>>> 4) The modular vs non-modular environment aspects discussed at "Modular
>>> vs Non-Modular Classloading and JBOSS_HOME" in [2] are not ideal. I'm
>>> not sure how far we can/should go in improving this though.
>>>
>>> 5) This is painfully lacking in tests!
>>>
>>> Comments and suggestions are welcome!
>>>
>>> Cheers,
>>> Brian
>>>
>>> [1] https://github.com/bstansberry/wildfly-core/commits/cli-embed-server
>>>
>>> [2] https://developer.jboss.org/docs/DOC-53050
>>>
>>> On 5/14/14 9:53 AM, John Mazzitelli wrote:
>>>> How topical :) The RHQ installer could use this - just this very
>>>> second I'm debugging and trying to figure out why the RHQ installer
>>>> can't connect to the running app server instance to do its initial
>>>> config setup - having to try to figure out what port its running on
>>>> and why I can't connect is a pain.
>>>>
>>>> ----- Original Message -----
>>>>> Moving a thread to the dev list.
>>>>>
>>>>> This is about some prototyping I've been doing on weekends 'cause I'm
>>>>> bored with my regular tasks. I've been playing with direct local
>>>>> administration of a WF installation via the CLI without requiring a
>>>>> socket-based connection. The general use case is initial setup type
>>>>> activities where the user doesn't want to have to launch a WF
>>>>> server or
>>>>> HC process and potentially have it be visible on the network.
>>>>> https://issues.jboss.org/browse/WFLY-3288 is one use case; another
>>>>> is a
>>>>> desire some folks have expressed in being able to do configuration
>>>>> without first having to edit any xml to avoid port conflicts on
>>>>> 9990 or
>>>>> 9999.
>>>>>
>>>>> This isn't a major initiative or big priority or anything at this
>>>>> point.
>>>>> Just something I find interesting and perhaps you will too.
>>>>>
>>>>> On 5/14/14, 8:54 AM, Alexey Loubyansky wrote:
>>>>>> Neat :) Yes, figuring out the module path is biting everywhere.
>>>>>> For file system path command line arguments there is a specialized
>>>>>> FileSystemPathArgument.
>>>>>>
>>>>>
>>>>> Thanks; I'll switch to that.
>>>>>
>>>>>>
>>>>>> On 05/13/2014 10:54 PM, Brian Stansberry wrote:
>>>>>>> Copying Heiko Braun as he expressed some interest in the topic.
>>>>>>>
>>>>>>> BTW, I played with this a bit more last weekend and was able to
>>>>>>> start an
>>>>>>> embedded server inside the CLI easily enough. See [1] for very raw
>>>>>>> prototype stuff. You can run bin/jboss-cli.sh (no -c) and then
>>>>>>>
>>>>>>> [disconnected/] embed-server
>>>>>>>
>>>>>>> There are a couple issues I see, besides the HC stuff I mentioned
>>>>>>> in my
>>>>>>> last message.
>>>>>>>
>>>>>>> 1) If the CLI is started in a non-modular environment via java -jar
>>>>>>> bin/client/jboss-cli-client.jar, we'd have to shade jboss-modules
>>>>>>> into
>>>>>>> the jar. And then the embed-server command would need params
>>>>>>> specifying
>>>>>>> the location of JBOSS_HOME, possibly module path etc. But it could
>>>>>>> embed
>>>>>>> a server installed in any accessible filesystem location.
>>>>>>>
>>>>>>> But what I did at [1] is based on bin/jboss-cli.sh, where the CLI is
>>>>>>> running from a WF dist in a modular environment and the embedded
>>>>>>> server
>>>>>>> modules are coming from the CLI's own module path. It would be more
>>>>>>> effort to support embedding a server based on some other module
>>>>>>> path.
>>>>>>> Maybe it's no big deal; maybe it's really hard. :)
>>>>>>>
>>>>>>> 2) The console logging from the embedded server goes to stdout
>>>>>>> mixed in
>>>>>>> with the CLI output. Maybe that's good, maybe it's bad.
>>>>>>>
>>>>>>> [1] https://github.com/bstansberry/wildfly/tree/cli-embed
>>>>>>>
>>>>>>> On 4/28/14, 10:04 AM, Brian Stansberry wrote:
>>>>>>>> I was poking around at this for an hour or so over the weekend.
>>>>>>>>
>>>>>>>> The standalone case seems pretty straightforward. Seems the
>>>>>>>> existing
>>>>>>>> embedded server API could work readily enough. The
>>>>>>>> org.jboss.as.embedded.StandaloneServer interface already provides a
>>>>>>>> ModelControllerClient.
>>>>>>>>
>>>>>>>> The domain case is much harder, as the CLI wants a HostController,
>>>>>>>> not a
>>>>>>>> ProcessController. I'd really like this to use an in-VM client,
>>>>>>>> not a
>>>>>>>> remote one, so I don't like having the CLI embed a PC and then the
>>>>>>>> HC is
>>>>>>>> an external process. My thoughts of the morning are to allow
>>>>>>>> inverting
>>>>>>>> the HC/PC relationship for this kind of usage. That is, remove
>>>>>>>> controlling the HC lifecycle from the charge of the PC component.
>>>>>>>> CLI
>>>>>>>> launches HC, and then the HC creates an in-process PC-ish
>>>>>>>> component (not
>>>>>>>> a separate process) to manage the server lifecycles. There could
>>>>>>>> be all
>>>>>>>> sorts of problems with that; it's just the thought for the morning.
>>>>>>>>
>>>>>>>> On 4/25/14, 11:49 AM, Alexey Loubyansky wrote:
>>>>>>>>> Embedding the AS is the best starting point to achieve that! And
>>>>>>>>> more
>>>>>>>>> fun, I agree :)
>>>>>>>>>
>>>>>>>>> On 04/25/2014 06:28 PM, Darran Lofthouse wrote:
>>>>>>>>>> And to think my reason for opening the Jira was just for a common
>>>>>>>>>> way to
>>>>>>>>>> mask password inputs where java.io.Console is not available ;-)
>>>>>>>>>>
>>>>>>>>>> On 25/04/14 17:09, Brian Stansberry wrote:
>>>>>>>>>>> On 4/25/14, 10:40 AM, Alexey Loubyansky wrote:
>>>>>>>>>>>> Wow! Indeed :)
>>>>>>>>>>>>
>>>>>>>>>>>> There could be an embedded scope - true, i.e. commands
>>>>>>>>>>>> available
>>>>>>>>>>>> only
>>>>>>>>>>>> this mode, like add-user, module mgmt related stuff, etc.
>>>>>>>>>>>
>>>>>>>>>>> Those commands wouldn't need to be only in that mode though. The
>>>>>>>>>>> implementation of all of them would be based in the server; the
>>>>>>>>>>> "client"
>>>>>>>>>>> aspect of the CLI would just use the management interface. The
>>>>>>>>>>> difference between an embedded mode and what we have now would
>>>>>>>>>>> just be
>>>>>>>>>>> in how the "client" side gets its ModelControllerClient --
>>>>>>>>>>> what we
>>>>>>>>>>> have
>>>>>>>>>>> now vs starting an embedded server and getting some sort of
>>>>>>>>>>> in-vm
>>>>>>>>>>> client.
>>>>>>>>>>>
>>>>>>>>>>>> But it would still mean the server/controller would have to
>>>>>>>>>>>> actually
>>>>>>>>>>>> provide implementations of that functionality and expose it to
>>>>>>>>>>>> the
>>>>>>>>>>>> management tools like the CLI in the embedded mode.
>>>>>>>>>>>
>>>>>>>>>>> Yep.
>>>>>>>>>>>
>>>>>>>>>>>> I like this idea as a concept - direct local management. W/o
>>>>>>>>>>>> any
>>>>>>>>>>>> remote
>>>>>>>>>>>> connect/re-connect/disconnect burden.
>>>>>>>>>>>>
>>>>>>>>>>>> Extending the CLI with custom modules is on the list too. It's
>>>>>>>>>>>> probably
>>>>>>>>>>>> easier to implement at this point.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Likely so, but maybe less fun. ;) I copied you on a PRD-related
>>>>>>>>>>> thread
>>>>>>>>>>> where I briefly get into this general area too.
>>>>>>>>>>>
>>>>>>>>>>>> Alexey
>>>>>>>>>>>>
>>>>>>>>>>>> On 04/25/2014 05:00 PM, Brian Stansberry wrote:
>>>>>>>>>>>>> Hi Alexey,
>>>>>>>>>>>>>
>>>>>>>>>>>>> Wanted to point the discussion on this JIRA out to you as it
>>>>>>>>>>>>> gets
>>>>>>>>>>>>> into
>>>>>>>>>>>>> some fairly fundamental brainstorming that you may find
>>>>>>>>>>>>> interesting.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> -------- Original Message --------
>>>>>>>>>>>>> Subject: [JBoss JIRA] (WFLY-3288) Update add-user to use
>>>>>>>>>>>>> AESH or
>>>>>>>>>>>>> move it
>>>>>>>>>>>>> into the CLI
>>>>>>>>>>>>> Date: Fri, 25 Apr 2014 09:44:35 -0400 (EDT)
>>>>>>>>>>>>> From: Darran Lofthouse (JIRA) <issues at jboss.org>
>>>>>>>>>>>>> To: brian.stansberry at redhat.com
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>       [
>>>>>>>>>>>>> https://issues.jboss.org/browse/WFLY-3288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12963854#comment-12963854
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> ]
>>>>>>>>>>>>>
>>>>>>>>>>>>> Darran Lofthouse commented on WFLY-3288:
>>>>>>>>>>>>> ----------------------------------------
>>>>>>>>>>>>>
>>>>>>>>>>>>> That could be very interested, won't go into too much
>>>>>>>>>>>>> detail in
>>>>>>>>>>>>> this
>>>>>>>>>>>>> Jira as it is not directly related shortly I am switching to
>>>>>>>>>>>>> the
>>>>>>>>>>>>> SSL
>>>>>>>>>>>>> related tasks we have outstanding including the out of the box
>>>>>>>>>>>>> enablement we talked about in Brno - managing an embedded
>>>>>>>>>>>>> instance
>>>>>>>>>>>>> could
>>>>>>>>>>>>> be useful there as well to get it all op based.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I can see this task may end up coming back my way combined
>>>>>>>>>>>>> with the
>>>>>>>>>>>>> other stuff ;-)
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Update add-user to use AESH or move it into the CLI
>>>>>>>>>>>>>> ---------------------------------------------------
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>                  Key: WFLY-3288
>>>>>>>>>>>>>>                  URL:
>>>>>>>>>>>>>> https://issues.jboss.org/browse/WFLY-3288
>>>>>>>>>>>>>>              Project: WildFly
>>>>>>>>>>>>>>           Issue Type: Feature Request
>>>>>>>>>>>>>>       Security Level: Public(Everyone can see)
>>>>>>>>>>>>>>           Components: Domain Management, Scripts
>>>>>>>>>>>>>>             Reporter: Darran Lofthouse
>>>>>>>>>>>>>>              Fix For: Awaiting Volunteers
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Within the add-user utility it is difficult to handle
>>>>>>>>>>>>>> situations
>>>>>>>>>>>>>> where
>>>>>>>>>>>>>> we do not have access to a java.io.Console which is the
>>>>>>>>>>>>>> easiest
>>>>>>>>>>>>>> way to
>>>>>>>>>>>>>> handle password reading without an echo to the user e.g. in
>>>>>>>>>>>>>> Cygwin
>>>>>>>>>>>>>> Switching to AESH would allow us to use the implementation
>>>>>>>>>>>>>> there to
>>>>>>>>>>>>>> handle this.
>>>>>>>>>>>>>> Alternatively it may actually make sense to make add-user a
>>>>>>>>>>>>>> special
>>>>>>>>>>>>>> mode of the CLI, we may at some point want to switch to
>>>>>>>>>>>>>> runtime
>>>>>>>>>>>>>> operations being executed on the server so porting to the CLI
>>>>>>>>>>>>>> could be
>>>>>>>>>>>>>> the first step to make this possible.
>>>>>>>>>>>>>> Overall this is going to require further discussion so the
>>>>>>>>>>>>>> comments
>>>>>>>>>>>>>> here are just a starting point.
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> This message is automatically generated by JIRA.
>>>>>>>>>>>>> If you think it was sent incorrectly, please contact your JIRA
>>>>>>>>>>>>> administrators
>>>>>>>>>>>>> For more information on JIRA, see:
>>>>>>>>>>>>> http://www.atlassian.com/software/jira
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Brian Stansberry
>>>>> Senior Principal Software Engineer
>>>>> JBoss by Red Hat
>>>>> _______________________________________________
>>>>> wildfly-dev mailing list
>>>>> wildfly-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>
>>>
>>>
>>
>>


-- 
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat

More information about the wildfly-dev mailing list