Skip to main content

Zarafa 7.2 Multi-Tenant mit Postfix, SpamAssassin und SASL

Zarafa 7.2 Multi-Tenant mit Postfix, SpamAssassin und SASL

Nachdem nun eine neue Version der Zarafa-Community Edition schon vor einiger Zeit erschienen ist, hatte ich mich entschlossen, mich auch einmal an die Aktualisierung meines Servers zu wagen. Ein Upgrade meiner bisherigen 7.1.x Version kam für mich nicht in Frage, da ich dieses mal auch auf eine Multi-Tenant-Umgebung gehen wollte, was nicht unerhebliche Anpassungen der Konfiguration bedingte.

Wenn also schon eine komplette Neuinstallation, dann wollte ich auch gleich mein Ubuntu 12.04 LTS auf ein Ubuntu 14.04 LTS ( 64-Bit Version ) anheben – ein ziemlicher Akt, alles in allem, doch letztlich war alles erfolgreich 🙂

Das Ziel dieser Anleitung ist ein funktionierender Zarafa-Mailserver, welcher mittels IMAP ( SASL-Auth ), ActiveSync ( Z-Push ) sowie einem Webinterface ( Zarafa Webapp ) erreichbar und verwendbar ist – inklusive einer wirksamen Spam-Kontrolle ( Spamassassin ).

Bei den Installations- bzw. Konfigurations-Anweisungen in dieser Anleitung ist wichtig zu beachten, dass die Paketversionen welche hier angegeben sind mit der Zeit aktualisiert werden und auch die hier benannten Passwörter, Benutzernamen und IP-Adressen müssen natürlich auf das jeweilige Server-Setup angepasst werden – es handelt sich hier lediglich um „sinnfreie“ Platzhalter. Es ist hier also kein durchgehend aktuelles Copy&Paste Tutorial !

Nun soll es aber los gehen und ich möchte mit den Grundvoraussetzungen für die Installation beginnen. Folgende Pakete sind installiert und stehen in der Paket-Basisversion bereit:

  • Ubuntu Server 14.04.xx LTS ( 64-Bit )
  • Zarafa Collaboration Platform 7.2.0 ( Open-Source Edition )
  • Z-Push 2.x
  • Apache 2.4.x
  • MySQL Server 5.5.x
  • PHP 5.5.x
  • Postfix 2
  • Spamassassin 3.4.x
  • Cyrus SASL 2
  • Zwei bis drei Liter Kaffee ( der muss wohl manuell „gezogen“ werden )

Es kann nun erst einmal eine Grundinstallation des Ubuntu Servers erfolgen. Hier mag ich nicht weiter auf die Details eingehen, denn dazu gibt es wirklich mehr als genug Anleitungen im Netz zu finden – am einfachsten ist es hier dann sicherlich, auf der offiziellen Ubuntu Webseite nachzusehen. Als nächster Schritt folgt die Installation von Mail-, Web- und Datenbankserver. Auch hier werden die Pakete erst einmal im Default-Zustand installiert und konfiguriert:

apt-get install apache2 libapache2-mod-php5 mysql-server php5 php5-curl php5-mcrypt php5-mysql postfix postfix-mysql sasl2-bin libsasl2-modules-db libsasl2-modules libsasl2-2 spamassassin pyzor razor

Alle Konfigurationsfragen dieser Pakete mit einem „ENTER“ bestätigen, denn es werden wie gesagt erst einmal nur die Basisinstallationen benötigt. Auch eventuelle Abhängigkeiten der Pakete ( je nachdem wie die Installation des Ubuntu Servers vorgenommen wurde ) müssen hier berücksichtigt werden. Um eventuell daraus resultierende, unaufgelöste Abhängigkeiten glatt zu ziehen, sind folgende Kommandos sehr sinnvoll:

apt-get update
apt-get -f install

Nun geht es an die Grundinstallation der Zarafa Collaboration Platform. Diese kann auf der Community Webseite von Zarafa geladen werden und muss vor der Installation der einzelnen Pakete entpackt werden:

tar xzvf zcp-7.2.0-48204-ubuntu-14.04-x86_64-opensource.tar.gz

Da bei der aktuellen Version scheinbar kein Installer mehr mit gepackt wurde, wie es noch bei der 7.1er Version der Fall war, müssen die Pakete manuell installiert werden. Da jedoch nicht alle Pakete benötigt werden, genügt hier die Installation des folgenden Pakets zur Vorbereitung:

apt-get install libicu52

und dann die letztlich eigentlichen Zarafa-Pakete ( auszuführen im Verzeichnis, in welchem das Zarafa .tar.gz File entpackt wurde ):

dpkg -i libunwind8-dev_1.1-3_amd64.deb libunwind8_1.1-3_amd64.deb php5-mapi_7.2.0.48204_amd64.deb python-mapi_7.2.0.48204_amd64.deb python-zarafa_7.2.0.48204_all.deb zarafa-client_7.2.0.48204_amd64.deb zarafa-common_7.2.0.48204_amd64.deb zarafa-contacts_7.2.0.48204_amd64.deb zarafa-dagent_7.2.0.48204_amd64.deb zarafa-dev_7.2.0.48204_amd64.deb zarafa-gateway_7.2.0.48204_amd64.deb zarafa-gsoap-doc_2.8.21-1_all.deb zarafa-gsoap_2.8.21-1_amd64.deb zarafa-ical_7.2.0.48204_amd64.deb zarafa-lang_7.2.0.48204_amd64.deb zarafa-libarchiver_7.2.0.48204_amd64.deb zarafa-libgoogle-perftools-dev_2.4_amd64.deb zarafa-libgoogle-perftools4_2.4_amd64.deb zarafa-libgsoap-dev_2.8.21-1_amd64.deb zarafa-libgsoap5_2.8.21-1_amd64.deb zarafa-libical-dev_1.0.1-1_amd64.deb zarafa-libical1_1.0.1-1_amd64.deb zarafa-libmapi_7.2.0.48204_amd64.deb zarafa-libvmime-dev_0.9.2+svn603-10_amd64.deb zarafa-libvmime0_0.9.2+svn603-10_amd64.deb zarafa-monitor_7.2.0.48204_amd64.deb zarafa-presence_7.2.0.48204_amd64.deb zarafa-search-plus_7.2.0.48204_amd64.deb zarafa-server_7.2.0.48204_amd64.deb zarafa-spooler_7.2.0.48204_amd64.deb zarafa-utils_7.2.0.48204_amd64.deb zarafa-webapp-browsercompatibility_2.0.1.47791_all.deb zarafa-webapp-extbox_2.0.1.47791_all.deb zarafa-webapp-files_2.0.1.47791_all.deb zarafa-webapp-folderwidgets_2.0.1.47791_all.deb zarafa-webapp-oauthlib_2.0.1.47791_all.de zarafa-webapp-pdfbox_2.0.1.47791_all.deb zarafa-webapp_2.0.1.47791_all.deb

Auch hier ist das identische, wie bereits weiter oben zu beachten, um eventuell unaufgelöste Paket-Abhängigkeiten glatt zu ziehen:

apt-get update
apt-get -f install

Um später den Zarafa-Server auch korrekt starten zu können, muss noch die Datenbank samt passendem User angelegt werden. Hierzu einfach mit dem Datenbankserver verbinden und folgende Kommandos ausführen:

create database zarafa;
create user zarafa@localhost identified by "zarafa";
grant all on zarafa.* to zarafa@localhost;
flush privileges;

Nun bedarf es auch noch eines Systemusers:

groupadd zarafa
useradd -g zarafa -d /var/lib/zarafa zarafa

Eine kurze Anpassung aus Sicherheitsgründen an der /etc/passwd:

zarafa:x:1001:1001::/var/lib/zarafa:/bin/false

Weiter geht es im kommenden Schritt, mit der Konfiguration der Zarafa Services und Server. Die POP3 Connectivity ist hier komplett deaktiviert, IMAP jedoch bleibt aktiv, denn es gibt ja immer mal Services, welche einen „externen“, funktionierenden SMTP Server voraussetzen ( z.B. Fritz!Box Push-Service ).

Als Basis steht hier immer die standardmäßige Konfigurationsdatei der jeweiligen Services bzw. Server und es sind somit auch nur die Anpassungen beziehungsweise Änderungen aufgelistet.

Zarafa-Server ( /etc/zarafa/server.cfg ):

server_bind = 127.0.0.1
log_level = 3
mysql_user = zarafa
mysql_password = zarafa
cache_cell_size = 1024M ( Abhängig vom zur verfügung stehenden RAM des Servers, gerne so hoch als möglich )
enable_hosted_zarafa = true
hide_everyone = yes
disabled_features = pop3
server_name = haertezone.de
local_admin_users = root zarafa
storename_format = %f(%c)
loginname_format = %u@%c

Zarafa-Gateway ( /etc/zarafa/gateway.cfg ):

pop3_enable = no
imap_public_folders = no
log_level = 3

Zarafa-Spooler ( /etc/zarafa/spooler.cfg ):

smtp_server = 127.0.0.1

Um den Push-Service für Smartphones & Co. auch realisiert zu bekommen, muss Z-Push heruntergeladen, bereitgestellt und konfiguriert werden. Dazu wird einfach das aktuelle Paket heruntergeladen und im Webserver-Root ( /var/www ) entpackt:

tar xzvf z-push-2.2.1-1939.tar.gz
ln -s z-push-2.2.1-1939 z-push
chown -R www-data: z-push-2.2.1-1939

und es darf dann auch das passende Log- bzw. Stating-Verzeichnis mit den entsprechenden Rechten nicht fehlen:

mkdir /var/log/z-push
chown -R www-data: /var/log/z-push
mkdir /var/lib/z-push
chown -R www-data: /var/lib/z-push

Sowie abschliessend die Timezone Anpassung je nach Standort ( /var/www/z-push/config.php ), welche identisch zu der Angabe in der php.ini ( date.timezone= „Europe/Berlin“ ) sein sollte:

define('TIMEZONE', 'Europe/Berlin');

Da hier eine Zarafa Umgebung als Multi-Company Umgebung aufgesetzt wird, ist für den Login über Push-Devices auch die vollständige Mailadresse zu verwenden. Hierzu muss noch folgende Option in der Z-Push Konfiguration ( /var/www/z-push/config.php ) angepasst werden:

define('USE_FULLEMAIL_FOR_LOGIN', true);

Weiter geht es mit der Anpassung des Apache Virtual-Host für die Bereitstellung des Z-Push Services. Hier habe ich mich für einen etwas ungewöhnlichen und ganz bestimmt auch nicht optimalen Weg entschieden, welcher jedoch zu einer gewissen Übersichtlichkeit beiträgt, insbesondere dann, wenn mehrere Virtual-Hosts auf dem gleichen Webserver aktiv sind. Es ist bei dieser Variante zwingend nach einem Zarafa-Update darauf zu achten, dass diese Schritte manuell nachgezogen werden, sonst gibt es doppelte und unschöne Virtual-Host Konfigurationen.

cd /etc/apache2/sites-available
unlink zarafa-webapp
rm zarafa-webapp.conf
cd /etc/apache2/sites-enabled
unlink zarafa-webapp.conf

Allgemein muss, falls nicht bereits im Vorfeld geschehen, noch das Default-Charset des Apachen auf deutsch gestellt werden, ansonsten wird die webapp Darstellungsprobleme bekommen, sobald diese auf deutsch eingestellt wird. Das geschieht durch die Anpassung der Apache LANG-Variable ( /etc/apache2/envvars ):

export LANG=de_DE.UTF-8

Ein neuer Virtual-Host ( /etc/apache2/sites-available ) wird nun definiert, dass dieser standardmäßige webapp-Alias nicht weiter verwendet wird – das macht eben zusätzliche Rewrites und Aliase überflüssig. Ein pauschaler Rewrite aller HTTP Anfragen auf eine verschlüsselte HTTPS-Seite ist hier ebenfalls mit eingebunden. Auf die Einbindung von SSL-Zertifikaten sowie deren Konfigurationsanpassungen gehe ich nicht weiter ein, denn auch hier gibt das Internet diverse Anleitungen her, unter anderem auch auf meinem Blog zu finden.

<VirtualHost *:80>
#
# kein HTTP erlaubt, alles auf HTTPS
#
ServerAdmin info@server.de

ServerName mail.server.de

RewriteEngine On
RewriteCond %{SERVER_PORT} !^443$
RewriteRule ^(.*)$ https://mail.server.de [L,R]

LogLevel warn rewrite:warn
ErrorLog /var/log/apache2/mail_server_de/error.log
CustomLog /var/log/apache2/mail_server_de/access.log combined
</VirtualHost>

<VirtualHost *:443>
ServerName mail.server.de

SSLEngine on
SSLCertificateFile /etc/apache2/ssl/mail.server.de.crt
SSLCertificateKeyFile /etc/apache2/ssl/mail.server.de.key
SSLCertificateChainFile /etc/apache2/ssl/startssl_ca.pem

LogLevel warn rewrite:warn
ErrorLog /var/log/apache2/mail_server_de/error.log
CustomLog /var/log/apache2/mail_server_de/access.log combined

#
# z-Push
#
Alias /Microsoft-Server-ActiveSync /var/www/z-push/index.php
php_flag magic_quotes_gpc off
php_flag register_globals off
php_flag magic_quotes_runtime off
php_flag short_open_tag on

DocumentRoot /usr/share/zarafa-webapp

# Modules to enable for the caching instructions to work:
# mod_expires
# mod_headers
# mod_setenvif - for Internet Explorer quirks
#
# For compression:
# mod_deflate
<Directory /usr/share/zarafa-webapp/>
DirectoryIndex index.php
Options -Indexes +FollowSymLinks
AllowOverride Options

<IfModule !mod_authz_core.c>
Order allow,deny
Allow from all
</IfModule>
<IfModule mod_authz_core.c>
Require all granted
</IfModule>

FileETag All

# Uncomment to enhance security of WebApp by restricting cookies to only
# be provided over HTTPS connections
php_flag session.cookie_secure on
php_flag session.cookie_httponly on

# Manipulate the cache control headers if mod_expires and
# mod_headers are both enabled; otherwise the client will depend
# on the ETag header. However, you can set FileETag to "None" if
# you have multiple servers serving WebApp to the same user. In
# that case, apache will fall back to the config below so make
# sure these two modules are loaded!
<IfModule expires_module>
<IfModule headers_module>
ExpiresActive On
ExpiresDefault "now"

<filesMatch "\.(jpg|gif|png)$">
# All (static) resources set to 2 months expiration time.
ExpiresDefault "access plus 2 months"
Header append Cache-Control "public"
</filesMatch>

<FilesMatch "\.(js|css)$">
# All non-dynamic files set to 2 weeks expiration time.
ExpiresDefault "access plus 2 weeks"
# User agents are requested to revalidate for each resource
# so that the server can always serve a newer version if
# necessary.
Header append Cache-Control "no-cache, must-revalidate"

# Treat IE a little differently due to the remarks on no-cache
# on http://support.microsoft.com/kb/234067
<IfModule setenvif_module>
BrowserMatch MSIE ie_bug
</IfModule>
Header set Cache-Control "must-revalidate, private" env=ie_bug
</FilesMatch>

<filesMatch "\.(php)$">
# PHP files must always be retrieved from the server.
ExpiresActive Off
Header set Cache-Control "private, no-cache, no-store, proxy-revalidate, no-transform"
Header set Pragma "no-cache"
</filesMatch>
</IfModule>
</IfModule>

# Enable gzip compression if the module is available
<IfModule deflate_module>
<filesMatch "\.(js|css)$">
SetOutputFilter DEFLATE
</filesMatch>
</IfModule>
</Directory>
</VirtualHost>

Als nächsten Schritt geht es zur Konfiguration des MTA, welcher hier in Form von Postfix eingesetzt wird.

Da die einzelnen Benutzer, welche sich am MTA authentifizieren müssen in der Zarafa-Datenbank liegen, sind zwei weitere Konfigurationsdateien ebenfalls vorab, für die Einbindung in die Postfix Konfiguration erforderlich, eine für die Benutzer und eine für die relevanten Domains.

Benutzerliste ( /etc/postfix/mysql-users.cf ):

user = zarafa
password = zarafa
hosts = 127.0.0.1
dbname = zarafa
query = select value from objectproperty where objectid=(select objectid from objectproperty where value='%s' limit 1) and propname='emailaddress';

Domainliste ( /etc/postfix/mysql-domains.cf ):

user = zarafa
password = zarafa
hosts = 127.0.0.1
dbname = zarafa
query = select value from objectproperty where propname='companyname' and value='%s'

Die Anpassung der ersten Postfix Konfigurationsdatei ( /etc/postfix/main.cf ) ist recht umfangreich, deswegen habe ich hier die komplette Konfigurationsdatei gelistet – es sind hier also nicht nur Anpassungen gelistet, sondern eben das komplette Konfigurationsfile:

smtpd_banner = $myhostname ESMTP NO UCE
myhostname = mail.server.de
biff = no
append_dot_mydomain = no
mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128
recipient_delimiter = +
inet_interfaces = all
smtp_bind_address = *externe IP-Adresse des Servers*
myorigin = $myhostname
mydestination = $myhostname localhost

virtual_mailbox_maps = mysql:/etc/postfix/mysql-users.cf
virtual_mailbox_domains = mysql:/etc/postfix/mysql-domains.cf
virtual_transport = lmtp:127.0.0.1:2003

#
# SASL
#
smtpd_sasl_auth_enable = yes
broken_sasl_auth_clients = yes

#
# TLS
#
smtpd_tls_security_level = may
smtpd_tls_auth_only = yes
smtpd_tls_loglevel = 0
smtpd_tls_received_header = yes
smtpd_tls_session_cache_timeout = 3600s
tls_random_source = dev:/dev/urandom

#
# Eingehende Mails
#
smtpd_recipient_restrictions =
permit_mynetworks,
permit_sasl_authenticated,
reject_unknown_recipient_domain,
reject_non_fqdn_recipient,
reject_non_fqdn_hostname,
reject_non_fqdn_sender,
reject_unauth_destination,
reject_unauth_pipelining,
reject_invalid_hostname

smtpd_data_restrictions =
reject_unauth_pipelining

#
# Client Beschraenkungen
#
smtpd_client_restrictions =
sleep 5,
reject_unknown_reverse_client_hostname,
permit_mynetworks,
permit_auth_destination,
permit_sasl_authenticated

#
# HELO
#
smtpd_helo_restrictions =
permit_mynetworks,
reject_invalid_hostname,
reject_non_fqdn_hostname

#
# Absender Beschraenkungen
#
smtpd_sender_restrictions =
reject_unknown_sender_domain,
reject_non_fqdn_sender,
permit_sasl_authenticated,
permit_mynetworks,
hash:/etc/postfix/blacklisted-domains

#
# Finetuning-Parameter
#
queue_run_delay = 900
minimal_backoff_time = 450
maximal_backoff_time = 1800
maximal_queue_lifetime = 14
bounce_queue_lifetime = 14
qmgr_message_recipient_limit = 1000000
message_size_limit = 20480000

#
# NIS-Fehlerleldungen im Logfile unterbinden
#
alias_maps = hash:/etc/aliases

#
# Standardisierung und Hardening
#
smtpd_helo_required = yes
strict_rfc821_envelopes = yes
disable_vrfy_command = yes

Parallel zum weiter unten beschriebenen spamassassin Filter habe ich direkt am MTA noch ein Blacklisting angebracht, welches ich manuell pflege. Zur manuellen Pflege dieser Blacklisting-Liste gehe ich auch in der spamassassin Konfiguration weiter unten näher ein. Hier wird nun erst einmal eine neue Datei angelegt ( /etc/postfix/blacklisted-domains ) und entsprechend editiert – ein Domain-Eintrag pro Zeile mit einem „REJECT“ am Ende. Hier ein Beispiel:

domainname1.org REJECT
domainname2.com REJECT
domain ...

Dieses File muss nun noch für Postfix bereitgestellt werden:

postmap /etc/postfix/blacklisted-domains

Für die Anpassungen an der zweiten Postfix Konfigurationsdatei ( /etc/postfix/master.cf ) habe ich folgende Konfiguration verwendet:

# ==========================================================================
# service type private unpriv chroot wakeup maxproc command + args
# (yes) (yes) (yes) (never) (100)
# ==========================================================================
smtpd pass - - n - - smtpd
-o content_filter=spamassassin
tlsproxy unix - - n - 0 tlsproxy
dnsblog unix - - n - 0 dnsblog
submission inet n - n - - smtpd
-o content_filter=spamassassin
# smtps inet n - n - - smtpd
# -o smtpd_tls_wrappermode=yes
# -o smtpd_sasl_auth_enable=yes
smtp inet n - n - - smtpd
-o content_filter=spamassassin
pickup fifo n - - 60 1 pickup
cleanup unix n - - - 0 cleanup
qmgr fifo n - n 300 1 qmgr
tlsmgr unix - - - 1000? 1 tlsmgr
rewrite unix - - - - - trivial-rewrite
bounce unix - - - - 0 bounce
defer unix - - - - 0 bounce
trace unix - - - - 0 bounce
verify unix - - - - 1 verify
flush unix n - - 1000? 0 flush
proxymap unix - - n - - proxymap
proxywrite unix - - n - 1 proxymap
smtp unix - - - - - smtp
# When relaying mail as backup MX, disable fallback_relay to avoid MX loops
relay unix - - - - - smtp
-o smtp_fallback_relay=
showq unix n - - - - showq
error unix - - - - - error
retry unix - - - - - error
discard unix - - - - - discard
local unix - n n - - local
virtual unix - n n - - virtual
lmtp unix - - n - - lmtp
anvil unix - - - - 1 anvil
scache unix - - - - 1 scache

# reinjection from spamassassin into mailflow after checks
127.0.0.1:10026 inet n - n - - smtpd
-o content_filter=
-o receive_override_options=no_unknown_recipient_checks,no_header_body_checks
-o smtpd_helo_restrictions=
-o smtpd_client_restrictions=
-o smtpd_sender_restrictions=
-o smtpd_recipient_restrictions=permit_mynetworks,reject
-o mynetworks=127.0.0.0/8
-o smtpd_authorized_xforward_hosts=127.0.0.0/8

spamassassin unix - n n - - pipe
user=debian-spamd argv=/usr/bin/spamc -e /usr/sbin/sendmail -oi -f ${sender} ${recipient}

Nun geht es an den SASL-Teil der Konfiguration ( dieser hatte mich gelinde gesagt in den Wahnsinn getrieben ). Hierzu sind zwei Konfigurationen anzupassen und auch der Postfix-Benutzer.

