This week's book giveaway is in the General Computing forum.
We're giving away four copies of Learning Regular Expressions and have Ben Forta on-line!
See this thread for details.
Win a copy of Learning Regular Expressions this week in the General Computing forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Liutauras Vilda
  • Campbell Ritchie
  • Tim Cooke
  • Bear Bibeault
  • Devaka Cooray
Sheriffs:
  • Jeanne Boyarsky
  • Knute Snortum
  • Junilu Lacar
Saloon Keepers:
  • Tim Moores
  • Ganesh Patekar
  • Stephan van Hulst
  • Pete Letkeman
  • Carey Brown
Bartenders:
  • Tim Holloway
  • Ron McLeod
  • Vijitha Kumara

JBoss 4.0.1 - Failed to load users/passwords/role files: Properties file users.properties not found  RSS feed

 
Ranch Hand
Posts: 650
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello,

We have an old installation of JBoss (4.0.1) on Windows for which we are
trying to provide support. I hope we can still get some help for this version.

We are trying to secure the two console applications (jmx-console and
web-console) using the instructions provided in the JBoss Administration
and Development guide. We're having the same problem with both the
jmx-console and web-console. However, I will refer to the jmx-console
within this help request.

To secure the jmx-console, I performed the following steps:

  • Uncomment the security-domain entry in the jboss-web.xml file
  • Uncomment the security-constraint entry in the web.xml file


  • Both files are in jboss/server/default/deploy/jmx-console.war/WEB-INF.

    In our test environment, this works and I am prompted for the login and
    password when attempting to access the jmx-console. In the customer's
    production environment, the login fails and we see the following error in
    the server.log file:



    Why is it looking for a file named "users.properties"? The file name
    configured in the login-config.xml file is "jmx-console-users.properties".

    The file "jmx-console-users.properties" (as well as the roles file) exist
    in the WEB-INF/classes directory and the user the JBoss application server
    is running as has read access (the application service is running as a
    system service with the Run As set to a specific user in the Windows
    domain).

    Note that in my test environment (which works as expected), I tried moving
    the jmx-console-users.properties file out of the way, and received a different
    error (javax.security.auth.login.LoginException: Missing users.properties file)
    so I don't think the problem is that the jmx-console can't find the properties
    file(s).

    I think the customer is not sophisticated enough to make changes to the
    JBoss configuration files, but perhaps something got corrupted along the
    way? I just don't know what to look for.

    I turned on some additional tracing via log4j.xml, and found the following
    entries in the server.log file:



    Does this tell us at all what might be wrong?

     
    author
    Bartender
    Posts: 5856
    7
    Android Eclipse IDE Ubuntu
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Mark, welcome to Java Ranch!

    Here is what I would do.

    First, I would ascertain that the user made the exact same changes I made - check the web.xml, jboss-web.xml file, and make sure no changes in login-config.xml.

    Second, I would have them temporarily run JBoss AS from a command line (not as a service). If this works (login to jmx-console works), then there is some issue with the service configuration or the user under which the service is running. Perhaps if you turn on file access logging in Windows for the conf direcotory and its subdirectories then you might see something in the Windows security logs. Another possibility is to use Process Monitor from sysinternals and monitor what it see for file access.

    If none of this yields any help, I would get the JBoss AS source and add some debugging code to security/src/main/org/jboss/security/auth/spi/UsersRolesLoginModule.java, specifically to print out what it thought it was opening.

    [rant]This problem illustrates one of my pet peeves which is Java developers failing to tell you exactly what data they were using when something failed. Having UsersRolesLoginModule include the full path name for the file in question as part of the error message would have made debugging this issue much simpler.[/rant]

    Digging through the source (I'm looking at 4.0.5, hope that 4.0.1 is not that different), there is a utility class that takes two properties file names - a default and a given one, so it appears that the error message for the IOException is based on the default file, whcih is users.properties. But I noticed that if you turn on trace logging the Util class will tell you which file it is attempting to open. So add this to server/xxx/conf/log4j.xml:



    you should then see which properties files are loaded, and the users and roles loaded.
     
    Mark E Hansen
    Ranch Hand
    Posts: 650
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Peter Johnson wrote:Mark, welcome to Java Ranch!

    Here is what I would do.

    First, I would ascertain that the user made the exact same changes I made - check the web.xml, jboss-web.xml file, and make sure no changes in login-config.xml.



    Actually, the customer provides me with Remote Access (using GoTo Meeting, similar to WebEx), so I edited the files personally. This is why I say that I don't believe the customer is editing the files - they've never had a reason to go in there any do anything (not that they haven't, it's just not SOP for them). I have looked at the files, and the changes all appear to be correct.

    Peter Johnson wrote:Second, I would have them temporarily run JBoss AS from a command line (not as a service). If this works (login to jmx-console works), then there is some issue with the service configuration or the user under which the service is running. Perhaps if you turn on file access logging in Windows for the conf direcotory and its subdirectories then you might see something in the Windows security logs. Another possibility is to use Process Monitor from sysinternals and monitor what it see for file access.



    I will try running from the command-line. The problem is that the application is expected to be up 24x7, so it's difficult to get any time where we can play with it. I will suggest this to the customer and let them decide when it would be best.

    I'm not very familiar with the other tools, so I'll have to look into those.

    Peter Johnson wrote:If none of this yields any help, I would get the JBoss AS source and add some debugging code to security/src/main/org/jboss/security/auth/spi/UsersRolesLoginModule.java, specifically to print out what it thought it was opening.

    [rant]This problem illustrates one of my pet peeves which is Java developers failing to tell you exactly what data they were using when something failed. Having UsersRolesLoginModule include the full path name for the file in question as part of the error message would have made debugging this issue much simpler.[/rant]

    Digging through the source (I'm looking at 4.0.5, hope that 4.0.1 is not that different), there is a utility class that takes two properties file names - a default and a given one, so it appears that the error message for the IOException is based on the default file, whcih is users.properties. But I noticed that if you turn on trace logging the Util class will tell you which file it is attempting to open. So add this to server/xxx/conf/log4j.xml:



    You should then see which properties files are loaded, and the users and roles loaded.



    Actually, I had already added that as part of the 'additional tracing' I mentioned in my OP. When I added that to my local instance, I see lots of great tracing as you mention. However, at the customer site, I don't. However, I do see lots of ClassNotFoundException, which look like this:



    I don't know if these are normal, but I don't see them in my testing environment.

    I still think something's wrong with the customer's environment. I'm trying to get a copy of it here so I can play with it locally. If it is a corrupted file, I should be able to reproduce the problem locally.

    Thanks again,


     
    Peter Johnson
    author
    Bartender
    Posts: 5856
    7
    Android Eclipse IDE Ubuntu
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    You posted more catalina log messages - please note that the log I suggested that you turn on is "org.jboss.security.auth.spi". This should give you log entries like this:

     
    Mark E Hansen
    Ranch Hand
    Posts: 650
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Thanks for your continued help, Peter. Actually, these are the tracing entries I have set up:



    As you can see, "org.jboss.security" is already there, but there were no tracing messages from any of those classes. I guess I'll have to try it again the next time the customer allows me RDP access to their system (this is hard to get due to the live nature of their application).

    I got a copy of the customer's JBoss environment and ran it locally, but did not see the problem (I was hoping there was a corrupted/improperly modified file in the customer's release).

    I think the next step is to run the customer's application server from the command line (using the JBoss run.bat script), just to see if the problem is permissions related (it normally runs as a system service configured to Rus-As a specific Windows domain user). Of course, this has to wait until the customer can schedule some 'down time'.

    Thanks again for all your help.
     
    Mark E Hansen
    Ranch Hand
    Posts: 650
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Well, the customer just told me that they restarted their JBoss application server, and the security configuration is now working as expected. First, I didn't have to restart the application server to get the security changes to take effect. Also, the customer told me they had already restarted the application server and it didn't help.

    Anyway, since it is now working, there is no need to look into the tracing issues.

    Thanks for all the help!
     
    • Post Reply Bookmark Topic Watch Topic
    • New Topic
    Boost this thread!