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.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 user friendly overview of the delegate folders are accessed, the audit.log can parsed.

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

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 beautomatically removed from the database.

Softdelete purges are automatically run every hour, unless the value for softdelete_lifetime is set to 0 (zero). For performance reasons in larger environments, a manual purge of the softdelete system is advisable. This can simply be configured by a cron job.

Purges can be manually triggered with the following command:

kopano-admin --purge-softdelete <days>

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