I accepted the default name for the host that was pulled from the system info and used the internal database, and now I cannot login to the admin interface after completing the setup.
Is there a way to roll back the setup so I can start over or something? I know I’m entering the email address and password correctly that I provided.
By the way, This is for an install of the current version of Openfire (3.6.4) on a CentOs 5.3 VPS machine, with 384MBytes of dedicated RAM and 1024MBytes of burstable RAM.
There’s some background here that I should reference too. I installed the 3.6.4 RPM, as it was recommended, but there were still issues I had to address before I could get the server running.
1.) In /etc/sysconfig/openfire, I had to set: JAVA_HOME=/opt/openfire/jre (The system was unable to locate the Java Runtime Environment)
2.) Also, in /etc/sysconfig/openfire, I had to set: OPENFIRE_OPTS="-Xms256m -Xmx512m" (Openfire would not start w/o these or similiar parameters - YMMV.
Once I had the server running and opened TCP port 9090 on the firewall, I went to http://fqdn:9090 and ran setup. Everything went well, but upon attempting to login once the initial setup had been completed, I could not. I searched around for a long time, and apparently, there is a really prominent bug in Openfire version 3.6.4 (that is supposed to have been taken care of in the 3.6.5 candidates) whereby the system does not let you log in at all, whatsoever.
I read several threads, most dealing with MySQL, but my particular install went with the default database, which should be fine with less than 25 or perhaps even 100 concurent users. Eventually, I found this thread: http://www.igniterealtime.org/community/message/191525#191525
Basically, what you need to do is:
1.) Stop the Openfire daemon (/etc/rc.d/init.d/openfire stop)
2.) Edit /opt/openfire/conf/openfire.xml by adding the following, just after the tag:
admin3.) Restart the daemon (/etc/rc.d/init.d/openfire start), and log in as “admin”, using the password you provided along with the email you had originally specified as the login userid.
I find it a bit frustating, that such a prevalent bug was actually documented as a possible issue in the installation docs, as something that should have taken ten minutes to fire up and configure took a whole day of wasted time, that many, many, other people have had to deal with already.
Regardless, it’s up and running now and I’m off to configuring the server and testing. Hopefully, I won’t be having any further issues that should have been documented as common issues that might arise during installation and setup.
I hope that my wrestling match and discovery of the solutions above help out the next few people who comes along, wondering whether they had mistpyed their password twice LOL!
I’m marking this thread as solved now. Gee, I wonder If I can give myself the points for this one
Kindest regards,
Bradley.
To Start Openfire 3.6.4 daemon on CentOs 5.3
edit /etc/sysconfig/openfire and set options for the location of JRE included w/the RPM and min/max memory alloc for Java to use.
Post install: enable admin user to actually login
edit /opt/openfire/conf/openfire.xml to fix broken distribution of Openfire version 3.6.4
Thnx man, it really helped me out
Hey I don’t know why something as straight-forward and critical to even starting up Openfire isn’t well documented in steps on this site - especially after all this time, and so many people that have come across this issue on a regular basis; but I am certainly glad to have helped and made a difference for you and all the others who have stuggled w/this issue
You’re very welcome Alejandro!
Kindest regards,
Bradley
.