Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

corporate AUS system / corporate add-on repository

2 views
Skip to first unread message

Christophe Brocas (mz)

unread,
Jan 16, 2008, 8:52:15 AM1/16/08
to community-...@lists.mozilla.org

Hello everybody,

It is time to start to use this list, a very good idea from David Ascher
and Mike Kaply.

I would like to know 2 things about corporate infrastructure and
Thunderbird :

* Is there a way to set-up an AUS (automatic update system) for an
internal use inside corporate network ?
* In the same order of things, is there a way to set-up an add-ons
repository inside a corporate network ?

If yes, is it documented ? will it be maintained ?
If no, is it planned to be coded/documented/supported ? If there
already a discussion under progress ?

Typical use case of such implementations :
* be sure that a new version of Thunderbird does not break an internal
use (I have got only one example but TH v1.5 breaks all our LDAP queries
: https://bugzilla.mozilla.org/show_bug.cgi?id=323608 )
* be sure that a dependency we have on a particular add-on version will
not be broked with an unmanaged auto-update

Thank you for all informations you can provide,
Christophe

--
Christophe Brocas
CNAMTS - french public healthcare insurance,
Thunderbird: 50.000+ deployed

*****************************************************
"Le contenu de ce courriel et ses eventuelles pièces jointes sont
confidentiels. Ils s'adressent exclusivement à la personne destinataire.
Si cet envoi ne vous est pas destiné, ou si vous l'avez reçu par erreur,
et afin de ne pas violer le secret des correspondances, vous ne devez pas
le transmettre à d'autres personnes ni le reproduire. Merci de le renvoyer
à l'émetteur et de le détruire.

Attention : L'Organisme de l'émetteur du message ne pourra être tenu responsable de l'altération
du présent courriel. Il appartient au destinataire de vérifier que les
messages et pièces jointes reçus ne contiennent pas de virus.
Les opinions contenues dans ce courriel et ses éventuelles pièces
jointes sont celles de l'émetteur. Elles ne reflètent pas la position de l'Organisme
sauf s'il en est disposé autrement dans le présent courriel."
******************************************************

David Ascher

unread,
Jan 16, 2008, 5:54:27 PM1/16/08
to Christophe Brocas (mz), community-...@lists.mozilla.org
Christophe Brocas (mz) wrote:
> Hello everybody,
>
> It is time to start to use this list, a very good idea from David Ascher
> and Mike Kaply.
>
> I would like to know 2 things about corporate infrastructure and
> Thunderbird :
>
Note that neither of the questions below are Thunderbird specific in
their implementation, but I do understand that for many users (such as
yourself), it's a business problem for Thunderbird use, and not so much
for Firefox use.

> * Is there a way to set-up an AUS (automatic update system) for an
> internal use inside corporate network ?
>
> * In the same order of things, is there a way to set-up an add-ons
> repository inside a corporate network ?
>
> If yes, is it documented ? will it be maintained ?
>
As far as I know, the current software is documented and its source is
available off of http://wiki.mozilla.org/AUS

I suspect that the main focus for AUS development is to provide support
for the 100M+ users on the internet, so I could imagine that there could
be choices that morgamic's team makes that may be good for that use case
and not as good for a within-enterprise deployment.

In particular, I would imagine that an enterprise AUS would in some ways
be a filter -- you probaly want your internal AUS to be notified very
quickly of upstream patches, but I understand that you'd want the
ability to control downstream distribution.

I wonder - I've heard this kind of request from Thunderbird users, but I
don't know if the same pressure is felt for Firefox usage in
enterprises. I could imagine that in some ways Thunderbird may tie in
more with other internal systems (LDAP, calendaring systems, etc.) than
Firefox. I could also imagine the opposite =).

