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)
> 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)
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"
