Bernhard Häussner
Tags: Artikel mit dem Tag «Shell» durchstöbern

Howto: PHP5.3 parallel zu PHP5 installieren

27.10.2009, 17:49

Wenn man die neuen PHP-5.3-Funktionen testen will, aber trotzdem für die meisten Projekte aus Kompatibilitätsgründen eine ältere PHP(5)-Version benutzen will, kann man PHP 5.3 parallel als CGI-Modul installieren. Dazu sind folgende Schritte möglich:

Zunächst benötigt man den Quelltext (Sourcecode) der aktuellen php5.3-stable Version. Er ist zu finden auf der PHP-Download-Seite bzw. Version 5.3.0 kann so direkt heruntergeladen werden:

wget http://de2.php.net/get/php-5.3.0.tar.gz/from/this/mirror
tar xzfv php-5.3.0.tar.gz
cd php-5.3.0/

Dann muss die PHP-Installation konfiguriert werden. Dazu benutzt man zunächst in der Ausgabe von phpinfo() das "Configure Command" als Basis. In diesem ändert man dann in den Dateipfaden php5 zu php53 und man setzt --bindir=/usr/bin/php53, um Konflikte mit anderen php5-Binaries zu vermeiden. Das sieht z.B. so aus:

./configure --prefix=/usr/share/php53\
 --datadir=/usr/share/php53\
 --mandir=/usr/share/man\
 --bindir=/usr/bin/php53\
 --with-libdir=lib64\
 --includedir=/usr/include\
 --sysconfdir=/etc/php53/apache2\
 --with-config-file-path=/etc/php53/apache2\
 --with-config-file-scan-dir=/etc/php53/conf.d\
 --enable-libxml\
 --enable-session\
 --with-pcre-regex=/usr\
 --enable-xml\
 --enable-simplexml\
 --enable-filter\
 --disable-debug\
 --enable-inline-optimization\
 --disable-rpath\
 --disable-static\
 --enable-shared\
 --with-pic\
 --with-gnu-ld

Eine Liste mit allen Optionen zeigt ./configure --help. Das Konfigurieren überprüft alle Einstellungen und wird eine Weile laufen - und meistens nicht beim ersten Mal klappen, was meistens bedeutet, dass --with-xyz verwendet wurde, ohne dass die entsprechenden Libraries gefunden wurden. Dann muss man das Modul deaktivieren oder nach einer Lösung googeln/bingen. Manchmal fehlen auch Header, welche, je nach Distribution, in einem Paket ähnlich wie [lib]xyz-dev[el] zu finden sind.

Als nächstes wird das ganze kompiliert und (als root/superuser) die neue PHP-Version installiert:

make
# optional, dauert, findet aber Fehler:
make test
# bringt die Dateien an ihren Platz: 
sudo make install

Jetzt muss noch Apache über das neue CGI-Modul informiert werden. Dazu müssen die folgenden Konfigurationen gesetzt werden (z.B. elegant in einer neuen Datei /etc/apache2/conf.d/php53cgi.conf):

# Damit mod_mime die neue Dateierweiterung erkennt:
AddHandler php53-cgi .php53
# Damit die Binaries aufgerufen, nicht versendet, werden:
ScriptAlias /bin-php53 /usr/bin/php53/
# Was eigentlich passieren soll:
Action php53-cgi /bin-php53/php-cgi
# Und noch ein paar Einstellungen für die Binaries:
<Directory /usr/bin/php53>
    # Kein .htaccess:
    AllowOverride None
    # CGI aktivieren, softlinks folgen
    Options +ExecCGI +FollowSymLinks
    # normalerweise ist der Zugriff auf alle „sonstigen“ Dateien gesperrt, 
    # daher hier wieder freigeben: 
    Order allow,deny
    Allow from all
</Directory>

Zum Testen kann man z.B. eine phpinfo.php53-Datei anlegen und man sollte die neue PHP-Verion angezeigt bekommen. Auf dieser Info-Seite kann man dann prüfen, ob alle Module verwendbar sind, die Zeitzone gesetzt ist und anderen potentielle Konfigurationsfehler auf die Schliche kommen. PHP 5.3 wird auch seine eigene php.ini in /etc/php53/apache2/php.ini verwenden, wohin man vielleicht zunächst die alte Konfigurationsdatei kopieren will.

# php.ini replazieren:
sudo cp /etc/php5/apache2/php.ini /etc/php53/apache2/php.ini
# im Webroot phpinfo mit namespace-Spielerei anlegen :)
echo "<?php namespace YEEES; phpinfo();" > phpinfo.php53

