Using Ubuntu 12.04 and Sun Java (so installed Java and Tomcat by hand) - this was required because another app requires the Sun Java. Did NOT do this with the default Ubuntu installer. Tomcat is installed in /usr/local/apache-tomcat-7.0.47 Java is the latest from Oracle-Sun. The following is the problem. 1. In server.xml the <Resource name="UserDatabase" auth="Container" type="org.apache.catalina.UserDatabase" description="User database that can be updated and saved" factory="org.apache.catalina.users.MemoryUserDatabaseFactory" pathname="conf/tomcat-users.xml" /> - had to be changed to - <Resource name="UserDatabase" auth="Container" type="org.apache.catalina.UserDatabase" description="User database that can be updated and saved" factory="org.apache.catalina.users.MemoryUserDatabaseFactory" pathname="/usr/local/apache-tomcat-7.0.47/conf/tomcat-users.xml" /> Where a softlink was used ( CATALINA_HOME=/usr/local/tomcat ) and tomcat is the softlink to /usr/local/apache-tomcat-7.0.47 - giving this line pathname="/usr/local/apache-tomcat-7.0.47/conf/tomcat-users.xml" it also failed. The failure is simply a repetition of the request for authentication. Nothing actually wrong with that part of the process. I am curious what sort of debugging might enable a check of the login processing itself as enabling debug down to "fine" still left me with no information that the file was not being found. This was discovered by trial and educated guesswork. There is no indication in the doc that it should be looked at. A wide range of useless information is out there on the web now, as a lot of people have this problem in some form. My tomcat-users.xml (when it finally worked) looks like this: <role rolename="manager"/> <role rolename="manager-gui"/> <role rolename="admin-gui"/> <role rolename="admin-script"/> <role rolename="manager-script"/> <role rolename="manager-xml"/> <role rolename="manager-status"/> <role rolename="tomcat"/> <role rolename="role1"/> <user username="tomcat" password="tomcat" roles="tomcat"/> <user username="both" password="tomcat" roles="tomcat,role1"/> <user username="role1" password="tomcat" roles="role1"/> <user username="admin" password="tomcat" roles="tomcat,manager,manager-gui,manager-status,manager-xml,manager-script,admin-gui,admin-script"/> I have no doubt that a lot of that can be pruned away. The process in the manual, no matter how carefully followed, does not result in a working login for the manager. There may be something more to this. I currently have started tomcat as "root" which troubles me... but I haven't gotten to the security doc yet and there is no discussion I've seen that says that manager won't work if you start as "root" either. respectfully BJ
As I expected, using the documented roles only does work properly. <role rolename="manager-gui"/> <role rolename="manager-script"/> <role rolename="manager-xml"/> <role rolename="manager-status"/> <role rolename="tomcat"/> <role rolename="role1"/> <user username="tomcat" password="tomcat" roles="tomcat"/> <user username="both" password="tomcat" roles="tomcat,role1"/> <user username="role1" password="tomcat" roles="role1"/> <user username="admin" password="tomcat" roles="manager-gui,manager-status"/> The issue is solely with the ability to access the file in the first instance, with the pathname in server.xml not being correct in some way. This is almost sure to be linux version, Java version, user or shell dependent, as it would not have been "incorrect" as written. The fact that it did not follow links surprises and suggests that it has to do with the identity starting tomcat. If root it may not behave... but as an ordinary user it did not start. Some sort of discussion of this (if it is the case) would be a useful hint to someone looking at the document but not able to reach the manager page. respectfully BJ
(In reply to BJ Chippindale from comment #1) > > 1. In server.xml the > > <Resource name="UserDatabase" auth="Container" > type="org.apache.catalina.UserDatabase" > description="User database that can be updated and saved" > factory="org.apache.catalina.users.MemoryUserDatabaseFactory" > pathname="conf/tomcat-users.xml" /> > > - had to be changed to - > > <Resource name="UserDatabase" auth="Container" > type="org.apache.catalina.UserDatabase" > description="User database that can be updated and saved" > factory="org.apache.catalina.users.MemoryUserDatabaseFactory" > > pathname="/usr/local/apache-tomcat-7.0.47/conf/tomcat-users.xml" /> > There is no need for such a change. When the value of the pathname attribute is a relative path, it is interpreted as relative to ${catalina.base}. The code is in org.apache.catalina.users.MemoryUserDatabase#open(). I am keeping this issue open, as I think the open() method may be improved to log a message when the file is missing. It may be a warning if(this.readonly==true) and an info message otherwise. Currently it just returns silently. > > A wide range of useless information is out there on the web now, http://tomcat.apache.org/findhelp.html http://tomcat.apache.org/lists.html#tomcat-users > If root it may not behave... but as an ordinary user it did not start. > A tip in advance: Do not forget to apply "chown" to all log and temporary files that were created when you started Tomcat as root. Those are in $CATALINA_BASE/logs and $CATALINA_BASE/work. If those are not accessible, things will go wrong. And if log files are not writable, you will get no logging. If you have further questions, ask on the mailing list.
I logged it as an error since failing to find the file is an issue that really needs to be fixed but is not fatal.
Gentlemen I know you may THINK I made a mistake here, but in the configuration I listed here the execution did not follow the $CATALINA_BASE with the softlink when starting as root. There are other configurations I have not checked and do not now care about as I have other problems of my own to fix. This is/was a sideshow, and it is quite certainly minor as I noted, but there is room for improvement in the document, not the software. It needs to give some further clues, either a link to a separate section about what to look at when things go wrong or a brief paragraph outlining the places to go looking. The problem is that the documentation which does NOT help find a problem of this nature nor provide any indications. I followed the instructions QUITE exactly, and varied them rationally more than a dozen times before isolating this path issue. This wasted a large amount of very valuable time and THAT is what good documents can avoid. I note that I chown'd everything in the process. I checked the simple things. Everything WAS accessible. Logs were being written. I followed the manual. The fact that this file isn't discovered on an attempted manager login does not appear at "fine". Had I not worked it out prior I would have tried "all" and waded through the results but neither process is appropriate to something that, by all the documentation will tell me, "just works". Very few packages are so robust as they cannot be started in a configuration that is ever so subtly wrong that they do NOT "just work". Documentation exists so that those of us starting without knowledge of how it works can learn how it does AND figure out why it did not when it doesn't. You provided part 1 quite admirably but part 2 wants some work. Not much. Probably a couple of hours of a couple of people's time (one has to check the other). More if the section on what to look for when it doesn't work doesn't actually exist in any form, but I have no doubt that it does... somewhere. I won't argue this should be re-opened, marked unresolved or anything else. I personally do not care what you do as I have fulfilled MY responsibilities with respect to this process. respectfully BJ Chippindale