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.
signature.asc
Description: Digital signature
------------------------------------------------------------------------------ WatchGuard Dimension instantly turns raw network data into actionable security intelligence. It gives you real-time visual feedback on key security issues and trends. Skip the complicated setup - simply import a virtual appliance and go from zero to informed in seconds. http://pubads.g.doubleclick.net/gampad/clk?id=123612991&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
