jboss-admin.sh subsystem configuration and batch script examples
by Misty Stanley-Jones
Does anyone have any batch script examples that I can look at? I don't find the WIki [1] to be very clear about the format of the batch scripts or the format of the add and write commands. It only shows read-only commands.
Also if anyone has any examples of configuring the subsystems (specifically modcluster, but not too picky) using the CLI, that would be fantastic! I just can't seem to get the hang of the syntax. I am sure it must be better and shinier than just editing the XML, but I can't seem to get past this road block.
Thanks in advance.
[1] https://docs.jboss.org/author/display/AS71/Management+Clients
--
Misty Stanley-Jones, RHCE
Content Author, ECS Brisbane
14 years
Security Subsystem Configuration Problems
by Jason T. Greene
I have been looking into updating the security subsystem to comply
properly with the management operation/interaction conventions, notably:
1. All attributes are writable
2. All operations and attributes have complete and correct descriptions
3. Resources are used in preference to custom attributes
4. Reasonable validation is performed
I also wanted to fix the plug point for custom login modules.
Digging into this though I found that this subsystem isn't complying
with the overall Andiamo goal of only exposing things that the user
cares about, and is safe to touch.
Pretty much all of the previously exiting wiring is exposed in the
domain model. So like for example you can change the
AuthenicationManager, TrustManager, CallBackHandler, AuditManager, and
MappingManager.
Do we really want to expose these things? Are customers/users actually
using these hooks? If so, is there better alternatives? As an example,
if you replace the authentication manager, which is essentially the
entire implementation of picketbox authentication, then the remaining
configuration of the security domain might not even be handled properly.
I'd love to get this resolved, but in the meantime I am going to make
this stuff be properties. That way we can at least avoid having to
support it forever.
--
Jason T. Greene
JBoss AS Lead / EAP Platform Architect
JBoss, a division of Red Hat
14 years
How do you handle AS7 main/head merges/commits?
by Bill Burke
How do you guys handle merging/committing updates to the AS7 main/head
GIT repo? How many people have responsibility to do this? Do you plan
on adding more? What is the criteria to be added? What are your
processes here? More importantly, do you like these processes?
I'm asking all this cuz I'm moving Resteasy to GIT pretty soon and want
to know best-practices here.
Thanks.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
14 years
[Detyped API Description] Example of multiple values for "allowed"?
by David Bosschaert
Hi all,
I'm looking at the EJB3 pools timeout-unit description, which is the
following:
"timeout-unit" => {
"description" => "The instance acquisition timeout unit",
"type" => STRING,
"required" => false,
"default" => "MINUTES",
"allowed" => "MILLISECONDS",
"access-type" => "read-only",
"storage" => "configuration"
}
Is there an example of an attribute somewhere where 'allowed' has more
than 1 value? I'd like to test a console gui piece against it.
Thanks,
David
14 years
Default Configuration Namespace
by Darran Lofthouse
Now that 7.0.2 is out and the only subsequent planned releases are for
7.1 can we switch the namespace for all default configuration to
'urn:jboss:domain:1.1'?
Regards,
Darran Lofthouse.
14 years
CLI new (generic type) commands
by Alexey Loubyansky
So, I've pushed the prototype for the new approach.
http://community.jboss.org/wiki/GenericTypeCLICommands
Advantages
- any changes in the management model (added/removed operations,
properties, etc) become immediately available in CLI commands without
code changes in the CLI;
- command help content is generated from the description of type,
operations and properties in the management model (so, no text
duplication, localization, etc);
- commands can be added and removed at runtime and customized by the user;
-the total number of cli commands will decrease and they, in a way, will
be better categorized.
Disadvantages
Tab-completion suffers from insufficient info in the management model
about the types, values and relationships/dependencies between the node
and operation properties.
- enumeration values, if the type is boolean, I can do it, but if it's
something else (e.g. tx isolation) the allowed values would have to be
specified in the management model for the type in fixed format;
- exclusive properties, e.g. driver-class/driver-name for datasources.
If I code the data-source command myself I can automatically exclude one
if the other one has been specified;
- referencing properties, e.g. driver-name accepts values that are
registered jdbc driver names, for that to tab-complete, this reference
would have to be described in the model.
There are probably other things that I forgot to mention. I'll follow up
if I remember something.
As always, feedback, ideas, suggestions are welcome.
Thanks,
Alexey
PS: it's not yet in the master as I send it, I did send the pull request
though, so, it's gonna be soon.
14 years
Validation of XML Parsers / Schemas
by Darran Lofthouse
The topic of how to validate the XML parsers or the schemas crops up
every now and again.
I have been having a couple of ideas of how we could at some point look
into this: -
http://community.jboss.org/docs/DOC-17243
The proposed idea actually covers two parts: -
- A wrapper around the existing API that allows the parsers to just
request the elements / attributes they require and leave the wrapper to
handle all the error handling we currently have distributed across the
parsers.
- This then allows us during testing to validate that the calls match
the structure defined in the schema.
I may try prototyping something other the weekend but thought I would
put this out there and see if anyone has any thoughts / comments.
Regards,
Darran Lofthouse.
14 years
Re: [jboss-as7-dev] Remoting issues
by Brian Stansberry
On 9/23/11 7:18 AM, Kabir Khan wrote:
> So:
>
> 1) HC continues to function the same way as it does at the moment.
> 2) For standalone servers we use a remoting-connector attribute to say we want to use a connector from the remoting subsystem, if we use the interface and address we open the endpoint ourselves.
> 3) For domain mode servers we use the native management stuff to say we want to use the endpoint from the remoting subsystems. This is slightly different from your
>> <server-group name="main-server-group" profile="default">
>> <native-management remoting-connector="management"/>
>> </server-group>
>
> since as far as I know domain mode servers don't actually open a management server connection, they connect in to the HC. So something like
> <server-group name="main-server-group" profile="default">
> <native-management remoting-endpoint="endpoint"/>
> </server-group>
>
I didn't like "name" as the attribute name so I guessed. It should
reference whatever the appropriate element is in the remoting subsystem
config. Seems the remoting configuration needs to be fleshed out to
clarify exactly what it should be.
<native-management remoting-endpoint="endpoint"/> -- I'm not sure what a
"remoting-endpoint" is in any of the remoting subsystem config examples
I've seen.
> Since the channels are named I think they would need to be configured as well under the sockets as mentioned already:
>>> <subsystem xmlns="urn:jboss:domain:remoting:1.0"/>
>>> <connector socket-binding="remote-management">
>>> <security-stuff><security-stuff/>
>>> <channel name="server" type="management"/>
What does the "type" attribute mean? And are these channels part of the
persistent config? Or are they runtime-only resources created when some
external service in injects a service that represents the connector and
creates a channel?
>>> </connector>
>>> <connector socket-binding="user">
>>> <security-stuff><security-stuff/>
>>> <channel name="jndi" type="jndi"/>
>>> <channel name="jndi" type="ejb"/>
>>> </connector>
>>> </subsystem>
>
>
> Security becomes a bit strange as it is currently configured as follows which applies to both the configured management interfaces:
> <management>
> <security-realms>
> SNIP
> </security-realms>
> <management-interfaces>
> <native-interface interface="management" port="9999" />
> <http-interface interface="management" port="9990"/>
> </management-interfaces>
> </management>
>
> Since security is configured at connector level I'm not sure what to do when we have:
> <management>
> <security-realms>
> SNIP
> </security-realms>
> <management-interfaces>
> <native-remoting-interface remoting-connector="management"/>
> <http-interface interface="management" port="9990"/>
> </management-interfaces>
> </management>
> In any case the native one gets whatever the remoting subsystem sets up. So I guess we either leave it as it is, and only apply the security settings from here to http-interface. Or we need to allow the security stuff to be used in the individual management interface entries so we could have:
> <management>
> <management-interfaces>
> <native-interface remoting-connector="management"/>
> <http-interface interface="management" port="9990">
> <security-realms>
> SNIP
> </security-realms>
> <http-interface>
> </management-interfaces>
> </management>
>
Currently, the <security-realms> element defines a set of possibilities
and the one one to use is done via an attribute that refers to one by name:
<management>
<security-realms>
<security-realm name="PropertiesMgmtSecurityRealm">
...
</security-realm>
</security-realms>
<management-interfaces>
<native-interface interface="management" port="9999"
security-realm="PropertiesMgmtSecurityRealm"/>
<http-interface interface="management" port="9990"/>
</management-interfaces>
</management>
So there is no need to in-line the security-realm config.
How this would work in the case where <native-interface> is pointing to
a remoting subsystem resource, I'm not sure. We need to understand how
the security aspects of the remoting subsystem configuration are going
to work.
>
> On 22 Sep 2011, at 21:41, Brian Stansberry wrote:
>
>> Real quick reply:
>>
>> 1) IMO only having a single remoting socket for both management and
>> other uses is A Real Good Thing™. But if there are situations that
>> prevent that, I don't think it's terrible.
>>
>> 2) We need to continue to support AS 7.0-style configs. That to me means
>> for cases where that style config is used, we create a separate endpoint.
>>
>> 3) For a domain mode server, we can't force people to add a remoting
>> subsystem in their domain.xml profile. We talked about having the
>> HostController generate one, but that will result in the server having a
>> profile that does not match what was configured in domain.xml --
>> suddenly a bonus subsystem appears. That is no good.
>>
>> 4) For a domain mode server if the HostController is going to configure
>> the server to set up a native management interface that points to the
>> remoting subsystem in the profile, it needs to be told how to do so. One
>> solution, is, in domain.xml:
>>
>> <server-group name="main-server-group" profile="default">
>> <native-management remoting-connector="management"/>
>> </server-group>
>>
>> In summary, I think reusing the remoting subsystem endpoint is great and
>> we should have our standard configs set up that way but there are cases
>> where things aren't going to be configured that way.
>>
>> On 9/22/11 2:19 PM, Kabir Khan wrote:
>>> I'm trying to understand the issues in remoting subsystem vs the management usage a bit better before I dig into this. We have 3 ways remoting is set up:
>>>
>>> 1) Standalone server
>>> a) Endpoint is set up when installing the subsystem
>>> b) Management is set up and creates a new stream server and channel open listener for ("management") with the endpoint from a) injected
>>>
>>> 2) Host controller
>>> a) Endpoint is set up by the bootstrap
>>> b) Bootstrap sets up the management stream server and channel open listeners for (using endpoint from a) injected
>>> -"management" - i.e. traffic on the management address
>>> -"server" - i.e. traffic from a server
>>> -"domain" - if it is the master, to listen to traffic from slaves
>>> c) If it is a slave it connects to the master on the "domain" channel
>>>
>>> 3) Domain mode server
>>> a) Endpoint is set up when installing the subsystem
>>> b) No management stream server is created
>>> c) A channel is opened to the HC using the endpoint from a) on the "server" channel.
>>>
>>> So, I think the issue is that the core depends on stuff set up by a subsystem? A problem in 3 is that if there is no remoting subsystem no endpoint is created, so communication with HC will not start and we will not get the subsystem config from the HC.
>>>
>>> Something doesn't feel quite right but I'm not sure what, so I'm throwing out some ideas.
>>>
>>> The remoting subsystem is quite basic at the moment and the code to set up new connectors is commented out.
>>>
>>> So maybe we should stick with what we have for HC:
>>> <management>
>>> <security-realms>
>>> SNIP
>>> </security-realms>
>>> <management-interfaces>
>>> <native-interface interface="management" port="9999" />
>>> <http-interface interface="management" port="9990"/>
>>> </management-interfaces>
>>> </management>
>>>
>>> But for the standalone server case do something like
>>>
>>> <management>
>>> <management-interfaces>
>>> <native-channel name="server" />
>>> <http-interface interface="management" port="9990">
>>> </management-interfaces>
>>> </management>
>>>
>>> <subsystem xmlns="urn:jboss:domain:remoting:1.0"/>
>>> <connector socket-binding="remote-management">
>>> <security-stuff><security-stuff/>
>>> <channel name="server" type="management"/>
>>> </connector>
>>> <connector socket-binding="user">
>>> <security-stuff><security-stuff/>
>>> <channel name="jndi" type="jndi"/>
>>> <channel name="jndi" type="ejb"/>
>>> </connector>
>>> </subsystem>
>>>
>>> Or maybe everything all goes over one socket so
>>> <subsystem xmlns="urn:jboss:domain:remoting:1.0"/>
>>> <connector socket-binding="remote-management">
>>> <security-stuff><security-stuff/>
>>> <channel name="server" type="management"/>
>>> <channel name="jndi" type="jndi"/>
>>> <channel name="jndi" type="ejb"/>
>>> </connector>
>>> </subsystem>
>>>
>>> I'm not clear on the security side of this but we now have the http side of it securing itself in one way and the native channel in another, so maybe this is better
>>>
>>> <management>
>>> <management-interfaces>
>>> <native-channel name="server" />
>>> <http-interface interface="management" port="9990">
>>> <security-realms>
>>> SNIP
>>> </security-realms>
>>> </http-interface>
>>> </management-interfaces>
>>> </management>
>>>
>>>
>>> Or the alternative for the domain mode server is to use two endpoints, one for management installed by the core, and one for other stuff installed by the remoting subsystem.
>>>
>>>
>>> _______________________________________________
>>> jboss-as7-dev mailing list
>>> jboss-as7-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>>
>>
>> --
>> Brian Stansberry
>> Principal Software Engineer
>> JBoss by Red Hat
>> _______________________________________________
>> jboss-as7-dev mailing list
>> jboss-as7-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jboss-as7-dev
>
--
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat
14 years
