Sie sind hier : Homepage →  Linux (4) Ein Mailserver→  Das Betriebssystem

Aug. 2016 - Versuch 1 mit opensuse Leap SuSE Linux 42.1

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.

Ein Fehlgriff - SuSE Linux 42.1 ist stink langsam.

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.
.

Sept. 2016 - Versuch 2
also eine Version zurück und opensuse 13.2 installatieren . . .

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 :
.

Meine opensuse 13.2 Konfiguration :

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

.

und von jetzt an arbeite ich nur noch als root-user

. . . . . 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.

.

Das "Commandline"- Innenleben verbessern

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 \$ "
.

Die Fehler-Log-Funktion zur alten Methode zurück ändern !

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.
.

Die Grundprogramme zum Arbeiten installieren

.

  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 !!!!
.

Den Apache Webserver aktivieren

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:
.

Die Apache Konfig Dateien

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>
.

Den Server Eingang absichern mit .htaccess und .htpasswd


Dieser Prüf- oder Admin-Zugang zu diesem Mail-Server soll nicht für jederman offen sein, also wird er "abgedichtet". In der Datei /etc/apache2/.htpasswd werden die erlaubten Benutzer samt der verschlüsselten Passwörter eingetragen, weiter nichts.

In /srv/www/htdocs wird eine .htaccess Datei angelegt mit diesem Inhalt :

require valid-user
AuthType Basic
AuthName "<br>Das ist der Zugang zu unserem Mail4 Server"
AuthUserFile /etc/apache2/.htpasswd


Selbstverständlich ist auch das evtl. notwendige phpMyAdmin Verzeichnis 
 /srv/www/htdocs/phpMyAdmin abgesichert (wenn wir es brauchen sollten) sowie andere Verzeichnisse, die man auch direkt im Browser aufrufen könnte.
.

Unser Beispiel ist der mail3 oder mail4.ipw.net Mailserver :

Wenn wir dann solch eine Seite sehen, lebt der Server bereits.

.

Ein ganz wichtiger Tip :

Installieren Sie von jetzt an nur, was Sie wirklich brauchen. Von allen Testprogrammen und (unerfolgreichen) Versuchen bzw. Versuchsinstallationen bleibt so viel Müll übrig, daß Sie sich später tot suchen werden, wenn irgendwo die obligatorischen Fehler auftreten.

Weiterhin ist es logistisch problematisch, daß von den erforderlichen und installierten Programmen nur ein Teil der Konfigurationen im seit 20 Jahren typischen Linux-Basisverzeichnis /etc/ eingetragen wird. Manche Konfigurations-Files wohnen in /usr/ und /var/share/ und anderen Ecken, das ist wirklich dumm gelaufen.

.

.

Zurück zur Startseite ----- © 2009 / 2018 - Copyright by Dipl. Ing. Gert Redlich - Zum Telefon - - - - NEU : Zum Flohmarkt