Current setup, arm based qnap nas device running a modified linux os. I have the arm based 1.6.0_32 Sun Microsystems Java HotSpot Embedded Client VM installed and openfire 3.7.1
openfire runs flawlessly in this configuration so if anyone wants to say openfire won’t run on arm, runs fine.
I have upgraded openfire using the gzip package, followed instructions exactly. and yes I’m working on the running copy verified from admin console to insure there wasn’t a second copy hiding somewhere. openfire was upgraded to 3.8.0, I preserved database, plugins save for admin console, conf folder and my security certs.
Now for the problem… admin console still claims everything is 3.7.1 and I cannot figure out why, I don’t know if upgrade is missing a vital file, or if admin interface is just lying to me, or what’s going on. yes I’ve restarted server since upgrade and yes openfire was shut down during upgrade.
any tips, pointers or hints would be appreciated. Thanks!
not sure why that matters. but the path is a bit odd because of the nas’s file structure. most of it is stored in volitile memory.
openfire is stored in non volitile storage and started by a cron job rather than service entries.
file path is something like /share/HDA_DATA/.ipkg/openfire or something like that. I’ve updated the appropriate files. my problem is not in finding the install path, it’s that openfire claims it’s still old version.
Back it up, delete it, see if it restarts - If it does restart, you know it’s some place else.
What does your java command line look like (with all the parameters) when it is running? Is the openfire.jar path the same place you think it is installe din?
or perhaps temporarily put it in a different directory strcture so you are not dealing with your NAS at all.
openfire is only installed in a single location. command line does point to the one and only install on the entire server. and it’s not simply stored on the nas, it’s actually running ON the nas, natively on it’s cpu.
please see original post, I already stated I am working on the only copy.
So remove it entirely, install new version and restore configs/anything else you need.
I don’t know your environemnt, so mostly just guessing and going through the same troubleshooting steps I would on my end. You could also try downloading 3.8.0 onto a different system and doing a md5/sha1 checksum of openfire.jar on both and seeing if they are identical.
I appreciate the advice so far, but these steps were already followed. reposted from original post
“openfire was upgraded to 3.8.0, I preserved database, plugins save for admin console, conf folder and my security certs.”
this was a fresh install basically, deleted entire folder, restored only config data after unpacking new openfire.
I have not tried md5 comparison but it could be possible the tarball I have has old files in it for some reason. not sure why that would be unless someone responsible for packaging or uploading the packages got them mixed up and uploaded older version with new version name.
shows file path as well. and it’s also the active copy running in memory. which means something screwy is going on with it somewhere cause it is newest copy.
wait, I’m very confused… how come all the sudden several days later it shows the upgraded version?
problem is gone and I’m left with a wtf thought. perhaps it was somehow using a cached copy of page? duno how as browser cached was cleared. either way problem has resolved itself. I have no idea why it claimed it was old version for days after the upgrade, but it finally resolve itself somehow… and yes I know service had been restarted many times cause I completely rebooted system multiple times just to be sure.