Feature Proposal: TWikiNonRootInstaller

Motivation

NonRoots might be the most important potential user-group, although they are not being adressed by standard TWiki installation. A second target-group are TWiki-Admins, who have to do several installations on one server, e.g. development site, testing site and productive site.

Description

Performs the basic steps from the documentation for NonRootUsers. Needs manual variable adaptions to specific environments, but should work on a standard Debian-account.

-- UweWahser - 22 May 2005

Impact and Available Solutions

Note: Patch is attached as https://www.twiki.org/p/pub/Codev/TWikiNonRootInstaller/twinst.sh. The patch is against the TWikiRelease of 01 Sept 2004.

Documentation

Should be self-explaining - just adapt the variables and run it from the same directory where you copied the TWiki tar-ball.

Examples

• Set up multiple environments

• Install TWiki on NonRootAccount

Implementation

Quick + dirty solution in bash which would need some adaption for standard users. Unfortunately variables have to be adapted within the script. Maybe one of the more experienced TWiki-users could see whether and how to integrate this further.

Potential improvements:

• A simple html-interface could make this a usefull tool for non-geeks.

• optional plugin-installers could be added as well as installers for language files.

---

Discussion:

I recently outlined some thoughts in a similar vein as part of this discussion on unix installers.

-- LynnwoodBrown - 23 May 2005

I just went back there - yes, that would of course be the better solution. Actually I didn't even want to start a new discussion, I just wanted to leave the script to whoever could use it in order to automate the steps from the manual, until a real installer could take over that part - maybe I shouldn't have placed it in FeatureRequest?

-- UweWahser - 24 May 2005

MediaWiki has a really neat way of separating the configuration of the webserver from the configuration of the wiki. Their installer is a CGI script, so if you can run the installer script, there's a pretty good chance the rest is going to work. They present you with a simple webform (though the doc stinks) that you fill in and press "go".

