Konfiguration
Vorbereitung
Nach der erfolgreichen Installation des Horde-Frameworks passen wir nun erst einmal die installierten Dateien und Verzeichnisse unseren Gegebenheiten und Vorstellungen nach an. Dazu kopieren wir als erstes die „distributionsabhängigen“ default-Konfigurationsdateien.
# cd /var/www/horde/config
# cp -a conf.php.dist conf.php
Bei der späteren Konfiguration des Horde-Frameworks benötigen wir für das Backup der Konfiguration eine „leere“ Datei mit dem Namen conf.bak.php. Diese legen wir nun an.
# touch /var/www/horde/config/conf.bak.php
Abschließend passen wir nun noch die Zugriffs- und Verzeichnisrechte des Konfigurationsverzeichnisses /var/www/horde/config und dem cache-Verzeichnis /var/www/horde/static an.
# chown -R root:apache /var/www/horde/config
# chown -R root:apache /var/www/horde/static
# chmod -R g+w /var/www/horde/config
# chmod -R g+w /var/www/horde/static
Apache vHost
Zur Auslieferung der Web-GUI greifen wir auf unseren Webserver zurück. Im Verzeichnis /etc/httpd/conf.d/ tragen wir in der vHost-Definitionsdatei vhosts.conf nachfolgende Konfiguration ein.
# vim /etc/httpd/conf.d/vhosts.conf
<VirtualHost *:80> ServerAdmin webmaster@nausch.org ServerName weboffice.nausch.org ServerAlias www.weboffice.nausch.org ServerPath / AddType application/x-httpd-php .php DocumentRoot "/var/www/horde" <Directory "/var/www/horde"> Options FollowSymLinks AllowOverride None Order allow,deny Allow from all </Directory> # Deny access to files that are not served directly by the webserver <DirectoryMatch "^var/www/horde/(.*/)?(config|lib|locale|po|scripts|templates)/(.*)?"> Order deny,allow Deny from all </DirectoryMatch> # Deny access to the test.php files except from localhost <LocationMatch "^/horde/(.*/)?test.php"> Order deny,allow Deny from all </LocationMatch> DirectoryIndex index.php ErrorLog logs/weboffice_error.log CustomLog logs/weboffice.log combined </VirtualHost>
Bevor wir nun die Konfigurationsänderung durch einen Restart des Apache-Webservers aktivieren, testen wir die Konfigurationsdatei.
# service httpd configtest
Syntax OK
Da der Syntax in Ordung ist, starten wir nun unseren web-server einmal durch.
# service httpd condrestart
Stopping httpd: [ OK ] Starting httpd: [ OK ]
mySQL Datenbank
Die einzelnen Anwendungen des Horde-Framworks benötigen eine mySQL-Datenbank, in der die System- und Anwenderkonfigurationsdaten vorgehalten und gesichert werden.
Wir werden also im nächsten Schritt, die Datenbank und den Horde-Systemuser für das Horde-Framework anlegen.
- Datenbank anlegen
Als erstes legen wir die Datenbank an. MySQL frägt uns bei den nachfolgenden Definitionen nach dem Passwort unseres mysql-Superusers root.# mysql -h localhost -u root -p
Enter password: Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 2 Server version: 5.1.66 Source distribution Copyright (c) 2000, 2012, Oracle and/or its affiliates. All rights reserved. Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective owners. Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. mysql>
mysql> create database horde;
Query OK, 1 row affected (0.02 sec) mysql>
- neuen Benutzer anlegen
Mit folgendem Befehl legen wir uns einen neuen Nutzer an:mysql> CREATE USER 'hordesystemuser'@'10.0.0.90' IDENTIFIED BY 'Django-1$-a-G33k!';
Query OK, 0 rows affected (0.00 sec) mysql>
und
mysql> CREATE USER 'hordesystemuser'@'vml000090.dmz.nausch.org' IDENTIFIED BY 'Django-1$-a-G33k!';
Query OK, 0 rows affected (0.00 sec) mysql>
- Benutzerprivilegien setzen und zuweisen
Anschließend setzen wir die Benutzerrechte unseres gerade angelegten Datenbanknutzers.mysql> GRANT ALL PRIVILEGES ON horde.* TO 'hordesystemuser'@'vml000090.dmz.nausch.org' IDENTIFIED BY 'Django-1$-a-G33k!' WITH GRANT OPTION MAX_QUERIES_PER_HOUR 0 MAX_CONNECTIONS_PER_HOUR 0 MAX_UPDATES_PER_HOUR 0 MAX_USER_CONNECTIONS 0;
Query OK, 0 rows affected (0.00 sec) mysql>
und
mysql> GRANT ALL PRIVILEGES ON horde.* TO 'hordesystemuser'@'10.0.0.90' IDENTIFIED BY 'Django-1$-a-G33k!' WITH GRANT OPTION MAX_QUERIES_PER_HOUR 0 MAX_CONNECTIONS_PER_HOUR 0 MAX_UPDATES_PER_HOUR 0 MAX_USER_CONNECTIONS 0;
Query OK, 0 rows affected (0.00 sec) mysql> <code> - **Rechte des Nutzers in der Datenbank neu laden** \\ Im letzten Schritt laden wir nun die Rechte unseres neuen Datenbankusers.<code>mysql> FLUSH PRIVILEGES;
Query OK, 0 rows affected (0.00 sec) mysql>
- mySQL-Datenbankverbindung beenden
Unsere Konfiguration unseres neuen Datenbanknutzers ist hiermit beendet und wir können die Verbindung zur Datenbank wieder schließen.mysql> exit Bye
- Datenbankverbindung testen
Zu guter Letzt versuchen wir nun von unserem Webserver aus eine Datebankverbindung zum Datenbankserver aufzubauen.$ mysql -D horde -h mysql.dmz.nausch.org -u hordeuser -p
Enter password:>/code> <code>Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 4453 Server version: 5.1.66 Source distribution Copyright (c) 2000, 2012, Oracle and/or its affiliates. All rights reserved. Oracle is a registered trademark of Oracle Corporation and/or its affiliates. Other names may be trademarks of their respective owners. Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. mysql>
mysql> show databases;
+--------------------+ | Database | +--------------------+ | information_schema | | horde | +--------------------+ 2 rows in set (0.00 sec) mysql>
mysql> use horde;
Database changed mysql>
mysql> show tables;
Empty set (0.00 sec) mysql>
mysql> quit Bye
Eigenes definiertes Logfile
Von Haus aus schreibt das Horde-Framework seine Meldungen ins Syslog. Möchten wir dies nicht so, sondern ein separates Logfile, dann können wir unseren Syslog-Server rsyslog entsprechend anweisen, die Horde-spezifischen Meldungen in einem eigenen Logfile abzulegen. Wir verändern hierzu die Konfigurationsdatei /etc/rsyslog.conf.
# vim /etc/rsyslog.conf
- /etc/rsyslog.conf
# rsyslog v5 configuration file # For more information see /usr/share/doc/rsyslog-*/rsyslog_conf.html # If you experience problems, see http://www.rsyslog.com/doc/troubleshoot.html #### MODULES #### $ModLoad imuxsock # provides support for local system logging (e.g. via logger command) $ModLoad imklog # provides kernel logging support (previously done by rklogd) #$ModLoad immark # provides --MARK-- message capability # Provides UDP syslog reception #$ModLoad imudp #$UDPServerRun 514 # Provides TCP syslog reception #$ModLoad imtcp #$InputTCPServerRun 514 #### GLOBAL DIRECTIVES #### # Use default timestamp format $ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat # File syncing capability is disabled by default. This feature is usually not required, # not useful and an extreme performance hit #$ActionFileEnableSync on # Include all config files in /etc/rsyslog.d/ $IncludeConfig /etc/rsyslog.d/*.conf #### RULES #### # Log all kernel messages to the console. # Logging much else clutters up the screen. #kern.* /dev/console # Django : 2013-01-22 # horde-Framework Loginformationen in einem eigenen Logfile ablegen programname, isequal, "HORDE" -/var/log/horde.log # Log anything (except mail) of level info or higher. # Don't log private authentication messages! # Django : 2013-01-22 # horde-Framework Loginformationen in einem eigenen Logfile ablegen # default: *.info;mail.none;authpriv.none;cron.none /var/log/messages :programname, isequal, "HORDE" ~ *.info;mail.none;authpriv.none;cron.none /var/log/messages # The authpriv file has restricted access. authpriv.* /var/log/secure # Log all the mail messages in one place. mail.* -/var/log/maillog # Log cron stuff cron.* /var/log/cron # Everybody gets emergency messages *.emerg * # Save news errors of level crit and higher in a special file. uucp,news.crit /var/log/spooler # Save boot messages also to boot.log local7.* /var/log/boot.log # ### begin forwarding rule ### # The statement between the begin ... end define a SINGLE forwarding # rule. They belong together, do NOT split them. If you create multiple # forwarding rules, duplicate the whole block! # Remote Logging (we use TCP for reliable delivery) # # An on-disk queue is created for this action. If the remote host is # down, messages are spooled to disk and sent when it is up again. #$WorkDirectory /var/lib/rsyslog # where to place spool files #$ActionQueueFileName fwdRule1 # unique name prefix for spool files #$ActionQueueMaxDiskSpace 1g # 1gb space limit (use as much as possible) #$ActionQueueSaveOnShutdown on # save messages to disk on shutdown #$ActionQueueType LinkedList # run asynchronously #$ActionResumeRetryCount -1 # infinite retries if host is down # remote host is: name/ip:port, e.g. 192.168.0.1:514, port optional #*.* @@remote-host:514 # ### end of the forwarding rule ###
# touch /var/log/horde.log
# chown apache.apache /var/log/horde.log
Die Änderungen werden durch einen Restart des Daemon aktiviert.
# service rsyslog restart
Shutting down system logger: [ OK ] Starting system logger: [ OK ]
Alarmierungen per eMail
Mit Hilfe des Programms horde-alarms kann Horde an die spezifizierten Administratoren eMails mit Stati und Alarmmeldungen versenden. Laut der Konfigurationsdokumentation soll man hierzu alle 5 Minuten das script laufen lassen. Wir ergänzen also die vorhandene Konfigurationsdatei /etc/crontab.
# vim /etc/crontab
- /etc/crontab
SHELL=/bin/bash PATH=/sbin:/bin:/usr/sbin:/usr/bin MAILTO=root HOME=/ # For details see man 4 crontabs # Example of job definition: # .---------------- minute (0 - 59) # | .------------- hour (0 - 23) # | | .---------- day of month (1 - 31) # | | | .------- month (1 - 12) OR jan,feb,mar,apr ... # | | | | .---- day of week (0 - 6) (Sunday=0 or 7) OR sun,mon,tue,wed,thu,fri,sat # | | | | | # * * * * * user-name command to be executed # Django : 2013-01-22 Horde-Alarmierung per eMail alle 5 Minuten starten. */5 * * * * /usr/bin/horde-alarms
Horde personalisieren
Im Browserfenster wird oben der Anwendungs/Webseitenname dargestellt. Im Falle unseres Horde-Frameworks lautet dieser schlicht und einfach Horde. Will man hier (s)einen Firmen- oder Kundennamen sehen, kann man über die Konfigurationsdatei /var/www/horde/config/registry.local.php den Namen anpassen. Wir legen einfach diese Datei an und tragen den gewünschten Namen dort ein.
# vim /var/www/horde/config/registry.local.php
- /var/www/horde/config/registry.local.php
<?php # Django : 2013-01-24 Namen des Horde-Framworks angepasst $this->applications['horde']['name'] = _("Djangos Weboffice");
Die Konfiguration wird beim Aufrufen der Webseite angezogen, somit erübrigt sich ein Reload bzw. Restart des Webservers.
Voraussetzungen überprüfen
Will man noch mal sicherstellen, dass alle Voraussetzungen für die Konfiguration des Horde-Frameworks auch wirklich gegeben sind, so greift man auf die Horde-eigene Tetsseite zurück.
Vor dem Aufruf der Testseite, kontrollieren wir, ob der Parameter testdisable in der Konfigurationsdatei /var/www/horde/config/conf.php auf den Wert false steht.
# vim /var/www/horde/config/conf.php
Falls dieser auf true ändern wir den konfigurationseintrag einfach auf $conf['testdisable'] = false;.
Anschließen rufen wir die Testseite unseres Webmailers auf http://weboffice.nausch.org/test.php auf.
Haben wir ggf. noch nötige Pakete nachinstalliert oder Anpassungen vorgenommen, bitte nicht vergessen den Paramter wieder zurück auf $conf['testdisable'] = true; zu setzen.
django