RFE: `--tempdironhome` ← creating random temporary directory on user home

[belonesox]

Let's consider the following use case:

• We have to run install script from read-only media (like CDROM)
• User wants to run it from directory of CDROM (clicking on script from GUI file manager)
• We have to unpack to regular filesystem, like ext3/4, to preserve file attributes (unpacking to «tmpfs» kills them)

So,

• we cannot unpack it to tmpfs (can be solved by --notemp)
• we cannot use --notemp (because impossible to unpacking to subdirectory of readonly CDROM)

Implementing something like --tempdironhome (creating random temporary directory on user home) can be a solution.
Also, this can solve issue #300.

May other solutions exist.

[megastep]

Believe it or not, early on Makeself was used as part of installers of games from CDROM so this is not exactly a new use case.

The easier workaround for this is just to set the $TMPDIR environment variable before running the script, which will instruct it to extract temporarily in a suitable location (like your home).

[belonesox]

I didn't claim that installing from СDROM is a new use case for makeself.

I described a scenario when

• the user is inexperienced (she uses a graphical interface, she does not read instructions, he does not know and does not want to know about the terminal and environment variables),
• additionally you cannot use tmpfs (rare but possible case, because of several tmpfs limitations, like size, xattrs, etc),
• and this use case should be prepared at the time the installer is built.

If makeself would setup itself environment variables (like $TMPDIR) before running extract/installation, this can be solution for the case (build time option like --set-env-vars-before-run). But better provide options for this specific usecase, to provide automatic cleanup for this "tempdir not on tmpfs".

[megastep]

I understand, but I'm also not clear that this is a decision that can necessarily be made on behalf of the user at the time of the archive's creation. Who's to say which directory will fit? If we can't trust /tmp or similar, then why should we assume the home directory (for instance) does not not have any such limitations either, or is otherwise unsuited?

[belonesox]

Theoretically, I agreed.
Actually, "completeness" for this feature requires custom logic before running extraction.

if not (tmpfs have 10GB for unpack and have ext4 attributes) then
     ...
     lets find fs and directory with 10GB free and ext4 and writeable …
     ...
    if not then some gracefull degradation ....
    ...

Something like pre_startup_script or pre_startup_code.
But this will be harder to implement, and not easy to use (bash programming).

In our case we know about target linux systems that…

• Their /tmp located on tmpfs, when our distro cannot be unpacked (no xattrs, no free space to unpack) — 99.99999%, and most modern linuxes have same problems.
• Their /home, /root, /opt shoud be on /ext3/ext4 with xattrs (because of using bsign, signing files with storing their hash/crc/sign in xattrs) etc.

This use case coud be common for case with big archives from CDROM (does not fit to /tmp and cannot unpack to subdir).

And practically, for all these cases, a heuristic like "if we cannot unpack in the current directory, let's unpack to $HOME" with 99.99% probability will be enough.

[realtime-neil]

This is easily worked around by the user performing the extraction:

$ TMPDIR="${HOME}"/my-target-dir ./my-makeself.run

[realtime-neil]

Their /tmp located on tmpfs, when our distro cannot be unpacked (no xattrs, no free space to unpack) — 99.99999%, and most modern linuxes have same problems.

@belonesox time to name names. Which distros? If I wanted to reproduce, then can I use a docker image to do so?

[belonesox]

Many Linux distributions use tmpfs for the /tmp directory by default, as tmpfs provides a fast and efficient way to manage temporary files, but unfortunately loosing xattr attributes, and limited on size by default.

Some examples of Linux distributions that use tmpfs for /tmp by default include:

• Ubuntu and its derivatives such as Linux Mint and elementary OS
• Fedora, CentOS, and Red Hat Enterprise Linux (RHEL)
• Debian and its derivatives such as MX Linux and Pop!_OS
• Arch Linux and its derivatives such as Manjaro Linux

Actually, I even dont know modern Linux, where installer does not use tmpfs for /tmp.
I am definitely sure, that you mount will show something like my FC36:

…
tmpfs on /tmp type tmpfs (rw,nosuid,nodev,nr_inodes=1048576,inode64)
…

Without extra tuning of /etc/fstab, size of /tmp on tmpfs by default half of user memory, so big archive cannot be unpacked.

On next comment I will show how "reproduce losing xattr on tmpfs". (I was thinking that the problems about limitations of default /tmp on tmpfs is well known and obvious)

[realtime-neil]

@belonesox My situation (on Ubuntu Focal) is different than yours:

$ findmnt -T /tmp
TARGET SOURCE                      FSTYPE OPTIONS
/      /dev/mapper/ubuntu--vg-root ext4   rw,relatime,errors=remount-ro

[realtime-neil]

Implementing something like --tempdironhome (creating random temporary directory on user home) can be a solution.

Statements like this one make me feel as though the next issue you file will be against --tempdironhome because it fails when the calling user's home directory doesn't exist.

I'm against (further) complicating the implementation of makeself-header.sh when such an obvious work-around exists: The caller with the deficient TMPDIR should override TMPDIR to something that is not deficient.

Adding yet another option to makeself to work around yet another specific condition --- it feels like creeping featurism. IMHO, it is creeping featurism.

[belonesox]

About demo, how to loose xattrs on tmpfs (if your are using modern linux with /tmp on /tmpfs).

Unpack:
xattr-and-makeself-demo.zip
(and install makeself, getfattr, setfattr …)

./adir/install-me  — sample install script
./0-setattr.sh  — set some xattr for ↑↑↑
./1-getattr-from-origin-file-ok.sh  — checks this xattr
./2-pack.sh — do makeself archive with all preserving xattr options
./3-unpack-to-tmp.sh  — unpacks to /tmp
./4-getattr-from-unpacked-tmp-fail.sh  — demo, that no more xattr on file unpacked to /tmp
./5-unpack-here.sh  — unpack to subdir (probably to ext4)
./6-getattr-from-unpacked-to-ext4-ok.sh   — we should get xattr from file unpacked to ext4

[belonesox]

My situation (on Ubuntu Focal) is different than yours:

Yes, many old LTS Linuxes did not use tmpfs for tmp, and you definitely run custom LVM partitioning.

Hmm, I cannot get — how should I prove, that modern linuxes using tmpfs by default?

By linking to modern mainstream installers source code?
Like that will be OK? → https://github.com/rhinstaller/anaconda/blob/661d501ab91b450608976ace23f967b5ce7c9f32/anaconda.spec.in#L2240

[belonesox]

This is easily worked around by the user performing the extraction:

$ TMPDIR="${HOME}"/my-target-dir ./my-makeself.run

Of course, I would like to not use even less ugly workaround like

./my-makeself.run  --target="${HOME}/my-target-dir"

(Why users should know anything about variables/options, if it not necessary)

[belonesox]

yet another specific condition

I am trying (probably unsuccessfully) to convince, that this case is not very specific («big on tmpfs from CD»)

Statements like this one make me feel as though the next issue you file will be against --tempdironhome because it fails when the calling user's home directory doesn't exist.

Yes, it is ugly heuristic. :( I will try to think about better solution, and will be glad to see better ideas.
But the problem exists and not very specific IMO.

[realtime-neil]

(Why users should know anything about variables/options, if it not necessary)

Because implementing this functionality is costly --- in development, certainly, but mostly in test units.

Putting aside the question of whether this functionality should exist, how do you propose to unit test it? Would you use sudo to invoke mount? How would you do that in an unprivileged container?