Can''t log in after config

Openfire Openfire Support
1

I’'m using a CentOS 4.4 Linux server. I downloaded the 3.2.2 rpm and installed it. I had no problems with the install and the config went well too. I set it up as simple as possible with the embedded database but I get this error when trying to log in.

HTTP ERROR: 500

INTERNAL_SERVER_ERROR

RequestURI=/index.jsp

Caused by:

java.lang.NullPointerException

at org.jivesoftware.wildfire.filetransfer.proxy.FileTransferProxy.isProxyEnabled(F ileTransferProxy.java:240)

at org.jivesoftware.wildfire.admin.index_jsp._jspService(index_jsp.java:525)

at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97)

at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)

at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:491)

at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.ja va:1074)

at com.opensymphony.module.sitemesh.filter.PageFilter.parsePage(PageFilter.java:11 8)

at com.opensymphony.module.sitemesh.filter.PageFilter.doFilter(PageFilter.java:52)

at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.ja va:1065)

at org.jivesoftware.util.LocaleFilter.doFilter(LocaleFilter.java:65)

at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.ja va:1065)

at org.jivesoftware.util.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingF ilter.java:41)

at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.ja va:1065)

at org.jivesoftware.admin.PluginFilter.doFilter(PluginFilter.java:69)

at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.ja va:1065)

at org.jivesoftware.admin.AuthCheckFilter.doFilter(AuthCheckFilter.java:98)

at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.ja va:1065)

at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:365)

at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:185)

at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)

at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:689)

at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:391)

at org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollect ion.java:146)

at org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:114)

at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)

at org.mortbay.jetty.Server.handle(Server.java:285)

at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:457)

at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.j ava:751)

at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:500)

at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:209)

at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:357)

at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:329)

at org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:475)

Powered by Jetty://

After uninstalling via rpm and deleting the /opt/wildfire directory and installing several more times I still get the same error. Before getting exasperated and wanting to post a very descriptive message expressing my dissatisfaction with the software here I thankfully tried installing it on another CentOS 4.4 machine (a workstation) and it installed fine.

Where do I go from here? I’‘ve searched for this message and only got a couple of hits. What could be wrong. I’‘ve uninstalled all java just to see if there was a conflict and it made not difference. I had jabberd2 installed and made sure that’'s shutdown and even shut down Apache just in case it was conflicting with the web interface to no avail.

Grant

2

WE have another server that’'s configured the same as the first running CentOS 4.4 on it and I tried to install Wildfire on it and got exactly the same results. grr…

Grant

3

Hi,

do you see errors in the log files?

Looking at the source code http://www.igniterealtime.org/fisheye/browse/svn-org/wildfire/trunk/src/java/org /jivesoftware/wildfire/filetransfer/proxy/FileTransferProxy.java?r=6714#l240 it could be a timing issue with “connectionManager” which seems to be “null” instead of initialized.

LG

4

It doesn’‘t like underscores in hostnames. Maybe that’‘s something I was already supposed to know but I’'ve never run into it. We have a lot of machines deployed globally so the hostname is machine_number with the number being of course a number. The servers are servername_number. This makes scripting really easy as hostnames can be handled in an array.

As default the installation configuration screen used our system hostname as it’‘s hostname and died. After getting it installed on one machine I knew it was a config problem. I removed it via rpm -ev and reinstalled again over and over until I found out what was killing it. Underscores in the hostname was what was killing it. It seems to allow dots in the hostname (as it should) but not underscores. Since then I’‘ve looked up hostnames with underscores and come to find out it breaks RFC 1123 & RFC 932. This isn’‘t the only time I’'ve seen hostnames with underscores though…

So for anyone in the future make sure you don’'t have any underscores in your hostnames.

Advice to the Wildfire people, maybe do some sanitizing of the hostname variable and throw up a message saying something to this nature? The code would be small and would allow more people to use it and educate those of us who don’‘t read RFCs in our spare time about proper hostname form. I’‘m a consultant deploying this for a very large client and we were about 5 minutes from moving onto another solution. Price doesn’‘t always matter, usability does. Hopefully it’'s smooth sailing from here on out.

Grant

Message was edited by: gmf

5

Hi Grant,

well, well, well.

One can assume that administrators who set up servers have enough knowledge to know that an underscore is not allowed within a host name. Maybe Gato likes to update the documentation with references to RFC 1123 & RFC 932 regarding the host name.

LG

6

You would think I’‘d know that wouldn’‘t you? This system we’‘re creating doesn’‘t use any form of hostname resolution outside of /etc/hosts so the underscores have never been a problem. I’‘ve personally never used them before because, well you just don’‘t see underscores in hostnames so I never thought about it. It’‘s like the choice of quoting variables in html, here’‘s the proper way thinking toward the future and there’‘s the way that works (just about anything goes). It’'s only when you run into a piece of software that forces the standards do you have a problem and your initial reaction is to blame the software. Putting a note in the docs would help but how many people install software without reading the docs?

A quick if (regex for _) then echo “You can’'t have _ in hostnames” would be great. Even better since the routine would be there it could parse any other characters not allowed too which would be a piece of cake. If this were written in a language I knew anything about I’'d make the patch myself.

Grant

7

You can blame it on my Windows experience… I’‘ve since found others making the same mistake including Google! Anyway I’‘ve found some instances where Windows software would allow underscores and give problems with hyphens. After digging though some RFCs I’'ve found that RFC 952 is much more clear.

  1. A “name” (Net, Host, Gateway, or Domain name) is a text string up

to 24 characters drawn from the alphabet (A-Z), digits (0-9), minus

sign , and period (.). Note that periods are only allowed when

they serve to delimit components of “domain style names”. (See

RFC-921, “Domain Name System Implementation Schedule”, for

background). No blank or space characters are permitted as part of a

name. No distinction is made between upper and lower case. The first

character must be an alpha character. The last character must not be

a minus sign or period. A host which serves as a GATEWAY should have

“-GATEWAY” or “-GW” as part of its name. Hosts which do not serve as

Internet gateways should not use “-GATEWAY” and “-GW” as part of

their names. A host which is a TAC should have “-TAC” as the last

part of its host name, if it is a DoD host. Single character names

or nicknames are not allowed.

So there we have it from the horses mouth.

So I guess the routine would check to see if there were anything but a-Z in the hostname and if there were

it would throw an error. Even though our system will never talk to the outside world using anything but an IP address I will implement a change so all hostnames comply.

Grant

8

Hi,

I did create JM-989 so a developer will add some lines to the documentation or modify the setup routine.

LG

9

Thanks, I was wondering how to do that. We’‘ve only been playing with Wildfire for a few days. The docs are very light but I’'m sure will fumble our way through.