1ZARAFA-SERVER(1) Zarafa user reference ZARAFA-SERVER(1)
2
6 zarafa-server - Start the Zarafa storage server.
7
9 zarafa-server [OPTION]
10
12 The zarafa-server is the Zafara storage server. It contacts a database
13 server and provides services to Zarafa clients. The user base can be
14 retreived from an external source, like LDAP, or can be setup with a
15 separate list of users.
16 After starting, the server keeps listening for connections on the
18 configured TCP port and/or Unix socket.
19
21 The Zarafa server program takes the following configuration options:
22 --config, -c file
24 Specify the location of the configuration file.
25 Default: /etc/zarafa/server.cfg
27 --foreground, -F
29 Run in the foreground. Normally the server will daemonize and run
30 in the background.
31 --restart-searches, -R
33 Rebuild all search folders. This may take some time and is only
34 needed when your search folders have become out-of-sync with the
35 actual data in the database. The sync will start synchronously at
36 the start of the server, and you will have to wait for all searches
37 to complete before connecting to the server.
38 --ignore-database-version-conflict
40 Ignore version information from the database. Zarafa will normally
41 not start the server if the database has a newer version than the
42 zarafa-server binary. This makes sure you cannot downgrade your
43 server binary while keeping the same database. If you know what
44 you´re doing, you can use this option to bypass the start-up
45 version check of the database.
46 --ignore-attachment-storage-conflict
48 Override the attachment storage option from the configuration file.
49 When you change the option of the location where to store
50 attachments after you´ve already started the zarafa-server once,
51 this location will conflict. Attachments will not be found when
52 they are stored in a different location.
53 --override-multiserver-lock
55 When you upgrade/downgrade from/to multiserver setups, the server
56 will not start, because of database differences. If you know what
57 you´re doing, and want to circumvent this and start the server
58 anyway, you can use this option.
59 --force-database-upgrade
61 The upgrade from 6.x to 7.0 is blocked, since it will take a long
62 time. We provide 2 methods to upgrade the database. One is using
63 the preferred zarafa7-upgrade python script. This is preferred
64 since it shows the upgrade progress, and you can estimate the time
65 it will take for the upgrade to complete. The second option is
66 letting the zarafa-server do the normal upgrade as usual. Pass this
67 option to use this method. The server will only daemonize when the
68 upgrade is complete. Simple progress can be followed in the log
69 output of the server.
70 -V
72 Print the version and exit.
73 When invoked with no options, the server will search for a
75 configuration file in /etc/zarafa/server.cfg. If no configuration file
76 is found, default values are used. See zarafa-server.cfg(5) for all
77 configuration options and their default values.
78
80 Starting the server with an alternative configuration:
81 zarafa-server -c /path/to/server.cfg
83 You may also use the init.d scripts:
85 /etc/init.d/zarafa-server [start| stop| restart]
87
89 /etc/zarafa/server.cfg
90 The server configuration file.
91 /etc/zarafa/license/base, /etc/zarafa/license/*
93 The base file contains your license key. When you have extra CAL
94 license keys, these are found in the other files available in the
95 license/ directory, one key per file. This directory is
96 configurable.
97 Configuration options for user plugins are in their respective
99 configuration file. The name of these files is set in the server.cfg
100 file. See zarafa-server.cfg(5) for information on the server.cfg
101 settings.
102
104 If you run into problems, check the log for any errors. If you made a
105 mistake in the configuration of the log method, this will be reported
106 on standard error. You can also restart the server with a higher log
107 level. Also, before starting the server, always make sure the database
108 server is running at the right location and no other server is
109 listening on the configured TCP port.
110
112 The normal way for user clients to connect to the server is over TCP,
113 either direct using the Zarafa port, or over HTTP when Apache is setup
114 as a proxy. Users can only login with their username and password.
115 The normal way for admin clients, like the spooler and admin tool, to
117 connect to the server is through the Unix socket on Unix type servers.
118 The admin clients are able to login when they are run as root or as the
119 user the Zarafa server process is running as. Most of the time this
120 will be root only, since the Zarafa server process runs as root by
121 default.
122 As an exception for the dagent, a unix user can also connect to it´s
124 own store without a password. Any other store cannot be accessed this
125 way.
126 Direct SSL connections are also possible. The server needs to be
128 configured to accept SSL connections on a new port. Login via an SSL
129 key is also possible. Please read the next section on how to setup SSL.
130
132 To accept SSL connections directly by the server, the Zarafa server
133 will need to listen on a different port to separate the normal
134 connections from the encrypted connections. This is set in the
135 server_ssl_port setting in the configuration file.
136 Then, you must setup a signed SSL certificate. First, we´ll create a
138 Certificate Authority to be able to sign certificate requests. We
139 provide a script which makes it easy to create certificates on any
140 distribution. This script is located in /usr/share/zarafa, called
141 ssl-certificate.sh. Enter the following commands to create a
142 certificate for the Zarafa server.
143 mkdir -p /etc/zarafa/ssl
145 cd /etc/zarafa/ssl
146 sh /usr/share/zarafa/ssl-certificate.sh server
147 Press enter twice to start the creation of a new CA, probably called
149 demoCA. Enter a password when asked for. This is the password later
150 used to sign certificate requests. Then enter your certificate
151 information. Do not leave the Common Name field blank, otherwise the
152 creation will fail. A good example for the Common Name field is your
153 hostname.
154 Now that we have a CA, we can create self-signed certificates. The
156 script will automatically start the creation of this certificate. The
157 CA certificate must be set in the server.cfg file in the
158 server_ssl_ca_file setting. We need a signed certificate for the server
159 to start with SSL support.
160 Enter a password for the request, and enter the certificate details.
162 Some details need to be different from what you typed when creating the
163 CA. Type at least a different name in the ´Organizational Unit Name´
164 field. The challenge password at the end may be left empty.
165 The script will automatically continue with signing this certificate
167 request. You will need to enter your CA certificate password again to
168 sign this request. Then you must accept the new certificate into the
169 CA.
170 After accepting, a new signed certificate is created, with the name
172 server.pem. This file contains the private key, so keep this file safe.
173 The script will ask if a public key should also be created. Since we´re
175 creating the certificate for the server, this is not needed. So enter
176 ´n´ and press enter.
177 The server.pem file should be set in the server.cfg file in the
179 server_ssl_key_file option. See zarafa-server.cfg(5) for information on
180 the possible SSL settings. The password of this key needs to be set in
181 the server_ssl_key_pass option. Do not forget this password in the
182 server.cfg file, otherwise the zarafa-server program will ask for this
183 password when an SSL connection is accepted.
184 To create a new certificate for a client service, run the script again.
186 You can create one new certificate for all clients, or seperate
187 certificates for each client.
188 sh /usr/share/zarafa/ssl-certificates.sh
190 When typing the certificate information, type at least a different
192 ´Organizational Unit Name´ field. When asked for a public key, type ´y´
193 and enter to create the public key.
194 Install the new service.pem on the server that will be logging in.
196 Install the service-public.pem file in the /etc/zarafa/sslkeys
197 directory:
198 mkdir /etc/zarafa/sslkeys
200 mv service-public.pem /etc/zarafa/sslkeys
201 The remote service, which has the service.pem private key, can now
203 login with the certificate, because the known public key matches.
204
206 The following signals can be sent to the Zarafa server process:
207 HUP
209 When the HUP signal is received, some options from the
210 configuration file are reloaded. The reloadable options are listed
211 in the zarafa-server.cfg(5) manual page.
212 Also, when using log_method = file, the logfile will be closed and
214 a new logfile will be opened. You can use this signal in your
215 logrotate system.
216 TERM
218 To gracefully let the server exit, the normal TERM signal is used.
219 Because of open sessions by clients it may take up to 60 seconds
220 for the server to completely shutdown.
221
223 Written by Zarafa.
224
226 zarafa-server.cfg(5) zarafa-admin(1)
227Zarafa 7.0 August 2011 ZARAFA-SERVER(1)