Marek Marczykowski-Górecki: > 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.
Yes. > 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). Yes, because I haven't seen /usr/local/home in FHS. site:pathname.com "/usr/local/home" >> 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? Yes. >> 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. I see. Yes, bind-dirs wouldn't be replaced by this. >> - 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. Okay. >> 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 ;) > > Thank you for your consideration! :) Best regards, Patrick -- 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/47705f1e-d829-2bc7-8749-f8e175fb1b2d%40riseup.net. For more options, visit https://groups.google.com/d/optout.
