Archiv der Kategorie: Installation

Installation, wie der Name schon sagt

eGroupware installieren

For xUbuntu 14.04 run the following:

sudo sh -c "echo 'deb http://download.opensuse.org/repositories/server:/eGroupWare/xUbuntu_14.04/ /' >> /etc/apt/sources.list.d/egroupware-epl.list"
sudo apt-get update
sudo apt-get install egroupware-epl

You can add the repository key to apt. Keep in mind that the owner of the key may distribute updates, packages and repositories that your system will trust (more information). To add the key, run:

wget http://download.opensuse.org/repositories/server:eGroupWare/xUbuntu_14.04/Release.key
sudo apt-key add - < Release.key

phpmyadmin installieren und absichern

Step One — Install phpMyAdmin

To get started, we can simply install phpMyAdmin from the default Ubuntu repositories.

We can do this by updating our local package index and then using the apt packaging system to pull down the files and install them on our system:

sudo apt-get update
sudo apt-get install phpmyadmin

This will ask you a few questions in order to configure your installation correctly.

  • For the server selection, choose apache2. Note: If you do not hit „SPACE“ to select Apache, the installer will not move the necessary files during installation. Hit „SPACE“, „TAB“, and then „ENTER“ to select Apache.
  • Select yes when asked whether to use dbconfig-common to set up the database
  • You will be prompted for your database administrator’s password
  • You will then be asked to choose and confirm a password for the phpMyAdmin application itself

The installation process actually adds the phpMyAdmin Apache configuration file into the/etc/apache2/conf-enabled/ directory, where it is automatically read.

The only thing we need to do is explicitly enable the php5-mcrypt extension, which we can do by typing:

sudo php5enmod mcrypt

Afterwards, you’ll need to restart Apache for your changes to be recognized:

sudo service apache2 restart

You can now access the web interface by visiting your server’s domain name or public IP address followed by /phpmyadmin:

http://domain_name_or_IP/phpmyadmin

phpmyadmin login screen

You can now log into the interface using the root username and the administrative password you set up during the MySQL installation.

When you log in, you’ll see the user interface, which will look something like this:

phpmyadmin user interface

Step Two — Secure your phpMyAdmin Instance

We were able to get our phpMyAdmin interface up and running fairly easily. However, we are not done yet. Because of its ubiquity, phpMyAdmin is a popular target for attackers. We need to secure the application to help prevent unauthorized use.

One of the easiest way of doing this is to place a gateway in front of the entire application. We can do this using Apache’s built-in .htaccess authentication and authorization functionalities.

Configure Apache to Allow .htaccess Overrides

First, we need to enable the use of .htaccess file overrides by editing our Apache configuration file.

We will edit the linked file that has been placed in our Apache configuration directory:

sudo nano /etc/apache2/conf-available/phpmyadmin.conf

We need to add an AllowOverride All directive within the <Directory /usr/share/phpmyadmin>section of the configuration file, like this:

<Directory /usr/share/phpmyadmin>
    Options FollowSymLinks
    DirectoryIndex index.php
    AllowOverride All
    . . .

When you have added this line, save and close the file.

To implement the changes you made, restart Apache:

sudo service apache2 restart

Create an .htaccess File

Now that we have enabled .htaccess use for our application, we need to create one to actually implement some security.

In order for this to be successful, the file must be created within the application directory. We can create the necessary file and open it in our text editor with root privileges by typing:

sudo nano /usr/share/phpmyadmin/.htaccess

Within this file, we need to enter the following information:

AuthType Basic
AuthName "Restricted Files"
AuthUserFile /etc/phpmyadmin/.htpasswd
Require valid-user

Let’s go over what each of these lines mean:

  • AuthType Basic: This line specifies the authentication type that we are implementing. This type will implement password authentication using a password file.
  • AuthName: This sets the message for the authentication dialog box. You should keep this generic so that unauthorized users won’t gain any information about what is being protected.
  • AuthUserFile: This sets the location of the password file that will be used for authentication. This should be outside of the directories that are being served. We will create this file shortly.
  • Require valid-user: This specifies that only authenticated users should be given access to this resource. This is what actually stops unauthorized users from entering.

When you are finished, save and close the file.

Create the .htpasswd file for Authentication

Now that we have specified a location for our password file through the use of the AuthUserFiledirective within our .htaccess file, we need to create this file.

We actually need an additional package to complete this process. We can install it from our default repositories:

sudo apt-get install apache2-utils

Afterward, we will have the htpasswd utility available.

The location that we selected for the password file was „/etc/phpmyadmin/.htpasswd„. Let’s create this file and pass it an initial user by typing:

sudo htpasswd -c /etc/phpmyadmin/.htpasswd username

