On Wed, Apr 15, 2015 at 5:01 PM, Matthew Miller <mattdm at mattdm.org> wrote:> On Wed, Apr 15, 2015 at 04:15:23PM -0500, Les Mikesell wrote: >> > Why does this directory have to be /tmp rather than a specific >> > directory belonging to twiki? >> Twiki is a perl web application run under apache. It doesn't have its >> own uid. It doesn't 'have' to be anywhere in particular but that is >> the way it was written and thus has very confusing results when trying >> to move it to CentOS 7. Is there some generic approach to fixing this >> kind of breakage (that is, to make it work and not confusing, not to >> say it was broken as designed)? To function as a backup, it >> probably shouldn't default to being in the same directory as the files >> it backs up. > > There are two (sane) options, I think. > > The first, and I think the best, is to configure twiki to share files > in some specific location rather than /tmp. It doesn't have to be the > same directory as the files being backed up ? maybe something under > /var/lib/twiki (or /var/local/twiki). > > If the twiki backup plugin didn't allow this to be configured, I would > argue that it _is_ broken by design. But a quick Google search leads me > to <http://twiki.org/cgi-bin/view/Plugins/BackupRestorePlugin>, which > shows that it is indeed configurable, so I'm just going to call it a > questionable default. :) > > If you want to keep that default, though, the second approach would be > to configure Apache to not use a private namespace, which I don't > recommend because you lose the security benefit. To do that, put > > [Service] > PrivateTmp=false > > in /etc/systemd/system/httpd.service (which may not exist). >Thanks - I can see how those would work once you understand what is broken on the target system and why, but is there a way that programs 'should' be written to run with/without systemd? That just happened to be the first thing I've tried to move over that wasn't already packaged and adapted - I expect to hit many more. -- Les Mikesell lesmikesell at gmail.com
On Wed, Apr 15, 2015 at 05:31:52PM -0500, Les Mikesell wrote:> Thanks - I can see how those would work once you understand what is > broken on the target system and why, but is there a way that programs > 'should' be written to run with/without systemd? That just happened > to be the first thing I've tried to move over that wasn't already > packaged and adapted - I expect to hit many more.This isn't really a systemd thing. It's a standard Linux kernel feature, which could also be enabled with (for example) pam_namespace. Systemd happens to make it easy, so we started enabling it for services which would benefit on Fedora, and that was inherited into RHEL and CentOS. See the change page for this <https://fedoraproject.org/wiki/Features/ServicesPrivateTmp>. If you're really interested in learning every possible thing about systemd, you could of course go through the author's blog post series "systemd for administrators" ? see <http://0pointer.de/blog/projects/systemd-for-admins-1.html>. It's pretty useful. Or, if you're mostly interested in packaging something up to run in a nice way in the Fedora/RHEL/CentOS-ecosystem, the Fedora packaging guidelines for systemd might help; those are at <http://fedoraproject.org/wiki/Packaging:Systemd>. I notice that private temp dirs aren't mentioned there (not a bad thing to add, really) but you'll find some other advice that might be helpful. (Take a look at private devices and networking for a related issue.) -- Matthew Miller <mattdm at fedoraproject.org> Fedora Project Leader
On Wed, Apr 15, 2015 at 6:48 PM, Matthew Miller <mattdm at mattdm.org> wrote:> On Wed, Apr 15, 2015 at 05:31:52PM -0500, Les Mikesell wrote: >> Thanks - I can see how those would work once you understand what is >> broken on the target system and why, but is there a way that programs >> 'should' be written to run with/without systemd? That just happened >> to be the first thing I've tried to move over that wasn't already >> packaged and adapted - I expect to hit many more. > > This isn't really a systemd thing. It's a standard Linux kernel > feature, which could also be enabled with (for example) pam_namespace. > Systemd happens to make it easy, so we started enabling it for services > which would benefit on Fedora, and that was inherited into RHEL and > CentOS. See the change page for this > <https://fedoraproject.org/wiki/Features/ServicesPrivateTmp>. > > If you're really interested in learning every possible thing about > systemd, you could of course go through the author's blog post series > "systemd for administrators" ? see > <http://0pointer.de/blog/projects/systemd-for-admins-1.html>. It's > pretty useful. > > Or, if you're mostly interested in packaging something up to run in a > nice way in the Fedora/RHEL/CentOS-ecosystem, the Fedora packaging > guidelines for systemd might help; those are at > <http://fedoraproject.org/wiki/Packaging:Systemd>. I notice that > private temp dirs aren't mentioned there (not a bad thing to add, > really) but you'll find some other advice that might be helpful. (Take > a look at private devices and networking for a related issue.)Mostly I'm interested in avoiding surprises and having code that isn't married to the weirdness of any particular version of any particular distribution. And I found this to be pretty surprising, given that I could see the file in /tmp and could read the code that was looking there. So, from the point of view of writing portable code, how should something handle this to run on any unix-like system? -- Les Mikesell lesmikesell at gmail.com