Support readonly root filesystem

[viceice]

general

• /usr/local/bin is symlinked to /opt/containerbase/bin
• /usr/local/lib is symlinked to /opt/containerbase/lib
• tool prepare state is stored at /var/lib/containerbase
• all cache files are stored at /tmp/containerbase
• files and folders in user home are symlinked to /tmp/containerbase/cache (eg .cache, .npmrc, .npm)

binarySource=global

• needs /tmp writable

binarySource=install

• needs /tmp writable
• needs /opt/containerbase writable

---

related issues

• Automatic runtime install of tools #101
• Allow pre-populate buildpack cache #380
• Support install-tool without associated version or env variable #1384
• Support tool version auto detection #1385

[viceice]

@rarkins There is one more issue! npm always tries to write to ~/.npm/_logs.

[rarkins]

It cannot be stopped??

[viceice]

not i'm aware of. i'm now redirecting home to /opt/containerbase/home, see linked PR.

We need to think about the existing data at /opt/containerbase when mounting a volume which will hide all existing. 🤔

[viceice]

I think we need to split installs again.

So when running as root and it's a docker build, then install tools to some other persistent path.
Otherwise all files and prepare information are gone when mounting a volume to /opt/containerbase 🤔

I would add a new containerbase-cli restore command, which recreates all missing folders and files.
It then symlinks the root installed files there, so the layout looks like now.

containerbase-cli restore will be called automatically by the entrypoint script and should be called by custom images with their own entrypoint.

@rarkins WDYT? Can you follow me?

[rarkins]

I'm not sure I fully follow, but I guess you mean that when the user mounts a volume to /opt/containerbase then anything we've put there prior is lost. So you're planning to put it in another location and symlink it over whenever the container runs?

[viceice]

Yes, that's the core idea.

When later running install-tool as user it will simply install to /opt/containerbase as now.
I can propably also check and run the containerbase-cli restore command implicit from install-tool when something is missing inside /opt/containerbase.

[rarkins]

Would it be a viable alternative to allow the user to configure the containerbase rw location via env variable? If configured then the restore happens from /opt/containerbase otherwise /opt/containerbase is used? Or is it too hard to set up PATH etc?

[viceice]

we can't ensure path then. a user would need to explicit set it 😞