Installing OpenFire 4.0.1 on CentOS 7

[scottalanmiller]

With the recent release of OpenFire 4, it is time to get it up and running in the NTG Lab. I have been wanting to get OF up and running in the lab for a while and today a couple different people asked me to get this working on CentOS 7. So this makes for a perfect opportunity.

First, as I have a CentOS 7 template ready to go on my Scale HC3 cluster, I can just clone that and be up and ready to install very quickly (SSH keys, Filebeat, Topbeat, Glances, firewall and the like all installed already.) If you want to follow along, this is a very minimumal CentOS 7 install, just be sure to add the firewall for security.

First clone my Scale CentOS 7 template.

The clone that I am working from is basically the CentOS 7 Minimal with the firewall already installed.

yum -y install firewalld

Database

OpenFire actually comes with an embedded database, so for many users, especially those just testing the product out or using it in a small business that is all that they need. It is pretty rare that you would need more than the embedded database will provide. For those that do, MariaDB is the recommended database and is easy to install. Now if you were going to do a massive install or you have an existing infrastructure for PostgreSQL, that would be an excellent choice, too.

yum -y install mariadb-server mariadb

The only extra thing that we need for installing OpenFire is Java. We could use Oracle's Java but the OpenJDK included with CentOS 7 seems to work just fine.

yum -y install java

OpenFire has one secret dependency that is not listed and does not get called by the package correctly. We need to install this library manually:

yum -y install libstdc++.i686

We will need to install OpenFire itself. Thankfully, OpenFire has always made this super easy. We just need to install their RPM package.

yum install http://www.igniterealtime.org/downloadServlet?filename=openfire/openfire-4.0.1-1.i386.rpm

Getting installed is easy. Now we have to configure our MariaDB database.

First we need to secure the installation, it just needs to be started first:

systemctl start mariadb
systemctl enable mariadb
mysql_secure_installation