> * be sure that a new version of Thunderbird does not break an internal
> use (I have got only one example but TH v1.5 breaks all our LDAP queries
> : https://bugzilla.mozilla.org/show_bug.cgi?id=323608 )
>

(Aside: is that problem resolved in 2.x?)


> * be sure that a dependency we have on a particular add-on version will
> not be broked with an unmanaged auto-update
>

Both of those would require QA steps, which I presume would be your
internal responsibility, correct?

--david

Christophe Brocas (mz)

unread,
Jan 18, 2008, 4:36:54 AM1/18/08
to David Ascher, community-...@lists.mozilla.org

Le 16/01/2008 23:54, David Ascher a écrit :
> Christophe Brocas (mz) wrote:
>> Hello everybody,
>>
>> It is time to start to use this list, a very good idea from David Ascher
>> and Mike Kaply.
>>
>> I would like to know 2 things about corporate infrastructure and
>> Thunderbird :
>>
> Note that neither of the questions below are Thunderbird specific in
> their implementation, but I do understand that for many users (such as
> yourself), it's a business problem for Thunderbird use, and not so
> much for Firefox use.
Hello David,

Thank you for your answer.

For my organisation, the answer is quite simple ... Firefox is not our
corporate web browser :-(

>> * Is there a way to set-up an AUS (automatic update system) for an
>> internal use inside corporate network ?
>> * In the same order of things, is there a way to set-up an add-ons
>> repository inside a corporate network ?
>> If yes, is it documented ? will it be maintained ?
>>
> As far as I know, the current software is documented and its source is
> available off of http://wiki.mozilla.org/AUS
>
> I suspect that the main focus for AUS development is to provide
> support for the 100M+ users on the internet, so I could imagine that
> there could be choices that morgamic's team makes that may be good for
> that use case and not as good for a within-enterprise deployment.
>
> In particular, I would imagine that an enterprise AUS would in some
> ways be a filter -- you probaly want your internal AUS to be notified
> very quickly of upstream patches, but I understand that you'd want the
> ability to control downstream distribution.

It is exactly the things we want to be able to do.

> I wonder - I've heard this kind of request from Thunderbird users, but
> I don't know if the same pressure is felt for Firefox usage in
> enterprises. I could imagine that in some ways Thunderbird may tie in
> more with other internal systems (LDAP, calendaring systems, etc.)
> than Firefox. I could also imagine the opposite =).

Yes, in our organisation, Thunderbird has got links with other parts of
our information system such as LDAP servers or Calendar system. But as I
say before, I can't say anything about Firefox because we do not support
it as our official corporate web browser. And I am (very) sad about this :-(

>> * be sure that a new version of Thunderbird does not break an internal
>> use (I have got only one example but TH v1.5 breaks all our LDAP queries
>> : https://bugzilla.mozilla.org/show_bug.cgi?id=323608 )
>>
> (Aside: is that problem resolved in 2.x?)

It was solved in the 1.5.0.2 version by applying the pre-1.5 LDAP search
filter.

No more problems since.


>> * be sure that a dependency we have on a particular add-on version will
>> not be broked with an unmanaged auto-update
>>
>
> Both of those would require QA steps, which I presume would be your
> internal responsibility, correct?

Totally correct.

> --david

Michael Kaply

unread,
Jan 20, 2008, 9:45:34 PM1/20/08
to
I've done a little documentation about what your own update server would
look like:

http://www.kaply.com/weblog/2007/03/26/deploying-firefox-2-within-the-enterprise-part-5/

http://www.kaply.com/weblog/2007/05/02/deploying-firefox-in-the-enterprise-part-5-revisited/

But this is an area that is definitely underdocumented....

Mike Kaply

Guy Fraser

unread,
Aug 5, 2008, 9:37:32 PM8/5/08
to
David Ascher wrote:
> In particular, I would imagine that an enterprise AUS would in some ways
> be a filter -- you probaly want your internal AUS to be notified very
> quickly of upstream patches, but I understand that you'd want the
> ability to control downstream distribution.


A key requirement would be to define the list of /permitted/ add-ons
(and customisation options) and control their rollout, eg. QA must be
performed on any changes before they get distributed out to end-users.

As such the corporate AUS repo would need to not only flag available
updates but retain information on which versions are currently approved,
optionally grouped with known compatible updates and further grouped by
department or job role, etc.

Guy

0 new messages