270066 - (bz-webinstall) UI/Back-end separation in checksetup.pl with console and web-based interface to it

Status: RESOLVED WONTFIX

(Bugzilla :: Installation & Upgrading, enhancement, P1)

Description

[Tor]

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

Comment 1

[Dave Miller [:justdave]]

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.

Comment 2

[Dave Miller [:justdave]]

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.

Comment 3

[Tor]

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

Comment 4

[Max Kanat-Alexander]

(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.

Comment 5

[Tor]

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

Comment 6

[Max Kanat-Alexander]

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

Comment 7

[Jacob Steenhagen]

I can certainly see where instructions such as this would be quite useful to
some people :).

Comment 8

[Tor]

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

Comment 9

[Vlad Dascalu]

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.

Comment 10

[Dave Miller [:justdave]]

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.

Comment 11

[Tor]

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.

Comment 12

[Vlad Dascalu]

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. :-)

Comment 13

[Tor]

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 ;?)  

Comment 14

[:glob ✱]

Attachment: checksetup.cgi -- work in progress

work in progress.  may cause your computer to explode.

Comment 15

[:glob ✱]

> may cause your computer to explode.

on my test box (win32) this causes perl to crash when it starts to play with dbi.

Comment 16

[Max Kanat-Alexander]

*** Bug 289036 has been marked as a duplicate of this bug. ***

Comment 17

[Max Kanat-Alexander]

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.)