Tags:
delete_me1Add my vote for this tag stale_content1Add my vote for this tag create new tag
, view all tags

NOTE

The installer described on this page is no longer maintained. See TWikiInstaller instead for a generic installer, and TWikiOn for installation on Unix/Linux - some distributions include TWiki packages that are easy to install.

TWiki Installer

IMPORTANT WARNING FOR POTENTIAL USERS:

  • This code is OLD and currently unmaintained. This is unlikely to change soon

See also:

This installer has been tested as working with SuSE Linux (aim is to work on "any" Unix), and Cygwin/Apache under Windows. (This installer doesn't contain any TWiki code, and hence for licensing, see this page - basically GPL'd unless you're granted extra rights)

This isn't one program, but likely to be a collection of them. This page documents the Unix installer. (The docs on the Windows installer have been moved to a separate page, since it AFAIK no longer works)

The Unix Installer

You need a TWiki production release (not alpha) to use this. This version of the installer requires the use of the tar.gz file, and does not support the zip file. See below how to convert.

You can also download latest version of installer, and talk about it at http://www.thwackety.plus.com/owiki/ , or (sometimes) at TWikiIRC.

Basic operation

  • Unpack TWiki & second stage installer, run the latter to set up the former
  • Ask questions
  • Act on them
  • Bounce web server

Assumptions

Non-exhaustive list of assumptions
  • You are running as root
  • You don't mind me modifying your apache config
  • You don't mind me restarting your apache server
  • That /etc/init.d/apache restart will achieve this
  • You're running a system this version is known good on. (Linux at present)
  • That you have a C pre-processor installed on your system
  • You downloaded the *.tar.gz release (or converted from *.zip )
  • If you're running cygwin you MUST have installed:
    • Perl, GCC (nb: GCC not GCC-2), Apache, Bash (part of base), patchutils, rcs

How To Use the Installer

To make .tar.gz from beta.zip file, you need:

   mkdir zipfile.zip.d
   cd zipfile.zip.d
   unzip ../zipfile.zip
   tar zcvflpP ../zipfile.tar.gz . 
   cd .. 
   rm -rf zipfile.zip.d

(please fix if any errors - it's copy/pasted from TWikiIRC chat)

To install from .tar.gz:

  • tar zxvf ../UnixInstaller.tar.gz
  • cd TWiki/
  • cp your TWiki Release Tar ball TWikiReleases/tars/
  • ./bootstrap.sh

And that's it. (Those using SuSE can do ./bootstrap.sh -headless and have a working twiki install in less than around 30 seconds.)

If you're NOT using BeijingRelease ( TWikiRelease01Feb2003 ), then you will need to change the RELEASE variable at the top of this script. If you want to use this with the TWikiAlphaRelease, please do - see the section below.

In lots of installs pressing return lots when asked questions does the right things. In the main configuration part, type "help" for help.

You get asked a bunch of questions, it bounces your apache server, and tells you what URL you need to access to look at your TWiki server - as well as where to look for a logfile (in case everything went "bang".

Using the installer with TWikiAlphaRelease

If you're installing a TWikiAlphaRelease to participate in AlphaTesting and using the buildAlphaRelease.sh script to create installable tarballs, you can use those to perform installs using this installer. That build script creates tar balls with names like: TWikialpha200307022354.tar.gz. The RELEASE string you need in bootstrap.sh in this case would be: TWikialpha200307022354 Report problems with the alpha release either via an appropriate topic, the current dev release page (eg CairoRelease), or via AlphaReleaseKnownIssues.

This version tested on, bugs, etc.

Bugs with Unix/Apache installer

If you use this, please let me know, and if you discover any bugs, please list them below...

If you test this on anything, please add list of issues/problems to the TWikiInstallerPerceivedIssues topic.

SuSE Linux Notes

No problems
  • Install accepting all defaults can be done using ./bootstrap.sh -headless

Cygwin Notes

Gosh, isn't this a poor Unix-alike system?! (And significantly slower than a real unix on the same hardware) Problems:
  • TWiki causes any perl code with shell outs to go bang occasionally. (Still works, probably a fork() style issue caused by the way TWiki works. Not an installer issue, and TWiki still works)
  • The installer tries to chown some files to a user that doesn't exist. This isn't a problem, and doesn't cause problems.

If your uname output is either CYGWIN_NT-5.1, or CYGWIN_ME-4.90, then...

  • An install accepting all defaults can be done using ./bootstrap.sh -headless

-- MichaelSparks - 20 Jul 2003

Build notes

Boring build/test notes, for the curious (and for me as a backup copy). Allows a complete rebuild & test TWiki install in under 60 seconds. (An actual install is less than 30)
A=`date`
( cd ~/Workspace/TWiki/Installer/; tar zcvf ../TWikiReleases/tars/UnixInstaller.tgz . )
( cd ~/Workspace; tar zcvf UnixInstaller.tar.gz TWiki/bootstrap.sh TWiki/TWikiReleases/tars/UnixInstaller.tgz TWiki/twikiinstallernecessary.p )
( cd ~/Workspace/tmp; tar zxvf ../UnixInstaller.tar.gz; cd TWiki; cp ../../TWiki/TWikiReleases/tars/TWiki20030201.tar.gz TWikiReleases/tars/; ./bootstrap.sh -headless)
echo $A `date`
-- MichaelSparks - 29 Jun 2003

Unix / Apache Installer features

Has a whole slew of defaults - these are suitable for SuSE linux and probably a few other Linux distributions. This installer is designed around the needs a DistributedTWiki server has, which affects the way it is used - see data and code separation for more details as to our setup using this.

Key features

  • Fixes permissions on Twiki tree to only allow web server access to data files.
  • Only allows webserver to execute Twiki binaries. Explicitly sets bit mask to avoid setuid style attacks
  • Ensures directory tree is solely owned by webserver user.
  • Supports LDAP authentication (2 major Apache module versions), htpasswd auth, and no authentication setups.
  • Includes maintenance tools to support data and code separation for distributed TWiki sites.
  • Works ! smile

  • Absolutely NO WARRANTY WHATSOEVER!

File Manifest - Main Tar Ball

The file manifest has changed. The system now has a two stage install - a basic setup environment, followed by a major install. The original file manifest is essentially the second stage installer.

File Purpose
TWiki/bootstrap.sh The main install script
TWiki/TWikiReleases/tars/UnixInstaller.tgz Second stage installer
TWiki/twikiinstallernecessary.p A patch to TWiki.cfg to make the config sep work

The second stage installer untars in $TwikiHome, and has the following files:

File or directory Purpose
./etc Dump zone for information local to this installation
./etc/.htpasswd Empty default .htpasswd file
./lib/adm Directory designed for admin scripts - ie maintenance ones - to live in
./lib/adm/makeApacheConfig.sh Calls cpp with a twiki.system-config file & twiki.mac
./lib/adm/twiki.mac cpp macros for generating a twiki.conf Apache conf file
./lib/adm/integrateWithApache.pl Takes a twiki.conf, integrates it into httpd.conf, and fixes perms
./lib/adm/twikiApacheConfig.pl Configures the twiki system suitable for apache
./lib/adm/distributify.sh Takes a standard twiki.zip file, and separates it for a distributed TWiki
./lib/adm/legacyfyNewStyleWebs.sh Takes an installed distributed TWiki and creates legacy links
./lib/adm/readLocale.pm Perl module for reading a twiki.system-config conveniently
./lib/readLocale.pm Duplicate of the module above - needs factoring

This is as before, except TWiki.cfg is no longer supplied - a patch is supplied instead. The reason for the lib/adm subdirectory is to allow the configuration code to be part of the syncable code tree.

This designed to take a standard TWiki installation and distributify it so that each web can be exported as a single rsync or samba share, as well as ease maintenance of such a system. One other key point is files that should only be readable by the webserver are only readable by the webserver.

Also it's has four different authentication mechanisms - none, htpasswd file (default file is empty), mod_ldap & auth_ldap. (The latter comes with SuSE linux)

Usage

See the new notes below.

Second Stage Installer - detailed innards

(includes more detail than most end users would want this is designed as reference...)

  1. untar's TWiki[releasedate].tar.gz
  2. untar's second stage installer
  3. Performs pwd > /etc/twiki . The installer script, and config stuff use this figure out where to put things and find stuff
  4. Changes to lib/adm , and runs ./distributify.sh - this moves all the data/templates/pub into an area separate from code.
  5. Runs the configuration script: ./twikiApacheConfig.pl
    • Presents the user with a default configuration - which you can be accepted or rejected. If it's rejected, the user can change any part. Each section includes help.
    • Saves the config in such a way that the default filename doesn't clobber the existing config.
  6. Creates a file twiki.conf containing apache directives suitable for inclusion in the webserver configuration using a directive like:
    Include /export/twiki/etc/twiki.conf
  7. Runs ./integrateWithApache.pl to add a line like the one abov, then locks down permissions and so on.
  8. Bounces your webserver

Changelog

Moved binaries to lib/adm since not local to any single TWiki. Included new legacyfyNewStyleWebs.sh - this is designed to be used after a code sync to sort out the symlinks that end up in the data directory. Also a general code cleanup, and archive rename. Added support for CommentPlugin, PollPlugin SessionPlugin and TWikiDrawPlugin (workarounds for Konqueror) to the authorisation schemes.

-- MichaelSparks - 03 Mar 2001

  • Old TODO Ensure ,v files changelogs match the webserver user for "this system".
    • Done - solved by simply deleting them - it's a fresh install - there's no need for the ,v files to be there. -- MichaelSparks - 29 Jun 2003

TODO

  • Reduce number of executables.


Motivation, Older Notes & Discussion

Motivation

Twiki needs an installer. When installing on various systems, some things that people need are:
  • A location where twiki should go.
  • Where Perl is on the system
  • Assuming they're running Apache and have access to the http config, they can simply include a preconfigured twiki.conf file, which itself can be autogenerated from user input.

As a result I'm currently working on an installer that does this:

  • Asks for:
    • TWiki install dir
    • Apache config directory
    • Apache user
    • Perl Location
  • Takes a tarball of a preconfigured TWiki, and uses the above information to untar Twiki into the required directory, take a template twiki.conf, modifies it to match the local system and to modifies the wikicfg.pm to update the things that should be updated.

-- MichaelSparks - 03 Mar 2001

Older Notes

This sounds like a great idea, although some of the information could be easily automatically determined, such as the perl location. In most Unixes it's in the default path. But the Apache config directory and user is much more subtle.

-- GregLindahl - 29 Apr 2001

We've recently been rolling out Twiki's inside our company (our one in the UK has been extremely useful, and helped bring others round to saying "I want one of those!"), and are aiming for a distributed twiki setup at the moment, and I've now got our new server install & system replicate down to the following:

tar zxvflp /tmp/twiki-base-0.1.tar.gz

cpp -DLDAPUIDATTR=uid -DLDAPBASE=dc=yeah,dc=right -DLDAPSERVER=flibble-DHTTPDLOCATION=/home/httpd -DAUTHSCHEME=AUTH_LDAP 2>&1 -P -traditional twiki.mac|egrep -v "(^ *$|invalid preprocessing directive)" >twiki.conf

rsync -z --force --numeric-ids --links --perms --recursive --owner --group\
       --times --sparse --one-file-system --partial --stats --progress \
      rsync://someuser@twiki.uk.ourdomain.com/TwikiSystem system
rsync -z --force --numeric-ids --links --perms --recursive --owner --group \
      --times --sparse --one-file-system --partial --stats --progress \
      rsync://someuser@twiki.uk.ourdomain.com/TwikiExtensions LocalExtensions

mkdir webs
for i in `rsync rsync://twiki.uk.inktomi.com/|grep '^web_'|awk '{print $1}'`; do
    B=`echo $i|sed -e 's#_#/#g'`;
    rsync -z --force --numeric-ids --links --perms --recursive --owner --group \
          --times --sparse --one-file-system --partial --stats  --progress \
          rsync://someuser@twiki.uk.ourdomain.com/$i $B ;
done

With just a couple of minor tweaks after that. The twiki.mac creates a twiki.conf file that iis suitable for simple inclusion into the apache config.

There are several differences between the structure I'm using for our twiki webs and the standard one - mainly along the lines of what I've discussed in DataAndCodeSeparation, and this is now getting to the stage where our internal goals for our twiki server can be realised in an easy manner:

  1. No single point of edit.
  2. Localised editting where possible
  3. For primary Twiki's as low load on the network as possible.
  4. Data - viewing - replicated across 3 largest support geographies.
  5. Centralised Authentication.

We've stil got a ways to go, and need to sync back our changes back into the main code base (things like more advanced definition lists and IMO nicer syntax for auto headings) but things are coming along nicely. Currently this is in 3 Geo's worldwide, but there are more sitesthan that, and I'd like to use my laptop as a roaming twiki, so there's a little way to go yet. This installer is the first step to making life simple...

-- MichaelSparks - 12 Jul 2001

Extra Feature Requirement noted from ConfigManagement is for the installer to allow better options for later things to configure being added. (Possibly an upgrade to my English would be a good idea too...) Currently the installer does this for of thing:

$templateDir      = "$nodeConfig{TWIKIBASELOCATION}/twiki/templates";

It would be better if this was changed to something more like where appropriate:

$templateDir      = $nodeConfig{TEMPLATEDIR} || someDefault

Small evolutionary change, but makes the main code able to support an external installer better, but be overridable in a nicer way. (Or again something like that but with better words)

-- MichaelSparks - 21 Jun 2003

Hi Michael,

I find myself in a situation where I've hosed my home development twiki ...and cygwin too... frown and I need to reinstall everything. I use this system for most of my work and then periodically syncrhonise, manually, with two different twiki installations. Each installation is in a different hosting environment (w2k+cygwin, debian linux, netbsd). Since I have to rebuild everything anyway, I would very much like to adopt the method you describe; what are my options? what would you recommend I do?

  • use the existing TWikiInstaller on the previous production release, and then attempt to upgrade to 2003-Feb-01 production release
  • wait for the installer to be brought up to date (how long?)
  • forget about DataAndCodeSeparation until the code matures, re-install using the old method and refamiliarise myself with it's particular collection of sufferings.
  • something else?

-- MattWilkie - 29 Jun 2003

"Current" Discussion

Matt,

I've just uploaded the current version of the installer. It's a good deal simpler to run now than above, includes help (and tells the user that help is available...). I would recommend that you try this first on your Debian box. Whilst the installer is tested under SuSE, there's little reason it shouldn't work fine under Debian since it doesn't use anything SuSE specific AFAIK. Likewise I would expect there to be no problems with the NetBSD box, but it's possible you may get some RCS issues. (Less likely given the approach I take to the webserver user/RCS files)

Regarding your Win2K box though I've no idea how this will fare - I suspect a crash and burn approach - after all I use symlinks to deal with backwards compatibility. Some basic docs for the new version follow... Aside from copying in a TWikiProductionRelease, running the script and pressing return lots I've now got an install system that is 99% automatic.

Timed install: 65 seconds

(But then I know all the Q's and A's, etc)

-- MichaelSparks - 29 Jun 2003 I am very enthusiastic about this Michael!

Unfortunately, I did try it but - like, I suspect, most people running TWikiOnWebHostingSites, I'm not running as root.

Additionally, in the use of the /etc/twiki setting, bear in mind that a lot of people will be running multiple copies of twiki (as you can't share a twiki installation between sites colocated on the same server). Therefore, even changing this to ~/etc/twiki (a good first step) would fail in more complex setups.

Also, the http settings for these people is done via .htaccess not the main webserver config file.

That said, if you can make it use ~/etc/twiki and make the bits that don't non-root executable bits optional I will certainly test it again.

Thanks smile

-- MartinCleaver - 30 Jun 2003 I didn't want to wait until I got to work so I tried it in cygwin first instead of debian. More details follow some other date, but I just wanted to let you know that the installer will work cygwin with a few relatively minor fixes. The trouble points are:

  • using (ctrl-z) to drop to the shell and poke around makes you lose the question and setting, so get all your info ahead of time
  • it would be nice to have a log file. Some error messages flashed by before "TWiki on Apache Configurator" started but they are not available in the scrollback buffer. (I got the offending buggers by being quick with ctrl=c )
  • cygwin doesn't seem to like the shell script it is currently running from (lib/adm/distributify.sh) being moved before it is finished. the offending line is #23.
  • the chown commands barf ("invalid user")
  • the auto restart of apache doesn't work. no big surprise here, cygwin doesn't have init.d. Not a big deal to bounce the webserver manually with apachectl restart
  • "Fixing permissions, ownership and updating symlinks" in legacyfyNewStyleWebs.sh (line 25) fails completely with "rm: cannot remove `23:30': No such file or directory"
  • the apache configurator pukes if you use "/" for TWIKISTEM.
  • You also break things if you use something like "§" for the WIKITOOLNAME.
  • "/bootstrap.sh: line 200: syntax error near unexpected token `fi'" forget to delete something?

It took me about 3 hours but I did get a working install. On the other hand, I've never been able to install twiki 20+ times in 3 hours before. smile

I won't be able to use the installer, in it's current form, on the netbsd box because that machine is not mine; no root access; no access to httpd.conf. I think I can wack the DataAndCodeSeparation script into something usable for me though.

-- MattWilkie - 30 Jun 2003

Matt, thanks for the feedback. I'm surprised anything worked in Cygwin TBH, since I don't do anything under windows, and didn't know how it deals with symlinks - so you did better than I would expect smile I'm taking your comments/issues and putting them in a table so I can track them better. The status field is a magic field only with meaning to me, infer nothing from it smile

Martin - thanks for yours too. Your requests partly overlap with Matt's so that's reflected below. Regarding the /etc/twiki thing. I realise the problem this causes for multiple installs and I may resolve this at a later time using a simple approach of going /etc/twiki/1,/etc/twiki/2,/etc/twiki/3,/etc/twiki/4 and look into a way of finding a context later.

The reason I'm doing it this way is because finding the twiki root on any system installed this way is them completely trivial:

  • cd `cat /etc/twiki`

There is more than one way to skin a cat, but having this single anchor point solves alot of problems. (and like any approach causes issues as well) If you're playing with an installer though - especially one that can create install directories for you on the fly at the rate of 20 installs in 20 minutes if you're testing something, having a simple way to find the current running version is extremely useful smile Point noted though!

-- MichaelSparks - 01 Jul 2003

Struck Cygwin from the etc/twiki row as cygwin should have no problem with multiple instances that linux proper doesn't have (it's just not a good idea for stability and performance reasons).

-- MattWilkie - 03 Jul 2003

Matt - did you change the script to make it work? Can you post a copy here?

-- MartinCleaver - 11 Jul 2003

  • Can you post a copy here? unified context diff here?

This is MUCH more useful. Way to generate:

  • diff -u ~/twiki/originaltarball.contents/system/lib/SourceFile.pm SourceFile.pm >CHANGE.patch

These are IMO much nicer than plain diffs of whole files. Unlike either they are more likely to be easier to integrate with a changed code base. (ie if there's drift there's a chance patch can find the new location of the text)

-- MichaelSparks - 11 Jul 2003

Other than the items I mentioned above, the biggest problem I had is that the installer needs an installer! smile It took me awhile to figure out what directories I had to create, and then what to put in them.

The attached patch is not as clean as it could be. Quick summary of changes it contains: 1) disable warning, 2) change format of ALPHA build name so it is a little easier for a human to read, 3) move distributify.sh out of the installer dir tree (must be done manually), 4) add alternate apache restart command suitable for cygwin and debian, 5) leave the name of the Sandbox web as Sandbox instead of Scratch.

-- MattWilkie - 12 Jul 2003

Thanks for the patch Matt smile

> the installer needs an installer!

Fair comment. The idea of the bootstrap.sh script is to act in this manner actually so I should make it resolve this. (The old version prior to this had even more setup requirements looking back on it...)

Regarding the changes you made:

  1. Remove warning - I understand why you've done this, but I won't be merging this in. I may however add in a flag to the installer to switch off the warning. (This would be necessary for "headless" installs anyway)
  2. The format for the alpha directory is nicer I agree. I'll merge that in.
  3. For this I presume you mean this part of your patch:
    -./lib/adm/distributify.sh
    =+~/stage2installer/lib/adm/distributify.sh
    Regarding this I'm unclear what you're doing here. In all the tests I'm running this works correctly. Is this due to your comment I summarise as "moving a script being run not liked by cygwin" above? Actually that makes sense.
    • yes, the script needs to be moved before/after it is finished. Making a complete copy elsewhere was just the quickest workaround. --MW
  4. Apache restart command. This needs merging in, but not in it's current form. Any LSB compliant system should use the /etc/init.d approach - including debian incidentally - but this can't be relied on. I think the sequence I should do is this: 1) check for an /etc/init.d script 2) check for an apachectl script 3) shell out to the user and ask where it lives. If I do 3 this implies I should be doing it in twikiApacheConfig . </randomThoughts>
    • yes debian does have an init.d apache control script; apachectl is the user-space version so I always use that one (because it is in $path, don't have to type as much) --MW
  5. Urgh. I've left some hardcoded personal preferences in. I'll put those into the twikiApacheConfig script.

I've been doing some work on Pi11 above. Some random notes:

  • I've created a sandbox hosting system. (Essentially apache configured to allow .htaccess in user directories)
  • I've tried getting the installer to work in this environment - it requires a number of hardcoded reference changes. (These relate to Pi11 above - specifically my anchor of /etc/twiki clearly doesn't hold.)
  • The TWIKIURL value the installer asks for isn't actually used in the right places by the current installer. (Changing it to use the value in the right places was simple though given the value was at least being asked for)
Possibly routes forward:
  • The bootstrap installer could be passed a value telling it where the replacement file for /etc/twiki is. The installer can then change the hardcoded values
  • There's a number of random variables that need evaluating:
    • The supplied .htaccess.txt doesn't include an Options ExecCGI line - this means the SetHandler cgi-script won't actually work unless the entire tree the code is installed into is already ExecCGI - ie the entire tree is being installed into a cgi-bin tree.(ugh!) Also depending on the AllowOverride settings adding such a line may or may not be valid.
    • The entire tree (including the pub/ directories) being cgi enabled (in the ExecCGI predefined case) has rather vicious security implications. (And forces some requirements onto attachment handling - specifically when attachments are added any directories created need to have an .htaccess file created with the appropriate deny lines. (Which also means the attachments should be served by TWiki rather than served by the webserver)

This is actually a rather messy way to run TWiki IMHO!

Incidentally, idea of using ~/etc/twiki is bogus and does not work reliably. (Having tried it)

  • It probably needs to be an absolute path, e.g. /home/users/msparks/etc/twiki as the webserver user will be different, and thus ~ resolves to something else. I've installed twiki into 3 different hosted environments. All of them were quite different in this regard. I don't think this step could be reliably automated and you will have to add a prompt for the home location. -- MattWilkie - 14 jul 2003

-- MichaelSparks - 12 Jul 2003
-- MattWilkie - 12 Jul 2003

Michael - I'll try testing this again tomorrow. Can you please make your latest version available somewhere?

-- MartinCleaver - 16 Jul 2003

It's attached to this page. There's no publicly usable version regarding the comments above available as yet. (That's what being ill for a few days does for you)

-- MichaelSparks - 16 Jul 2003

Matt said:

  • It took me awhile to figure out what directories I had to create, and then what to put in them.

Please reveal what you had to do, I can't get it to work.

-- MartinCleaver - 18 Jul 2003

From my Instructions above:

  • tar zxvf ../UnixInstaller.tar.gz
From just now:
zathras@linux:~/Documents/tmp> tar zxvf ../UnixInstaller.tar.gz
TWiki/bootstrap.sh
TWiki/TWikiReleases/tars/UnixInstaller.tgz
TWiki/twikiinstallernecessary.p
From my Instructions above:
  • cd TWiki/
From just now:
:~/Documents/tmp> cd TWiki/
:~/Documents/tmp/TWiki> 

From my Instructions above:

From just now:
:~/Documents/tmp/TWiki> cp ~/Workspace/TWiki/TWikiReleases/tars/TWiki20030201.tar.gz TWikiReleases/tars/
:~/Documents/tmp/TWiki> ls TWikiReleases/tars/
TWiki20030201.tar.gz  UnixInstaller.tgz
(That UnixInstaller.tgz is the second stage installer)

From my Instructions above:

  • ./bootstrap.sh
From just now:
:~/Documents/tmp/TWiki> su
Password:
:~/Documents/tmp/TWiki> ./bootstrap.sh
fx: presses return to lots of questions (Aside from first)

Result: I'm left with a working system. So that Matt can get this working with cygwin, the one thing Matt needed to move was the file that ends up with this filename (in this case):

:~/Documents/tmp/TWiki/alpha200307181356/twiki/system/lib/adm/distributify.sh

The following patch results in the installer using a copy that doesn't try to move itself. (Which apparently cygwin hates) It might work for you. Basic smoke test shows that doing an install pressing return lots using this works.

--- .old/bootstrap.sh   2003-06-29 23:52:46.000000000 +0100
+++ bootstrap.sh        2003-07-18 14:03:53.000000000 +0100
@@ -75,7 +75,10 @@
 #================================================================================
 # Distributify
 echo "Performing DataAndCodeSeparation"
-./lib/adm/distributify.sh
+pwd
+cp ./lib/adm/distributify.sh .
+./distributify.sh
+rm ./distributify.sh
 cd system/lib/adm
 # ---- Create the Apache Config

Save that as bootstrap.sh.p, and then do a patch -p0 <../bootstrap.sh.p it.

-- MichaelSparks - 18 Jul 2003

Merged this fix, and Matt's nicer installation directory fixes. This means the installer should now play happier with Cygwin. (Not a complete solution though)

-- MichaelSparks - 18 Jul 2003

Further updates:

  • Creates a log file. (TWikiInstaller.log-Date-and-Time )
  • No longer clears the screen during install
  • Points you at testenv after install
  • Points you at your log file after install

-- MichaelSparks - 18 Jul 2003

Further update:

  • Possibly solved Pi6 - ie under cygwin removing dead symlinks failed. Minor rewrite to avoid dependency on vagaries of ls on various systems.

-- MichaelSparks - 19 Jul 2003

Update to pick a config based on the uname of the system. Now includes more friendly defaults for cygwin.

-- MichaelSparks - 19 Jul 2003

Bit the bullet. Found a system I could fight cygwin on. Installer now works on Cygwin. Minor issues, and (obviously) has installation dependencies. See the Cygwin sub-section above in the "tested on" section. If you're uname is CYGWIN_ME-4.90, and wish to accept all the defaults, then your install can be as simple as a ./bootstrap.sh -headless. If your uname is CYGWIN_NT-5.1 you might well be able to do the same (I can't check that). If your uname is anything else you should double check the information you give the installer.

Still not perfect, but this does mean that I've now used the installer to do "hands free" installations on both Windows & Linux, both of which are customised installs with better defaults, and data and code separation. Some clean up work required for some other things.

-- MichaelSparks - 20 Jul 2003
[ MartinCleaver's comments on using the Unix installer to install Windows/Apache moved to TWikiInstallerWindows. ]


Discussion moved to TWikiInstallerDiscussion

-- MartinCleaver - 22 Jul 2003

What page do unix-specific patches go to? Is cygwin unix-specific or Windows? (I'd say unix but others may differ)

-- MattWilkie - 22 Jul 2003

Ahh.. this is so cool, I really need this! Is there a new version out? I need to run at hosting but script don't work properly there. What should I do? Thanks Joern.


> I need to run at hosting but script don't work properly there. What should I do?

Given almost every hosting environment is different from almost every other one this isn't going to be resolved immediately. I've done some initial work on seeing how to take hosting environments forward. Ways you can help make this happen are to post on TWikiInstallerHostingRequirements :

  • The version of perl your hosting environment supplies
  • What "user" you scripts there run as. Specifically whether they run as the webserver's user ID or run as your user ID. (This shouldn't be a massive issue though) ie are your scripts running under suexec or similar?
  • Whether you have only ftp access, or telnet access - or do you have to use an upload script (ala TWiki attachments) to put files onto the ftp server?
  • Does your hosting provider allow your CGI scripts to directly change files on disk, or does storage from FTP scripts have to be done
  • Does your hosting provider allow you to create directories?
  • Does your hosting provider provide in addition to perl:
    • cpp
    • rcs -- ci , co
    • tar
    • gzip
    • zip / unzip
  • Whether you are given a user cgi directory, or whether you're given a user sand box. (What do I mean? If you log in using FTP/telnet can you see other users directories? ie if immediately after login you cd .. ; ls do you see any user directories? )
  • Does your hosting provider use a Unix or Unix-like OS for hosting, or is it a windows based environment?
  • If Unix and you have telnet/shell access, what's the output from uname; uname -a ?
  • Regarding email/includes from CGI's does your hosting provider give you any of the following:
    • Are your CGI's allowed arbitrary network access?
    • Are they allowed to port to random hosts on port 80, 8080, 1080, others ?
    • Or do you have to use a proxy (ala sourceforge)?
      • If so do you know the proxy settings you need? (Often <proxy name> port 3128 or 8080)
      • Do you know which type of proxy it is? (eg Squid, 3Com, Network Appliance, Inktomi, Cacheflow)
      • Does it have ACL's preventing access to specific pages? (See TWikiRemoteWebpageIncludesSecurityIssue )
    • Does your CGI hosting provider allow your CGI's to send email using:
      • A mail program running on a host with an existing MTA configured? (ie can you just run "mail" or "sendmail" and send mail using them without specifying any mail server?)
      • Do you have to use their SMTP server - they may also call this a smart host?
      • If the latter do they have Net::SMTP installed?

There's probably more questions, but those are probably the key headlines. Without this sort of information from users including yourself an installer for hosting environments is doomed to failure (Or the TWiki installed will be extremely crippled). However, even with this information I can't promise any timescales. But if people don't come forward with the information this will never happen. You can get quite a lot of this information (not all, but lots) from the testenv script supplied with TWiki. Except that mean you'd need to install TWiki to run it. Which means you wouldn't need the installer. Oh, hold on....

Feedback on the page mentioned above with the information noted welcome smile

-- MichaelSparks - 28 Jul 2003

Re the testenv issue - it is possible to just run testenv like this without a web server, providing usable output but with the unfortunate restriction that it's not being run under the correct Apache environment:

  1. Do =cd twiki/bin; perl testenv > /tmp/testenv.html
  2. View results with lynx /tmp/testenv.html or copy to another system, or put it in your Apache data directory and view it through Apache.

You could even automate the Lynx part, dumping its output to stdout, and then analysing the results. However, it would be better to do a mini-install of just testenv.

See also TWikiOnWebHostingSites - recommended hosting sites are much more likely to make it easy to run the TWiki installer (e.g. see DreamhostSetupNotes for the one I use, though I haven't tested the installer yet).

BTW I did the rename of this page, which has caused quite a lot of churn in Codev smile

-- RichardDonkin - 29 Jul 2003

New Vision for a basic unix installer.

Seems like this discussion has stalled out and I'd like to revive it. I know that WillNorris and other are working on more ambitious installer solutions but I'd love to see just a basic TWiki installer such as most other software products seem able to provide. I'm not talking about a solution that can manage installation of plugins and everything�just one that will install a basic twiki package.

I have no idea what's involved in creating such a solution but thought I could at least provide a vision of what one might look like, based on my experience with installing other programs and knowledge of what's involved with installing TWiki. I imagine an installer for windows could involve the same basic steps and options but I don't know enough about windows to provide the detail I have here.

A general goal I would strongly encourage for the TWikiUnixInstaller would be be that it would require the user only to use ftp and web browser.

Description of installation process using TWikiUnixInstaller.

  1. Prep for installation
    1. FTP two files, install.pl and twiki.dat, into the directory that will be top level of twiki installation.
      • Install.pl is the installation script.
      • twiki.dat contains only the esssential files for a basic installation (what has recently been referred to as a TWikiKernel).
    2. Set the permission for install.pl to 755.
    3. Direct your browser to http://yourdomain.com/twikidirectory/install.pl
  2. Screen #1: Environment Check
    • This screen would be similar to testenv, only simplier, and displays:
      • A check that twiki dependencies are present. Reports if they are there or not and, if not, whether it is a critical dependency.
      • List basic information, such as document root, name under which scripts run, etc.
    • Concludes with message whether or not installation can proceed.
  3. Screen #2: Confirm installation settings
    • This screen presents probable installation settings, with option to modify if so desired.
    • Includes:
      • Directory settings:
        • Path to installation root.
        • url of root
        • Path to lib directory
        • Path to data directory
        • Path to pub directory
        • Url for pub directory
      • Platform settings
        • Name of wiki (for setting WIKITOOLNAME)
        • Name of administrative user.
        • Password for administrative user with confirmation.
        • Email address for twiki administrator. E.g. "twikiadmin@yourdomain.com
        • Ask whether installation is for Intranet or Internet (for setting registration page).
        • Select kind of authentication desired. Basic option is preselected with other options listed with notes on requirements.
    • Concludes with "Proceed with installation" button.
    • Results of clicking button include:
      • The twiki.dat file is unpacked.
      • All the directories are created and appropriate permissions set.
      • The appropriate registration page is created.
      • The selected authentication method is implemented with htpasswd and htaccess files created as appropriate.
      • The administrative user is created and added to TWikiAdminGroup.
      • The basic "TWiki Platform Settings" in TWikiPreferences are set.
  4. Screen #3: Confirmation
    • Confirmation is provided that installation is complete.
    • Ask whether user desires to proceed to wiki installation with button that says "Yes!"
    • Click on button results in install.pl and twiki.dat being deleted and browser being directed to base url for site.

I hope this bit of brainstorming helps inspire and direct someone with the skills to code such a solution. I'd be delighted to help out with testing and documentation.

-- LynnwoodBrown - 20 Apr 2005

Has anyone noticed and tried out the TWiki installation scripts mentioned in this article? (Here's the direct link to download the scripts.).

-- LynnwoodBrown - 25 Apr 2005

Lynwood, I've been looking at finding a unix installer for TWiki and the situation seems a bit confused at the moment. I mean that the UnixInstaller as attached here seems to use a somewhat "controversial" mechanism as discussed in DataAndCodeSeparation. Particulary as the Upgrade script appears to be getting attention, thus perhaps rendering the data and code seperation approach less important.

In terms of your suggestion I guess you have the "someone else hosts the webserver" scenario in mind. Do you not agree that there is also a need for a simple install script that could be run by a site admin to install new TWikis ?

-- RobByrne - 06 Jun 2005

Bug reports and feature requests go to TWikiInstallerPerceivedIssues.
Discussion regarding modifiying TWikiInstaller to work with Windows (other than cygwin) goes to TWikiInstallerWindows

Topic attachments
I Attachment History Action Size Date Who Comment
Unknown file formatgz UnixInstaller.tar.gz r11 r10 r9 r8 r7 manage 18.6 K 2003-08-13 - 21:09 UnknownUser Unix installer, better cygwin support
Perl source code filepl WinNTSetup.pl   manage 3.3 K 2001-06-02 - 13:36 SvenDowideit  
Unknown file formatpatch cygwin-matt.patch r2 r1 manage 1.1 K 2003-07-22 - 06:44 MattWilkie fix too broad 'user*' search in httpd.conf
Edit | Attach | Watch | Print version | History: r79 < r78 < r77 < r76 < r75 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r79 - 2008-09-23 - RichardDonkin
 
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2018 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.