Need help: need openfire 3.9.3 on debian x64 with openjre1.7 instead 1.6

Hi,

I am running openfire on debian 7.6 x64, ssl enabled with certificates.

there are a few other things on the server, some of which are dependent on openjre1.6

i installed openjre1.7 and tried to get openfire to use 1.7 without much success

i tried to “tell” debian to make 1.7 default

i tried to edit the init.d script to hardcode the paths to the 1.7 installation

whatever I do I can not get openfire to “use” 1.7 and its driving me mad.

unfortunately I can not remove 1.6, it is in the dependencies of other software, also has a higher package priority

there must however be a way to force openfire to use 1.7

note: why do I need 1.7 ? to enable better ciphers so android 5 clients can connect again…

apt-get -y install openjdk-7-jre is working for me on Debian, immediately after clean install - although the better and less bloated “openjdk-7-jre-headless” did not work…Note however, that I am using 3.10 nightly build.

Also check this out for trustworthy openfire ciphers: https://alpha-labs.net/2014/12/openfire-and-ciphers/

unfortunately, this doesnt help much.

i did install openjdk-7-jre-headless

i tried update-alternatives --set --> it throws a lot of errors

i tried config-java and set 1.7 as manual default

i even edited the init.d script to force the java-path to the 1.7 install

openfire still uses 1.6

the solution can not be to install the none-headless package. it will install A LOT of crap that I dont need on a production server (x11? yeah right…)

I did manage to get it to use 1.7 in a testsystem by ripping out 1.6 entirely. it seems to break some none openfire related stuff though…

i will do more tests and maybe consult with debian support

this is a very annoying problem. how hard can it be to upgrade java and/or to make one application chose a different java version then the rest of the system. this sucks!

I found a working workaround… using oracle non-open java7

it is not really the best possible solution but it appears to not break anything and just plain works “out of the box”

ciphers can and should be manually looked after, but at least tls 1.x is supported without any hassle and lets android5 devices connect again.

to install via the ubuntu sources use the following commands:

echo "deb [http://ppa.launchpad.net/webupd8team/java/ubuntu](http://ppa.launchpad.net/webupd8team/java/ubuntu) precise main" | tee /etc/apt/sources.list.d/webupd8team-java.list echo "deb-src [http://ppa.launchpad.net/webupd8team/java/ubuntu](http://ppa.launchpad.net/webupd8team/java/ubuntu) precise main" | tee -a /etc/apt/sources.list.d/webupd8team-java.list apt-key adv --keyserver hkp://keyserver.ubuntu.com:80 --recv-keys EEA14886 apt-get update apt-get install oracle-java7-installer

Its certainly true about the non-headless oopenjdk 7 installing a pile of unnecessary junk, although most of it seems to lie dormant - I think…? It does then set itself as the default for me, although openjdk 6 has not been installed as well. The 3.10 nightly Openfire seems to be working fine, but will not work with the headless version at all, even if I force the install. And to use the non-open Oracle may itself be a compromise in the high security you are seeking…

I’m going to post a question about this separately.

Well, this is a bit more complicated when going into more details. This is not a essential live system which is earning me money or has a business name attached. So its not exactly critical infrastructure as many would understand it. Still, for me, my family and friends the server is important enough for me not to screw around with it. I have a identical installation in a vm + snapshots to test every update and try out stuff before replicating on the live system.

that said, it is unacceptable to install x11 and other unneccesary packages for a “simple” small runtime environment like java. that said, none-headless as presented is NOT an option.

I could not definately test if headless/none headless makes the difference. And it would not matter since none-headless is not feasable.

Additionally, other software installed has java6 as a dependency and did behave somewhat unexpected when swapping out openjre 6 with 7 (not thorougly tested)

Long story short, yes, I would have prefered to just apt-get the openjre7, set java manually to 7 and have everything just work. I tried figuring that out, asking here, the debian irc people and other sources and did not get it to work with many hours trying.

I do not have a problem with none-open software. Yes I would prefer the openjre, but its not a neccesity. Security is as always a concern, but the potential damage when the system becomes compromised is minimal. I did not research security differences between oracle java and openjre but if that were a real issue I would have to decide between a) not using openfire or b) live with whatever security risk oracle is exposing me to. For now, I chose a

I wish you luck in figuring out the headless/none headless problematic.