enterprise – Page 6

What makes an Enterprise Wiki Special

see me at OSDC 2008 – 3-5 December 2008. I’ll be giving a short talk and demo:

Traditional Wikis are about developing ‘legacy’ documents. Wikipedia is an asymptotic example where the ideal is to craft a perfect topic that accurately and concisely covers its subject matter.

Enterprise Wikis have a different focus :- they attempt to dynamically integrate processes, workflows and data, to support and automate an Enterprises Business Intelligence.

They provide integration points to provide not only an up to date status of an Enterprise, but to provide a Historical record of the development of that status, providing a Knowledge management and decision making framework.

Today, Enterprise Wiki’s are Social Knowledge management systems, recruiting peers throughout an organization, but leading into the future, Enterprise Wiki’s will become Knowledge driven Performance indicating Dashboards.

TWiki 4.2.3 JeOS Virtual Machine

TWiki 4.2 JeOS VM

mirror 1 460MB (USA) TWiki 4.2.3, (does not include VMware):

Easy installation on Windows, Linux and OSX!

Trivial upgrades of TWiki and TWiki Plugins

Summary: This package enables you to quickly and easily install a pre-configured TWiki 4.2 ‘software appliance’ on Windows, by using the free VMware Player or VMware Server – like another computer running within your computer. This generally performs better than a normal WindowsInstallCookbook approach and is easier to install than IndigoPerlCookbook (takes just 5 minutes, a bit like installing a hard disk that has TWiki and Linux pre-installed). Although running TWiki on Linux on top of Windows may seem complicated, it’s actually much simpler than installing TWikiOnWindows – no TWiki or Linux knowledge is needed to get a working TWiki installation!

This uses TWiki VM 4.2.3 released on 12 September 2008. It is installed using SvenDowideit‘s fosiki TWiki debian package repository to make upgrades, and installation of TWiki Plugins (with external dependencies) easy.

TWiki 4.2.3 Windows installer update

TWiki 4.2 for windows – with fully integrated native installers that will update your Computer with perl, apache and other tools needed to run TWiki.

The first of these installers released is the Windows TWiki installer, and includes

Apache 2.2, (apache_2.2.10-win32-x86-openssl-0.9.8i.msi)
ActiveState Perl (ActivePerl-5.8.8.824-MSWin32-x86-287188.msi)
Gnu Grep
Gnu rcs
Vanilla TWiki 4.2.3.

If the installer detects that you already have the same version (or later) of apache, perl, grep or rcs installed, it will only install the needed components. TWiki is installed into c:\Program Files\TWiki. The main change to the installer is that it now tries to detect non-English ‘Program Files’ directories and install into the right place.

Please download it, try it out and report your impressions, gripes, bugs and successes here on TWiki.org, or in the TWiki Bugs system.

Another TWiki innovation brought to you by fosiki, a WikiRing.com founding partner.

older releases of Solaris 10

If like me, you’re looking for an older release of Solaris – so you can replicate a client’s setup, you can find them at http://www.sun.com/software/solaris/releases.jsp

I couldn’t find it without help – as Sun’s web site is a study in how to make things impossible to find.

Now to install Solaris 10 update 3 (11/06) on my old ultra sparc 5 – yep, 10 year old tech. its been sitting in the garage for the last year or so, but as its built like a tank, it seems to start fine. I do wish the 10K 18.4G Quantum cheetah wasn’t quite such a painful noise though.

My client chooses to use the http://www.sunfreeware.com/ packages – which means that to get Perl 5.8.8 humming (and subversion so I could commit TWiki fixes), required me to install:

