This page present some questions about OpenMOLE.

Which Java version should I use?

OpenMOLE is fully working under OpenJDK 7 and 8. This is the recommended option. You can check which Java version you're running by typing java -version in a console.

If you use the closed-source Oracle Java virtual machine (which is probably the case if you are working on Mac or Windows), you have to install the Java Cryptography Extension (JCE) available at the bottom of this page in order for OpenMOLE to be fully functional.

JCE is an archive containing a bunch of files that you should replace in the jre/lib/security directory of your java installation. It enables strong cryptographic algorithms.

Another concern for Mac users are the concurrent versions of Java that are often present on the same system. Mac OS ships with a default Java 6 that is not suitable to execute OpenMOLE. You must install Java 7 ir greater and set the environment variable JAVA_HOME to the install location on your machine (typically the directory containing .../bin/java).

Where can I find the old versions of OpenMOLE?

Old versions of OpenMOLE software and documentation are available here.

OpenMOLE cannot connect to my environment using SSH

When your workflow does not start to the remote environment you’re accessing through SSH, you can try these few steps to identify the problems.

If you are using OpenMOLE in console mode, enable the FINE level of logging in the console using: logger.level("FINE")

A typical SSH connection error will report as:
FINE: Error in job refresh
net.schmizz.sshj.userauth.UserAuthException: Exhausted available authentication methods

FINE: Error in job refresh
net.schmizz.sshj.transport.TransportException: Incorrect identification: line too long

Password Authentication

If you are using the LoginPassword authentication you might want to double check the user and password you entered since one of them is more than likely incorrect.

SSH Keypair Authentication

In such a case, we'll have to investigate multiple options, as SSH public key authentications are sensible to several configuration parameters.

Public key authentication has usually a higher priority than password-based authentication when trying to connect to a remote server. Thus, when you attempt an SSH connection to the the target environment, if your client asks you to enter a password (please note that a passphrase is different from a password), then your public key authentication is not taken into account.

SSH will skip your public key in case of bad configuration. The most common cases of badly configured keypairs are the following:
  • You haven't created an SSH keypair yet (using ssh-keygen). Private keys are usually stored in ~/.ssh/id_rsa or ~/.ssh/id_dsa, and should have a matching ~/.ssh/id_[rd]sa.pub next to them.
  • Permissions of your ~/.ssh folder must be set to drwx—— (700 in octal). Also, too permissive home directories (with write access given to the whole group for instance) might show problematic.
  • A ~/.ssh/authorized_keys file must be present on the remote system. It should at least contain a line matching the content of the ~/.ssh/id_[rd]sa.pub from your base system.
  • You entered a passphrase when you generated your SSH keys and cannot remember it. In such a case, it might be better to generate another keypair.

If you still could not solve your SSH authentication problems, another option is to recreate a public/private keypair using the ssh-keygen shell command. Store it to a different file to avoid overwriting the one already in place. You might also want to try a simple LoginPassword authentication as explained in the SSH section.

Adding the -vvv flag to your ssh command will give a lot more details on the communication between your client and the remote server. This will allow you to find out which authentication is successful as well as the order in which the authentication modes are tried.

My problem is not listed here

If you could not resolve your problems, feel free to post your problem on the mailing-list.

If you think your problem is induced by a bug in OpenMOLE, please report the issue exhaustively on our GitHub page.