Product SiteDocumentation Site

Preface

1. Document Conventions

This manual uses several conventions to highlight certain words and phrases and draw attention to specific pieces of information.
In PDF and paper editions, this manual uses typefaces drawn from the Liberation Fonts set. The Liberation Fonts set is also used in HTML editions if the set is installed on your system. If not, alternative but equivalent typefaces are displayed. Note: Red Hat Enterprise Linux 5 and later includes the Liberation Fonts set by default.

1.1. Typographic Conventions

Four typographic conventions are used to call attention to specific words and phrases. These conventions, and the circumstances they apply to, are as follows.
Mono-spaced Bold
Used to highlight system input, including shell commands, file names and paths. Also used to highlight keycaps and key combinations. For example:
To see the contents of the file my_next_bestselling_novel in your current working directory, enter the cat my_next_bestselling_novel command at the shell prompt and press Enter to execute the command.
The above includes a file name, a shell command and a keycap, all presented in mono-spaced bold and all distinguishable thanks to context.
Key combinations can be distinguished from keycaps by the hyphen connecting each part of a key combination. For example:
Press Enter to execute the command.
Press Ctrl+Alt+F2 to switch to the first virtual terminal. Press Ctrl+Alt+F1 to return to your X-Windows session.
The first paragraph highlights the particular keycap to press. The second highlights two key combinations (each a set of three keycaps with each set pressed simultaneously).
If source code is discussed, class names, methods, functions, variable names and returned values mentioned within a paragraph will be presented as above, in mono-spaced bold. For example:
File-related classes include filesystem for file systems, file for files, and dir for directories. Each class has its own associated set of permissions.
Proportional Bold
This denotes words or phrases encountered on a system, including application names; dialog box text; labeled buttons; check-box and radio button labels; menu titles and sub-menu titles. For example:
Choose SystemPreferencesMouse from the main menu bar to launch Mouse Preferences. In the Buttons tab, click the Left-handed mouse check box and click Close to switch the primary mouse button from the left to the right (making the mouse suitable for use in the left hand).
To insert a special character into a gedit file, choose ApplicationsAccessoriesCharacter Map from the main menu bar. Next, choose SearchFind… from the Character Map menu bar, type the name of the character in the Search field and click Next. The character you sought will be highlighted in the Character Table. Double-click this highlighted character to place it in the Text to copy field and then click the Copy button. Now switch back to your document and choose EditPaste from the gedit menu bar.
The above text includes application names; system-wide menu names and items; application-specific menu names; and buttons and text found within a GUI interface, all presented in proportional bold and all distinguishable by context.
Mono-spaced Bold Italic or Proportional Bold Italic
Whether mono-spaced bold or proportional bold, the addition of italics indicates replaceable or variable text. Italics denotes text you do not input literally or displayed text that changes depending on circumstance. For example:
To connect to a remote machine using ssh, type ssh username@domain.name at a shell prompt. If the remote machine is example.com and your username on that machine is john, type ssh john@example.com.
The mount -o remount file-system command remounts the named file system. For example, to remount the /home file system, the command is mount -o remount /home.
To see the version of a currently installed package, use the rpm -q package command. It will return a result as follows: package-version-release.
Note the words in bold italics above — username, domain.name, file-system, package, version and release. Each word is a placeholder, either for text you enter when issuing a command or for text displayed by the system.
Aside from standard usage for presenting the title of a work, italics denotes the first use of a new and important term. For example:
Publican is a DocBook publishing system.

1.2. Pull-quote Conventions

Terminal output and source code listings are set off visually from the surrounding text.
Output sent to a terminal is set in mono-spaced roman and presented thus:
books        Desktop   documentation  drafts  mss    photos   stuff  svn
books_tests  Desktop1  downloads      images  notes  scripts  svgs
Source-code listings are also set in mono-spaced roman but add syntax highlighting as follows:
package org.jboss.book.jca.ex1;

import javax.naming.InitialContext;

public class ExClient
{
   public static void main(String args[]) 
       throws Exception
   {
      InitialContext iniCtx = new InitialContext();
      Object         ref    = iniCtx.lookup("EchoBean");
      EchoHome       home   = (EchoHome) ref;
      Echo           echo   = home.create();

      System.out.println("Created Echo");

      System.out.println("Echo.echo('Hello') = " + echo.echo("Hello"));
   }
}

1.3. Notes and Warnings

Finally, we use three visual styles to draw attention to information that might otherwise be overlooked.

Note

Notes are tips, shortcuts or alternative approaches to the task at hand. Ignoring a note should have no negative consequences, but you might miss out on a trick that makes your life easier.

Important

Important boxes detail things that are easily missed: configuration changes that only apply to the current session, or services that need restarting before an update will apply. Ignoring a box labeled 'Important' will not cause data loss but may cause irritation and frustration.

Warning

Warnings should not be ignored. Ignoring warnings will most likely cause data loss.

2. Feedback

We value feedback on our software as well as our documentation. Please find ways to contact us in this section.

2.1. Reporting Bugs in Kolab