You will be prompted to select and confirm a password for the user you are creating. Afterwards, the file is created with the hashed password that you entered.

If you want to enter an additional user, you need to do so without the -c flag, like this:

sudo htpasswd /etc/phpmyadmin/.htpasswd additionaluser

Now, when you access your phpMyAdmin subdirectory, you will be prompted for the additional account name and password that you just configured:

http://domain_name_or_IP/phpmyadmin

phpMyAdmin apache password

After entering the Apache authentication, you’ll be taken to the regular phpMyAdmin authentication page to enter your other credentials. This will add an additional layer of security since phpMyAdmin has suffered from vulnerabilities in the past.

Conclusion

You should now have phpMyAdmin configured and ready to use on your Ubuntu 14.04 server.

Neuen LAMP Server in Betrieb nehmen

wichtig, bei den meisten Virtual Servern, die gehostet werden ist Apache, PHP und MySQL schon installiert, muß aber noch in Betrieb genommen werden

apt-get update
apt-get upgrade

um erstmal die vorhandene Software auf den neuesten Stand zu bringen

apache starten PHP müßte dann mit kommen, kann über phpinfo.php im Document Root Verzeichnis überprüft werden

MySQL starten und mit

mysqladmin -u root password NEUESPASSWORD

ein Password vergeben, damit die diversen Scripte, die auf MySQL zugreifen und ein Passwort für den root user haben wollen auch funktionieren.

Open Xchange installieren

Nach diversen Versuchen Open Xchange zu installieren, unter Debian, unter CentOS mit Plesk Panel, die alle fehlgeschlagen sind, nun noch ein Versuch unter CentOS „ohne Alles“.

Eine recht gute Anleitung für die Installation findet man eigentlich direkt auf der Seite von OX, ich will hier aber auch auf ein paar Kleinigkeiten hinweisen und außerdem die (eventuellen) Besonderheiten bei einem Virtuellen Root Server (von Host Europe) vermerken.

Open Xchange AppSuite auf CentOS

Also starten wir mit der Anleitung speziell für CentOS von der OX Seite:

http://oxpedia.org/wiki/index.php?title=AppSuite:Open-Xchange_Installation_Guide_for_CentOS_6

Es wird mit Hilfe dieser Anleitung eine Single Server Installation durchgeführt mit einer Single Open-Xchange Instanz (kein Cluster, was mit OX auch möglich ist) und einer Datenbank mit nur einem Datenbank Service. Es wird nur die Open Xchange Installation beschrieben und die absolute Basis Konfiguration, keine Mailserver Installation, oder Konfiguration und auch keiner weiterführende OX Konfiguration.

Voraussetzungen

Was muß an Voraussetzungen gewährleistet sein?

Plain installed CentOS

Ein ohne Schnick-Schnack installiertes CentOS, also eine reine Basis-Installation. Ob dies bei mir der Fall ist, werde ich während der Installation erfahren, denn ich habe einen Virtuellen Root Server und da weiß man nie genau was alles installiert ist. Wenn zum Beispiel Plesk Panel installiert ist, dann ist auch MySQL drauf und schon mit Usern und vor allem Passwörtern versehen, was für diese Installationsanleitung ungeeignet ist.

A configured Internet connection

Allerdings sollte der Server über eine Internetverbindung verfügen, was aber bei einem gehosteten Server im Netz wohl durchaus gegeben ist, wie sollte man sonst selber darauf zugreifen können.

httpd – Apache web server

Der Apache Web Server sollte installiert sein, dies muß ich erstmal überprüfen, denn bei einer echten Plain Installation ist kein Web Server dabei. Ich muß also auf den Server, am besten über SSH-Konsole, ich verwende auf meinem Windows Rechner für diesen Zweck PuTTY, wie wohl die meisten. Dies hier ist keine PuTTY Anleitung, also verbindet Euch auf Euren Server.

Also bei mir ist der Apache2 installiert, nur wird er nicht beim Serverstart mitgestartet, er steht in allen runlevels auf off, dies erfährt man indem man mal

chkconfig –list –Levels eingibt

dann erfährt man was so alles installiert ist, aber nicht gestartet wird. Bei mir also auch httpd, so heißt Apache unter CentOS. Sollte der Diesnt noch nicht laufen, dann mit

/etc/init.d/httpd start

starten bitte. Mit einem kurzen Aufruf des Servers über einen Browser kann man prüfen ob der Apache auch arbeitet, denn wenn er es tut bekommt man eine Seite wie diese hier angezeigt.

2015009_231008_Apache_Server_Test_Page

Also bei mir erstmal alles in Butter. Weiter im Text.

