30.1.2012 - eine Virtuelle Maschine mit Suse 12.1 erstellen
201 - die erste VM auf einem Proliant DL360 G4 installieren

Hier noch einmal zum Verständnis, das hier ist ein Sonderweg für die HP/Compaq Proliants DL360/DL385 mit speziellen teuren RAID5 Profi- Cachecontrollern (cciss Treiber). Der aktuelle Plattencontroller hat 512MB akkugepufferten Cache.

Inzwischen installiere ich immer "aus dem Netz", also vom Suse Repository-Server, da vermute ich die jeweils aktuellen Module, vor allem bei den Updates. Es gibt (gab) inzwischen auch bei der 12.1 zu viele Ecken und Haken, die doch hoffentlich irgendwann ausgemerzt werden (wurden).

Über die Namensvergabe der einzelnen VMs hatte ich ja schon meine neue Strategie aufgezeigt. Und so installiere ich zum Beispiel auf "/dev/cciss/c0d3" den Webserver Nr. 32, also unseren www32.ipw.net . Die VM bekommt bei mir also den Namen "c0d3-www32" plus die Größe der Platte. Das ist im XEN Manager deutlich übersichtlicher, wenn man später mal eine einzelne, also die richtige, VM runterfahren will oder muß.

Das hier ist in 12.1.10 repariert : (In die Befehlszeile der Bootoption muß(te) wieder noapic, acpi=off rein, sonst startet(e) (nicht nur) diese VM überhaupt nicht. Eine Suse 12.1 VM benötigt nach der "swap" Partition und vor der "root" Partition noch zwingend eine 400MB "/boot/" Partion.) Muß inziwschen auch nicht mehr sein.

201 - immer alle Updates ausführen, alle.

Sicher ist Suse nicht begeistert, wenn unnötiges Datenvolumen verplempert wird, doch die Fehlerhäufigkeit bei der 12.1 hatte sich deutlich gesteigert. Bis ich "gerafft" hatte, daß die Installation selbst der ersten virtuellen Maschine (also nicht der DOM 0) von der 4.7GB DVD sinnlos ist, hat es etwas gedauert.

Die Installaton wird auf jeden Fall per DHCP durchgeführt, dann merkt man gleich am Beginn, ob mindestens der Netzwerkzugang über eine der (bei uns 4) Schnittstellen funktioniert. Die Repository-URL ist im XEN Install- Manager bereits korrekt vorbelegt. Die Umstellung auf eine feste IP kommt erst ganz viel später nach der Installation, wenn wirklich alles läuft wie geschmiert. Alles Andere ist erfahrungsgemäß vergebene Mühe und oft umsonst (wenn man nochmal neu anfangen muß).
-

205 - Die Erfahrung - es kann ohne Grund schief gehen.

Es ist bei der Installation einer beliebigen VM unter Suse 12.1 nicht ungewöhnlich, daß es beim 4. oder 7. Male einfach nicht mehr geht, obwohl es vorher drei mal sauber geklappt hatte, und man nochmal vorn vorne anfangen muß - und das, obwohl ich das Rezept bzw. den Fahrplan hier auf der Webseite mehrfach aufgeschrieben hatte und immer wieder strikt nach (eigenem) und jeweils korrigiertem Rezept arbeite. Also nicht ägern, es ist eben so, zwar nicht gerade glücklich, sondern eher empirisch.
-

210 - Erfolg - die neue VM ist wirklich wieder gestartet.

Bislang kommt die IP immer noch per DHCP und wird mit "ifconfig" sicherheitshalber angezeigt. Mit "rcsshd start" wird der ssh-Dienst gestartet und jetzt kann man schon mit putty auf diese (neue) VM drauf. Bis zu diesem Punkt brauchten wir auf der Remotekonsole nicht das yast Config-Werkzeug. Würden wir es brauchen, ist der Befehl "term=vt100" essentiell wichtig, sonst sieht man auf dem ganzen Bildschirm nur Sonderzeichen.

