-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Tue, Dec 20, 2016 at 11:35:00PM +0000, Patrick Schleizer wrote: > There are a few Qubes specific configuration files such as: > > - /rw/config/qubes-bind-dirs.d/50_user.conf > - Qubes-Whonix specific /rw/config/whonix_firewall.d > - and a few other examples. > > /rw is a non-standard folder. > > I think we can standardize this a bit. Examples: > > - /usr/local/etc/qubes-bind-dirs.d/50_user.conf > - Qubes-Whonix specific /usr/local/etc/whonix_firewall.d > > (/usr/local is stored in /rw anyhow.)
It looks you're actually proposing using /usr/local/etc instead of /rw/config. Not /usr/local instead of /rw. So for example /home is left as /rw/home (and bind-mounted to /home), not moved to /usr/local/home (and bind-mounted from there). > I don't propose abolishing existing implementations using /rw. > > - It would suffice if we keep this in mind for new developments. I.e. if > some new Qubes functionality wants provide TemplateBasedVM specific "/rw > style" settings, make that '/usr/local/etc/...' instead. > > - We could add parsing /usr/local to existing components (such as > qubes-bind-dirs etc.). > > - Best to keep it backwards compatible, i.e. to keep parsing /rw/ for > bind-dirs etc. So, in practice, for any tool supporting /rw/config currently, you propose to change places searched for configuration: from: /rw/config, /etc to: /usr/local/etc, /rw/config, /etc And for the new software, use only: /usr/local/etc, /etc. Is that right? > Why? > > - /usr/local is an FHS standard. [1] > > - Other applications support /usr/local/etc. (Search engines say so.) > (corridor does.) - For users it's best if it's kept uniform rather than > having a standardized and Qubes specific location. - From my experience most applications support _either_ /usr/local/etc or /etc. Depending on how was built. But not both. So, we'd still need to bind-mount/copy/symlink selected configuration to have it persistent. The only difference would be location (/usr/local/etc vs /rw/config), but the operation would be needed anyway. > - If feature requests are made / patches are proposed against third > party applications (let's say for example against onionshare, Tor > Browser), then it is more likely to have a request for the standardized > /usr/local rather than Qubes specific /rw folder accepted. This is fair point, but I don't think it's any standard to look for configuration first in /usr/local/etc then fallback to /etc. That would still be Qubes-specific _in practice_. But indeed more likely to be accepted. I think very similar use case is diskless system, started from some read-only network share. And according to my experience, such setups use some kind of filesystem level overlay (aufs/unionfs/overlayfs) to place host-specific configuration files in alternative location. So, /usr/local doesn't look to be a solution there either. > What do you think? Generally, I agree that /rw choice might not be the best one in the first place. But /rw is well established in Qubes OS for years and I'm also not sure if the change would improve much. For existing users, the change (even when keeping /rw/config compatibility) will be a problem - there surely will be inconsistencies in the transitional time etc. Will it be easier for new users to use /usr/local/etc instead of /rw/config? I don't know. On Linux both are unexpected places to put configuration in. On the other hand, it would be more familiar for FreeBSD users. So, I'm slightly against this change. Unless some other benefits will be found, to justify all the issues with the change itself. > [1] https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s09.html PS /usr/local/etc is longer to type than /rw/config ;) - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJYXUw7AAoJENuP0xzK19csMF0H+wR8rnlyWy/mknTmuhmF6LQI Qeg9rH08Le2DRKNlhyTC1celphacBImPMuOSlFLv43a/W7cIWsdzCAJ6QpmVHRzg VgP2aVRz6xehu0Az+0IJrb2pnkJYlLoacIW3sOBRqBQ9RyZsWe7udiPN0K+U2jGW 37Ee1//YPGOt6B8nGWfxkWHQtATvY1XcdacRBeZUyQs4vrj5n3dMjD5oOdwB/oud tsACzUKRq/utoSTyuj7AmeLZJ9c7QcKlitaNYKVbfQIqnZ/T7F9yuf4AvBLhtAzi jpMUf9Gzy3HWGjBzX2CpYNwDyJLUriiVfVDGtzpNIQUCT/xnKO/3pa+TNgr9YHo= =Mewh -----END PGP SIGNATURE----- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/20161223160928.GR1239%40mail-itl. For more options, visit https://groups.google.com/d/optout.