This will step us through getting our default install secured. Just follow the prompts. (I'll include the full dialogue below for those that want to see what it looks like for comfort.)

Now we can configure our database:

mysqladmin create openfire -p

(The -p flag tells it to ask for our password. It will prompt you for a password and will ask for the one given during the script that you just ran before that.)

cat /opt/openfire/resources/database/openfire_mysql.sql | mysql openfire -p;

Same here with the password as before.

Firewall

Now we just need to open the firewall and start OpenFire:

firewall-cmd --zone=public --add-port=9090/tcp --permanent
firewall-cmd --reload
systemctl start openfire
systemctl enable openfire

Setup from Browser

Now OpenFire should be running and you can point a local webbrowser to http://ipofyourserver:9090/ and we will continue from the graphical interface.

If all worked as it should have, now we just need to step through the graphical install screens. First we select our language:

Then we set our basic server settings. Really the only thing necessary to change here is "Domain", just put in the hostname of your OpenFire server.

Now we choose the "full" database option or embedded. If you want to use the embedded you have to decide now, but we are using MariaDB in this example so we just accept the default.

And now our database settings. Here I used root and the password that we set during the MariaDB securing script. Notice that I changed the connection URL to 127.0.0.1 and put in the name of our database: openfire. Choose MySQL from the database drop down and these will be populated for you, requiring only the changes that I mention.

MariaDB is a drop in replacement for MySQL. So all of the documentation that we are using is for MySQL. MariaDB is actually the more advanced and robust of the two today.

Note: This is only for a demo installation, for a production installation you should create a non-root database user. However, if this is the only use of the system and the database will not be used for any other function this is actually a trivial security step.

Now in our Profile Settings we can just accept the defaults. For advanced users, you can connect OpenFire to Active Directory.

Configure the admin account. Your admin user will be called admin, here you assign that account an email address and set the password.

Setup is complete! Click to continue on to the full administration console.

That's it. OpenFire is installed and configured.

[scottalanmiller]

As promised, below is the output of the database security script....

NOTE: RUNNING ALL PARTS OF THIS SCRIPT IS RECOMMENDED FOR ALL MariaDB
SERVERS IN PRODUCTION USE! PLEASE READ EACH STEP CAREFULLY!

In order to log into MariaDB to secure it, we'll need the current
password for the root user. If you've just installed MariaDB, and
you haven't set the root password yet, the password will be blank,
so you should just press enter here.

Enter current password for root (enter for none):
OK, successfully used password, moving on...

Setting the root password ensures that nobody can log into the MariaDB
root user without the proper authorisation.

Set root password? [Y/n] y
New password:
Re-enter new password:
Password updated successfully!
Reloading privilege tables..
... Success!

By default, a MariaDB installation has an anonymous user, allowing anyone
to log into MariaDB without having to have a user account created for
them. This is intended only for testing, and to make the installation
go a bit smoother. You should remove them before moving into a
production environment.

Remove anonymous users? [Y/n] Y
... Success!

Normally, root should only be allowed to connect from 'localhost'. This
ensures that someone cannot guess at the root password from the network.

Disallow root login remotely? [Y/n] Y
... Success!

By default, MariaDB comes with a database named 'test' that anyone can
access. This is also intended only for testing, and should be removed
before moving into a production environment.

Remove test database and access to it? [Y/n] Y

• Dropping test database...
  ... Success!
• Removing privileges on test database...
  ... Success!

Reloading the privilege tables will ensure that all changes made so far
will take effect immediately.

Reload privilege tables now? [Y/n] Y
... Success!

Cleaning up...

All done! If you've completed all of the above steps, your MariaDB
installation should now be secure.

Thanks for using MariaDB

[stacksofplates]

So I just looked at this like 10 minutes ago and it was fine. I opened it now and the formatting is screwed up. It looks the same as it did on that Ansible write-up I did where the formatting was changing.

[stacksofplates]

I'll try to get a rocket.chat server set up so I can do a write up for it. It looks interesting, and it's built on meteor/electron.

[scottalanmiller]

@johnhooks said:

So I just looked at this like 10 minutes ago and it was fine. I opened it now and the formatting is screwed up. It looks the same as it did on that Ansible write-up I did where the formatting was changing.

Looking okay here, for the moment, at least.

[scottalanmiller]

@johnhooks said:

I'll try to get a rocket.chat server set up so I can do a write up for it. It looks interesting, and it's built on meteor/electron.

Their site is down.

[stacksofplates]

@scottalanmiller said:

@johnhooks said:

I'll try to get a rocket.chat server set up so I can do a write up for it. It looks interesting, and it's built on meteor/electron.

Their site is down.

I tried following their documentation last night and it didn't work out. I'll have to try to find some other people that have set it up.

[Alex Sage]

@rocketchat looks amazing!

[scottalanmiller]

@anonymous said:

@rocketchat looks amazing!

Do you mean you have it up and running and it looks amazing... or the potential for it looks amazing?

[stacksofplates]

Ha well, I just created an account for speak.io yesterday and I just went on the site to link it here and they're shutting down. I was going to say it's an interesting replacement for Skype and others, but never mind.

http://blog.speak.io/epilogue/

[scottalanmiller]

@johnhooks said:

Ha well, I just created an account for speak.io yesterday and I just went on the site to link it here and they're shutting down. I was going to say it's an interesting replacement for Skype and others, but never mind.

You know, I had looked at their site just this morning and thought "neat technology, but I could not see us using it." I feel like lots of people felt the same way.

[stacksofplates]

@scottalanmiller said:

@johnhooks said:

Ha well, I just created an account for speak.io yesterday and I just went on the site to link it here and they're shutting down. I was going to say it's an interesting replacement for Skype and others, but never mind.

You know, I had looked at their site just this morning and thought "neat technology, but I could not see us using it." I feel like lots of people felt the same way.

I saw it linked in the Electron page, so I figured I'd just play around with it. It doesn't look like the cost was worth it, but it seemed to work well.

[scottalanmiller]

@johnhooks said:

@scottalanmiller said:

@johnhooks said:

Ha well, I just created an account for speak.io yesterday and I just went on the site to link it here and they're shutting down. I was going to say it's an interesting replacement for Skype and others, but never mind.

You know, I had looked at their site just this morning and thought "neat technology, but I could not see us using it." I feel like lots of people felt the same way.

I saw it linked in the Electron page, so I figured I'd just play around with it. It doesn't look like the cost was worth it, but it seemed to work well.

That's how I felt at a quick look. It looked like it would be an amazing open source project but it was very expensive and only duplicated functionality that we already have several different ways. Had it been free and open source, well worth looking into. As a paid service, it was of no interest.

[travisdh1]

So I decided to try hooking up a new install of openfire to my domain controller (Zentyal). Turns out you need a more recent version of prototype.js to make it work correctly.

cd /opt/openfire/plugins/admin/webapp/js; mv prototype.js prototype.js.old; wget https://ajax.googleapis.com/ajax/libs/prototype/1.7.1.0/prototype.js

systemctl restart openfire

At that point clear your browser cache if you had started the setup configuration via web browser already, and you should be able to complete the setup using your Active Directory information.

I know, I know, way beyond the article scope, but I figured it would save some of us a little headache.