Thanks for your responses, Mark! I suppose I'm still curious if it is necessary for Tomcat to own DSpace, or if it just needs some combination of read/write/execute permissions.
Admittedly, I'm quite new to Java, so I'm not quite sure how "it all" works. I assume that it's not enough for the webapps to be accessible by Tomcat? The entirety of the "installed" DSpace needs to be accessible to Tomcat, yes? I've been reading the install documentation for DSpace 3.x and (more recently) 4.x, and they both seem to presume that Tomcat was installed manually rather than via a package manager :/. Yum and Apt both install tomcat using a user/group of "tomcat". In the case of apt, I think you might be able 'su' into tomcat, but you can't with the package installed from yum - at least in the case of the Fedora-based Amazon AMI. As far as I can tell, it's impossible to log into that user (even if you are root) without modifying the user in some way. Actually, I take that back. Apparently, " su -s /bin/bash - tomcat" would work. I'm not sure how well that would work in a build/install script, but something to try in the future for sure. I've never played with ACLs, but that sounds like it would work well! I like that concept. I tended to think about them as build/install phases, but didn't realize that the build could be anyone while the install/update should be by Tomcat's owner. I'll definitely have to try out your recommendations! Thanks again for the help! -David -----Original Message----- From: Mark H. Wood [mailto:[email protected]] Sent: Saturday, 1 February 2014 2:20 AM To: [email protected] Subject: Re: [Dspace-tech] DSpace/Tomcat Ownership On Fri, Jan 31, 2014 at 05:25:22PM +1100, David Cook wrote: > I'm just curious as to why DSpace and Tomcat need to be run as the > same user. Because Tomcat needs access to DSpace's files and directories. The simplest way to do that is to have Tomcat own them. Tomcat is the only thing that is "running". DSpace is a web application deployed in the servlet container that Tomcat provides. > I've often set built DSpace using a "dspace" user, then forgotten to > switch ownership to Tomcat, and I've gotten errors when running DSpace > for the first time. Don't do that. Install DSpace as whatever user owns Tomcat. There's no need for a user "dspace" unless Tomcat runs as "dspace". I'm aware that many distro.s set up the 'tomcat' user with /dev/null for a home directory. See below -- by "install" I only mean the final placement of the files, which could be built anywhere. > However, with subsequent builds, when I revert back to "dspace" and > forget to switch back to "tomcat", I don't receive those errors anymore. [Groucho] Don't do that. > I tend to install Tomcat via apt-get or yum so I don't have the > control of installing Tomcat as the DSpace user. This is something that was not recognized in the documentation for some time -- it was assumed that you were manually installing Tomcat etc. from source and had full control of the account used. I hope that we have now fixed that, but the instructions you see will depend on which version you are reading. If you installed Tomcat using your distro's package manager, ignore any mention of the 'dspace' user and use whatever account runs your instance of Tomcat. > Any tips or best practices on this one? (Rather than switching back > and forth between a "builder" user and a "server" user) When I want to install a new version that we've worked up, I log onto the server as me, check out the new version from our local VCS, build, 'su', 'su tomcat', and install. All the installed files will be owned by 'tomcat'. I keep a second terminal window open running as root for things like restarting Tomcat. In my development environment, I make liberal use of ACLs to ensure that my developer persona has sufficient access to my local test Tomcat's directories and Tomcat has sufficient access to what I install. I have a directory ~/dspaces with a default ACL that makes Tomcat an owner of any new DSpace instance I install under it, and $CATALINA_BASE/conf/Catalina/localhost has an ACL that lets me drop Context files into it as me, to be owned by me and readable by Tomcat. BTW I find it helpful to think of DSpace installation in two phases. 'mvn' is the build phase, and can be run as anyone. 'ant' is the install phase and may be best done as Tomcat's owner. -- Mark H. Wood, Lead System Programmer [email protected] Machines should not be friendly. Machines should be obedient. ------------------------------------------------------------------------------ Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk _______________________________________________ DSpace-tech mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dspace-tech List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette
