Provogeek
Contributor
Contributor

Unable to get upgrade from 2.3.2 to 3.2 to work

Jump to solution

A customer asked me to upgrade their Usage Meter appliance for them, and to me it seems like the upgrade process does not work at all.  I have made multiple attempts following documentation instructions and each ends with the same failure; Java Exception errors on the appliance Web UI on login.

  1. I upload the OVA and do the base setup of the appliance, post OVA import I have just been setting the Web UI password and timezone.  I have tried logging in and setting up the basic customer information in the system, I have also tried doing nothing and leaving it alone.
  2. I open up SSH on the 2.3.2 source server running "service sshd start"
  3. On the destination 3.2 machine, I run "importum 10.1.1.13 232"    The command completes with errors, never prompts for passwords as expected.  When looking at the message logs, I find that the connection from the destination server was refused.   Trying to manually connect, the SSH connection is refused.  When the migration attempt fails like this, the appliance will then be unusable.  Just opening the Web UI produces Java Exception errors.

I was able to resolve the connection issue by adding sshd: ALL to the hosts.allow file, but this did not help my migration to complete.  When running updateum, it now prompts me as expected for the source root password.  It looks like it completes, and now the login page for the UI will come up.  But once I login, I get a Java Exception error message.

Labels (2)
Tags (1)
1 Solution

Accepted Solutions
dbriccetti
Hot Shot
Hot Shot

Hi. Thanks for the detailed description of the problems. I believe we can correct the remaining problem.

In Version 3.0 we began encrypting the Manage Page email server password (if one was provided). This required a manual step of blanking out that password before migration. We neglected to mention this in the current migration instructions. I apologize for this error. You have two ways to proceed. I recommend Approach B.

Approach A:

  1. remove the email server password on the 2.3.2 system (Manage Page), migrate again, then restore the password

Approach B:

  1. ssh to the 3.2 system (or open the console from a vSphere client)
  2. run: service tomcat stop
  3. run: sql (this is an alias for a command that will put you in a PostgreSQL interactive shell)
  4. type: update "EmailServer" set password = '';
  5. type: Ctrl+D (hold down ctrl and press D). You should be back at the Linux shell.
  6. run: service tomcat start
  7. Go to the Manage page on the 3.2 webapp and put the email server password back in

Please let me know what happens. Thanks.

Message was edited by: Dave Briccetti Noted that it was version 3.0 where the change was introduced. The error reported here affects only migrations from 2.3.2.

View solution in original post

7 Replies
dbriccetti
Hot Shot
Hot Shot

Hi. Thanks for the detailed description of the problems. I believe we can correct the remaining problem.

In Version 3.0 we began encrypting the Manage Page email server password (if one was provided). This required a manual step of blanking out that password before migration. We neglected to mention this in the current migration instructions. I apologize for this error. You have two ways to proceed. I recommend Approach B.

Approach A:

  1. remove the email server password on the 2.3.2 system (Manage Page), migrate again, then restore the password

Approach B:

  1. ssh to the 3.2 system (or open the console from a vSphere client)
  2. run: service tomcat stop
  3. run: sql (this is an alias for a command that will put you in a PostgreSQL interactive shell)
  4. type: update "EmailServer" set password = '';
  5. type: Ctrl+D (hold down ctrl and press D). You should be back at the Linux shell.
  6. run: service tomcat start
  7. Go to the Manage page on the 3.2 webapp and put the email server password back in

Please let me know what happens. Thanks.

Message was edited by: Dave Briccetti Noted that it was version 3.0 where the change was introduced. The error reported here affects only migrations from 2.3.2.

Provogeek
Contributor
Contributor

Thank you Dave, that resolved the issue  (did the first suggestion)

0 Kudos
dbriccetti
Hot Shot
Hot Shot

Great! Thanks again for the report. Having it will help others.

0 Kudos
SysAdmin_Dave
Contributor
Contributor

Hi,

I am trying to migrate from a 2.3.2 vCloud appliance to a 3.2 vCloud appliance and have followed the same steps as Provogeek as outlined in the vCloud Usage Meter Users Guide.  I am getting very similar errors when I run the importum command and I'm not prompted for a my password as I should be according to the Users Guide:

importum command output.jpg

Although the import says it completes when I look at the log file there are hundreds of error messages, the majority of them are similar to the following:

ALTER DATABASE

CREATE TABLE

psql.bin:/opt/vmware/cloudusagemetering/database/migrate/232-30.sql:11 ERROR relation "Collection" does not exist.

Import Log File.jpg

We have no e-mail server password set on the Manage Page on our 2.3.2 appliance although I have tried following dbriccetti suggestions anyway with no success.

Any help would be appreciated

SysAdmin Dave.

0 Kudos
dbriccetti
Hot Shot
Hot Shot

Hi. I think the best clue here is “connection closed by remote host”. I think you’ll find you are unable to ssh to that old Usage Meter. Can you fix that problem first? Perhaps /etc/hosts_allow?

Dave Briccetti

Lead Usage Meter developer

0 Kudos
SysAdmin_Dave
Contributor
Contributor

Hi Dave,

Thanks for your response.  I have allowed SSH in /etc/hosts_allow and I now got prompted for the password when I run the importum command, however, the outcome is still the same when I try to browse to the web interface.  I get the same error message as I attached in my previous update.

Regards

Sysadmin Dave

0 Kudos
dbriccetti
Hot Shot
Hot Shot

Dave, sorry to hear there are still problems. Since this is a different issue from the one in this thread (which is answered), could you create a new message, please, and include the import log and then your /var/log/usgmtr/um.log? Thanks.

Dave Briccetti

0 Kudos