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)
kopano-spooler processes are mandatory to run Kopano Core. The
kopano-ical services are optional. To start a service, type:
service kopano-<servicename> start
<servicename> with the service that needs to start. To start the
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
/usr/sbin/kopano-server -c /etc/kopano/server.cfg
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:
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:
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_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.
Increase the level of messages that will be logged. Level
6 is the highest level.
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¶
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)
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 signalfor a list of most common signal IDs.
When a user (not the internal SYSTEM user) logs in, the following message will be printed in the security log:
authenticate ok user='john' from='127.0.0.1' method='User supplied password' program='apache2'
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.
184.108.40.206. Authentications with impersonation¶
When a user logs in and authenticates as another user, the following message will be printed in the security log:
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'
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.
220.127.116.11. 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.
18.104.22.168. Not logged¶
Only “toplevel” objects rights are checked, so you won’t see actions on attachments, recipients or msg-in-msg objects.
/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:
--systemGives information about threads, SQL and caches
--sessionGives information about sessions and server time spent in SOAP calls
--usersGives information about users, store sizes and quotas
--companyGives information about companies, company sizes and quotas
--topShows 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
--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
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.