AM Update to 8.2 from 8.1 SP1 Patch 10 Failed

[MattEvangelisti]

Can you apply 8.2 on top of 8.1 SP1 Patch 10?

My update just failed.

Log attached.

Please help, thanks!

[_EricaChalfin]

Matthew Evangelisti‌,

According to the RSA Authentication Manager 8.2 Setup and Configuration Guide ou can apply the RSA Authentication Manager 8.2 upgrade patch to any hardware appliance or virtual appliance that has RSA Authentication Manager 8.1 Service Pack 1 (SP1) software.

I would recommend that you https://community.rsa.com/docs/DOC-1294 and open a case so that a support engineer can assist you.

Regards,

Erica

[EdwardDavis]

Yes you should be able to.

The error is specifically this:

Exception in thread "Main Thread" : Unable to delete file /opt/rsa/am/server/servers/AdminServer/data/store/diagnostics/old/WLS_DIAGNOSTICS000000.DAT

Not sure what to say about it, but this is what the patch is complaining about.

Try this: if it rolled back and the system is up and running again on 8.1 sp1 p10

See if you can install/upgrade 8.1 sp1 patch 15 (and if so, install 8.2 on top of that)

[MattEvangelisti · Accepted solution]

Thank you Edward and Erica.

It looks like a previous administrator created the directory "old" as ROOT to backup diagnostic files in. Problem is, updates are run as rsaadmin, so of course it did not have permissions to delete the file (not sure why it needs to, either).

It's unfortunate that this would make the entire update fail, or that it was allowed to get to a point where it couldn't roll back. Luckily I had crated a snapshot before starting.

I think it might be a good idea to implement a file and folder permissions check on the FS into that "Preparing for update..." stage.

Solution was:

1. Shutdown
2. Rollback to snapshot
3. Power on
4. Sync Replica
5. Check Replica status is Normal
6. Shutdown
7. Delete snapshot
8. Create fresh snapshot
9. Power on
10. Manually delete "old directory"
11. Apply update

[SGTech]

Hi Matt, we should not touch any thing in the OS or any changes or permissions or any thing in the RSA appliance as the OS is specially designed for 2FA solution. please don't create any folder.

thanks

[MattEvangelisti]

Agreed, but since it is possible to do, people will do it anyway.

In my case (and I'm sure many other's), it hard to know who has touched the system since multiple people manage these VMs across a team. I had no way of knowing the FS was modified 2 years ago by someone who no longer works at the company.

For both of those reasons, doesn't it make sense to add a simple permissions check on the filesystem to the upgrade script, before the upgrade executes? (Perhaps during the "Preparing for upgrade..." step)

Especially since permission integrity is so sensitive (literally a folder was added) and will determine the success of the upgrade which has no option to rollback.