Bug reports can be logged in our Bugzilla issue tracker. Please bear in mind registration is required to log bugs.
Before reporting a bug, please search the issue tracker for existing bugs that may report the same problem.
When reporting a bug, please prepare to provide the following information;
  • Your platform, and if applicable, your distribution and the distribution version.
  • The version(s) of the relevant Kolab component(s) you are using.
  • If a custom version is used, any options that may have specified during the build process.

2.2. Mailing Lists

Mailing lists are a quick way to get in touch with a large number of subscribers, who may know the answer to your question or can provide you with additional insight.
Announcement Mailing List
Kolab Groupware administrators and developers are strongly encouraged to subscribe to the moderated, low-volume announcement mailing list, to which important release announcements are submitted. We have the announcement mailing list available at https://lists.kolab.org/mailman/listinfo/kolab-announce. To subscribe to the list, either click the aforementioned link and fill out the information requested, or send an email to kolab-announce-subscribe@kolab.org.
User Mailing List
For users of Kolab software, we run a public mailing list at https://lists.kolab.org/mailman/listinfo/kolab-users. To subscribe to the list, either click the aforementioned link and fill out the information requested, or send an email to kolab-users-subscribe@kolab.org.
Development Mailing List
For developers of Kolab software, as well as general discussion on bugs and patches, we run a public mailing list at https://lists.kolab.org/mailman/listinfo/kolab-devel. To subscribe to the list and fill out the information requested, or send an email to kolab-devel-subscribe@kolab.org.

2.2.1. Archives

The archives of the announcement, user support and development discussion mailing lists are available through web archives.

2.3. IRC

Internet Relay Chat (IRC) is another way to get in touch with some of the people that develop and use Kolab Groupware. Use your favorite IRC client to connect to the FreeNode IRC Network, or use the web-based chat.
Once connected, join us in the #kolab IRC channel.

3. About Kolab Groupware

Kolab Groupware is a highly scalable, flexible, mutli-platform solution for Emails, Appointments, Contacts and more. It supports mixed client environments (Outlook/KDE) because of a well-defined, interoperable and open storage format. Any email client speaking standard protocols can be served.
The Kolab Groupware solution consists of many Free Software components, integrated by Kolab in order to build a groupware solution.

3.1. Free Software Components

Free Software components included with Kolab Groupware include;
  • Postfix
    Postfix attempts to be fast, easy to administer, and secure. The outside has a definite Sendmail-ish flavor, but the inside is completely different.
  • Cyrus IMAP
    Cyrus IMAP is a highly scalable enterprise mail system designed for use in enterprise environments of various sizes using standards based technologies. Cyrus IMAP technologies scale from independent use in email departments to a system centrally managed in a large enterprise.
  • OpenLDAP
    OpenLDAP Software is an open source implementation of the Lightweight Directory Access Protocol.
  • Roundcube
    Roundcube webmail is a browser-based multilingual IMAP client with an application-like user interface. It provides full functionality you expect from an e-mail client, including MIME support, address book, folder manipulation, message searching and spell checking.

3.2. Supported Platforms and System Requirements

Kolab Groupware is supported on the following platforms;

3.3. Kolab Product Series

Kolab Groupware consists of free software components, each of which are available from various upstream development and support project organizations, including Linux distributions.
The Kolab Groupware developers, community members and Kolab Systems engineering and support staff maintain many of the packages related to Kolab with the Linux distributions through which those packages are available.
The Kolab software repositories can therefor include only those software components, or those specific versions of software components, that differentiate from what is available through the upstream Linux distribution software repositories, and possibly recommended or required additional software repositories.
Product series are versioned, each of them created to provide a sustainable stream of updates to the individual software components included in that product serie.
The convention for Server Product Versioning is subject to the guidelines proposed and accepted as Kolab Enhancement Proposal #5 (KEP #5 for short).

3.3.1. Product Streams

Two different product streams exist, a community edition and an enterprise edition.
The differences between the community edition and the enterprise edition are as follows:
  1. No debuginfo sub-packages are made available through the repositories for the community edition. You typically need debuginfo sub-paclages in case stack traces need to be generated for binary compiled programs such as mysql, openldap, cyrus-imapd, php and others.
  2. The packages available through the repositories for the community edition are not signed with a PGP key, and therefor the authenticity of the packages cannot be verified.
  3. The repositories for the community edition are made available through HTTP only, while the enterprise edition's repositories are available over HTTPS only. For the community edition, the the authenticity cannot be verified.
  4. In the repositories for the community edition, no package builds other then the latest are made available. Rolling back a software update foo-1.0-2.el5 to a previously installed software version foo-1.0-1.el5 after a failed update is therefor not possible unless a copy of foo-1.0-1.el5 had been preserved.
  5. For the community edition, no security errata –other then for critical security issues– is sent out.
  6. The enterprise edition is supported for a longer term than the community edition.
  7. The software available in the enterprise edition is subjected to thorough quality assurance and certification before being made available.

3.3.2. Repository Stages

4 different repository stages exist, each of them indicating the expected level of stability, and point-in-time release.
The release and updates repositories contain the most stable software (community edition) which is supported (professionally in the enterprise edition).
The updates-testing repositories contain software that is being stabilized (through the collection of community feedback for the community edition) before being submitted to the updates repository.


[1] By reasonably recent versions of Linux, we intend to indicate the Kolab project can manage to keep up with the latest distribution release ear-marked stable.