Coding locally and testing on a remote server, is often troublesome.
For example, forgetting to update the server results in useless tests.
Easiest way is to automatically synchronize the wanted folders.

For Windows I use WinSCP, which allows to easily to keep a remote directory updated.
For Linux, there is a script from Lukas Meyer:

  • livesync
    #!/bin/bash
    #infinite loop, we can end the script hitting ctrl+c
    #define options as array
    declare -a options#set first empty position with new value
    options[${#options[*]}]=”site1″;
    options[${#options[*]}]=”site2″;
    options[${#options[*]}]=”site3″;while [ true ] ; do
    #we create a menu to select which site to update
    select site in “${options[@]}” ; do
    #based on the selection, the syncscript with the proper arguments is called
    case ${site} in ${options[0]})
    syncscript /site1/local/folder server_ip1 username1 password1 /var/www ;
    ;;
    (site2)
    syncscript site2/local/folder server_ip2 username2 password2 site2/remote/folder ;
    ;;
    (site3)
    syncscript site3/local/folder server_ip3 username3 password3 site3/remote/folder ;
    ;;
    esac;
    done
    done
  • syncscript
    #!/usr/bin/expect -f
    #the she bangs line, to find out the path to expect on your system, type "which expect" on the shell
    #we get the command line arguments
    set localfolder [lrange $argv 0 0]
    set server_ip [lrange $argv 1 1]
    set username [lrange $argv 2 2]
    set password [lrange $argv 3 3]
    set remotefolder [lrange $argv 4 4]#this disables the timeout, so our script waits as long as it takes for the transfer
    set timeout -1
    #this calls rsync based on the command line args
    spawn rsync -r -a -v $localfolder $username@$server_ip:$remotefolder –exclude .svn
    #this avoids that if the output is to large, the earlier bytes won’t be fotgotten
    match_max 100000#we’re expecting the password prompt, we use a pattern so it can be anything that contains password: or Password
    expect “*?assword:*”
    #after we get the prompt we send the password
    send — “$password\r”
    #then we send a newline to make sure we get back to the command line
    send — “\r”#wait for the end-of-file in the output
    expect eof

Das Ding mit dem XDebug hatten wir ja schon mal… Folgendes hat sich neu ergeben:

  • Launchpad bietet ein php5-xdebug package für Ubuntu Gutsy.
  • Der XDebug lässt sich somit einfach installieren, z.B. in einer VMWare-Appliance
  • Das Eclipse PDT hat einen XDebug-Support integriert.

Die Konfiguration serverseitig ist recht einfach:

xdebug.remote_enable = on
xdebug.remote_host = 192.168.237.1 # ACHTUNG: Das ist die Workstation mit Eclipse

In der Datei /etc/php5/conf.d/xdebug.ini bearbeiten.

In Eclipse muss schliesslich unter “Window” -> “Preferences” der Browser eingestellt werden. Bei Firefox reicht als Parameter ein simples %URL%. Im Debug Dialog muss eine “PHP-WebPage” konfiguration angelegt werden. In der Server-Konfiguration müssen beim Tab “File Mapping” die absoluten Pfade zu den Dateien angelegt werden. Die Online-Hilfe von Eclipse bietet weitere Infos.

Multi-User Environment / Entwickler hinter der Firewall: Für solche Dinge gibts einen Proxy fürs DBGp (Debug Protocol). Dieser muss verwendet werden, wenn der PHP-Server nicht auf den Port des Clients (also den PC mit Eclipse) zugreifen kann, oder wenn mehrere User sich eine Debug-Session teilen möchten.

Hibernate – auch bekannt als “Suspend to Disk” – erfreut sich unter mobilen Benutzern grosser Beliebtheit: Im Büro das Laptop schnell ausschalten, im Zug einfach wieder arbeiten, im Bus das Laptop im Rucksack, und im Zuhause schnell noch die Arbeit beenden. Wohlgemerkt: Emails oder Briefe schreiben sich so ohne Speichern. Da immer der momentane Systemzustand wiederhergestellt wird.

Einziger Nachteil unter Ubuntu: In der Default-Einstellung braucht ein Suspend fast so lange wie ein Start.

Schneller gehts mit dem Tool uswsusp und dieser Anleitung.

Eine recht einfache Anleitung zur Installation von XDebug findet man ja schnell. Da jedoch php5-dev installiert werden muss, wirds wohl auch schon bald von der codeBase ein .deb geben. Wir wollen keine Development-Pakete auf unseren Servern, die enthalten Kompiler und machen das System deshalb unsicher.

Was der freie Debugger sonst noch so kann, finden Sie auf der XDebug-Homepage raus.

Auf Remote Debugging, und die Integration in Eclipse kommen wir noch zu sprechen… versprochen.

FTP ist unsicher. Nicht nur alle Daten, sondern auch alle Passwörter / Benutzernamen werden in Klartext übermittelt.

Mit SSL oder TLS verschlüsselt werden aber sowohl die Daten, als auch die Credentials verschlüsselt übermittelt. Wir verwenden den Proftpd. Eine gute Anleitung wie man diesen verschlüsselt findet sich hier: http://www.diegosblog.de/2007/05/13/proftpd-ftps/

Einige Ubuntuspezifische Änderungen brauchts aber trotzdem:

Schlüssel generieren

openssl req -new -x509 -days 365 -nodes -out /etc/ssl/certs/proftpd.cert.pem -keyout /etc/ssl/certs/proftpd.key.pem

Server Konfigurieren

TLSEngine on
TLSLog /var/log/proftpd-tls.log
TLSProtocol SSLv23
TLSOptions NoCertRequest
TLSRSACertificateFile /etc/ssl/certs/proftpd.cert.pem
TLSRSACertificateKeyFile /etc/ssl/certs/proftpd.key.pem
TLSVerifyClient off

Zertifikat erstellen folgt später.