Sphere 56b Linux Installation

Rund um die Technik von 55R + 56

Moderator: Mods - Sphere

Antworten
Nachricht
Autor
Silarion_

Sphere 56b Linux Installation

#1 Beitrag von Silarion_ » 10 Apr 2008 10:52

Angeregt durch das Post „Sphere Installation für Windows Dummies“ von Nazghul, ( http://uodev.de/viewtopic.php?t=5001 ) gibt es hier nun die Beispiel Installation für einen Sphere Linux. Dies ist nicht die ultimative richtige Installation, sondern dient nur als Beispiel. Es soll kein Tutorial sein, sondern nur ein Einblick, wie ich Sphere Linux auf den vServer gebracht habe. Ein Linux Server braucht immer Linux Kenntnisse. (O.k. meine sind nach Jahren der Pause mehr miserabel wie sonst was, aber ich hab die Gurke ans laufen bekommen. *g* )

Unser Opferserver ist ein vServer von 1&1 mit Suse 10.1 (64bit) und Plesk. (Gleich vorweg: Dieser Server ist für mittlere und große Shards nicht geeignet, da zu wenig Leistung.)

Die Vorbereitungen wurden über ein Windows-Pc gemacht.


- Vorbereitungen die Erste:


Wir fragen die Suchmaschine unseres Vertrauens nach den Programmen:

Putty <- Das ist unsere Konsole um z.B. Programme auf dem Server zu starten/installieren

WinSCP <- hiermit laden wir die Dateien auf den Server und erstellen Verzeichnisse

sowie den Linux Paketen (für Suse 10.x):

mysql-shared-32bit-5.0.26-16.x86_64.rpm <- Unser 64bit System braucht für Sphere 32bit Mysql

zlib-1.2.3-13.i586.rpm <- um 32bit Mysql installieren zu können wird das hier benötigt.


- Vorbereitung die Zweite:

Wir besorgen uns den aktuellen Sphere Server für Linux in der Version 56b (siehe Anleitung für Nazghul) und entpacken diese in den selbsterstellen Ordner: sphere. (Tip: unter Linux Ordner und Dateien immer klein schreiben)

Durch unseren Tip erkennen wir schon ein kleinen Fehler: die Sphere.ini ist groß geschrieben, bitte umbenennen in sphere.ini

Nun befolgen wir vom Nazghul Tutorial folgende Schritte (achtet drauf, das wir ein anderes Verzeichnis benutzen):

Schritt 6, 7, 8, und 9

Und erstellen so die noch fehlenden Ordner und Dateien, bzw kopieren die .mul Dateien in unseren Ordner und ändern die sphere.ini.


- Vorbereitung zum Dritten:



(Als Voraussetzung für diese Vorbereitung ist, das beim vServer von 1&1 unter Suse 10.1 (64bit) im Verzeichnis /usr/lib keine libmysqlclient.so.15 Dateien vorhanden sind. Diese sind im Ordner /usr/lib64 und können von sphere nicht benutzt werden. Wir müssen also erst die 32bit Dateien installieren. Kopieren der 64bit Dateien erzeugt Fehlermeldungen. Finger davon weg!)

Wir starten WinSCP, geben die IP des vServers an, sowie root als Benutzername und das Passwort.

Wir wechseln das Verzeichnis mit Doppelklick auf .. (die 2 Punkte) und befinden uns im Hauptverzeichnis.

Dann Doppelklick auf das Verzeichnis /home

Und laden dort die 2 RPM Dateien hin die wir am Anfang gesucht und downgeloadet hatten.

(Da WinSCP sich fast so bedienen lässt wie z.B. WS_FTP war das bisher einfach)

Unter Linux müssen Dateien bestimmte Rechte haben zb. Lesen, schreiben, ausführen. Für unsere Dateien müssen wir das noch ändern. Die 2 RPM Dateien mit Rechts anklicken, Eigenschaften und bei root die Rechte r, w, und x ein Haken machen. Nun sind die Dateien ausführbar.

Wir starten Putty, root, pw sollte klar sein.

Schau an, eine schwarze Konsole *g*

Nun müssen wir wieder ins /home Verzeichnis wechseln. Wer Dos benutzt hatte, der kennt die Befehle dafür:

.. <- ein Verzeichnis nach oben

dir <- listet das Inhaltsverzeichnis

cd home <- wechselt in das Verzeichnis /home (Change Directory)

dir <- noch mal das Inhaltsverzeichnis, um zu sehen ob wir richtig sind.

Unsere 2 RPM Dateien sollten nun grün aussehen. Wenn ja, dann sind Sie ausführbar, wenn Nein Rechte mit WinSCP ändern.

Da es unter Linux Abhängigkeiten zu anderen RPM Paketen gibt, müssen wir nun als erstes die Datei zlib-1.2.3-13.i586.rpm installieren, bevor wir die 32bit Version von mysql installieren können.

Der Befehl ist:

rpm –i zlib-1.2.3-13.i586.rpm

Auf unserem vServer gab es nun keine Fehlermeldung daher installieren wir das nächste:

rpm –i mysql-shared-32bit-5.0.26-16.x86_64

Auch hier gab es keine Fehlermeldung (bin immer noch erstaunt darüber *g*).

Wir nehmen nun wieder WinSCP und schauen im Hauptverzeichnis nach dem Ordner /usr und dort im Ordner /lib nach. Unter anderem sollte die Datei libmysql.so.15 hier nun vorhanden sein.


- Installation von Sphere:


Los geht’s!

Wir laden mit WinSCP unseren sphere Ordner nach /home (Sphere mit dem Muls von ML dürfte so um die 165 Mb groß sein)

Die Datei spheresvr in dem Ordner muß noch die Rechte zum ausführen bekommen (das x bei Root), sowie Schreibrechte für die Ordner save, accounts und logs und die jeweiligen Dateien darin (Das w bei Root).

Wir nehmen Putty und gehen ins /home Verzeichnis und dort in /sphere mit einem

dir

sehen wir ob alles da ist.

./spheresvr

startet nun ganz unspektakulär unseren Server. Der ganze Text wie bei Windowssphere sollte nun kommen und das war es mit der Installation. Sphere lief nun bei mir auf dem 1&1 vServer.


- Besonderes:

Sobald wir Putty schliessen ist auch unsere Sphere ausgeschaltet. Hierzu gibt es noch ein interessantes Thema im Forum:


http://uodev.de/viewtopic.php?t=5088&highlight=putty von Mondrak.


Viel Spaß

Silarion

nazghul

#2 Beitrag von nazghul » 11 Apr 2008 00:33

Zwei Dinge noch:

a) "man screen" erzäht einem, wie man die Sphere quasi im Hintergrund startet und dennoch an die Konsole rankommt (na gut:

Code: Alles auswählen

cd /home/sphere
screen -D -m spheresvr &
Nummer des gestarteten Prozesses (wird ausgegeben) merken, oder bei Bedarf nachlesen, denn mit

Code: Alles auswählen

screen -r <prozessnummer>
kommt man wieder an die Konsole. Auch wenn man zwischendurch aus der Shell ausgelogged war. "STRG-A STRG-D" bringt einen aus der Konsole wieder raus)

b) ich würde GANZ DRINGEND dazu raten, einen eigenen Systemuser "sphere" anzulegen (useradd sphere), dann das Sphere-Installationsverzeichnis diesem User zu übergeben (cd /home/sphere; chown -R sphere . - wenn das Installationsverzeichnis "/home/sphere" ist), dann mit "chmod 4750 sphere/spheresvr" dafür sorgen, dass das Sphere-Binary IMMER (egal, wer es startet) als User "sphere" ausgeführt wird. Sollte einem ein Admin-Account irgendwann mal ge-hijacked werden kann derjenige dann wenigstens außerhalb des Sphere-Ordners keinen Schaden anrichten (was sonst mit dem File-Objekt, oder einfach dank ".set serv.Log=/etc/" trivial wäre)

Stordyr

#3 Beitrag von Stordyr » 11 Apr 2008 07:20

man muss screen übrigens nicht mit prozessnummern nutzen. das geht auch prima mit mnemonischen Namen

Ich glaub
screen -S <name>
und
screen -R <name> für's attachen

und wer nicht weiß, wie er's sauber detacht..
in der Shell des screens einfach STRG+A und dann STRG+D
und wech is das screen

Silarion_

#4 Beitrag von Silarion_ » 11 Apr 2008 10:25

in der Shell des screens einfach STRG+A und dann STRG+D
und beim STRG+D hab ich dann Putty gekillt und komme nach Neustart nicht mehr in screen rein. Das ist aber erst so, seit ich den Ordner an den Benutzer sphere übergeben habe bzw spheresvr immer als benutzer sphere ausgeführt wird (nach Nazghuls Anleitung)

Meine Vorgehensweise (User sphere):

screen -D -m spheresvr &

screen -r

strg+a

strg+d <-- Erzeugt dann Absturz Putty

Neueinloggen

top

spheresvr läuft noch

aber mit screen kein zugriff mehr drauf

*grübel* *grübel* *grübel*

nazghul

#5 Beitrag von nazghul » 11 Apr 2008 15:34

mein Fehler. Nicht strg-D, sondern nur "D" - Putty mag das STRG-D nicht (benutze ein anderes SSH, das da unempfindlicher ist)

Silarion_

#6 Beitrag von Silarion_ » 11 Apr 2008 21:37

Nur D macht aber auch Mist .... Naja hab mal ZOC 5.09 im Test, mächtiges Programm, 10.000 Funktionen die ich nicht brauche. Aber funktioniert Fehlerfrei.

Gibts nicht noch was kleineres, was Freeware ist?

Putty ist ja ein sehr treffender Name .. Putty .. putt ... ist ja nur Version 0.6

Sil

nazghul

#7 Beitrag von nazghul » 11 Apr 2008 21:52

Eban mal mit PuTTY probiert. Läuft absolut schmerzfrei. Könnte sein, dass Deine terminfo - sagen wir: suboptimal ist

und zur Ehrenrettung von PuTTY muss man sagen, dass es weniger Bugs hat also so manches kommerzielle ssh-Programm für ein Heidengeld (fsecure z.B. - mein Gott, was für'n sauteurer Sch***). Mach nicht ein Tool verantwortlich für etwas, das Deine Systemumgebung (ob nun auf Client oder Server) verbockt :)

Antworten