This is neat because (1) it makes sure there is a clear separation between config needed to set up the webserver (gnarly, and not really TWiki's problem) and configuration of the wiki (2) it's CGI script and since it is only configuring mediawiki components it is largely platform independent (3) you can easily go back and re-run it if you want to change anything.

I think we should use testenv as the basis for an interactive CGI installer. Answer the questions until testenv gives you a green light, and you have configured your TWiki.

-- CrawfordCurrie - 06 Jun 2005

OK, the new configure CGI script in SVN 4366

-- CrawfordCurrie - 09 Jun 2005

Crawford - just tried out your configure script and it looks great!!

Here's some more feedback:

• The formatting needs some work. Much of the instructions and some of the text boxes ran outside the white box and off right side of window (requiring horizontal scrolling).
• I'm assuming the script writes to TWiki.cfg . I wonder if it could write to LocalSite.cfg instead. Is there any reason to store local configuration in TWiki.cfg anymore?
• The page is awefully long. Could it be split into several screens, with a "save & next" button on each one?

-- LynnwoodBrown - 09 Jun 2005

Yeah, formatting is pretty horrible, I agree. My focus was on functionality rather than cssart. i also was using FireFox, which is a lot better than IE at showing screens like this.

No, it doesn't write to TWiki.cfg, ever. It only writes to LocalSite.cfg. TWiki.cfg is IMHO read-only in Dakar.

Split into screens; that gets too complicated, IMHO. We want something of a "start at the top and read down, filling in items as you go" nature - thus the required items are at the top, and the update button at the bottom. Remember, most people will use this rarely, so IMHo multiple screens are more work for little benefit, maybe even negative.

-- CrawfordCurrie - 09 Jun 2005

After a chat with PeterThoeny we identified the following issues:

1. Protecting bin/configure so JoeHacker can't get to it
   • my view is that this is a documentation fix; the installler should be advised how to use .htaccess to restrict access to a small number of usernames.

With WillNorris, we came up with this list of what bin/configure does not do:

1. install plugins
2. manage multiple data/single code multiple code/single data
3. work on the zip; it requires an unpacked package
4. configure TWikiAdminGroup
5. configure Auth (e.g. copy TWikiRegistrationPub etc)
6. configure TWiki variables like WIKIWEBMASTER
7. install CPAN modules
8. produce installation report

In the short term, only (8) is a requirement; configure should write to an installation log. Longer term, 4-6 should be looked at, 4 being especially nice. The only reason I didn't do 6 was that I didn't want to have to work out Upgrade when variable settings in TWiki topics are now in Configure. I did it for SMTP by allowing the TWiki variables to override bin/configure but that is clunky and not a general solution.

I will create entries in the Bugs web so we can track A.1 B.4 and B.8. Since these are requirements for Dakar, I'm setting this topic to "done".

-- CrawfordCurrie - 17 Jun 2005

I have a few suggestions. Have a look at my first stab: http://visiblearea.com/devtwiki/bin/configure

Redesign steps:

1. make it look like pattern skin
2. make the options look like accordion pane - the selected item should look selected, does not yet
3. reshuffle the info text
4. redesign the green text layout (not done)
5. opening and closing the bars should set the page to the same scroll height, i.e. not move the page (not done)

-- ArthurClemens - 07 Jul 2005

personally I think the buttons should be made into tabs along the top, that way the user is not forced to scroll, when they are just trying to browse each category.

-- SvenDowideit - 08 Jul 2005

I am seeing 3 problems with that:

1. The contents of each option block is quite long, so scrolling cannot be evaded when using tabs.
2. It will be hard to fit all texts into the labels. The text should be way smaller, but even then it will be a very wide row of tabs.
3. There is not a logical progression down to the save button. When the first tab is open it is even off screen. Should Save then be made part of the tab row, at the far right?

-- ArthurClemens - 08 Jul 2005

1. scrolling is fine when i've found the option set that contains the settings that i want, but if i'm just browsing, scrolling is not fine.
2. i'm not opposed to multiple rows of tabs - but yes, its an issue
3. this is an issue both now and with tabs

-- SvenDowideit - 08 Jul 2005

It is also possible to have vertical tabs, or just a vertical menu, with the option block at the right.

-- ArthurClemens - 08 Jul 2005

Scrolling on each tab could be implemented using overflow:auto on the divs. That way the save button and the tabs can be visibles all the time.

-- RafaelAlvarez - 08 Jul 2005

and copying the wikipedia user preferences ui would not be a bad thing

-- SvenDowideit - 08 Jul 2005

I have kept the accordion pane, but added a scrollbar: http://visiblearea.com/devtwiki/bin/configure. Some text reshuffling, still not final.

-- ArthurClemens - 08 Jul 2005

When egrep is not found, a warning is issued. But without egrep, my search is not working. Shouldn't that be an error message?

-- ArthurClemens - 08 Jul 2005

yeah, i didn't realise at the time how major a problem it was

-- SvenDowideit - 09 Jul 2005

I am almost finished reformatting (http://visiblearea.com/devtwiki/bin/configure). I also recoded the way lines are printed to the screen by removing as many print instructions as possible.

I also changed the styles for error and warning for the color blinds.

I have a few questions:

1. There are 2 "General path settings" blocks. But because I changed the ids to the anchor names (to make the link from the explanation text easier/more logical), they both have the id "GeneralPathSettings" (which also causes the page not to validate). How can I change the last block (for instance to "General path settings Windows")?
   • configure is data-driven from the TWiki.cfg and LocalSite.cfg files. This means that it relies on formatted comments in those files to provide the documentation - and the values - of configuration variables. You can change any text by editing TWiki.cfg.
2. Why is the configuration password needed? Is is a TWikiAdministrator password? Shouldn't the field be filled in (with dots/stars) if the user visits the page for the second time? What if he has lost his password?
   • Without a password, anyone could change the configuration. The idea was that configure can be used like testenv for most people, and admins could change values if they know the password. -configure does not use cookies, so remembering passwords is not an option for it. As explained in the documentation, if a password is lost, the administrator can log in to the server and manually edit the password. It is stored in LocalSite.cfg, along with all other local configuration settings.
3. If I change the name of the TWiki web to 'System' the site does not work with pattern skin anymore, and a lot of variables are not expanded. So it is not so simple to change as it seems.
   • Correct. That has always been the case. configure only presents the configuration options that have always been available through editing TWiki.cfg. The very fact that you have observed this limitation shows that it is doing it's job of making the configuration more accessible! Please feel free to add entries to the Bugs web wherever you feel documentation is inadequate.

-- ArthurClemens - 09 Jul 2005

I've added a fallback mechanism in case javascript is off to show all blocks open.

• Nice one!

-- ArthurClemens - 09 Jul 2005

The second "General path settings" comes from LocalSite.cfg. I've changed the title to "General path settings (local site)". But there are no settings in there to change - not with the configure page. Is it meaningful to keep this block in configure?

-- ArthurClemens - 10 Jul 2005

Once users are using configure, the only thing that will insert formatted comments into LocalSite.cfg are plugins install scripts. There should be no other sections in there. I guess you are using a file based on the old LocalSite.cfg.txt template - this template is really redundant now, as working with the configuration view configure is so much easier,

-- CrawfordCurrie - 10 Jul 2005

Right. Updating to the latest LocalSite.cfg made the double heading go away as well.

I have committed my changes to configure to SVN (4563). Please assist in testing.

• Fixes in 4564 (CC) and 4565 (AC) -- ArthurClemens - 10 Jul 2005

There is a small formatting bug in Firefox that causes a horizontal scrollbar to appear in each folding block. Hope to fix that.

-- ArthurClemens - 10 Jul 2005

one small complaint - Arthur, can you please not put huge borders around the configure page? right now, you're using 2 inches (each side) of my 15' 1600x1200 notebook screen for pink, and andther inch per side of white - that forces me to enlarge my browser way beyond sanity - and the font size you're using now is too big even for my tiny pixels.. - you're tempting me to turn off css completely.

• This is all done for consistency. So the page should have the same borders as the edit and attach pages. And isn't the font size the same size as other twiki pages? If this is different there is a bug in the css. Oh, and the margins grow with increasing font size. -- ArthurClemens - 11 Jul 2005
• nope, both the borders and fonts are way larger (i made sure both browsers are set to medium font) - see /p/pub/Codev/TWikiNonRootInstaller/BordersAndFont.JPG -- Sven
  • Yes, I see now. But after testing I found this is caused by the first line, the xml declaration. This causes Explorer to go astray. The xml line is not in normal twiki pages. Compare:
    1. original script page: http://visiblearea.com/devtwiki/bin/configure
    2. test page no xml: http://visiblearea.com/devtwiki/bin/test.html

also - the red background for settings makes me think they are in error, not that they are compulsory - which i think is typically denoted using an asterix

• Fair enough. We can choose another color that is not green or red. -- ArthurClemens - 11 Jul 2005

as a non-newbie - i'd like to twistie the explanitory text too - its taking up too much space too (considering it will proably be read once, and then never again)

• Solution: make a toggle button to hide/show the explanation? With a cookie to remember the setting. -- ArthurClemens - 11 Jul 2005

-- SvenDowideit - 11 Jul 2005

just read the above and realised I've filed bugs that have already been reported above and are symptoms of other bugs. Oh well.

I will note that the W3C validator points out that "The character encoding specified in the HTTP header (iso-8859-1) is different from the value in the XML declaration (utf-8). I will use the value from the HTTP header" so I think it's probably a wise move to remove the xml declaration.

We now have two sets of code for toggling sections of a page. The code in configure and toggle.js (used for the personal WebLeftBar. See also Bugs:Item92). We should probably look at consolidating them to one codebase (even if it has to be duplicated so that configure is self contained). It would be nice if the WebLeftBar sections also used cookies to remember hide/show settings.

I've included a search below for configure script items in the develop Bugs web. Please start all your configure script bugs' subjects with configure script.

-- SamHasler - 12 Jul 2005

Arthur - I've attached 2 800x600 sized images (ie & firefox), and would like to make sure you understand that this is unacceptable for the main administrative interface. As an admin, I never maximise my browser, in fact i resent being forced to run my browser to the admin interface much bigger than this, and I generally would expect that the fonts used are small enough (and the UI designed well enough) no to need to scroll too much. Personally i also dislike having to use internal scroll bars - I already have one set on my browser application, why can't you design the page to use that?

my complaints also hold true for all twiki usage, but i've come to deal realise that to use twiki.org, i'm forced to maximse the browser on my 1600x1200 screen.

Please, can you start looking at smaller, lower resolution solutions?

-- SvenDowideit - 12 Jul 2005

Of course the IE screenshot is ridiculous. Have you read my remark about the xml declaration? How to get rid of this line?

• i recon the firefox screenshot is no less ridiculous. I read your remark, but i presumed you'd also fixed it later on, as firefox was pretty much just as bad.

Please have a look at SVN 4616. No more internal scrollbars. Smaller text.

• mmm, either http://develop.twiki.org/~develop/cgi-bin/configure did not update, or my css is cached, or i see no change with either firefox or ie (i'll look further tonite)

-- ArthurClemens - 12 Jul 2005

I second the request nuke or minimise the side whitespace panels.

Lack of consistency with regular twiki browsing experience in this context is just fine. Configure is an administration page, it's actually better if it stands out from the rest to some extent to highlight it's importance and that its behaviour is also outside the regular paradigm.

I love what you've done with the rendering of the configure script. It's much much easier to use now, but the whitespace and side scrolling just gets in the way.

-- MattWilkie - 12 Jul 2005

The xml declaration is removed. IE should render now more or less the same as Firefox.

-- ArthurClemens - 14 Jul 2005

Outstanding issues

Failed to include URL http://develop.twiki.org/~develop/cgi-bin/view/Bugs/WebSearch?skin=plain&summary=configure+script.*&status=New%7CDeferred%7CActioning%7CWaiting+for+Feedback Protocol scheme 'https' is not supported (LWP::Protocol::https not installed)