Re: [VOTE] sponsor ActiveMQ ServiceMix to become sub-projects of Geronimo
+1 [EMAIL PROTECTED] wrote: The current PMCs of both ActiveMQ and ServiceMix have overwhelmingly voted to become Geronimo sub-projects. The incubator proposals are here... http://wiki.apache.org/incubator/ActiveMqProposal http://wiki.apache.org/incubator/ServiceMixProposal Please vote if you'd like Geronimo to be the sponsor of the projects during incubation [ ] +1 = I support the move to sponsor ActiveMQ ServiceMix during incubation as sub-projects of Geronimo [ ] +0 = I don't mind either way [ ] -1 = I don't support this move because: ___ I'm obviously +1 :) James --- http://radio.weblogs.com/0112098/
Re: Remote Deployment from the Web Console
Joe, I think we still should aim to support remote deployment using the command line tools as users will expect them to work with remote systems, e.g. a user developing on Windows who wants to deploy to their UNIX box (possibly automated as part of their build process). John Joe Bohn wrote: There has been some discussion about the need/desire for remote deploy in V1. I just wanted to point out that it appears that the deployment from the web console works remotely (with file upload). This surprised me and several others so I just wanted to make sure people were aware of it. I verified this across two machines (not across firewalls or anything)and it worked fine for a simple war. Is the console capability good enough to claim remote deploy even if we don't have a command line version of this? -Joe
Re: NEW - [VOTE] sponsor WADI to become sub-projects of Geronimo
Gmane doesn't want to forward my email, so here's my fourth attempt at voting: +1 Jan Jeff Genender wrote: The current PMCs of WADI have overwhelmingly voted to become a Geronimo sub-project. The incubator proposal is here... http://wiki.apache.org/incubator/WadiProposal Please vote if you'd like Geronimo to be the sponsor of the project during incubation [ ] +1 = I support the move to sponsor WADI during incubation as sub-projects of Geronimo [ ] +0 = I don't mind either way [ ] -1 = I don't support this move because: ___ I'm obviously +1 :) Jeff
Re: [VOTE] sponsor ActiveMQ ServiceMix to become sub-projects of Geronimo
2 attempts via gmane to email this have failed, so hopefully this one will succeed: +1 Jan [EMAIL PROTECTED] wrote: The current PMCs of both ActiveMQ and ServiceMix have overwhelmingly voted to become Geronimo sub-projects. The incubator proposals are here... http://wiki.apache.org/incubator/ActiveMqProposal http://wiki.apache.org/incubator/ServiceMixProposal Please vote if you'd like Geronimo to be the sponsor of the projects during incubation [ ] +1 = I support the move to sponsor ActiveMQ ServiceMix during incubation as sub-projects of Geronimo [ ] +0 = I don't mind either way [ ] -1 = I don't support this move because: ___ I'm obviously +1 :) James --- http://radio.weblogs.com/0112098/
Re: Constructing deployment plans from Configuration GBeanData
You could look at how ant does it. I am guessing using exec(). http://ant.apache.org/manual/CoreTasks/chmod.html John Aaron Mulder wrote: On 11/18/05, Dain Sundstrom [EMAIL PROTECTED] wrote: In 1.1+ we could change the config store to set the file permissions on the directories it creates. How can you do that from Java? Aaron On Nov 18, 2005, at 11:05 AM, Kevan Miller wrote: On 11/18/05, Aaron Mulder [EMAIL PROTECTED] wrote: On 11/18/05, Dain Sundstrom [EMAIL PROTECTED] wrote: Wait a sec. We are worried about an administrator that has access to the console from seeing a password embedded an a configuration file? The admin can deploy applications, which could easily just scan for passwords in memory or on disk. Anyone with access to this console is root for the geronimo instance. Yeah, that's why I waffle. But for example, if you look at a database pool in the console, it uses a password field and doesn't show you the plain text. It's not that you can't get around this (via, say, view source, if not writing your own code to inspect the GBeans), it's that I'm not sure I like flagrantly popping up stuff with passwords right there. You know, shoulder-surfing, or whatever. Erin says some peolpe argue that no security is better than something weak that gives you a false sense of security, but I also think there's a place for defending against the casual observer. Forget about the console for a sec. How many people will think to make their config store directory non-world-readable? Sure you could write some code to deserialize the stuff in there today, but if anyone with an account on the box can just view a plain-text plan out of the config store with the passwords, that's really no security. (And since every connector has different config params it's not so easy to just mask out the password in every file we copy in there, though it would be a good start to do it for any config-param where name.toLowerCase().indexOf(password) -1.) Aaron I think you raise a couple of good points about 1) protecting config-store directory and 2) masking sensitive configuration data. I ran into both of these looking at your recent issue http://issues.apache.org/jira/browse/GERONIMO-1135 (keystore and passstore passwords are available in System properties). BTW, another potential exposure of sensitive data are the admin ids and passwords stored in a .geronimo-deployer directory by your recent login addition to deployer. config-store and .geronimo-deployer are documentation/good practice issues which shouldn't be too hard to document (but easy to ignore/ miss...). Protecting sensitive data in the runtime seems like a harder task. Something we can address in V1? Something we must address in V1? Any other security-related problems? -dain
Re: Loose end #1 -- tomcat configuration files
JIRA issue Review location of config-store directory - http://issues.apache.org/jira/browse/GERONIMO-739 should be considered when looking at support for multiple instances. John Jeff Genender wrote: +100 on this idea...we need to support multiple instances. This is going to be key on hosting configuration and developer shared boxes. Matt Hogstrom wrote: I think anything we do in this area should start to factor in the idea of multiple configurations for a single Geronimo tree. For example, if I was running server 1 and server 2 and wanted to have unique containers for both I would need something like: $G/var/server1/catalina $G/var/server2/catalina as well as unique log4j properties files, config-store, etc. Continuing the single version per tree for 1.0 is fine but I'd like to see us start thinking in a larger context for more complicated customer deployments. In one instance a customer may server multiple servers from a single NAS. Just some food for thought. David Jencks wrote: I now have servers for jetty and for tomcat built using the packaging and assembly plugins. For the second time I've spent 2 days trying to figure out why tomcat is broken only to realize that some required configuration files are missing. The server built in modules/assembly copies the files from the tomcat module, whereas I have simply included them in the geronimo-tomcat-j2ee assembly. Both of these solutions are really unsatisfactory. How about writing a gbean that copies resources out of its classpath and into a specified location (in var)? This would let us package these files in the geronimo-tomcat car so they would be available for any tomcat server. Can anyone see a problem with this approach? thanks david jencks
Re: Create a security committee?
I'd like to at least observe this, and participate where I can. I suggest we exclude vulnerability reports from this so more people can participate. -dain On Nov 18, 2005, at 8:19 PM, Aaron Mulder wrote: All, I'd really like to have a group of interested and available people to review security-related changes to Geronimo. And by this I mean, features dealing with SSL, security realms, storing files with passwords, showing passwords in the console, establishing procedures for locking down the server, reviewing vulnerability reports, etc. I don't really mean nitty gritty details of JACC or conducting a comprehensive security audit of the entire codebase. What would people think of that, and are there any volunteers? I should also note that I expect some vulnerabilities to be reported to the PMC rather than to the public list, but I think a lot can be done outside the PMC as well (or maybe I should exclude reviewing vulnerability reports from what I'm talking about, I don't know if there's a policy there). Thanks, Aaron
Re: Constructing deployment plans from Configuration GBeanData
How about we do what apple does... When connecting to a protected wifi node, it won't show you the password unless you ask it to. This prevents shoulder surfing but if you know your location is safe, you can actually see what you typed. Also the key chain manager built into the os allows you to see your stored passwords but you must provide your paster password first. Anyway, we could pop up a dialog box reminding the user that the configuration file may contain sensitive information such as passwords and do they really want to show it on the screen? Alternatively, we could ask the user to re-authenticate themselves before showing any sensitive information, but I'm not sure how you do this in a web application. -dain On Nov 18, 2005, at 9:14 AM, Aaron Mulder wrote: On 11/18/05, Dain Sundstrom [EMAIL PROTECTED] wrote: Wait a sec. We are worried about an administrator that has access to the console from seeing a password embedded an a configuration file? The admin can deploy applications, which could easily just scan for passwords in memory or on disk. Anyone with access to this console is root for the geronimo instance. Yeah, that's why I waffle. But for example, if you look at a database pool in the console, it uses a password field and doesn't show you the plain text. It's not that you can't get around this (via, say, view source, if not writing your own code to inspect the GBeans), it's that I'm not sure I like flagrantly popping up stuff with passwords right there. You know, shoulder-surfing, or whatever. Erin says some peolpe argue that no security is better than something weak that gives you a false sense of security, but I also think there's a place for defending against the casual observer. Forget about the console for a sec. How many people will think to make their config store directory non-world-readable? Sure you could write some code to deserialize the stuff in there today, but if anyone with an account on the box can just view a plain-text plan out of the config store with the passwords, that's really no security. (And since every connector has different config params it's not so easy to just mask out the password in every file we copy in there, though it would be a good start to do it for any config-param where name.toLowerCase().indexOf(password) -1.) Aaron
[jira] Created: (GERONIMO-1204) Jetty Stack Dump
Jetty Stack Dump Key: GERONIMO-1204 URL: http://issues.apache.org/jira/browse/GERONIMO-1204 Project: Geronimo Type: Bug Components: web Versions: 1.0-M5 Reporter: Aaron Mulder Fix For: 1.0 Not sure what happened -- I was coding for a while and when I went back to deploy an updated version I found this in the server console: 20:38:01,479 WARN [AbstractSessionManager] EXCEPTION java.lang.IllegalStateException at org.mortbay.jetty.servlet.AbstractSessionManager$Session.invalidate(AbstractSessionManager.java:714) at org.mortbay.jetty.servlet.AbstractSessionManager.scavenge(AbstractSessionManager.java:555) at org.mortbay.jetty.servlet.AbstractSessionManager.access$200(AbstractSessionManager.java:63) at org.mortbay.jetty.servlet.AbstractSessionManager$SessionScavenger.run(AbstractSessionManager.java:588) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
