As you noticed, if you're using packaged tomcat, it's easier to use the tomcat user created by the tomcat package as the owner of all dspace files. However, you don't have to sudo every single command. You can either:
A) run a shell as the tomcat user like this: sudo -u tomcat -i B) or you can allow login for that user by setting its password: sudo passwd tomcat and making sure the user has a valid shell: sudo usermod --shell /bin/bash tomcat In the later case you would log in normally as the tomcat user with the password you set. Regards, ~~helix84 Compulsory reading: DSpace Mailing List Etiquette https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette On Wed, Sep 19, 2018 at 5:15 PM <kard...@gmail.com> wrote: > > DSpace installation instructions suggest creating a `dspace` user account to > own the DSpace installation, while current advice (1, 2, 3) suggests having > `tomcat` be the owner of these files (though all of these links are several > years old at this point). > > Neither is ideal. > > It is relatively easy to set up Tomcat to run as a different user (I've used > the instructions at > https://askubuntu.com/questions/371809/run-tomcat7-as-tomcat7-or-any-other-user/527826#527826 > before), but the permission changes required are reverted whenever Tomcat is > updated by one's package manager. > > It is also relatively easy to just assign ownership of the dspace > installation files to Tomcat, but on some Linux distros `tomcat` is a nologin > user, which makes running mvn, ant, and bin/dspace commands awkward (`sudo -u > tomcat ...`). > > It is also possible to change group ownership settings on some DSpace dirs > (log, assetstore, etc.) so that tomcat can write to them, but is difficult to > keep these up to date, and the Solr index is especially tricky > permission-wise. > > It would be really nice if both the DSpace installation files and the files > generated at runtime (logs, etc.) had permissions that were conducive to > group-based reading/writing. > > Is this something others are interested in? What is the current consensus on > this issue? > > I'm currently using the following setup (with DSpace 5.9): > > Tomcat is run as tomcat. DSpace (both source and installation) is owned by > tomcat. > > To build, I have to do `sudo -u tomcat /full/path/to/maven package`, then > `sudo -u tomcat /full/path/to/ant update -f > path/to/dspace/target/dspace-installer/build.xml`. > > Any DSpace command (e.g., `index-discovery` or `filter-media`), I run as > `sudo -u tomcat path/to/dspace/bin/dspace ...`. > > Thanks, > > Jacob > > -- > All messages to this mailing list should adhere to the DuraSpace Code of > Conduct: https://duraspace.org/about/policies/code-of-conduct/ > --- > You received this message because you are subscribed to the Google Groups > "DSpace Technical Support" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to dspace-tech+unsubscr...@googlegroups.com. > To post to this group, send email to dspace-tech@googlegroups.com. > Visit this group at https://groups.google.com/group/dspace-tech. > For more options, visit https://groups.google.com/d/optout. -- All messages to this mailing list should adhere to the DuraSpace Code of Conduct: https://duraspace.org/about/policies/code-of-conduct/ --- You received this message because you are subscribed to the Google Groups "DSpace Technical Support" group. To unsubscribe from this group and stop receiving emails from it, send an email to dspace-tech+unsubscr...@googlegroups.com. To post to this group, send email to dspace-tech@googlegroups.com. Visit this group at https://groups.google.com/group/dspace-tech. For more options, visit https://groups.google.com/d/optout.