Im putty Terminal (auf einem 19" LCD Monitor ist das besonders übersichtlich) rufen wir yast auf und installieren frei weg:
-

  1. midnight-commander, htop, iftop
  2. yast2-runlevel und evtl. weitere yast2 module
  3. apache2, php5, mysql (immer gleich alle 3 am Stück installieren)
  4. phpMyAdmin (einmal pro Server für alle virt. Hosts)
  5. imagemagick (einmal pro Server brauchen wir für Typo3)
  6. awstats-7.0-14.1.noarch (einmal pro Server für alle virt. Hosts)
  7. mailx (für scripte - ist bei 12.1 nicht mehr automatisch mit dabei ???)
  8. postfix deinstallieren - (geht nicht mehr - exim dagegen geht sofort)
  9. mit diversen direkten Links per zypper und yast folgende Programme
    fail2ban (yast2 -i fail2ban)
    jailkit-2.13-1.2.x86_64.rpm

-
aber !!! wir konfigurieren hier noch gar nichts. Wir warten ab, ob die einzelnen Installationen alle sauber durchlaufen.
-

230 - ich stelle die VM auf eine feste IP um

Jetzt aktiviere ich den sshd Dienst beginnend zum Systemstart und jetzt stelle ich die (virtuelle) Netzwerkkarte auf eine feste IP um, mit korrektem Gateway, DNS Server und Netzmaske sowie Firewall Zonenzuordnung und starte die VM neu von der Masterconsole der DOM0 aus mit "reboot". Putty hat sich zu dem Zeitpunkt ja schon längst (wegen der neuen IP) verabschiedet.

Von nun an arbeite ich auf dieser VM nicht mehr mit Hilfe der DOM0 Masterconsole, sondern nur noch direkt auf dieser VM mit putty. Nur noch im Notfall benutze ich iLO, die physikalische (Remote-) Konsole, weil es dort zu langsam geht.

250 - etwas mehr Komfort in 3 Dateien

Jetzt modifiziere ich in /etc/ jeweils (1) motd, (2) profile und (3) bash.bashrc.local. Das ist etwas für Profis mit SSH Rootzugang zum Server.

(1) In /etc/profile modifiziere ich den "promt" de Kommandozeile.

export PS1="\[\e[0;32m\][www14.ipw.net - \u] \w \$ "

(2) Dann habe ich /etc/motd mit einem Begrüßungstext gefüttert, damit man beim Login sofort sieht, auf welcher VM man gelandet ist.

Beispiel:
=======================================================
Du bist auf dem BlaBla-XENxx server - auf der virtuellen Maschine wwwyy.abc.de
=
Dieser Produktions-Server steht im Data Keller !!!
=
= Proliant DL385 mit 4 x 2,2 Opteron CPUs mit zz GB RAM und 6 x xxxGB SCSI
========================================================

(3) Und in bash.bashrc.local substituiere ich zwei uralte DOS Kommandos, "d" = Dir und "cls" mit:

alias d='ls -F'
alias cls='clear'

und fertig.

300 - Kontrolle - Apache vhost fähig machen und starten.

-

  1. in /etc/apache2 in listen die nunmehr statische IP Nummer eintragen,
  2. in /etc/apache2/vhosts.d die (neuen) confs editieren,
  3. Änderungen in httpd.conf, default-server.conf,
  4. der mod_rewrite Eintrag in /etc/sysconfig/apache2
  5. das Default - Web aufbereiten, bei uns ist das default Web zum Beispiel das "www32.rde.net" in /srv/www/htdocs", da muss ein index.html rein
  6. und natürlich in der Suse Firewall den Port 80 freigeben, sonst geht es nie nach draussen.

-

310 - Die Startseite des Default Webs (in /srv/www/htdocs/) dieses Servers wird angezeigt.

Das bedeutet, wir haben alles für den Apache richtig gemacht, fast alles jedenfalls. Die richtigen virtuellen Webs laufen aber später unter TYPO3 und haben daher weitere Forderungen an das System.

312 - Prüfverfahren für die "virthost" Installation

Alle unsere Web-Server werden für virtuelle Hosts eingerichtet. Das bei der Installation des Apache2 (bei Suse) eingerichtete "default" Web liegt immer in "/srv/www/htdocs" und wird bei uns mit dem eingetragenen Servernamen angesprochen, also "wwwXX.ipw.net", (zum Beispiel www31.ipw.net).

Das erste virtuelle Web liegt dagegen schon in unserer physikalischen Webumgebung (auf einem separaten Volumen), bei uns ist das "/vol2/www/" und heißt "wwwXX.ipw.net".

Wenn diese beiden Webs funktionieren, funktioniert prinzipiell die vhost Umgebung dieses Servers.
-

314 - Läuft der Apache nicht, liegen irgendwelche Altlasten vor.

Dann ist zum Beispiel in der php.ini (/etc/php5/apache2 - im Bereich "Paths and Directories") bei den php extensions bereits die mnogosearch Engine eingetragen, doch ein mysql Modul fehlt noch. Oft ist es die "mysqlclienet 18 - shared library". (Das kommt vor, wenn vorkompilierte Module von der mnogosearch Engine verwendet werden sollen - Stichwort Cloning von VMs.) Mehr steht auch bei den Suchmaschinen im TYPO3 Bereich.

-

316 - phpMyAdmin Verzeichnis durch .htaccess sichern

Da ja inzwischen phpMyAdmin installiert ist und auch schon einen root user bekommen hatte, sollte diese Ecke per .htaccess dicht gemacht werden.

Dazu muss man in "/etc/apache2/conf.d" die Datei "phpMyAdmin.conf" editieren (das ist nämlich der automatisch angelegte vhost Eintrag) und aus "AllowOverride NONE" jetzt "AllowOverride ALL" machen, sonst greift die .htaccess Datei überhaupt nicht.
-

320 - gelöst: "postfix" ist bereits durch "exim" ersetzt

In Suse 12.1 hat postfix Probleme. Habe postfix mit yast deinstalliert und damit wird automatisch der Mailserver "exim" vorgeschlagen und installiert. Auf einmal sind diese dummen Konfig-Probleme innerhalb von Sekunden beseitigt. (Das hatte jemand im opensuse Forum herausgefunden - Danke)
-

330 - in "/etc/php5/apache2" die php.ini verbessern

1. timezone : date.timezone = "Europe/Berlin"

Das hier war ganz großer Unsinn, trifft nur für Windows zu !! (also nicht machen !!!!!!! 2. opensssl aktivieren in der obigen php.ini : extension=php_openssl.dll)
.

350 - "mysql" Version 5.5.xx zurück auf "myisam" stellen !!!

Bislang ist die mysql Datenbank noch nicht initialisiert worden. Damit warten wir, bis wir in der /etc/my.cnf die Default Engine (nach unseren Vorgaben) gesetzt haben.

Seit mysql 5.5.0 ist jetzt "innodb" die Default Engine , vorher war "myisam" die Default Engine. ist, hat aber für uns (bei kleineren und mittleren Diese innodb Engine, auch wenn sie angeblich "moderner"Anwendungen) überhaupt keine Vorteile, eher mehr Nachteile. (Der Vergleich steht an anderen Stellen.)

In die "my.cnf" der version 5.5.x (und Nachfolgern) tragen wir folgende Zeile neu ein (denn früher musste man die innodb von Hand aktivieren - das war vorbereitet - jetzt brauchen wir aber wieder myisam als default engine) :
-

  • (1) in den [mysqld]-Abschnitt kommen jetzt 2 Zeilen neu hinzu und eine wird geändert:
    default-storage-engine=MyISAM

  • (2) Dann verlegen wir das Datenverzeichnis von mysql, egal welche Engine benutzt wird, auf eine eigene Partition oder eine eigene Festplatte (bzw. auf den zugehörigen symbolischen Link)
    datadir = /vol2/mysql

  • (3) Weiterhin wird der mysql Netzwerkzugang (von draußen) in my.cnf abgeschaltet. Wir sprechen unsere aktuellen mysql Datenbanken ausschließlich auf dem gleichen Server über "localhost" an.

  • (4) Jetzt erst starten wir die mysql Datenbank mit "rcmysql start" und lassen danach den Install-Script laufen: /usr/bin/mysql_secure_installation
    Wie das genau geht , steht hier.

-
Somit ist der mysql- "root"-User mit einem Passwort versehen, der "anonymus" sowie "test" sind weg und mit phpMyAdmin muss ich bereits auf die gesamte mysql Engine mit allen Datenbanken zugreifen können.
-

370 - phpMyAdmin absichern

Die mysql Datenbanken werden zur Zeit noch am Schnellsten mit phpMyAdmin gepflegt. Doch das müssen wir "dicht" machen mit einer lokalen ".htaccess" Datei.

Damit die auch wirkt (funktioniert), muß in der speziellen (Apache-) vhost Konfiguration auch der "override" durch eine lokale .htaccess erlaubt werden. Diese Konfig-Datei steht in "/etc/apache2/conf.d " und ist "phpMyAdmin.conf", eine ganz normale vhost Datei.
-

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