von Gert Redlich im Sept. 2016 - Die Überlegung hieß bei mir, wie lange (also wieviele Jahre) soll dieser Server "laufen" ? "Man nehme" also am besten die aktuelle Version von opensuse, das wäre Leap 42.1. Unter XEN, dem Virtualisierungs-Grundsystem von Linux, der sogenannten "DOM 0", gibt es den "Virtuellen Maschinen Manager" und dort gibt es den Menüpunkt "Neue Virtuelle Maschine anlegen" Eine solche virtuelle Maschine wird auch "VM" genannt.

Also nichts wie ran - auf einer 20 GB Platte auf einer von mehreren 20 GigaByte großen Partitionen des HP-Server RAID Sstems - (früher hatten wir nur 80 Megabyte!!) geht es ganz ordentlich zur Sache. - 4 CPUs (von 8 Kernen) und 1 GB Speicher (von den 32GB) reichen aus, es dauert für die Default- Installation mit allen voreingestellten Werten etwa 20 Minuten - und - die neu erstellte VM stürzt beim Neustart gnadenlos ab.

Also nochmal beginnen und mit etwas angepaßten Eigenschaften, wieder stürzt die VM ab. Nach dem 3. Versuch, jedesmal wurde 1GB Traffic verbraten, kam ich auf die Idee, von dem eingestellten hypermodernen "BTRFS"- Dateisystem auf das ältere ausgereifte "ext4" Dateisystem zu gehen und siehe da, ziemlich blöd, es funktionert auf Anhieb.

Die Suse Entwickler haben es "schon wieder nicht !!!!!" fertig gebracht (bzw. überprüft), in den aktuellen XEN Kernel der Version 42.1 jetzt den BTRFS Treiber einzubinden. So ein Schmarren. Wir schreiben Sept. 2016 und immer wieder diese zeitraubenden Kleingkeiten bei einer angeblich ausgreiften Version (die jetzt bereits fast 1 Jahr alt ist), und die mich jetzt wieder über 2 Stunden verplemperte Zeit samt Frust gekostet haben.

Schon wieder ein Schmarren. Damit kann ich nicht arbeiten. Bekanntermaßen wurde zum Beispiel das wichtige YAST in der opensuse Version 13.1 oder 13.2 völlig neu geschrieben und wurde gegenüber der opensuse Version 12.3 extrem lahm. Jetzt wurde nochmal eins drauf gelegt und es wurde noch langsamer. Als dann der Midnight Commander, der für mich 80% aller Jobs erledigt, auch noch stink lahm war, war die Version 42.1 fürs Erste "gegessen."

Zum Verständnis, ich öffne von der gleichen (Multiscreen) Arbeitsstation drei "putty" Sessions und zwar auf dem gleichen physikalischen Server auf drei verschiedenen Virtuellen Maschinen, - die eine mit opensuse 12.3, die zweite mit opensuse 13.2 und die neue VM mit opensuse 42.1. Es ist also wirklich ein echter seriöser Vergleich unter Äpfeln, kein Schummel. Was haben sie da gemacht ? An der Anzahl der CPUs liegt es nicht, die älteren VMs haben nur 2 Kerne zugeordnet bekommen und gehen ganz deutlich schneller.
.

Die Installation der opensuse 13.2 lief optisch und zeitlich ähnlich gut wie die 42.1, wobei ich jetzt von Anfang an dieses default BTRFS weggeklickt hatte. Ich installiere immer die kleinste textbasierte (default) opensuse Variante mit aktiviertem SSH und aktivierter Firewall ohne den ganzen Grafikrucksack. Es lief alles (je nach Internet Auslastung ca. 20 Minuten) super schnell durch. Als nächstes kommt die notwendige Grundkonfigurtaion für den Kommandozeilen SSH (putty) Zugang :
.

Es soll also ein eigener (Mail-) Server in einer eigenen virtuellen Maschine werden :
.

1. Umbau der Server-IP von DHCP auf statische IP per YAST.
2. Zuordnung der ETH0 Schnittstelle zur externen Zone
3. Umlegung des ssh Ports von 22 auf Port 60.xxx sowohl in /etc/ssh/sshd_config
   als auch in der SuSEfirewall - /etc/sysconfig/SuSEfirewall2
4. Abschaltung des root-Login von draußen in sshd.conf
5. reboot und Zugangstest mit putty - von jetzt an erst mit einem Hilfsbenutzer und dann anmelden als root-user mit "su -"
6. jetzt den Nameserver-Eintrag prüfen (bei mir hier "mail4.ipw.net")
   ping auf mail4.ipw.net - vom lokalen PC aus : bzw. ping 193.218.xxx.yyy
7. yast-online-update-config und -frontend (2 YAST Module) nachinstallieren

.

. . . . . müssen uns aber immer erst mit einem "Hilfsbenutzer" einloggen, dann erst als superuser anmelden.
.

• Ein Tip : es scheint, daß man zwischendurch doch öfter mal als "root" user ein "reboot" initieren soll. Manche Probleme tauchen dann nicht mehr auf.

.

Jetzt kommen die komfortablen Feinheiten, wenn das installierte opensuse Grundsystem funktioniert

>>>>>>>>>>>>>>>>>>     motd anpassen
joe /etc/motd  --  mein Beispiel :

===============================================
Du bist auf dem xen7-DL385-G5  - mail4   - xen7
=
8 x Opteron  mit 2,3GHz CPU mit 32 GB RAM
=
sowie 8 x 72 GB SCSI Platten - Okt 2015
===============================================
usw. diverse Infos anfügen
.
dann
>>>>>>>>>>>>>>>>>>     bash.bashrc.local estellen
joe /etc/bash.bashrc.local

alias d='ls -F'
alias cls='clear'
export LANG=de_DE.UTF-8
export LANGUAGE=de_DE:de
export LC_ALL=de_DE.UTF-8

dann
>>>>>>>>>>>>>>>>>>    profile.local erstellen
joe /etc/profile.local

export PS1="\[\e[0;32m\][xen7-mail4 - \u] \w \$ "
.

Es ist jetzt neu, daß die binären Log-Einträge (angeblich) gemeinsam in einer Logdatei jetzt mit journalctl -f angezeigt werden können, aber es ist alles mühsam. Die altbekannte Log-Datei "messages" (eine einzelne lesbare Textdatei) ist wesentlich komfortabler und muß daher wieder her :

Der Tip war: "Install "rsyslog" and "/var/log/messages" will come back."

Und jetzt diese blöde Spam-Anzeige im syslog Log bei messages abschalten:
in     /run/rsyslog/additional-log-sockets.conf das hier einbauen:

# von mir selbst eingefuegt sept 2016
:msg, contains, "Time has been changed" ~
.
sonst ist /var/log/messages im Sekundentakt gnadenlos zugemüllt und man sieht gar nichts mehr
.
und ntp (die Korrektur der Serverzeit) in der VM könnte wieder aktiv sein, muß aber nicht !!!, denn das XEN Grundsystem stellt allen VMs die korrekte Zeit zur Verfügung.
.

.

1. zypper install mc
2. zypper install htop
3. zypper install iftop
4. zypper install apache2
   dann a2enmod rewrite
5. zypper install php5
6. zypper install perl
7. zypper install openssl (das wird später nocheinmal empfohlen)

.
bis hierhin sind es jetzt 982 MB auf der Platte - das ist der Versuch 2 !!!!
.

Um von draußen zu prüfen, ob der gesamte Linux-Server (also diese "virtuelle Maschine") überhaupt "draußen" ereichbar ist, sollte der Apache Webserver funktionieren. Das spätere "webmin" Programm benötigt ihn sowieso. Doch dieses "webmin" erzeugt sich seine eigene völlig unabhängige Konfiguration. Also bauen wir uns - unabhängig von "webmin" - die ganz normale "vhost"- Konfiguration zusammen:
.

in /etc/apache2/listen.conf steht, daß auf Port 80 und 441 "gelauscht" wird:

Listen *:80 http
<IfDefine SSL>
    <IfDefine !NOSSL>
        <IfModule mod_ssl.c>
Listen *:443 https
        </IfModule>
    </IfDefine>
</IfDefine>

bei uns steht weiterhin in
/etc/apache2/vhosts.d/00-mail3-redirect-auf-ssl.conf
die gnadenlose Weiterleitung von Port 80 auf den https Port 443 - ohne Ausnahme

VirtualHost mail3.ipw.net:80>
        ServerName mail3.ipw.net
        Serveralias 193.218.16.83
        Redirect "/" "https://mail3.ipw.net/"
</VirtualHost>

und bei uns steht weiterhin in
/etc/apache2/vhosts.d/01-mail3.ipw.net_ssl.conf

<VirtualHost mail3.ipw.net:443>
ServerName mail3.ipw.net
Serveralias 193.218.xxx.yyy

DocumentRoot /srv/www/htdocs

<Directory "/srv/www/htdocs">
        AllowOverride all
        Require all Granted
        Options Indexes FollowSymLinks
</Directory>

# Alias /phpMyAdmin /srv/www/htdocs/phpMyAdmin
<Directory /srv/www/htdocs/phpMyAdmin>
   Options Indexes FollowSymLinks
   AllowOverride all
   Require all Granted
</Directory>

# Alias /squirrelmail /srv/www/htdocs/squirrelmail
<Directory /srv/www/htdocs/squirrelmail>
   Options Indexes FollowSymLinks
   AllowOverride all
   Require all Granted
</Directory>

ScriptAlias /cgi-bin/ "/srv/www/cgi-bin/"
<Directory "/srv/www/cgi-bin">
   AllowOverride all
   Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch -Includes
   Require all Granted
</Directory>

 <IfModule mod_userdir.c>
  UserDir public_html
  Include /etc/apache2/mod_userdir.conf
 </IfModule>
        HostnameLookups Off
        UseCanonicalName Off
        ServerSignature Off
        SSLEngine on
        SSLCertificateFile /etc/webmin/miniserv.pem
        SSLCertificateKeyFile /etc/webmin/miniserv.pem
        ErrorLog /var/log/apache2/mail4-web-error.log
        CustomLog /var/log/apache2/mail4-access.log combined
        LogLevel warn
</VirtualHost>
.

.

.

.