Accessing the root filesystem from a plan

I have a situation where I need to copy something to /root. I haven’t been able to find anything in the documentation in plan variables, nor by internet searching. How do I go about accessing the root filesystem?

@thedarkula - by default the Pkg user is hab you can override that by specifying a user. So you could just use root as the Pkg user in the plan.sh. Or you could give the hab user sudo permission to copy the file. There is a lot flexibility in this case. I might personally look for alternatives to where this file can exist. There are phases ahead of the init hook you could use In the plan to copy the file from root to the packages data path. We currently do it in the do_install function. Hopefully that points you in the right direction.

That was all super helpful information.
Adding pkg_svc_user=root to plan.sh. allowed a binary to write to /root/.

I’m working in do_install() as well, but I’m haven’t been able to discern what variable to use to be able to access the root filesystem.

If I do something like cp file /root/file, that doesn’t work. Is there something like $hab_root_path that I’m not aware of to use?

One other thing is, I need a definite path, because I’m referencing it from a docker-compose.yml file, so the volume can’t be a dynamically-generated path as is the case for habitat packages.

I ended up copying the things I needed to the $pkg_prefix and then doing a symlink to that in the run hook.

That’s a solid way to do that. There are a few different paths and pathing helpers available in the build program that are probably worth checking out https://www.habitat.sh/docs/reference/#plan-variables. Ideally with hab since we can isolate all of the files we need into a single deterministic pathing structure, we typically suggest doing something like what you’ve done. I would also suggest if you’re copying or symlinking things at runtime in order to prep your runtime environment you use the init hook as opposed to the run hook.

init will run the first time a service starts up. Whereas run is going to pop off every time a service starts up.

Good to know I was thinking about things correctly :slight_smile:
Thanks for the tip on using init instead of run.
Much better idea

1 Like