I've been toying with the idea of an "express upgrade" button that just
answers "yes" to every question in the upgrader. After you
authenticate, there's really no reason why you can't just take all the
default values, except in certain case. And I think we could it pretty
easily by just chaining the steps together and taking the default unless
there's an error. The advantage of that is that if there's an error, we
actually stop at the right sequence in the upgrader and show them a
reasonable UI. Thoughts?
Andy Staudacher wrote:
> For some reason Rowan's emails to gallery-devel don't get through and are
> not listed as pending mails either.
> Thus I forward his message to -devel.
>> -----Original Message-----
>> From: Rowan Crawford [mailto:sumaleth@...]
>> Sent: Monday, January 22, 2007 4:28 AM
>> To: Andy Staudacher
>> Subject: RE: [Gallery-devel] Gallery2 and Installatron
>>> Please send me the mail and I'll forward it.
>> Here it is:
>> I'm Rowan from Installatron (http://www.installatron.com). I
>> handle all the installers and upgraders, and I'm very happy
>> to see that you're considering ways to make auto-installer
>> support easier.
>> First, I'll address the points made in the document:
>> Re: KEEP IT UP TO DATE
>> Our policy at the moment is to wait up to a week after the
>> release of a new version of most scripts before updating the
>> installer, though there are a lot of scripts that we'll do
>> upgraders for as soon as we see a new release.
>> The reason for the delay is that almost half of all script
>> releases have problems, so we like to wait a little bit to
>> see how the release holds up before updating our installer.
>> For major updates (eg. 1.x to
>> 2.0) we'd usually wait even longer, maybe even up to a month
>> if it's a really hefty overhaul to gauge public reaction to it.
>> The Gallery project seems to be well tested though, so I
>> don't mind releasing updates quicker in this case. I've
>> subscribed myself to the gallery-announce mailing list, and
>> will endeavor to update the installer within 0-1 days of a
>> new (non-beta) release.
>> Re: PROVIDE AN UPGRADE PATH
>> Installatron includes upgrading, which I'll talk about more below.
>> Installatron includes "user notification" which will send
>> emails to users when a new version of their installed scripts
>> become available.
>> The server administrators can also forcible upgrade their
>> user's installs from administrator or from shell.
>> Re: PLAN FOR SUPPORT AND MAINTENANCE
>> Regarding usage documentation, our design policy is to
>> simplify installation as much as possible, and for this
>> reason we've been moving away from including usage notes. We
>> could never include them for all languages, and we found
>> better ways to do it.
>> Regarding support, we haven't had much of a problem with it
>> to this point. We have had the occasional user come to us
>> with a Gallery question, but we haven't minded trying to
>> solve it with them or head them in the right direction.
>> Perhaps as the number of Installatron users increases, along
>> with the number of scripts we support, we'll need to consider
>> making the division clearer.
>> Regarding modifications to Gallery, we only modify the
>> install system, to make it easier to use. I'll talk more
>> about that below.
>> Re: TIMEOUTS AND RESOURCE LIMITS
>> During installation of Installatron, we suggest they set the control
>> panel timeout setting to 5 minutes. So if the install and upgrade
>> processes will never take longer than 5 minutes we should be fine.
>> Re: DYNAMIC DEPENDENCIES
>> This is something we have plans to add to Installatron, but at the
>> moment it's not supported by Installatron.
>> Though things are a little different for us than they are for you.
>> You need to think about every user, whereas we we need to think more
>> about the server. If the installer works on the server, it'll work
>> for the ~300 users on that server.
>> So server administrators are expected test the installer on their
>> server and if it doesn't work (due to incompatibilities) they can
>> make it unavailable.
>> Additionally we keep track of requirements on this page:
>> Though scripts sometimes change requirements so we consider the "give
>> it a try" method much more worthwhile for administrators.
>> Re: NON-TRIVIAL CHANGES BETWEEN RELEASES
>> Re: MISSING AND INCOMPATIBLE PLUGINS ON UPGRADE
>> These are both related to upgrading, which I'll talk about below.
>> Re: CLEARING CACHED DATA ON UPGRADE
>> This is not currently performed by our upgraders. Do you happen to
>> know how I could automate those cache-clearing tasks? Are there
>> files/directories/tables I can delete?
>> I'd like to now talk a bit about how Installatron handles installing
>> and upgrading, and what improvements we might be able to make in the
>> case of Gallery2:
>> Installatron has the ability to use a 2-step or 3-step install
>> procedure, depending on the needs of the script. In the case of
>> Gallery2, we currently use 3-step install, but would ideally like to
>> change to a 2-step install if possible.
>> The first step is always "collection of information". This includes
>> install location, database options, acceptance of the license
>> agreement, and the collection of other details such as password,
>> email address, etc. For Gallery2, we don't currently collect any
>> extra details, so it's just location, database, and license.
>> The second step is where Installatron extracts the archive and
>> performs any tasks that need to be performed. In a 2-step install,
>> the script will be completely installed here. In the case of 3-step
>> installers, such as Gallery2, this sets up as much as
>> possible for step 3.
>> The optional third step is to call an external install script. In the
>> case of Gallery2, this is the install/ script. This is loaded into a
>> new browser window, and the user has to complete the external process
>> before they can come back to Installatron and finalize the install.
>> We use a 3-step install for Gallery2 because I wasn't able to
>> reproduce the install steps in our installer.
>> So we rely on the G2 install script, but even that script is pretty
>> complex for the sort of users that use Installatron. The solution for
>> us was to modify the G2 install script in our "step two". To give you
>> a rough idea of the modifications we make:
>> . Generate a key, create login.txt, and hard-code the key into
>> AuthenticateStep.class so that the user doesn't need to know about it.
>> . Remove settings from Multisite.html. Installatron only installs the
>> single-site version. It's up to the user if they want to get tricky
>> with the other options later.
>> . Remove settings from StorageSetupRequest.html. Installatron
>> automatically creates the g2data directory in a standized location.
>> . Remove settings from DatabaseSetupRequest.html. Installatron
>> automatically creates the database and sets these values.
>> . Replaces the message from Secure.html with a note to finalize the
>> install in Installatron at this point, before continuing. This
>> secures config.php and chmod's g2data.
>> . And finally it creates/chmods the files/directories as required.
>> I'd love to be able to remove all that. The ideal would be a
>> 2-step install:
>> . Collect admin password, email address and real name on the first
>> page of the install process.
>> . Complete the install internally in Installatron.
>> Many scripts include a .sql file with the archive which can be used
>> to create the tables and enter all the default values, and then we
>> would tweak a couple of table rows with the password and email
>> address we collected in step one.
>> Other scripts include an external install script that can be called
>> via a socket. For example, Installatron might call--
>> --and that would complete the install without user interaction (or
>> visual output).
>> Gallery2 seems more suited to the latter idea, though the modules
>> part of the install process is where we get stuck. We'd either
>> automatically install all of them, automatically install a subset of
>> modules that we deem "standard", or we generate a list of modules and
>> allow user selection in step one of our install process.
>> Our usual approach with Installatron is to "install everything". We
>> don't like asking the user to consider configuration choices during
>> installation, we like to install the script as simply as possible and
>> then let them consider configuration at their own leisure.
>> If neither the .sql file idea not the install.php?db=fg4g&pw approach
>> is an option, and we need to stick to using G2's install system, then
>> we'd love to see it simplified. Perhaps have an
>> install.php?method=simple option, which cuts it back to bare bones --
>> just the environment-check page, the page that collects the admin
>> password, and the modules selection page are needed. Things like the
>> g2data location and the database options can be handled by
>> Upgrading in Installatron is all handled by a single step.
>> For G2, there was no way for us to reproduce the upgrade steps in
>> Installatron so we went with this fairly simple set of tasks:
>> . Extract the new archive over the top of the install.
>> . Modify AuthenticateRequest.html with a note that the password might
>> be the database password (that's where Installatron gets the original
>> password from).
>> . Chmod 666 the config.php file.
>> Next time the user loads their gallery it'll automatically go to the
>> upgrade script (which is nice), with everything set up for it to run
>> without problem.
>> Generally speaking that's a pretty good upgrade procedure, though
>> there are a couple of issues: we don't like having to leave
>> config.php at 666, and it'd be better if the user didn't have to
>> worry about the authentication password.
>> It'd be nice if we could perform the upgrade completely in
>> Installatron (and this would allow us to leave config.php at 644
>> instead of 666). Calling something like this over a socket
>> might be the ideal:
>> Or if you wanted to break it up into separate processes:
>> Installatron currently installs both Gallery1 and Gallery2 with
>> separate installers. This came about because the upgrade procedure to
>> 2.0 didn't look like it would be something that every user would want
>> to attempt, and wasn't something we could do from within
>> Installatron. And you said you were going to continue supporting 1.x
>> so we branched the installers and continue to maintain both.
>> We always get a bit nervous when a script goes up a major version,
>> wondering whether we'll have to start the installer from scratch and
>> whether it'll be possible to support upgrading.
>> AND THEY ALL LIVED HAPPILY EVER AFTER
>> Anyway, plenty to think about there, and hopefully most of it makes
>> sense. I'm more than happy to discuss this at even longer length, so
>> if you have any questions let me know.
>> Oh, and tar.gz archives would be better than zip from an
>> auto-installer point of view. They're smaller files, and are less
>> prone to server quirks.
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> __[ g a l l e r y - d e v e l ]_________________________
> [ list info/archive --> http://gallery.sf.net/lists.php ]
> [ gallery info/FAQ/download --> http://gallery.sf.net ]