Die Installation unter Red Hat Linux 8.0.94 (»Phoebe«,
Betaversion zu
Red Hat Linux 9) scheitert -- wie leider so häufig -- an nicht
erfüllten Abhängigkeiten des Paketes:
[root@lx]# rpm -Uvh typo3-3.3.0.i386.rpm
Fehler: Failed dependencies:
libcrypto.so.2 is needed by typo3-3.3.0-1
libssl.so.2 is needed by typo3-3.3.0-1
Die Installation unter
Red Hat Linux 9 (»Shrike«) stellt sich noch schwieriger
dar, da hierfür ein RPM- Paket gar nicht erst bereitgestellt wird.
Ersatzweise man auf Lars Leuchters Automatic Build Script in
Version 2.6 ausweichen:
www.lleuchter.de/typo3.html,
typo3.sunsite.dk/LAMP/README.txt.
Das ursprünglich von Jamie Becker entwickelte Skript existiert in
drei Varianten:
Das Skript wurde unter Red Hat Linux 8.0 entwickelt, sollte aber auch
auf SuSE- oder Mandrake- Distributionen ausführbar sein; es benötigt
etwa 300 MB freien Speicherplatz im temporären Installationsverzeichnis
/typo3install. Installiert werden folgende Anwendungpakete:
- Apache 2.0.47
- libJPEG 6b
- libTIFF v3.5.7
- FreeType 1.3.1
- GD 1.8.3 patched for GIF
- ImageMagick 4.2.9
- PHP 4.3.3
- Typo3 3.5.0
- CURL-7.10.7
- GETTEXT-0.12.1
- LIBPNG-1.2.5
- PDFLIB-5.0.1
- ZLIB-1.1.4
- MySQL 4.0.15 Server
- MySQL 4.0.15 Development
- MySQL 4.0.15 Client
- MySQL 4.0.15 Shared
- mod_perl (2.x)
Ein eventuell installiertes MySQL sollte vor dem Aufruf des Skripts
vollständig deinstalliert werden:
rpm -e --nodeps mysql mysql-server mysqlclient9 mysql-devel
Dasselbe gilt für Apache und PHP:
rpm -qa |grep php and rpm -qa | grep apache
Ausserdem wird ein geeigneter C-Compiler vorausgesetzt, der über
$PATH erreichbar sein muss -- andernfalls stirbt das Skript nach dem
Download der 49 Installationsdateien; das steht weder auf der Website
noch im README, und natürlich könnte das Skript diese Überprüfung auf
gcc auch vor dem Download vornehmen, aber nein, wir
betreiben ja Linux...
Eine eventuell bereits vorhandene MySQL- Installation und/oder
Datenbanken werden übrigens von dem Skript überschrieben, wenn sie sich
in /var/lib/mysql befinden; falls sich da wichtige Daten
befinden, sollte man die rechtzeitig manuell in Sicherheit bringen. Auch
das könnte man natürlich über die Paketverwaltung von Distributionen wie
Red Hat oder Debian erledigen, aber -- ich sagte es ja schon -- wir
betreiben ja Linux...
Nachdem wir also den gcc nachinstalliert haben können
wir install-all-sunsite.sh noch einmal ausführen (nein, die
heruntergeladenen Dateien werden nicht zwischengespeichert und
können beim nächsten Versuch nicht erneut genutzt werden). Ja,
wir betreiben Linux...
Das sieht dann während des Downloads, den man bei T-DSL rund ca. 20
Minuten lang bewunden kann, etwa folgendermassen aus:
...
19:36:47 (31.67 KB/s) - »databases.tar.gz« gespeichert
[465581/465581]
--19:36:47--
http://typo3.sunsite.dk/LAMP/freetype-1.3.1.tar.gz
=> `freetype-1.3.1.tar.gz'
Auflösen des Hostnamen »typo3.sunsite.dk«.... fertig.
Verbindungsaufbau zu typo3.sunsite.dk[130.225.247.92]:80...
verbunden.
HTTP Anforderung gesendet, warte auf Antwort... 200 OK
Länge: 1,427,072 [application/x-tar]
100%[============================>] 1,427,072 39.10K/s ETA 00:00
19:37:26 (39.10 KB/s) - »freetype-1.3.1.tar.gz« gespeichert
[1427072/1427072]
--19:37:26--
http://typo3.sunsite.dk/LAMP/gd-1.8.3gif_t3.tar.gz
=> `gd-1.8.3gif_t3.tar.gz'
Auflösen des Hostnamen »typo3.sunsite.dk«.... fertig.
Verbindungsaufbau zu typo3.sunsite.dk[130.225.247.92]:80...
verbunden.
HTTP Anforderung gesendet, warte auf Antwort... 200 OK
Länge: 291,731 [application/x-tar]
100%[============================>] 291,731 21.46K/s ETA 00:00
19:37:41 (21.46 KB/s) - »gd-1.8.3gif_t3.tar.gz« gespeichert
[291731/291731]
--19:37:41--
http://typo3.sunsite.dk/LAMP/gettext-0.12.1.tar.gz
=> `gettext-0.12.1.tar.gz'
Auflösen des Hostnamen »typo3.sunsite.dk«.... fertig.
Verbindungsaufbau zu typo3.sunsite.dk[130.225.247.92]:80...
verbunden.
HTTP Anforderung gesendet, warte auf Antwort... 200 OK
Länge: 5,727,037 [application/x-tar]
100%[============================>] 5,727,037 41.22K/s ETA 00:00
19:39:59 (41.22 KB/s) - »gettext-0.12.1.tar.gz« gespeichert
[5727037/5727037]
...
Wenn der Download dann noch einmal geklappt hat und der gcc
in $PATH gefunden wurde, werden erstmal alle Binaries neu
compiliert. Das wollen wir eigentlich gar nicht -- wir benutzen ja die
paketbasierte Distribution Red Hat Linux nicht ohne Grund -- aber sei's
drum. Nach langer Wartezeit scheitert das Build-Skript dann natürlich
wieder:
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Building PHP binary
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
creating cache ./config.cache
checking host system type... i686-pc-linux-gnu
checking for gcc... gcc
checking whether the C compiler (gcc ) works... yes
checking whether the C compiler (gcc ) is a cross-compiler... no
checking whether we are using GNU C... yes
checking whether gcc accepts -g... yes
checking whether gcc and cc understand -c and -o together... yes
checking how to run the C preprocessor... gcc -E
checking for AIX... no
checking if compiler supports -R... no
checking if compiler supports -Wl,-rpath,... yes
checking for ranlib... ranlib
checking whether ln -s works... yes
checking for gawk... gawk
checking for bison... no
checking for byacc... no
configure: warning: You will need bison if you want to regenerate
the PHP parsers.
checking for flex... lex
checking for yywrap in -ll... no
checking lex output file root... ./configure: line 2373: lex:
command not found
configure: error: cannot find output from lex; giving up
Aha, diesmal fehlen bison und byacc.
Eigentlich wollten wir auf unserem Webserver Websites hosten und keine
kompletten GNU- Entwicklungsumgebungen installieren, aber -- wie könnte
man es vergessen -- wir betreiben ja Linux... Ach ja, natürlich könnte
das Skript diese Überprüfung auf bison und
byacc auch vor dem Download vornehmen, aber nein, wir
betreiben ja Linux... (harr!)
Also, auf ein neues, und das -- wie ich mittlerweile sagen würde --
wirklich strunzdumme install-all-sunsite.sh ein drittes Mal
ausgeführt...
Zunächst werden einige RPMs installiert:
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Installing required RPMs
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Warnung: mysql-client-4.0.i386.rpm: V3 DSA signature: NOKEY, key ID
5072e1f5
Preparing... ########################################### [100%]
1:MySQL-client ########################################### [100%]
Warnung: mysql-devel-4.0.i386.rpm: V3 DSA signature: NOKEY, key ID
5072e1f5
Preparing... ########################################### [100%]
1:MySQL-devel ########################################### [100%]
Warnung: mysql-shared-4.0.i386.rpm: V3 DSA signature: NOKEY, key ID
5072e1f5
Preparing... ########################################### [100%]
1:MySQL-shared ########################################### [100%]
Warnung: mysql-server-4.0.i386.rpm: V3 DSA signature: NOKEY, key ID
5072e1f5
Preparing... ########################################### [100%]
1:MySQL-server ########################################### [100%]
Installing all prepared tables
031011 20:02:44 /usr/sbin/mysqld: Shutdown Complete
PLEASE REMEMBER TO SET A PASSWORD FOR THE MySQL root USER !
This is done with:
/usr/bin/mysqladmin -u root password 'new-password'
/usr/bin/mysqladmin -u root -h lx password 'new-password'
See the manual for more instructions.
NOTE: If you are upgrading from a MySQL <= 3.22.10 you should run
the /usr/bin/mysql_fix_privilege_tables. Otherwise you will not be
able to use the new GRANT command!
Please report any problems with the /usr/bin/mysqlbug script!
The latest information about MySQL is available on the web at
http://www.mysql.com
Support MySQL by buying support/licenses at https://order.mysql.com
Starting mysqld daemon with databases from /var/lib/mysql
031011 20:02:44 mysqld ended
Warnung: mysql-bench-4.0.i386.rpm: V3 DSA signature: NOKEY, key ID
5072e1f5
Preparing... ########################################### [100%]
1:MySQL-bench ########################################### [100%]
Warnung: mysql-embedded-4.0.i386.rpm: V3 DSA signature: NOKEY, key
ID 5072e1f5
Preparing... ########################################### [100%]
1:MySQL-embedded ########################################### [100%]
...
Natürlich bricht das Skript auch diesmal wieder ab:
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Building PHP binary
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
creating cache ./config.cache
checking host system type... i686-pc-linux-gnu
checking for gcc... gcc
checking whether the C compiler (gcc ) works... yes
checking whether the C compiler (gcc ) is a cross-compiler... no
checking whether we are using GNU C... yes
checking whether gcc accepts -g... yes
checking whether gcc and cc understand -c and -o together... yes
checking how to run the C preprocessor... gcc -E
checking for AIX... no
checking if compiler supports -R... no
checking if compiler supports -Wl,-rpath,... yes
checking for ranlib... ranlib
checking whether ln -s works... yes
checking for gawk... gawk
checking for bison... bison -y
checking bison version... 1.35 (ok)
checking for flex... lex
checking for yywrap in -ll... no
checking lex output file root... ./configure: line 2373: lex:
command not found
configure: error: cannot find output from lex; giving up
Jetzt wird's so langsam kompliziert, ich habe keine Ahnung, was
lex oder yywrap ist. Und eigentlich wollte ich auch
nicht zum Experten für GNU-Entwicklungssysteme werden. Aber, antürlich,
wir betreiben ja Linux...
Pakete für 'lex' oder 'yywrap' gibt es bei Red Hat nicht, probieren
wir es mal mit flex und starten install-all-sunsite.sh ein
viertes Mal. Mittlerweile wurstelt dieses dümmliche Skript über
anderthalb Stunden, obwohl die ganze Angelegenheit mit vernünftigen
Paketen -- wie bei der Installation von
Typo3 unter Debian GNU/Linux oder Windows -- eine Angelegenheit von
wenigen Minuten wäre. Nun ja, wenn man effizient arbeitet muss, wird man
wohl nicht grundlos eher unter anderen Betriebssystemen arbeiten. Aber
wir betreiben ja Linux...
Sehr viel später -- das Übersetzen dauert selbst auf einem
Dual- Athlon signifikant lange, rechnen sie zumindest mit einer guten
dreiviertel Stunde -- kommt dann endlich mal eine angenehme
Meldung:
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Installation finished!
If you like to proceed with your Typo3 enviroment, please go to
http://localhost:81 or
http://yourdomain.com:81
http://ipaddress:81
depending on your enviroment you installed this script on.
Latest version always available at
http://www.lleuchter.de/typo3.html
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Das machen wir auch gleich mal:
Erfreulich, zumindest ein erster Erfolg. Wir sollten demnach jetzt
u.a. folgende Seiten aufrufen können:
- Typo3 Testsite,
- Typo3 Administration Interface (login: admin, password:
password),
- Typo3 Installation Tool (password: joh316),
- PHP Information page.
Gut, rufen wir also die Testsite aus
(http://192.168.101.123:81/testsite/):
Die Testsite fühlt sich nicht gut: "Database Error. The current
username, password or host was not accepted when the connection to the
database was attempted to be established!"
Hm, das klappt also nicht. Dann vielleicht das Administration
Interface?
Auch das Administration Interface mach blau: "The current
username, password or host was not accepted when the connection to the
database was attempted to be established! Database Error".
Nun, diese Typo3- Installation ist ja wirklich grandios
vorkonfiguriert.
Schade eigentlich. Läuft eigentlich PHP?
Schauen wir mal, was das Installation Tool macht:
Sieht besser aus, es gibt einen Warnhinweis...
...und erlaubt den Login mit dem Default- Passwort.
Und endlich kommen wir ins Install Tool!
Vor den Lohn hat der Herr ja bekanntlich den Schweiss gesetzt (wir
sind ja nicht zum Vergnügen hier, wir betreiben ja Linux...), deshalb
stimmt die Datenbankverbindung natürlich nicht.
Nun können wir entweder anfangen zu raten -- 'mysql' wäre ja auch zu
einfach für Linux, oder in den Eingeweiden von MySQL herumstochern, um
diese Informationen auf nachvollziehbare Werte zu setzen.
Jetzt würde man beispielsweise mysql -u root oder an der
MySQL- Kommandozeile SET PASSWORD FOR root = PASSWORD("geheim");
aufrufen, um ein definiertes Passwort zu erhalten. Aber wir betreiben ja
Linux, und das grandios selbstgebaute MySQL sagt:
[root@lx /]# mysql -u root
ERROR 2002: Can't connect to local MySQL server through socket
'/var/lib/mysql/mysql.sock' (2)
So, uns spätestens jetzt, nach rund drei Stunden völlig sinnloser
Bastelei kommt einem der kalte Kaffee hoch. Wie hiess es doch gleich in
der Beschreibung: "Automatic Build Script for Linux/Unix Systems -
now includes MySQL 4.0.15, PHP 4.3.3, Apache 2.0.47 and mod_perl 2.x
ready configured Typo3 and databases". Total toll vorkonfiguriert,
dieses Typo3 und seine Datenbanken.
Um Typo3 dann produktiv einsetzen zu können -- wenn das Compiliern
denn klappt --, müsste der Apache dann noch auf Port 80 in der
/usr/local/typo3/conf/httpd.conf umgebogen werden. Der Pfad
entspricht natürlich keinerlei Dateikonventionen, und die gesamte
Paketverwaltung zerbricht spätestens jetzt, nach dem erfolgreichen
Ausführen des Installationsskripts, aber wir betreiben ja eben Linux...
Uns beschäftigt aber jetzt eher das Problem, wie man diesen ganzen
Müll aus der Red Hat- Installation wieder wegbekommt. Noch einmal: Die
Selbstbauerei zerstört das brauchbare Paketmanagement von Red Hat Linux,
und jetzt ist die Kacke wirklich am dampfen...
Wenden wir uns angenehmeren Dingen zu, nämlich der Konfiguration von
Typo3 unter einer funktionierenden Installation (Debian
GNU/Linux).
Weiterlesen: Konfiguration
von Typo3.
Kefk Network :
GNU/Linux |
About |
Wiki.
Red Hat Linux:
EUR
49,90
