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
On 4/15/2015 6:52 PM, Les Mikesell wrote:> 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?you sure this had nothing to do with selinux not letting perl running as the http user write there? -- john r pierce, recycling bits in santa cruz
On Wed, Apr 15, 2015 at 9:00 PM, John R Pierce <pierce at hogranch.com> wrote:> On 4/15/2015 6:52 PM, Les Mikesell wrote: >> >> 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? > > > you sure this had nothing to do with selinux not letting perl running as the > http user write there? >No, systemd actually remaps /tmp from apache - and apparently most other daemons - to private directories below /tmp with configs as shipped. The command line tool wrote the file to /tmp as expected. The perl code running under httpd reading what it thought was /tmp was actually looking under /tmp/systemd-private-something. I'm beginning to see why so much of EPEL isn't included in epel7 yet. -- Les Mikesell lesmikesell at gmail.com
On Wed, Apr 15, 2015 at 08:52:16PM -0500, Les Mikesell wrote:> 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 IThat's always difficult, as distributions all have their own quirks. We have some semblance of a standard in the LSB, but it's not strongly adhered to by any distro. For file locations in specific, there is the FHS (see http://www.linuxbase.org/betaspecs/fhs/fhs.html for latest draft), and while I think it could be a little more clear on /tmp, there are no promises of anything other than that /tmp must be available to programs ? and that programs can't count on data there to be preserved. I think it's clear that /var/lib/{something} is a better match. Of course, with some degree of irony, providing a defacto standard base across Linux distributions is, I think, one of the goals of the upstream project ? and, whatever you may think of it, as measured by distribution adoption, that seems to be _more_ successful in practice than any previous standarization effort. So, with an eye to the future, "do what systemd suggests" is, really, not your worst option.> 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?Do exactly what twiki does ? provide a configuration option. -- Matthew Miller <mattdm at fedoraproject.org> Fedora Project Leader