Have an option to use tmpfs for /tmp in securetmp script
Many scripts use mktemp and depend on the IOPS capabilities of the filesystem for performance.
noted that a few scripts of ours perform poorly only on our cPanel
servers. We've identified the difference being that we use tmpfs on our
/tmp folder on all our non-cPanel servers.
securetmp script sets up a loop device for the /tmp and /var/tmp
mountpoints. /tmp is set up as a loop device in /usr/tmpDSK
/var/tmp is set up as a bind mount on /tmp directly
Other systems - Consensus:
When searching online for the consenus on how these folders should be treated, I find mostly the following:
/tmp should be cleared on each boot and, if the server has high uptime, old/stale content should be removed
should *not* be cleared on each boot and, if the server has high
uptime, old/stale content should be removed - but not as aggressively as
Systemd's defaults (relevant as a baseline) appear to be:
/tmp is cleared on boot and, each day, anything older than 10 days is deleted
/var/tmp is *not* cleared on boot and, each day, anything older than 30 days is deleted
It stands to reason then that having /var/tmp be a bindmount to /tmp doesn't make much sense - by doing so, the two folders cannot be treated differently.
the securetmp script bypasses our wish to have the /tmp folder use
tmpfs - the reason we noticed this issue. We're happy with /var/tmp
being on physical disk however.
A workaround to
assist in "fixing" the situation is mentioned here:
rather than disabling the feature (as having a standardised security
feature is a good thing), we would prefer to have the script updated to
be able to provide tmpfs.
1. Allow different standardised behaviour for /tmp and /var/tmp behaviour:
mount /var/tmp as loop device using /usr/tmpDSK
bindmount /tmp within a subfolder of /var/tmp
2. Have a switch/option to mount /tmp as tmpfs instead of using the bindmount
3. Optional - it is certainly not a big issue and I could easily be wrong on this point:
The current path used is /usr/tmpDSK. I would have expected the loop device to be within the /var filesystem. If the path should be changed, this is probably a good opportunity.