Nach den Schritten dieses Tutorials dürfte dann PHP 5.3 mehr oder weniger optimal laufen, ohne dass die Funktion alter Scripte eingeschränkt werden muss, und es lässt sich einfach die Interkompatibilität zwischen den Versionen testen.

Keine Garantie, Verwenden auf eigenes Risiko.

Edit 2009-10-28: On-the-fly zu PHP5.3 Wechseln

Das ständige Umbenennen von Dateien kann natürlich sehr mühsam sein. Leicht wechselt man ganze Verzeichnisse zu PHP5.3 indem man folgendes in ihrer .htaccess-Datei einfügt:

AddHandler php53-cgi .php

So kann man dann auch zum Testen schnell den ganzen Server zwischen den Versionen wechseln.

Kommentare: 7 Einträge

VNC mit openSUSE oder Debian Linux (Howto)

22.10.2009, 09:13

Die Verwendungsmöglichkeiten einer Remote-Desktop-Lösung reichen von Fernadministration bis Support. VNC erlaubt den Fernzugriff auf graphische Benutzeroberflächen. Eine Kurzanleitung zur Installation von VNC-Server und -Client unter openSUSE und/oder Debian:

Server

Zunächst benötigt man auf dem Server (der Computer dessen Bildschirm übertragen werden soll) einen VNC-Server, wie z.B. x11vnc:

sudo zypper install x11vnc
#oder Debian:
sudo aptitude install x11vnc

Als nächstes legt man eine Passwort-Datei an, in der das Passwort für den Fernzugriff gespeichert wird:

mkdir ~/.vnc
x11vnc -storepasswd ~/.vnc/passwd
#(fragt nach einem neuen Passowrt)
chmod 0600 ~/.vnc/passwd

Da die Firewall den benutzen Port 5900 blockieren sollte, wird das Passwort nur gebraucht, da sich nicht jeder Benutzer des Server-Computers in den Desktop einklinken können soll. Nun könnte auf dem Server schon der VNC-Server gestartet werden, doch das mache ich dann vom Client:

Client

Zunächst stellen wir sicher, dass es ein VNC-Client installiert ist:

sudo zypper install tightvnc
#oder Debian:
sudo aptitude install xtightvncviewer

Da die Verbindung sicher sein soll und Firewalls umgehen soll, wird das ganze über SSH getunnelt (Mehr zum SSH-Tunnel am Beispiel MySQL), und der Server gleich mit gestartet, durch dieses kleine Script: (Es setzt eine konfigurierte OpenSSH Public Key Authentication voraus)

#!/bin/bash
SSHLOGIN=user@vncserver
ssh -L 5900:localhost:5900 $SSHLOGIN "x11vnc -localhost -display :0 -rfbauth ~/.vnc/passwd" &
sleep 3
vncviewer localhost

Optional kann man auch die SSH-Option -C angeben, die bei Netzwerkverbindungen mit geringer Bandbreite (Internet) die Daten komprimiert und somit alles schneller läuft. Theoretisch.

Arbeitet man auf verschiedenen remote Desktops kann man $SSHLOGIN durch $1 ersetzen und dann das Script mit der passenden User/Server-Kombination für SSH starten.

Das Script verlangt die Eingabe des des oben gesetzten VNC-Passworts, dann müsste der Remote Desktop zu sehen sein.

Kommentare: 5 Einträge

Linux Backup Server

02.08.2009, 13:04
Backup Server

Backup Server

Da die Anzahl „wichtiger“ elektronischer Dokumente, hauptsächlich Rechnungen, wächst, und ich auch sonst nichts vermissen will, sichere ich meine Daten hin und wieder auf einem Backup-Server. Wie ich das mache und was man noch mit einem solchen Server anfangen kann:

Volldatensicherung

Für die komplette Sicherung des /home-Ordners erstelle ich tar-Archive.

Um einfach auf die Backuplaufwerke zugreifen zu können, kann man SMB-Freigaben mounten:

mount -t cifs -o username=bernhard //server/backup /mnt/backup/
#Beispielhafter-Aufruf:
tar -czvf /mnt/backup/pc1/`date +%Y-%m-%d`-amoebes.tar.gz\
 -X /home/amoebe/tarexclude\
 /home/amoebe >> /mnt/backup/pc1/last.log 2>&1

Es geht aber natürlich auch über eine Pipe zu SSH:

tar -czf - -X /home/amoebe/tarexclude /home/amoebe\
 | ssh server "cd /home/bernhard/backup/pc1/\
 && cat - > `date +%Y-%m-%d`-amoebes.tar.gz"

Weil ich der eigenen Samba-(nicht)-Konfiguration kaum vertraue, und ich auch nicht immer 100%ig weiß, was CIFS anrichtet, ist mir SSH lieber. Die Verschlüsselung von SSH kostet zumindest nicht zu viel Zeit - das Backup dauert ohnehin nur rund 7 Minuten bei den gut 2 GB. Und SSH ist fast immer verfügbar, während Samba nicht überall installiert ist.

Da man temporäre Dateien, wie den Mülleimer, nicht zu sichern braucht, kann man sie vom Backup ausschließen. Dazu hat tar eine eingebaute Filterfunktion, die aus einer Datei eine Liste von Mustern auslesen kann, welche Dateien nicht in das Archiv kommen. Für mein OpenSUSE/KDE habe ich mir folgende Excludes für tar zusammengestellt:

/home/amoebe/tarexclude:
.local/share/Trash/files/*
.thumbnails/*
.beagle
.gvfs
*~
*.swp

Inkrementelles Backup

Für größere Datenmengen ist das Vollbackup nicht mehr zu praktikabel, weshalb man nur noch die Änderungen seit dem letzten Backup überträgt. Dazu ist rsync das passende Tool und bedient sich so:

rsync -vaP --exclude=Backups/ -e ssh amoebe@192.168.1.36:/mnt/lib\
 /home/bernhard/backup/lib/
#Allgemein: rsync [Quelle] [Ziel]

rsync kann SSH gleich mit benutzen. Dieser Befehl läuft auf dem Backup-Server z.B. in einem Cron-Job. Er wird die Dateien vergleichen und neue Dateien bzw. veränderte Dateien übertragen. Es wird allerdings kein Archiv erstellt. Mit diesem Befehl halte ich eine Kopie meiner Datensammlung synchronisiert, was bei jedem Durchlauf ungefähr 2 Minuten braucht (bei 57 GB).

Sharing

Ein Vorteil von einem solchen NAS-ähnlichem Backup-Server ist, dass man auch gleich gut Dateien zwischen Computern im Netzwerk teilen kann. So habe ich auf den Server ein Software-Repository, in dem sich duzende von Windows-Installern, jQuery-Plugins und ähnlichem tummeln. Dazu bastelt man zunächst ein Ordner mit Setuid-Bit, welches beim Erstellen von Dateien die Gruppenzugehörigkeit auf die des Ordners setzt. Oder man ändert einen Ordner nachträglich:

chgrp -R sharer /srv/share
find /srv/share/* -type d -exec chmod g+srw {} \;

So kann dann eine ganze Benutzergruppe den Ordner teilen. Eigentlich bräuchte man dazu noch ein nettes Webinterface mit einer Datenbank im Hintergrund, sodass man die Dateien mit Meta-Infos versehen kann und schnell durchsuchen kann.

Freizeit

Leider kein echtes Wärmebild von meinem Computer

Leider kein echtes Wärmebild von meinem Computer

Da der Server die meiste Zeit mehr oder weniger nutzlos herumsteht, lasse ich ihn nebenbei potentielle Primzahlen faktorisieren. Dazu gibt es das Projekt GIMPS, wo auf Distributed Computing gesetzt wird, um riesige Primzahlen zu finden. Man läd sich das Programm mprime herunter und startet es, dann beantwortet man ein paar Fragen und das rechnen kann beginnen. Ungefähr so:

mkdir primes
cd primes/
wget http://mersenneforum.org/gimps/mprime259-linux64.tar.gz
tar xzvf mprime259-linux64.tar.gz
less readme.txt
#Wenn man screen nicht hat, debian:
sudo apt-get install screen
screen
./mprime
# strg+a strg+d lässt das Programm im Hintergrund weiterlaufen („detach“)
screen -r #holt es zurück. 

Etwas skeptisch bin ich damit allerdings noch, da es meine CPUs recht warm (50° C) hält (und damit die Lüfter laut) und auch etwas mehr Strom verbraucht.

http://www.mersenne.org/ - Website von GIMPS

Mehrere SSH-Verbindungen

Wenn man ein paar Computer gleichzeitig benutzt, und ein paar Terminals offen hat, kann es schnell passieren, dass man einen Befehl auf dem falschen Computer ausführt. „Ein Paar“ beginnt hier erfahrungsgemäß wirklich schon bei 2. Daher mache ich meine Remote-Prompts gerne türkis, mit dieser Zeile in der .bashrc:

PS1="\@ \[\033[0;36m\]\u@\\h\[\033[0m\]:\w> "

Da das immer noch nicht eindeutig genug ist, habe ich mir die Terminals auch noch mit unterschiedlichen Farben hinterlegt:

Das geht mit urxvt oder indem man in Konsole ein neues Farbschema anlegt und dann ein neues Profil, für das man bei Befehl den SSH-Befehl eingibt.

SCP und SHH Dateiübertragungsgeschwindigkeit

Irgendwie würde mich interessieren, wieviel SCP und SSH durch die Verschlüsselung langsamer werden. Darum habe ich paar Komponententests des Vollbackups gemacht.

  • Reines Übertragen der Backup-Datei mit scp: 1787MB in 00:50 bei 35.7MB/s
  • Erstellen des Archivs: 1787 MB in 4:51 also 6 MB/s
  • Lesegeschwindigkeit Quelle: 58,5 MB/s (arm)
  • Schreibgeschwindigkeit Ziel: 79,3 MB/s
  • Lesegeschwindigkeit Ziel: 371 MB/s (für Übertragungs-Tests verwendet)
  • Lesegeschwindigkeit über SMB: 48,9 MB/s
  • Netzwerkgeschwindigkeit rund 100MB/s

Es ist also kein Problem die Daten zu verschlüsseln, da das erstellen des Archivs nicht sonderlich schnell ist. Bei einer geringeren Netzwerkgeschwindigkeit, z.B. bei fast Ethernet oder über das Internet würde es sogar ohne archivieren nicht mehr auffallen.

Das sind also meine Tricks, was ich mit dem Server so anstelle.

Kommentare: keine

Javascript Library Builder

31.07.2009, 13:07
JS-Build

JS-Build

Es gibt einige Methoden Javascript auf HTML-Seiten einzubinden. Ein Block im <body>, in onclick-Attributen und ähnlichem, oder als Verknüpfungen im <head> aber am besten in einer externen Datei, die nach dem HTML-Dokument geladen wird. Nur will man beim Entwickeln die einzelnen Javascript-Teile meist in getrennte Dateien legen und auf der Seite dann möglichst viel in eine (am besten möglichst kleine) Datei packen, um Requests zu sparen. Dieses Problem kann der Javascript Library Builder lösen, ein recht kurzes Shell-Script, welches eine Sammlung von .js-Dateien in wenige Dateien minimiert.

Man nehme zum Beispiel eine solche Dateistruktur:

lib/
  php/...
  js_frontend/
    00_jQuery.js
    01_jQ_plugin.js
    02_effekte.js
    licence.txt
  js_backend/
    03_ajaxCalls.js

Der Scriptaufruf wäre so einfach wie:

jslibbuild.sh -o build lib/js* 

Ich habe auf dieser Seite 27 einzelne Dateien, die ich in zwei Javascript Dateien packe, nämlich für die Seite und für das CMS. Diese Beispiel-Dateistruktur würde jetzt in den zwei Dateien js_frontend.min.js und js_backend.min.js im Ordner build resultieren. Der Datei js_frontend.min.js würde zusätzlich nach dem minimieren mit jsmin die Datei licence.txt vorgehängt, sodass z.B. in Kommentaren (die von jsmin geschluckt werden) vermerkte Autorenhinweise erhalten bleiben, was unter anderem bei den CC-Lizenzen nötig ist.

Dazu akzeptiert das Script die optionale Option -l nach der der Name der Lizenz-Dateien angegeben wird. Eine weitere optionale Option ist -c, um das build-Verzeichnis vor dem Anlegen der neuen Dateien zu löschen. Das ist nötig, wenn ein ganzer source-Ordner gelöscht wird, aber dringend zu vermeiden, wenn weitere Dateien im build-Ordner liegen. Hier noch ein Beispiel:

jslibbuild.sh -c -l gpl.txt -o /srv/www/htdocs/js ~/web/lib/js/* 

Das Script benötigt jsmin, steht unter GPLv2+ und kann hier heruntergeladen werden:

Zum „installieren“ einfach in den Ordner ~/bin kopieren. Das Script ist eigentlich ziemlich einfach, kann aber doch einiges an Arbeit ersparen.

Kommentare: keine

MySQL von außen via SSH-Tunnel (und KDE GUI)

28.12.2008, 17:04
Lokaler MySQL-Client 
    |
    |
(verschlüsselte SSH-Verbindung)
    |
    v
MySQL-Server

Als Web-Administrator braucht man oft Zugang zu einem MySQL-Server. Das kann man mit phpMyAdmin machen, doch das ist kaum so sicher und weniger komfortabel wie remote-Zugriff über einen SSH-Tunnel.

Was kann der SSH-Tunnel und wie geht das?

En SSH-Tunnel macht, dass, wenn auf den eigenen Rechner von einem Port zugegriffen wird, dann die Packete über die verschlüsselte SSH-Verbindung von dem Verbundenen Rechner (Gateway) aus wieder an einen Rechner weitergeleitet werden. Der Befehl sieht so aus:

ssh -L lokalerport:zielrechner:zielport sshgatewaylogin@gateway

Siehe auch das Diagramm:

Irgendwer 
    |
    |
(Lokaler Port)
    |
    v
Mein Computer
    |
    |
(verschlüsselte SSH-Verbindung)
    |
    v
Gateway, eingeloggt als SSH-Gateway-Login
    |
    |
(Zielport)
    |
    v
Zielrechner

Im Fall MySQL greife nur ich über irgendeinen Port auf meinen Computer zu. Der Gateway-Rechner und Zielrechner sind der MySQL-Server und der greift auf sich selbst zu und zwar über den MySQL-Port (Standard: 3066). Dann sieht das ungefähr so aus:

ssh -L 7777:127.0.0.1:3306 me@mysqlserver -N -f

In Verbindung mit MySQL am besten immer 127.0.0.1 verwenden, das vermeidet Ärger. Das praktische ist nun, dass man MySQL-Clients auf den eigenen Rechner nun mit der Datenbank auf dem Server verwenden kann. Solche Clients sind z.B. der MySQL-Abfrage-Browser oder der MySQL-Administrator oder sogar ein PHP-Skript, das auf dem eigenen Rechner läuft. Man kann damit also nicht nur die Datenbank mit einem schönen GUI verwalten, sondern auch PHP-Skripte, Templates o.ä. auf dem eigenen Rechner testen, nur eben mit der Datenbank auf dem Server. Das ist besonders praktisch, wenn man in einem nicht-lokalen Team zusammenarbeitet, da dann alle auf eine zentrale (Development-)Datenbank zugreifen und nicht jeder ständig seine Datenbank synchronisieren muss. (Außerdem muss nicht jeder einen MySQL-Server installieren. )

Wie man das verwendet ist auf tsunamihost.ch sehr gut beschrieben, für Windows und unixoide Systeme. Es findet sich sogar ein kleines Script für init.d um den Tunnel bei jedem Systemstart zu aktivieren.

(Update 2010-11-21) Um zum Beispiel ein MySQL-Dump über den SSH-Tunnel auf einen entfernten Datenbankserver aufzuspielen genügt dann dieser Befehl:

cat local_path/to/dump.sql | \
   mysql -u db_user -p -P 7777 -h 127.0.0.1 db_schema

Es ist hier wichtig als Host 127.0.0.1 anzugeben, da sonst eine lokale Socket-Verbindung genutzt wird. Und natürlich den Port, über den der Tunnel läuft. (/Update)

Ich will mir keine Befehle und Ports merken und habe KDE

Dann habe ich noch ein kleines Script im Angebot: Es lässt sich z.B. im Startmenü verknüpfen und wenn man es anklickt öffnet sich ein Dialog, der fragt, ob der MySQL-Tunnel benötigt wird. Ein klick auf „Ja“ und der Tunnel wird gestartet bzw. läuft weiter oder ein Klick auf "Nein" und der Tunnel wird, sollte er laufen, gestoppt. Einfacher geht es nicht, oder? Das Sktipt braucht KDE, da es kdialog verwendet und steht hier zum Download bereit:

Kurz die Konfiguration bearbeiten und in den Ordner ~/bin verschieben und der Tunnel kann jederzeit gestartet werden.

Da das Tunnel Aufbauen von meiner Server Management Software YaSvenT erledigt wird, benutze ich inzischen das Sktipt allerdings fast nicht mehr

Kommentare: keine
 
Χρόνογραφ
© 2008-2017 by Bernhard Häussner - Impressum - Login
Kurz-Link zur Homepage: http://1.co.de/