Can you apply 8.2 on top of 8.1 SP1 Patch 10?
My update just failed.
Log attached.
Please help, thanks!
Can you apply 8.2 on top of 8.1 SP1 Patch 10?
My update just failed.
Log attached.
Please help, thanks!
According to the RSA Authentication Manager 8.2 Setup and Configuration Guide [y]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 How to contact RSA Customer Support and open a case so that a support engineer can assist you.
Regards,
Erica
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)
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:
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
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.
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: