Permissions for /var/spool/koha/instance and possible path changes
Hi all, I was just reviewing the Filesystem Hierarchy Standard, and it's led me to think that the package backups should be written to /var/lib/koha rather than /var/spool/koha. Compare http://www.pathname.com/fhs/2.2/fhs-5.8.html and http://www.pathname.com/fhs/2.2/fhs-5.14.html I say this because I want to make use of /var/spool/koha/instance/X to store data for later processing, but notice that /var/spool/koha/instance can only be written to by root, and thus is inaccessible to the Koha user. So I figure that we should make /var/spool/koha/instance owned by the Koha user and just have backups owned by root like usual. That would solve the issue. But on top of that. I'm wondering if we should be using /var/lib/koha/instance/backups for storing the SQL and config backups. I'm open to other ideas, but backups don't really seem like spooled data to me. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Office: 02 9212 0899 Direct: 02 8005 0595
opt is nice, http://www.pathname.com/fhs/2.2/fhs-3.12.html code in /opt/koha and data in /var/opt/koha We've been using this pattern at the place I just left (not for Koha but other things) and it makes it very easy and (for us at least was--your mileage will vary) intuitive. -- side note-- /var/opt instead of /opt/var allows you to keep a var-like disk management strategy for all of /var without having to make it a special case. -reed On 13 July 2016 at 13:58, David Cook <dcook@prosentient.com.au> wrote:
Hi all,
I was just reviewing the Filesystem Hierarchy Standard, and it’s led me to think that the package backups should be written to /var/lib/koha rather than /var/spool/koha.
Compare http://www.pathname.com/fhs/2.2/fhs-5.8.html and http://www.pathname.com/fhs/2.2/fhs-5.14.html
I say this because I want to make use of /var/spool/koha/instance/X to store data for later processing, but notice that /var/spool/koha/instance can only be written to by root, and thus is inaccessible to the Koha user.
So I figure that we should make /var/spool/koha/instance owned by the Koha user and just have backups owned by root like usual. That would solve the issue.
But on top of that… I’m wondering if we should be using /var/lib/koha/instance/backups for storing the SQL and config backups. I’m open to other ideas, but backups don’t really seem like spooled data to me.
David Cook
Systems Librarian
Prosentient Systems
72/330 Wattle St
Ultimo, NSW 2007
Office: 02 9212 0899
Direct: 02 8005 0595
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
That’s an option for folk doing tarball installs, but I’m thinking for the Debian packages, which already have a set way of doing things (like code in /usr/share/koha, etc). To be honest, I’ve been thinking a bit about making RPM packages for Koha and thinking about where I’d put all the files… I’d probably want to emulate the Debian layout as much as possible to reuse scripts with hard-coded values. Of course, I probably won’t make an official RPM for Koha since managing the Perl dependencies on a non-Debian system is impossible using the distro’s package manager alone… David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Office: 02 9212 0899 Direct: 02 8005 0595 From: Reed Wade [mailto:reed@typist.geek.nz] Sent: Wednesday, 13 July 2016 12:09 PM To: David Cook <dcook@prosentient.com.au> Cc: Koha Devel <koha-devel@lists.koha-community.org> Subject: Re: [Koha-devel] Permissions for /var/spool/koha/instance and possible path changes opt is nice, http://www.pathname.com/fhs/2.2/fhs-3.12.html code in /opt/koha and data in /var/opt/koha We've been using this pattern at the place I just left (not for Koha but other things) and it makes it very easy and (for us at least was--your mileage will vary) intuitive. -- side note-- /var/opt instead of /opt/var allows you to keep a var-like disk management strategy for all of /var without having to make it a special case. -reed On 13 July 2016 at 13:58, David Cook <dcook@prosentient.com.au <mailto:dcook@prosentient.com.au> > wrote: Hi all, I was just reviewing the Filesystem Hierarchy Standard, and it’s led me to think that the package backups should be written to /var/lib/koha rather than /var/spool/koha. Compare http://www.pathname.com/fhs/2.2/fhs-5.8.html and http://www.pathname.com/fhs/2.2/fhs-5.14.html I say this because I want to make use of /var/spool/koha/instance/X to store data for later processing, but notice that /var/spool/koha/instance can only be written to by root, and thus is inaccessible to the Koha user. So I figure that we should make /var/spool/koha/instance owned by the Koha user and just have backups owned by root like usual. That would solve the issue. But on top of that… I’m wondering if we should be using /var/lib/koha/instance/backups for storing the SQL and config backups. I’m open to other ideas, but backups don’t really seem like spooled data to me. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Office: 02 9212 0899 Direct: 02 8005 0595 _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org <mailto:Koha-devel@lists.koha-community.org> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
P.S. In general, I quite like /opt/X for code. I’ve been working more on Redhat lately, and I’ve noticed that Redhat uses /opt for their Redhat Software Collection packages. Not sure how common it is to use in the packaging world though. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Office: 02 9212 0899 Direct: 02 8005 0595 From: Reed Wade [mailto:reed@typist.geek.nz] Sent: Wednesday, 13 July 2016 12:09 PM To: David Cook <dcook@prosentient.com.au> Cc: Koha Devel <koha-devel@lists.koha-community.org> Subject: Re: [Koha-devel] Permissions for /var/spool/koha/instance and possible path changes opt is nice, http://www.pathname.com/fhs/2.2/fhs-3.12.html code in /opt/koha and data in /var/opt/koha We've been using this pattern at the place I just left (not for Koha but other things) and it makes it very easy and (for us at least was--your mileage will vary) intuitive. -- side note-- /var/opt instead of /opt/var allows you to keep a var-like disk management strategy for all of /var without having to make it a special case. -reed On 13 July 2016 at 13:58, David Cook <dcook@prosentient.com.au <mailto:dcook@prosentient.com.au> > wrote: Hi all, I was just reviewing the Filesystem Hierarchy Standard, and it’s led me to think that the package backups should be written to /var/lib/koha rather than /var/spool/koha. Compare http://www.pathname.com/fhs/2.2/fhs-5.8.html and http://www.pathname.com/fhs/2.2/fhs-5.14.html I say this because I want to make use of /var/spool/koha/instance/X to store data for later processing, but notice that /var/spool/koha/instance can only be written to by root, and thus is inaccessible to the Koha user. So I figure that we should make /var/spool/koha/instance owned by the Koha user and just have backups owned by root like usual. That would solve the issue. But on top of that… I’m wondering if we should be using /var/lib/koha/instance/backups for storing the SQL and config backups. I’m open to other ideas, but backups don’t really seem like spooled data to me. David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Office: 02 9212 0899 Direct: 02 8005 0595 _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org <mailto:Koha-devel@lists.koha-community.org> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
participants (2)
-
David Cook -
Reed Wade