Install vim first – Editor installieren

Dann wird in der Anleitung noch darauf hingewiesen, daß der VIM (Weiterentwicklung des VI) nicht standardmäßig installiert ist und deshalb auch noch nachinstalliert werden muß. Ich mochte schon den VI nicht und mit dem VIM fühle ich mich nicht viel wohler, also werde ich stattdessen den nano installieren, auch wenn die Linux Puristen jetzt die Nase rümpfen mögen.

yum install nano

Das System checkt und fragt nach ob die Downloadgröße so in Ordnung ist man sagt yes und los geht’s, zack complete.

Also ich würde sagen, ich habe die Voraussetzungen für die Installation von Open Xchange erfüllt.

PHP Prüfung

Nur um mich zu versichern ob PHP installiert und in welcher Version, habe ich die Datei

/var/www/html/info.php

mit folgendem Inhalt erzeugt

<?php
phpinfo();
?>

Dann habe ich auf meiner Internetseite, auf der ja das Apache Testbild läuft, hinten noch info.php rangehängt und schwups erzählt mir der Server die Version von PHP die installiert ist und hunderte von PHP Einstellungen und Parametern noch dazu. (Sicherheitshinweis, bitte prüfen, ob Ihr die Datei da stehen lassen könnt und wollt.)

Eventuell bekommen wir während der Installation noch Probleme mit MySQL, da MySQL schon installiert ist und ich nicht weiß ob schon Passwörter vergeben wurden und welche, aber das werden wir während der Installation erfahren. Los geht’s jetzt endlich.

Ich habe sicherheitshalber auch noch die Java Installation geprüft (Debian z.B. installiert sowas nämlich nicht mit) mit dem Befehl

java -v

spuckt mir das System eine Version aus und ich bin zufrieden, sollte Java nicht drauf sein, ein kurzes

yum install Java

erledigt dies dann für euch

Open Xchange Repositories hinzufügen

Um Open Xchange downloaden und installieren zu können ist der einfachste Weg, die Quellen dem Installer yum bekannt zu machen, dann überprüft der die in Zukunft immer mit und man kann auch ganz normal über yum installieren.

Wir erzeugen also ein Software-Repository-File für Open-Xchange

nano /etc/yum.repos.d/ox.repo

Folgendes wird in diese Datei eingetragen/reinkopiert und gespeichert:

[ox-appsuiteui]
name=Open-Xchange-appsuiteui
baseurl=http://software.open-xchange.com/products/appsuite/stable/appsuiteui/RHEL6/
gpgkey=http://software.open-xchange.com/oxbuildkey.pub
enabled=1
gpgcheck=1
metadata_expire=0m

[ox-backend]
name=Open-Xchange-backend
baseurl=http://software.open-xchange.com/products/appsuite/stable/backend/RHEL6/
gpgkey=http://software.open-xchange.com/oxbuildkey.pub
enabled=1
gpgcheck=1
metadata_expire=0m

Das wars schon

Update Repositories and installing packages

Repositories aktualisieren

Wir aktualisieren also die Pakete des Installers

yum update

und fertig aktualisiert.

Installation Open-Xchange

Kommen wir nun endlich zur eigentlichen Installation. Ich weiß, daß auf meinem System schon MySQL installiert ist, ich führe es der Vollständigkeit halber im Installationsbefehl trotzdem nochmal auf, also folgender Befehl installiert alles:

yum install mysql-server open-xchange open-xchange-authentication-database open-xchange-grizzly \
  open-xchange-admin open-xchange-appsuite \
  open-xchange-appsuite-backend open-xchange-appsuite-manifest

Ich muß zweimal mit yes bestätigen, Download und noch etwas und eine Weile warten, denn ein bißchen was ist ja schon zu installieren und dann ist das auch erledigt.

Open Xchange Konfiguration

OX User

Als erstes zu den Usern die wir verwenden, hier sollte man von allzuviel Kreativität Abstand nehmen, außer man kennt OX schon eine Weile, hat es mehrfach installiert und weiß an welchen Stellen überall in den diversen Installations- und Konfigurationsdateien man dann etwas ändern muß. Anfängern würde ich also empfehlen die Usernamen zu belassen (die kommen nämlich in einigen der Standardinstallationsscripte drin vor) und wirklich nur die Passwörter durch eigene ordentliche Passwörter zu ersetzen. Die User müssen nicht als Systembenutzer angelegt werden.

MySQL Datenbank User

Da wäre der MySQL Datenbank User für Open Xchange:

Username:      openexchange
Password:       db_Password (bitte durch eigenes ersetzen)
Aufgabe:          Führt alle Datenbankoperationen aus

Open Xchange Admin Master

Dann der Open Xchange Admin Master, also der Administrator für die gesamte OX Installation:

Username:     oxadminmaster
Password:      admin_master_Password (bitte durch eigenes ersetzen)
Aufgabe:         Contexte administrieren, Serverkonfiguration

Context Admin

Der Context Admin ist Administrator für jeweils einen Context innerhalb von OX

Username:     oxadmin
Password:      admin_Password (bitte durch eigenes ersetzen)
Aufgabe:         Administriert User/Gruppen/Ressourcen innerhalb seines Kontextes

Vorbereitungen

Um OX konfigurieren zu können muß der MySQL Server laufen. Wir starten den also, nur falls er noch nicht läuft:

/etc/init.d/mysqld start

Bei mir war es eindeutig der erste Start, er brachte diverse Hinweise wie ich MySQL abzusichern hätte usw., aber das erledigen wir bewußt erst nach der OX Installation, die mag nämlich gar nicht wenn es schon Passwörter und so was gibt.

Des Weiteren hält OX es für eine gute Idee den Open Xchange Pfad zu Standardpfadangabe des Systems hinzuzufügen, weil dies macht das starten von OX Befehlen und Programmen einfacher, also tun wir dies.

echo PATH=$PATH:/opt/open-xchange/sbin/ >> ~/.bashrc && . ~/.bashrc

Mit Hilfe des initconfigdb scriptes konfigurieren wir nun die OX Konfigurations Datenbank.

/opt/open-xchange/sbin/initconfigdb --configdb-pass=db_password -a

erledigt, hat funktioniert.

Der Parameter -a sorgte dafür, daß ein Administrator Account zu MySQL hinzugefügt wurde, mit dem wir später dann auch die Datenbank für OX anlegen können. War MySQL schon angelegt, kann dies zu Problemen in der weiteren Installation führen, man sollte also bei Problemen in den nächsten schritten in jedem Falle prüfen, ob das mit dem DB-User geklappt hat und ob der wirklich alle Privilegien besitzt.

Na dann starten wir mal ohne viel Vorrede den oxinstaller

/opt/open-xchange/sbin/oxinstaller --no-license \
--servername=sokrates --configdb-pass=db_password \
--master-pass=admin_master_password --network-listener-host=localhost --servermemory 1536

Und auch das funktionierte anstandslos, wunderbar.

Die offizielle Anleitung läßt mich jetzt Einstellungen für ein Mailserver Login vornehmen, aber dies möchte ich später tun, also weiter im Test.

Starten wir den OX Service

/etc/init.d/open-xchange start

Done OK, super.

Nun müssen wir noch den neuen Server bei der Open Xchange Konfigurations-Datenbank anmelden

/opt/open-xchange/sbin/registerserver -n sokrates -A oxadminmaster -P admin_master_password

Server 1 registered, heißt es hat geklappt.

Nun legen wir ein Verzeichnis an, in dem der Server Dateien wie Anhänge usw. ablegen kann und damit OX auch darauf zugreifen kann geben wir dem von den Scripten erzeugten Systemuser open-xchange auch die Rechte auf dieses Verzeichnis

mkdir /var/opt/filestore
chown open-xchange:open-xchange /var/opt/filestore

Und auch das scheint funktioniert zu haben. Bleibt noch das Verzeichnis auch als Filestore bei OX zu registrieren:

/opt/open-xchange/sbin/registerfilestore -A oxadminmaster -P admin_master_password \
-t file:/var/opt/filestore -s 1000000

filestore 2 registered, heißt auch das hat geklappt.

So, nun noch die OX Datenbank registrieren in der Open Xchange all seine Sachen ablegen kann und dann sollte es losgehen.

/opt/open-xchange/sbin/registerdatabase -A oxadminmaster -P admin_master_password \
-n oxdatabase -p db_password -m true

database 3 registered, heißt,h at auch geklappt.

Service Konfigurieren

Jetzt wo der Open Xchange Server läuft und die Datenbank dazu läuft müssen wir den Apache so konfigurieren, daß er auch das OX GUI anzeigt. Außerdem ist es empfohlen die Erweiterungen mod_expires und mod_deflate einzuschalten. Als erstes aber löschen wir die aktuelle Welcome Message unseres Apache Servers, obwohl uns diese bisher so viel Freude bereitet hat.

rm /etc/httpd/conf.d/welcome.conf

Begrüßung gelöscht. Jetzt konfigurieren wir das mod_Proxy_http Modul

nano /etc/httpd/conf.d/proxy_http.conf

folgender Inhalt soll in die Datei

LoadModule proxy_http_module modules/mod_proxy_http.so

