Tracking bug for the one-step install for NT
On Sun, Oct 14, 2001 at 12:19:20AM -0400, John Muczynski wrote: > I've been at work on > http://bugzilla.mozilla.org/show_bug.cgi?id=44659 > and > http://bugzilla.mozilla.org/show_bug.cgi?id=104660 > as I'm sure you noticed. This is in regard to installing on Windows NT. > > Question: Do you intend people installing on Windows boxes to use > Makefile.pl ? (I was able to get Bugzilla 2.14 to work quite fine > without even having to change the #! lines. Of course I used Apache.) > I'm thinking that your changes in the other files might require that > Makefile.pl be run whether a user wants to run it or not. Perhaps that > isn't the case. Do you have time to comment? > > By the way, I don't know any perl, so I'm reading perldoc today. > > Kind Regards, > > -Stosh Yes, the intention was to have all users, including Windows [NT], be able to run the Makefile.PL for configuring and installing Bugzilla. The way I have Makefile.PL and Bugzilla/Config.pm architected, you should be able to use them in your DOS batch file to save you a lot of work. If you pre-define all the parameters in your own copy of a Bugzilla/Config.pm file, you can run the Makefile.PL non-interactively from the batch file and run "perl.exe Makefile.PL; make; make test; make install; make setup". However, please note that I have NOT tested the Makefile.PL patches on a Windows [NT] system, so I'm not sure what pitfalls or problems there are or that there may be. (For example, does ActiveState Perl come with a compatible make.exe/nmake.exe, or does the Cygwin/MS Visual C++ environment have to be installed first?) I doubt that I will have the time or a Windows box to test this on, so any testing you can do would be appreciated.
Another way to create a one-step (or at least more simple) install for Windows users is to build an installer using something similar to InstallShield or MSI (Microsoft System Installer) that is compatible with the MPL. http://www.installshield.com/ http://www.microsoft.com/downloads/release.asp?releaseid=32832&NewList=1 http://www.microsoft.com/downloads/release.asp?ReleaseID=32831 The Apache Group now uses MSI as of apache-1.3.22. http://httpd.apache.org/dist/httpd/binaries/win32/ In this way, the installer binary could be built on a "development" machine, and end users wouldn't have to worry about having "make.exe" and other development items installed. (The would have to have both Apache and ActiveState Perl installed, though.)
Although Apache supports the use of .msi files, you do have to have the correct version of Microsoft's MSI installed on your NT box in order to use the .msi file. I'm thinking it would be easier to download the Bugzilla tarball and not require a .msi version of it for Windows people. For a one step install, I'm hoping to get Apache, Perl, and Mysql installed for the user rather than make them do it separately. Thus, the idea is a one step install; not a four step install. :-) If running Bugzilla after 2.14 is going to require Makefile.pl (and it sounds like it will require it), then perhaps I'll have to install a make if it doesn't come with Apache, Perl, or Mysql. If Bugzilla install is going to require Makefile.pl, then I don't see using .msi being able to avoiding that step. I obviously don't know enough (yet) about the sequence that Makefile.pl is using. I'll download it and start getting to work...
What I meant is that if Bugzilla were packaged up in an .MSI like Apache is now, it would make your batch file even simpler since you could simply invoke the installers for Apache, Perl, MySQL and Bugzilla in turn.
*shrug* activestate also supports msi for windows. and i'm trying to convince mozilla browser to support it too. the fact that you need a certain version of msi doesn't bother most people, we should be able to borrow the help text from activestate. As always everyone is free to use cvs checkout or sourceballs, but there's nothing wrong w/ offering an MSI format.
There's nothing wrong with offering an .msi In fact, it seems that using a tarball or using an .msi would have the same steps. TARBALL 1. get gunzip 2. use gunzip & pax to install tarball MSI 1. get correct msi 2. use msi to install .msi This goes the same for a zip: (self expanding or not) 1. get unzip.exe 2. use unzip to install .exe/.zip I wouldn't be opposed to supporting all three formats. It appears that unattended operation would be the feature to die for. :-)
MSI is probably the best solution 1. ActiveState (perl) use MSI 2. Apache use MSI 3. MSI can be used to run any "external" program (why not "perl makefile.pl ;-) 4. MSI in included in windows 2000/ME/XP only NT 4 and Windows 9x users need to manualy install the runtime 5. If you realy need you can wrap your .msi and the MSI runtime in a single large making your setup a real "OnStep" install The only problem in to select the tool to generate the .msi (I only know comercial products)
CC writes: "MSI is probably the best solution. ... NT 4 and Windows 9x users need to manualy install the runtime ... problem is to select the tool to generate the .msi (I only know comercial products)" I'm thinking that using a .bat would be nice: 1. works on 9x, NT, and 2000 2. Doesn't require a manual install of a runtime 3. can be used to run any program (perl onestep.pl :-) 4. a text editor is the tool to generate the .bat 5. ftp, .gz, .tar, and .zip files can be processed from a .bat 6. it might even be possible to do an unattended install of a .msi file
i'm confused, yes msi's can be linked together for package purposes. the bottom line is there's no reason not to do an MSI in addition to whatever other silly methods we choose to implement. fwiw .bat's may or may not work on NT.
>the bottom line is there's no reason not to do an MSI in addition to >whatever other silly methods we choose to implement. For distributing Bugzilla, yes. But that's not what this bug's about. What is the goal of this bug? The TODO (attached above as attachment 53448 [details]) says, Goal: To setup up bugzilla on a Windows NT system assuming that the user knows nothing and has nothing installed. Is there any reason to supply more than one method of getting to that goal? I'm hesitant to say that .msi files can't get to that goal, but they're not exactly popular in my neck of the woods. To use .msi, it seems like the user would have to know a few non-trivial somethings rather than nothing. >fwiw .bat's may or may not work on NT. Um, attachment 53449 [details] [diff] [review] above is a .bat that runs on Windows NT.
Possible formats/executables that can be used on Windows NT include: 1. exe, 2. bat, 3. zip, 4. self extracting zip, 5. tar, 6. tar.gz, 7. msi, 8. perl, 9. com, 10. cdrom autorun, 11. bootable cdrom, 12. bootable floppy, 13. make, 14. csh scripts, 15. visual basic (I'm probably missing a few others) I'm ready to discount 9, 10, 11, and 12 as silly. Of the remaining, only 1, 2, and 4 will run, given the assumption that the user has nothing installed. Does anyone see any other options or do you think the goal should be different?
ok nm the .bat thing we're aiming for convenience for a system admin, not something else (i was thinking in lockdown mode... which a system admin might actually do considering ... ah well nm anyways) fwiw you missed .cmd (like .bat) and .js (like .vbs). I think we should offer .msi because it allows for very clean uninstall procedure and at some point will be a logo requirement (it was supposed to be for w2k...)
>Goal: To setup up bugzilla on a Windows NT system > assuming that the user knows nothing and > has nothing installed. A quote from Murphy's Law: "Build a system that even a fool can use, and only a fool will use it." Basically what I'm saying is that the installer should provide intelligent defaults for all options (for the user that "knows nothing"), but allow the user with a clue to override the defaults, however that is accomplished with the selected installation technology.
I like David Kilzer's point that the one-step process should make provisions for a user with a clue to override the defaults. Here's a list of the defaults that I can think of. Please, please, add additional ones (within the scope of this bug). 1. Whether to install Apache or make provisions for some other http server. 2. Whether to install ActiveState Perl, Apache/modperl, or make provisions for some other perl. 3. What FTP servers to get various tars from. Whether to use tars the user has downloaded and where to find them. 4. What version of Bugzilla to install, where to install it, and what url prefix to attach it to. Whether to uninstall earlier bugzilli, or leave them; what url prefix to attach them to (if left), or no url access. 5. Whether to use MySql for the database, or some other option. (I'm thinking future here...) 6. Whether MySql will be running on the same machine as Apache, or another machine. 7. Whether to uninstall packages that already exist, or to use the existing files. 8. Which CPAN mirror to use to get the perl modules required by Bugzilla.
I installed InstallShield devloper 7 on my pc. This version allow to create a msi package but allow to wrap it in diferent format: single .exe (including the msi runtime) single .exe (with automatic download of the msi runtime if needed) small setup.exe with download of the msi package by the exe This is probably the best tool to use to generate an ez to user setup
Can we get some sort of milestone on this? Thanks.
Created attachment 125483 [details] perl script wrapped inside a .bat header -- alpha version of one step install Ready to look at, but not ready to execute.
*** Bug 209105 has been marked as a duplicate of this bug. ***
as I have said in Bug 209105, (sorry for the dup, my search was not exhaustive enough): We have to make a "double click" install for BZ. It will further have to be hot fixable. Our target delivery date is July 15, 2003. (Bugzilla STABLE/Tip) We plan on using NSI, **BUT** if we can get docs on MSI asap, and the license issues are minimal/none we will redo in MSI. see Bug 208521
> We plan on using NSI, **BUT** if we can get docs on MSI asap, and the license > issues are minimal/none we will redo in MSI. see Bug 208521 Windows Installer SDK Startpage: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/msi/setup/about_windows_installer.asp
thanks, and the dl link is: http://www.microsoft.com/msdownload/platformsdk/sdkupdate/ only works in IE, does some scripting w/ the os to dl.
Created attachment 126995 [details] perl script wrapped inside a .bat header -- alpha version of one step install This attachment is one of the files inside the .zip attachment.
http://www.geocities.com/johnstosh/2003-07bugzilla_install.zip The zip was just a little bit too big to attach, so here's a url to the zip. This will have to be a self-extracting .exe ... http://www.geocities.com/johnstosh/2003-07bugzilla_install.zip
the link does not work, do you have access to a site with semi-reliable storage? if no, we can setup a bz user for files on one of our systems.
http://www.geocities.com/johnstosh/ Okay, the problem appears to be that Yahoo wants the file attached to an HTML before it'll allow access. Follow this link to download the zip: http://www.geocities.com/johnstosh/ The zip contains: perl.exe, perl56.dll, onestepmodules.pl, and onestep.bat Once I start making it as a self-extracting .exe it will be enough to bootstrap a system when someone double-clicks (plus or minus bugs, plus or minus downloads not being available because of version number changes, plus or minus ...)
Created attachment 129335 [details] 2003-Aug-6 onestepmodules.pl (still alpha version) You'll note this is still using bugzilla 2.14.5 since 2.17 is not quite up to speed for windows. I've looked at 2.17.4 and it'll require a good piece of work to get going. I'll be approaching that later ...
Also, http://www.geocities.com/johnstosh/ provides the latest files for onestep install (still alpha version). This version runs on 2.17.4 but does not patch for bug 185330. (The description for Bug 185330 has several fixes for the bug.)
Created attachment 132901 [details] Oct 8, 2003 version. This is starting to look pretty good. http://www.geocities.com/johnstosh/ provides a zip of the latest files for onestep install (still alpha version). Today's version is 2003-10-08bugzilla_install.zip This version runs on Bugzilla 2.17.4 and does patch for bug 185330.
The 10-29-2003 version of the One Step Install is available as a self- extracting executable at http://johnstosh.public.pyerotechnics.com (thanks Jason Pyeron) This version ... ... is still alpha. ... runs on Bugzilla 2.17.4 and does patch for bug 185330. ... isn't ready for Windows XP, yet; due to issues with PAX.EXE. ... is almost ready for Windows 2000. ... works on my Windows NT 4.0 box, but I haven't tested it on a different NT box. I'm expecting problems with my.cnf files and database passwords. ... includes code to see if Apache is running and if the bugzilla pages are accessable and has a feeble attempt to bring up a browser.
can you provide a link on the site back to this bug? just for those pesky search engines...
New version now installs with blank mysql password for 'bugs'. I've also changed the password on my machine (for 'bugs' in mysql) to a blank password. Interestingly enough, uninstalling mysql doesn't seem to erase all its passwords. See the 2003-11-19bugzilla_install.exe link at http://johnstosh.public.pyerotechnics.com In a little while (a week or two) I'll be testing this again on Windows 2000 and Windows XP.
New version tested on NT/2K/XP. Seems to work except for SENDMAIL. See the 2003-11-26bugzilla_install.exe link at http://johnstosh.public.pyerotechnics.com In a little while (a week or two) I'll be working on sendmail (version 8.7 or better). I suppose you could try this version if you weren't interested in having bugzilla send email. (Please send me an email if you do try it.)
> In a little while (a week or two) I'll be working on sendmail (version 8.7 or > better). I've looked at email and (although its swell on the unix side) it is a bit lacking on the windows side. I'm hoping the work on a few bugs gets completed before I try to automatically configure email on windows. That will give me time to find an smtp host or something at my location. I suppose you could try this version if you weren't interested in having bugzilla send email. (Please send me an email if you do try it.)
This is sort of an outside project, so don't take the milestone literally. I'm just getting it off the radar for our release blockers.
Bugzilla 2.20 feature set is now frozen as of 15 Sept 2004. Anything flagged enhancement that hasn't already landed is being pushed out. If this bug is otherwise ready to land, we'll handle it on a case-by-case basis, please set the blocking2.20 flag to '?' if you think it qualifies.
The trunk is now frozen to prepare Bugzilla 2.22. Only bug fixes are accepted, no enhancement bugs. As this bug has a pretty low activity (especially from the assignee), it's retargetted to ---. If you want to work on it and you think you can have it fixed for 2.24, please retarget it accordingly (to 2.24).
I don't imagine anything happening on this bug, so I've reassigned it to default. The files are still up on http://johnstosh.public.pyerotechnics.com
Is that still something we want? If I understand correctly, this bug asks for a single .exe or .msi file which would install Perl + MySQL/PostgreSQL/Oracle + Apache + Bugzilla and configure everything for you. This sounds prone to problems to me, especially because it has to work on Windows 2000/XP/Vista + with 32 or 64 bits flavor. Max, what's your opinion?
If somebody maintains it well, or gives it to us in some way that's really easy to maintain, I'd still be happy to have it.
i'll give this one a shot, using strawberry perl, mysql, apache and nsis.
I've got a script about half-way done with NSIS. It installs PostgreSQL, Apache, and Strawberry Perl, it just doesn't do the configuring of anything yet.
i've uploaded a functional win32 installer to http://landfill.bugzilla.org/win32installer/ remaining items: - configure cvs, interdiff and diff (and test) - add/remove programs icon - uninstall - license(s) display (MPL & GPL i guess) - post-install launching of browser - adding scheduled tasks and of course more testing :)
That's so cool. Anybody else who knows NSIS: Want to look over glob's installer code? (I imagine that since it lacks an uninstall, actually testing it right now might not be feasible.)
uploaded another revision. changes: - configures cvs, interdiff and diff - correct icon in add/remove programs - implemented uninstall - loads browser post-install - batch file for generating backup file - now using cvs stable tag instead of tarball todo: - adding scheduled tasks currently uninstall deletes the entire bugzilla directory, including the database. much easier to implement, but i need to put a decent warning in the uninstaller prior to nuking things from orbit.
I think you can pretty much mark this FIXED. :-)