[Pulp-list] Avoid usage of '/tmp'

[Nick Coghlan]

On 12/08/2011 06:17 AM, Jay Dobies wrote:
> On 12/07/2011 03:11 PM, John Matthews wrote:
>> The issue of Grinder writing some data to /tmp/grinder and referring
>> to it in between runs came up during our SELinux policy rewrite. Dan
>> Walsh suggested we avoid using '/tmp/grinder' and instead switch to
>> '/var/run/grinder'. I wanted to share his blog post highlighting this
>> reason with the team.
>>
>> http://danwalsh.livejournal.com/11467.html
>> <snippet from above>
>> "
>> Daemon developers should follow these rules:
>>
>> /tmp is for users to store their stuff not for daemons or any process
>> that is started in the boot process.
>> If a daemon wants to communicate with a user then he should do it via
>> /var/run/DAEMON.
>> If you have a daemon that wants its temporarily files to survive a
>> reboot. consider using /var/cache/DAEMON
>> "
>>
>> Pulp's BZ to fix this: https://bugzilla.redhat.com/show_bug.cgi?id=761173
>
> What about making a new directory in /var/lib/pulp?
>
> I don't want to break the conventions that Dan's mentioning, but we have
> to think about situations where space on the root partition isn't
> exactly in high availability.
>
> Some of the cloud images we've seen have really small root partitions.
> Some of the providers I've talked to have differences between the root
> volume and the ones they've attached meant to serve Pulp content.
>
> The RHUI installation conventions have been to mount a bunch of space at
> /var/lib/pulp for repos. It'd be nice if we could have all of our space
> requirements captured in that one case v. having to potentially have
> them increase the availability for /var/run/pulp too (not sure the order
> of magnitude of how much data grinder uses as temp space).

Both this and the SELinux compatibility question provide a strong 
rationale for using the Pulp-provided working directory in plugins 
rather than using /tmp directly.

I've created a corresponding BZ for PulpDist as well: 
https://bugzilla.redhat.com/show_bug.cgi?id=761257

Cheers,
Nick.

-- 
Nick Coghlan
Red Hat Engineering Operations, Brisbane