<IfModule mod_proxy_http.c>
   ProxyRequests Off
   ProxyStatus On
   # When enabled, this option will pass the Host: line from the incoming request to the proxied host.
   ProxyPreserveHost On
   # Please note that the servlet path to the soap API has changed:
   <Location /webservices>
       # restrict access to the soap provisioning API
       Order Deny,Allow
       Deny from all
       Allow from 127.0.0.1
       # you might add more ip addresses / networks here
       # Allow from 192.168 10 172.16
   </Location>
 
   # The old path is kept for compatibility reasons
   <Location /servlet/axis2/services>
       Order Deny,Allow
       Deny from all
       Allow from 127.0.0.1
   </Location>
   
   # Enable the balancer manager mentioned in
   # http://oxpedia.org/wiki/index.php?title=AppSuite:Running_a_cluster#Updating_a_Cluster
   <IfModule mod_status.c>
     <Location /balancer-manager>
       SetHandler balancer-manager
       Order Deny,Allow
       Deny from all
       Allow from 127.0.0.1
     </Location>
   </IfModule>
   
   <Proxy balancer://oxcluster>
       Order deny,allow
       Allow from all
       # multiple server setups need to have the hostname inserted instead localhost
       BalancerMember http://localhost:8009 timeout=100 smax=0 ttl=60 retry=60 loadfactor=50 route=OX1
       # Enable and maybe add additional hosts running OX here
       # BalancerMember http://oxhost2:8009 timeout=100 smax=0 ttl=60 retry=60 loadfactor=50 route=OX2
      ProxySet stickysession=JSESSIONID|jsessionid scolonpathdelim=On
      SetEnv proxy-initial-not-pooled
      SetEnv proxy-sendchunked
   </Proxy>
   
   # The standalone documentconverter(s) within your setup (if installed)
   # Make sure to restrict access to backends only
   # See: http://httpd.apache.org/docs/$YOUR_VERSION/mod/mod_authz_host.html#allow for more infos
   #<Proxy balancer://oxcluster_docs>
   #    Order Deny,Allow
   #    Deny from all
   #    Allow from backend1IP
   #    BalancerMember http://converter_host:8009 timeout=100 smax=0 ttl=60 retry=60 loadfactor=50 keepalive=On route=OX3
   #    ProxySet stickysession=JSESSIONID|jsessionid scolonpathdelim=On
   #	   SetEnv proxy-initial-not-pooled
   #    SetEnv proxy-sendchunked
   #</Proxy>
   # Define another Proxy Container with different timeout for the sync clients. Microsoft recommends a minimum value of 15 minutes.
   # Setting the value lower than the one defined as com.openexchange.usm.eas.ping.max_heartbeat in eas.properties will lead to connection
   # timeouts for clients.  See http://support.microsoft.com/?kbid=905013 for additional information.
   #
   # NOTE for Apache versions < 2.4:
   # When using a single node system or using BalancerMembers that are assigned to other balancers please add a second hostname for that
   # BalancerMember's IP so Apache can treat it as additional BalancerMember with a different timeout.
   #
   # Example from /etc/hosts: 127.0.0.1	localhost localhost_sync
   #
   # Alternatively select one or more hosts of your cluster to be restricted to handle only eas/usm requests
   <Proxy balancer://eas_oxcluster>
      Order deny,allow
      Allow from all
      # multiple server setups need to have the hostname inserted instead localhost
      BalancerMember http://localhost_sync:8009 timeout=1900 smax=0 ttl=60 retry=60 loadfactor=50 route=OX1
      # Enable and maybe add additional hosts running OX here
      # BalancerMember http://oxhost2:8009 timeout=1800  smax=0 ttl=60 retry=60 loadfactor=50 route=OX2
      ProxySet stickysession=JSESSIONID|jsessionid scolonpathdelim=On
      SetEnv proxy-initial-not-pooled
      SetEnv proxy-sendchunked
   </Proxy>
   
   # When specifying additional mappings via the ProxyPass directive be aware that the first matching rule wins. Overlapping urls of
   # mappings have to be ordered from longest URL to shortest URL.
   # 
   # Example:
   #   ProxyPass /ajax      balancer://oxcluster_with_100s_timeout/ajax
   #   ProxyPass /ajax/test balancer://oxcluster_with_200s_timeout/ajax/test
   #
   # Requests to /ajax/test would have a timeout of 100s instead of 200s 
   #   
   # See:
   # - http://httpd.apache.org/docs/current/mod/mod_proxy.html#proxypass Ordering ProxyPass Directives
   # - http://httpd.apache.org/docs/current/mod/mod_proxy.html#workers Worker Sharing
   ProxyPass /ajax balancer://oxcluster/ajax
   ProxyPass /appsuite/api balancer://oxcluster/ajax
   ProxyPass /drive balancer://oxcluster/drive
   ProxyPass /infostore balancer://oxcluster/infostore
   ProxyPass /publications balancer://oxcluster/publications
   ProxyPass /realtime balancer://oxcluster/realtime
   ProxyPass /servlet balancer://oxcluster/servlet
   ProxyPass /webservices balancer://oxcluster/webservices

   #ProxyPass /documentconverterws balancer://oxcluster_docs/documentconverterws
 
   ProxyPass /usm-json balancer://eas_oxcluster/usm-json
   ProxyPass /Microsoft-Server-ActiveSync balancer://eas_oxcluster/Microsoft-Server-ActiveSync