db-4.2.52.NC-sol10-sparc-local
diffutils-2.8.1-sol10-sparc-local
expat-2.0.1-sol10-sparc-local
gcc-3.4.6-sol10-sparc-local
gdbm-1.8.3-sol10-sparc-local
grep-2.5.1a-sol10-sparc-local
libiconv-1.9.2-sol10-sparc-local
libintl-3.4.0-sol10-sparc-local
libxml2-2.6.31-sol10-sparc-local
make-3.81-sol10-sparc-local
ncftp-3.2.1-sol10-sparc-local
neon-0.25.5-sol10-sparc-local
neon-0.28.3-sol10-sparc-local
openssl-0.9.8i-sol10-sparc-local
pcre-7.8-sol10-sparc-local
perl-5.8.8-sol10-sparc-local
rcs-5.7-sol10-sparc-local
subversion-1.4.4-sol10-sparc-local
swig-1.3.36-sol10-sparc-local
wget-1.11.4-sol10-sparc-local
zlib-1.2.3-sol10-sparc-local

and after all that, I’m having weird spillover issues with CPAN, caused by having the built in Perl 5.8.4 in the PATH before /usr/local/bin/perl (the 5.8.8)

So if you have more than one Perl installed, and want to use CPAN – BE CAREFUL to set the PATH to use your desired Perl’s path first – calling it directly will lead to problems.

Open source culture clash

Larry Augustin talks about the difference in how open source is selected and perceived between the US and Europe – roughly boiling down to:

US companies see Open source as a free ride they can take to getting their millions, whereas Europeans see Open source as a way to reduce risk, and localise expertise.

In many things Australia follows the US examples – but with their economy imploding due to criminally negligent stupidity, and the Australian government contemplating a 50% tax rebate for companies that work on open source – perhaps things are looking up here.

The TWiki.org open source project has a governance crisis for exactly this mismatch reason. The main code contributors for the last 5 years have been, well, me and Crawford Currie – both of us with very European ideals for the project, and most of the users and other contributors feel the same way. Then, last year, Peter, the project founder found some angel funding to build a startup to capitalize on his ownership of the trademark – very much in the US open source way.

This isn’t being handled cleverly enough PR wise – most likely because the ‘US’ open source style companies aren’t even aware that they are behind.

ever had Perl CPAN not work on your debian, even though you installed make etc?

CPAN, while incredibly useful, can be a pain, if you forget that you need to re-configure it after installing essential tools.

For example, if you make the mistake of setting up a basic, non-development Debian virtual machine, configure CPAN, try to use it, and on seeing ‘make’ errors like (from install Bundle::CPAN of all things) :
Running make test Can't test without successful make Running make install make had returned bad status, install seems impossible Running install for module Compress::Raw::Zlib Running make for P/PM/PMQS/Compress-Raw-Zlib-2.012.tar.gz Is already unwrapped into directory /root/.cpan/build/Compress-Raw-Zlib-2.012 Has already been processed within this session Running make test Can't test without successful make Running make install make had returned bad status, install seems impossible Running make for P/PM/PMQS/IO-Compress-Zlib-2.012.tar.gz Is already unwrapped into directory /root/.cpan/build/IO-Compress-Zlib-2.012 Has already been processed within this session Running make test Can't test without successful make Running make install make had returned bad status, install seems impossible

cpan>

You install make apt-get update ; apt-get install build-essential…, only to continue to see the same errors wizz past….

CPAN really truly needs to realise that the make settings are mis configured, and tell you.

What you need to do, is to tell your cpan about it by running:
cpan> o conf init

OR, if you’ve not yet messed (configured) up your cpan, install build-essential first.

And while you’re contemplating using cpan, think hard about trying dh-make-perl instead 🙂

Ideally, CPAN should be able to realise that it can’t call make if it does not know where it is – and point this fact out, rather than making it appear as though the package being installed has an issue.

Enterprise Wiki – Debian TWiki repository updated to TWiki 4.2.2

I’ve just updated the Experimental TWiki and Plugins repository. It now contains TWiki 4.2.2 and 226 Plugins, Contribs and Skins that you can simply apt-get install

To use them, add the following 2 lines to your /etc/apt/sources.list
deb http://distributedinformation.com/experimental/ experimental main contrib deb-src http://distributedinformation.com/experimental/ experimental main contrib

then type
apt-get update
to update the available packages.

you can now see all 226 packages with apt-cache search twiki-

and install (assuming you don’t have twiki installed yet)

apt-get install apache2 twiki

