Softpanorama
(slightly skeptical) Open Source Software Educational Society

May the source be with you, but remember the KISS principle ;-)

Google   

Perl Wiki

News See also Recommended Links Kwiki UseModWiki Twiki
          Etc

Wiki is a development that reminds Usenet groups but with the ability to edit somebody else posts.

Typically they use simplified, very primitive markup language and not HTML. Although this is a peripheral issue a lot of coding efforts are sunk into reinventing the bicycle.

The balance of author control/democracy here is slated toward democracy and so far this proved to be a workable solution where abuse does not derail most projects. The most famous Wiki is probably Wikipedia.

Most small modifiable Perl Wiki projects in Freshmeat are abandonware.  In essence Wiki is a poor man content management system and most small content management systems can be used along or instead. See Comparison of content management systems - Wikipedia, the free encyclopedia

Another similar category is Internet forum software which is closer to traditional Usenet forums.

Notes:
  • Those pages are written by people for whom English is not a native language. Some amount of grammar and spelling errors should be expected.
  • This is a Spartan WHYFF (We Help You For Free) site. It cannot replace the best teachers and the best books.
  • The site contain some obsolete pages as it develops like a living tree... Some links on older pages are broken. Please try to use Google, Open directory, etc. to find a replacement link (see HOWTO search the WEB for details). We would appreciate if you can mail us a correct link.

Search Amazon by keywords:

 Google   
Open directory
Research Index
 
Old News ;-)

[June 21, 2006] Assorted findings:

[Feb 27, 2006] Using Wikis and Blogs to Ease Administration Linux Journal Using Wikis and Blogs to Ease Administration By Ti Leggett on Mon, 2006-02-27 02:00. SysAdmin

This tutorial on TWiki and WordPress shows how wikis and blogs can be useful for system administration and documentation. System administration can be like sailing a ship. You must keep your engines running smoothly, keep your crew and the harbors notified and up to date and also maintain your Captain's log. You must keep your eye on the horizon for what is coming next. Two technologies have emerged over the past few years that could help keep you on course, wikis and blogs.

Maintaining Good Documentation

I find that one of the most difficult aspects of system administration is keeping documentation accurate and up to date. Documenting how you fixed a pesky problem today will help you remember how to fix it months later when it occurs again. If you ever have worked with others, you realize how critical good documentation is. Even if you are the only system administrator, you still will reap the benefits of good documentation, even more so if another sysadmin is ever brought on board.

Some goals of a good documentation system should be:

Unfortunately, keeping your documentation up to date can be a full-time job in itself. Documenting, though not a very glamorous task, certainly will pay off in the long run.

Why a Wiki?

This is where a wiki comes in. From Wikipedia: "a wiki is a type of Web site that allows users to add and edit content and is especially suited for constructive collaborative authoring."

What this means is a wiki allows you to keep and edit your documentation in a central location. You can access and edit that documentation regardless of the platform you are using. All you need is a Web browser. Some wikis have the ability to keep track of each revision of a changed document, so you can revert to a previous version if some errant changes are made to a document. The only obstacle a new user must overcome is learning the particular markup language of your wiki, and sometimes even this is not completely necessary.

One of a wiki's features is also one of its drawbacks. Wikis are pretty free flowing, and although this allows you to concentrate on getting the documentation written quickly, it can make organization of your wiki rapidly spiral out of control. Thought needs to be put into how the wiki is organized, so that topics do not get stranded or lost. I have found that making the front page a table of contents of all the topics is very handy. However you decide to organize your wiki, make sure it is well understood by everyone else. In fact, a good first document might be the policy describing the organization of the wiki!

TWiki

There are several open-source wikis available, such as MediaWiki [see Reuven M. Lerner's article on page 62 for more information on MediaWiki] and MoinMoin, each with its own philosophy on markup and layout, but here we concentrate on TWiki. Some of TWiki's benefits are:

The most current stable release at this time is Cairo, or TWiki20040904. It was released, as the name suggests, on September 4, 2004, and it has been proven to be very stable. However, it does lack some of the features of the current beta release, Dakar, that I find to be very useful. The Dakar release we use here is TWikiRelease2005x12x17x7873beta.

Installing TWiki is relatively easy, but still needs work. I hope, as the beta progresses, we will see improvements in ease of installation and upgrading along with clearer documentation.

First, you must create the directory where you want to install TWiki, say /var/www/wiki. Next, untar the TWiki distribution in that directory. Then you must make sure that the user with rights to run CGI scripts (usually apache or www-data), owns all of the files and is able to write to all files:

# install -d -o apache /var/www/wiki
# cd /var/www/wiki
# tar zxf /path/to/TWikiRelease2005x12x17x7873beta.tgz
# cp bin/LocalLib.cfg.txt bin/LocalLib.cfg
# vi bin/LocalLib.cfg lib/LocalSite.cfg
# chown -R apache *
# chmod -R u+w *

Now copy bin/LocalLib.cfg.txt to bin/LocalLib.cfg, and edit it. You need to edit the $twikiLibPath variable to point to the absolute path of your TWiki lib directory, /var/www/wiki/lib in our case. You also must create lib/LocalSite.cfg to reflect your specific site information. Here is a sample of what might go into LocalSite.cfg:

# This is LocalSite.cfg. It contains all the setups for your local
# TWiki site.
$cfg{DefaultUrlHost} = "http://www.example.com";
$cfg{ScriptUrlPath} = "/wiki/bin";
$cfg{PubUrlPath} = "/wiki/pub";
$cfg{DataDir} = "/var/www/wiki/data";
$cfg{PubDir} = "/var/www/wiki/pub";
$cfg{TemplateDir} = "/var/www/wiki/templates";
$TWiki::cfg{LocalesDir} = '/var/www/wiki/locale';

Here is a sample section for your Apache configuration file that allows this wiki to run:


ScriptAlias /wiki/bin/ "/var/www/wiki/bin/"
Alias /wiki "/var/www/localhost/wiki"
<Directory "/var/www/wiki/bin">
    Options +ExecCGI -Indexes
    SetHandler cgi-script
    AllowOverride All
    Allow from all
</Directory>
<Directory "/var/www/wiki/pub">
    Options FollowSymLinks +Includes
    AllowOverride None
    Allow from all
</Directory>
<Directory "/var/www/wiki/data">
    deny from all
</Directory>
<Directory "/var/www/wiki/lib">
    deny from all
</Directory>
<Directory "/var/www/wiki/templates">
    deny from all
</Directory>
 

TWiki comes with a configure script that you run to set up TWiki. This script is used not only on initial install but also when you want to enable plugins later. At this point, you are ready to configure TWiki, so point your browser to your TWiki configure script, http://www.example.com/wiki/bin/configure. You might be particularly interested in the Security section, but we will visit this shortly. Until you have registered your first user, you should leave all settings as they are. If the configure script gives any warnings or errors, you should fix those first and re-run the script. Once you click Next, you are prompted to enter a password. This password is used whenever the configure script is run in the future to help ensure no improper access.

Once you have completed the configuration successfully, it is time to enter the wiki. Point your browser to http://www.example.com/wiki/bin/view, and you are presented with the Main web. In the middle of the page is a link for registration. Register yourself as a user. Be sure to provide a valid e-mail address as the software uses it to validate your account. Once you have verified your user account, you need to add yourself to the TWikiAdminGroup. Return to the Main web and click on the Groups link at the left, and then choose the TWikiAdminGroup. Edit this page, and change the GROUP variable to include your new user name:

   Set GROUP = %MAINWEB%.TiLeggett
   Set ALLOWTOPICCHANGE = %MAINWEB%.TWikiAdminGroup

The three blank spaces at the beginning of each of those lines are critical.

These two lines add your user to the TWikiAdminGroup and allow only members of the TWikiAdminGroup to modify the group. We are now ready to enable authentication for our wiki, so go back to http://www.example.com/wiki/bin/configure. Several options provided under the Security section are useful. You should make sure the options {UseClientSessions} and {Sessions}{UseIPMatching} are enabled. Also set the {LoginManager} option to TWiki::Client::TemplateLogin and {PasswordManager} to TWiki::Users::HtPasswdUser. If your server supports it, you should set {HtPasswd}{Encoding} to sha1. Save your changes and return to the wiki. If you are not logged in automatically, there is a link at the top left of the page that allows you to do so.

Now that you have authentication working, you may want to tighten down your wiki so that unauthorized people do not turn your documentation repository into an illicit data repository. TWiki has a pretty sophisticated authorization system that is tiered from the site-wide preferences all the way down to a specific topic. Before locking down the Main web, a few more tasks need to be done. Once only certain users can change the Main web, registering new users will fail. That is because part of the user registration process involves creating a topic for that user under the Main web. Dakar has a user, TWikiRegistrationAgent, that is used to do this. From the Main web, use the Jump box at the top left to jump to the WebPreferences topic. Edit the topic to include the following four lines and save your changes:

Set ALLOWTOPICRENAME = %MAINWEB%.TWikiAdminGroup
Set ALLOWTOPICCHANGE = %MAINWEB%.TWikiAdminGroup
Set ALLOWWEBRENAME = %MAINWEB%.TWikiAdminGroup
Set ALLOWWEBCHANGE = %MAINWEB%.TWikiAdminGroup,
 -->;%MAINWEB%.TWikiRegistrationAgent

This allows only members of the TWikiAdminGroup to make changes or rename the Main web or update the Main web's preferences. It also allows the TWikiRegistrationAgent user to create new users' home topics when new users register. I have included a patch that you must apply to lib/TWiki/UI/Register.pm as well. The patch follows, but you can also download the patch from the LJ FTP site (see the on-line Resources):

--- lib/TWiki/UI/Register.pm.orig       2006-01-04 01:34:48.968947681 -0600
+++ lib/TWiki/UI/Register.pm    2006-01-04 01:35:48.999652157 -0600
@@ -828,11 +828,12 @@
 
     my $userName = $data->{remoteUser} || $data->{WikiName};
     my $user = $session->{users}->findUser( $userName );
+    my $agent = $session->{users}->findUser( $twikiRegistrationAgent );
     $text = $session->expandVariablesOnTopicCreation( $text, $user );
 
     $meta->put( 'TOPICPARENT', { 'name' => $TWiki::cfg{UsersTopicName}} );
 
-    $session->{store}->saveTopic($user, $data->{webName},
+    $session->{store}->saveTopic($agent, $data->{webName},
                                  $data->{WikiName}, $text, $meta );
     return $log;
 }

Otherwise, new users' home directories will fail to be created and new user registration will fail. Once you have verified that the Main web is locked down, you should do the same for the TWiki and Sandbox webs.

When you are done configuring TWiki, you should secure the files' permissions:

# find /var/www/wiki/ -type d -exec chmod 0755 {} ';'
# find /var/www/wiki/ -type f -exec chmod 0400 {} ';'
# find /var/www/wiki/pub/ -type f -exec chmod 0600 {} ';'
# find /var/www/wiki/data/ -type f -exec chmod 0600 {} ';'
# find /var/www/wiki/lib/LocalSite.cfg -exec chmod 0600 {} ';'
# find /var/www/wiki/bin/ -type f -exec chmod 0700 {} ';'
# chown -R apache /var/www/wiki/*
As I mentioned before, TWiki has a plugin system that you can use. Many 
							plugins are available from the TWiki Web site. Be 
							sure the plugins you choose have been updated for 
							Dakar before you use them.

Keeping Your Users in the Know

One important aspect of system administration that is sometimes overlooked is keeping users informed. Most users like to know when there is new functionality available or when resources are down or not available. Not only does it make users happier to be kept informed, but it also can make your life easier as well. The last thing you want to do when the central file server is down is reply to users' questions about why they cannot get to their files. If you have trained your users to look at a central location for status of the infrastructure first, all you have to do after notification of a problem is post to this central place that there is a problem. Mailing lists also are good for this, but what if the mail server is down? Some people, for instance your boss or VP of the company, might like to know what the status is of things as they happen. These updates might not be suitable to send out to everyone daily via e-mail. You could create yet another mailing list for these notifications, but you also might consider a blog.

If you are not familiar with a blog, let us refer back to Wikipedia: "a blog is a Web site in which journal entries are posted on a regular basis and displayed in reverse chronological order."

The notion of a blog has been around for centuries in the form of diaries, but blogs recently have had an explosion on the Internet. Many times a blog is started as someone's personal journal or as a way to report news, but blogs can be extremely useful for the sysadmin.

Blogs can help a sysadmin give users an up-to-the-minute status of what they are doing and what the state of the infrastructure is. If you faithfully update your blog, you easily can look back on what you have accomplished so you can make your case for that raise you have been hoping for. It also will help you keep track of what your coworkers are doing. And, with many blog software packages providing RSS feeds, users can subscribe to the blog and be notified when there are new posts.

... ... ...

Wrapping Up

I hope that after this whirlwind tour of wikis and blogs you have come to see how they can be beneficial to help your shop run a smoother ship and provide your users with all the information they might want. Just as there are many different sails to keep your ship sailing, there are many different wiki and blog software packages out there. The right package for you is the one that keeps your users happy and you productive.

Resources for this article: www.linuxjournal.com/article/8832.

Ti Leggett (ti@daleggetts.com) is a full-time system administrator. When he's not working, he might be found playing his Gibson B-25 or doing some home improvements or wood working.

freshmeat.net Project details for ReciPants

ReciPants is a Web-based recipe manager that supports Postgres, MySQL, and Oracle databases. It features searching, categories, exporting, scaling, emailing recipes, password reminders, secure user cookies, internationalization, and fully customizable templated output.

ONLamp.com Which Open Source Wiki Works For You

Kwiki

The Kwiki motto is a "A Quickie Wiki that's not Tricky." Installing it is pretty straightforward for a site you admin: just install the Perl package (from CPAN or elsewhere), and then type kwiki-install in a CGI-served directory to create an instance. Installing Kwiki on a server you are not an admin of is more complicated but doable.

I found the Kwiki markup not powerful. Some things are impossible with it, such as hyperlinking an arbitrary piece of text to an email address (mail fooish). I also could not find how to link a Wiki page with a text link different from the Wiki page name (like this link to LinkedWikiWikiPage). There is also no support for attachments, HTML markup as an alternative to the Wiki markup, etc. It is disappointing.

Kwiki can use either RCS or Subversion for version control. (Those who wish to use Subversion should check out the corrected Kwiki version as the CPAN Kwiki does not work with the up-to-date Subversion.) Kwiki is easily customizable and has several Kwiki enhancements available. Generally, however, they are less powerful than TWiki's.

All in all, Kwiki is easy to install and customize, but its formatting rules are lacking.

... ... ...

UseModWiki

UseModWiki is a Wiki engine written in Perl. Anecdotally, Wikipedia used this first before re-implementing their current engine. Other sites also use UseModWiki.

UseModWiki is very simple to set up and upgrade. It has a rich syntax, and allows for arbitrary characters in page names. It also supports using some HTML tags instead of the WikiWiki markup. It has other nice features, including search, a list of recent changes, and page history.

For simple Wikis, UseModWiki is a very good choice. I recommend choosing between it and PmWiki based on the feature list of both Wikis.

Recommended Links

In case of broken links please try to use Google search. If you find the page please notify us about new location
Google     

 

Kwiki

The Kwiki motto is a "A Quickie Wiki that's not Tricky." Installing it is pretty straightforward for a site you admin: just install the Perl package (from CPAN or elsewhere), and then type kwiki-install in a CGI-served directory to create an instance. Installing Kwiki on a server you are not an admin of is more complicated but doable.

I found the Kwiki markup not powerful. Some things are impossible with it, such as hyperlinking an arbitrary piece of text to an email address (mail fooish). I also could not find how to link a Wiki page with a text link different from the Wiki page name (like this link to LinkedWikiWikiPage). There is also no support for attachments, HTML markup as an alternative to the Wiki markup, etc. It is disappointing.

Kwiki can use either RCS or Subversion for version control. (Those who wish to use Subversion should check out the corrected Kwiki version as the CPAN Kwiki does not work with the up-to-date Subversion.) Kwiki is easily customizable and has several Kwiki enhancements available. Generally, however, they are less powerful than TWiki's.

All in all, Kwiki is easy to install and customize, but its formatting rules are lacking.

... ... ...

 

UseModWiki

UseModWiki is a Wiki engine written in Perl. Anecdotally, Wikipedia used this first before re-implementing their current engine. Other sites also use UseModWiki.

UseModWiki is very simple to set up and upgrade. It has a rich syntax, and allows for arbitrary characters in page names. It also supports using some HTML tags instead of the WikiWiki markup. It has other nice features, including search, a list of recent changes, and page history.

For simple Wikis, UseModWiki is a very good choice. I recommend choosing between it and PmWiki based on the feature list of both Wikis.

Twiki

TWiki - Enterprise Collaboration Platform TWiki is a cgi-bin script written in Perl. It reads a text file, hyperlinks it and converts it to HTML on the fly. TWiki is GPLed software. The Perl CGI source code, templates and documentation is available for free.

 

Etc

 

deplate 0.6a
 by tlink - Fri, Oct 29th 2004 11:11 PDT  

 

About: deplate is a tool for converting documents written in an unobtrusive, wiki-like markup to LaTeX, DocBook, HTML, or "HTML slides". It supports embedded LaTeX code, footnotes, citations, bibliographies, automatic generation of an index, etc. In contrast to many wiki engines, it is made for "offline" use as a document preparation tool. In this respect it is similar to tools like aft or txt2tags. It aims to be modular and easily extensible. It is the accompanying converter for the Vim viki plugin.

Changes: Two bugs that prevented it from running on an OS with case-sensitive file names or with the Win32 exe have been fixed. There are minor amendments.

This site documents the Faq-O-Matic. The Faq-O-Matic is a CGI-based system that automates the process of maintaining a FAQ (or Frequently Asked Questions list). It allows visitors to your FAQ to take part in keeping it up-to-date. A permission system also makes it useful as a help-desk application, bug-tracking database, or documentation system. Jon wrote an article about the FAQ-O-Matic that appeared in the USENIX ;login: newsletter: http://www.usenix.org/publications/login/1998-6/faq.html.

This documentation itself is, naturally, maintained with Faq-O-Matic. Hence the weird title. If you see anything that can use updating, please do fix it! If you just want to play around, check out the (Xref) Playground.
 
The Users' Guide tells new users what a FAQ-O-Matic is, how to read it, and how to contribute to it.

The Administrators' Guide tells FAQ administrators how to download, install and maintain a FAQ-O-Matic. If you want to start your own FAQ-O-Matic, look here.

The Playground is a place where anyone can experiment with the FAQ-O-Matic by creating their own answers.

The List Of Faq-O-Matics is a list of websites that use FAQ-O-Matic.

Here are Postcards I have received from people who use FAQ-O-Matic.

This is the Faq-O-Matic Sourceforge page: http://sourceforge.net/projects/faqomatic
lost+found

Jon Howell is a graduate student working with David Kotz at Dartmouth College. His research is on single-system-image operating environments that span adminstrative domains. He also enjoys robotics, web glue, and kernel tweaking.

What is the best way to maintain a Frequently Asked Questions list? Traditional FAQs are maintained by hand and often become outdated as the maintainer loses interest in the task. Mailing list archives can be helpful, but are often too disorganized. When I found myself answering the same FAQs about Linux for PowerPC and MkLinux last year, I faced this very problem. I am far too lazy to commit to maintaining a FAQ, but the mailing list archives were not significantly reducing the load of redundant questions.

Solution Design

The FAQ-O-Matic is a Web-editable FAQ designed to offer a middle ground. Because the general public can edit it, it is less likely to become neglected and stale like a manually maintained FAQ. Because changes are submitted where the FAQ is read, one can be rather lazy and still contribute to the FAQ. No one person has the responsibility of maintaining the entire document.

Because a FAQ-O-Matic is topically and hierarchically organized, browsing solutions is easier than it is in mailing list archives. Queries on mailing list archives can return matches for old, outdated information and miss newer answers. The topical organization of a FAQ-O-Matic helps avoid this problem as well.

A search function makes FAQ-O-Matic as accessible as a mailing list archive. Another function lists recently changed items, so users can check back for changes if they did not find a satisfying answer the first time they looked. There is a command to show entire categories in one HTML file, to facilitate printing or export of the FAQ.

How It Works in Practice

I launched the first FAQ-O-Matic by seeding it with about 60 or 70 answers gleaned from recent list postings. Although this opposed my laziness philosophy, I knew that I would not be responsible for keeping the answers up to date. Then I began advertising it by answering questions with URLs to the FAQ-O-Matic.

One problem with the initial implementation was that answers were identified by their location in the topic hierarchy. So if you sent out a URL to a FAQ-O-Matic answer and the database was subsequently reorganized, that URL would go sour.

I initially thought allowing people to submit questions without answers would help define the structure of the FAQ by reserving spaces for answers when they became available. Instead, people who were too lazy to search would post poorly considered questions in inappropriate categories.

The submission page asked users to leave an email address with their comment, but people often forgot or inserted text between previous text and its attribution. Furthermore, although the server uses RCS to protect against wholesale vandalism, there was no way to trace subtle, intentional corruption of the database.

The FAQ-O-Matic allowed the entry of HTML tags, so users could supply links and formatting information for their answers. However, other than links, HTML was rarely used to good effect. Instead, it often made for inconsistent appearance as people appended to existing answers and as HTML tags fought with the formatting generated by the CGI script. Furthermore, code segments pasted into the FAQ-O-Matic would mysteriously lose < and & symbols.

Finally, I found that I had to put in a certain amount of effort moving answers around to keep them organized as new answers showed up. This was compounded by the difficulty of performing this sort of administration on the first implementation of FAQ-O-Matic.

Version 2

Over the summer, I rewrote the FAQ-O-Matic to address these problems. First, each answer is now assigned a permanent ID number. This solves the sour URL problem and also provides a facility for "see also" links inside the FAQ.

I posted a policy disallowing questions without answers, which trivially solved the second problem.

The new version has an authentication scheme that verifies email addresses by sending a secret validation code to the given address. Thus each submission is attributed to a real email address, and intentional corruption, once noticed, can be traced and rolled back.

FAQ-O-Matic 2 no longer allows HTML tags; they are displayed as entities (&lt;). This prevents code from becoming corrupted and enforces a uniform (if bland) appearance. Links are supported heuristically by detecting things that look like links (http://...) and generating HTML links on the fly. Internal links are supported with a special URL that begins "faqomatic:"

Version 2 also has support for reorganizing answers and categories from the Web interface. This facility might allow a Web user to moderate a section of the FAQ and care for its organization. Moderators can request that they receive mail whenever any answer in their area is changed, minimizing the effort associated with the moderation task.

The 1998 LinuxPPC CD was announced in January, prompting an estimated 4,500 people to visit the FAQ-O-Matic on <www.dartmouth.edu> in one day. Because every request required service by a Perl CGI, the memory pressure overloaded the server, and the FAQ-O-Matic had to be throttled. In response to that event, version 2.6 adds a server-side HTML cache, so that people who are only reading the FAQ receive HTML directly from the Web server, without the cost of invoking the CGI.

Other Uses

Because FAQ-O-Matic has an authentication scheme, it made sense to give it flexible authorization as well. The FAQ can be configured to be very open, not even requiring mail-back email secrets, to encourage the shy, lazy, or anonymous contributor at the expense of accuracy of attributions.

Alternatively, it can be set to allow only assigned moderators to modify the FAQ. In this arrangement, it is suitable for use as a help desk database: only help desk operators can modify the database, but it is available for all to read.

Numbers

The Linux on PowerPC FAQ-O-Matic has been available for 15 months. In that time, about 75,000 different people (IP addresses) have seen it, and it has received 1,500 submissions. On average, visitors access it about ten times. A few dozen people claim to be running their own FAQ-O-Matics, some for internal projects, others for Internet-accessible sites.

Conclusion

The FAQ-O-Matic has turned out to be a successful system for documenting the Linux on PowerPC projects. It is more organized than a mailing list archive, but avoids going stale as traditional FAQs often do. It allows a division of labor in maintaining both answers and the overall organization of the FAQ. And it has access control features that make it suitable for other applications. To try it out, visit the FAQ-O-Matic at <http://www.dartmouth.edu/cgi-bin/cgiwrap/jonh/faq.pl>.

Copyright © 1996-2008 by Dr. Nikolai Bezroukov. www.softpanorama.org was created as a service to the UN Sustainable Development Networking Programme (SDNP) in the author free time. Submit comments This document is an industrial compilation designed and created exclusively for educational use and is placed under the copyright of the Open Content License(OPL). Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

Standard disclaimer: The statements, views and opinions presented on this web page are those of the author and are not endorsed by, nor do they necessarily reflect, the opinions of the author present and former employers, SDNP or any other organization the author may be associated with. We do not warrant the correctness of the information provided or its fitness for any purpose.

Last modified: