7. Managing KC Components

7.1. Starting the services

There are 7 services that can be run:

  • kopano-server, the main server process
  • kopano-spooler, sends outgoing email to an SMTP server
  • kopano-monitor, checks for quota limits
  • kopano-gateway, provides POP3 and IMAP access
  • kopano-ical, provides iCal and CALDAV access for clients that use this type of calendar
  • kopano-search, provides a full text indexing service for quick searching through email and attachments
  • kopano-dagent, runs as a service when using local mail transfer protocol (LMTP, see Postfix integration)

The kopano-server and kopano-spooler processes are mandatory to run Kopano Core. The kopano-monitor, kopano-gateway, and kopano-ical services are optional. To start a service, type:

service kopano-<servicename> start

Replace <servicename> with the service that needs to start. To start the kopano-server, type:

service kopano-server start

This script will start the server. The init.d scripts can start, stop and restart the services. If the init.d script cannot be used, the server needs to be started manually. It is possible to explicitly tell the kopano server where the configuration file is, using the -c switch:

/usr/sbin/kopano-server -c /etc/kopano/server.cfg

The kopano-server will daemonise, so prompt will almost immediately return. Use -F to start it in the foreground. The -F switch can also be used for programs like daemontools that monitor services.

7.1.1. Stopping the services

To stop a service, type:

service kopano-<servicename> stop

Most services will stop almost immediately. The kopano-spooler may take up to 10 seconds to stop. The kopano-server may take up to 60 seconds to stop.

7.1.2. Reloading service configuration

Some options can be modified and reloaded by the service in a live environment. The options that can be reloaded are described in the manual page of the service configuration file. Example: for the kopano-server, type the following command to get the configuration manual page:

man kopano-server.cfg

In the reloading chapter are all the options that can be reloaded for that service. To make a service reload the configuration file, type:

service kopano-<servicename> reload

7.2. Logging options

Each component allows the log method to be chosen in its configuration file. Two ways of logging methods are supported: file and syslog.

Normally, all KC components log to their respective file located in /var/log/kopano. This directory is created when the packages are installed. When this directory is not present, or not writable under the running user, services will not be able to open their log file and will print the log messages to the standard output.

Log messages of the server can be configured. The following options need to be altered in the configuration file:

log_method

How to log the messages. file sends the messages to a file. On Linux systems, syslog sends the messages to the default maillog through syslog.

log_file

When the log_method is set to file, this is the variable that defines the name of file. The server needs write access to the directory and file.

log_level

Increase the level of messages that will be logged. Level 6 is the highest level.

log_timestamp

1 or 0; This will enable or disable a timestamp, when using a file as the log method.

Logging of other services than kopano-server are configured in a same manner as the server.

7.3. Security logging

Based on thie extended security logging auditing can be done on the kopano-server. This logging will contain startup messages, user authentications and access actions on delegate stores.

7.3.1. Logging items

7.3.1.1. Startup

When the server is (re)started, the following message will be printed in the security log:

kopano-server startup by user uid=0

The following tag is possible in the startup line:

uid The unix user id used to start the server (not necessarily the user the server will be running as)

7.3.1.2. Signals

When the server receives a signal, the following message will be printed in the security log:

kopano-server signalled sig=15

The following tag is possible in the signal line:

sig The signal the server received. See man 7 signal for a list of most common signal IDs.

7.3.1.3. Authentications

When a user (not the internal SYSTEM user) logs in, the following message will be printed in the security log:

Correct authentication:

authenticate ok user='john' from='127.0.0.1' method='User supplied password' program='apache2'

Incorrect authentication:

authenticate failed user='john' from='127.0.0.1' program='apache2'

Only with sso logins:

authenticate spoofed user='john' requested='test' from='192.168.50.178' \
                     method='kerberos sso' program='OUTLOOK.EXE'

The following tags are possible in the authentication line:

user The username sent to the kopano server. requested The name in the MAPI profile to open the store of, user tag will be the actual authenticated user. (SSO only) from Unix socket or IP-address the connection to the server was made to. method Method the user was validated with, one of the following: socket, certificate, password, ntlm sso or kerberos sso. program The program being used to login with.

7.3.1.4. Authentications with impersonation

When a user logs in and authenticates as another user, the following message will be printed in the security log:

Correct impersonation:

authenticate ok user='john' from='127.0.0.1' method='User supplied password' program='apache2'
impersonate ok user='jane', from='127.0.0.1' program='apache2' impersonator='john'

Incorrect impersonation:

authenticate ok user='john' from='127.0.0.1' method='User supplied password' program='apache2'
impersonate failed user='jane', from='127.0.0.1' program='apache2' impersonator='john'

The following tags are possible in the impersonation line:

user The username of the user being impersonated. from Unix socket or IP-address the connection to the server was made to. program The program being used to login with. impersonator The user that is impersonating another user. This is the user whose credentials are being checked.

7.3.1.5. Sharing actions

When a user opens objects that are not within his own store, a message will be logged. This also accounts fo the Public store.

The following message will be printed in the security log:

Allowed sharing action:

access allowed objectid=387538 type=3 ownername='test' username='constant' rights='view'

Denied sharing action:

access denied objectid=387538 type=3 ownername='test' username='constant' rights='view'

The following tags are possible in the sharing line:

objectid The object being acted on. type The MAPI type of the object. Possible values are 3 (store), 5 (folder) and 7 (message). ownername The owner of the store the objectid is in (not necessarily the user that actually created that object) username The user performing the action on the object. rights The action being performed.

Note

For the Public store the ownername will be SYSTEM in single-tenancy mode, and the company name in multi-tenancy mode.

Possible actions in rights:

read Reading the object. create Creating a new object edit Editing an existing object (eg altering properties, but also adding/removing of recipients and attachments) delete Deleting (softdelete) or moving the object create folder Creating a new folder view Reading the folder hierarchy / contents tables folder permissions Altering the permissions, modifying and deleting folders owner submitMessage/finishMessage/abortSubmit, sending email actions in someone else’s store is never permitted unless you’re the owner. admin Unused, will never actually be printed

7.3.1.6. Log parsing

When a user is accessing a delegate store or folder an entry is written to the audit.log. To have a more userfriendly overview of the delegate folders are accessed, the audit.log can parsed.

The following command will parse the logfile and make the output more userfriendly:

perl /usr/share/doc/kopano/audit-parse.pl < /var/log/kopano/audit.log

The script will display now the exact foldername which is access in the delegate store:

access allowed rights='view' type='folder' objectid='store\27\IPM_SUBTREE\Calendar' \
               username='john' ownername='mary'

In this example the user john has opened the Calendar of user mary.

7.3.1.7. Not logged

Only “toplevel” objects rights are checked, so you won’t see actions on attachments, recipients or msg-in-msg objects.

7.3.2. Configuration

In the /etc/kopano/server.cfg the following options are added:

audit_log_enabled = no
audit_log_method = syslog
audit_log_file = -
audit_log_level = 1
audit_log_timestamp = 0

By default the audit logging is disabled. When enabled, the default is to log through syslog since this can be configured to send the messages to an external syslog server. The syslog authpriv facility will be used to send the messages to.

7.4. Kopano statistics monitoring

The statistics and server status can be checked with the kopano-stats tool. The kopano-stats tool offers the following options:

  • --system Gives information about threads, SQL and caches
  • --session Gives information about sessions and server time spent in SOAP calls
  • --users Gives information about users, store sizes and quotas
  • --company Gives information about companies, company sizes and quotas
  • --top Shows top-like information about sessions and server resource usage

To use the kopano-stats tool use for example the following command:

kopano-stats --top
Last update: Tue Mar 29 13:40:18 2011
Sess: 1     Sess grp: 1       Users: 1    Hosts: 1    CPU: 0%   QLen:    QAge:
SQL/s SEL:    0 UPD:   0 INS:   0 DEL:   0        Threads(idle): ()   SOAP calls: 6

VERSION      USERID  IP/PID  APP             TIME  CPUTIME CPU    NREQ   TASK
7,0,0,24874  SYSTEM  4527    kopano-spooler  0:00  0:00    0      6      tableQueryRows

The --top overview gives every second status information about CPU usage, connected clients, active threads, queue length and SQL queries. When the server has a high queue length and age the amount of threads should be normally increased.

7.5. Soft Delete system

If a user deletes emails, calendar items or complete folders, there are by default moved to the Deleted Items folder.

When the items are removed from the Deleted Items, the items still will not be fully removed from the database. Rather, they are marked as deleted, so the user does not see the items. Even when a user deletes items with <SHIFT> <delete> they are not removed from the database, but marked as deleted.

This makes restoring of items quick and easy from Outlook: choose Extra from the menu bar in Outlook menu, and click on Restore deleted items. Items are grouped by the folder they were deleted from. Most items will appear in the Deleted Items folder as they have been removed from that location.

Soft deletes always remain in the database, until they are purged. When an item will be purged is set by the softdelete_lifetime configuration value. The default value is 30 (days).

In this example, the value is set to 30. This means that deleted items will be purged from the database 30 days after they were deleted. When this option is set to 0 (zero), the items will never be removed from the database.

Purges can also be triggered with the following command:

kopano-cli --purge-softdelete <days>

<days> denotes the number of days that recently removed items are kept. When 0 (zero) all removed items are purged.

For performance reasons a manual purge of the softdelete system is advisable for larger KC environments. This can be simply configured by a cron job.