Slashdot Mirror
Rolling Out Mozilla in an Organization?
jdclucidly asks: "I am a network administrator for a small non-profit (about 50 employees). I would like to roll Mozilla 1.2.1 out to all of our desktops. We don't have a single ghost image because the computers on site are too varied. Yes, I did my Googling. The source for the installer is just huge and mind boggling. Is there something like a Mozilla Administration Kit that will generate custom Mozilla installers? If not, would people on Slashdot be interested in starting a new project to make such a kit?" If you were going to deploy a "branded" version of Mozilla, company-wide, how would you do it, especially if you had to worry about a mixed OS environment?
I installed Mozilla on my machine using the stub installer and had it save all of the .XPI components to a folder. I went in and extracted the .XPI's and examined them. It seems possible to do these things but not without learning XUL, JavaScript, XML and Mozilla.org's own stuffings -- not to mention setting up a Visual C++/Cygwin compiling farm for every next Mozilla release. Can I:
"Here's what I want to do:
- Install everything but Quality Feedback Agent
- Set Mozilla as the default browser
- Disable 'Open Unrequested Windows' (kill pop-ups)
- Install Elveraldo's Crystal-Classic theme as default
- Set Google as the default search engine
- Set 'Georgia' as the default Serif font for Western and Unicode
- Enable HTTP Pipelining
- Enable FIPS internal cryptography
- Set toolbar to 'Pictures only'
- Set Home Page to my organization's intranet site
- Set start page to 'Blank page'
- Disable 'Hide the tab bar'
- Enable Middle-click for new tab
- Enable control+enter for new tab
- Default downloads to 'open a progress dialog'
- Disable Javascript and Plugins for Mail & News
- Enable quicklaunch
- Create an additional shortcut on the desktop and in quicklaunch that uses chrome/icons/mailnew.ico as it's source and points to 'mozilla.exe -mail'
I installed Mozilla on my machine using the stub installer and had it save all of the .XPI components to a folder. I went in and extracted the .XPI's and examined them. It seems possible to do these things but not without learning XUL, JavaScript, XML and Mozilla.org's own stuffings -- not to mention setting up a Visual C++/Cygwin compiling farm for every next Mozilla release. Can I:
- Directly modify the defaults/prefs/all.js file to incorporate my preference defaults above and then recompress the .XPI?
- Add to the installer Crystal-Classic.jar somehow? Where are those changes made?
- Make the installer NOT allow the user to change any of this?
- Make the installer create the above mentioned shortcut?"
I recommend Automate. It would get the job done and can be deployed over a network. Although it'll only work on windows machines. Alternatively a cheaper solution would be to copy over all the mozilla files and registry settings to each machine.
Unfortunately Phoenix nightlies have dropped the pretty theme that they had in 0.1 - 0.5. They have a new and ugly theme.
This is 100% the wrong way to go about things, bud. What you want to do is use something like Microsoft Systems Management Server, Veritas WinInstall, or Novell ZenWorks SnAPPShot to monitor the install on your install test-bed PC (you DO have one, don't you?), make all those oodles of changes you want to, then redistribute it identically to your clients. If you don't have these, I would buy one of the packages -- the money you spend will save you $$$ in man-hours trying to come up with a hackneyed, crappy homebrew solution in the long run. Once you start using these distribution apps, they will become your next best friend.
Ah, I used to do something similar at the Department of Networking Services & Information Technologies, at the University of Chicago, were I used to work. Setup up webkiosks and the like for the campus.
Your probably already know this, but I'll point out the obvious:
1. Set up a Ghost server for yourself. Maybe even look at a copy of Alteris LabExpert.
2. Backup often.
3. Set yourself a timeline with mile markers. Give yourself a few months, so you don't pull out your hair or have a mental break down. Plan a reasonable project timeline, such as 3 months.
4. Set up testing workstations. Get all of your networking issues out of the way before you start on Mozilla. TCP/IP or other protocol stacks should already be installed. All device drivers should already be installed.
5. Take the list which you've already made, and make the changes to the box. When you get the change to work, backup the box with your image server. Keep detailed notes of what you've just accomplished.
6. Repeat step 5 until all items are completed.
7. When step 6 is completed, backup the workstation, diff the image if needed, and push it onto workstations of similar hardware configuration. Either package the image as an application (tar, zip), an application image (ZenWorks, Active Directory resource, Ghost, etc), or an operating system image (SMS, Alteris, Ghost).
Once you get into the groove of the project, it'll go quickly.
Sorry for stating the obvious, but you're talking about a fairly complex network engineering task. Don't expect it to happen next week or even next month. Just make sure you have an imaging server and that you take good notes, and the project will go fine.
Dont forget to copy the registry.dat when you copy Mozilla from Application data so that Mozilla knows where you are storing the Mozilla profile. As long as you are using 2000/XP (NT could work too, that's what I had have to use at work right now), just make all of your profile directories/files ready only *EXCEPT* the parent salted directory, they need read/delete to that for the lock file.
The way I have Mozilla set on our NT4 machines is to use the profile editor (name?), delete the default, create my own (named modlang, being that I run the modlang computer lab) profile, put it under mozilla.org in the program files directory, set everything to the way I want (popup blocking, default homepage, etc) and then simply copy mozilla.org directory (with mozilla already being installed on the profile creating machine) to each target machine.
The tricky part was figuring out that I needed to copy the registry.dat to default user's application data directory, after figuring that out it is cake.
I like Phoenix because I'm forced to switch between browsers a lot (thanks to my job). All the shortcut keys are similar between IE and Phoenix (unlike Mozilla). Alt-D puts me in the address bar (Ctrl-L in Moz), Shift-Click opens in a new window, and best of all, Ctrl-Enter in the address bar, as you said, works just like in IE. The consistency is handy if you use two different browser at the same time (like havign IE at home and Phoenix at work, as I imagine many of your employees will have).
What part of the article didn't I address? Sure the Google bit was a duplication, but that's how I came acroos the CCK in the first place.
How about understanding what I posted? I find a brain works well for that sort of thing.
/mike
-- "So, what's the deal with Auntie Gerschwitz et all?"
Phoenix development has died. Hyatt is now working on Safaria full time(he couldn't be happier), Blake(high schooler busy with getting ready for college) is MIA and Asa as usual doesn't comment on such things even when they seem grim. It looks like Phoenix as a project is dying/dead. No work has been done on Phoenix since December, and a critical bug has prevented anyone from using themes/extensions with new nightly versions since 12/28. This most basic bug pretty much shows the state of the project and how the developers involved have either a)lost interest or b) simply moved on. I know Blake had talked how eventually even he would get bored and move on(let any dev would), but it would have been nice if he had at least given some sort of warning.
Also the Mozilla development staff has been axed as well, so it too has slowed down at a very critical time when there have been a ton of regressions.
I'm a big fan of Mozilla(its all I use), so I hate to say these things which some people will undoubtably call FUD. But its not FUD and if you follow the project closely you'll know I'm not making this stuff up. Right now Mozilla is going through a very tough time and I really hope some new blood can come in to save it.
You'll excuse me for being a coward and not signing my name, but sorry that the way this has to be.
there's a good website called http://appdeploy.com that covers this area.
I'd be using cfengine (or something similar) to manage something that size. cfengine claims to be able to deal with Windows NT as well as Unix. I only discovered it a few months ago, so I'm still in the planning stages for our network (which is all Unix anyway), but hopefully something like that will be useful.
:).
http://pikt.uchicago.edu/pikt/other.html
Then again, cfengine might take a while to roll out
Also he wants to make it default browser, so he need to update some registry keys.
MSDOS: 20+ years without remote hole in the default install
I tried this. For some reason it was _really_ slow. I have many apps installed this way but it did not work well for Mozilla.
REGEDIT4
r entVersion\Run]Z ILLA.EXE\" -turbo"
[HKEY_CURRENT_USER\Software\Microsoft\Windows\Cur
"Mozilla Quick Launch"="\"C:\\PROGRA~1\\MOZILLA.ORG\\MOZILLA\\MO
Other registry entries might be necessary to set Mozilla as the default browser.
Other handy tips for mozilla configuration (such as locked config items, automatically generated personal config, etc) can be found at http://www.alain.knaff.lu/howto/MozillaCustomizati on/
This is used in the schools participating in the LLL project.
Some Highlights:
- Any configuration options accessible in prefs.js can be stored in a locate mozilla.cfg file (optionnally locked in such a way that it can no longer be overridden by the user):
- Disable 'Open Unrequested Windows' (kill pop-ups),
- Enable HTTP Pipelining,
- Set toolbar to 'Pictures only',
- Set Home Page to my organization's intranet site,
- Set start page to 'Blank page',
- Enable Middle-click for new tab,
- Enable control+enter for new tab,
- Default downloads to 'open a progress dialog',
- Disable Javascript and Plugins for Mail & News
- Using mozilla's own registry (%USERPROFILE%\Application Data\Mozilla\registry.dat) set the profile directory (which contains prefs.js et al.) to be on the user's home directory (H:\). That way, you can have a personalized configuration (Mail & News) automatically created by a script. When the user first logs in, he doesn't need to set his email address, server name, etc for using Mail & News, everything is already done for him!
- Disabling of the bulky XUL.mfl file (whose sizes quickly add up if you have thousands of users): just create a directory named XUL.mfl, and Mozilla will be unable to create that file, and it will still work correctly!
- Automatical loading of the needed registry entries as soon as user logs in, using a netlogon script
At LLL, we deploy our machines using Udpcast, which might not be appropriate in your case (all your machines are different), but as other posters have pointed out, most of the client-side installation options can also be handled by a Zipfile plus a small install script to put stuff into the correct place.Say no to software patents.
We have seen this behaviour too. However, apparently, as far as we could see, it would only happen on Win2k, on NTFS partitions. Win2k + FAT32 was ok. So, what we did was create a small D: partition as FAT32, and configured Windows to store the cached user profile on that partition. From then on, our "multiple profiles" problem was gone.
Since your profile location is a hardcoded path in registry.dat, Mozilla will find it, but will try to load the profile in the stale profile location. If that doesn't exist now, it'll throw up a profile manager asking you to recreate one.
Or just store the profile somewhere on the user's home directory (H:\Mozilla\)
No need to bother with vbscript. Just use locked settings in the mozilla.cfg file. This page described how. Just insert entries such as the following into your mozilla.cfg.txt:
Then encrypt the file to mozilla.cfg using this program (with an offset of 13). N.B. The mozilla.cfg.txt file must start with a comment (two slashes), and be referenced from all.js or else it will be ignored by mozilla. After having set up a mozilla.cfg, the user can no longer change the relevant settings (they are greyed out), and even if he does manually edit his prefs.js, mozilla will fix prefs.js the next time it starts up.
Say no to software patents.
There is also use a defaultPref command for setting defaults that the user may change.
Check this page for more details.
Granted, this is not foolproof (the user could use the same method as described here to change his settings), but you can make it difficult enough by making the mozilla.cfg file writeable only by the Administrator.
Say no to software patents.
However, eventually we gave up on this setup due to bandwidth considerations: it takes a much higher bandwidth to send X commands (containing uncompressed bitmaps) over the network, than it does to send html, gifs and jpegs. So, eventually, we moved to a solution where the browser runs natively on Windows (first netscape, now mozilla), and the Linux box does only the squid caching (for better usage of our WAN connectivity) and file serving (for roaming profiles).
(Of course, the Linux box does lots of other stuff as well (print serving, web server, firewall, user administration, udpcast server, ...), but these are unrelated to the browser issue that we are discussing here ;-) )
Say no to software patents.
The Nullsoft Scriptable Install System is the open-source installer developed for Winamp. (Yes, I know Winamp is closed, but the installer it uses is under the zlib license).
First thing to do is to fire up Mozilla and configure it how you want it to work on your network. Now look in your profile and take a copy of the file 'pref.js' and the file 'localstore.rdf'. Now put these files somewhere safe.
Take a clean machine (fresh install) and repackage Mozilla using WinInstallLE (This can be found on the Windows 2000 CD). Take your prefs.js and localstore.rdf file from before and add them into the package you have just created, ensure they are placed somewhere sensible like %PROGRAMFILES%\mozilla and rename them to something like 'default.js' and 'default.rdf' to prevent confusion with the original files. Ensure you configure your filesystem security so that people who shouldn't be able to change this files that will affect all users, can't.
To deploy the application, you might want to use SMS or maybe Active Directory group policy, but it doesn't stop there. For each user to have your configuration you need to ensure that when a mozilla profile is created for a user that their 'pref.js' and 'localstore.rdf' files are the same as the ones you made earlier, this can be done using a logon script. Here is the logon script that I use.
This won't prevent users from changing settings, but you can easily do this by modifying your pref.js file. For LOTS more information about doing this try this 111 pages of useful information