tpasswd script does not allow password creation without an already deployed system

[GoogleCodeExporter]

What steps will reproduce the problem?

1. I need to create passwords for Tungsten security framework
2. I copy tpasswd from the source code tree into tungsten-replicator/bin
3. I run tpasswd -c username my_password 

What is the expected output?

Either an error message saying that it does not know where to write, or a 
password file containing my newly created password.

What do you see instead?

./tungsten-replicator/bin/tpasswd -c batman GothamCity -t rmi_jmx
log4j:WARN No appenders could be found for logger 
(com.continuent.tungsten.common.security.PasswordManager).
log4j:WARN Please initialize the log4j system properly.
log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more 
info.

And no password file was created

What is the possible cause?

1) The configuration of LOG4J is not correct
2) There is apparently no check about a security.properties file being used or 
not. 

What is the proposed solution?

1) move the file to the build directory
2) adjust the Log4J settings
3) remove the option related to security.properties, and use a mandatory 
argument for the password file. Deploying the file is a task for the installer. 
This utility should only create/update the password file.
4) make sure that the script works in a pre-installation environment (inside 
the staging directory, immediately after unpacking the tarball).

Original issue reported on code.google.com by g.maxia on 31 Jul 2013 at 1:30

[GoogleCodeExporter]

The tpasswd is missing log/ folder setup, like the following:

# Set log directory. 
if [ -z "$REPLICATOR_LOG_DIR" ]; then 
  REPLICATOR_LOG_DIR=$RPHOME/log
fi
if [ ! -d "$REPLICATOR_LOG_DIR" ]; then
  echo "Cannot find replicator log directory: $REPLICATOR_LOG_DIR"
  exit 1
fi
JVM_OPTIONS="${JVM_OPTIONS} -Dreplicator.log.dir=$REPLICATOR_LOG_DIR" 

Original comment by linas.vi...@continuent.com on 31 Jul 2013 at 2:24

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I guess it should not be located inside the replicator as it's a potentially 
used by other components than the replicator.
Should it be under cluster-home/bin ?

tpasswd was not deployed correctly as it was missing the log4.properties file-> 
you could not see error messages.

> What is the expected output?
Error message is present when application deployed correctly

>What is the possible cause?
>1) The configuration of LOG4J is not correct
Yes, the properties file was not deployed

Original comment by ludovic....@continuent.com on 31 Jul 2013 at 2:56

[GoogleCodeExporter]

as long as it runs properly (both before and after installation), it can be in 
either cluster-home/bin or tungsten-replicator/bin

Original comment by g.maxia on 31 Jul 2013 at 3:04

[GoogleCodeExporter]

1) The tool should tell you where the file is created, or alternatively you 
should be able to tell it where to create the file.

Ideally it should be the latter so that it can be easily referenced during tpm 
install/update. 

2) For the security.properties file, for the distributed version we shouldn't 
have to supply this information; it should really be hardcoded based on the 
configuration file that would be installed if JMX was enabled. 

Original comment by mc.br...@continuent.com on 1 Aug 2013 at 2:13

[GoogleCodeExporter]

On further investigation, I can see no reason for the requirement of the 
security.properties file, other than to determine the location of the password 
file. 

As such, tpasswd should work as follows: 

tpasswd -c username password -t prefix -o passwordfile 

That would make the entire system much simpler. 

If the security properties file is required for some part of the salt used to 
encrypt the passwords, it should be automatically determined, not user 
supplied, but you should *always* be able to write to a password of your 
choosing, otherwise it will be impossible to use with tpm as the distribution 
mechanism

Original comment by mc.br...@continuent.com on 1 Aug 2013 at 3:44

[GoogleCodeExporter]

The idea is that the security parameters should be transparent once they're 
setup. In the same way as you don't specify anything when using trepctl, you 
don't want to specify anything when modifying or creating users.

The security.properties file is used to specify the location of the password 
file AND to decide whether the password ahould be stored encripted or not (and 
locate the trustore if needed.).

security.properties is the "central repository" of security related parameters. 
This is why tpassws should use it rather than expose numerous other command 
line options.

Original comment by ludovic....@continuent.com on 2 Aug 2013 at 8:49

[GoogleCodeExporter]

When we start a new installation, we DON'T have any password file yet. 
If we want to start the installation and pass the password file to the 
installer, we need to create it first.
How do we create a file that needs to be installed in order to be seen by 
tpasswd?

Original comment by g.maxia on 2 Aug 2013 at 9:05

[GoogleCodeExporter]

If the file doesn't exist, application will create it

Original comment by ludovic....@continuent.com on 2 Aug 2013 at 12:14

[GoogleCodeExporter]

First off, currently it does not happen. If the file does not exist, it is not 
created, and no errors are DISPLAYED. (The errors, according to the code, 
should go to the logs, but since log4j is misconfigured, we don't know anything 
about what happened).

Second, when we are about to install, we do not have a security properties 
available. The template in the tarball points to a directory that does not 
exist yet. 
If tpasswd only refers to the passwords file through security properties, it 
means that users must run the installer twice (the first time to put a dummy 
passwords.store in place, and the second time after the file is created, to 
deploy the password file to all nodes).

Original comment by g.maxia on 2 Aug 2013 at 12:41

• Added labels: Usability

[GoogleCodeExporter]

Options added to override or replace security.properties
tpasswd to be deployed in cluster-home/bin
log directory to be created in cluster-home/log
log4j.commandline.properties to be deployed in cluster-home/conf

Original comment by ludovic....@continuent.com on 6 Aug 2013 at 2:58

• Changed state: Fixed

[GoogleCodeExporter]

Original comment by g.maxia on 6 Aug 2013 at 5:21

• Changed state: Started

[GoogleCodeExporter]

-password file created if it doesn't exist
-tpasswd deployed with release-community.sh in cluster-home/bin
-log4j configuration file placed in cluster-home/conf: it is used to display 
feedback on the command line.
-log directory created with release-community.sh

Original comment by ludovic....@continuent.com on 8 Aug 2013 at 1:20

• Changed state: Fixed