Now that I’ve added external dependancies to the repository, complex TWiki Plugin like ImageGalleryPlugin is as easy as apt-get install twiki-imagegalleryplugin and then enabling it via configure.

etch:~# apt-get install twiki-imagegalleryplugin Reading package lists... Done Building dependency tree... Done The following extra packages will be installed: defoma gsfonts libfreetype6 libgraphics-magick-perl libgraphicsmagick1 libice6 libjasper-1.701-1 libjpeg62 liblcms1 libmagick9 libpng12-0 libsm6 libtiff4 libwmf0.2-7 libx11-6 libx11-data libxau6 libxdmcp6 libxext6 libxml2 libxt6 perlmagick x11-common Suggested packages: defoma-doc psfontmgr x-ttcidfont-conf dfontmgr libfreetype6-dev graphicsmagick-dbg libjasper-runtime liblcms-utils libwmf-bin Recommended packages: libft-perl gs-gpl gs xml-core The following NEW packages will be installed: defoma gsfonts libfreetype6 libgraphics-magick-perl libgraphicsmagick1 libice6 libjasper-1.701-1 libjpeg62 liblcms1 libmagick9 libpng12-0 libsm6 libtiff4 libwmf0.2-7 libx11-6 libx11-data libxau6 libxdmcp6 libxext6 libxml2 libxt6 perlmagick twiki-imagegalleryplugin x11-common 0 upgraded, 24 newly installed, 0 to remove and 15 not upgraded. Need to get 11.2MB of archives. After unpacking 25.4MB of additional disk space will be used.

You will still need to use configure to enable Plugins.

Please report your experiences to me – bugs, gripes, you name it – its a work in progress. and I need your help!

Enterprise Wiki – TWiki 4.2.1 update released

This release makes over 150 improvements to the current Enterprise TWiki.

Along with many WYSIWYG Editing improvements, better UTF8 support, User mapping fixes and SEARCH improvements, This release contains an optimization that should see 4.2.1 being 10-30% faster than 4.2.0.

I will be updating the TWikiInstallers as soon as I can – the Windows installer should see the biggest impact, as I have managed to fix a number of SEARCH issues that are windows specific.

see TWikiRelease04x02x01 for more details.

Debian TWiki repository now with 212 TWiki Plugins, Contribs, Skins and more.

I’ve just updated the Experimental TWiki and Plugins repository. It now contains TWiki 4.2.0 and 212 Plugins, Contribs and Skins that you can simply apt-get install

then type
apt-get update
to update the available packages.

you can now see all 212 packages with apt-cache search twiki-

and install (assuming you don’t have twiki installed yet)

apt-get install apache2 twiki

and TWiki Contrib installation is as easy as

apt-get install twiki-bugscontrib

You will still need to use configure to enable Plugins.

Please report your experiences to me – bugs, gripes, you name it – its a work in progress. and I need your help!

defense against the dark arts? (Cross site scripting and Cross Site forgery)

I was having a discussion with someone on IRC about how TWiki is vulnerable to Cross-site scripting and Cross-site request forgery, and we realized that there are 2 possible approaches to securing TWiki effectively (both requiring a unique magic number for all URLs):

add a pre process to the TWiki::UI system, requiring a valid and unique magic, and a post process step between rendering and output to the browser
use a small proxy system between TWiki and browsers to add and validate the magic

is actually still risky as all scripts still are able to output directly to the browser using a =print= statement, thus giving the user urls that may not have a necessary magic in the url, or similarly for AddOns that persist in not using resthandlers.

whereas 2. abstracts the security from the application server, in much the same way as it is for ssl – goodness all round.

So – I wonder if there is such a proxy already?

There are also massive performance reasons why you should always have a proxy between browsers and heavy application servers like TWiki – this too could do with filling out.Securing TWiki is not as simple as converting all actions to POST (ie using proper REST / HTTP) because there are too many legacy conveniences, allowing GET URL’s to act upon the data. But, by delegating the securing of the transactions to an external wrapper, I think we can avoid these flaws.
see Wikipedia on Cross Site Scripting and Cross-site request forgery