</IfModule>

Viele Zeilen, aber man kann ja kopieren.

Jetzt manipulieren wir noch die Default Website Settings um das Open Xchange GUI anzuzeigen

nano /etc/httpd/conf.d/ox.conf

und dies der Inhalt der neuen Datei

<VirtualHost *:80>
       ServerAdmin webmaster@localhost

       DocumentRoot /var/www/html
       <Directory /var/www/html>
               Options Indexes FollowSymLinks MultiViews
               AllowOverride None
               Order allow,deny
               allow from all
               RedirectMatch ^/$ /appsuite/
       </Directory>

       <Directory /var/www/html/appsuite>
               Options None +SymLinksIfOwnerMatch
               AllowOverride Indexes FileInfo
       </Directory>
</VirtualHost>

Hoffentlich klappt das alles.

Das Installationsdokument möchte gerne, daß ich HTTPS konfiguriere, aber auch das spare ich mir für später, erstmal soll es laufen, dann wird abgesichert.

Deshalb werden wir jetzt den Webserver neu starten um die gemachten Änderungen auch wirksam werden zu lassen.

/etc/init.d/httpd restart

Um sicherzustellen, daß bei einem Neustart des Servers auch alle benötigten Diesnte mit hochkommen, tragen wir die jetzt in die entsprechenden Runlevels ein.

$ chkconfig --level 345 mysqld on
$ chkconfig --level 345 httpd on
$ chkconfig --level 345 open-xchange on

Kontext und User anlegen

Um wenigstens testen zu können sollten wir einen Admin und einen Testuser anlegen.

Wir kreieren also Kontext 1 als Default Context und den dazu gehörigen Administrator und dann noch einen Testuser in diesem Kontext, mit dem wir testen können. Das soll es dann gewesen sein.

/opt/open-xchange/sbin/createcontext -A oxadminmaster -P admin_master_password -c 1 \
-u oxadmin -d "Context Admin" -g Admin -s User -p secret -L defaultcontext \
-e oxadmin@example.com -q 1024 --access-combination-name=all

context 1 created, bedeutet es hat geklappt, nun noch der Testuser

/opt/open-xchange/sbin/createuser -c 1 -A oxadmin -P secret -u testuser \
-d "Test User" -g Test -s User -p secret -e testuser@example.com \
--imaplogin testuser --imapserver 127.0.0.1 --smtpserver 127.0.0.1

user 3 in context 1 created, heißt auch das hat funktioniert, nun folgt der ultimative Test, wir versuchen uns anzumelden.

ES HAT FUNKTIONIERT.

Subdomain über Auto-DNS auf konkrete IP-Adresse verweisen lassen

Um eine Subdomain direkt auf die IP-Adresse eines (anderen) Servers zeigen zu lassen kann man nicht die Standardfunktion im KIS verwenden:

20150209_163042_HE_KIS_Admin_WebServer_Domains_Subdomains

Nein, sondern man muß im Administrationsbereich für Domains die Stelle suchen, wo man die Auto DNS Einträge bearbeiten kann. Dort sucht man sich dann die Domain, zu der man eine Subdomain anlegen möchte und klickt hinter dieser auf Editieren.

20150209_214323_HE_KIS_Admin_Domainservices_Admin_AutoDNS_Domains bearbeiten_1

Dann bekommt man für die Domain alle möglichen eingetragen Records angezeigt und kann eine weitere Subdomain mit IP-Adresse hinzufügen. Nicht vergessen, wer mit IPv6 arbeitet auch an den A Record mit den vielen A’s (AAAA) zu denken.

20150209_161846-HE_KIS_Admin_Domainservices_Admin_AutoDNS_Domains bearbeiten

Nach einer Weile kann man dann über den Subdomain-Namen auf die gewünschte (eingetragene) IP zugreifen.

Nun muß man noch an die Reverse-Auflösung denken. Zumindest für die Virtual Root Server befindet sich diese Funktion bei HE im KIS unter dem Punkt IP-Netze.

20150209_215234_HE_KIS_Admin_IP Netze_Reverse Delegation_1

Hier kann man zur passenden IP, die passende Domain eintragen.

Selbiges gilt nun auch für IPv6

20150209_215524_HE_KIS_Admin_IP Netze_IPv6_1

Soweit so gut.

 

WordPress Blog umziehen/kopieren

Einleitung

Ich möchte eine 1 zu 1 Kopie des aktuellen (www.alt.de) Blogs auf einen anderen Blog (www.neu.de) haben.

Neuen Blog vorbereiten

Jetzt werden wir erst mal das Installationsverzeichnis anlegen, in welches wir später den Blog installieren wollen. Dazu gehen wir via FTP in das Verzeichnis “www“ des Servers und legen dort das gewünschte Unterverzeichnis an: “neu“

Dann lassen wir die Domain, welche wir verwenden wollen auf dieses Verzeichnis zeigen. Dazu rufen wir in der Serververwaltung (KIS bei HE) unter Administration den Link “Domains” auf und dort den Punkt “Domainzuordnungen editieren”. Dort tragen wir hinter den Domains, welche auf den Blog zeigen sollen, das entsprechende Verzeichnis ein. In unserem Falle also also hinter der Domain “neu.de“, das Verzeichnis “/www/neu“

Kopie vom alten Blog erzeugen

Nun machen wir uns daran eine Kopie des alten Blogs auf unseren lokalen Rechner zu ziehen. Ein WordPress Blog unterteilt sich im Wesentlichen in zwei Teile, zum einen all das was die Inhalte sind, die sind in der Datenbank abgelegt, dazu gehören aber auch Kategorien, Tags usw. Während alle Bilder, Thema Einstellungen und Plugins sich im Wesentlichen im Filesystem wiederfinden. Wir müssen also auf den neuen Blog die geänderten Dateien bringen und die Inhalte der Datenbank.

Kopie vom Filesystem

Los geht’s, wir kopieren das Verzeichnis “alt“ vom Server auf unsere lokale Platte. Einzige Datei, die wir später beachten müssen, weil sie eine Sonderrolle spielt ist die Datei wp-config.php, hier werden nämlich die Zugangsdaten zur Datenbank verwaltet und die passen ja nicht auf die neue, hier ist vergleichen angesagt, aber so lang ist die Datei nicht.

Kopie der Datenbank

Wir rufen phpMyAdmin des Alt-Systems und dort für die entsprechende Datenbank auf. (HE – KIS unter dem entsprechenden WebServer auf Datenbanken -> Datenbanken verwalten). Hinter der gewünschten Datenbank klicken wir auf den Knopf Verwalten. Dann gibt es oben einen Knopf für Exportieren, da klicken wir drauf. Alle Einstellungen belassen wir wie sie sind und klicken unten rechts auf OK. Dann geht das übliche Downloadfenster auf und wir speichern auf die lokale Platte ab.

Lokale Kopie an Zielsystem anpassen

Die lokal abgelegten Dateien müssen nun mit ein paar Handgriffen für das neue Zielsystem vorbereitet werden.

Im Filesystem

Im Filesystem betrifft dies die Datei wp-config.php hier soll man folgendes tun:

„In diesen lokal auf Deinem Rechner gespeicherten WordPress Dateien änderst Du die wp-config.php entsprechend der Zugangsdaten Deiner neuen Datenbank auf der neuen Domain ab. Wichtig sind hier die Einträge hinter: DB_NAME, DB_USER, DB_PASSWORD, DB_HOST.“

Import in den neuen leeren Blog

Wir laden alle Dateien, vom lokalen Rechner in das Filesystem des neuen Blogs hoch.

Wir rufen PHPMyAdmin für die neue Datenbank auf. (HE – KIS – Wir gehen im neuen Server auf Datenbanken -> Datenbanken verwalten und klicken hinter der neuen Datenbank auf Verwalten, dann sind wir auch dort) Also logischerweise muß man das Passwort des jeweiligen Datenbankadministrators, oder das des globalen Datenbank-Admins haben.

Dann klicken wir oben auf den Reiter importieren. Wir wählen die Datenbank.sql Datei auf dem lokalen Rechner, lassen alle Einstellungen wie sie sind und klicken auf OK.

Nun öffnen wir noch in PHPMyAdmin die wp-options Tabelle und passen die entsprechenden Daten für URL und Home usw. an.

Das wars!

Nacharbeiten im neuen Blog

Installation eines neuen leeren Blogs im KIS von HE

Ab ins KIS, dort gehen wir wie immer auf WebServer, dann auf Konfigurieren klicken, hinter dem Server auf dem der Blog laufen soll. Dann wählen wir Scripte -> Webanwendungen und suchen uns WordPress und klicken dahinter auf Konfigurieren.

Autor und Dateigröße läßt sich nicht eingeben/editieren, ist vorgegeben, aber die Domain kann ich auswählen, tue ich auch, in diesem Falle neu.de, bei Datenbank wähle ich Datenbank automatisch anlegen. (Hinweis: Ich mußte auch für dieses Paket erst im Menüpunkt Datenbanken, selbige aktivieren, dazu mußte ich dem globalen MySQL User ein Passwort vergeben. Außerdem habe ich gleich noch eine free-DB erstellt um dann im Script die Option des automatischen Datenbank Anlegens überhaupt zur Verfügung stehen zu haben. Diese Schritte sind im Changelog-Blog an anderer Stelle beschrieben – Datenbanken aktivieren und Datenbank anlegen)

Des Weiteren schalte ich ein, daß alles als Webserver-User installiert wird, macht später die wenigsten Sorgen .

Und dann auf den Knopf „Konfiguration starten“ geklickt.

Die ausführlichere Konfiguration der Installation folgt nun:

Host Europe - KIS - WordPress - InstallationMit dem Unterschied, daß die Datenbank db11134678-fmb heißt.

WordPress 5 Minuten Installation

Die Anleitung befindet sich offiziell hier:

WordPress 5 Minuten Installation

Ich habe sie in groben Zügen hierhin übernommen.

Bevor wir beginnen, prüfen, ob der Server auf dem WordPress laufen soll, auch alle Voraussetzungen dafür mitbringt.

  • PHP 5.2.4 oder höher
  • MySQL 5.0 oder höher
  • Das Apache Modul “mod_rewrite”

Siehe auch http://wpde.org/voraussetzungen/

Nun geht es los.

  • Wir laden die neueste Version von WordPress herunter (http://wpde.org/download/)
  • Diese entpacken wir in einem lokalen Verzeichnis um einige Anpassungen vornehmen zu können.
  • Diese Datei jetzt unter dem neuen Namen wp-config.php abspeichern.
  • Übertrage alle Dateien auf deinen Server.
  • Starte die Installation, indem du mit deinem Browser zu der Seite install.php surfst. Sie liegt relativ zu den Daten, die du hochgeladen hast, im wp-admin Ordner. Da wir den Pfad zu deiner Datei nicht wissen können, mußt du das folgende Beispiel entsprechend anpassen. Beispiel: http://www.deineDomain.de/der Ordner in dem WordPress liegt/wp-admin/install.php
  • Notiere dir unbedingt das Passwort, dass Dir während des Installationsprozesses gegeben wird.
  • Das Installationsskript wird dich am Ende auf eine Anmeldeseite schicken. Hier meldest du dich mit dem Benutzernamen “admin” und dem Passwort an, das du eben notieren solltest. Du kannst es in der Rubrik “Profile” (klick es mal an) sofort wieder ändern und durch ein neues Passwort ersetzen.
  • Das war`s schon! Wenn du möchtest, kannst du jetzt noch dein neues WordPress Weblog im Forum bekanntgeben.

 

WordPress Access Control installieren

Ich klicke auf Plugins. Ungeachtet der verfügbaren Aktualisierung für eines der drei standardmäßig installierten Plugins, klicke ich auf „Installieren“ ganz oben. Jetzt kann ich suchen. suche „WordPress Access Control“ und bekomme es auch als erstes angezeigt.

Klicke auf „Jetzt installieren“ Die bist sicher Abfrage beantworte ich mit JA. Er lädt runter entpackt und installiert. Ich drücke gleich noch auf aktivieren. Und es ist da und aktiviert, jetzt werde ich es noch schnell konfigurieren.

Dazu gehe ich auf „Einstellungen“ und klicke auf den Punkt „Members Only“. Ich mache als erstes den Blog für Members only, oben ankreuzen. Jetzt nur noch was ich ändere: Ich setze den Default Post State von „Public“ auf „Members Only“ auch den Default Page State setze ich auf „Members Only“

Dann klicke ich auf Save Changes, den Rest können wir später noch verfeinern.

Mailkonten für Admin und Webmaster einrichten

Also ab in der Administration zu Email, dort zu emailkonten und dort flugs das Konto wp111316334-admin eingerichtet und die Emailadresse admin@magath.net eingerichtet.

Schon bei der Anlage der nächsten Emailadresse, nämlich webmaster@magath.net gibt es wieder Schwierigkeiten, er behauptet plötzlich, daß magath.net nicht zu meinem Paket gehört. Irgednwie ist der Wurm drin.,