Many companies these days are looking at groupware solutions to facilitate in-house communications. Groupware applications allow employees to communicate effectively by sending quick messages, sharing calendars, spreading news, and so forth. Some groupware applications also double as e-mail or news clients.
Groupware applications have become quite popular among many companies—and even among home users with networked systems that various family members access. Because of the versatility of groupware applications, they can be used almost anywhere and by anyone. Even single-user environments can take advantage of some groupware applications that act as personal information managers.
Probably the best-known groupware application is Microsoft Exchange. The drawback to Exchange, however, is that it runs only under Windows and is accessible only to Windows clients. This leaves Linux users or environments that use various other operating systems with a bit of a problem.
Fortunately, there are a growing number of Linux-based groupware applications. Probably the most notable and most ambitious is the Evolution program by Ximian (formerly HelixCode). The problems with Evolution are two-fold, however. First, it is currently in a beta status, and the usual disclaimers apply: It will crash, it will lose your mail, it is generally unstable, and it shouldn’t be used in a production environment. The other problem is that, like Exchange, it is designed for a single operating system.
So how do you overcome the differences of a mixed network where some clients may be Windows machines and some Linux, with perhaps a few Macs thrown into the mix? The answer is simple and in front of you right now. The interface is your Web browser, and the medium is standard HTML. The server is a simple Apache server running PHP and MySQL. Sound impossible? Ask the folks who wrote TWIG: The Web Information Gateway.
In this Daily Drill Down, we’ll take a look at installing and using TWIG by taking advantage of some of its many features. TWIG provides e-mail messaging via IMAP, Usenet newsgroups, a calendar, a contact manager, to-do lists, and Web bookmarks. And the best part is that TWIG is 100 percent free and open source. It utilizes a free programming language (PHP), runs on a free Web server (Apache), which in turn runs on a free operating system (Linux), and uses a free database back end (either MySQL or PostgreSQL).
To install TWIG, you will need a Linux computer to use as the Web server. This machine should have PHP version 3 or higher, Apache, and MySQL or PostgreSQL for the back end. We’ll assume that you’re installing TWIG on an intranet to be used internally by your company. The Web server should be inaccessible to the Internet unless you’re prepared to protect TWIG from unauthorized access by using .htaccess files in Apache to require authentication. This might be useful if you want employees on the road to have access to TWIG, but you’d best ensure its security if you don’t want just anyone looking at your employees’ calendars or schedules.
Go to the TWIG Web site and download the latest version of TWIG, which as of this writing is 2.6.2. Download the twig-2.6.2.tar.gz file and save it to your hard drive.
Let’s assume that your Web server root is /var/www/html, following the current FHS standards. Change to this directory and unarchive the TWIG archive by issuing these commands:
tar xvzf twig-2.6.2.tar.gz
mv twig-2.6.2 twig
This will unarchive the package and rename the subdirectory twig-2.6.2/ to twig/, which makes it a little easier for your employees to remember.
Change to your new twig/ directory and then again to the config/ subdirectory, which is where TWIG stores its configuration files. The next step is to configure TWIG so that you can use it.
Use your favorite text editor to edit the config.inc.php3 file. This is where the bulk of your configuration will take place. The configuration options are done through a series of PHP variables that you’ll need to modify. We’ll look at the ones you need to change to get you up and running as quickly as possible. There are, of course, other variables you can modify, such as the color of various elements on the page, but we’ll leave these up to you.
The first variable to modify is $config[“fromdomain“]. This variable defines which domain to use when sending mail from within TWIG. You would use something like “mydomain.com“ here.
The $config[“basedir“] variable defines the URL path to TWIG on your Web browser. This would be “/twig“ if you unarchived TWIG in the way previously specified.
The $config[“auth“] variable determines the authorization type. You can choose either “basic“ or “forms“. The best method to use is “forms“, as it will display a form asking for the user’s login ID and password.
The $config[“auth_provider“] variable determines the authorization method. You can choose a variety of authorization types here: “imap-new“, “imap“, “sqltable“, “mysql“, “pgsql“, “ldap“, “sqlimap“, “sqlopen“, or “nntp“. Some of these authorization types require the users to have access to the required server. For example, if you choose “nntp“, the user must be prompted for a username and password for the defined news server. If TWIG can properly connect to the news server with that username and password, the user will be allowed access. The same follows for the other authorization mechanisms. If you choose “mysql“, that username and password must be allowed to access the MySQL server. If you do not wish to use e-mail and news with TWIG, or you do not allow your employees direct access to the database, you’ll want to use “sqltable“ as the authorization mechanism. This will allow you to enter the user’s name and password into the database, and TWIG will use that information to determine whether or not the user has access to the site.
The $config[“security“] variable determines the type of security to use, either basic or advanced. I recommend using basic right now, as the advanced security settings are more work to configure. The basic security gives users access to everything in TWIG. Using advanced, you can limit users to what they can or cannot access by using ACL-based security. The advanced setting defaults to denying users access to everything, and you need to specifically tell TWIG to allow users access to certain functions. You can change from basic to advanced at any time.
The $config[“groups“] variable determines the type of group support to use. You can choose None for no group support, Standard for TWIG’s standard group support, or Personal. The default is Standard and it should be used. If you select None, the user will be able to file items into a single group that only that user can see, so no data can be shared between users. The Standard setting allows for items to be either saved to a shared group or a personal group. The Personal setting allows users to file items into multiple groups but does not allow them to be viewed by others.
The $config[“spellcheck“] variable determines the external spell checker to use. You can leave this blank if you do not wish to use one, or you can use something like /usr/bin/ispell -a to use the ispell program. A number of Linux spell-checking programs are available, but ispell is perhaps the most widely known. The default is to use aspell, which is another spell checker for Linux. You must provide the appropriate parameter to allow the spell checker to run over piped information: With aspell or ispell, this is the -a parameter.
Further down in the file, you will see some settings for the IMAP server. If you do not use IMAP or do not plan to use e-mail within TWIG, you can skip this section. The default for the IMAP server is the localhost, the port to use is 143, and the default mail path is the home directory. Change these if you’re using a remote IMAP server.
You can also configure the SMTP server to send mail through. The $config[“mail_sender“] variable should be set to Relay if the SMTP server is a relay server and to Internal if not. The default SMTP server is the localhost, and the default port is 25.
You can also configure the NNTP server to allow your clients access to newsgroups. The default NNTP server is on the localhost, and the default port is 119, which is standard. If any of these are different, change the values of the variables.
The next file to edit is the dbconfig.inc.php3 file, which is in the same directory. Concern yourself with only the first few lines. The $dbconfig[“sqlserver“] variable should point to the machine that runs the database. In most cases, this will probably be localhost. Change the $dbconfig[“sqlusername“] and $dbconfig[“sqlpassword“] variables to match the access rights to your database. Let’s say the username is twig and the password is secret.
Leave the $dbconfig[“defaultdb“] variable as twig. This tells TWIG the database name to use.
Finally, change the $dbconfig[“sqltype“] variable to either mysql or pgsql, depending on whether you are using MySQL or PostgreSQL, respectively. You can also tell TWIG to use other databases, such as Oracle, MS SQL, or Sybase. Select the appropriate value, depending on which database you’re using. For this Daily Drill Down, we’ll be using MySQL, so we will leave it at the default value of mysql.
Editing other files
There are a number of other files you can edit to personalize your TWIG system. The other files in the config/ directory are used to customize various visual features of TWIG, so I’ll briefly describe them.
The header.inc.php3 file is used to customize information that goes on the top of every page. The footer.inc.php3 file does the same but for the bottom of each page.
The announcements.php3 file is used to display announcements on the main login page. If this file doesn’t exist, nothing is displayed.
The login.header.inc.php3, login.form.inc.php3, and login.footer.inc.php3 files customize the login page’s header, body, and footer, respectively.
The mainmenu.inc.php3 file displays the items shown on the main menu bar. If you want to globally disable a feature in TWIG (for example, remove the News menu item if you do not use TWIG to read newsgroups), you would do so here.
The mailfooter.inc.php3 file contains text to append to the bottom of every outgoing message.
The newusergroups.inc.php3 file contains the default groups to add a new user to if you’re using advanced security.
The defaults.inc.php3 file contains various system-wide defaults for many of TWIG’s features. You will definitely want to go through this file at some point to customize many of the default options for dealing with TWIG. The file is fairly well commented and should be easy to edit. For the most part, the defaults listed there should be enough to allow you to fully use TWIG.
Accessing the database
The next step after you have edited the configuration files is to change to the twig/setup/ directory. This directory contains the table structures for the various databases you can use with TWIG. Because we’re using MySQL, we will only be concerned with the twig.table.mysql file. If you changed any of the database names in the dbconfig.inc.php3 file, you’ll need to modify this file to reflect those changes. If you left everything at their defaults, you should be able to use this file immediately.
You must create the database in MySQL and give your TWIG user access to it. To do this, you must have write access to your MySQL server. For this illustration, we’ll assume that you have root access to the MySQL server, so execute the following command:
mysql -u root -p
This will prompt you for the MySQL root user’s password. (This may differ from the system root user’s password!) Once you’re in the MySQL server, execute the following commands to create the database and give your TWIG user—in our case, twig—access to the database with the password secret:
mysql> CREATE database twig;
Query OK, 1 row affected (0.00 sec)
mysql> GRANT ALL ON twig.* TO twig@localhost IDENTIFIED BY ‘secret’;
Query OK, 0 rows affected (0.02 sec)
Now, you need to import the table structure into the database using the twig.table.mysql file mentioned earlier. Execute the following command:
mysql -u twig -p twig <twig.table.mysql
You will then be asked for the twig user’s password, which in our case is secret. Once you are returned to a shell prompt, your table structure has been imported into the TWIG database.
If you chose to use the sqltable authentication method in TWIG, which was configured by the $config[“auth_provider“] variable in config.inc.php3, you have one more step to go.
The table used to store the user information if you’re using sqltable is the twig_accounts table. Before you can use TWIG, you will need to insert a user who will have access to the site. To do this, enter MySQL as your TWIG user by executing
mysql -u twig -p
Once you have logged into MySQL, execute the following commands:
mysql> USE twig;
mysql> INSERT INTO twig_accounts (username, password) VALUES (“joe“,“joepass“);
Query OK, 1 row affected (0.00 sec)
This will allow Joe, with the username joe and the password joepass, to log in to TWIG. And now you’re ready to log in to TWIG for the first time!
Fire up your browser and point it to the machine running TWIG. Let’s assume that the Linux server running TWIG is called twig.mydomain.com, so we would point our browser to http://twig.mydomain.com/twig/. Log in as Joe with his password and you will be taken to the main TWIG screen.
The first thing Joe should do is set up his preferences. Here, you can define items such as Web bookmarks, contacts, mail preferences, news, contacts, schedules, and so on. The main menu will appear at the top of each page, so the user can switch between different functions at will.
You may find a few PHP warnings on various parts of the screen if you’re not using IMAP. Because TWIG is rather IMAP-centric (it was originally a Web-based IMAP client), it depends on connecting to IMAP servers and will complain about being unable to find a stream pointer if you don’t use IMAP. You can safely ignore these warnings, and I suspect that in a future version of TWIG, you will be able to completely disable IMAP support so that these warnings do not appear.
At this point, you can explore the TWIG interface. There isn’t much else to say about TWIG at this point because every user will want to configure their preferences in different ways and the options are self-explanatory.
In this Daily Drill Down, we looked at many of TWIG’s features. While TWIG may have a way to go compared to other groupware solutions, it has a number of benefits that you certainly cannot beat. The fact that it is open source and uses only open source components is a definite bonus. Everything TWIG relies on can be either commercial-grade or open source, meaning that you can have a TWIG system running in minutes with the only cost being your time.
TWIG is fully cross-platform as well. The only requirements to access TWIG are a browser and Internet/intranet access. Because of this, mixed-network environments can enjoy a consistent groupware application regardless of which operating system you use.
Finally, TWIG is in perpetual development. This means that an already excellent product can only get better.