Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
Beide Seiten der vorigen Revision Vorhergehende Überarbeitung Nächste Überarbeitung | Vorhergehende Überarbeitung | ||
centos:mail_c7:horde_1 [19.09.2014 06:45. ] – [PHP Einstellungen anpassen] django | centos:mail_c7:horde_1 [20.04.2018 10:46. ] (aktuell) – Externe Bearbeitung 127.0.0.1 | ||
---|---|---|---|
Zeile 1345: | Zeile 1345: | ||
</ | </ | ||
- | # yum localinstall http:// | + | # yum localinstall http:// |
Anschließend starten wir unseren http-Daemon 1x durch. | Anschließend starten wir unseren http-Daemon 1x durch. | ||
# systemctl restart httpd.service | # systemctl restart httpd.service | ||
- | ===== Installationsdokumentation | + | ===== Dokumentation |
+ | ==== Installation | ||
# cat / | # cat / | ||
- | <code> | + | <file / |
| | ||
============================== | ============================== | ||
Zeile 2243: | Zeile 2244: | ||
.. _`session.gc_divisor`: | .. _`session.gc_divisor`: | ||
.. _`session.gc_maxlifetime`: | .. _`session.gc_maxlifetime`: | ||
- | </code> | + | </file> |
- | ===== PHP Einstellungen anpassen===== | + | ==== Sicherheit |
- | Gemäß den angaben | + | # cat / |
+ | |||
+ | <file / | ||
+ | Horde Security Notes | ||
+ | ====================== | ||
+ | |||
+ | :Contact: horde@lists.horde.org | ||
+ | |||
+ | .. contents:: Contents | ||
+ | .. section-numbering:: | ||
+ | |||
+ | |||
+ | Temporary files | ||
+ | =============== | ||
+ | |||
+ | Horde applications make extensive use of temporary files. | ||
+ | sure these files are secure, you should make sure your installation meets the | ||
+ | following criteria. | ||
+ | |||
+ | Sites may gain increased security by defining a temporary directory in the | ||
+ | Horde configuration which is writable by the web server, but not writable by | ||
+ | other users. | ||
+ | is best to also make these file unreadable by other users. | ||
+ | be made readable and writable only by the web server user. | ||
+ | |||
+ | |||
+ | PHP Sessions | ||
+ | ============ | ||
+ | |||
+ | For the most security, you should enable PHP session cookies by enabling the | ||
+ | PHP setting ``session.use_cookies``. When doing so, be sure to set an | ||
+ | appropriate cookie path and cookie domain in the Horde configuration also to | ||
+ | secure your cookies. You should even force session cookie usage in the Horde | ||
+ | configuration, | ||
+ | |||
+ | If you want to use HTTPS connections, | ||
+ | Horde configuration. This will force cookies to be sent over secure connections | ||
+ | only and helps to prevent sidejacking. | ||
+ | |||
+ | If PHP sessions are set to use the ``files`` save_handler, | ||
+ | should be secured properly. Sites can increase security by setting the PHP | ||
+ | setting ``session.save_path`` to a directory that is only readable and | ||
+ | writable by the web server process. | ||
+ | |||
+ | Sites with a large user base should consider setting the | ||
+ | ``session.entropy_file`` and ``session.entropy_length`` to appropriate values. | ||
+ | |||
+ | Horde will encrypt the user credentials before storing them in the session. | ||
+ | Thus, a compromised sessions will not reveal the user's stored credentials. | ||
+ | |||
+ | |||
+ | Default database passwords | ||
+ | ========================== | ||
+ | |||
+ | The Horde documentation and sample database creation scripts create a default | ||
+ | user and password for accessing the horde database. | ||
+ | production environment is a security hole, since an attacker will easily guess | ||
+ | it. | ||
+ | |||
+ | It is very important that sites change at least the password to something | ||
+ | secure. | ||
+ | |||
+ | |||
+ | Prevent configuration file reading and writing | ||
+ | ============================================== | ||
+ | |||
+ | The configuration files may contain sensitive data (such as database | ||
+ | passwords) that should not be read or written by local system users or remote | ||
+ | web users. | ||
+ | |||
+ | If you use a Unix system, one way to make the configuration files and | ||
+ | directories accessible only to the web server is as follows. | ||
+ | that the web server runs as the user ``apache`` and the files are located in | ||
+ | ``/ | ||
+ | |||
+ | $ chown -R apache / | ||
+ | $ chown -R apache / | ||
+ | $ chmod -R go-rwx / | ||
+ | $ chmod -R go-rwx / | ||
+ | |||
+ | For completely fascist permissions, | ||
+ | inaccessible by anyone except the web server user (and root):: | ||
+ | |||
+ | $ chown -R apache / | ||
+ | $ chmod -R go-rwx | ||
+ | $ chmod -R a-w / | ||
+ | |||
+ | Note that the last line makes all files unwritable by any user (only root can | ||
+ | override this). | ||
+ | administrate. | ||
+ | configuration interface, forcing you to update the Horde configuration files | ||
+ | manually (as per the INSTALL_ instructions). | ||
+ | |||
+ | The above will not secure the files if other user's on the same machine can | ||
+ | run scripts as the apache user. If you need to protect against this you | ||
+ | should make other user's scripts run under their own account with some | ||
+ | facility such as apache' | ||
+ | cgi scripts, but also for other modules like mod_php, mod_perl, mod_python, | ||
+ | etc. that may be in use on your server. | ||
+ | |||
+ | .. _INSTALL: ? | ||
+ | |||
+ | |||
+ | Restricting the test script | ||
+ | =========================== | ||
+ | |||
+ | The test script (``horde/ | ||
+ | be used against the site by attackers. | ||
+ | this reason. | ||
+ | |||
+ | This script is configured via the ' | ||
+ | |||
+ | After manually enabling the script, and once you have confirmed that | ||
+ | everything is working, you should disable access to the test script. | ||
+ | |||
+ | |||
+ | Preventing Apache from serving configuration and source files | ||
+ | ============================================================== | ||
+ | |||
+ | The Horde configuration files may contain sensitive data (such as database | ||
+ | passwords) that should not be served by the web server. Other directories | ||
+ | contain PHP source code that isn't intended for viewing by end-users. The | ||
+ | Horde group has provided ``.htaccess`` files in various directories to help | ||
+ | protect these files. | ||
+ | ``.htacess`` files (which is a performance hit, and may not be available in | ||
+ | all web servers). | ||
+ | |||
+ | An Apache site can also prevent the web server from serving these | ||
+ | files by adding sections to ``httpd.conf`` such as the following:: | ||
+ | |||
+ | < | ||
+ | order deny, | ||
+ | deny from all | ||
+ | </ | ||
+ | < | ||
+ | order deny, | ||
+ | deny from all | ||
+ | </ | ||
+ | < | ||
+ | order deny, | ||
+ | deny from all | ||
+ | </ | ||
+ | < | ||
+ | order deny, | ||
+ | deny from all | ||
+ | </ | ||
+ | < | ||
+ | order deny, | ||
+ | deny from all | ||
+ | </ | ||
+ | < | ||
+ | order deny, | ||
+ | deny from all | ||
+ | </ | ||
+ | |||
+ | Repeat this pattern for each Horde application. | ||
+ | would then add:: | ||
+ | |||
+ | < | ||
+ | order deny, | ||
+ | deny from all | ||
+ | </ | ||
+ | < | ||
+ | order deny, | ||
+ | deny from all | ||
+ | </ | ||
+ | < | ||
+ | order deny, | ||
+ | deny from all | ||
+ | </ | ||
+ | < | ||
+ | order deny, | ||
+ | deny from all | ||
+ | </ | ||
+ | < | ||
+ | order deny, | ||
+ | deny from all | ||
+ | </ | ||
+ | < | ||
+ | order deny, | ||
+ | deny from all | ||
+ | </ | ||
+ | |||
+ | |||
+ | Setup scripts | ||
+ | ============= | ||
+ | |||
+ | There are various scripts use to setup or configure Horde. | ||
+ | users on the web server machine, you should protect these files from being | ||
+ | accessed by them. On a unix system, you might restrict these files to root | ||
+ | access by using the following type of commands:: | ||
+ | |||
+ | $ chown -R root / | ||
+ | $ chown -R root / | ||
+ | $ chmod -R go-rwx / | ||
+ | $ chmod -R go-rwx / | ||
+ | |||
+ | |||
+ | Using a chroot web server setup | ||
+ | =============================== | ||
+ | |||
+ | Unix users may want to consider using a chroot environment for their web | ||
+ | server. | ||
+ | information exists on the world wide web and/or in your server documentation | ||
+ | to complete this task. | ||
+ | |||
+ | |||
+ | Hiding PHP info from the user | ||
+ | ============================= | ||
+ | |||
+ | You should consider setting the following PHP variables in your ``php.ini`` | ||
+ | file to prevent information leak to the user, or global insertion by the | ||
+ | user:: | ||
+ | |||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | |||
+ | You should also set up error logging (using the PHP ``error_log`` variable) | ||
+ | to log to a file, syslog, or other log destination. | ||
+ | |||
+ | |||
+ | Using a secure web server | ||
+ | ========================= | ||
+ | |||
+ | Horde depends on passing sensitive information (such as passwords and session | ||
+ | information) between the web server and the web client. | ||
+ | (SSL-enabled) web server will help protect this information as it traversing | ||
+ | the network. | ||
+ | |||
+ | |||
+ | Using a secure POP3/IMAP server | ||
+ | =============================== | ||
+ | |||
+ | If you are using a POP3/IMAP server with Horde (e.g. for authentication or for | ||
+ | IMP) then Horde is passing the user's login credentials between the web server | ||
+ | and the mail server. | ||
+ | |||
+ | If your web server and IMAP server are on the same host, you can increase | ||
+ | security by forcing all traffic over the loopback or localhost interface so | ||
+ | that it is not exposed to your network. | ||
+ | |||
+ | In cases where that is not possible, we recommend using a secure mail | ||
+ | connection such as IMAP-SSL or POP3-SSL to ensure that passwords remain safe. | ||
+ | |||
+ | |||
+ | LDAP Security | ||
+ | ============= | ||
+ | |||
+ | LDAP security is similar to the above POP3/IMAP server security issue. | ||
+ | are using LDAP, you should make sure that you are not exposing ldap passwords | ||
+ | or any sensitive data in your LDAP database. | ||
+ | |||
+ | |||
+ | Database socket security | ||
+ | ======================== | ||
+ | |||
+ | If your database (e.g. MySQL or PostgreSQL) is on the same host as your web | ||
+ | server, you may use unix sockets rather than tcp connections to help improve | ||
+ | your security (and performance). | ||
+ | achieve some better security by restricting the tcp support to the loopback or | ||
+ | localhost interface. | ||
+ | |||
+ | If the database keeps its socket file (e.g. ``mysql.sock``) in a directory | ||
+ | like ``/tmp`` or ``/ | ||
+ | that local users (if you have any) can't delete the socket. | ||
+ | bit should already be sent on the temporary directory itself, but you also | ||
+ | need to make sure the socket itself isn't writable by " | ||
+ | delete it. | ||
+ | |||
+ | You might consider moving the socket file to another location such as | ||
+ | ``/ | ||
+ | ``/ | ||
+ | |||
+ | |||
+ | Sendmail or SMTP considerations | ||
+ | =============================== | ||
+ | |||
+ | In some cases, you can increase security by sending mail via the local | ||
+ | command-line sendmail program on your web server, rather than using SMTP. | ||
+ | However, there may be reasons to use SMTP instead, such as if your smtp server | ||
+ | does spam or virus checking which would be skipped using the local sendmail | ||
+ | program. | ||
+ | |||
+ | |||
+ | Additional Notes | ||
+ | ================ | ||
+ | |||
+ | This is by far not a complete security HOWTO. This is just a compiled list of | ||
+ | what people have contributed so far. If you have tips, ideas, suggestions or | ||
+ | anything else that you think could help others in securing their Horde | ||
+ | installation, | ||
+ | </ | ||
+ | http:// | ||
+ | |||
+ | ==== Performance ==== | ||
+ | # cat / | ||
+ | |||
+ | <file / | ||
+ | Horde Performance Guide | ||
+ | ========================= | ||
+ | |||
+ | :Contact: horde@lists.horde.org | ||
+ | |||
+ | .. contents:: Contents | ||
+ | |||
+ | |||
+ | Some tips on performance tuning systems for Horde. | ||
+ | hardware tuning or even low level system (network, filesystem, etc) tuning. | ||
+ | |||
+ | Don't apply the following tuning hints blindly. | ||
+ | and after the changes under the conditions that are important for you. For | ||
+ | some people it's more important to make them as fast as possible for a small | ||
+ | user base, others require the applications to scale well under a high load. | ||
+ | Some of these hints might even make the applications slower under certain | ||
+ | conditions or using a certain hardware. | ||
+ | |||
+ | |||
+ | Linux Tuning | ||
+ | ============ | ||
+ | |||
+ | * Recompile RPMS for your architecture (e.g. i586, i686, athlon, etc). | ||
+ | This applies most to your Apache, PHP, IMAP, and POP3 packages. | ||
+ | |||
+ | |||
+ | Webserver/ | ||
+ | ==================== | ||
+ | |||
+ | * Consider a PHP accelerator program. | ||
+ | Suite`_, the `Alternative PHP Cache`_, eAccelerator_, | ||
+ | accelerators speed up access by caching the compiled PHP code, eliminating | ||
+ | the need to recompile the code for every single page load. **This is probably | ||
+ | the easiest way to improve the performance of Horde**. See Autoloading_ | ||
+ | further down to get even more out of some of those accelerators. | ||
+ | |||
+ | * Enable PHP output compression in the Horde configuration. Do not enable | ||
+ | compression in the PHP configuration (i.e. in ``php.ini``), | ||
+ | scripts don't work well with compression and Horde takes care of disabling | ||
+ | compression conditionally. | ||
+ | |||
+ | * Keep the include path defined in ``php.ini`` as short as possible, with the | ||
+ | most frequently used library paths first. | ||
+ | local directory ``.`` because Horde always uses full paths instead of | ||
+ | relative paths. | ||
+ | |||
+ | * Use an optimized ``php.ini``: | ||
+ | dsitribution. | ||
+ | |||
+ | * Don't run PHP session garbage collection too often if using a slow storage | ||
+ | medium (like SQL). (See ``session.gc_probability`` in ``php.ini``) | ||
+ | |||
+ | * If you have a large number of sessions and are using PHP's default file | ||
+ | based session handler, consider storing them in hashed directory levels. | ||
+ | (See ``session.save_path`` at http:// | ||
+ | |||
+ | * Consider using a faster storage medium for sessions, such as a tmpfs | ||
+ | (if storing sessions locally) or memcache (for storing session information | ||
+ | that can be accessed by multiple servers). | ||
+ | |||
+ | * Only load as many Apache and PHP extensions as needed (to reduce memory | ||
+ | usage). | ||
+ | |||
+ | * Use statically compiled Apache modules, including the PHP module. | ||
+ | |||
+ | * Use compiler optimizations (--prefer-non-pic, | ||
+ | -mmmx, -mfpmath=sse, | ||
+ | |||
+ | * If using SSL with a large site, consider a hardware SSL accelerator. | ||
+ | |||
+ | * Use shared memory for the Apache SSL cache if possible. | ||
+ | |||
+ | * To improve caching of static content if accessing Apache SSL with Internet | ||
+ | Explorer, try setting longer expiration periods:: | ||
+ | |||
+ | ExpiresActive On | ||
+ | ExpiresByType image/png "now plus 1 month" | ||
+ | ExpiresByType image/gif "now plus 1 month" | ||
+ | ExpiresByType text/ | ||
+ | ExpiresByType application/ | ||
+ | ExpiresByType text/css "now plus 1 month" | ||
+ | |||
+ | .. Note:: You must compile the ``mod_expires`` extension into Apache in | ||
+ | order to use these directives. | ||
+ | |||
+ | .. Warning:: This might cause problems if you upgrade Horde and the users' | ||
+ | | ||
+ | |||
+ | * Disable DNS lookups in your Apache logging, or use a caching DNS server on | ||
+ | the web server host. | ||
+ | |||
+ | * Enable Apache keepalives. | ||
+ | |||
+ | * You can configure Horde to serve all images, style sheets and/or static | ||
+ | javascript files from a different server. This could be a very lightweight | ||
+ | server without PHP (and other CGI modules) builtin. If using SSL to serve | ||
+ | all pages, the images/js server will also have to serve SSL content or else | ||
+ | browsers will complain about non-secure content in a secure page. Since this | ||
+ | server does not need to handle dynamic content, it would be wise to use a | ||
+ | high-performance server with low memory and/or system resource requirements | ||
+ | (this `IBM Article`_ can provide further information). You need to set | ||
+ | the ``themesuri`` and/or ``jsuri`` parameters in ``config/ | ||
+ | all applications and copy all ``themes`` and/or ``js`` directories in the | ||
+ | same directory layout to the other server. | ||
+ | |||
+ | * Your webserver should use Expires headers to make sure static content can | ||
+ | be cached on the user's browser. | ||
+ | expiration date on all graphics, javascript files, and stylesheets, | ||
+ | the following to ``lighttpd.conf``:: | ||
+ | |||
+ | $HTTP[" | ||
+ | expire.url = ( "" | ||
+ | } | ||
+ | |||
+ | * Enable caching in horde. Several applications make heavy use of caching and, | ||
+ | if enabled, you will see a significant increase in performance. | ||
+ | |||
+ | * Enable caching/ | ||
+ | which concludes that " | ||
+ | impact on reducing response time". Caching via filesystem is HIGHLY | ||
+ | RECOMMENDED: | ||
+ | browsers. Caching can also be done via horde caching, but the | ||
+ | cache-busters used to generate unique URLs when the cached content changes | ||
+ | do not work 100% reliably across all browsers. | ||
+ | |||
+ | * It is highly recommended to install the horde_lz4 package to activate | ||
+ | compression for Horde data. horde_lz4 is a minimal package that does | ||
+ | real-time compression. On modern CPUs, this compression is as fast as an | ||
+ | (unoptimized) memcpy action, making the compression essentially ' | ||
+ | compared to uncompressed data. horde_lz4 can be installed via PECL (see | ||
+ | INSTALL for further details). | ||
+ | |||
+ | .. _`The Zend Performance Suite`: http:// | ||
+ | .. _`Alternative PHP Cache`: http:// | ||
+ | .. _eAccelerator: | ||
+ | .. _XCache: http:// | ||
+ | .. _`IBM Article`: http:// | ||
+ | .. _`Yahoo' | ||
+ | |||
+ | |||
+ | Sending Mail | ||
+ | ============ | ||
+ | |||
+ | * Generally using a local sendmail command to send mail will result in better | ||
+ | peformance than using a SMTP connection. | ||
+ | |||
+ | * Some MTA servers may be faster or more efficient than others. | ||
+ | switching to a faster format if needed. | ||
+ | |||
+ | |||
+ | PostgreSQL tuning | ||
+ | ================= | ||
+ | |||
+ | * Do a ``VACUUM`` command periodically to tune your database. | ||
+ | |||
+ | * Increase ``shared_buffers`` and ``sort_mem`` memory settings. | ||
+ | |||
+ | * If web server and database is on the same unix host, use unix sockets | ||
+ | instead of network connections for database access. | ||
+ | |||
+ | |||
+ | MySQL tuning | ||
+ | ============ | ||
+ | |||
+ | * If web server and database is on the same unix host, use unix sockets | ||
+ | instead of network connections for database access. | ||
+ | |||
+ | * Enable mysql query cache if you have sufficient RAM. Edit your ``my.cnf`` | ||
+ | file and add the following to the ``[mysqld]`` section (change the memory | ||
+ | size to meet your needs):: | ||
+ | |||
+ | set-variable = query_cache_size=128M | ||
+ | |||
+ | |||
+ | Horde tuning | ||
+ | ============ | ||
+ | |||
+ | Autoloading | ||
+ | ----------- | ||
+ | |||
+ | * Horde automatically loads PHP source files on demand which relies on the PHP | ||
+ | autoloading feature introduced with PHP 5 and the Horde Autoloader library. | ||
+ | Both allow to limit the set of source code files pulled into the system to | ||
+ | the minimal amount required to answer the current request. This saves memory | ||
+ | and time but at the same time the Autoloader library has to map each class | ||
+ | name to the path of the corresponding PHP file that holds the class | ||
+ | definition. This procedure is expensive and can slow the system down. | ||
+ | Fortunately the mapping is fixed unless files are added or removed which | ||
+ | usually only happens during an upgrade. | ||
+ | |||
+ | Thus Autoloading is amenable to caching and an easy way to improve the | ||
+ | performance of the Horde Autoloader library, is to install the Autoloader | ||
+ | Cache extension:: | ||
+ | |||
+ | pear install horde/ | ||
+ | |||
+ | This library is not installed by default because it will unconditionally use | ||
+ | any of the following cache backends and does not allow for any further | ||
+ | configuration: | ||
+ | temporary filesystem. | ||
+ | |||
+ | It also doesn' | ||
+ | Horde changes. In this case you either need to use the provided script to | ||
+ | empty the cache:: | ||
+ | |||
+ | | ||
+ | |||
+ | or empty the cache manually, e.g. by restarting the web server or deleting | ||
+ | the cache file from the temporary directory. | ||
+ | |||
+ | VFS | ||
+ | --- | ||
+ | |||
+ | * Try to avoid using a SQL backend for VFS. Many databases require binary data | ||
+ | to be heavily escaped, resulting in storage sizes that are many times | ||
+ | greater than the actual size of the data. File system VFS will normally | ||
+ | provide much improved performance. | ||
+ | |||
+ | |||
+ | Application tuning | ||
+ | ================== | ||
+ | |||
+ | * Some applications contain advanced features that might have a certain impact | ||
+ | on the performance. | ||
+ | application' | ||
+ | performance hit in the configuration web frontend. | ||
+ | </ | ||
+ | |||
+ | ===== Konfiguration ===== | ||
+ | ==== PHP Einstellungen | ||
+ | Gemäß den Angaben | ||
# vim / | # vim / | ||
Zeile 2261: | Zeile 2792: | ||
</ | </ | ||
- | * [[centos:mail_c6:horde_2|Basiskonfiguration von horde]] | + | Den Hinweisen aus der Sicherheitsdokumentation // |
- | * **horde | + | |
- | * [[centos:mail_c6:horde_3|Webmailer | + | <code php / |
- | * [[centos:mail_c6: | + | |
- | * [[centos:mail_c6:horde_5|Adressbuch | + | ; Decides whether PHP may expose the fact that it is installed on the server |
- | | + | ; (e.g. by adding its signature to the Web server header). |
- | * [[centos:mail_c6:horde_7|Kalender - kronolith]] | + | ; threat in any way, but it makes it possible to determine whether you use PHP |
- | * [[centos:mail_c6:horde_8|Filter-Regeln (IMAP) - ingo]] | + | ; on your server or not. |
- | * [[centos:mail_c6:horde_9|Passwort-Änderungen - passwd]] | + | ; http:// |
+ | ; Django : 2014-09-19 | ||
+ | ; horde' | ||
+ | ; default: expose_php = On | ||
+ | expose_php = Off | ||
+ | |||
+ | ... | ||
+ | </ | ||
+ | |||
+ | Zur Aktivierung der Anpassungen führen wir einen Reload des Apache-Daemon durch. | ||
+ | # systemctl reload httpd.service | ||
+ | |||
+ | ===== Apache vHost ===== | ||
+ | ==== vHost Definition ==== | ||
+ | Für unsere WEB-Applikation richten wir uns nun einen geeigneten **[[centos:web_c7:apache_2|SSL-Name Based Virtual Host]]** ein. | ||
+ | Im Konfigurationsverzeichnis unseres [[centos: | ||
+ | # vim / | ||
+ | |||
+ | <file apache / | ||
+ | # horde.sec-mail.guru (Horde Groupware Version 5) | ||
+ | # | ||
+ | < | ||
+ | ServerAdmin webmaster@nausch.org | ||
+ | ServerName horde.sec-mail.guru | ||
+ | ServerAlias xn--bro-hoa.sec-mail.guru | ||
+ | ServerPath / | ||
+ | |||
+ | < | ||
+ | Options -Indexes +FollowSymLinks | ||
+ | Require all granted | ||
+ | </ | ||
+ | |||
+ | RewriteEngine on | ||
+ | RewriteCond %{HTTPS} off | ||
+ | RewriteRule (.*) https:// | ||
+ | |||
+ | DirectoryIndex index.php | ||
+ | |||
+ | ErrorLog logs/ | ||
+ | CustomLog logs/ | ||
+ | </ | ||
+ | < | ||
+ | ServerAdmin webmaster@nausch.org | ||
+ | ServerName horde.sec-mail.guru | ||
+ | ServerAlias xn--bro-hoa.sec-mail.guru | ||
+ | ServerPath / | ||
+ | DocumentRoot "/ | ||
+ | |||
+ | < | ||
+ | SSLEngine on | ||
+ | SSLProtocol -ALL +SSLv3 +TLSv1 | ||
+ | SSLCipherSuite EECDH+AES256: | ||
+ | SSLHonorCipherOrder on | ||
+ | SSLCertificateFile / | ||
+ | SSLCertificateKeyFile / | ||
+ | SSLCertificateChainFile / | ||
+ | |||
+ | </ | ||
+ | |||
+ | < | ||
+ | GnuTLSEnable on | ||
+ | GnuTLSPriorities SECURE: | ||
+ | # # | ||
+ | GnuTLSCertificateFile / | ||
+ | GnuTLSKeyFile / | ||
+ | </ | ||
+ | |||
+ | < | ||
+ | AddOutputFilterByType DEFLATE text/html text/plain text/xml text/css text/ | ||
+ | AddOutputFilterByType DEFLATE application/ | ||
+ | < | ||
+ | < | ||
+ | SetOutputFilter DEFLATE | ||
+ | BrowserMatch ^Mozilla/4 gzip-only-text/ | ||
+ | BrowserMatch ^Mozilla/ | ||
+ | BrowserMatch \bMSIE !no-gzip !gzip-only-text/ | ||
+ | SetEnvIfNoCase Request_URI \.(?: | ||
+ | </ | ||
+ | < | ||
+ | Header append Vary User-Agent env=!dont-vary | ||
+ | </ | ||
+ | </ | ||
+ | </ | ||
+ | |||
+ | |||
+ | AddType application/ | ||
+ | |||
+ | # Link to system Javascript Libraries | ||
+ | Alias / | ||
+ | Alias / | ||
+ | Alias / | ||
+ | |||
+ | # Link to Micro$oft stuff | ||
+ | Alias / | ||
+ | Alias / | ||
+ | |||
+ | < | ||
+ | # **IMPORTANT** By default, everyone accessing Horde is automatically logged | ||
+ | # in as ' | ||
+ | # you change the authentication backend under the ' | ||
+ | # For this reason, Horde is currently only accessible from localhost. | ||
+ | < | ||
+ | # | ||
+ | # | ||
+ | # | ||
+ | Require all granted | ||
+ | </ | ||
+ | |||
+ | # Django : 2014-09-19 | ||
+ | # aus der Konfigurationsdatei php-horde-kronolith.conf übernommen | ||
+ | < | ||
+ | RewriteEngine On | ||
+ | RewriteBase | ||
+ | RewriteCond | ||
+ | RewriteCond | ||
+ | RewriteRule ^(.*)$ rampage.php [QSA,L] | ||
+ | </ | ||
+ | |||
+ | Options +FollowSymLinks | ||
+ | #Options All | ||
+ | # | ||
+ | |||
+ | # Rewrite the requestet URI, when it is with german " | ||
+ | RewriteEngine On | ||
+ | RewriteCond %{REQUEST_URI} ^/$ | ||
+ | RewriteCond %{HTTP_HOST} ^xn--bro-hoa.sec-mail.guru$ [NC] | ||
+ | RewriteRule ^$ https:// | ||
+ | |||
+ | # Exclude file from password protection | ||
+ | SetEnvIf Request_URI " | ||
+ | SetEnvIf Request_URI " | ||
+ | SetEnvIf Request_URI " | ||
+ | SetEnvIf Request_URI " | ||
+ | SetEnvIf Request_URI " | ||
+ | SetEnvIf Request_URI " | ||
+ | |||
+ | # ActiveSync | ||
+ | RewriteEngine On | ||
+ | RewriteRule ^/ | ||
+ | RewriteRule .* - [E=HTTP_MS_ASPROTOCOLVERSION: | ||
+ | RewriteRule .* - [E=HTTP_X_MS_POLICYKEY: | ||
+ | RewriteRule .* - [E=HTTP_AUTHORIZATION: | ||
+ | </ | ||
+ | |||
+ | # Deny access to the test.php files except from localhost | ||
+ | <Files " | ||
+ | # Django : 2014-09-19 | ||
+ | # Zugriff generell verbieten | ||
+ | # Require all denied | ||
+ | # Zugriff nur vom Host vml000010.dmz.nausch.org aus erlauben | ||
+ | Require host vml000010.dmz.nausch.org | ||
+ | </ | ||
+ | |||
+ | # Those directories should not be viewed by Web clients. | ||
+ | < | ||
+ | Require all denied | ||
+ | </ | ||
+ | < | ||
+ | Require all denied | ||
+ | </ | ||
+ | |||
+ | |||
+ | < | ||
+ | < | ||
+ | RewriteEngine On | ||
+ | RewriteCond | ||
+ | RewriteCond | ||
+ | RewriteRule | ||
+ | </ | ||
+ | </ | ||
+ | |||
+ | # Django : 2014-09-19 | ||
+ | # aus der Konfigurationsdatei php-horde-content.conf übernommen | ||
+ | < | ||
+ | < | ||
+ | RewriteEngine On | ||
+ | RewriteCond | ||
+ | RewriteCond | ||
+ | RewriteRule ^(.*)$ index.php [QSA,L] | ||
+ | </ | ||
+ | </ | ||
+ | |||
+ | # Django : 2014-09-19 | ||
+ | # aus der Konfigurationsdatei php-horde-kronolith.conf übernommen | ||
+ | < | ||
+ | < | ||
+ | RewriteEngine On | ||
+ | RewriteCond | ||
+ | RewriteCond | ||
+ | RewriteRule | ||
+ | </ | ||
+ | </ | ||
+ | |||
+ | DirectoryIndex index.php | ||
+ | ErrorLog logs/ | ||
+ | CustomLog logs/ | ||
+ | </ | ||
+ | </ | ||
+ | |||
+ | <WRAP round important> | ||
+ | |||
+ | Solange wir unseren vHost noch nicht in der Produktionsumgebung steht und fertig konfiguriert wurde, beschränken wir den Zugriff auf den vHost noch. Hierzu tragen wir in der **Directive // | ||
+ | <code apache> | ||
+ | < | ||
+ | # Access-stuff (Zugriff von überall erlauben.) | ||
+ | #Require all granted | ||
+ | # Access-stuff (Zugriff nur vom Admin-Netz aus!) | ||
+ | Require host nausch.org | ||
+ | </ | ||
+ | ... | ||
+ | </ | ||
+ | Nach erfolgter Konfiguration, | ||
+ | <code apache> | ||
+ | < | ||
+ | # Access-stuff (Zugriff von überall erlauben.) | ||
+ | Require all granted | ||
+ | # Access-stuff (Zugriff nur vom Admin-Netz aus!) | ||
+ | #Require host nausch.org | ||
+ | </ | ||
+ | ... | ||
+ | </ | ||
+ | </ | ||
+ | |||
+ | ==== Konfiguration aktivieren ==== | ||
+ | Bevor unseren Webserver starten, damit der neue vHost auch bedient werden kann, überprüfen wir die Konfiguration noch auf syntaktische Fehler. | ||
+ | # apachectl -t | ||
+ | |||
+ | | ||
+ | |||
+ | Abschließend führen wir einen Reload sdes Daemon durch. | ||
+ | # systemctl reload httpd.service | ||
+ | |||
+ | Bei Bedarf können wir auch den Status des Apche Webservers abfragen. | ||
+ | # systemctl status httpd.service | ||
+ | |||
+ | < | ||
+ | | ||
+ | | ||
+ | Process: 20019 ExecStop=/ | ||
+ | Process: 22718 ExecReload=/ | ||
+ | Main PID: 20024 (httpd) | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | | ||
+ | |||
+ | Sep 10 19:45:20 vml000097.dmz.nausch.org systemd[1]: Reloading The Apache HTTP Server. | ||
+ | Sep 10 19:45:21 vml000097.dmz.nausch.org systemd[1]: Reloaded The Apache HTTP Server. | ||
+ | </ | ||
+ | |||
+ | |||
+ | |||
+ | ===== mySQL Datenbank ===== | ||
+ | Ein Großteil der Benutzer-Konfigurationsdaten werden in einer **[[centos: | ||
+ | |||
+ | ==== Datenbank anlegen ==== | ||
+ | Diese **[[centos:mysql|mySQL-Datenbank]]** /* FIXME */ und der zugehörige Datenbankuser werden wird nun im ersten Schritt anlegen. | ||
+ | |||
+ | Wir melden uns also als berechtigter Datenbankuser an der mySQL-Datenbank an. | ||
+ | | ||
+ | |||
+ | < | ||
+ | Welcome to the MySQL monitor. | ||
+ | Your MySQL connection id is 217075 | ||
+ | Server version: 5.1.73 Source distribution | ||
+ | |||
+ | Copyright (c) 2000, 2013, 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 ' | ||
+ | |||
+ | mysql> | ||
+ | </ | ||
+ | Dort legen wir als aller erst einmal eine Datenbank mit dem Namen **horde** an. | ||
+ | | ||
+ | |||
+ | Query OK, 1 row affected (0.00 sec) | ||
+ | |||
+ | ==== Datenbankuser anlegen ==== | ||
+ | Anschließend legen wir uns einen Datenbankuser an, denen wir entsprechende Rechte an der, gerade angelegten Datenbank **horde** einräumen. Als Namen nehme wir einfach **hode_admin_user**. | ||
+ | |||
+ | | ||
+ | |||
+ | Query OK, 0 rows affected (0.00 sec) | ||
+ | |||
+ | und | ||
+ | | ||
+ | |||
+ | Query OK, 0 rows affected (0.00 sec) | ||
+ | |||
+ | ==== Nutzerberechtigungen setzen ==== | ||
+ | Dem gerade angelebtem Datenbankuser für **[[http:// | ||
+ | | ||
+ | |||
+ | |||
+ | Query OK, 0 rows affected (0.00 sec) | ||
+ | |||
+ | und | ||
+ | | ||
+ | |||
+ | Query OK, 0 rows affected (0.00 sec) | ||
+ | |||
+ | ==== Nutzerberechtigungen zuweisen ==== | ||
+ | Zum Ende unserer mySQL-Userkonfiguration weisen wir unserem Nutzer die Berechtigungen zu. | ||
+ | | ||
+ | |||
+ | Query OK, 0 rows affected (0.00 sec) | ||
+ | |||
+ | Wir können uns nun vom Datenbank-Server wieder abmelden. | ||
+ | | ||
+ | |||
+ | Bye | ||
+ | |||
+ | ==== Zugriff testen ==== | ||
+ | Als nächstes überprüfen wir, ob der zuvor angelegt User/Zugang vom WEB-Server aus auch funktioniert. | ||
+ | # mysql -D horde5 -h mysql.dmz.nausch.org -u horde_admin_user -p | ||
+ | < | ||
+ | Welcome to the MariaDB monitor. | ||
+ | Your MySQL connection id is 217265 | ||
+ | Server version: 5.1.73 Source distribution | ||
+ | |||
+ | Copyright (c) 2000, 2014, Oracle, Monty Program Ab and others. | ||
+ | |||
+ | Type ' | ||
+ | |||
+ | MySQL [horde5]> | ||
+ | </ | ||
+ | Die Verbindung klappt schon mal, daher lassen wir uns mal ansehen, welche Datenbanken der administrative Horde-User sehen kann. | ||
+ | |||
+ | |||
+ | MySQL [horde5]> | ||
+ | < | ||
+ | | Database | ||
+ | +--------------------+ | ||
+ | | information_schema | | ||
+ | | horde5 | ||
+ | +--------------------+ | ||
+ | 2 rows in set (0.01 sec) | ||
+ | |||
+ | MySQL [horde5]> | ||
+ | </ | ||
+ | Auch dieser Test fiel positiv aus, wir können uns daher die Verbindung zum Datenbank-Server beenden und uns der weiteren konfiguration widmen. | ||
+ | MySQL [horde5]> quit | ||
+ | |||
+ | Bye | ||
+ | |||
+ | ===== weitere Schritte zur Einrichtung ===== | ||
+ | Nach der erfolgreichen Einrichtung des [[centos:mail_c7:horde_1?&# | ||
+ | |||
+ | ====== Links ====== | ||
+ | * **⇒ [[centos:mail_c7:horde_2|Weiter zum Kapitel " | ||
+ | * **[[centos:mail_c7:start|Zurück zum Kapitel >> | ||
+ | * **[[wiki:start|Zurück zu >> | ||
+ | * **[[http:// | ||
+ |