SASL Konfiguration ( /etc/default/saslauthd ):

START=yes
DESC="SASL Authentication Daemon"
NAME="saslauthd"
MECHANISMS="rimap"
MECH_OPTIONS="127.0.0.1"
THREADS=5
OPTIONS="-c -m /var/run/saslauthd -r"

Postfix-SASL Konfiguration ( /etc/postfix/sasl/smtpd.conf ):

pwcheck_method: saslauthd
mech_list: plain login

Postfix Benutzer ( Kommandozeile ):

gpasswd -a postfix sasl

Ich bin bei dem SASL-Teil der Konfiguration wegen eines eigentlich trivialen Problems immer wieder in Fehler gelaufen ( Schach und Schande über mich ), welchen ich hier deswegen explizit anmerken möchte. Bitte einfach bei eventuellen Fehlermeldungen und Probleme prüfen, ob der SASLAuthDaemon auch wirklich läuft bzw. beim Server-Neustart automatisch hoch fährt:

service saslauthd status

Sollte der automatische Start nicht eingestellt sein, kann dies ganz einfach erreicht werden:

update-rc.d saslauthd defaults

Als nächste Komponente geht es zum Spam-Filter spamassassin. Hier wird zuerst ein Log-Verzeichnis angelegt:

mkdir /var/log/spamassassin
chown -R debian-spamd: /var/log/spamassassin

und die bereits bekannten Anpassung der /etc/passwd:

debian-spamd:x:111:118::/var/lib/spamassassin:/bin/false

und dann die Default-Konfiguration ( /etc/default/spamassassin ) angepasst:

ENABLED=1
SALOG="/var/log/spamassassin/"
OPTIONS="--create-prefs --max-children 5 --helper-home-dir -s ${SALOG}spamd.log -u debian-spamd -g debian-spamd"

Als letzter Schritt folgt nun noch die Anpassung der eigentlichen spamassassin-Konfiguration ( /etc/spamassassin/local.cf ):

rewrite_header Subject ****SPAMASSASSIN (_SCORE_)****
report_safe 1

Nun ist es auch fast geschafft und nach einem Neustart aller relevanten Services können Domains und User in Zarafa angelegt werden. Ich empfehle hier einen kompletten Neustart des Servers vorab, da dann auch gleich sichergestellt werden kann, dass alle Services wirklich bootfest sind.

Domain in Zarafa anlegen:

zarafa-admin --create-company server.de

User ( hier als Admin ) in Zarafa anlegen:

zarafa-admin -c info@server.de -P -e "info@server.de" -f "Server Admin" -a 1

Als finales Finetuning muss hier nun noch das Logrotate angepasst werden, damit die Logfiles nicht überlaufen.

Z-Push ( /etc/logrotate.de/z-push ):

/var/log/z-push/*.log {
weekly
missingok
rotate 52
compress
delaycompress
notifempty
create 640 www-data www-data
sharedscripts
postrotate
/etc/init.d/apache2 reload > /dev/null
endscript
}

Zum Schluss möchte ich mich auch noch bei David Gabriel bedanken, welcher mir mit seinem Wiki-Eintrag für dieses How-To viele gute Ansatzpunkte und Lösungsoptionen geliefert hat !

Community, Ubuntu, Zarafa


Sven Neidahl

Hallo, ich bin Sven, technikbegeisterter Mensch mit Blog-Ambitionen. Ich liebe Australian-Shepherds, leckeres Essen, laute Musik und Wandern mit anschliessendem Wellness-Programm, hauptsache "Lebe das Leben mit Liebe, Spass und Technik".

Kommentar

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Diese Seite ist durch reCAPTCHA und Google geschütztDatenschutz-Bestimmungen UndNutzungsbedingungen anwenden.

The reCAPTCHA verification period has expired. Please reload the page.