geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Blevins <dblev...@gluecode.com>
Subject Re: Proposed Deployer Syntax
Date Fri, 29 Oct 2004 06:01:43 GMT
Looks good.

I'd like to add the ability to have the password read from standard in 
(system.in) as is done with many unix tools that set or require 
passwords.  I don't like scripts that required the password to be part 
of the args (it shows up in your command history and the processes 
list).  You might as well give the info to everyone on the box--not fun 
if you provide app server hosting.

Also, how do we feel about allowing users to put username and password 
information in their home directory and looking for them there.

Being a security conscious script kinda guy I like to do thing like 
this:

cat myModuleWithPlan.ear | ssh myserver.acme.com java -jar 
geronimo/bin/deployer.jar deploy

Then I don't need a deployer running on a port and the only way to 
deploy something is to have a public key installed on the box (don't 
even need an account with login).  This would require the deploy tool 
to read from standard in (system.in) and some flag to tell the deploy 
command to do so.

-David

On Oct 28, 2004, at 7:12 PM, Aaron Mulder wrote:

> General syntax:
>
> deployer [--uri URI [--driver JarFile] [--user username [--password \
>          password]]] command arguments
>
> --uri: a URI to contact the server.  The server must be running for 
> this
> to work.  If not specified, the deployer default to operating on a
> Geronimo server running on the standard port on localhost, or if 
> nothing
> is available there, then the Geronimo server installation that the
> deployer JAR is part of.
> 	A URI to connect to Geronimo has the form:
> geronimo:deployer:jmx:rmi://localhost/jndi/rmi:/JMXConnector
>
> --driver: if you want to use this tool with a server other than 
> Geronimo,
> then you must provide the path to its driver JAR.  Currently, manifest
> Class-Path entries in that JAR are ignored.
>
> --user: if the deployment operation requires authentication, then you 
> can
> specify the username to use to connect.  If no password is specified, 
> the
> deployer will attempt to connect to the server with no password, and if
> that fails, will prompt you for a password.
>
> --password: specifies a password to use to authenticate to the server
>
>
> Common Commands and Options
> ---------------------------
> deployer deploy [module] [plan]
>
> 	Normally both a module and plan are passed to the deployer.
> Sometimes the module contains a plan, or requires no plan, in which 
> case
> the plan may be omitted.  Sometimes the plan references a module 
> already
> dpeloyed in the Geronimo server environment, in which case a module 
> does
> not need to be provided.
> 	If the server is not currently running, the module will be marked
> to start next time the server is started.
>
> deployer undeploy [ModuleID|TargetModuleID]+
>
> 	Accepts the configId of a module, or the fully-qualified
> TargetModuleID identifying both the module and the server or cluster 
> it's
> on, stops that module, and removes the deployment files for that module
> from the server environment.  If multiple modules are specified, they 
> will
> all be undeployed.
>
> deployer start [ModuleID|TargetModuleID]+
>
> 	Accepts the configId of a module, or the fully-qualified
> TargetModuleID identifying both the module and the server or cluster 
> it's
> on, and starts that module.  The module should be available to the 
> server
> but not currently running.  If multiple modules are specified, they 
> will
> all be started.
> 	If the server is not running, the module will be marked to start
> next time the server is started.
>
> deployer stop [ModuleID|TargetModuleID]+
>
>         Accepts the configId of a module, or the fully-qualified
> TargetModuleID identifying both the module and the server or cluster 
> it's
> on, and stops that module.  The module should be available to the 
> server
> and running.  After stop is completed, the server still has the module 
> and
> deployment information available, it's just not running.  If multiple
> modules are specified, they will all be stopped.
> 	If the server is not running, the module will be marked to not
> start next time the server is started.
>
> deployer redeploy [module] [plan] [ModuleID|TargetModuleID+]
>
> 	A shortcut to undeploy a module from one or more servers, then
> deploy a new version.  This is not a smooth cutover -- some client
> requests may be rejected while the redeploy takes place.
> 	Normally both a module and plan are passed to the deployer.
> Sometimes the module contains a plan, or requires no plan, in which 
> case
> the plan may be omitted.  Sometimes the plan references a module 
> already
> dpeloyed in the Geronimo server environment, in which case a module 
> does
> not need to be provided.
> 	If more than one TargetModuleID is provided, all TargetModuleIDs
> must refer to the same module (just running on different targets).
> 	Regardless of whether the old module was running or not, the new
> module will be started (if the server is running) or marked to start 
> (if
> the server is not running).
>
>
> Other Commands and Options
> --------------------------
> deployer distribute [module] [plan]
>
> 	Just like deploy, except the module is not started by this
> operation.
>
> deployer list-targets
>
> 	Lists the targets known to the server you've connected to.
> Currently, there is only ever one target, but this may eventually 
> change.
>
> deployer list-modules [--all|--started|--stopped] [target*]
>
> 	Lists the modules available on the specified targets.  If
> --started or --stopped is specified, only started or stopped modules 
> will
> be listed; otherwise all modules will be listed.  If no targets are
> specified, then modules on all targets will be listed; otherwise only
> modules on the specified targets.  (But note that right now there's 
> only
> ever 1 target.)
>
>
> Not For General Consumption Commands and Options
> ------------------------------------------------
> deployer package [--classPath path] [--mainClass class] \
>          [module] [plan] fileName
>
> 	Creates a configuration JAR rather than installing into the server
> environment.  The fileName argument specifies the JAR to create.  The
> optional classPath argument specifies a Class-Path to include in the 
> JAR
> manifest.  The mainClass argument specifies the Main-Class to include 
> in
> the JAR manifest.
> 	The standard arguments may not be used with this command -- it
> never connects to a remote server.
>
>
> Aaron


Mime
View raw message