I've just completed a fresh install of DSpace 1.5.2 running on Redhat
Enterprise 5.4 64-bit. I used the default RHEL packages for all of
DSpace's requirements except for Maven which I manually downloaded and
installed.

 

I am using a local account called 'dspace' for building and deploying
DSpace and Tomcat is running as 'tomcat'. I've added 'tomcat' to the
'dspace' group and made sure my DSpace installation directory has at
least 770 (rwxrwx---) permissions so dspace and tomcat can access the
files. This appears to be working just fine. The only problem I'm
running into is getting dspace access to cocoon.log. The log file is
created by Tomcat, the permissions are 644 (rw-r--r--) and it's owned by
tomcat:tomcat. Whenever any of the dspace cronjobs are triggered they
fail because they can't read/write to cocoon.log.

 

I've tried running Tomcat as 'dspace' which fails thanks to the fact I
installed Tomcat using yum instead of downloading a copy and
installing/running it as dspace from the get go. To make security
updates and management easier I would like to keep my Tomcat
installation I have anyway. My current work around for this problem is
the following cronjobs run by root before any dspace cronjobs run:

 

#Fixes permissions on DSpace logs (Currently a work around)

0 11 * * * chmod -R 664 /data/dspace/log

1 11 * * * chown -R dspace:dspace /data/dspace/log

 

These crons are run before any of dspace's and hopefully after tomcat
rotates its log for the night.

 

I'm looking for a better solution then this. So far what I've come up
with is figuring out how to change the default permissions tomcat uses
to create the cocoon.log file so the permissions are 664 (rw-rw-r--)
instead of 644 (rw-r--r--). Then I could set the group sticky bit on the
log directory so files created in the log directory would be owned by
tomcat:dspace which would solve the problem completely. Does anyone know
how to tweak the default permissions used for creating the cocoon.log
file? Should I submit a bug for this?

 

Anyone else have a better solution? I'm all ears.

------------------------------------------------------------------------------
Join us December 9, 2009 for the Red Hat Virtual Experience,
a free event focused on virtualization and cloud computing. 
Attend in-depth sessions from your desk. Your couch. Anywhere.
http://p.sf.net/sfu/redhat-sfdev2dev
_______________________________________________
DSpace-tech mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-tech

Reply via email to