TWiki Installer FAQ

See also TWikiUnixInstaller

This FAQ currently deals with the unix based installer. (The only installer AFAIK)

Is there a Windows Installer ?

Not a working one at present. See TWikiInstallerWindows for more info/ideas.

-- MichaelSparks - 18 Jul 2003

Are you going to write an installer for Windows?

Me? No. If you want one, feel free to write and contribute one. Windows is a consumer OS and not suitable as a server OS in my personal opinion.

-- MichaelSparks - 18 Jul 2003

It would also be nice if it didn't make a new directory for a new installation.

This isn't going to change.

This is a deliberate decision to make it so that people do not accidentally clobber their current install. (This is also why it goes down to a granularity of minutes when naming the directory, given an install can be <30s in headless mode - and is potentially insufficient granularity as a result.)

The Installer has quirks under Cygwin, can you fix them?

The Unix installer is designed for running under a Unix environment. People have reported success with modifications to the installer using Cygwin & Apache. As people who use this system roll back fixes/patches, these things will get fixed. I don't use Windows/Cygwin, so I can't fix them directly. (So that's a "no", but with a caveat of "maybe )

-- MichaelSparks - 18 Jul 2003

Update: the Installer has been tested should work without quirks/modifications under cygwin under CYGWIN_NT-5.10 (XP?) and CYGWIN_ME-4.90.

-- MichaelSparks - 21 Jul 2003

The Unix Installer Removes the *,v files - Can I keep them?

(I was porting a system between servers and did not want to lose my history).
The sole reason for removing the lock files is to avoid this problem: (output is from testenv, light reformatted) User: wwwrun

• Note: Your CGI scripts are executing as this user.
  Warning: Since your CGI script is not running as user nobody, you need to change the locks in the *,v RCS files of the TWiki distribution from nobody to wwwrun . Otherwise, changes to topics will not be logged by RCS.

IF you are installing a new server and that server uses the same user to execute TWiki as the user in the *,v files (eg you're installing a second identically configured server)...
THEN removing the distribution ,v files is not a problem *and massively simplifies dealing with the above problem. Why? You would perform an upgrade/second install as follows:

• On original machine: cd `cat /etc/twiki`; tar zcvf /tmp/webs.tar.gz webs/
• Copy those to the new machine (to say /tmp)
• Perform a standard installation using the TWikiUnixInstaller
• cd `cat /etc/twiki`; tar zxvf /tmp/webs.tar.gz=
• ./system/lib/adm/legacyfyNewStyleWebs.sh
• In this scenario all your histories are preserved - with no changes to the code.

If however you wish to keep the version histories from the source distribution rather than just your own webs this is non-trivial. You have to change all the ,v files so they are locked by the appropriate user. Simply searching & replacing all occurances of (say) nobody with (say) wwwrun can result in changing the topic text (eg also in past revisions). I would welcome a patch that does this without this side effect.

Interaction between the Unix installer & package managers - .rpm, .deb ?

How does the Unix installer interact with the .rpm and .deb package mechanisms? How does it deal with upgrades to a working Twiki?

-- HendrikBoom - 05 Jan 2002

The focus of the Unix installer has been on getting a system that can work on generic unix systems - whilst my dev system may be SuSE based, the target systems are Solaris 7, 8 & Linux, all of which are installed differently. Upgrades to a working DistributedTwiki are designed to take the following approach in our environment (see DistributedTwiki for info on our environment) :

How can I use this for Incremental upgrades ?

• Upgrade one machine with an exportable code tree (cf data and code separation )
• Test on this system that things are still working as desired.
• The production sites would then rsync the code tree from this central location. (This step could just as easily be replaced by distributing a new code tar ball)
• The contents of $TWIKIHOME/etc/ isn't exported so local config settings don't get clobbered, though re-running the installer (which reads the local settings) would be wise since it can then add in any extra necessary values.

ie drop on a new code base (either via rsync or tar ball) designed to work with the twiki installer

This is more complex than a .rpm or .deb approach - but then I'm looking to perform this on non .rpm & .deb systems as a primary design factor. (eg this will work nicely on Slackware & BSD systems as well)

Incidentally I'm already doing this now since my dev system is a SuSE based laptop which I sync the code base to a desktop based machine for dev testing, which if that works as desired I sync the code base to a desktop system that's part of our DistributedTWiki for greater load testing. End users don't notice anything, except for transparent improvements to the system.

How can I use this for Flip over upgrades ?

For a flip over - ie two alternate code trees - upgrade you would have two $TWIKIHOMEs - flipped between by changing /etc/twiki to point at the "current" twiki, perhaps copy over the old etc/twiki.system-config as the new one & rerun the installer and restart apache. To take the old content with you, you have two options - copy $TWIKIHOME/webs into your new heirarchy, or have a symbolic link from $TWIKIHOME/webs to where the webs are held.

In this situation if you experience problems, you can simply change /etc/twiki to point at the old code base. (Unlike .rpm/.deb based approaches)

Finally, how does this interact with .rpm & .deb based systems? Simple - neither "knows" about the installation. If apache is upgraded, and Redhat decides to clobber your httpd.config, then you need to re-run the installer (safe to do on a running system).

Bottom line - if .rpm/.deb modifies stuff which this installer relies upon, it can re-integrate itself cleanly and this installer works completely independently of the .rpm/.deb approach, leaving your system unaffected.

• If you have any requests for a SuSE .rpm based version, please let me know
• If you have any requests for a Redhat .rpm based version, see comments for .deb
• If you just want a simple rpm based install, look at: InstallationScripts - I haven't tried those.
• If you have any requests for a .deb based version, let me know, but also provide me with a of doing this and some docs on how to create a .deb!
• If you have any requests for a .tgz slackware package based version, see comments for .deb!

-- MichaelSparks - 05 Jan 2002