Re: How to apply security policies for the web application deployed in Geronimo ?
Hi All, For each application you should add a new line like this grant codeBase "file:${org.apache.geronimo.base.dir}/config-store/APP-NUMNER/-" { permission java.security.AllPermission;};You must change APP-NUMBER with the right value. by the way "permission java.security.AllPermission" is not the best permission for a production environment.ByePaul McMahan [EMAIL PROTECTED] escribió: Please see this thread for information about using security policiesin geronimo:http://mail-archives.apache.org/mod_mbox/geronimo-user/200602.mbox/[EMAIL PROTECTED]Also please note the following JIRA which should address
the issuewith config-store in the pending 1.1 release of Geronimo.http://issues.apache.org/jira/browse/GERONIMO-1689Best wishes,PaulOn 3/31/06, Anitha Krishnasamy <[EMAIL PROTECTED]>wrote: How to apply security policies for the web application deployed in Geronimo ? As in tomcat we have catalina.policy file for all web applications in the conf directory. catalina.policy file grant{ permission java.security.AllPermission; }; Can any one able to help me ? Thanks... Anitha.K__Correo Yahoo!Espacio para todos tus mensajes, antivirus y antispam ¡gratis! ¡Abrí tu cuenta ya! - http://correo.yahoo.com.ar
Re: Multiple servers sharing the same repo and config store
Hi, In WebSphere this is the directory organization: $WAS_HOME/config/cells/$CELL_NAME applications (EAR/WAR/RAR) nodes .$NODE_NAME ..servers (JVM Configurations) ..$SERVER_NAME ..server.xml ..resources.xml ..variables.xmlThe applications are deployed by default in $WAS_HOME/installedApps but the administrator can change the directory (this is a cool functionality)I think that BEA Weblogic has a similar architecture.In WAS 6 there is a new concept (profile).Bye, Dain Sundstrom [EMAIL PROTECTED] escribió: Does anyone know how other J2EE servers structure their directories when they have multiple instances configured?-dainOn Jan 30, 2006, at 5:04 AM, Aaron Mulder wrote: This sounds reasonable to me. I'd prefer to have resolveServer and always look for /var under there. If there are multiple config store s, we'll have to figure out how the deploy tool will know which one to use. Perhaps there should be something indicating whether the config store is "writable" at runtime (vs at server construction time) and only the server-specific one would be writeable? Or at least, the tools would default to writeable ones over not? (Right now they'd theoretically deploy to all available config stores, but I think there's an outstanding issue that the Deployer GBean doesn't let you specify a config store even if you wanted to.) Thanks, Aaron On 1/30/06, David Jencks <[EMAIL PROTECTED]>wrote: Many people have talked on and off about how to set up multiple servers sharing the same repository and config-store, but we haven't arrived at an agreed on way to do it. We have a prospective customer for this feature (Vincent Massol with Cargo) so I'd like to move beyond thinking about it in my head, discuss it, and have someone implement it. I believe any implementation will be more or less trivial, the hard part is figuring out what to do. I've only thought of ways to extend what we have now, rather than restructure anything or add big new capabilities. If someone sees a better way, please speak up. So, we have a ServerInfo gbean that knows where geronimo is located and can resolve absolute locations for other components. Then we have things like the repository and config store gbeans that typically are "located" outside the var dir and things like the logging framework, local attribute manager, derby, and tomcat, that typically keep stuff in the var directory. All or most of these start with the first configuration loaded so t hey can't have any attributes overridden by config.xml: in fact this file is read by one of the gbeans that we need to "relocate". I've thought of two related solutions. Both of them involve giving ServerInfo knowledge of another path and another resolve method. One would be something like "resolveVar" and would normally resolve to geronimo_home/var. This would involve all the gbeans currently looking inside var having the "var" trimmed off the front of their paths and using the new resolveVar method. In this case we'd have different servers represented as e.g. var1 var2 var3 ... The other would give ServerInfo something like resolveServer which would normally resolve to geronimo_home. The gbeans looking inside var would keep their current paths and just call the new resolve method instead of the old one. In this case we'd have servers like var server1/var server2/var ... In either case I think starting geronimo with a command line argument pointing to the var directory is the only way to specify which server you want to run; the default would presumably be as now "var". Several people have suggested putting an additional config-store into var for "private" use by a particular server. At the moment I think that providing a different config-store class that uses the new resolve method on server info would be the best way to do this. I'm not attached to these ideas but this is as far as my thinking has gone. Please comment. thanks david jencks __Correo Yahoo!Espacio para todos tus mensajes, antivirus y antispam ¡gratis! ¡Abrí tu cuenta ya! - http://correo.yahoo.com.ar
Re: Geronimo JVM Configuration Portlet
Hi, I thinkif this new feature will be in a multi-server/cluster topology there should be new java proccess with specific roles (Manager, Node Agent, App.Server) also I think there shouldbe a Sync service for config files, under this topology the Node Agent must have the resposabiliy of luching the App.servers, it means creating the java -X -D -gc command line.I'm sorry if I'm not the right person for this dev forum.Thanks. Paul McMahan [EMAIL PROTECTED] escribió: The multi-server aspect of this potential new feature had crossed my mind. But I didn't have a firm grasp yet on how the console should behave in a clustered environment. For example, if we decide that some particular node in the cluste r will be designated as the manager then its console should be capable of doing things like setting JVM args for the other cluster members as well as deploying apps to them. However, if each member of the cluster is a peer then each could have its own independent console which handles setting its JVM args independently (seems like we would want to provide this capability in any case). Like you say, this should factor into the 2.0 discussion as it gets underway.Paul On 1/19/06, Matt Hogstrom [EMAIL PROTECTED] wrote: I like the idea of using an env script/bat implementation.It makes lots ofsense in many ways.I don't think one would be allowing users to directly modify the scripts b ut we'd ask for their input and validate it before buildingthe script.So from that perspective the input mechanism is is responsible fordoing the scrubbing.The bigger issue in my mind is the strategy for supporting multiple server configurations.A single env script is not adequate for all possible serverssince the user may choose to run different apps on servers that are not part ofthe same group.I'm not sure how WADI is handling this from an admin / config perspective but they have the same issue in how do we get the right information into aparticular server instance.It sounds like this will most likely be a 2.0discussion since it will be a significant change over how were currently structured. One possible (and simple solution) would be to:$g/var/servers/server1/config.xml /server2/config.xml /server3/config.xmlWould contain the meta data used to generate unique env scripts (not very scalable) or better yet, be used to dynamically build the java command to launchthe desired server.I guess at some point someone might want to restrict who can configure a set ofservers based on their credentials but I think that'sa bit out on the horizon. To paraphrase Guglielmo, perhaps that is a feature that people will get fromcommercial software.Thoughts?Matt __Correo Yahoo!Espacio para todos tus mensajes, antivirus y antispam ¡gratis! ¡Abrí tu cuenta ya! - http://correo.yahoo.com.ar
