Hello, For what it's worth, we run Tomcat as the tomcat7 user on Ubuntu. I build and deploy DSpace as the tomcat7 user. I log into the server as myself via SSH, then use `sudo su - tomcat7` to become the tomcat7 user. The tomcat7 user must be assigned a login shell for this to work of course, but it does not need a password. Furthermore, SSH access to the machine is limited to specific user accounts. I don't see any issues with this.
Regards, On Wed, Sep 19, 2018 at 8:23 PM <kard...@gmail.com> wrote: > Hi Tim, > > Thanks for the reply! > > Unfortunately, I don't think that would work with the RedHat/CentOS 7 > Tomcat (7) package. I just spun up a fresh centos:7 docker container with > packaged Tomcat to confirm. > > The user is hard-coded into the systemd service file (which could be > modified). > > When Tomcat is run as another user, logging is not persisted in > /var/log/tomcat (unless permissions are changed). It may be necessary to > update the permissions for work and temp as well, I didn't have a way to > quickly test that. > > Years ago we did run Tomcat as DSpace, under RedHat 6 where Tomcat 7 was > provided by EPEL. This worked fine mostly, though we did have an instance > where an unattended Tomcat upgrade broke permissions (which was quickly > resolved, but required manual intervention). > > Jacob > > > > On Wednesday, September 19, 2018 at 11:27:31 AM UTC-5, Tim Donohue wrote: >> >> Hello Jacob, >> >> I'd recommend *not* modifying the "tomcat" user account, and simply >> updating Tomcat to run as the "dspace" user. That's exactly the strategy >> we use on the http://demo.dspace.org site (running Ubuntu 16.04). It >> has worked fine for us, even with "unattended upgrades" enabled. In case >> it's useful, we have publicly shared the Puppet scripts we use for the >> setup of demo.dspace.org. Here's all of the permission changes/tweaks >> we make to Tomcat: >> >> >> https://github.com/DSpace/puppet-dspace/blob/master/manifests/tomcat_instance.pp >> >> In case you don't know Puppet syntax well, here it is in human terms: >> >> 1. Install Tomcat as normal (from apt-get). >> CATALINA_HOME=/usr/share/tomcat7 CATALINA_BASE=/var/lib/tomcat7 >> 2. Override the default <Host name="localhost"> setting, configuring >> it to use the [dspace]/webapps/ location. E.g. <Host name="localhost" >> appBase="/home/dspace/dspace/webapps" unpackWARs="true" autoDeploy="true"> >> 3. Stop Tomcat >> 4. Update the service script to run-as "dspace". This involves >> editing the /etc/default/tomcat7 script and changing >> "TOMCAT7_USER=dspace". NOTE: We leave the TOMCAT7_GROUP=tomcat7 >> 5. Changes the ownership permissions (recursively) on CATALINA_BASE >> to "dspace:tomcat7" (notice again we keep the tomcat7 group, and also >> that >> we do NOT change permissions on CATALINA_HOME) >> >> That's basically it. That Puppet script does some other stuff specific >> to our setup...but, these 5 steps are all you need to setup Tomcat to run >> as a "dspace" user. As noted, we also have Ubuntu's "unattended-upgrades" >> enabled on this server, and have yet to notice it revert our CATALINA_BASE >> back to different ownership. >> >> With these settings in place, you can run all builds as the "dspace" >> user. You'll notice that DSpace itself (see #2) is installed under >> ~dspace/dspace/ (which is in the "dspace" user home directory). That >> directory is owned by "dspace:dspace". >> >> - Tim >> >> On Wed, Sep 19, 2018 at 10:56 AM <kar...@gmail.com> wrote: >> >>> I guess mostly I am uncomfortable modifying a user account that I didn't >>> create (tomcat). I don't know all the ins and outs and permissions granted >>> to that user as part of the tomcat package (in my case from RedHat 7 >>> server). I don't fully know the security implications of letting tomcat >>> login. >>> >>> Because of that, it is awkward to work with DSpace (requiring all those >>> `sudo -u tomcat ...` commands). >>> >>> Until recently I was running DSpace where the DSpace logs and a couple >>> other directories were owned by dspace:tomcat, and this mostly worked well; >>> it was just somewhat painful to maintain. >>> >>> Jacob >>> >>> >>> >>> On Wednesday, September 19, 2018 at 10:41:11 AM UTC-5, helix84 wrote: >>> >>>> In order to run without issues, tomcat has to run as the user who owns >>>> the dspace files, whatever the user is named. >>>> What is it specifically that makes a difference to you in how the user >>>> is named? >>>> >>>> >>>> Regards, >>>> ~~helix84 >>>> >>>> Compulsory reading: DSpace Mailing List Etiquette >>>> https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette >>>> >>>> On Wed, Sep 19, 2018 at 5:34 PM <kar...@gmail.com> wrote: >>>> > >>>> > Thanks for the reply, helix84. >>>> > >>>> > But giving tomcat a password and a login shell has security >>>> implications (which are similar to, but not the same as, having a `dspace` >>>> user own the files). >>>> > >>>> > Jacob >>>> > >>>> > On Wednesday, September 19, 2018 at 10:25:14 AM UTC-5, helix84 wrote: >>>> >> >>>> >> 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 <kar...@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...@googlegroups.com. >>>> >> > To post to this group, send email to dspac...@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...@googlegroups.com. >>>> > To post to this group, send email to dspac...@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...@googlegroups.com. >>> To post to this group, send email to dspac...@googlegroups.com. >>> Visit this group at https://groups.google.com/group/dspace-tech. >>> For more options, visit https://groups.google.com/d/optout. >>> >> -- >> Tim Donohue >> Technical Lead for DSpace & DSpaceDirect >> DuraSpace.org | DSpace.org | DSpaceDirect.org >> > -- > 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. > -- Alan Orth alan.o...@gmail.com https://picturingjordan.com https://englishbulgaria.net https://mjanja.ch "In heaven all the interesting people are missing." ―Friedrich Nietzsche -- 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.
