Here is a sample, for an instanace called "esme": -rw-r----- 1 root esme-koha 147K Jan 11 12:27 esme-2012-01-11.sql.gz -rw------- 1 root root 153K Jan 11 12:27 esme-2012-01-11.tar.gz The database file gets this treatment: chown "root:$name-koha" "$dbdump" chmod g+r "$dbdump" while the other file does not get anything similar.
It's semi-deliberate. Our Koha deployments have a feature that allows the superlibrarian to download the .sql.gz file[0], so it needs to be readable by the webserver. However, there is no need of this for the .tar.gz as it will be server config dependent, or derived data. So it's not made readable by the webserver. [0] One day I plan to upstream this, but it's fiddly as it depends on the setup of the server. I might do it as package-specific patches maybe.
(In reply to comment #1) Semi-deliberate, eh? ;-) I'm not sure what makes sense if we try to generalize it, though.... > [0] One day I plan to upstream this, but it's fiddly as it depends on the setup > of the server. I might do it as package-specific patches maybe. How about having it governed by a syspref that defaults to "off" but can be set to "on" by koha-create (or a wrapper script for koha-create)?
Setting sysprefs with koha-create is tricky, as it may not be creating the DB. However, the package patches could alter the default SQL for sysprefs.
Actually, additional to this, pains must be taken to avoid it being accessible by the webserver, as there may be sensitive config and log related material in there.