Closed Bug 270066 (bz-webinstall) Opened 17 years ago Closed 14 years ago
UI/Back-end separation in checksetup
.pl with console and web-based interface to it
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0 Please pardon me if this is a duplicate. I looked through the search and did not readily see anything that matched this. I, like many, have a web hosting reseller account with FTP and a web based SQL interface. The server I am on seems to have all the modules installed, however I do *not* have access to the CLI to install bugzilla. I would like to see someone take 10 minutes or so and add to the installation instructions the following information: (Installation Instructions: http://www.bugzilla.org/docs/2.18/html/installing-bugzilla.html) 1. SQL DB Dump File This file would allow users to manually configure their SQL interface without the CLI. I have access to a web interface that can take a dumb file or a series of commands manually to create databases. It should be very easy to get a DB Dump file. 2. A basic/example "localconfig" file This file should contain the basic parameters for getting Bugzilla running. Comments should be placed in the file at points that will likely need to be modified based on the installation location of various modules. With these two pieces of information I could probably get bugzilla working on my HostDime.com accounts. It would take some work on my part, but I am willing to do that. I hope someone will take a little bit of time and help me. I just need some information to start with. The only reference to a FTP Installation of bugzilla had a broken link for the part that contained the localconfig so I was screwed. If anyone needs some help getting the SQL db dump or modifying the localconfig file so that it contains more generic information please let me know. I'd be happy to help on this issue. I do not have a server to do this myself at the moment. Reproducible: Always Steps to Reproduce: NA, Request for additional information to make Manual Installation without the CLI possible on systems that already have the required modules. Actual Results: NA, See above. Expected Results: The software should have contained a little more information including an example localconfig file so that users could manually install and configure bugzilla using FTP and some form of SQL database management. I call this a "blocker" because there is no way for me to install the code on the server I have access to. I believe the server meets all the requirements except for a CLI. All the modules are installed as far as I can tell. I just can't create my own localconfig file and do not have the right database table configuration information. With these two things I could begin to install and test Bugzilla. I was hoping to install the 2.18rc-3 version asap. Thank you so much for your time and consideration here. -Tor
There really is no way to run a generic database dump to hand out to people... the configuration script asks you a bunch of questions, and some of the stuff that gets put into the database depends on your answers. The only real way to do this is to install it on a local machine, answer the questions the way you want, then use mysqldump to dump the resulting database and feed it to phpMyAdmin on the server (or whatever the interface is they gave you). You can also FTP the resulting localconfig file and data directory to the server if you have an FTP client that will preserve permissions on the upload and recursively upload a directory. And to answer the question you asked on IRC (sorry I disappeared on you, I got a work-related phone call while we were talking), Bugzilla should work fairly out of the box on FC3. You'll need to install MySQL and a few Perl modules, but most most everything else should be there already.
Assignee: zach → documentation
Severity: blocker → normal
Status: UNCONFIRMED → NEW
Component: Installation & Upgrading → Documentation
Ever confirmed: true
FYI, 2.18rc3 also works on Windows, and a database dump from a Windows MySQL server will run just fine on the linux hosting service's MySQL.
I'll try it on my laptop, but I don't like installing extra **** on my work computer. It seems to me that there should be a way that those "questions" could at least be documented with an example of some answers and the resulting configuration. Leave it up to a user to tackle. There should be a setup method that doesn't require a CLM. Ever considered making the initialization php driven? zencart has a really awesome php driven installation wizard. I doubt bugzilla would need anything quite so fancy. Heck a lot of stuff could still be autodetected using php. I'll see what I can do here, but I still think that if i had an example to go off of, and a basic mysql table to work from I could customize it manually if I knew what the questions were and the mentioned example of a couple answers. Without that kind of stuff documented it is literally impossible to do a manual configuration. I wonder how many other people struggle with getting bugzilla installed on a service that doesn't readily offer a CLI. Many more would be likely to adopt it if it was more natural to install. Anyone else willing to vote for this issue? Making the installer more compatible "right out of the box" ? -Tor -Tor
(In reply to comment #3) > Anyone else willing to vote for this issue? Making the installer more > compatible "right out of the box"? Hey Tor. I think that *of course* EVERYBODY would be willing to *vote* for the issue. :-) Have you ever looked at the installer code (checksetup.pl), though? It's 4500 lines of code, at the moment. It's not votes that are needed, it's just specifications, consensus, and then patches. The "patches" part is of course the hardest part to come by, though the "consensus" part can also be difficult. Anyhow, you can file a separate enhancement for it, in the "Installation & Upgrading" component, if you've got some good ideas.
Thanks Max. When I can articulate the idea a little better I'll post it as you said. If someone was willing to help layout the specifications for exactly what the current localconfig does i'd be glad to try my hand at the php that would replace it. I have looked at it. Given enough time I think I could duplicate the functionality with php. Each block by itself is rather straight forward. It is the end result that is unclear since I haven't been able to install bugzilla. That time would be reduced by 75% if someone helped outline the spec. -Tor -Tor
I'm sure we'd all appreciate a general overview of what checksetup.pl is doing. There are some comments at the beginning that go over it, and there are comments all the way through that are pretty decent. You can also file a request for the general overview... :-D
I can certainly see where instructions such as this would be quite useful to some people :).
Priority: -- → P4
The comments are decent but they are piece-mill meaning that they do not provide a linear A->Z walkthrough of what is going on. With a defined set of "requirements" in terms of what that file must do I think a comparable php initialization could be created OR perhaps a web-based perl script? I have gotten bugzilla installed using the ftp method. I found that the sql database, localconfig, and the data directory seemed to be the only things that were customized during the checksetup.pl steps. (that and directory permissions and .htaccess files which could be part of the tarball anyway.) A generic db dump file with some comments in it would be very useful. I have the basis for one. Comments in the form of what kind of variations/customizations are possible would be useful, however for the first version of a "manual install" method I would expect the user to get mostly a canned default/generic installation. As time allows I'll see what I can do to document what I've found so far. I didn't get to run the checksetup.pl myself as I did not have a server setup yet. a friend of mine helped me out with that and provided me with the output. -Tor
The issue here is that we haven't performed UI/back-end separation in checksetup.pl. Solving this would solve quite nicely all the other problems. I suggest to tackle this issue first and to create a .pm module with the "core" DB create/conversion code by taking it out of checksetup.pl. After this, we can have a command-line front-end to it (the remaining part of checksetup.pl), or rewrite the 100-lines remaining code into a .cgi that can be accessed via the web.
Component: Documentation → Installation & Upgrading
Summary: Manual FTP Installation Instructions using FTP and Web-SQL Manager → UI/Back-end separation in checksetup.pl with console and web-based interface to it
checksetup.pl actually already lets you feed it a script for the answers to the questions it'll ask. It would probably be a pretty easy thing to do to write a CGI that would ask those questions (use the existing answers from localconfig and the DB if things are already present), generate said script file, then call checksetup.pl with that script and feed the output back to the browser. The problem with this is it exposes a potential security breach if someone besides the admin happens to run the CGI script (remember, the first time it's run, there won't even be an admin defined to authenticate to make sure they can access it, so we'll have to have blind faith that it works). upon successful completion, checksetup.pl should probably take steps to disable said CGI script so it can no longer be run from the web. (Outright deleting it would be best - most other packages I've seen with web-based install scripts either delete the install script or have you delete it when you're done) Note (actually somewhat unrelated) that the basic separation of the back end of checksetup.pl is part of the plan for the database compatibility stuff. The database configuration code needs to be separated from the rest of the filesystem configuration stuff.
Exciting to hear. I like where this is heading. It would be nice to let the user decide if the cgi should be deleted. Either way, the checksetup.pl in generating .htaccess files could easily add the specific web cgi to the block list. So what is the next step? Is there something I can provide help with? I do not have my own linux box setup where I can run checksetup.pl from the command prompt, but I could call it from another cgi-script on the system I'm using. I'm not familiar with the "questions" that the checksetup.pl asks. I've looked through the script but one more familiar with the questions could articulate them and define what the form the answers take. I'll get my own personal server setup in the near future, but until then I'd still be willing to help as time allows.
checksetup.pl runs in Windows as well. You can use even a laptop to download and install Bugzilla (with ActivePerl, Apache and MySQL) and then you will have a fully functionale Bugzilla on your very own computer. :-)
This isn't my personal computer... that will be getting linux soon. This is my work laptop. I don't think the boss would appreciate me installing a bunch of apps like that. Software developers tend to be picky about production systems ;?)
work in progress. may cause your computer to explode.
Assignee: zach → bugzilla
Status: NEW → ASSIGNED
> may cause your computer to explode. on my test box (win32) this causes perl to crash when it starts to play with dbi.
*** Bug 289036 has been marked as a duplicate of this bug. ***
So, basically, I've decided that we're not going to be doing this. See bug 389845 for the reasons. If you really want this to happen, feel free to: 1) Explain how you would overcome the technical obstacles. 2) Write the code yourself. (Start by reversing the patch in bug 389845.)
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → WONTFIX
Whiteboard: [roadmap: 3.2]
Target Milestone: Bugzilla 3.2 → ---
You need to log in before you can comment on or make changes to this bug.