Designing a generic web installer
Each somehow popular web applications needs one: A proper web installer, there still is no general solution for that. Christian Weiske already blogged about this issue some time ago. He also came up with a list of requirements, which sound very sensible. Sadly the pear installer does not provide a way to build such web-installers in an easy way, without shell access, and additionally pear is often not even installed properly at mass hosters systems.
Since implementing an installer for Arbit is one of the bigger points on the current roadmap, we are facing this situation right now. As you can see from the different libraries we already spun out of Arbit, we try to do such things right, once we need them. So we started a design document, based on Christians requirements, to specify what we need from an installer and how it could be implemented.
I founded Qafoo together with two other Arbit contributors, and beside consulting and training around high quality PHP software we provide commercial support for Arbit and other software quality related tools.
If you are interested in a web installer for your distributable application, I would love, if you could check out the design document and verify that it meets your requirements, or is extensible enough to do so.
If you have to add anything to add or discuss, please join #arbit on FreeNode to get in touch with us.
If you liked this blog post, or learned something please consider using flattr to contribute back: .
Comments
Fields with bold names are mandatory.
Thomas Koch at Mon, 26 Apr 2010 13:05:53 +0200
I'd like to mention http://project-builder.org . It's a project to continously build packages for different distributions like Debian, Fedora, Suse. This would be an alternative to create your own installer.
Link to commentMany people prefer to install software only by the means of their distribution's package management system.
However this won't work for shared hosts of course, so depending on your priorities this may be a no-go.
Kore at Mon, 26 Apr 2010 13:28:15 +0200
Building an installer, which works for shared host is the key-requirement here. Additionally building packages for the various distributions is, of course, an additional nice thing to have.
Link to commentNoel Darlow at Mon, 26 Apr 2010 15:33:05 +0200
A web-based installer creates a serious security risk on shared hosts because of file ownership. Anything your installer can write to is wide open to other accounts on the same server.
Link to commentKore at Mon, 26 Apr 2010 15:39:13 +0200
@Noel: Short answer: No.
Link to commenta) You can drop privileges after the installation
b) You can ask the user to do so
c) Setups where webuser != ftp-user, are flawed in different ways anyways
d) You always need to be able to write to some dirs (caching, logs)
It is part of the installer design / specification, and we will deal with that.
Brett Bieber at Mon, 26 Apr 2010 22:02:44 +0200
Hi Kore,
Link to commentI would encourage you to check out what is available in PEAR2, specifically the new installer, Pyrus.
Using PEAR2 & Pyrus as a base would make creating a web-based installer really easy. The PEAR2 registry format is completely localized, and Pyrus is available as a phar so there's no complex installation required as with pear (v1). I was able to create an autoloader that installs pear packages in about 50 lines - http://github.com/saltybeagle/AutoloadPackage/blob/master/AutoloadPackage.php
so it's not complex at all.
We've planned on building a web-based package installer for pyrus, which I started a few weeks ago, but haven't finished yet: http://svn.php.net/viewvc/pear2/sandbox/Pyrus_WebFrontend/trunk/
The plan is that this would be a .phar or .php that users would simply drop into a web-accessible directory.
Just might be worth checking out.
Cheers,
Balu at Thu, 06 May 2010 16:59:13 +0200
An Installer should not have more than a few steps:
Link to comment1. Check requirements and prerequisites.
If one of those fails, don't move on to step 2.
But there should be a difference between warnings and errors. Warnings are meant for things which the software can work around or are just important to be mentioned.
2. Input required configuration
Ask a minimum of really necessary options, everything else should be configured later in the backend.
3. Check data and install
Check if the user input is ok, e.g. if a connection to a database works. Otherwise do step 2 again.
Do everything that is needed to install, like setting up databases, configuration file (allow for automatic and manual creation of this by the user).
4. Display (positive) result and give the user some hints on how to access the frontend and backend.
Balu
Kore at Thu, 06 May 2010 17:04:43 +0200
@Balu: I second that, and the installer in its current design can do exactly this. In the case you only have one task, it will behave like you described.
Link to commentSome people might want to configure more then the very basic setup in their installer - I saw this in some more complex PHP applications. For this the installer implements the possibility to execute multiple of those "tasks" depending on the configuration options provided in the first "task", which will then each behave like you described above.
Leaving this to the "user" of the installer, and making both possible, is the best thing you can do here, imho.