On Wed, Mar 14, 2018 at 3:31 PM, Stephen Dowdy <[email protected]> wrote:
> On 03/14/2018 01:43 PM, Mike Kaply wrote:
> > If you've been using Autoconfig since the early days, you probably only
> use lockPref/pref/defaultPref, so you have nothing to worry about. Any
> changes we make to Autoconfig are about removing the fact that it was
> accidentally changed at some point to allow access to system globals.
>
> Predominantly 'defaultPref()' (Academia and Research where we tend to want
> to set baselines but allow users to change them if needed).
>
> So, do i take this that AutoConfig is *NOT* going away? And it will
> continue to have a reasonably functional javascript environment? (IIRC, at
> one point 'user.js' was parsed by javascript engine, but is now just
> statically parsed, so i hope that AutoConfig would still allow me to do
> basic javascript stuff)
>
Yes, Autoconfig will continue to be a standard Javascript environment.
>
> > As far as your ideas about adapting policies, we're in the very early
> phases of putting this stuff together (especially on Linux), so we're
> looking at best ways to do things.
> >
> > Linux especially doesn't seem to have any standard management. We're
> open to any ideas folks have about how to do this stuff. Your thoughts
> about environment variables is great.
>
> A couple more thoughts...
> (I have not pulled down nightly60 at this point to look at what it's
> doing).
>
> For Linux, the "Standards" are definitely flaky. FHS (Filesystem
> Hierarchical Standard) might dictate putting config files in
> /etc/opt/{VENDOR/PRODUCT}/... XDG (FreeDesktop) might have you put it in
> /etc/xdg/...
> FWIW, i think chrome stores its policies in /etc/opt/chrome/policies/ (at
> least that's where i populated one when i had time to start looking into it)
>
> I use Firefox/FirefoxESR mostly in an NFS shared tree for hundreds of
> desktops, so for me, having the configuration bits tightly bound to the
> APPDIR (install directory hierarchy) is better, as i may have multiple
> versions available. (i have default links to latest releases for both
> RR/ESR, but keep explicit previous versions (limited) available by running
> from direct path (e.g. /usr/local/firefox-58.0.2/firefox). So, i'd want
> the policy config within that directory, by default)
>
> Rather than hardcoding a config lookup to some place like
> /etc/opt/mozilla/firefox/policy.json, a SearchPath or other control
> that's prioritized in APPDIR would be preferred. Like:
>
> find Policy via scanning by priority:
> ${MOZ_POLICY_FILE} (or ${MOZ_POLICY_DIR}/policy.json) # Allow
> EnvVars (File/Directory/SearchPath)
> APPDIR/policy.json (or APPDIR/browser/policy.json) # Look in
> install directory
> /etc/opt/{mozilla/,}firefox/... # SysAdmin
> controlled site/system conf
> (use a featureful system that does a searchpath with #Include (conf.d/*)
> and does prioritized merging/overrides of APPDIR with overrides by system)
>
We have a preference where you can point to anywhere you like to find the
policies file. I wonder if that might be enough?
We'll look into this.
>
> I use env-vars in AutoConfig for mostly my own use for debugging stuff
> like:
>
> var moz_ignprefs=( getenv("RAL_MOZ_IGNPREFS") == 1 );
> // If we get ignprefs, then redefine defaultPref() and friends to just
> dump() what WOULD have been done, ignoring Prefs settings
> if ( moz_ignprefs ) {
> function defaultPref(pref,value) {
> dump("RAL_MOZ_IGNPREFS: Ignore defaultPref(\""+pref+"\",
> "+value+");\n");
> }
> }
>
> or in thunderbird like:
>
> userInfo.envUser = getenv("LOGNAME"); // Unix Username
> if( userInfo.envUser )
> { var ldapFilter = "uid=" + userInfo.envUser; }
> else
> { throw("Couldn't get UID from the environment"); }
>
> ...
>
> thanks,
> --stephen
> --
> Stephen Dowdy - Systems Administrator - NCAR/RAL
> 303.497.2869 - [email protected] - http://www.ral.ucar.edu/~
> sdowdy/
>
>
_______________________________________________
Enterprise mailing list
[email protected]
https://mail.mozilla.org/listinfo/enterprise
To unsubscribe from this list, please visit
https://mail.mozilla.org/listinfo/enterprise or send an email to
[email protected] with a subject of "unsubscribe"
