vagga icon indicating copy to clipboard operation
vagga copied to clipboard

Running vagga on strange file systems.

Open tailhook opened this issue 10 years ago • 0 comments

The examples are:

  1. Running on vagrant in /vagrant folder
  2. Same as (1) but running on windows
  3. Fuse file systems
  4. Some kind of NFS
  5. Fat32 or some other weird file system (not sure it's important)
  6. Encrypted file systems

In the case (2) and (5) are problematic because they doesn't support symlinks. Case (1) and (3) may have issue with user namespaces (there is a patch in vagrant which probably solve the issue), because they mount filesystem with user=x,group=x. Not sure about NFS. Not sure about OS X.

There are three kind of issues:

  1. Unable to write files inside the namespace (at least for case (1) above)
  2. Unable to do symlinks
  3. Inefficient resource usage (NFS, Fuse, maybe vboxsf)
  4. Mount --bind sometimes fail (encrypted fs, #124)

The case (3) is currently fixed with storage-dir in settings

For avoiding other issues the current best practice is:

mkdir .vagga
sudo mount --bind /some/writable/folder .vagga
vagga whatever

It's probably possible to:

  1. Automatically detect this condition to vagga and propose storage-dir: /home/<user>/.cache/vagga
  2. Setup the storage dir in a way that doesn't require manipulating .vagga folder inside the user namespace and doesn't require symlinks in source folder

The problems to solve:

  1. There are links .vagga/<container_name> which are super-useful in the IDE's, it's not clear how to setup them in all the cases above (i.e. when symlinks doesn't work)
  2. The layout of .vagga folder to support this. Probably .vagga/.lnk might be a text file
  3. Security measures (i.e. if we manipulate .vagga before setting up chroot, we may touch folder outside of both project dir and storage-dir, which is a security issue)

tailhook avatar Aug 29 '15 12:08 tailhook