Betriebskonzept Website und zugehörige Applikationen

Transcrição

Patagon:
Betriebskonzept
Website und zugehörige Applikationen
Typ
Dokumentation
Version
Erstellt
0.2
17. Juli 2001 / Johannes Faassen, opus5 Dreieich
Kurzbeschreibung
Dieses Dokument beschreibt die Betriebsabläufe der Applikationen und
Server, die für die www.patagon.de Website benötigt werden. Abgedeckt
werden die Installation, Regelbetrieb und die Fehlerbehandlung bis hin
zur Wiederherstellung nach einem Totalausfall.
Inhaltsverzeichnis / Übersicht
1
Systemüberblick .....................................................3
1.1
Kurzbeschreibung der Einzelsysteme .............................3
1.2
Netzwerkplan und Kommunikationsbeziehungen .....................3
1.3
ContentSwitch und Failover-Konzept .............................4
2 Installation und Konfiguration ......................................6
2.1
Hardware und Basissystem .......................................6
2.1.1
Webserver ...................................................6
2.1.2
Messaging-Box ...............................................6
2.1.3
Datenbankserver .............................................7
2.1.4
Loghost und CMS .............................................8
2.1.5
Content-Switch ..............................................8
2.1.6
Firewall ...................................................11
2.2
Software und Applikationen ....................................12
2.2.1
Datenbank ..................................................12
2.2.2
Messaging-System ...........................................16
2.2.3
Webserver und Webapplikationen .............................23
2.2.4
Backend-Applikationen ......................................30
2.2.5
Reporting ..................................................30
2.2.6
CMS und QS .................................................32
2.3
Externe Komponenten ...........................................40
2.3.1
Monitoring .................................................40
opus5 interaktive medien gmbh
1
3
4
5
6
2.3.2
Backup .....................................................40
2.3.3
ITBS Datenfeed .............................................40
2.3.4
FMS ........................................................40
2.4
Securitypolicy ................................................41
Organisatorische Vorbereitung ......................................41
3.1
Service Team Systeme und Applikationen ........................41
3.1.1
Rollen .....................................................41
3.1.2
Service Kanäle .............................................41
3.1.3
Servicezeiten ..............................................41
3.2
Service Team Hosting ..........................................41
3.3
Service Center Patagon ........................................41
3.4
Notfallstab Patagon ...........................................41
3.5
Vorzubereitende Entscheidungen und Eskalationsszenarien .......41
3.5.1
Intrusion ..................................................41
3.5.2
Eingeschränkter Betrieb nach Totalausfall ..................41
Regelbetrieb .......................................................41
4.1
System ........................................................41
4.1.1
Monitoring .................................................41
4.2
Backup ........................................................49
4.2.1
Konzept ....................................................49
4.2.2
Wiederherstellung ..........................................49
4.3
ContentSwitch .................................................49
4.3.1
Konfigurationsfile und Standard-Doings .....................49
4.4
Anwendungen ...................................................50
4.4.1
Frontent-Anwendungen .......................................50
4.4.2
QS-System ..................................................53
4.4.3
Webapplikation Backend .....................................54
4.4.4
Reporting-Server ...........................................55
4.4.5
CMS ........................................................56
4.4.6
Messaging-System ...........................................59
4.4.7
Datenbank ..................................................60
4.4.8
Checklisten ................................................61
4.5
Batches .......................................................66
4.5.1
Batch-Jobs auf dem LogHost .................................66
4.5.2
Batch-Jobs auf dem Datenbankserver .........................67
4.6
Archivierung ..................................................67
4.7
Email Adressen ................................................67
4.8
Sonstige manuelle Prozesse ....................................67
Störungsbehebung und Service-Level .................................67
5.1
Fehlertypen ...................................................67
5.2
Fehlerbehebung ................................................67
5.3
Intrusion Incident ............................................67
5.4
Desaster Recovery .............................................67
Versionsübersicht ..................................................68
2
1
Systemüberblick
Das Serversystem des Webauftritts patagon.de besteht aus folgenden
Komponenten:
•
•
•
•
•
ContentSwitch
Liveservern (Webapplikation)
Loghost (CMS, Backend, Reporting, Webapplikation)
Datenbankserver
Message Box
1.1
Kurzbeschreibung der Einzelsysteme
Als Verteilungsmechanismus für eingehende Anfragen dient der
ContentSwitch. Er verteilt die Anfragen an die verfügbaren Webserver
weiter. Die Applikation auf den Webservern arbeiten eng mit der Datenbank
zusammen, die auf dem Datenbankserver installiert ist.
Auf dem Loghost ist das Content Mangagement System, das Reporting, die
Applikations Administration (Backend) und eine weitere Version des
Webauftritts (für den Quality of Service Check) installiert.
Für den Versand der Newsletter steht die Message Box bereit.
1.2
Netzwerkplan und Kommunikationsbeziehungen
Maschinen, IPs, Logins:
IP(extern)
IP(intern)
Name
Login
217.110.119.84
Funktion
ContentSwitch
217.110.119.85 192.168.150.101
santanderbkg-01 w101-101
www
217.110.119.86 192.168.150.102
www
217.110.119.87 192.168.150.103
www
217.110.119.90 192.168.110.2
mail
217.110.119.70 192.168.140.2
CMS(cms-apache,
jdk1.2.2,
tomcat)
cms
217.110.119.71 192.168.140.3
reporting
217.110.119.72 192.168.140.4
217.110.119.73 192.168.140.5
QS(
colt-apache,
jdk13,
resin)
backend
192.168.120.2
database
oracle
•
•
•
santanderbkg-01 bis santanderbkg-05 sind Linux-Rechner, RedHat 7.0,
Kernel 2.4.5.
santanderbkg-06 ist der DB-Server auf Solaris-Sun, Solaris 8.
Wechsel nach root auf allen Maschinen möglich.
3
Passworte: auf Anfrage bei opus Administration
Jeder Rechner in der Colt Infrastruktur ist mit 2 bzw. 3
Netzwerkinterfaces ausgestattet, von denen eins für den externen
Zugriff verwendet wird und das/die anderen für interne
Zwecke. Dementsprechend kann ein interner Rechner einen anderen sowohl
über das externe als auch das interne Interface adressieren.
Für die externen Adressen ist das Subnetz
217.110.119.64/27 (d.h. 217.110.119.64 - 217.110.119.95)
für die internen Netze die
• 192.168.110.x für die Messaging Box
• 192.168.120.x für die DB
• 192.168.130.x für die externe Seite der Webserver zum ContentSwitch
• 192.168.140.x für den Loghost und die Backendsysteme
• 192.168.150.x für die interne Seite der Webserver
In jedem Subnetz stehen Rechner mit gleichen Aufgaben bzw. gleichem
Schutzbedarf, so daß die Zugriffe innerhalb eines privaten Subnetzes
nicht gefiltert werden. Die Filter-Regeln für Zugriffe vom privaten
Subnetz zu privatem Subnetz werden uniform gehandhabt, d.h. es werden
nur Filterregeln auf Netz nicht aber auf Hostbasis formuliert.
Bei Zugriffen, die von extern kommen, werden durchaus Rechner in einem
privaten Subnetz unterschiedlich behandelt.
Weitere Subnetze bzw. externe Mitspieler sind:
ContentSwitch:
extern:
• 217.110.119.80 = Adresse des Contentswitches selbst
• 217.110.119.84 = www.patagon.de
• 217.110.119.89 = search.patagon.de
• 217.110.119.88 = www-test.patagon.de
• 217.110.119.90 = search-test.patagon.de
werden alle intern in das 192.168.130.x Netz gemappt.
weitere Rechner mit externer IP:
• 217.110.119.70 -> 192.168.140.2
• 217.110.119.71 -> 192.168.140.3
• 217.110.119.72 -> 192.168.140.4
• 217.110.119.73 -> 192.168.140.5
•
=loghost
=loghost
=loghost
=loghost
und
und
und
und
cms.patagon.de
reporting.patagon.de
qs.patagon.de
backend.patagon.de
217.110.119.74 -> 192.168.110.2 list.patagon.de
fremde Subnetze und IPs:
• 213.61.10.125 = mail.santander.de und primärer MX der patagon.de
• 212.20.130.17 = Externe Adresse des Patagon-Netzes
• 62.144.160.154, 195.170.104.82 = Externe Adressen des opus5-Netzes
10.49.129.41 = NameServer und Timerserver Colt
Das DNS wird von Colt verwaltet.
1.3
ContentSwitch und Failover-Konzept
Der ContentSwitch Cisco 11050
4
(http://www.cisco.com/univercd/cc/td/doc/product/webscale/css/) ist
zentral verantwortlich für Failover-Funktionalitäten und die
Skalierbarkeit der Patagon-Website.
Die Grundidee ist die, daß der ContentSwitch nach außen als
z.B. www.patagon.de erscheint und hinter der zugehörigen Adresse
eine ganze Farm von Servern verbirgt, auf die die eingehenden Requests
verteilt werden. Zur Zeit werden die Request auf zwei Gruppen von
Servern „live“ und „test“ verteilt.
Da eingehende Requests auf unterschiedliche Maschinen gemappt werden,
die keine Sessioninformationen austauschen, muß der ContentSwitch
ferner dafür sorgen, daß alle Requests mit Session-Bezug eines
Clients immer von derselben Maschine bedient werden. Diese Mimik wird
über die sogenannte „sticky option“ geregelt, die sich z.B. der
Client-IP oder eines Cookies bedient. Neben der Verteilung von
Requests, kann das verwendete Gerät auch Portmappings (z.B. für Inktomi)
und Servicetests (Keep-Alive Requests, siehe 2.1.5)durchführen, welche
sich auf der Ebene von Content-Rules definieren lassen.
Auf der Patagon-Website werden aus Sicht des ContentSwitchs die
Content-Typen
• statischer Content
• dynamischer Content
• SSL-Inhalte
• Suchmaschine
unterschieden. Die initiale Motivation dafür ist, daß z.B. die
dynamischen Contents von der Verfügbarkeit der Datenbank
abhängen, es aber nicht sinnvoll ist, auf einem Webserver keine
statischen Inhalte mehr auszuliefern, nur weil die Datenbank von
diesem temporär nicht erreichbar ist. Mit Ausnahme der Suchmaschine
werden alle Content-Typen auf jedem Webserver der Farm bedient. Für
jeden Content-Typen gibt es auf jedem der Webserver unter Port 999 ein
CGI mit dem der ContentSwitch prüft, ob ein Service auf einem
physikalischen Webserver verfügbar ist oder nicht. Das CGI führt die
notwendigen Tests durch, um zu entscheiden, ob ein Service z.B. die
Suchmaschine auf einer Maschine verfügbar ist.
Zusätzlich zu den Content-Typen gibt es zwei Gruppen von Servern, die
Test-Gruppe und die Live-Gruppe. Von jedem physikalischen
Webservern kann entschieden werden, in welchen der beiden Gruppen er
Services anbietet, wobei ein Rechner auch in beiden Gruppen sein
kann. Die Idee hinter diesem Vorgehen ist die, daß man mit der
Testgruppe durch Konfiguration gezielt einzelne Rechner oder
Rechnergruppen mit Requests beschicken, was sonst wegen der
intransparenten Loadbalancing-Strategie des ContentSwitches nicht
möglich wäre. Ferner kann man z.B. die Erweiterung der Serverfarm
testen bevor man die neuen Rechner in den Live-Betrieb integriert.
Welche Maschine welche Services serviert, wird durch ein
Konfigurationsfile gesteuert, daß durch „rsync“-Verteilung auf die
Maschinen verteilt wird und das Antwortverhalten des Service-CGIs
steuert.
Obwohl der ContentSwitch selbst Failover-Funktionalitäten für die
Webserver implementiert, ist er selber ein „single point of
failure“, der durch eine cold standby Lösung substituiert wird.
5
Beteiligte Komponenten
• Cisco ContentSwitch 11050
• virtueller Webserver auf Port 999 auf jedem physikalischen
Webserver, mit Service-CGI (siehe 2.2.3.1.1)
• zentrale Konfiguration mit Verteilfunktion auf dem „Loghost“ (siehe
2.2.3.1.1)
• Monitoring (SiteScope bei COLT)
2
Installation und Konfiguration
Dieses Kapitel beschreibt die einzelnen Systeme genauer und die Abläufe
die zum Aufsetzen der Systeme nötig sind.
2.1
Hardware und Basissystem
2.1.1 Webserver
Die Webserver stellen patagon.de im Netz bereit. Abhängig von den
Einstellungen im Content Switch, stehen bis zu drei Webserver zur
Verfügung.
Rechner:
• santanderbkg-01
• santanderbkg-02
• santanderbkg-03
Ausstattung:
• Hardware:
o 2 x Intel Pentium III 800 MHz
o Plattenplatz 17 GB
o Plattenaufteilung:
Filesystem 1k-blocks Mounted on
/dev/sda1
2047696
/
/dev/sda6
521748
/tmp
/dev/sda5
521748
/var
/dev/sda8
14104588
/data
o
Speicher 1 GB
• Betriebssystem:
o Linux
• Softwarepakete:
o Apache
o Resin 1.2.7
• eingerichtete Benutzer:
o w101-101, w102-102, w103-103 (je nach Rechner)
o cms
2.1.2 Messaging-Box
Die Messaging Box dient zur Versendung der Newsletter.
Rechner:
6
• santanderbkg-04
Ausstattung:
• Hardware:
/dev/sda1
2047696
/
/dev/sda6
521748
/tmp
/dev/sda5
521748
/var
/dev/sda8
14104588
/data
o
Speicher 1 GB
• Betriebssystem:
o Linux
• Softwarepakete:
o MySQL 3.23.38
o QMail 1.03
o Perl
o Apache
o Resin 1.2.7
o w002-002
o bmail
2.1.3 Datenbankserver
Auf diesem Rechner ist die Oracle-Datenbank installiert.
Rechner:
1)santanderbkg-06
Ausstattung:
• Hardware:
o Sun
Filesystem
1k-blocks
/dev/md/dsk/d10 3096423
/dev/md/dsk/d30 492872
/dev/md/dsk/d40 30262302
o
Mounted on
/
/var
/data
Speicher
• Betriebssystem:
o Solaris 8
• Softwarepakete:
o Oracle
7
o w006-006
o oracle
2.1.4 Loghost und CMS
Der Loghost ist das QS-System für die Applikation und beherbergt das
Content Management System.
Rechner:
2)santanderbkg-05
Ausstattung:
• Hardware:
/dev/sda1
2047696
/
/dev/sda6
521748
/tmp
/dev/sda5
521748
/var
/dev/sda8
67454832
/data
o Speicher 1,5 GB
• Betriebssystem:
o Linux
• Softwarepakete:
o CMS
§ MySQL
§ Tomcat
o Apache 1.3.17
o Resin 1.2.7
o w002-002
o cms
o o5oper
2.1.5 Content-Switch
Alle Informationen über die initiale Installation des ContentSwitch
liegen auf seiten der COLT TELECOM. An dieser Stelle wird nur die
aktuelle Konfigurationsdatei und die grundsätzliche Arbeitsweise
erklärt.
Server Gruppen
Derzeit gibt es zwei Servergruppen, die sich auf 3 physikalische
Webserver im im VLAN 192.168.130.x verteilen. Diese Gruppen sind die
live-Gruppe für den Produktionsbetrieb und die test-Gruppe für
Funktionstests einer speziellen Maschine oder Maschinengruppe.
Der ContentSwitch ist so konfiguriert, daß grundsätzlich alle
Maschinen in beiden Gruppen sind und alle Services (Contents)
anbieten. Die Entscheidung, ob eine
Maschine aktuell Services in einer Gruppe leistet, wird über den
Keep-Alive-Request auf Port 999 der jeweiligen Maschine
8
entschieden. Das dahinterliegende CGI prüft seinerseits die effektive
Verfügbarkeit eines Services und ob er laut Konfigurationsfile
(siehe Abschnitt 2.2.3.1.1) dort angeboten werden soll.
Das externe Mapping der Gruppen ist:
Live-Gruppe
Name
www.patagon.de
Adresse
217.110.119.85
search.patagon.de
217.110.119.89
Services
Website, statisch,
dynamisch, SSL
Inktomi Suchmaschine
Test-Gruppe
www-test.patagon.de
217.110.119.88
search-test.patagon.de
217.110.119.90
Website, statisch,
dynamisch, SSL
Inktomi Suchmaschine
Content-Rules
Die Contentrules definieren die einzelnen Services, die auf einer
Maschine angeboten werden. Die Unterscheidung der Content-Typen
erfolgt im ContentSwitch anhand von Adressen und URL-Patterns. Letztere
sind heuristisch gewachsen, da sich ein Servlet mit URI
„/servlet/KundeWerden/“ nicht offensichtlich von einem Verzeichnisaufruf
auf ein „index.html“ in „/servlet/KundeWerden/“ unterscheiden läßt. Da
die Trennung zwischen statischen und dynamischen Inhalten mit einer
Restunschärfe behaftet ist, werden auch für die statischen Inhalte
dieselben Vorsichtsmaßnahmen getroffen, wie sie für dynamische Inhalte
notwendig sind, z.B. die Stickyness.
Der Test, ob ein Content auf einer Maschine verfügbar ist oder nicht,
geschieht über das Service-CGI, das entweder ein HTTP 200 oder ein
HTTP 204 zurückgibt.
Statische Inhalte
Als statische Inhalte werden alle Inhalte bezeichnet, die vom
Webserver ohne Servlet-Engine via HTTP ausgeliefert werden können. Um
dies auch zu ermöglichen, werden sie unabhängig von den dynamischen
Inhalten als eigener Service angeboten.
Adresse Live/Test
URL-Pattern
Stickyness
Keep-Alive
Mapping
Intervall
217.110.119.84:80 /
217.110.119.88:80
extension List + domain
list
Source IP
siehe Konfigurationsfile
Timeout von 60 Minuten,
nur sticky wegen
potentieller Verwechslung
mit dynamischen Inhalten
SERVER:999/service/static[ HEAD
tst]
SERVER:80
5 sec.
Fehler erlaubt, danach
aus Service raus
9
Dynamische Inhalte
Als dynamisch wird alles das interpretiert, was auf die entsprechende
Adresse/Port kommt und nicht via URL-Pattern als statisch erkannt wird.
Adresse Live/Test
URL-Pattern
Stickyness
Keep-Alive
Mapping
Intervall
217.110.119.84:80 /
217.110.119.88:80
alles was nicht statisch ist
Source IP
Timeout von 60
Minuten
SERVER:999/service/dynamic[tst] HEAD
SERVER:80
5 sec.
2 Fehler erlaubt,
danach aus Service
raus
SSL Inhalte
Hinter den SSL Inhalten verbergen sich im Wesentlichen die
Formularapplikationen. Da der ContentSwitch die URIs der SSL Requests
nicht sieht, kann man die SSL-Inhalte nur pauschal zusammen wie
dynamische Inhalte behandeln.
Adresse Live/Test
URL-Pattern
Stickyness
Keep-Alive
Mapping
Intervall
217.110.119.84:443 /
217.110.119.88:443
alles was nicht statisch ist
Source IP & Timeout von 60
Minuten
SERVER:999/service/secure[tst] HEAD
SERVER:443
5 sec.
2 Fehler erlaubt,
danach aus Service
raus
Suchmaschine
Der Content-Typ Suchmaschine hat die Besonderheit, daß hier zusätzlich
neben der Verteilung auf verschiedene Server ein Portmapping von 80
auf 8765 stattfindet. Dies ist notwendig, damit die Suchmaschine nicht
auf einem privilegiertem Port laufen muß.
Ferner ist zu beachten, daß die Suchmaschine wegen der Lizenzkosten
nur auf 2 Maschinen (\#1 und \#2) läuft, was über die Service-CGIs
konfiguriert ist.
Adresse Live/Test
URL-Pattern
Stickyness
Keep-Alive
Mapping
Intervall
217.110.119.89:80 /
217.110.119.90:80
Mapping über Adresse/Port
Source IP
Timeout von 60
Minuten
SERVER:999/service/search[tst] HEAD
SERVER:8765
5 sec.
2 Fehler erlaubt,
danach aus Service
raus
10
Referenzen
• http://www.cisco.com/univercd/cc/td/doc/product/webscale/css/
• Service-CGI
2.1.6 Firewall
Der Zugriff auf die Rechner wird durch eine Firewall geschützt.
Die Rechner haben alle 2 oder 3 (Webserver) Netzwerkkarten mit
entsprechenden Nummern, ein Interface für externen Zugriff, eins für
internen Zugriff und eins für das Backup.
Alle Rechner sollen auf den primären Nameserver für die patagon.de
zugreifen können.
Die unten genannten Nummern dienen nur zur Identifikation der Maschine
nicht zur Definition der Routing/Filter-Regeln nach Interface bzw. IP.
Die von/nach-Service-Beziehung definiert auch keine Portkombinationen,
sondern effektive Services von/nach.
Firewall-Rules
Gruppen
Web
web-test
SDB
Opus5
admin
repqs
msgbox
relay
dns
db
217.110.119.84, 217.110.119.89
217.110.119.88, 217.110.119.90
212.20.130.17
62.144.160.154, 195.170.104.82
217.110.119.70, 217.110.119.73
217.110.119.71, 217.110.119.72
217.110.119.74
213.61.10.125, 213.61.10.124
10.49.129.41
192.168.120.2 ?? nicht klar über welches Interface
Rules
(dns ist noch unsauber, da routing zum 10.x über anderes Interface läuft)
Any
Any
Relay
opus5
SDB
192.168.110.x
192.168.110.x
192.168.110.x
192.168.110.x
192.168.120.x
→
→
→
→
→
→
→
→
→
→
192.168.120.x
192.168.120.x
192.168.140.x
192.168.140.x
192.168.140.x
192.168.140.x
192.168.140.x
→
→
→
→
→
→
→
web, web-test
repqs
msgbox
admin
admin
any
dns
relay
192.168.140.x
dns (geht real nicht über
120.x Interface)
Relay
192.168.140.x
Dns
relay
web, web-test
192.168.110.x
192.168.120.x
http, https
https
smtp
http, https, ssh
http, https, ssh
smtp
dns
smtp
ntp
dns
smtp
ntp
dns, ntp
smtp
http,https
ssh,http
ssh,oracle
11
192.168.140.x
192.168.150.x
192.168.150.x
192.168.150.x
192.168.150.x
192.168.150.x
2.2
→
→
→
→
→
→
192.168.150.x
dns
192.168.140.x
any
relay
192.168.120.x
ssh
dns
ntp
http,https
smtp
oracle
Software und Applikationen
In diesem Kapitel werden die Schritte zur Installation und Konfiguration
der einzelnen Softwarekomponenten aufgeführt.
2.2.1 Datenbank
2.2.1.1
Installationsvorbereitungen
2.2.1.1.1 Anpassen der Systemdatei /etc/system
Der Datei sind folgende Konfigurationseinstellungen hinzuzufügen :
* BEGIN stuff for Oracle
* PC, 08-jun-2000
* Values are minimum requirements unless stated otherwise
* Max size of shared memory segments
set shmsys:shminfo_shmmax=4294967295
* Min size of shared memory segments
set shmsys:shminfo_shmmin=1
* Max number of shared memory identifiers in system
set shmsys:shminfo_shmmni=100
* Max number of shared memory segments a user process can attach
set shmsys:shminfo_shmseg=10
* Max number of semaphore identifiers in system
set semsys:seminfo_semmni=100
* Max number of semaphores in a set
* recommended: 10+largest PROCESSES parameter of any Oracle DB on the system
set semsys:seminfo_semmsl=100
* Max number of semaphores in system
* Recommended: sum of all PROCESSES parameters + 10 for each DB + largest
* PROCESSES parameter
set semsys:seminfo_semmns=200
* Max number of operations per semop call
set semsys:seminfo_semopm=100
* Semaphore max value
set semsys:seminfo_semvmx=32767
* END Oracle stuff
Nach Speicherung der Datei musste das System neu gebootet werden, da
ansonsten die Einstellungen nicht übernommen wurden.
12
2.2.1.1.2
Anlegen der Gruppen und Benutzer
groupadd -g 2003 dba
groupadd -g 2004 oinstall
useradd -u 30004 -g 2004 -G 2003 -c 'Oracle DB User' -d /export/home/oracle -s
/usr/local/bin/bash -m oracle
cat >>/export/home/oracle/.profile <<__EOT__
umask 022
ORACLE_BASE=/opt/Oracle/app/oracle
ORACLE_HOME=\$ORACLE_BASE/product/8.1.6
ORA_NLS33=\$ORACLE_HOME/ocommon/nls/admin/data
NLS_LANG=GERMAN_GERMANY.WE8ISO8859P15
PATH=\$PATH:\$ORACLE_HOME/bin:/usr/ccs/bin
TNS_ADMIN=\$ORACLE_HOME/network/admin
export ORACLE_BASE ORACLE_HOME NLS_LANG ORA_NLS33 PATH
__EOT__
2.2.1.1.3 Anlegen der Datei srvcustom.rsp im Verzeichnis
/data/source/oracle
[General]
RESPONSEFILE_VERSION=1.7.0
[SESSION]
UNIX_GROUP_NAME="oinstall"
FROM_LOCATION="/data/source/oracle/stage/products.jar"
NEXT_SESSION_RESPONSE=
ORACLE_HOME="/export/Oracle/app/oracle/product/8.1.6"
TOPLEVEL_COMPONENT={"oracle.server","8.1.6.0.0"}
SHOW_SPLASH_SCREEN=false
SHOW_WELCOME_PAGE=false
SHOW_COMPONENT_LOCATIONS_PAGE=false
SHOW_CUSTOM_TREE_PAGE=true
SHOW_SUMMARY_PAGE=true
SHOW_INSTALL_PROGRESS_PAGE=true
SHOW_REQUIRED_CONFIG_TOOL_PAGE=true
SHOW_OPTIONAL_CONFIG_TOOL_PAGE=false
SHOW_RELEASE_NOTES=false
SHOW_ROOTSH_CONFIRMATION=true
SHOW_END_SESSION_PAGE=false
SHOW_EXIT_CONFIRMATION=false
NEXT_SESSION=false
NEXT_SESSION_ON_FAIL=false
#----------------------------------------------------------------------------# End of GENERAL SESSION section
#----------------------------------------------------------------------------[oracle.server_8.1.6.0.0]
COMPONENT_LANGUAGES={"de", "en"}
INSTALL_TYPE="Custom"
DEPENDENCY_LIST= {
"oracle.rdbms","8.1.6.0.0",
"oracle.networking","8.1.6.0.0",
"oracle.utilities","8.1.6.0.0",
"oracle.assistants","8.1.6.0.0",
"oracle.p2k.devtools","8.1.6.0.0",
"oracle.java","8.1.6.0.0",
"oracle.emprod","8.1.6.0.0",
"oracle.install","8.1.6.0.0",
"oracle.doc.unixdoc","8.1.6.0.0"
"oracle.options","8.1.6.0.0"
}
sl_userNodeList=
[oracle.options_8.1.6.0.0]
DEPENDENCY_LIST= {
"oracle.cartridges.ordts","8.1.6.0.0",
"oracle.cartridges.ordvir","8.1.6.0.0",
"oracle.cartridges.spatial","8.1.6.0.0",
"oracle.options.ops","8.1.6.0.0",
"oracle.options.ano","8.1.6.0.0",
"oracle.options.intermedia.imserver","8.1.6.0.0"
}
13
[oracle.rdbms_8.1.6.0.0]
DEPENDENCY_LIST= {
"oracle.assistants.dbca","8.1.6.0.0",
"oracle.rdbms.advrep","8.1.6.0.0",
"oracle.rdbms.lsm","8.1.6.0.0",
"oracle.emprod.oemagent","8.1.6.0.0",
"oracle.options.partitioning","8.1.6.0.0",
"oracle.rdbms.hs_odbc","8.1.6.0.0"
}
sl_dbaOperGroups={"dba","dba"}
[oracle.utilities_8.1.6.0.0]
DEPENDENCY_LIST= {
"oracle.utilities.util","8.1.6.0.0",
"oracle.rdbms.sqlplus","8.1.6.0.0"
}
[oracle.p2k.devtools_8.1.6.0.0]
DEPENDENCY_LIST= {
"oracle.rdbms.oci","8.1.6.0.0",
"oracle.p2k.ott","8.1.6.0.0"
}
[oracle.emprod_8.1.6.0.0]
DEPENDENCY_LIST= {
"oracle.sysman.client","2.1.0.0.0",
"oracle.emprod.oemagent","8.1.6.0.0"
}
[oracle.networking_8.1.6.0.0]
DEPENDENCY_LIST= {
"oracle.networking.netclt","8.1.6.0.0",
"oracle.networking.netsrv","8.1.6.0.0",
"oracle.networking.names","8.1.6.0.0",
"oracle.networking.cman","8.1.6.0.0"
}
[oracle.options.ano_8.1.6.0.0]
DEPENDENCY_LIST={}
[oracle.options.ano.sns_8.1.6.0.0]
sl_chosenAuthAdapters={}
[oracle.java_8.1.6.0.0]
DEPENDENCY_LIST= {
"oracle.java.jdbc","8.1.6.0.0",
"oracle.java.javavm.javatools","8.1.6.0.0",
"oracle.java.sqlj","8.1.6.0.0"
}
[oracle.assistants_8.1.6.0.0]
DEPENDENCY_LIST= {
"oracle.assistants.dbca","8.1.6.0.0"
}
[oracle.assistants.dbma_8.1.6.0.0]
OPTIONAL_CONFIG_TOOLS={}
sl_migrateSIDDialogReturn={"<None>", "<None>"}
[oracle.sysman.oms_2.1.0.0.0]
DEPENDENCY_LIST=
ServerRepository_index=0
EMCARspFileLocation=
[oracle.sysman.client_2.1.0.0.0]
DEPENDENCY_LIST= {
"oracle.sysman.console","2.1.0.0.0",
"oracle.sysman.dbapp","2.1.0.0.0"
}
[oracle.sysman.dbapp_2.1.0.0.0]
DEPENDENCY_LIST= {
"oracle.sysman.dbapp.schema", "2.1.0.0.0",
"oracle.sysman.dbapp.storage", "2.1.0.0.0",
"oracle.sysman.dbapp.security", "2.1.0.0.0",
"oracle.sysman.dbapp.instance", "2.1.0.0.0",
"oracle.sysman.dbapp.sqlplusworksheet","2.1.0.0.0",
"oracle.sysman.database","2.1.0.0.0"
}
[oracle.assistants.dbca_8.1.6.0.0]
14
s_seedLocation=
s_responseFileName=
s_globalDBName=PATAGON.opus5.de
b_createStarterDBReturn=true
s_mountPoint=/data/Oracle/Daten0
s_dbSid=PATAGON
[oracle.sysman.dbappext_2.1.0.0.0]
DEPENDENCY_LIST= {
"oracle.apps.oam.client","2.1",
"prv","2.1.0.0.0",
"oracle.sysman.wf.client","2.1.0.0.0",
"dam","1.0",
"Replication_Manager","2.1",
"analyzer","2.1.0.0.0",
"occm","2.1.0.0.0",
"oracle.security.admin.enterprise","2.0",
"oracle.oas.mngr.oem","2.1.0.0",
"oracle.odm","2.0.6.0.0"
}
[oracle.java.jdbc_8.1.6.0.0]
DEPENDENCY_LIST= {
"oracle.java.jdbc.thin12","8.1.6.0.0"
}
[oracle.networking.netca_8.1.6.0.0]
s_responseFileName=<Value Unspecified>
[oracle.networking.protocol_supp_8.1.6.0.0]
sl_protocolSelectionDialogReturn={}
[oracle.install_8.1.6.0.0]
DEPENDENCY_LIST= {
"oracle.swd.oui", "1.7.0.12.0"
}
[oracle.sysman.website_2.1.0.0.0]
DEPENDENCY_LIST={ "oracle.oas.lstnr","4.0.8.0.0" }
[oracle.sysman.quicktour_2.1.0.0.0]
DEPENDENCY_LIST= {
"oracle.sysman.dbapp.qt","2.1.0.0.0",
"oracle.sysman.em.qt","2.1.0.0.0"
}
[oracle.swd.oui_1.7.0.15.1]
PROD_HOME=“/export/Oracle/apps/oui“
[oracle.swd.jre_1.1.7]
PROD_HOME="/export/Oracle/app/jre"
2.2.1.1.4 Installation
Um den Universal Installer von Oracle starten zu können musste zunächst
das X11- Forwarding aktiviert werden.
Außerdem muss dem User oracle ein Passwort gegeben werden, damit er sich
am System anmelden kann.
Einloggen auf dem Login-Host :
ssh [email protected] –X –2
Einloggen auf dem DB-Server :
15
ssh [email protected] –X –2
su
mkdir –p /export/Oracle/app/oracle
chown oracle:oinstall /export/Oracle/app/oracle
su - oracle
export DISPLAY=levant.opus5.de:0.0
cd /data/source/oracle
./runInstaller –responseFile svrcustom.rsp
2.2.1.1.5 Erstellung der Start-/Stopskripte
Anlegen der Datei /etc/init.d/dbora und Einbindung in die Runlevel 0 und
2:
#!/bin/sh
#
# LOCAL CHANGES:
# 99-11-01 pd start-up listener `listener'
#
# Set ORA_HOME to be equivalent to the ORACLE_HOME
# from which you wish to execute dbstart and
# dbshut
# set ORA_OWNER to the user id of the owner of the
# Oracle database in ORA_HOME
ORA_HOME=/opt/Oracle/app/oracle/product/8.1.6
ORA_OWNER=oracle
LSNRCTL=$ORA_HOME/bin/lsnrctl
if [ ! -f $ORA_HOME/bin/dbstart ]
then
echo "Oracle startup: cannot start"
exit
fi
if [ ! -x ${LSNRCTL} ]
then
echo "Oracle startup: cannot start listener"
LSNRCTL=
fi
case "$1" in
'start')
# Start the Oracle databases:
# The following command assumes that the oracle login will not prompt the
# user for any values
su - $ORA_OWNER -c ". /export/home/oracle/.profile; $ORA_HOME/bin/dbstart &"
[ "$LSNRCTL" ] && su - $ORA_OWNER -c "$LSNRCTL start listener"
[ "$LSNRCTL" ] && su - $ORA_OWNER -c "$LSNRCTL dbsnmp_start"
;;
'stop')
# Stop the Oracle databases:
# The following command assumes that the oracle login will not prompt the
# user for any values
su - $ORA_OWNER -c ". /export/home/oracle/.profile; $ORA_HOME/bin/dbshut &"
[ "$LSNRCTL" ] && su - $ORA_OWNER -c "$LSNRCTL dbsnmp_stop"
[ "$LSNRCTL" ] && su - $ORA_OWNER -c "$LSNRCTL stop listener"
;;
esac
2.2.1.1.6 Datenbank erstellen
Die Datenbank wurde über die grafische Benutzeroberfläche erzeugt.
Weiteres Material von Christian
2.2.2 Messaging-System
2.2.2.1 Vorraussetzungen
Für den Betrieb der Messaging Box müssen folgenden Komponenten
installiert werden:
• Webserver
• Perl
16
• MySQL-Datenbank
• QMail
2.2.2.2 Installation der einzelnen Komponenten
Zusätzlich zur vorhanden Installation bei Colt wurden folgende RPM’ s
installiert, da diese noch nicht vorhanden waren :
• kernel-headers-2.4.0-0.26.i386.rpm
• glibc-devel-2.1.92-14.i386.rpm
• cpp-2.96-54.i386.rpm
• binutils-2.10.0.18-1.i386.rpm
• gcc-2.96-54.i386.rpm
• make-3.79.1-5.i386.rpm
Folgende
• rpm
• rpm
• rpm
• rpm
• rpm
Pakete sind zu löschen :
-e perl-5.6.0-COLT1
-e mysql-3.23.32-COLT1
-e DBI-1.14-COLT1
-e Msql-Mysql-modules-1.2215-COLT1
-e Data-ShowTable-3.3-COLT1
Dann Original RedHat RPMS installieren :
• rpm -ivh compat-glibc-6.2-2.1.3.2.i386.rpm
• Die Datei /etc/ld.conf angepasst und ldconfig ausgeführt.
• rpm -ivh perl-5.6.0-9.i386.rpm
• Installation mit rpm -ivh mysql* von folgenden Paketen
o mysql-3.23.32-1.7.i386.rpm
o mysql-devel-3.23.32-1.7.i386.rpm
o mysql-server-3.23.32-1.7.i386.rpm
o mysqlclient9-3.23.22-3.i386.rpm
• rpm -ivh perl-DBI-1.14-8.i386.rpm
• rpm -ivh perl-Msql-Mysql-modules-1.2215-1.i386.rpm
è von www.haoli.org/rpm/redhat-7.x-i386-1.html
(hier gibt es noch mehr nützliche RPM's für RedHat7.x)
2.2.2.2.1 Webserver Apache
Als Webserver kommt ein Apache-Webserver in der Version 1.3.19 zum
Einsatz. Die Sourcen stehen unter
http://httpd.apache.org/dist/httpd/apache_1.3.19.tar.gz
zum Download zur Verfügung.
Installation und Konfiguration
a) Entpacken des Paketes :
tar xvzf apache_1.3.19.tar.gz
b) Übersetzen des Webservers :
17
/.configure –prefix=/export/www/apache-1.3.19
make
make install
c) Anpassen des Documentroot in der http.conf auf /www/docs
d) Einbindung der Startskripts zum automatischen Start/Stop des
Webservers:
ln –s /export/www/apache-1.3.19/bin/apachectl /sbin/init.d/rc2.d/S20apache
ln –s /export/www/apache-1.3.19/bin/apachectl /sbin/init.d/rc2.d/K20apache
e) Starten des Webservers:
/export/www/apache-1.3.19/bin/apachectl restart
2.2.2.2.2 MTA qmail
Aufgrund der im Workingpackage WP 203-3 aufgeführten Gründe kommt als
MTA qmail in der Version 1.03 zum Einsatz.
2.2.2.2.2.1 Sourcen
Die Sourcen zu qmail können unter
http://cr.yp.to/software/qmail-1.03.tar.gz
heruntergeladen werden.
Zusätzlich sollten noch die Zusatzmodule ucspi-tcp
ftp://cr.yp.to/ucspi-tcp/ucspi-tcp-0.88.tar.gz
und die Daemontools
ftp://cr.yp.to/daemontools/daemontools-0.70.tar.gz heruntergeladen
werden. Sie dienen der Optimierung von qmail.
2.2.2.2.2.2 Installation
Entpacken der Distribution
mkdir -p /usr/local/src/qmail
mv qmail-1.03.tar.gz /usr/local/src/qmail
su –
cd /usr/local/src/qmail
gunzip qmail-1.03.tar.gz
tar xvf qmail-1.03.tar
gunzip ucspi-tcp-0.88.tar.gz
tar xvf ucspi-tcp-0.88.tar
gunzip daemontools-0.70.tar.gz
tar xvf daemontools-0.70.tar
Erstellen der Benutzer und Gruppen
mkdir /data/qmail
groupadd nofiles
useradd alias -g nofiles -d /data/qmail/alias -s /nonexistent
useradd qmaild -g nofiles -d /data/qmail -s /nonexistent
useradd qmaill -g nofiles -d /data/qmail -s /nonexistent
useradd qmailp -g nofiles -d /data/qmail -s /nonexistent
groupadd qmail
useradd qmailq -g qmail -d /data/qmail -s /nonexistent
useradd qmailr -g qmail -d /data/qmail -s /nonexistent
useradd qmails -g qmail -d /data/qmail -s /nonexistent
Anzupassenden Dateien
• in der Datei /usr/local/src/qmail/qmail-1.03/conf-qmail ist der
Installationspfad für qmail anzupassen
18
• in der
• in den
o
o
o
o
Datei /data/qmail/rc ist der Pfad anzupassen
Dateien:
/data/qmail/supervise/qmail-send/run,
/data/qmail/supervise/qmail-send/log/run,
/data/qmail/supervise/qmail-smtpd/run
/data/qmail/supervise/qmail-smtpd/log/run
ist der Pfad anzupassen.
Kompilierung der Sourcen
a) qmail
make setup check
./config für korrekt konfigurierte DNS-Server
oder
./config-fast the.full.hostname falls config den DNS-Server nicht finden kann.
b) ucspi-tcp
cd /usr/local/src/qmail/ucspi-tcp-0.88
make
make setup check
c) Daemontools
cd /usr/local/src/qmail/daemontools-0.70
make
make setup check
2.2.2.2.2.3 Konfiguration
Startskripts
Zum Starten von qmail wird das Startskript /data/qmail/rc benötigt.
Dieses hart
folgenden Aufbau :
#!/bin/sh
# Using splogger to send the log through syslog.
# Using qmail-local to deliver messages to ~/Mailbox by default.
exec env - PATH="/data/qmail/bin:$PATH" \
qmail-start './Maildir/'
Um qmail beim Starten und Herunterfahren des Systems zu starten bzw. zu
beenden wird noch ein System Startup-Skript benötigt. Dies kann unter der
Adresse http://web.infoave.net/~dsill/qmail-script-dt61.exe
heruntergeladen werden und wird im Verzeichnis /sbin/init.d/qmail
gespeichert. Die Einbindung erfolgt über:
ln
ln
ln
ln
ln
ln
ln
–s
–s
–s
–s
–s
–s
–s
/sbin/init.d/qmail
/sbin/init.d/qmail
/sbin/init.d/qmail
/sbin/init.d/qmail
/sbin/init.d/qmail
/sbin/init.d/qmail
/sbin/init.d/qmail
/sbin/init.d/rc0.d/K30qmail
/sbin/init.d/rc2.d/S80qmail
Supervise Skripts
a) Erstellen der Supervise-Verzeichnisse und Files für den qmailService
19
mkdir
mkdir
chmod
chmod
-p
-p
+t
+t
/data/qmail/supervise/qmail-send/log
/data/qmail/supervise/qmail-smtpd/log
/data/qmail/supervise/qmail-send
/data/qmail/supervise/qmail-smtpd
b) Erstelle das /data/qmail/supervise/qmail-send/run File:
#!/bin/sh
exec /data/qmail/rc
c) Erstelle das /data/qmail/supervise/qmail-send/log/run File:
#!/bin/sh
exec /usr/local/bin/setuidgid qmaill /usr/local/bin/multilog t /data/logs/qmail
d) Erstelle das /data/qmail/supervise/qmail-smtpd/run File:
#!/bin/sh
QMAILDUID=`id -u qmaild`
NOFILESGID=`id -g qmaild`
MAXSMTPD=`cat /data/qmail/control/concurrencyincoming`
exec /usr/local/bin/softlimit -m 2000000 \
/usr/local/bin/tcpserver -v -p -x /etc/tcp.smtp.cdb -c "$MAXSMTPD" \
-u "$QMAILDUID" -g "$NOFILESGID" 0 smtp /data/qmail/bin/qmail-smtpd 2>&1
e) Erstelle das concurrencyincoming Kontrollfile:
echo 20 > /data/qmail/control/concurrencyincoming
chmod 644 /data/qmail/control/concurrencyincoming
f) Erstelle das /data/qmail/supervise/qmail-smtpd/log/run File:
#!/bin/sh
exec /usr/local/bin/setuidgid qmaill /usr/local/bin/multilog t /data/logs/qmail/smtpd
g) Mache die run-Files ausführbar :
chmod
chmod
chmod
chmod
755
755
755
755
/data/qmail/supervise/qmail-send/run
/data/qmail/supervise/qmail-send/log/run
/data/qmail/supervise/qmail-smtpd/run
/data/qmail/supervise/qmail-smtpd/log/run
h) Erstelle die Logverzeichnisse:
mkdir -p /data/logs/qmail/smtpd
chown qmaill /data/logs/qmail /data/logs/qmail/smtpd
Erstellen der Systemaliase
echo postmaster.email > /data/qmail/alias/.qmail-root
echo postmaster.email > /data/qmail/alias/.qmail-postmaster
ln -s .qmail-postmaster /data/qmail/alias/.qmail-mailer-daemon
chmod 644 /data/qmail/alias/.qmail-root /data/qmail/alias/.qmail-postmaster
Erstellen der Benutzer und der Maildir-Verzeichnisse
Zum Erstellen eines neuen Benutzers muss zunächst die Datei
/data/qmail/users/assign erstellt bzw. angepasst werden. Diese Datei hat
folgendes Format :
=address:user:uid:gid:directory:dash:extension:
+prefix:user:uid:gid:directory:dash:prepend:
. ? Dieser Punkt ist wichtig !!!
Sind die neuen User in der Datei eingetragen ist das Programm
/data/qmail/bin/qmail-newu aufzurufen, welches die Benutzerdatenbank
20
erstellt. Die Mailboxverzeichnisse werden dann wie folgt eingerichtet :
/data/qmail/bin/maildirmake /export/home/username/Maildir
ln -s . /export/home/username/Mailbox
chown -R user-id:nofiles /export/maildirs/username/Maildir
Starten von qmail
/sbin/init.d/qmail restart
2.2.2.2.2.4 Dokumentation
Dokumentationen zum qmail-Projekt finden sich in großer Menge unter
http://www.qmail.org. Besonders empfehlenswert ist dort die Dokumentation
Life with qmail von Dave Sill.
2.2.2.2.3 Datenbank MySQL
Als Datenbank für die Speicherung der Daten von gebouncten e-mails wird
eine MySQL Datenbank in der Version 3.23.38 eingesetzt.
2.2.2.2.3.1 Sourcen
Die Sourcen liegen unter
http://www.mysql.com/Downloads/MySQL-3.23/mysql-3.23.38-pc-linux-gnui686.tar.gz
zum Download bereit.
groupadd mysql
useradd -g mysql mysql
cd /usr/local
gunzip < /usr/local/mysql-3.23.38-pc-linux-gnu-i686.tar.gz | tar xvf –
ln –s mysql-3.23.38-pc-linux-gnu-i686 mysql
cd mysql
scripts/mysql_install_db
chown -R root /usr/local/mysql
chown -R mysql /usr/local/mysql/data
chgrp -R mysql /usr/local/mysql
chown -R root /usr/local/mysql/bin/
Anpassung der Pfade in /usr/local/mysql/support-files/mysql.server
Einbindung der Start-/Stopskripts
Um MySQL nicht als User root laufen zu lassen, muss ein switch
auf den User mysql gemacht werden. Dies erledigt folgendes kleines ShellSkript :
#!/bin/sh
su –m –mysql –c '/usr/local/mysql/support-files/mysql.server start’
Dieses wird nun in das Startprozedere eingebunden :
ln –s /usr/local/mysql/support-files/start-mysql /sbin/init.d/rc2.d/S20mysql
ln –s /usr/local/mysql/support-files/mysql.server /sbin/init.d/rc2.d/K20mysql
Kopieren von /usr/local/mysql/support-files/my-large.conf nach
/etc/my.conf
Starten des Datenbankservers
21
/usr/local/mysql/support-files/mysql.server start|stop
2.2.2.2.3.3 Konfiguration
Für die Speicherung der „Bouncedaten“ wird eine Datenbank mailing
angelegt. In dieser Datenbank wird eine Tabelle BOUNCERS angelegt, in
welcher die aus den gebouncten Mail extrahierten Daten gespeichert
werden. Außerdem wird zu Testzwecken eine weitere Tabelle mit dem Namen
INVALID_EMAIL_ADRESSES angelegt, in welcher die eMail-Adressen gespeichert werden, welche von der Checkroutine als ungültig erkannt wurden.
create database mailing ;
create table BOUNCERS (
email char(255) not null,
sender char(255),
firstbounceDate Date,
firstbounceTime Time,
lastbounceDate Date,
lastbounceTime Time,
numberofbounces Integer,
lasterrorcode char(3), PRIMARY KEY(email)
);
create table INVALID_EMAIL_ADRESSES (
email char(255) not null,
PRIMARY KEY(email)
);
Folgende Daten werden in der Tabelle BOUNCERS gespeichert :
• email
- Return-Path der gebouncten eMail
• sender
- Absender der eMail
• firstbounceDate - Datum an dem zum ersten mal gebounct wurde
• firstbounceTime - Zeitpunkt an dem zum ersten mal gebounct wurde
• lastbounceDate - Datum an dem das letzte mal gebounct wurde
• lastbounceTime - Zeitpunkt an dem das letzte mal gebounct wurde
• numberofbounces - Anzahl der gebouncten eMails
• lasterrorcode
- Errorcode der letzten gebouncten eMail (noch nicht
implementiert)
Der Zugriff auf die Datenbank ist zur Zeit auf Localhost und den Benutzer
root beschränkt.
Für den Zugang zur MySQL DB und die Abwicklung des Bouncemanagements
wurde ein neuer Benutzer bmail angelegt. Der Benutzer hat in der
Datenbank nur Rechte auf die Datenbank mailing. Sein Homeverzeichnis
liegt unter /data/home/bmail.
Der Benutzer bmail wurde außerdem als User in qmail/users/assign angelegt
und mit /data/qmail/bin/qmail-newu in die cdb-Datei übernommen:
=bmail:bmail:508:102:/home/bmail:::
+bmail-:bmail:508:102:/home/bmail:-::
=w002-002:w002-002:102:102:/home/w002-002:::
+w002-002-:w002-002:102:102:/home/w002-002:-::
.
Im Homeverzeichnis des Users wurde die Datei .qmail wie folgt angelegt :
22
| condredirect [email protected]
/data/HBounceMsg/bounced_msg.pl
./Maildir/
Daraufhin wurde im Homeverzeichnis noch das Mailverzeichnis erzeugt :
/var/qmail/bin/maildirmake /export/home/bmail/Maildir
ln -s . /export/home/bmail/Mailbox
chown -R 508:nofiles /export/maildirs/bmail/Maildir
2.2.2.2.4
Perl
Als Grundlage für die Perl-Installation wird das Basispaket für Perl
welches in der Suse Distribution enthalten ist benutzt.
Die Installation erfolgt über die Installationsoberfläche von Suse (YaST)
oder manuell mit Hilfe des RPM-Paketes.
2.2.2.2.4.2 Zusätzlich benötigte Module
Zusätzlich zum Basispaket wurde die Perl-Unterstützung für MySQL
installiert. Das Paket hat den Namen mysqlperl. Des weiteren benötigt
dieses Modul die Pakete MySQL - Development header files and Libraries
(mysqldev) und MySQL – Shared Libraries (mysqllib).
2.2.3 Webserver und Webapplikationen
Auf den Webservern müssen folgende Komponenten installiert werden:
• Apache
• JDK
• Resin
2.2.3.1 Apache
In der Konfigurationsdatei /etc/httpd/httpd.conf ist das DocumentRoot auf
/data/apache/htdocs vorkonfiguriert. Dieses wird auf /data/wwwdocs
geändert. Später wird diesem Apache noch das Resin Modul (DSO)
hinzugefügt.
Logrotate
Installiert ist bei Colt das Paket cronolog, welches die WebserverLogfiles täglich oder monatlich rotiert. Geschrieben wird dabei unterhalb
/data/apache/logs/2001/<monat>/<tag>.
Diese täglich rotierten Apache-Logfiles werden von einem Cronjob
eingesammelt und vom WebTrends Reporting Server ausgewertet.
2.2.3.1.1 Service-CGI
Als Gegenstück für die Content-Rules auf dem ContentSwitch gibt es für
jede Content-Rule auf Port 999 jedes Webservers ein Service-CGI, das
lokal auf dem jeweiligen Webserver testet, ob ein Service verfügbar ist
oder nicht und ob dieser Service auf der Maschine konfiguriert (gewollt)
ist. Auf diese Weise läßt sich einstellen, welche Sorten Requests auf
welche Maschinen verteilt werden sollen. Das CGI testet dann z.B. die
Lauffähigkeit der Servlet-Engine durch Aufruf einer JSP und gibt bei
23
Erfolg ein HTTP 200 zurück, sonst ein HTTP 204.
Die Konfiguration der Services erfolgt über ein File, das zwar auf jedem
Webserver in Kopie lokal vorliegt aber zentral gepflegt und verteilt
werden sollte. Auf dem Weg der Konfiguration läßt sich auch gezielt eine
einzelne Maschine in die Testgruppe nehmen, z.B. um das Inktomi
konfigurieren zu können oder eine spezielle Maschine von extern zu
testen.
Beteiligte Komponenten
•Cisco ContentSwitch 11050 (siehe 2.1.5)
•virtueller Webserver auf Port 999 auf jedem physikalischen Webserver,
mit Service-CGI
•zentrale Konfiguration mit Verteilfunktion auf dem Loghost
•Monitoring (SiteScope bei COLT, siehe 4.1.1)
•VLAN-Adressbereich, dieser ist im Script hart kodiert
Warnung: Achtung vorher lesen
Die Verteilfunktion "~cms/bin/rsync-service" kopiert Scripte und
Konfiguration für das Service-CGI auf alle Webserver. Wenn die kopierten
Scripte fehlerhaft sind oder nicht vorhanden, sterben binnen 15 Sekunden
alle Services auf allen Webservern ab. Tests sollten daher unbedingt mit
einem modifizierten Verteilscript erfolgen.
Die Installation des Service-CGI beinhaltet den zentralen Teil für die
Konfiguration der Services und den dezentralen auf den einzelnen
Webservern. Das Vorgehen zur Installation ist wie folgt:
2.2.3.1.1.1.1
Auf jedem
Webserver
Perl-CGIs
Installation Virtueller Webserver
der Webserver im VLAN 192.168.130.x ist ein virtueller
auf Port 999 zu installieren, dessen einzige Aufgabe es ist
zu servieren.
Benötigte Pakete (auf Webserver)
•Apache 1.3.x mit mod_cgi (genaue Version nicht relevant und sollte
durch die eigentliche Web-Applikation vorgegeben sein)
•Digest-MD5-2.13
•MIME-Base64-2.12
•URI-1.12
•HTML-Tagset-3.03
•HTML-Parser-3.25
•libnet-1.0703
•libwww-perl-5.53
•Crypt-SSLeay-0.27 (je nach SSL-Check, im Moment nicht notwendig)
•opensshd
•lynx (verzichtbar, für Testzwecke nützlich)
Benötigte Pakete (auf Loghost)
•openssh
•rsync
24
Alle Pakete sollten im Projektarchiv verfügbar sein. Die Versionsnummern
sind nicht essentiell, vielmehr sollten die Pakete aufeinander abgestimmt
sein.
In /etc/httpd.conf wird ein eigener VirtualHost auf Port 999
dafür konfiguriert, dessen CGI-Verzeichnis namens "service" auf
/data/service-cgi zeigt, worin sich das Perl-Skript namens
"global" befinden wird. Die weiteren Parametrisierungen für den RequestTyp erfolgt über die URI in der Weise, daß "static", "dynamic" usw. nur
symbolische Links auf das "global" Script sind. Deshalb müssen die
"follow symlinks" auch in der Konfiguration vorgesehen sein.
oValidiere, daß der User cms vorhanden ist und das scp vom Loghost aus
als User cms ohne Passwort-Request funktioniert.
oPakete Installieren.
oVerzeichnis /data/service-cgi einrichten mit chmod 755 und Owner cms
o
Die Scripte werden nicht lokal installiert sondern direkt von zentral
kopiert.
2.2.3.1.1.1.2 Installation der zentralen Verteilfunktion (siehe Warnung)
Die Scripte nebst symbolischer Links und die Verteilfunktion sollten sich
auf dem Loghost befinden:
• Dateien: /data/cms/admin/service
• Verteilscript: ~cms/bin/rsync-service
Alle Dateien sollten sich im CVS Repository befinden, bis auf die
symbolischen Links auf das global. Diese sind nach einem Neuaufbau im
Verzeichnis /data/cms/admin/service manuell anzulegen. Das Verteilscript
war nicht executable um versehentliches Ausführen des Scripts
unwahrscheinlicher zu machen.
•validieren, daß User cms und die genannten lokalen Verzeichnisse
vorhanden sind.
•validieren, daß auf den beteiligten Webservern die virtuellen
Webserver installiert und die Verzeichnisse korrekt eingerichtet
sind
•validieren der symbolischen Links in /data/cms/admin/service, dies
sind:
1) static[tst]
2) dynamic[tst]
3) secure[tst]
4) search[tst]
• validieren, daß das eigentliche Script "global" executable ist und
dem User "cms" gehört.
• validieren, daß alle Webserver im "~cms/bin/rsync-service"
drinstehen. Den Test einer neuen Maschine sollten die produktiven
Systeme auskommentiert werden.
• validieren, daß im Konfigurationsfile "service.conf" die notwendigen
Services eingetragen sind (siehe 4.3) und dieses File nur chmod 744
ist.
• su - cms
• Verteilfunktion aufrufen und mitlesen, ob die Verteilung erfolgreich
war.
2.2.3.1.1.1.3 Verifikation der Funktion auf einem speziellen Webserver
25
Nach den oben beschriebenen Schritten sollte auf den betroffenen
Webservern das Service-CGI laufen. Wenn der Rechner auch im ContentSwitch
konfiguriert und aktiviert ist, sollte jede Content-Rule alle 5 Sekunden
einen Request auslösen, was sich durch einen Blick in das Logfile klären
läßt. Hier sieht man auch, ob es HTTP 200 oder 204 für den einzelnen
Service gibt.
Gibt es im Access-Log keinen Hinweis, kann der Aufbau auch wie folgt
getestet werden.
•Auf dem betroffenen Webserver einloggen. z.B. als User cms
•mit netstat -tln checken, daß auf Port 999 was lauscht, wenn nein
Webserver-Virthost checken
•mit z.B. lynx 192.168.130.101:999/service/global?this=1 prüfen, was
auf dem Webserver konfiguriert ist, ggfs. Konfiguration checken,
(siehe 4.3.1). Vorsicht, das richtige Interface läßt sich nur
innerhalb des entsprechenden VLANs requesten. Der gleiche Test vom
Loghost aus müßte daher scheitern.
•Achtung: im global Script sind die VLAN Adressen hardcoded. Sollte
sich das Class-C geändert haben, muß dies im Script nachgeführt
werden.
2.2.3.2 JDK
Java 2 SDK Version 1.3.1 zu finden unter:
http://java.sun.com.
Unter
http://java.sun.com/j2se/1.3/download-linux.html
gibts ein "RedHat RPM shell script"
ftp://213.244.188.40/pub/j2sdk/1.3.1/f198267/j2sdk-1_3_1-linux-i386rpm.bin
Dieses enthüllt nach Aufruf dann ein RPM
[w002-002@santanderbkg-05 w002-002]$ sh j2sdk-1_3_1-linux-i386-rpm.bin
Heraus kommt die Datei jdk-1.3.1.i386.rpm
Es erfolgt die RPM-Installation:
[root@santanderbkg-05 w002-002]# rpm -ivh jdk-1.3.1.i386.rpm
Zusätzlich wird noch das RPM compat-libstdc++-6.2-2.9.0.9.i386.rpm
installiert:
[root@santanderbkg-05 w002-002]$ rpm -ivh compat-libstdc++-6.2-2.9.0.9.i386.rpm
[w002-002@santanderbkg-05 w002-002]$ /usr/java/jdk1.3.1/bin/java -version
java version "1.3.1"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1-b24)
Java HotSpot(TM) Client VM (build 1.3.1-b24, mixed mode)
2.2.3.3 Caucho Resin
Zum Komipieren des Resin-Apache-Moduls wird der gcc benötigt, das
wiederum weitere, noch nicht installierte RPMs benötigt.
Nachinstallation von
• rpm -ivh kernel-headers-2.4.0-0.26.i386.rpm
• rpm -ivh glibc-devel-2.1.92-14.i386.rpm
• rpm -ivh cpp-2.96-54.i386.rpm
• rpm -ivh binutils-2.10.0.18-1.i386.rpm
• rpm -ivh gcc-2.96-54.i386.rpm
26
• rpm -ivh make-3.79.1-5.i386.rpm
Resin ist also nicht als RPM verfügbar, das tar.gz Archiv wird
installiert. Zu finden unter:
http://www.caucho.com
Per scp zu Colt übertragen in /data/home/w002-002/SonstigeSoftware. Dann:
[root@santanderbkg-05 /root]# cd /data
[root@santanderbkg-05 /data]# tar xfvz /data/home/w002-002/SonstigeSoftware/resin1.2.7.tar.gz
[root@santanderbkg-05 /data]# chown -R w002-002.w002-002 resin-1.2.7
[w002-002@santanderbkg-05 w002-002]$ cd /data/resin-1.2.7/
[w002-002@santanderbkg-05 resin-1.2.7]$ ./configure --with-apache=/opt/local/apache -with-java-home=/usr/java/jdk1.3.1
[w002-002@santanderbkg-05 resin-1.2.7]$ make
Installation
[w002-002@santanderbkg-05 resin-1.2.7]$ su Password:
[root@santanderbkg-05 /root]# cd /data/resin-1.2.7/
[root@santanderbkg-05 resin-1.2.7]# make install
[root@santanderbkg-05 resin-1.2.7]# ls -l /opt/local/apache/libexec/mod_caucho.so
-rwxr-xr-x
1 root
root
151012 Jun 15 14:42
/opt/local/apache/libexec/mod_caucho.so
In der httpd.conf steht nun am Ende folgender Abschnitt:
#
# Caucho Servlet Engine Configuration
#
# Uncomment the following two lines to enable CSE
LoadModule caucho_module /opt/local/apache/libexec/mod_caucho.so
AddModule mod_caucho.c
<IfModule mod_caucho.c>
CauchoConfigFile /data/resin-1.2.7/conf/resin.conf
</IfModule>
In der resin.conf werden nun folgende Änderungen vorgenommen:
• der JDBC Abschnitt wird auskommentiert
• <app-dir>/data/wwwdocs</app-dir> auf das richtige DocRoot setzen
• <http port='8080'/> auskommentieren.
• <srun host='127.0.0.1' port='6802'/> => erstmal default lassen
• caucho-status in Produktionsumgebung auf false setzen!
• Autosetup deaktivieren: <war-dir id='webapps'/> auskommentieren
• "<web-app id='/'>" wird die einzig aktive sein.
•
•
•
•
•
to define: <welcome-file-list>
"snoop servlet" deaktivieren (servlet-mapping und servlet-name)
"/~user maps" deaktivieren
ALLE weiteren web-app Einträge mit "id=examples/*" deaktivieren
Der Abschnitt <web-app id='/'> wird um diverse Zeilen erweitert.
Bemerkung:
Evtl. wäre es hier sinnvoller, die Applikations(!)-Konfiguration
(zumindest teilweise) statt in der resin.conf, in einer Datei
WEB-INF/web.xml (siehe Servlet Spezifikation 2.2, PDF-Format, Seite 44)
27
zu schreiben, da diese dann jeweils mit der Applikation upgedatet
werden könnte.
• das Update Intervall für Klassen wird auf 300 gesetzt
<class-update-interval id='300'/>
• Neue Applikation <web-app id='customerPopup' ...> :
<web-app id='customerPopup' app-dir='/data/wwwdocs/customer/popup'>
<class-update-interval id='2'/>

