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

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  ]

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.

  1. 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> 
  2. 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> 
  3. 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>
  4. 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
  5. 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

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  ]

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

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.

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.

Cookies helfen bei der Bereitstellung von Inhalten. Durch die Nutzung dieser Seiten erklären Sie sich damit einverstanden, dass Cookies auf Ihrem Rechner gespeichert werden. Weitere Information
  • centos/mail_c6/horde_5_1.txt
  • Zuletzt geändert: 22.11.2013 12:51.
  • von django