Clarify some issues regarding bind-dirs #299

unman · 2017-03-03T23:00:05Z

marmarek

The only thing really needed to change is typo at the beginning. Others - let me know what do you think about it.

marmarek · 2017-03-05T11:11:05Z

customization/bind-dirs.md

-With [bind-dirs.sh](https://github.com/QubesOS/qubes-core-agent-linux/blob/master/vm-systemd/bind-dirs.sh)
-you can make arbitrary files or folders persistent in TemplateBasedVMs.
+With [bind-dirs](https://github.com/QubesOS/qubes-core-agent-linux/blob/master/vm-systemd/bind-dirs.sh)
+any arbitrary files or folderscan be made persistent in TemplateBasedVMs.


missing space

marmarek · 2017-03-05T11:14:45Z

customization/bind-dirs.md

+
+Creation of the file and folders in /rw/bind-dirs should be automatic the first time the TemplateBasedVM is restarted after configuration.
+
+If you want to circumvent this process, you can create the relevant filestructure under /rw/bind-dirs and make any changes at the same time that you perform the configuration, before reboot.


I think much easier option is to edit configuration and then launch bind-dirs script manually to create appropriate directories structure. It's easier to do and harder to make a typo. But see limitations below.
Do you think it worth mentioning this simpler method, maybe with a reference to a limitation below + a ticket (AFAIK there is none for it yet)?

Would QubesOS/qubes-issues#2673 suffice as the ticket you'd reference there or did you have something different in mind?

Just here to say that noting that the persisted data lives in /rw/bind-dirs is a useful thing to document, regardless of whether bind-dirs.sh is idempotent. +1 for this PR

marmarek · 2017-03-05T11:17:29Z

customization/bind-dirs.md

-* Re-running `sudo /usr/lib/qubes/bind-dirs.sh` without previous `sudo /usr/lib/qubes/bind-dirs.sh umount` does not work.
+* Files that exist in the TemplateVM root image cannot be deleted in the TemplateBasedVMs root image using bind-dirs.sh.
+* The file / folder in question must already exist in the root image. I.e. a file that does not exist in the root image cannot be bind mounted in the TemplateBasedVM.
+* Re-running `sudo /usr/lib/qubes/bind-dirs.sh` without a previous `sudo /usr/lib/qubes/bind-dirs.sh umount` does not work.


Actually, if you created bind-dirs configuration for the first time (it was empty during VM startup), it works fine. But in other cases, it will indeed result in some weird situation (multiple mounts in the same place etc).

Perhaps bind-dirs should figure out the state etc.. If already mounted, avoid duplicate mount etc.

(And if it is not possible to figure out the state - keep a state file with the state.)

There is mountpoint tool which can check if a directory or file is a mountpoint. That would be a first step. The second one (less important here): checking if mounted thing is a file/directory from /rw/bind-dirs.

Created QubesOS/qubes-issues#2673 for it. (Feel free to edit any of my tickets in case I misquoted.)

marmarek · 2017-03-05T11:19:29Z

customization/bind-dirs.md

 * Running 'sudo /usr/lib/qubes/bind-dirs.sh umount' after boot (before shutdown) is probably not sane and nothing can be done about that.
+* Many editors create a temporary file and copy it over the original file. If you have bind mounted an individual file this will break the mount.


In many cases it's easy to workaround: configure the whole directory for bind-dirs. Of course it isn't feasible if said directory would be the whole /etc or such...

Ideally, bind-dirs would be as robust as supporting even /. :)

copy it over the original file. If you have bind mounted an individual file this will break the mount.

This is not the actual limitation as I observed it (with /etc/default/dnsmasq being a bind mounted file by bind-dirs):

root@s-cm:/etc/default# cp dnsmasq dnsmasq-copy root@s-cm:/etc/default# cp dnsmasq-copy dnsmasq root@s-cm:/etc/default# strace -e trace=file mv dnsmasq-copy dnsmasq [...] rename("dnsmasq-copy", "dnsmasq") = -1 EBUSY (Device or resource busy) mv: cannot move ‘dnsmasq-copy’ to ‘dnsmasq’ open("/usr/share/locale/en_US.UTF-8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory) : Device or resource busy +++ exited with 1 +++ root@s-cm:/etc/default# strace -e trace=file rm dnsmasq [...] unlinkat(AT_FDCWD, "dnsmasq", 0) = -1 EBUSY (Device or resource busy) rm: cannot remove ‘dnsmasq’ open("/usr/share/locale/en_US.UTF-8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory) : Device or resource busy +++ exited with 1 +++

Moving/recreating is also a thing that config management systems like to do after templating a file (and validating it) which is also effected by this:

ansible-playbook -l s-cm ansible/ypid-playbooks/service/dnsmasq-qubes_os.yml [...] TASK [debops.dnsmasq : Configure defaults for dnsmasq service] ***************** fatal: [s-cm]: FAILED! => {"changed": true, "failed": true, "msg": "Could not replace file: /home/user/.ansible/tmp/ansible-tmp-1489657252.52-223355023089868/source to /etc/default/dnsmasq: [Errno 16] Device or resource busy"}

Maybe generalize the point to: Deleting/renaming of bind mounted files/directories does not work. Programs might do this internally when updating a file by first creating a new file and then doing a rename or unlinkat. Examples include editors and configuration management systems. A workaround might be to bind mount a parent directory instead or do the file operations in the rw location (/rw/bind-dirs/) (the last option will require a unmount/remount for the changes to become visible).

adrelanos

I am okay with these changes. Mergeable.

adrelanos · 2017-03-05T23:09:34Z

If you want to circumvent this process, you can create the relevant filestructure under /rw/bind-dirs

With any examples this is still difficult to figure out.

Anyhow. These changes are okay and I'd appreciate if merged. I am a fan of many small iterations with improvements over time, wiki style. We could still add this on top later.

andrewdavidwong · 2017-03-06T00:25:43Z

@unman or @adrelanos: Please resolve the nontrivial conflicts.

andrewdavidwong

Please resolve any nontrivial conflicts.

ypid · 2017-03-16T10:51:31Z

customization/bind-dirs.md

 * Running 'sudo /usr/lib/qubes/bind-dirs.sh umount' after boot (before shutdown) is probably not sane and nothing can be done about that.
+* Many editors create a temporary file and copy it over the original file. If you have bind mounted an individual file this will break the mount.


copy it over the original file. If you have bind mounted an individual file this will break the mount.

This is not the actual limitation as I observed it (with /etc/default/dnsmasq being a bind mounted file by bind-dirs):

root@s-cm:/etc/default# cp dnsmasq dnsmasq-copy root@s-cm:/etc/default# cp dnsmasq-copy dnsmasq root@s-cm:/etc/default# strace -e trace=file mv dnsmasq-copy dnsmasq [...] rename("dnsmasq-copy", "dnsmasq") = -1 EBUSY (Device or resource busy) mv: cannot move ‘dnsmasq-copy’ to ‘dnsmasq’ open("/usr/share/locale/en_US.UTF-8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory) : Device or resource busy +++ exited with 1 +++ root@s-cm:/etc/default# strace -e trace=file rm dnsmasq [...] unlinkat(AT_FDCWD, "dnsmasq", 0) = -1 EBUSY (Device or resource busy) rm: cannot remove ‘dnsmasq’ open("/usr/share/locale/en_US.UTF-8/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory) : Device or resource busy +++ exited with 1 +++

Moving/recreating is also a thing that config management systems like to do after templating a file (and validating it) which is also effected by this:

ansible-playbook -l s-cm ansible/ypid-playbooks/service/dnsmasq-qubes_os.yml [...] TASK [debops.dnsmasq : Configure defaults for dnsmasq service] ***************** fatal: [s-cm]: FAILED! => {"changed": true, "failed": true, "msg": "Could not replace file: /home/user/.ansible/tmp/ansible-tmp-1489657252.52-223355023089868/source to /etc/default/dnsmasq: [Errno 16] Device or resource busy"}

Maybe generalize the point to: Deleting/renaming of bind mounted files/directories does not work. Programs might do this internally when updating a file by first creating a new file and then doing a rename or unlinkat. Examples include editors and configuration management systems. A workaround might be to bind mount a parent directory instead or do the file operations in the rw location (/rw/bind-dirs/) (the last option will require a unmount/remount for the changes to become visible).

ypid · 2017-03-19T08:52:47Z

customization/bind-dirs.md

 * Running 'sudo /usr/lib/qubes/bind-dirs.sh umount' after boot (before shutdown) is probably not sane and nothing can be done about that.
+* Many editors create a temporary file and copy it over the original file. If you have bind mounted an individual file this will break the mount.
+Any changes you make will not survive a reboot. If you think it likely you will want to edit a file, then either include the parent directory in bind-dirs.rather than the file, or perform the file operation on the file in /rw/bind-dirs.
+* Some files are altered when a qube boots - e.g. /etc/hosts. If you try to use bind-dirs on such files you may break your qube in unpredictable ways.


Maybe change "bind-dirs.rather than the file, or perform the file operation on the file in /rw/bind-dirs." to "bind-dirs rather than the file, or perform the file operation on the file in /rw/bind-dirs which will require a unmount/remount for the changes to become visible)."

@ypid I take your point, but since we have highlighted the fact that rerunning the script without umount doesnt work, and umount isn't sane, it's not appropriate at the moment. Many users will be able to use this without knowing how to umount/remount an individual file - that's what this script is for. (Note that the situation may change.)

Thanks for explaining.

unman · 2017-03-19T22:48:48Z

@andrewdavidwong I think you should merge it now. (Patrick is happy as you can see).
we can deal with any further issues or changes as they arise.

andrewdavidwong · 2017-03-20T02:00:12Z

@unman: It looks like there are still nontrivial conflicts that I need you to resolve first.

andrewdavidwong · 2017-03-21T02:25:05Z

Thanks, @unman and all!

andrewdavidwong requested a review from marmarek March 3, 2017 23:34

marmarek requested changes Mar 5, 2017

View reviewed changes

adrelanos mentioned this pull request Mar 5, 2017

make bind-dirs idempotent / allow re-running bind-dirs QubesOS/qubes-issues#2673

Open

adrelanos approved these changes Mar 5, 2017

View reviewed changes

andrewdavidwong self-requested a review March 6, 2017 01:24

andrewdavidwong requested changes Mar 6, 2017

View reviewed changes

ypid suggested changes Mar 16, 2017

View reviewed changes

unman added a commit to unman/qubes-doc that referenced this pull request Mar 18, 2017

Some minor changes as per discussion on QubesOS#299

1fa9229

adrelanos approved these changes Mar 18, 2017

View reviewed changes

ypid mentioned this pull request Mar 19, 2017

Support persistent paths via symlinks the same way bind-dirs does it via bind mounts QubesOS/qubes-issues#2714

Open

ypid suggested changes Mar 19, 2017

View reviewed changes

ypid approved these changes Mar 20, 2017

View reviewed changes

unman closed this Mar 20, 2017

unman force-pushed the 2661 branch from 81cca55 to 8b6994a Compare March 20, 2017 23:25

Clarified bind-dirs in accordance with comments in 299

56863c2

unman reopened this Mar 20, 2017

marmarek approved these changes Mar 21, 2017

View reviewed changes

andrewdavidwong approved these changes Mar 21, 2017

View reviewed changes

andrewdavidwong merged commit 56863c2 into QubesOS:master Mar 21, 2017

unman deleted the 2661 branch February 7, 2024 13:31

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Clarify some issues regarding bind-dirs #299

Clarify some issues regarding bind-dirs #299

unman commented Mar 3, 2017 •

edited

Loading

marmarek left a comment

marmarek Mar 5, 2017

marmarek Mar 5, 2017

adrelanos Mar 5, 2017

jpouellet Mar 15, 2017 •

edited

Loading

marmarek Mar 5, 2017

adrelanos Mar 5, 2017

marmarek Mar 5, 2017

adrelanos Mar 5, 2017

marmarek Mar 5, 2017

adrelanos Mar 5, 2017

ypid Mar 16, 2017 •

edited

Loading

adrelanos left a comment

adrelanos commented Mar 5, 2017

andrewdavidwong commented Mar 6, 2017

andrewdavidwong left a comment

ypid Mar 16, 2017 •

edited

Loading

ypid Mar 19, 2017

unman Mar 19, 2017

ypid Mar 20, 2017

unman commented Mar 19, 2017

andrewdavidwong commented Mar 20, 2017

andrewdavidwong commented Mar 21, 2017


		Creation of the file and folders in /rw/bind-dirs should be automatic the first time the TemplateBasedVM is restarted after configuration.

		If you want to circumvent this process, you can create the relevant filestructure under /rw/bind-dirs and make any changes at the same time that you perform the configuration, before reboot.

		* Running 'sudo /usr/lib/qubes/bind-dirs.sh umount' after boot (before shutdown) is probably not sane and nothing can be done about that.
		* Many editors create a temporary file and copy it over the original file. If you have bind mounted an individual file this will break the mount.

Clarify some issues regarding bind-dirs #299

Clarify some issues regarding bind-dirs #299

Conversation

unman commented Mar 3, 2017 • edited Loading

marmarek left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jpouellet Mar 15, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ypid Mar 16, 2017 • edited Loading

Choose a reason for hiding this comment

adrelanos left a comment

Choose a reason for hiding this comment

adrelanos commented Mar 5, 2017

andrewdavidwong commented Mar 6, 2017

andrewdavidwong left a comment

Choose a reason for hiding this comment

ypid Mar 16, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

unman commented Mar 19, 2017

andrewdavidwong commented Mar 20, 2017

andrewdavidwong commented Mar 21, 2017

unman commented Mar 3, 2017 •

edited

Loading

jpouellet Mar 15, 2017 •

edited

Loading

ypid Mar 16, 2017 •

edited

Loading

ypid Mar 16, 2017 •

edited

Loading