<classpath id='/data/wwwdocs/WEB-INF/classes'
source='/data/wwwdocs/WEB-INF/classes'
compile='false'/>
<classpath id='/data/wwwdocs/WEB-INF/lib/oracle.jar'
compile='false'/>
<servlet-mapping url-pattern='/servlet/*' servlet-name='invoker'/>
<servlet servlet-name='customer' servlet-class='de.opus5.patagon.custome
<servlet-mapping url-pattern='/popup/jsp/*.jsp' servlet-name='customer'/
</web-app>
Hinweis:
Die Konfigurationszeile
<host id=''>
sollte nicht auf eine IP oder einen Hostnamen abgeändert werden, da es
sonst zu Kommunikationproblemen zwischen Resin und Apache kommt.
In der httpd.conf sind folgende Anpassungen vorzunehmen:
vi /etc/httpd/httpd.conf
Statt
DocumentRoot "/data/apache/htdocs"
das Verzeichnis
DocumentRoot "/data/wwwdocs"
Schreibberechtigt für letzteres ist der Benutzer cms.
Alle PHP Zeilen sind auszukommentieren.
Anschließend die saubere Resin-Umgebung einrichten.
In der Datei /data/resin-1.2.7/bin/srun.sh muß noch die Zeile
args=
durch die Zeile
args="-java_home /usr/java/jdk1.3.1"
ersetzt werden.
Als root:
cd /data/resin-1.2.7
chown -R nobody.nobody .
chmod o-x bin/*.sh
su - nobody -c "cd /data/resin-1.2.7/bin; ./srun.sh start"
Das so installierte Resin wird nun (inkl. Dateirechte plus
/opt/local/apache/libexec/mod_caucho.so und httpd.conf) auf die
weiteren Webserver verteilt.
Neustarts
28
•
•
su cd /data/resin-1.2.7/bin; ./resin-init.sh (stop|start)
bzw.
•
su - nobody -c "cd /data/resin-1.2.7/bin; ./srun.sh (stop|start)"
Für Reboots noch als root:
cd
ln
cd
ln
ln
cd
ln
ln
/etc/init.d
-s /data/resin-1.2.7/bin/resin-init.sh resin
/etc/rc3.d/
-s ../init.d/resin S95resin
-s ../init.d/resin K95resin
/etc/rc2.d/
-s ../init.d/resin S95resin
-s ../init.d/resin K95resin
2.2.3.4 Webapplikation
Die Webapplikation liegt unter /data/wwwdocs. Die Klassen liegen dort im
Verzeichnis WEB-INF/classes.
2.2.3.5
Suchmaschine Inktomi
2.2.3.5.1 Installation
Es existieren unterschiedliche Installations Paket für die verschiedenen
Plattformen. Anleitungen zur Installation sowie Download Möglichkeiten
findet man im Netz unter
http://www.inktomi.com/products/search/support/docs/ink4 x x install
linux.htm
oder für eine Installation auf Windows unter
http://www.inktomi.com/products/search/support/docs/ink4 x x install
nt.htm.
Die Installation beschränkt sich unter Linux auf das Auspacken des
heruntergeladenen Tar Archivs in ein gewünschtes Installations
Verzeichnis und dem Folgen der Installationsanweisungen in der INSTALL
Datei. Nach erfolgter Installation liegt folgende Verzeichnis Struktur
vor
/ - Hauptverzeichnis der Installation mit folgendem Inhalt
ultraseek - Start Datei für den Such Service
README - Readme Datei
INSTALL – Installationsanleitung
/lib - Bibliotheken des Such Dienstes mit folgendem Inhalt
python1.5 - Python Datei zum Patchen des Such Dienstes
/Fonts - Fonts
/docs - HTML Dateien für die Nutzerschnittstelle des Such Dienstes
/bin - ausführbare Dateien zum Start des Such Dienstes
Für die Installation der Patagon Anpassungen an der Nutzer Schnittstelle
müssen nach der Inktomi Service Installation im Installationsverzeichnis
des Service noch die aktuellen HTML Dateien im Verzeichnis docs
installiert werden.
2.2.3.5.2 Konfiguration
Für die Kon_guration des Such Dienstes, so dass die Patagon Seiten
korrekt indiziert werden, sind folgende Schritte notwendig:
1. Login in die Administrator Schnittstelle
29
2. Erstellen eines Such Index für den Patagon Auftritt
a) Erstellen einer neuen Collection
b) \spidering the web" (URL: http://host:port/de/*)
c) Konfiguration der Collection (regelmässige Jobs, Layout, usw.)
Result Page Width 600 (450)
Display Number of Hits 10
show query form above
Show individual word scores off
Remove from results duplicate hits with the same URL on
Highlight query terms in results page on
Interleave Sites off
Provide option to search the Internet off
3. Anstoßen der Indizierung der Seiten.
Die Qualität der Suchergebnisse h.angt nicht unwesentlich von der Qualtät
der indizierten Dokumente ab. Wurden im HTML zum Beispiel Meta Tags
definiert, die eine Beschreibung und/oder Schlüsselworte definieren,
können bei der Indizierung diese Angaben mit ausgwertet und eine
Bewertung der Seiten nicht nur einfacher sondern auch genauer vorgenommen
werden. Auch die Ausnutzung ähnlicher Mechanismen bei anderen Dokument
Typen führt zu einer genaueren Bewertung der Inhalte der Dokumente und
somit letzendlich zu einem besseren Suchergebnis.
Das Aktualisierungsverhalten des Such Service bestimmt die Aktualität der
Bewertung der indizierten Seiten. Damit wird auch die Qualität der
Suchergebnisse der Suchmaschine direkt beeinflußt. Auf Änderungen von
Seiten innerhalb der Menge indizierter Seiten wird vom Suchsystem
innerhalb bestimmter Zeitintevalle reagiert. Diese werden dynamisch an
Änderungsverhalten der Seiten/ Verzeichnisinhalte angepasst. Bei
Änderungen in diesem Verhalten sowie bei neu eingestellten Seiten kann
die Aktualisierung bestimmter Seiten zu selten erfolgen. Damit liegen
diese Seiten falsch bewertet im Index und werden möglicherweise über
nicht zutreffende Sucheingaben gefunden bzw. bei passenden Anfragen
nicht entdeckt.
Sollte es dadurch zu Problemen beim Suchservice kommen, kann die
Indizierung der Seiten von Hand neu angestoßen werden. Das Anstoßen der
Indizierung und das Setzen der Vorgabewerte für die
Aktualiserungsintervalle kann über die Administrator Oberfläche erfolgen.
2.2.4 Backend-Applikationen
Die Backend-Applikation ist auf dem Loghost unter /data/backend
installiert. Die Klassen liegen dort im Verzeichnis WEB-INF/classes.
2.2.5 Reporting
Das Reporting ist auf dem Loghost unter /data/reporting installiert.
Die Klassen liegen dort im Verzeichnis WEB-INF/classes.
2.2.5.1 WebTrends Enterprise Reporting Server
Der WebTrends Reporting Server generiert zyklisch Logfileauswertungen
aller Live-Webserver (HTTP und HTTPS), die ein Apache unter
https://reporting.patagon.de zur Verfügung stellt.
2.2.5.1.1 Installation auf LogHost
Die Installation erfolgt unter der Kennung root.
[root@santanderbkg-05 /root]# rpm -ivh /home/w002-002/WebTrends/wt-ers-linux.i586.rpm
30
Obwohl WebTrends offiziell nur für die RedHat-Versionen 5.2, 6.0, 6.1 und
6.2 zur Verfügung steht, war hier die Lösung für RedHat 7.0 mit der
Installation des RPMS compat-glibc-6.2-2.1.3.2.i386.rpm gefunden.
Die WebTrends-Installation befindet sich dann in
loghost:/usr/local/webtrends
Die Installation wird noch vervollständigt per:
[root@santanderbkg-05 /root]# cd /usr/local/webtrends
[root@santanderbkg-05 webtrends]# ./configure.sh
Lizenz lesen, "accept" tippen, Enter (UserAuthentication),
Ports: 80 (default 1099) für UI und 9999 (default) für Engine ....
SerialNumber: Enter (später Trial Code eingeben), start beim booten: Y ,
alles dem User bin geben lassen,
Would you like to have the .. started now: Y, Enter.
Anschließend steht der Reporting Server unter
http://`hostname`:80
zur Verfügung. Beim Erstaufruf sieht man eine Seite zum "Timed-Trial
mode". Über einen Button kommt man auf die Registrierseite von WebTrends,
wo man sich einen Trialcode bestellen kann. Dieser kommt unverzüglich per
E-Mail und kann dann in der Seite "Timed-Trial mode" unten unter:
"Trial Code or Product Serial Number: " eingegeben und submitted
werden. Damit läuft diese Installation nun mit einer Trial Lizenz
für 14 Tage.
Die Installation legt per Shellscript configure.sh die Linux-Boot-Dateien
an:
[root@santanderbkg-05 /etc]# ls -l init.d/*wtrs*
-rwxr--r-1 root
sys
1229 Jul 5 18:29 init.d/wtrs
[root@santanderbkg-05 /etc]# ls -l rc?.d/*wtrs*
lrwxrwxrwx
1 root
root
21 Jul 5 18:29 rc3.d/S99wtrs ->
/etc/rc.d/init.d/wtrs
lrwxrwxrwx
1 root
root
21 Jul 5 18:29 rc5.d/S99wtrs ->
/etc/rc.d/init.d/wtrs
[root@santanderbkg-05 /etc]#
Es fehlen die Stop-Varianten. Manuelle Nachinstallation:
[root@santanderbkg-05
/etc]# cd rc3.d/
rc3.d]#
rc3.d]# ln -s /etc/rc.d/init.d/wtrs K99wtrs
rc3.d]# cd ../rc5.d/
rc5.d]# ln -s /etc/rc.d/init.d/wtrs K99wtrs
Unter reporting.opus5.de sollen weiterhin Applikationsreports generiert
bzw. ausgeliefert werden. Dazu wird - analog zum Backend - noch eine
Resin-Instanz konfiguriert:
• /data/resin-1.2.7/bin/resin-init-reporting.sh
• /data/resin-1.2.7/conf/resin-reporting.conf
Zugriff auf die Administrationsseite:
• Einloggen auf Loghost per ssh mit X-Forwarding:
ssh 217.110.119.70 -l w002-002 -X
• Netscape remote starten:
netscape
• Aufruf in Netscape (auch über Bookmark "Webtrends Reporting
Server"):
31
http://localhost:1234/
• Login: cms (leeres Passwort); "sicher genug" da vorher ssh login
nötig
Aktuelles Auswertungsintervall: stündlich
2.2.6 CMS und QS
2.2.6.1
Installation des Content-Management-Systems E-Spirit
2.2.6.1.1 Voraussetzungen:
Folgende Software sollte vor dem Installieren zur Verfügung stehen:
• Sun JDK 1.2.2_006 (jdk-1_2_2_006-linux-i386.tar.gz)
• CMS.tar.gz (Komplett-Packet des Systems, verwendet Apache 1.3.19,
Tomcat, MySql 3.23.37 sowie einen virtuellen Xserver und ist
vorkonfiguriert zur Installation unter dem Verzeichnis /opt/cms des
Zielrechners)
Dazu werden die Archive auf den Loghost kopiert.
• scp CMS.tar.gz [email protected]:.
• scp jdk-1_2_2_006-linux-i386.tar.gz [email protected]:.
Danach Einloggen auf dem Loghost und root werden.
• ssh 217.110.119.89 -l w002-002
• su Installation JDK:
Den User cms auf Zielrechner anlegen, der zur Gruppe users gehört.
• useradd -u 3006 -g 100 -d /home/cms -s /bin/bash -c "Account für
Patagon-CMS" -m cms
Das zu verwendene JDK in ein frei wählbares <Verzeichnis> installieren.
(CMS läuft nach Angaben de Herstellers hiermit stabil)
Vorgehensweise:
a) jdk-1_2_2_006-linux-i386.tar nach <verzeichnis> kopieren
b) cd <verzeichnis>
c) jdk-1_2_2_006-linux-i386.tar.gz – Archiv entpacken:
• gunzip jdk-1_2_2_006-linux-i386.tar.gz
• tar –xvf jdk-1_2_2_006-linux-i386.tar
d) Verzeichnis java1.2.2 wurde unter <verzeichnis> angelegt.
e) Zur Versionsspezifizierung java1.2.2 umbenennen:
• mv java1.2.2 java1.2.2_006
f) Das CMS-System läuft später als cms-User und soll die den gerade
installierten JDK verwenden. Dies wird erreicht, indem im
Homedirectory des Users die ./bashrc editiert wird und am Ende der
Datei folgender Eintrag erfolgt:
• export PATH=<verzeichnis>/jdk1.2.2_006/bin:$PATH
Bei dieser Gelegenheit sollte für die spätere Datenbankanbindung
noch folgende Einträge vorgenommen werden:
• export PATH=/opt/cms/system/mysql/bin:$PATH
32
•
exportLD_LIBRARY_PATH=
$LD_LIBRARY_PATH:/opt/cms/system/mysql/lib
g) Mit 'which java' die Version überprüfen:
cms@host:~ > which java
/usr/local/jdk1.2.2_006/bin/java
Anmerkung:
In diesem Fall wurde beispielsweise /usr/local als
Installationsverzeichnis verwendet, wobei man hier jedoch nicht
festegelegt ist.
2.2.6.1.2 Installation des CMS:
Das CMS wird vorkonfiguriert als Package mit allen notwendigen
Komponenten geliefert. Demzufolge ist es notwendig, das CMS-System unter
dem Verzeichnis /opt/cms zu installieren, um eine komplette
Neukonfiguration zu vermeiden.
Vorgehensweise:
1) Als root-User in das Verzeichnis /opt wechseln und das Verzeichnis
cms anlegen.
• mkdir cms
2) Das Verzeichnis /opt/cms dem cms-User zuweisen:
• chown cms.users /opt/cms
3) Das Archiv-File CMS.tar.gz im Verzeichnis /opt/cms entpacken
• gunzip CMS.tar.gz
• tar –xvf CMS.tar
Nun sollten alle Komponenten des Systems anglegt worden sein:
cms@host:/opt/cms > ls
bin export lang projects servlets user
classes globalconfig log scripts system www
clientjar java policies serverjar tasks
cms@host:/opt/cms >
4) Nach /opt/cms wechseln und einen symbolischen Link java anlegen,
bzw. den bestehenden verändern, so dass er auf das zu verwendende
JDK verweist :
• ln -s <installationsverzeichnis>/jdk1.2.2_006 /opt/cms/java
Anmerkung:
Wie oben schon erwähnt, wir beim Package CMS.tar.gz /usr/local
als <installationsverzeichnis> verwendet.
5) Nach /opt/cms/globalconfig wechseln und die cms.ini-Datei
editieren. Hier muss die Variable PREVIEW_URL auf den verwendeten
Host angepasst werden:
• PREVIEW_URL =http://<hostname>:8000/preview
6) Nach /opt/cms/bin wechseln und von dort aus das CMS starten
33
•
cms start
Folgende Startreihenfolge ist in der Shell zu beobachten
1) mysql-DB auf Port 3306 (Standard-Port)
2) Virtueller X-Server Xvfb
3) CMSServer
4) RMI-Server (im Zuge des CMSServer-Starts)
nach einer Verweilzeit von 2 Minuten werden die weiteren
Komponenten gestartet:
5) Apache Webserver auf Port 8000, als User cms der Gruppe
users
6) Jakarta Tomcat auf Port 8080
h) Unter http://<hostname>:8000/admin/ sollte nun die Startseite des
Systems zu sehen sein.
2.2.6.1.3 Softwarekomponenten:
Die neben dem CMS verwendeten Softwarekomponenten befinden sich im
Verzeichnis
/opt/cms/system :
cms@host:/opt/cms/system > ls
apache jakarta-tomcat mysql xvfb
cms@host:/opt/cms/system >
a) CMS
Die Hauptkomponenten des CMS sind das CMSClient.jar-File im
Verzeichnis /opt/cms/clientjar und das CMSServer.jar-File im
Verzeichnis /opt/cms/serverjar. Bei einem Release-Wechsel sind nur
diese beiden Dateien durch die neuen Files zu ersetzten.
Zu beachten ist, dass im Verzeichnis /opt/cms/www/admin ein
symbolischer Link angelegt ist, der auf das CMSClient.jar - File
verweist, um die Änderungen im System bei einem Release-Wechsel auf
die beiden Dateien im Verzeichnis clientjar bzw. serverjar zu
beschränken.
Konfigurationsdateien und Info's:
Die wesentliche Konfigurationsdatei des CMS ist die Datei cms.ini
unter /opt/cms/globalconfig. Dieses File beinhaltet alle wesentlichen
Einträge zum Start des Systems. Eine weitere wichtige Datei ist die
Datei cms unter /opt/cms/bin. Über diese Datei und der Eingabe von
cms start kann das komplette System als User 'cms' gestartet und
gestoppt 2werden ( cms stopp).
b) MySQL-Datenbank
Nach der Installation des CMS-Packages sollte die Datenbank direkt
funktionsfähig sein. Zu diesem Zweck existiert ein User cms @
localhost mit Password ' cmsadmfsp' und allen Rechten. Nach dem Start
der Datenbankinstanz sollte das Shell-Frontend funktionieren:
34
cms@host:~ > mysql
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 7 to server version: 3.23.37
Type 'help;' or '\h' for help. Type '\c' to clear the buffer
mysql>
So dass das Ganze überprüft werden kann, wenn man sich die UserTabelle ausgeben lässt:
mysql> use mysql;
Database changed
mysql> select * from user;
+-----------+------+------------------+-------------+----| Host | User | Password | Select_priv |
Insert_priv | Update_priv
| Delete_priv | Create_priv | Drop_priv | Reload_priv |
Shutdown_priv | Process_
priv | File_priv | Grant_priv | References_priv |
Index_priv | Alter_priv |
+-----------+------+------------------+-------------+----| localhost | cms | 78abc1706f4d5de5 | Y | Y
|Y
| Y | Y | Y | Y | Y
|Y
| Y | Y | Y | Y
|Y |
+-----------+------+------------------+-------------+----2 rows in set (0.00 sec)
mysql>
Auf dem Loghost war es nötig, dass von Colt installierte MySQL zu
deaktivieren.
Installiertes und aktiviertes MySQL abschalten:
• /etc/init.d/mysql stop
Startskripte des Colt-RPMs werden in /etc/rc2.d entfernt:
• rm /etc/rc.d/rc0.d/K90mysql
• rm /etc/rc.d/rc2.d/S90mysql
• Evtl. ganzes RPM entfernen.
Im Verzeichnis /opt/cms/system/mysql/data existiert ein
Konfigurations-File my.cnf, das die erforderlichen Einträge enthält.
Die Systemdatei mysql.sock wird unter /tmp angelegt.
Die Datenbank läuft auf Ihrem Default-Port: 3306
c) Apache
Statt dem installierten Apache-RPM wird der mit CMS gelieferte Apache
verwendet und auf Port 80 konfiguriert.
Dazu wird der Start des Apache im Startscript /opt/cms/bin/cms
auskommentiert:
• START_APACHE=0
35
In der Konfigurationsdatei /opt/cms/system/apache/conf/httpd.conf
der Port von 8000 auf 80 geändert.
Danach wird dann der Apache-RPM gestoppt:
[root@santanderbkg-05 /data]# /opt/local/apache/bin/apachectl stop
/opt/local/apache/bin/apachectl stop: httpd stopped
und dann die Init-/Startskripte des Apache-RPMs deaktiviert:
[root@santanderbkg-05 /etc]# find rc*.d -name "*apache*"
rc.d/init.d/apache
rc.d/rc3.d/S80apache
rc.d/rc3.d/K80apache
[root@santanderbkg-05 /etc]# rm rc.d/rc3.d/S80apache
rm: remove `rc.d/rc3.d/S80apache'? y
[root@santanderbkg-05 /etc]# rm rc.d/rc3.d/K80apache
rm: remove `rc.d/rc3.d/K80apache'? y
Dann Start als root mit "/opt/cms/system/apache/bin/apachectl start"
der Apache gestartet.
Im Jakarta Tomcat Teil des CMS läuft defaultmäßig auch ein Webserver.
Dieser wurde mangels Notwendigkeit deaktiviert, indem der Connector
für HttpConnectionHandler in /opt/cms/system/jakartatomcat/conf/server.xml auskommentiert wurde.
d) Weiter Softwarekomponenten/ Anpassungen
Es gab Probleme mit libdb.so.3. Eine Lösung ist das Nachinstallieren
des RPMs. Dazu Mounten der RedHat 7.0 CD 1, dann:
[w002-002@santanderbkg-05 w002-002]$ cd /mnt/cdrom/RedHat/RPMS/
[w002-002@santanderbkg-05 w002-002]$ scp compat-glibc-6.2-2.1.3.2.i386.rpm [email protected]:.
[w002-002@santanderbkg-05 w002-002]$ su [root@santanderbkg-05 /root]# rpm -ivh /home/w002-002/compat-glibc-6.2-2.1.3.2.i386.rpm
[root@santanderbkg-05 /root]# cd /etc
[root@santanderbkg-05 /root]# vi ld.so.conf
Den Pfad /usr/i386-glibc21-linux/lib hinzufügen und ldconfig
aufrufen.
Dann muß noch (eine Komponente von) X installiert sein:
[w002-002@santanderbkg-05 w002-002]$ scp XFree86-libs-4.0.1-1.i386.rpm [email protected]:.
[w002-002@santanderbkg-05 w002-002]$ su [root@santanderbkg-05 /root]# rpm -ivh /home/w002-002/XFree86-libs-4.0.1-1.i386.rpm
Zu Xvfb (virtueller X-Server):
[root@santanderbkg-05 bin]# su - cms
[cms@santanderbkg-05 cms]$ cd /opt/cms/bin/
[cms@santanderbkg-05 bin]$ vi cms
weitere XFree86-Pakete fuer Xforwarding
36
[root@santanderbkg-05 /root]# rpm -ihvv --test /data/home/w002-002/XFree86-xfs-4.0.11.i386.rpm
rpm -ihvv --test /data/home/w002-002/Mesa-3.3-5.i386.rpm --nodeps
rpm -ihvv --test /data/home/w002-002/XFree86-4.0.1-1.i386.rpm
rpm -ihvv --test /data/home/w002-002/XFree86-tools-4.0.1-1.i386.rpm
Änderung:
# Xvfb $DISPLAY -nolisten tcp -fp /usr/X11R6/lib/X11/fonts/misc -screen 0 1024x768x24 &
# modifiziert nach Absprache mit e-spirit, 19.06.2001, [email protected]
Xvfb $DISPLAY -nolisten tcp -fp $CMS_SERVER_HOME/system/xvfb/fonts/misc -co
$CMS_SERVER_HOME/system/xvfb/lib/rgb -sp
$CMS_SERVER_HOME/system\/xvfb/lib/SecurityPolicy -screen 0 1024x768x24 &
Von E-Spirit wurde noch ein Archiv nachgeliefert, welches
den Verzeichnisbaum (/opt/cms/)"system/xvfb/lib" mit 2 Dateien
enthält.
scp xvfb.tgz [email protected]:.
[root@santanderbkg-05 root]# cd /opt/cms
[root@santanderbkg-05 cms]# tar xfvz /home/w002-002/xvfb.tgz
Zu Testzwecken lokaler HTTP-Zugriffe wurde noch das RPM lynx
installiert, allerdings mit der RPM-Option --nodeps wegen
fehlgeschlagenem Check auf Datei /usr/bin/perl.
[root@santanderbkg-05 /root]# rpm -ivh --nodeps /home/w002-002/lynx-2.8.4-3.i386.rpm
Das lynx-RPM wurde weiterhin auf der Maschine 192.168.150.103
installiert, um die Resin-Applikation lokal zu testen.
Für lokale, manuelle Zugriff auf das MySQL des CMS wird das ClientBinary /opt/cms/system/mysql/bin/mysql verwendet. Damit dieses aber
auf der aktuellen Installation funktioniert, wird noch (zusätzilch
zum installierten RPM ncurses-5.2-2) das RPM ncurses4-5.0-2
nachinstalliert.
a) Apache und Jakarta-Tomcat
Beide Komponenten liegen in den Verzeichnissen opt/cms/system/apache,
bzw. /opt/cms/system/jakarta-tomcat.
Der Apache Webserver läuft als cms-User auf Port 8000 und das TomcatModul auf Port 8080. Die Konfiguartionsdatei für den Apache liegt
unter:
/opt/cms/system/apache/conf/httpd.conf
und für den das Tomcat-Modul unter:
/opt/cms/system/jakarta-tomcat/conf/server.xml
b) Alle Log-Dateien des System liegen unter
/opt/cms/system/apache/logs
2.2.6.1.4 Software-Updates zum CMS
Dazu wird das CMSClient.jar und das CMSServer.jar auf den Loghost
kopiert.
scp CMS*.jar [email protected]:.
Auf dem Loghost als root:
37
su - cms
cp /home/w002-002/CMSClient.jar /opt/cms/clientjar/
cp /home/w002-002/CMSServer.jar /opt/cms/serverjar/
cd /opt/cms/bin
./cms stop
./cms start
2.2.6.1.5 Deployment Konfiguration
Verteilung der Inhalte erfolgt per rsync over ssh als User cms.
Die RSync Homepage ist zu finden unter: http://rsync.samba.org/ bzw. die
Manpage mit:
man rsync
Vorbereitung:
Auf alle Webmaschinen und dem Loghost wird das RPM rsync-2.4.4-1
eingespielt. Anschließend ssh Verbindung inkl. Authentification
konfigurieren:
[w103-103@santanderbkg-03 w103-103]$ cd .ssh/
[w103-103@santanderbkg-03 .ssh]$ ssh-keygen
[w103-103@santanderbkg-03 .ssh]$ ssh-keygen -t dsa
scp .ssh/identity.pub [email protected]:.ssh/au1.add
scp .ssh/id_dsa.pub [email protected]:.ssh/au2.add
cd .ssh
vi config
Neue Zeile: "cipher blowfish"
[w101-101@santanderbkg-01
.ssh]$
.ssh]$
.ssh]$
.ssh]$
cp -p authorized_keys authorized_keys.bak
cp -p authorized_keys2 authorized_keys2.bak
cat authorized_keys.bak au1.add > authorized_keys
cat authorized_keys2.bak au2.add > authorized_keys2
[w103-103@santanderbkg-03 w103-103]$ ssh -v -2 192.168.150.101 -l w101-101
[w103-103@santanderbkg-03 w103-103]$ ssh -v -1 192.168.150.101 -l w101-101
Da gibts einige Probleme beim Userwechsel in ssh-Aufruf.
Daher wird der User cms, UID 3006 auf allen Webmaschinen angelegt:
[root@santanderbkg-03 /root]# useradd -u 3006 -g 100 -d /data/home/cms -s /bin/bash -c
"CMS sdist User" -m cms
[root@santanderbkg-03 /root]# passwd cms
[root@santanderbkg-03 /root]# su - cms
[cms@santanderbkg-03 .ssh]$ ssh-keygen
[cms@santanderbkg-03 .ssh]$ ssh-keygen -t dsa
cd ..
scp .ssh/identity.pub [email protected]:.ssh/authorized_keys
scp .ssh/id_dsa.pub [email protected]:.ssh/authorized_keys2
vi .ssh/config
Test mit:
ssh -v -2 192.168.150.101
ssh -v -1 192.168.150.101
Passworte der User cms auf den Webmaschinen werden wieder zurückgesetzt
(in /etc/shadow).
Das Programm /data/home/cms/bin/rsync-patagon verteilt momentan unter
User 'cms' (den es nun auf allen Maschinen gibt) vom
loghost:/data/cms/deployed
38
nach w1, w2 und w3 in /data/wwwdocs
Vorher wird der einzuspielende Stand archiviert in
loghost:/data/cms/archive/dep.$filedate.tgz
Für ssh-Keyübertragung wurde dem User ein Passwort gesetzt. Hinterher auf
allen 3 Maschinen:
usermod -L cms
Zum Testen (des CMS lokal, Netscape unter Linux auf Loghost):
Installation folgender RPMS:
•
•
•
netscape-navigator-4.75-2.i386.rpm
netscape-common-4.75-2.i386.rpm
chkfontpath-1.7.2-5.i386.rpm
Weiterhin j2sdk-1_3_1-linux-i386.bin in /home/w002-002,
wobei die Datei java.policy von e-spirit noch ins Unterverzeichnis
/home/w002-002/jdk1.3.1/jre/lib/security/
kopiert wurde und durch Einfügen der Zeile
policy.url.2=file:${java.home}/lib/security/java.policy.cms
in
/home/w002-002/jdk1.3.1/jre/lib/security/java.security
bekannt gemacht wurde.
Abschließend wurde noch das CA-Zertifikat vom TCTrustcenter von
http://www.trustcenter.de/certservices/cacerts/_1716.der
downgeloaded und per
/home/w002-002/jdk1.3.1/jre/bin/keytool -import -file /tmp/_1716.der keystore /home/w002-002/jdk1.3.1/jre/lib/security/cacerts -storetype jks
registriert. (Default Passwort dabei ist noch: changeit)
Vor Starten des Netscape Clients wird noch (in $HOME/.bashrc) die
Variable
export NPX_PLUGIN_PATH=/home/w002-002/jdk1.3.1/jre/plugin/i386/ns4
gesetzt, damit das Java-Plugin aus dem JDK 1.3.1 funktioniert.
2.2.6.1.6 sendmail Konfiguration
Es werden die folgenden kleinen Änderungen an der Default-Installation
vorgenommen, damit Mails von Cronjobs, vom CMS etc. korrekt versendet
werden können.
39
[root@santanderbkg-05 /etc]# diff sendmail.cf sendmail.cf.bak
87c87
< DSmail.santander.de
--> DS
116c116
< DHmail.santander.de
--> DH
[root@santanderbkg-05 /etc]# diff mail/access mail/access.bak
7,9c7,9
< #localhost.localdomain RELAY
< #localhost RELAY
< #127.0.0.1 RELAY
--> localhost.localdomain RELAY
> localhost RELAY
> 127.0.0.1 RELAY
[root@santanderbkg-05 /etc]#
Nach Umkonfiguration muß sendmail restartet werden:
[root@santanderbkg-05 mail]# /etc/init.d/sendmail condrestart
Shutting down sendmail: [ OK ]
Starting sendmail: [ OK ]
[root@santanderbkg-05 mail]#
Nachtrag:
Zu CMS-Test-Zwecken wird auf einer neuen Maschine, IP 217.110.119.75, das
CMS noch einmal installiert. Die Maschine wurde von Colt neu installiert
plus der inzwischen auf dem Loghost existierenden User. Anschließend wird
von opus das CMS - wie oben beschrieben - installiert.
2.3
Externe Komponenten
2.3.1 Monitoring
2.3.2 Backup
2.3.3 ITBS Datenfeed
Die Daten werden von http://www.santander.de/stb_daten/upload geholt.
Konfiguration erfolgt an den folgenden Stellen:
• getITBS.pl
• Applet
• JSP-Dateien (werden im CMS verwaltet)
2.3.4 FMS
Für die Anbindung an FMS ist es notwendig, dass die Webserver IP-Adresse
bei FMS freigeschaltet wird.
Die Komponenten für die Anbindung sind in die Webapplikation integriert,
und müssen nicht einzeln installiert werden.
Die Konfiguration erfolgt über die FMSInit.properties, die sich auf dem
Loghost im Verzeichnis /data/cms/deployed/WEB-INF/classes befindet.
Von dort wird sie auf alle Webserver verteilt (Restart der Resins
notwendig)
40
2.4
3
3.1
Securitypolicy
Organisatorische Vorbereitung
Service Team Systeme und Applikationen
3.1.1 Rollen
3.1.2 Service Kanäle
3.1.3 Servicezeiten
3.2
Service Team Hosting
3.3
Service Center Patagon
3.4
Notfallstab Patagon
3.5
Vorzubereitende Entscheidungen und Eskalationsszenarien
3.5.1 Intrusion
3.5.2 Eingeschränkter Betrieb nach Totalausfall
4
Regelbetrieb
In diesem Kapitel sind die Aktivitäten erklärt, die für die
Aufrechterhaltung des täglichen Betriebs nötig sind.
Es wird beschrieben welche Logfiles vom System erzeugt werden und wie
einzelne Komponenten neu gestartet werden können.
4.1
System
4.1.1 Monitoring
Nach dem Monitoringkonzept von Johannes Fassen vom 16.08.2001.
4.1.1.1 Einführung
Für jede Servergruppe und den ContentSwitch gibt es ein eigenes
Monitoring Paket, das auf dem COLT Standardpaket basiert. In jedem
Paket gibt es kritische Monitore, die sofort einen definierten
Reaktionsplan auslösen und solche, die primär informativen Charakter
haben. Unabhängig davon sind von jedem Monitor Auswertungsübersichten
über mindestens einen Monat bzw. 31 Tage rollierend vorzuhalten, die
in einfacher Form revisionssicher archivierbar sein müssen.
Neben dem Monitoring gibt es noch die normalen Logfiles, die z.B.
beim Versagen des Backups geschrieben und selbstverständlich auch zur
Kenntnis genommen werden müssen. Diese sind nicht Gegenstand dieses
Dokuments.
Von der Begrifflichkeit wird zwischen Verfügbarkeit und Erreichbarkeit
unterschieden, wobei Erreichbarkeit heißt, daß "vom System aus ein
externer Service erreicht werden kann", und Verfügbarkeit heißt, daß
„ein Service auf der lokalen Maschine läuft und extern zugreifbar
ist“. Laut COLT sind Erreichbarkeitstests nur über Skript Monitore
realisierbar, so daß die effektive Erreichbarkeit eines externen
Service nur an einer Stelle aus der Patagon-Infrastruktur bei COLT
getestet wird.
Ebenso können Verfügbarkeiten z.B. einer URL nur auf Interfaces
getestet werden, die von extern oder aus dem Admin-LAN von COLT heraus
ansprechbar sind. Dieser Umstand hat insbesondere Einfluß auf die
Gestaltung der Monitore der Webserver-Farm, da hier alle relevanten
41
Services auf einem Interface laufen, das nur vom ContentSwitch aus
sichtbar ist.
4.1.1.2
Webserver-Farm
4.1.1.2.1 Tests
Für die Maschinen der Webserver-Farm soll ein Standard Grundpaket
eingerichtet werden. Da der eigentlich interessierende Service (HTTP,
über URL Test) wegen der Netzwerktopologie nicht direkt
implementierbar ist, wird dieser funktional im Monitoring des
ContentSwitch realisert. Auf diese Weise wird die Erweiterung des
Monitorings für den ContentSwitch bei Ausbau der Webserver-Farm über
das Standard Grundpaket des Webservers abgedeckt. Auf den Webservern
selbst laufen nur noch die Basistests.
Service
CPU
Plattenspeicher
Arbeitspeicher
Ping
Testmethode
COLT SiteScope
Standard
Anmerkungen
ping auf dem
Service LAN
lassen sich gezielt
Interfaces pingen?
Reaktionsplan
#2.1
#2.2
4.1.1.2.2 Reaktionspläne
#2.1: (automatisch)
1) Notifikation bei 1. Warnung: Email an [email protected]
2) Alarm bei 2. Schwellwertüberschreitung: Email an [email protected]
#2.2: (bis Behebung oder Eskalation nach opus5: 15 Minuten)
1) COLT eigener Reaktionsplan bei Netzwerkproblemen
2) Falls Netzwerkproblem und nicht behebbar und nicht nur das Service
LAN betroffen ist, Email an [email protected]
3) Sollte mehr sollte mehr als 1 Webserver betroffen sein, sofort
Email an: [email protected] und Anruf auf Mobiltelefon
4.1.1.2.2.1 TODOs
· Mobiltelefon opus 5 (=> opus5)
4.1.1.3
Messagebox (Standard Grundpaket + Zusatzpaket 2)
4.1.1.3.1 Tests
Neben den Basistests soll auf der Messagebox die Verfügbarkeit des
Webinterfaces für den Newsletterversand und die Erreichbarkeit des
Mailrelays und des DNS Servers sichergestellt werden. Die
Erreichbarkeitstest sind über einen Skript-Monitor zu realisieren.
Service
CPU
Plattenspeicher
Arbeitspeicher
ping
Verfügbarkeit
Webserver und
Testmethode
COLT SiteScope
Standard
ping auf dem
Service LAN
URL-Monitor
Standard
Anmerkungen
Reaktionsplan
#3.1
#3.2
Von extern ein HTTP
GET auf ein zu
#3.3
42
MySQL
Erreichbarkeit
des SMTP-Relays
Skript Monitor
definierendes CGI,
das auch auf die
MySQL DB zugreift
Versand einer Email
an [email protected]
Getestet wird nur ob
die Email auch vom
Mailrelay angenommen
wird.
DNS Lookup –t MX
#3.4
#3.1: (automatisch)
1) Notifikation bei 1. Warnung: Email an [email protected]
2) Alarm bei 2. Schwellwertüberschreitung: Email an [email protected]
2) Falls Netzwerkproblem und nicht behebbar und nicht nur das
Service LAN betroffen ist, Email an [email protected] und
den Owner bei Patagon für den Newsletter Versand zur
Notifikation
1) Netzwerktest durch COLT. Falls Netzwerkproblem bei COLT => COLT
interne Eskalationsplan und Email an [email protected] und
Notifikation an Owner des Newsletters
2) in der Newsletter-Versandzeit Email an: [email protected]
und Anruf auf Mobiltelefon, sowie Notifikation an Owner
Newsletter
3) in der sonstigen Zeit Email an: [email protected]
1) Check des Mail Relay Monitors mail.santander.de =>
Eskalationsplan Santander Infrastruktur
interne Eskalationsplan und Email mit Notifikation an [email protected]
3) Problem nicht behebbar:
Newsletter
4.1.1.3.2.1 3.3 TODOs
•
•
Notifikationskanal für Newsletter(=>patagon), failsafe gegen
Mailausfall, da dieser Workflow über den ausgefallenen Relay
laufen würde.
Definition Newsletter-Versandzeit (=> patagon)
43
•
•
•
•
Bereitstellung des Selbsttest CGIs (=> opus5)
Sicherstellung, daß mail.santander.de in einem adäquaten
Monitoring überwacht und Notifikationskanal eingerichetet ist
(=> patagon)
Definition Schnittstelle Fehlerstatus bei Skript Monitoren und
der Möglichkeit zur Anzeige einer Fehlermeldung (=>COLT)
Implementation Skript Monitor (=> opus5)
4.1.1.4
Datenbank-Server
4.1.1.4.1 Tests
Auf der Datenbank sollte neben den Basistest die Verfügbarkeit und
angemessene Performance der Datenbank überwacht werden. Die
Überwachung der Datenbank geschieht durch den durch eSpirit
implementierten Monitor. Dieser ruft extern via JDBC eine Stored
Procedure auf, welche neben der Sicherstellung der prinzipiellen
Erreichbarkeit der Datenbank, die statistischen Systemtabellen
ausliest, welche Aufschluß über die Performance der Datenbank liefern.
Dieser Monitor unterscheidet zwischen Notifikationen bei anstehenden
Performance Problemen und Alerts bei akuten Verfügbarkeitproblemen.
Ferner ist sicherzustellen, daß der DB-User keinen Zugriff auf die
Nutzdaten hat.
Service
CPU
Plattenspeicher
Arbeitsspeicher
ping
Datenbank
Backup
Testmethode
COLT SiteScope
Standard
ping auf dem
Service LAN
Oramon Monitoring
Tool für die
Datenbank von
Espirit
Skript Monitor
Anmerkungen
Schwellwerte für
Plattenspeicher
Reaktionsplan
#4.1
#4.2
#4.3
Prüft, ob die
Dumpfiles für das
Backup korrekt
erzeugt wurden.
#4.4
#4.1: (automatisch)
1) Email an [email protected]
1) umgehende Notifikation an das Kunden-Callcenter, dass potentiell
Störungen zu befürchten sind.
3) Falls Netzwerkproblem und nicht behebbar und nicht nur das
Service LAN betroffen ist, Email an [email protected]
#4.3: (bis Behebung oder Eskalation nach opus5: <10 Minuten)
1) Performance und Auslastungs Events: Email an [email protected]
2) Verfügbarkeitsevents: umgehende Notifikation an das Kunden-
44
Callcenter, da Störungen hier sofort Kundensichtbar werden.
interne Eskalationsplan und Email an [email protected]
4) Falls Probleme nicht behebbar: Email [email protected] und
Mobiltelefon opus5
#4.4: (automatisch)
4.1.1.4.2.1 TODOs
•
•
•
•
4.1.1.5
Notifikationskanal für Call-Center (=>patagon), möglicherweise
failsafe gegen Mailausfall
Genaue Sichtung der Features und Events von oramon (=>
Vorbereitung COLT), sowie damit die Definition der kritischen
Events
Einrichtung der notwendigen User auf der DB und Installation der
SP (=> opus5)
Implementation Skript Monitor (=>opus5)
Loghost (Standard Grundpaket + Zusatzpaket 2)
4.1.1.5.1 Tests
Auf dem Loghost sollte getestet werden:
Service
CPU
Plattenspeicher
Arbeitspeicher
Ping
Testmethode
COLT SiteScope
Standard
Anmerkungen
ping auf externes
Interface
Port 80
Connect auf Port 80
der «CMS IP»
Allgemeiner
Skript Monitor
Skript prüft die
Konnektivitätste
Erreichbarkeit der
st:
Services auf
Mail-Relay,
Portebene. Die
Messagebox,
grundsätzliche
DB,
Funktionalität der
Webserver-Farm
Services wird durch
andere Monitore
sichergestellt.
Verfügbarkeit
URL Monitor
aller (4)
Standard über
virtueller
externe Adresse
Webserver
CMS Selbstest
Skript Monitor
Skript requestet die
Status-Pages des CMS
und matcht auf
kritische Strings
Deployment-Test Skript Monitor
Skript testet die
Verteilfunktion für
das Deployment auf
die Livegruppe
Reaktionsplan
#5.1
#5.2
#5.2
#5.3
#5.4
#5.5
#5.6
45
FMS Datenquelle
URL Monitor auf
externe Maschine
#5.7
Im Scriptmonitor werden alle komplexen Wirkzusammenhänge getestet.
Zunächst wird dies sein, das Deployment zu testen und die „Hänger“
beim Webtrends, falls es keinen griffigen CMS-Selbsttest gibt, kommt
dieser ebenfalls in dieses Script.
Das Script selbst sollte Emails für Notifikationen generieren z.B. für
das hängende Webtrends und eine Error-Response für die kritischen
Teile, z.B. das Deployment.
#5.1: (automatisch)
1) umgehende Notifikation an die Redaktion
3) Bei Redaktionszeiten: Email [email protected], Mobiltelefon
opus5 außerhalb der Redaktionszeiten: Email [email protected]
1) Netzwerktest durch COLT von der Maschine aus. Falls
Netzwerkproblem bei COLT => COLT interne Eskalationsplan und
Email an [email protected] und Notifikation an Owner des
Newsletters und die Redaktion
Newsletter
Notifikation an: Redaktion, Reporting.
2) Während der Redaktionszeit: Email an [email protected] und
Mobiltelefon opus5
Notifikation an: Redaktion, Reporting.
Mobiltelefon opus5
Notifikation an: Redaktion, Reporting
Mobiltelefon opus 5
#5.7: (bis Behebung oder Eskalation nach FMS: 15 Minuten)
interne Eskalationsplan und Email an [email protected]
46
2) Bei offensichtlichem Netzwerkproblem bei der FMS => Alerting
Kanal FMS
3) Kein Netzwerkproblem erkennbar => Alerting Kanal FMS
4.1.1.5.2.1 TODOs
•
•
•
•
•
•
•
4.1.1.6
Alerting Kanal bei FMS (=>patagon)
Definition einer geeigneten Seite bei der FMS (=> FMS)
Selbsttest des CMS (=> eSpirit)
Notifikationskanal Redaktion (=> patagon)
Notifikationskanal Reporting (=> patagon)
Definition der Redaktionszeit (=> patagon)
Implementation der Script Monitore (=>opus 5)
Content-Switch
4.1.1.6.1 Tests
Von jedem Service sollte die aktuelle sowie die historische Verfügbarkeit
sichtbar sein. Bei den Content-Rules bieten sich Server-zentrierte
Sichten sowie „Gruppen-Ansichten“ an, um auf einen Blick zu sehen, wie
die Verfügbarkeit einer Content-Rule auf der Serverfarm ist.
Notwendig ist es, für jede Content-Rule einen Schwellwert zu definieren,
der bei Unterschreitung präventiv einen Alert auslöst, bevor eine Gesamte
Servicegruppe z.B. die www.patagon.de (statische Contents) ausfällt.
Die Nichtverfügbarkeit einer URL, www.patagon.de search.patagon.de und
https://www.patagon.de muß unmittelbar zu einem Alert führen. Bei den
Contentrules, sollte dies vom Schwellwert abhängen.
Sinnvolle Sichten:
• Überblick, aktuelle und historische Sicht der Gruppen bzw. URLs
• Pro-Server-Sicht: aktuelle und historische Informationen zu den
Content-Rules pro Server
• Content-Rule bezogene Sicht über alle Server
Da die Einrichtungsaufwände für die Überwachung der Content-Rules von der
Anzahl der Webserver abhängt, sind diese wie eingangs erwähnt in
Kombination mit dem Monitoring Paket der Webserver zu sehen und werden
über dieses abgerechnet.
Service
http://www.patagon.de
http://search.patagon.de
https://www.patagon.de
ContentRule:
ContentRule:
ContentRule:
ContentRule:
ContentRule:
static
dynamic
search
secure
statictest
Testmethode
Anmerkungen
URL Monitor,
Intervall 1 Min
URL Monitor,
Intervall 1 Min
URL Monitor,
Intervall 1 Min
SNMP, SW = 2
SNMP, SW = 2
SNMP, SW = 2
SNMP, SW = 2
SNMP, SW = 0
Reaktionsplan
#6.1
#6.1
#6.1
#6.2
#6.2
#6.2
#6.2
47
ContentRule: dynamictest SNMP,
ContentRule: searchtest
SNMP,
ContentRule: securetest
SNMP,
Test auf Totalausfall des
ContentSwitches selbst
*) SW=Schwellwert , SW=0 heißt,
SW = 0
SW = 0
SW = 0
Definition
durch Colt
es werden keine Alerts generiert.
#6.3
#6.1: (Störungsbehebung innerhalb 30 Minuten)
1) Notifikation an das Kunden-Call-Center und [email protected] (automatisch)
2) Netzwerk-Diagnose durch COLT
3) während der Service-Zeiten opus 5 auch per Mobiltelefon
Abarbeitung einer Checkliste von opus5 durch COLT
4) Bei Mißerfolg auch außerhalb der Service-Zeiten Mobiltelefon
opus5
#6.2: (Weitermeldung an opus5 innerhalb 30 Minuten)
1) Netzwerk-Diagnose durch COLT
2) Service auf allen Maschinen weg => #6.1
3) Email [email protected]
#6.3: (Störungbehebung innerhalb von 15 Minuten)
COLT eigenes Szenario
4.1.1.6.2.1 TODOs
• Implementation ContentSwitch Monitoring: 1) Vorschlag von COLT für
die einzelnen Sichten 2) Abnahme, patagon 3) Implementation
• Checkliste für die Störungsbehebung (=> opus5)
• Wiederherstellungsszenario für den ContentSwitch selbst(=> SLAs
COLT)
4.1.1.7 Sonstiges und weiteres Vorgehen
• Die Firewall selbst sowie die Router erscheinen nicht explizit im
Monitoring und werden als Teil der Netzwerkinfrastruktur
betrachtet. Wiederherstellungszeiten müssen von COLT im Rahmen der
SLAs angegeben werden.
• die Alerting und Service Kanäle sind gegen die vertraglichen SLAs zu
prüfen
• Es bleibt zu prüfen, welche Teile des Alertings automatisierbar sind
und welche Entscheidungen manuell zu treffen sind =>
Reaktionszeiten
• die prinzipielle fachliche Abstimmung, die die Beauftragbarkeit des
Monitoring sicherstellt, sollte bis zum 17. August 17:00
abgeschlossen sein. Dazu ist ggf. bis 17. August 12:00 ein
gemeinsamer Workshop zwischen patagon, COLT und opus 5.
• opus 5 muß neben der technischen Implementation die Reaktionspläne
inhaltlich qualitätssichern und auf organisatorische Abbildbarkeit
prüfen.
• die von COLT vorgeschlagenen Transaktions-Monitore, sollten für eine
zweite Stufe z.B. für den Kunde werden Prozeß ins Auge gefaßt
werden.
48
• Archivierung der Monitoring Historien
4.2
Backup
4.2.1 Konzept
Backup der Platten der einzelnen Systeme von Colt.
Dump vom CMS und von der Datenbank. (siehe auch 4.5)
4.2.2 Wiederherstellung
4.3
ContentSwitch
Unter normalen Umständen ist am Service-CGI nichts zu konfigurieren oder
zu überwachen, lediglich die Logfiles sollten beim allgemeinen LogfileAufräumen mit gelöscht werden.
In der Regel werden Konfiguratonsänderungen nur zu diagnostischen Zwecken
bzw. zur Konfigurationsarbeit z.B. am Inktomi geschehen.
Dementsprechend gibt es zwei Standardsituationen: Testen einer Speziellen
Maschine und erweitern der Webserver-Farm.
4.3.1 Konfigurationsfile und Standard-Doings
Das Konfigurationsfile (service.conf) ist gegliedert in:
•node: Hier stehen alle Knotennummern der Rechner, auf denen überhaupt
Services vorgesehen sind. Die Nummer entspricht der Class-C
Subnetzadresse. Ein Rechner der hier nicht steht macht keinen
Service.
•group_test: Nummern der Rechner, die in der Testgruppe Dienste
anbieten
•group_live: Nummern der Rechner, die in der Testgruppe Dienste
anbieten
•Services: die Services sind für beide Gruppen pro Maschine identisch,
d.h. test und live werden nur auf Gruppenebene unterschieden.
Die Gruppendefinitionen sind in folgendem Konfigurationsausschnitt
enthalten
# define the service group
nodes:101,102,103
group_live:101,102
group_test:103
# define the content rules
static:101,102,103
dynamic:101,102,103
secure:101,102,103
search:101,102
Bei fehlendem File sollte das Script auf alle Services defaulten.
4.3.1.1
Herauspicken eines speziellen Server in die Testgruppe
Um einen bestimmten Rechner zu testen, oder das Admin-Frontend des
Inktomi für genau eine Maschine zu bekommen:
• Auf loghost als User cms einloggen
• group_test genau auf den Rechner setzen der getestet werden soll und
checken, daß dieser auch den entsprechenden Service anbietet
"/data/cms/admin/service/service.conf"
• Verteilfunktion aufrufen.
49
4.3.1.2
Abklemmen eines Rechners aus den dynamischen Contents wegen
defekter Servlet-Engine
a) auf loghost als User cms einloggen
b) Den betroffenen Rechner aus der Service-Liste "dynamic"
austragen. "/data/cms/admin/service/service.conf"
c) Verteilfunktion aufrufen
4.4
Anwendungen
4.4.1 Frontent-Anwendungen
4.4.1.1 Webapplikation Kundenseite
Die Webapplikation ist erreichbar unter http://www.patagon.de.
Das Dokumentroot ist auf dem jeweiligen Rechner unter /data/wwwdocs zu
finden.
Die Properties sind im Verzeichnis /data/wwwdocs/WEB-INF/classes
abgelegt. Um Änderungen an den Properties wirksam werden zu lassen, ist
ein Neustart der Servletengine Resin nötig.
Die Properties dürfen auf den Liveservern nicht direkt editiert werden.
Änderungen erfolgen auf dem QS-Rechner (loghost) unter
/data/cms/deployed/WEB-INF/classes und werden dann über das BackendSkript /data/apache/htdocs/cgi-bin/rsync-patagon.cgi) auf die Liveserver
verteilt.
4.4.1.1.1 Starten und Stoppen
Das Starten und Stoppen der Webapplikation auf dem jeweiligen Rechner
(santanderbkg-0(1|2|3) ) erfolgt unter der Kennung root.
Servletengine Resin:
Um die Applikation neu zu starten, muß zuerst ein Login auf dem
entsprechenden Rechner erfolgen.
Der Loginvorgang erfolgt über den Loghost.
1. Einloggen auf dem Loghost:
ssh 217.110.119.70 -l w002-002
2. Von dort bei Bedarf auf den Liverservern einloggen:
login-w(1|2|3)
3. Auf der entsprechenden Maschine root werden:
su 4. Stoppen der Servletengine Resin:
/data/resin-1.2.7/bin/resin-init.sh stop
5. Stoppen der Servletengine Resin:
/data/resin-1.2.7/bin/resin-init.sh start
Webserver Apache:
1. Dazu einloggen auf dem Loghost:
ssh 217.110.119.70 -l w002-002
2. Von dort zum gewählten Rechner verzweigen:
login-w(1|2|3)
3. und dort root werden:
su -
50
4. Stoppen des Webservers Apache:
/opt/local/apache/bin/apachectl stop
5. Starten des Webservers Apache:
/opt/local/apache/bin/apachectl start
Achtung: Das starten des Webservers Apache erfordert die Eingabe einer
Passphrase! Die Passphrase schützt die Verwendung der SSL-Zertifikate.
4.4.1.1.2
Logfiles
Akivitäten werden in folgenden Logfiles protokolliert:
Webapplikation:
• /data/resin-1.2.7/log/patagon.log
• /data/resin-1.2.7/log/stderr.log
• /data/resin-1.2.7/log/stdout.log
• /data/resin-1.2.7/log/error.log
Webserver Apache:
• /data/apache/log/<Jahr>/<Monat>/<Tag>/access.log
• /data/apache/log/<Jahr>/<Monat>/<Tag>/errors.log
• /data/apache/log/<Jahr>/<Monat>/<Tag>/other_errors.log
• /data/apache/log/<Jahr>/<Monat>/<Tag>/servicecheck-access.log
• /data/apache/log/<Jahr>/<Monat>/<Tag>/servicecheck-error.log
• /data/apache/log/<Jahr>/<Monat>/<Tag>/ssl-access.log
• /data/apache/log/<Jahr>/<Monat>/<Tag>/ssl-error.log
• /data/apache/log/<Jahr>/<Monat>/<Tag>/ssl_engine_log
4.4.1.2 Alerting
Über den Alerting-Cron-Job alerting.sh wird alle 10 Minuten der Austuasch
der Alering-daten mit FMS angestoßen. Das Programm öffnet eine
Datenbankverbindung und liest alle Daten aus dem View
V_ALERTING_QUEUE
aus. In dem View werden Benutzerkonten und deren geänderter AlertingStatus (setzen/löschen) gespeichert. Der Alerting-Status wird über die
Web-Site unter dem Punkt 'Daten ändern' gesetzt. Alle Datensätze die der
View liefert werden einzeln von dem Programm als Get-Request an einen
FMS-Server gesendet und dort in einer Datenstruktur abgelegt. Als
Rückgabewert des Requests (Result) werden in XML definierte Statuscodes
geliefert. Wird der Statuscode 'Ok' geliefert, so wird der Datensatz aus
dem View gelöscht, ansonsten bleibt der Datensatz in dem View bestehen.
Die Inhalte des View V_ALERTING_QUEUE sollten sich also alle 10 Minuten
ändern, ansonsten ist das ein Indiz für einen Fehler im Cron-Job, der
Datenbank-Verbindung oder der Verbindung zu dem FMS-Server.
Falls Fehler auftreten ist zu überprüfen, ob der, auf dem Loghost unter
der Kennung o5oper installierte, Cron-Job
/home/o5oper/cron/alerting.sh
51
ausgeführt wird (siehe auch Kapitel 4.4.1.2 ). Das Skript alerting.sh
kann jederzeit manuell gestartet werden:
ssh -l w002-002 217.110.119.70
2. root werden:
su -
3. o5oper werden:
su - o5oper
4. Skript ausführen:
4.4.1.3 ITBS-Datenfeed
Die ITBS Applikation zur Darstellung von Kursdaten als Tageskursliste
innerhalb von JSPs bzw. als Kursverlauf innerhalb eines Applett benötigt
für die Anzeige aktueller Daten eine regelmässige Aktualisierung ihrer
Datenbasis. Die Datenbasis bilden Text Dateien die über eine Script
täglich von einem Server der Santanderbank geholt werden.
Das für den Download verwendete Script heißt getITBS.pl und befindet
sich im Verzeichnis.
/home/cms/bin
auf dem Loghost. Dieses Script wird automatisch jeweils um 7:00, 16:00,
17:00 und 18:00 Uhr gestartet und lädt die aktuellen Dateien mit den
Kursdaten in das Verzeichnis.
/data/e-spirit/data/.
Anschließend an den Datendownload werden die aktualisierten Dateien über
das Script rsync-espirit auf die Liveserver verteilt. Dabei wird ein
Backup der übertragenen Daten im Verzeichnis /data/cms/archive abgelegt.
Von dem Script getITBS.pl wird eine Logdatei in das Verzeichnis /tmp/ mit
dem Namen ITBS-<aktueller Zeitstempel>.log geschrieben. In diese Log
Datei werden Statusmeldungen zum Download jeder einzelnen Datei
geschrieben. Es kann also nach jeder Aktualisierung der Daten für jede
Datei nachvollzogen werden ob der Download erfolgreich verlaufen ist.
4.4.1.4 Suchmaschine Inktomi
Inktomi ist auf den Rechnern santanderbkg-01 und santanderbkg-02
installiert.
Zum Stoppen und Starten auf dem jeweiligen Rechner, sind folgende
Schritte durchzuführen:
ssh -l w002-002 217.110.119.70
2. Einloggen auf einem der Inktomi Rechner:
52
login-w(1|2)
3. root werden:
su -
4. Inktomi stoppen:
/opt/InktomiSearch/inktomisearch stop
5. Inktomi starten:
/opt/InktomiSearch/inktomisearch stop
4.4.1.4.2 Verwendung des Administrations-Frontends
Bei Verwendung des Adminfrontends ist darauf zu achten, daß man per
search(-test).patagon.de auf einer dedizierten Instanz (auf w1 oder w2)
arbeitet/konfiguriert/sichtet. Es ist also durch Konfiguration des
ContentSwitch sicherzustellen, daß über search(-test).patagon.de die
spezielle Instanz angesprochen wird (siehe auch Kapitel 4.3.1)
4.4.1.4.3 Logfiles
Die Logfiles sind über das Adminfrontend zu erreichen:
http://search.patagon.de/admin
4.4.2 QS-System
Der Staging-Server der Web-Applikation ist auf dem LogHost installiert
und lässt sich unter http://qs.patagon.de erreichen. Der Zugriff auf den
Stating-Server ist durch Basic Authentication geschützt.
Das Dokumentroot der Staging-Applikation liegt unter /data/cms/deployed.
4.4.2.1 Starten und Stoppen
Das Starten und Stoppen des QS-Servers erfolgt unter der Kennung root:
ssh 217.110.119.70 -l w002-002
2. und root werden:
su -
3. Restart der gewählten Komponente:
• für Apache:
/opt/local/apache/bin/apachectl (stop|start)
•
für Resin:
/data/resin-1.2.7/bin/resin-init-backend.sh (stop|start)
4.4.2.2 Logfiles
Webapplikation:
53
• /data/resin-1.2.7/log/stderr.log
• /data/resin-1.2.7/log/stdout.log
• /data/resin-1.2.7/log/error.log
Webserver Apache:
• /data/apache/log/<Jahr>/<Monat>/<Tag>/qs-access.log
• /data/apache/log/<Jahr>/<Monat>/<Tag>/qs-errors.log
• /data/apache/log/<Jahr>/<Monat>/<Tag>/ssl_engine_log
4.4.2.3 Update-Mechanismus
Unter http://qs.patagon.de dient dazu die Funktionalität der Applikation
vor dem Aufspielen auf die Live-Webserver zu testen.
Vom CMS Deployment-Prozess erzeugte Daten werden in das Verzeichnis
/data/cms/deployed eingespielt und können so einer Qualitätssicherung
unterzogen werden.
Updates der Java-Klassen und Property-Files werden vom Entwicklungsserver
(opus 5 intern) manuell in das Verzeichnis /data/cms/deployed gespielt.
Nach erfolgter Qualitätssicherung werden die Daten über ein VerteilerScript (Aufruf über das Backend) auf die Live-Systeme verteilt. Dies gilt
sowohl für die HTML und JSP-Seiten der Präsentationsschicht als auch für
die Java-Klassen und Property-Files der Applikationslogik.
4.4.3 Webapplikation Backend
Das Backend ist über die URL: http://backend.patagon.de zu erreichen, und
läuft auf dem Loghost.
Das Starten und Stoppen des Backends erfolgt unter der Kennung root.
ssh 217.110.119.70 -l w002-002
2. und root werden:
su -
• für Apache:
•
für Resin:
/data/resin-1.2.7/bin/resin-init-backend.sh (stop|start)
4.4.3.2 Logfiles
Webapplikation:
54
• /data/resin-1.2.7/log/stderr-backend.log
• /data/resin-1.2.7/log/stdout-backend.log
Webserver Apache:
• /data/apache/log/<Jahr>/<Monat>/<Tag>/backend-access.log
• /data/apache/log/<Jahr>/<Monat>/<Tag>/backend-errors.log
4.4.4 Reporting-Server
Der Reporting-Server ist zu erreichen unter http://reporting.patagon.de.
Das Reporting besteht im Wesentlichen aus zwei Teilen:
• dem WebTrends Enterprise Reporting Server und
• der Reporting Applikation.
Beide Teile sind über die angegebene URL zu erreichen und laufen auf dem
Loghost.
4.4.4.1 Reporting Applikation
Die Reporting Applikation stellt das Frontend für Auswertungen über, von
den Webapplikationen bereitgestellte, Daten dar. Es ermöglicht die
Visualisierung von Berichten zu diesen Daten.
Diese Applikation läuft als Servlet auf dem Loghost.
Das Starten und Stoppen der Servletengine erfolgt unter der Kennung root.
ssh 217.110.119.70 -l w002-002
2. und root werden:
su -
• für Apache:
•
für Resin:
/data/resin-1.2.7/bin/resin-init-reporting.sh (stop|start)
4.4.4.1.2 Logfiles
Webapplikation:
• /data/resin-1.2.7/log/stderr-reporting.log
• /data/resin-1.2.7/log/stdout-reporting.log
Webserver Apache:
• /data/apache/log/<Jahr>/<Monat>/<Tag>/reporting-access.log
55
•
•
•
/data/apache/log/<Jahr>/Monat>/<Tag>/reporting-errors.log
/data/apache/log/<Jahr>/<Monat>/<Tag>/reporting-ssl-access.log
/data/apache/log/<Jahr>/Monat>/<Tag>/reporting-ssl-errors.log
4.4.4.2 Webtrends Enterprise Reporting Server
Starten und Stoppen des Webtrends Enterprise Reporting Server:
ssh –l w002-002 217.110.119.70
2. Root werden:
su –
3. Den Server stoppen:
/etc/init.d/wtrs stop
4. Den Server starten:
/etc/init.d/wtrs start
Der Webtrends Enterprise Reporting Server ermöglicht Auswertungen über
die Inhalte von Logdateien von Web Servern und Servlet Engines. Dazu
müssen die Logdateien dem Server lokal zur Verfügung stehen. Zu diesem
Zweck wird jede Stunde ein Script zum Download der aktuellen Logdateien
von den Liveservern gestartet.
Es wird der Inhalt des folgenden Verzeichnisses heruntergeladen:
/data/apache/logs/2001/.
Die Dateien werden anschließend nach
• /data/weblogfiles/w1 bzw
• /data/weblogfiles/w2,
• /data/weblogfiles/w3
kopiert. Da WebTrends nicht über verschiedene Unterverzeichnisse sondern
nur über mehrere Dateien im gleichen Verzeichnis auswerten kann, werden
per cronjob prepareLogs.sh die Logs aus
/data/weblogfiles/w1-w3
nach
/data/weblogfiles/all
kopiert und dabei umbenannt (die ursprünglichen Namen sind auf allen
Live-Maschinen identisch).
4.4.5 CMS
Das CMS ist unter /opt/cms installiert. Das CMS liegt physisch unter
/data/cms_system und ist über einen symbolischen Link nach /opt/cms
gemountet, da die CMS-Installation im Verzeichnis /opt/cms erfolgen muß.
Zum Betrieb ist der Webserver erforderlich, der unter
/opt/cms/system/apache installiert ist.
56
4.4.5.1
Starten und Stoppen
CMS-Server
Das CMS wird als User cms mit gestartet bzw. heruntergefahren.
ssh 217.110.119.70 -l w002-002
2. und root werden:
su -
3. cms User werden:
su - cms
4. CMS neu starten:
•
•
/opt/cms/bin/cms stop
/opt/cms/bin/cms start
Webserver Apache:
Starten/ Stoppen unter der Kennung root.
ssh 217.110.119.70 -l w002-002
2. und root werden:
su -
3. und den Apache neu starten:
•
•
opt/cms/system/apache/bin/apachectl stop
opt/cms/system/apache/bin/apachectl stop
4.4.5.2 Der CMS-Exportprozeß
Zweimal am Tag wird der Content aus dem CMS-System exportiert.
Der Export erfolgt in das Verzeichnis:
/data/cms/deployed_cms_only/.
Beim Start des Exports wird das Skript:
/opt/cms/scripts/startScript.sh ausgeführt.
Dieses Skript setzt ein Flag, daß in der Backend-GUI den laufenden Export
anzeigt. Nach Beendigung des Exports wird das Skript:
/opt/cms/scripts/endScript.sh ausgeführt.
Hier werden verschiedene Funktionalitäten durchgeführt.
• /home/cms/bin/pickings.pl:
ersetzt Umlaute in allen Dateien in /data/cms/deployed_cms_only/
• /home/cms/bin/error_pages.pl:
bearbeitet die Bildreferenzen der Errorpages
• /home/cms/bin/asuro_hd.pl:
Asuro- und Hypothekendiscount-Fragmente erzeugen
• löscht die alten Daten in /data/cms/deployed/ (Verzeichnisse de,
de_1, media)
• Kopieren der exportierten Daten von /data/cms/deployed_cms_only/
nach /data/cms/deployed
• Rechte für den Newsletterversand im Verzeichnis
/data/cms/deployed/de_1/email_abo werden gesetzt
• Update der Datenbank mit den Daten der exportierten
Abstimmungsseiten durch folgenden Aufruf
57
„java -classpath /data/cms/voting/:/data/cms/deployed/WEBINF/classes:/data/cms/deployed/WEB-INF/lib/oracle.jar
de.opus5.patagon.voting.VotingTableUpdater“
• im Falle eines konfigurierten automatischen Deployment, werden die
Daten, nach einer definierten Wartezeit (einstellbar im Backend)
auf die konfigurierten Server verteilt.
(/data/apache/htdocs/cgi-bin/rsync-patagon.cgi)
Das Deployment
ausführbar.
Änderungen der
Liveserver neu
Diese Funktion
auf die Liveserver ist auch über das Backend-GUI
Properties werden nur wirksam, wenn die Servletengines der
gestartet werden.
kann nicht über das Backend-GUI ausgeführt werden.
Dazu:
1. Einloggen auf dem Loghost unter w002-002:
ssh –l w002-002 217.110.119.70
2. alias login-w(1|2|3) benutzen um sich auf einem der Liveserver
einzuloggen, z.B.:
login-w1
3. dort root werden:
su -
4. Neustart des Resin:
•
•
/data/resin-1.2.7/bin/resin-init.sh stop
/data/resin-1.2.7/bin/resin-init.sh start
4.4.5.3
Logfiles
wichtige CMS-Logfiles:
• /opt/cms/log/CMS_Server.log
• /opt/cms/log/access_log (Webserver)
• /opt/cms/log/error_log (Webserver)
• /opt/cms/log/deployment.log (Meldungen zum Deployment)
• /opt/cms/log/generate.log (Meldungen während der Generierung des
Projektes)
Die Dateien CMS_Server.log und generate.log werden vom CMS ständig in
ZIP-Files archiviert. Die ältesten Versionen dieser Dateien sollten
regelmäßig nach eventueller externer Archivierung (CD) gelöscht werden.
Ebenso sollte die übrigen Logfiles auf Größe kontrolliert werden.
Abstimmungsfunktionalität:
Bestandteil das CMS-Export. Protokoll unter:
• /data/cms/voting/protocol.txt (wird in der Datei
/data/cms/voting/logger.properties definiert)
Newsletterversand:
Nach dem erfolgten CMS-Export kann über die Backend-GUI, oder über die
Shell, der Newsletterversand angestoßen werden.
• /data/apache/htdocs/cgi-bin/delivery.cgi
• Das Protokoll wird in folgender Datei gespeichert:
/data/cms/delivery/protocol.txt (wird in der Datei
58
/data/cms/delivery/logger.properties definiert)
4.4.5.4 Backup
Es ist ein tägliches Backup eingerichtet, das das Projekt in das
Verzeichnis /opt/cms/backup als ZIP-File exportiert. Da jede dieser
Dateien zur Zeit rund 100MB groß ist, müssen ältere Versionen in
regelmäßigen Abständen (z.B. wöchentlich) nach eventueller externer
Archivierung (CD) gelöscht werden.
4.4.6 Messaging-System
Die Messaging Box läuft auf dem Rechner list.patagon.de. Die Requests
werden von der Messaging Box über folgende URL entgegengenommen:
http://192.168.110.2/cgi-bin/send.pl
4.4.6.1 Webserver Stoppen und Starten
1. Einloggen auf Loghost:
ssh -l w002-002 217.110.119.70
2. Einloggen auf santanderbkg-04:
login-mail
3. root werden:
su -
4. Apache stoppen:
/opt/local/apache/bin/apachectl stop
5. Apache neu starten:
/opt/local/apache/bin/apachctl start
4.4.6.2 Logfiles
Die Zugriffe und Fehler werden in
• /data/apache/log/access.log und
• /data/apache/log/error.log mitgeloggt.
Die Logfiles von Qmail liegen unter:
/data/logs/qmail
4.4.6.3 Bounce-Datenbank
Die gebouncten Emailadressen werden in der Datenbank gespeichert. Zugriff
auf die Tabellen über Mysql-Shell, unter der Kennung bmail.
ssh 217.110.119.70 -l w002-002
2. Von dort zum Message Box Rechner verzweigen:
login-mail
3. Mysql-Shell unter der Kennung bmail starten:
mysql -u bmail -p
4. Tabellen auslesen:
59
use mailing;
select * from BOUNCERS;
select * from INVALID_EMAIL_ADRESSES;
4.4.7 Datenbank
Der Datenbankserver ist auf der
192.168.120.2 installiert.
Der Server wird mit Hilfe des Servermanagers kontrolliert:
ssh 217.110.119.70 -l w002-002
2. Wechseln zum Datenbankserver:
ssh -l oracle 192.168.120.2
3. Server-Manager starten mit:
svrmgrl
4. Datenbank stoppen:
SVRMGR> connect internal as sysdba
SVRMGR> shutdown immediate
(kein Semikolon am Ende!)
(Das Herunterfahren der Datenbank nimmt etwas Zeit in Anspruch
(ca. 30 Sekunden))
5. falls sich nichts tut:
SVRMGR> shutdown abort
6. Datenbank starten:
SVRMGR> connect internal as sysdba
SVRMGR> startup mount PATAGON
SVRMGR> alter database open;
(falls nicht schon angemeldet)
(Semikolon!)
(Auch bei für diesen Prozess wird etwas Zeit benötigt)
4.4.7.2 Backup
Das Backup wird durch das Skript dbbackup.sh (siehe Kapitel 4.5.2)
angestoßen, dieses wird durch den Cron verwaltet.
Das Skript führt einen vollständigen Tablespace-Dump des Oracle-Benutzer
'patagon' aus und legt die entstandene Datei unter '/data/OracleBackup'
ab. In dem Home-Verzeichnis des Benutzer 'oracle' schreibt das Skript in
dem Ordner 'cron/' ein Log-File mit den Dump-Ausgaben.
4.4.7.3 Monitoring
Kontrolle der Anzahl offener Verbindungen zum Datenbankserver:
ps -eadf |grep 'oraclePATAGON' | wc -l
Ab einer Anzahl grösser 37 kann man davon ausgehen, daß die Datenbank
überlastet ist.
Behebung des Problems:
1.Neustart der Resins der Webapplikation
2.wenn 1.) keine Veränderung bringt Datenbank Neustart (siehe oben),
60
danach müssen ALLE Resins neugestartet werden, die eine Verbindung zur
Datenbank haben.
4.4.8 Checklisten
Die folgenden Checklisten dienen zur Eingrenzung und Behebung von Fehlern
in einem oder mehreren Teilen der Web-Applikation. Führen die
aufgelisteten Maßnahmen nicht zur Fehlerbehebung, sollte gemäß
Eskalationsplan nach opus 5 eskaliert werden.
Funktionierende Server-Systeme nach dem in Kapitel 4.1.1 beschriebenen
System-Monitoring sind hier vorrausgesetzt.
4.4.8.1
Webapplikation
Teilapplikation
Check
Maßnahme
User-Login
Datenbankverbindung der
Resin neu starten #10
Applikation im Logfile #1
Verbindung zum
Datenbankserver überprüfen
(Colt-Ansprechpartner
benachrichtigen)
Datenbank neu starten #11
Anbindung FMS-Daten FMS Erreichbarkeit der
FMS-Ansprechpartner
Applikation im Logfile #2 benachrichtigen
Kunde-Werden Prozeß Datenbankverbindung der
Verbindung zum
benachrichtigen)
Forum
Verbindung zum
benachrichtigen)
Abstimmungsfunktionalität
Verbindung zum
benachrichtigen)
Send2aFriendFunktionalität
Mailrelay Erreichbarkeit Mailrelay-Ansprechpartner
#3
benachrichtigen
Suchfunktion
Verfügbarkeit Inktomi
Tool #4
Neustart von Inktomi #4
Keine oder nicht
Verfügbarkeit und
Aktualisierung der Kurs-
61
Teilapplikation
Check
Maßnahme
aktuelle Kursdaten Aktualität der Kursdaten Daten #5
zu Währungen,
#5
Aktienfonds
Abgleich der
Austausch der Alerting
Alerting-Daten mit Daten mit FMS #6
FMS
FMS Erreichbarkeit #6
Brokerage Applet
4.4.8.2
Aktualisierung von FMS #6
FMS-Ansprechpartner
benachrichtigen
Elaxy Ansprechpartner
benachrichtigen
Backend
Funktion
Check
Maßnahme
Deployment auf die Verbindung vom Loghost
Liveserver
auf die Livesever aktiv
Colt-Ansprechpartner
benachrichtigen
Newsletterversand
Netzverbindung überprüfen
benachrichtigen)
Messaging Box
Erreichbarkeit #7
Webserver der Messaging Box
überprüfen/ neu starten #12
Datenbank Erreichbarkeit Verbindung zum
#8
benachrichtigen)
4.4.8.3
Reporting
Funktion
Check
Reporting Applikation Verfügbarkeit der
Applikation #1
Maßnahme
Verbindung zum
Datenbankserver
überprüfen (ColtAnsprechpartner
benachrichtigen)
Datenbank neu starten
#11
WebTrends Enterprise
Reporting Server
4.4.8.4
Hängende Prozesse #9
WebTrends neu starten #9
Check~ und Maßnahmenkatalog
#1: Datenbankverbindung der Applikation im Logfile
62
Es ist zu untersuchen, ob die Applikation ein funktionierende Verbindung
zur Datenbank hat.
1. Auf dem betroffenen Rechner in den Logfiles:
• santanderbkg-0(1|2|3|5):/data/resin-1.2.7/log/patagon.log
• santanderbkg-0(1|2|3|5):/data/resin-1.2.7/stderr.log
nach java.sql.SQLExceptions suchen.
2. Mögliche Maßnahmen:
1) Resin neu starten (#10)
2) Datenbank neu starten (#11)
#2: FMS Erreichbarkeit der Applikation im Logfile
Es ist zu untersuchen, ob die Applikation eine funktionierende Verbindung
zum FMS-Service hat.
ist im Falle von Problemen eine java.io.FileNotFoundException
vorhanden.
2. Bei der Verbindung zu FMS kann es mehrere Probleme geben:
• FMS ist nicht erreichbar
? im Logfile ist eine java.net.SocketException zu sehen
• FMS-Service nicht verfügbar
? bis zum Timeout des FMS-Webservers ist nichts zu sehen, dann
java.io.FileNotFoundException
• FMS kann Request nicht bearbeiten und liefert Fehlerseite zurück
? Applikation loggt Meldung „"got ErrorPage from FMS“ ins
Logfile
Beim ersten und zweiten Punkt sind auf jedenfall FMS-Ansprechpartner zu
benachrichtigen.
#3: Mailrelay Erreichbarkeit der Applikation im Logfile
Bei einem SendToAFriend-Funktionsaufruf wird die erzeugte Mail direkt an
den konfigurierten SMTP-Host (localhost) ausgeliefert. Wenn die
Verbindung nicht möglich ist, kann man dies im Logfile auf einem der
Liverserver sehen.
ist in diesem Fall eine javax.mail.MessagingException zu sehen, mit
der Erklärung, daß eine Verbindung zum Port 25 des SMTP-Hosts nicht
möglich sei.
63
2. Hier muß die Verfügbarkeit des Mailrelay gestestet werden (z.B. telnet
mail.santander.de 25), bzw. die Verbindung dorthin.
#4: Verfügbarkeit des Inktomi Tools
Das Inktomi Tool ist auf den Rechnern santanderbkg-01 und santanderbkg-02
verfügbar. Bei Nicht-Verfügbarkeit, kann ein Neustart sinnvoll sein
(siehe Kapitel 4.4.1.4 ).
#5: Verfügbarkeit der Kursdaten
Die Applikation liest die Kursdaten local aus dem Filesystem des
jeweiligen Liveservers ein.
Die Aktualität der Kursdaten wird über einen periodischen
Aktualisierungsprozess sichergestellt. Dazu holt das in der Crontab auf
dem Loghost definierte Skript:
/home/cms/bin/getITBS.pl
die Kursdaten auf den Loghost. Fehler bei Downloadprozess werden in der
Datei:
/tmp/ITBS<Zeitstempel>.log dokumentiert.
Die Verteilung der aktualisierten Dateien auf die Liverserver erfolgt
mittels
/home/cms/bin/rsync-espirit
(Auch dieser Prozess wird über die Crontab eingebunden).
Sollten bei diesem Prozeß Fehler auftreten, sind z.B. die Daten im
Livesystem nicht aktuell, bzw. nicht vorhanden, können die Daten auch
manuell vom Server geholt und auf die Liveserver übertragen werden (siehe
Kapitel 4.4.1.3 ).
#6: Austausch der Alerting Daten mit FMS
Durch das in der Crontab auf dem Loghost definierte Skript:
wird alle 10 Minuten die Datenbank nach neue Einträgen in der AlertingQueue durchsucht. Diese Einträge werden per HTTP zu FMS übermittelt.
Sind die Daten bei FMS nicht vorhanden, kann der Service bei FMS nicht
erreichbar sein.
Der Versand zu FMS kann per Hand angestoßen werden (siehe Kapitel 4.4.1.2
).
#7: Newsletterversand, Messaging Box erreichbar?
Der Newsletterversand übergibt die zu versendenen Newsletter an die
Message Box per HTTP.
1. Wenn die Message Box nicht verfügbar ist, wird das im Logfile:
loghost:/data/cms/delivery/protocol.txt
durch eine
• java.io.FileNotFoundException (Service nicht verfügbar)
bzw.
• java.net.SocketException (keine Verbindung zu santanderbkg-04)
dargestellt.
2. Hier ist eine Überprüfung der Netzanbindung bzw. Überprüfung des
64
Webservers der Message Box nötig.
#8: Newsletterversand, Datenbankanbindung vorhanden?
Der Newsletterversand stellt die Abonnenten der Newsletter durch
Datenbankabfragen fest.
1. Wenn die Datenbankanbindung gestört ist, werden keine Newsletter
versendet und im Logfile:
loghost:/data/cms/delivery/protocol.txt
wird das durch eine java.sql.SQLExceptions angezeigt.
2. Hier muß die Netzanbindung an den Datenbankserver kontrolliert werden
bzw. die Verfügbarkeit der Datenbank selbst. Ist der Service nicht
verfügbar muß die Datenbank neu gestartet werden (#11).
#9: Hängender WebTrends Enterprise Reporting Server
Es besteht die Möglichkeit, daß der Reporting Server nicht mehr
erreichbar ist.
• Einloggen auf Loghost:
ssh 217.110.119.70 -l w002-002
• Feststellen, daß WebTrends hängt:
ps gauxwww|grep wtr
Der folgende Text ist ein Beispiel für einen Ausschnitt des
Ergebnisses des obigen Aufrufs
/usr/local/webtrends/wtrs_ui -start
nobody
32147 0.0 0.5 20100 8012 pts/116 S
/usr/local/webtrends/wtrs -start
nobody
14912 0.0 3.9 77284 61344 pts/116 SN
/usr/local/webtrends/wtrs 1 -child
nobody
14913 0.0 0.0
0
0 pts/116 ZN
.
.
.
Aug13
0:04
00:00
0:00
00:00
0:01 [wtrs <defunct>]
==> Der <defunct> und der "-child" sind die hängenden Prozesse.
Neustart des Reporting Server, siehe Kapitel 4.4.4.2 .
Falls der Neustart die hängenden Prozesse nicht beseitigt. Manuelles
Stoppen dieser Prozesse mit:
kill -9 <pid>
#10: Restart der Webapplikation (Neustart Resin)
Siehe dazu Kapitel 4.4.1.1.1.
#11: Neustart der Datenbank
Die Datenbank kann mit Hilfe des Servermanagers neu gestartet werden.
Siehe 4.4.7.1 .
#12: Webserver der Messaging Box überprüfen/ neu starten
Siehe Kapitel 4.4.6.1 .
65
4.5
Batches
Auf den Rechnern laufen verschiedene Cron-verwaltete Prozesse:
4.5.1 Batch-Jobs auf dem LogHost
Alerting Prozeß
Dieser Prozess sorgt für den Abgleich der Alerting-Daten zwischen der
User-Datenbank und dem FMS-System (siehe auch Kapitel 4.4.1.2 )
alerting.sh
Frequenz
User
Pfad
Voraussetzungen
Alle 10 Minuten
o5oper
Dieser Prozess benötigt lesenden Zugriff auf das
Verzeichnis /data/wwwdocs/WEB-INF/
ITBS-Datenfeed
Das Skript getITBS.pl dient zum Download der aktuellen Kursdaten (siehe
auch Kapitel 4.4.1.3 ).
getITBS.pl
Frequenz
User
Pfad
Voraussetzungen
Täglich um 7:00, 16:00, 17:00 und 18:00 Uhr
cms
/home/cms/bin/getITBS.pl
Anschliessen wird mit dem Script rsync-espirit die Verteilung der
aktualiserten Dateien auf die Liveserver angestoßen. (siehe Kapitel
4.4.1.3
rsync-espirit
Frequenz
Täglich um 7:15, 16:15, 17:15 und 18:15 Uhr
User
cms
Pfad
/home/cms/bin/rsync-espirit
Voraussetzungen
Logfile-Bearbeitung
Für die Statistik-Auswertungen der Webserver werden die LogDateien der
Liveserver auf dem Loghost gesammelt.
(siehe Kapitel 4.5.1)
preparelogs.sh
Frequenz
User
Pfad
Voraussetzungen
Stündlich um 0:45, 1:45, 2:45, etc. Uhr
Cms
/home/cms/bin/prepareLogs.sh
66
4.5.2 Batch-Jobs auf dem Datenbankserver
Backup
dbbackup.sh
Frequenz
User
Pfad
Voraussetzungen
4.6
Täglich um 2:00 Uhr Nachts
oracle
/export/home/oracle/cron/dbbackup.sh
Archivierung
Bei jedem Deployment über das Backend (Ausführung des Skriptes
/data/apache/htdocs/cgi-bin/rsync-patagon.cgi) wir ein Tar-Archiv des
Verzeichnisses /data/cms/deployed erstellt und unter dem Namen
dep.`date +%Y%m%d%k%M%S`.tgz
in /data/cms/archive abgelegt.
Die Größe eines Archives beträgt aktuell ca. 25 Megabyte. Deshalb muß das
Archiv in regelmässigen Abständen geleert werden, indem man z.B. die
Dateien auf CD brennt.
Das Verzeichnis /data/espirit-data wird von /home/cms/bin/rsync-espirit
auf die Rechner santanderbkg-0(1-3):/data/wwwdocs/e-spirit/data verteilt.
Die übertragenen Daten werden unter /data/cms/archive/espirit.`date
+%Y%m%d%k%M%S`.tgz
abgelegt (siehe Kapitel 4.4.1.3 ).
4.7
Email Adressen
Folgende Emailadressen sind bei Opus5 für das Projekt eingerichtet:
• [email protected]
für Network & Systemadministration
• [email protected] für Applications Bugs & Administration
• [email protected] Alias für application
für Redaktionelle Themen & CMS
für Bedienhinweise und
Endkundenrequests
für Notfälle jeder Art
Topf für [email protected]
Mülleimer
4.8
Sonstige manuelle Prozesse
In regelmäßigen Abständen müssen Verzeichnisse mit den Logdateien
aufgeräumt/archiviert werden (siehe Angaben der Logfiles in den einzelnen
Anwendungen), z.B. die Backups in /data/cms/archive.
5
Störungsbehebung und Service-Level
5.1
Fehlertypen
5.2
Fehlerbehebung
5.3
Intrusion Incident
5.4
Desaster Recovery
67
6
Versionsübersicht
Version
0.1
Datum
16.07.01
0.2
17.8.01
Bearbeitet von
Johannes Faassen
Initialversion
Thomas Rohnke, Tomas
Herrmann, Gesine Schröter
68

Betriebskonzept Website und zugehörige Applikationen

Transcrição

Documentos relacionados

Alukompletträder

IntersoluteCMS

DMSJ Vorkampf in Dortmund Mengede

16 ZOLL CMS C9 CB CB MATTSCHWARZ

Dissertationspreis zur Erhaltung wandernder Tierarten 10.000 EURO

Prospekt des CMS Pflegewohnstift Wattenscheid

Firmenfolder - Zirbenland Steiermark

CMS begleitet Freiberger Wohnungsgesellschaft bei

thementag am 22. november 2016 in leipzig

Nachlese 14. TT Gerümpelturnier