61
edits
Deployment:Deploying Firefox: Difference between revisions
Jump to navigation
Jump to search
→possible design of a toolkit for firefox customization, deployment and management on a corporate network
| Line 546: | Line 546: | ||
== design sketch: 'Corporate Firefox' Toolkit == | == design sketch: 'Corporate Firefox' Toolkit == | ||
== | |||
== major block: requirement and expectations by it management and support == | |||
Regardless wether in small nor in medium to largesized corporations: | Regardless wether in small nor in medium to largesized corporations: | ||
Since requirements can be bit abstract, the following | The requirements, demands, wishes and expectations of it staff and others managing and supporting more than one firefox installations on a network are not considered important by mozilla - neither in the past nor today. | ||
expected and/or required configuration and management tools | |||
Not even logically following functions are provided, and/or at application level recognized or considered worth action, though they result from the mere facts that: | |||
- multiple installations on a network require lifecycle management | |||
- said network is part of an corporate it-infrastructure | |||
- the existance or demand for network wide policies controlling access to application functions can be expected | |||
- configuration can be provided in parts or total via network | |||
- | |||
The following examples outline the impact on real-world scenarios | |||
===Example: Update sources === | |||
==== Problem==== | |||
There is no way to centrally manage the settings for updates sources as well as other installation sites after installation. | |||
==== Scenario ==== | |||
After the initial deployment, the misspelled servername can only be locally fixed using an 3d- party addon. | |||
There is no way to add a new website to the list of allowed installation sites. | |||
===Example: Firefox and addon lifecycle management === | |||
==== Problem ==== | |||
Once distributed, application and addons are essentially 'unmanaged', with installed releases and revisions unknown as well as occured errors during update/upgrades or normal usage. | |||
==== Usage scenario ==== | |||
The xxy - addon has a severe security problem since update 121, possibly resulting in remote root-access. | |||
Tough luck: | |||
- One would never know, how many installations have already installed the update and are actually affected. | |||
- Even knowing the affected ones, there`s no roll-back function to move back to the older release. | |||
- The addon can not be globally disabled | |||
- you cannot stop the provision of updates except by redircting dns entries | |||
Boom, showstopper... | |||
=== design sketch: Toolkit module - Firefox and addon lifecylce management === | |||
The solution should provide functions for the following typical, reoccurring tasks: | |||
Monitor: | |||
- monitor firefox and addon releases and aviable updates | |||
- detect and report installations with missing or still pending updates or errors, | |||
Manage: | |||
- Enable, disable, update, upgrade, remove or replace an application or addons based on policy or all managed installations. | |||
Update: | |||
- download updates from the original source, apply signature, redistribute them based on per-packet lock/free switch | |||
- state of lock/free switch depends on wether the preliminary required verification-process was completed and confirmed as successfull. | |||
- wizard to run the per-package verification - process: check the QA - policy assigned t, check changelogs, run tests and document results, finally sign the update package and make it aviable via an corporate run server. | |||
(this will be a common demand...) | |||
- create and provide notification for the user on the update, the reason, relevant changes and possible issues or use automatic notification for normal, small updates - this information can be provided by the verification-process. | |||
Rollback: | |||
- roll-back of any changes made to software, eg. switch down to a previous version. | |||
- document using an audit-trail: | |||
-- all actions and changes made by the user | |||
-- all changes made to configuration settings | |||
-- all changes made to a software package and provide a per-package history | |||
-- provide a datasource for reports | |||
- research the reason for errors from relations between errors, a raising application error rate,installed addons, last changes, with per-installation logdata made aviable by the distributed installations (flat files, eg. via webdav, smb etc.). | |||
A feature to provide information on current security threats for the applicaton as well as addons is missing. | |||
Ok, there is a tutorial on a custom update server, but nothing that covers | |||
the other demands. | |||
news on security risks / | |||
This way, mozilla and the firefox project shoot themself multiple times into the left, and also the right foot: | |||
A very large group of people in (key) positions who: | |||
- decide on, support and influence the direction a decision pro/contra the use of firefox and | |||
- act as natural multipliers and advocats: | |||
-- influencing corporate decison which affects an prominent, important, often used application | |||
-- influencing private choice of employes: | |||
---indirectly through the corporate position, plans and decision | |||
---direcly by their personal opinions and feelings toward mozilla and firefox | |||
-- as well as the overall impression and opinion employees get on mozilla, firefox as well as related projects and possibly opensource in general. | |||
-- | |||
And this can have quite grave, longterm consequences: | |||
Eg: a typical it staff / admin gets the task to evaluate a corporate switch to firefox on a 50 user network and provide an initial estimate on risk, required resources, etc. | |||
currently would currently easely make the following expirience: | |||
- no primary official site/portal found by google | |||
- no resources covering questions an initial evaluation might bring up | |||
- no reviews, success-stories etc. | |||
- information is outdated, does not state the firefox versions it is verified for. | |||
- there appears to be no dedicated active community (the enterprise working group | |||
- tools and usage are scattered, requiring different levels of skills | |||
- no tool-chain: tools have no direct connection to similar tools or those providing functions required for the next step in the repackage-process (eg, tool A: create custom xpis, tool B: repackaging of firefox), | |||
- | |||
- | |||
--- | |||
multiple users | |||
providing high quality | |||
existance and non-existance of 'official' administration tools | |||
=== possible design of a toolkit providing life-cycle management for distributed firefox installations in corporate or similar networks=== | |||
Since requirements can be bit abstract, the following sketch design describes possible structure based on expected and/or required configuration and management tools | |||
Functions and features are grouped into hypothetical packages or products, one would/could expect to find when searching for something like "Corporate firefox toolkit" or "corporate framework for firefox". | Functions and features are grouped into hypothetical packages or products, one would/could expect to find when searching for something like "Corporate firefox toolkit" or "corporate framework for firefox". | ||
| Line 565: | Line 706: | ||
- corporate firefox manager tookit: | - corporate firefox manager tookit: | ||
- run as ff addon or xul app | -- run as ff addon or xul app | ||
- plugin interface and structure, plugins are addons | -- plugin interface and structure, plugins are addons | ||
- access to main app, app manger and subtrees as well as moduls | -- access to main app, app manger and subtrees as well as moduls based on acl | ||
- common access controll lists providing typical acl - settings like 'per remote ip/net etc.' - | |||
| Line 605: | Line 747: | ||
- structure, security settings and the content of directories exported via ftp, ftps, smb, http, etc. | - structure, security settings and the content of directories exported via ftp, ftps, smb, http, etc. | ||
- updates, provides addons and custom software | - updates, provides addons and custom software | ||
- package builder: | - package builder: | ||
=== design sketch: possible corporate user-level applications using the tookit as management framework === | === design sketch: possible corporate user-level applications using the tookit as management framework === | ||