10
Jan 13

Hello world!

Welcome to my blog! :)


19
Mar 13

Schneller Zugriff auf PHP-Programme

Es ist etwas umständlich, auf PHP-Programme immer mit einem vorangestelten php und dem vollständigen Pfad zur Datei zugreifen zu müssen. Um sich das Leben einfacher zu machen, kann man den langen Befehl in einer Bash-Datei wrappen. Diese wird in einem Verzeichnis für ausführbare Programme abgespeichert — und schon fungiert sie als Alias für die PHP-Datei.

Ein Beispiel: Ich möchte die Class Map Generator Utility benutzen. Anstatt jedes Mal

php /lib/ZendFramework/ZF2/bin/classmap_generator.php -w

einzutippen, erstelle ich unter /usr/bin/ eine kleine Bash-Datei mit einem beliebeigen Namen, z.B. “zf2cg”, und folgendem Inhalt:

#! /bin/bash
# echo $*
php /lib/ZendFramework/ZF2/bin/classmap_generator.php "$@"

Die Zeichenkette “$@” legt fest, dass alle an das Bash-Skript übergebenen Argumente an das Unterprogramm (in dem Fall also php) weitergegeben werden sollen. Mit dem hier auskommentierten echo $* können die Argumente ausgegeben werden.

Alles hier Beschriebene bezieht sich auf ein System mit folgenden Parametern:

$ lsb_release -a
No LSB modules are available.
Distributor ID:    Debian
Description:    Debian GNU/Linux 6.0.6 (squeeze)
Release:    6.0.6
Codename:    squeeze

18
Mar 13

Git Commit Message ändern

$ git commit -m "wrong message"
$ git push

ooops!..

$ git commit --amend -m "right message"
$ git push -f

18
Mar 13

PHP Phar Konsolentool auf Debian

PHP Phar kann nicht nur über den PHP-Code, sondern auch als Kommandozeilentool benutzt werden. Die Phar Manual Page beschreibt den Umgang damit. Doch wo bekommt man das Tool? Seit PHP 5.3 ist Phar ein Bestandteil der Standard-PHP-Installation. Für eine Version vor 5.3 musste es noch über PEAR installiert werden. Aber anders, als wenn man PHP selber aus dem Source-Code kompilliert, wird Phar Command Line Tool bei einer Installation von PHP als Paket nicht mitgeliefert. Hier möchte ich zeigen, wie das Phar Tool auf Debian aus dem Quelltext installiert werden kann.

1. PHP-Sourcecode herunterladen

Der PHP-Sourcecode kann von GitHub heruntergeladen werden, z.B. so:

$ cd /tmp/
$ git clone git://github.com/php/php-src.git

2. Makefile

Nun muss der Makefile, der das Phar Comman Line Tool installieren soll, (von hier) in den PHP Source-Code Ordner  heruntergeladen werden.

$ cd /tmp/php-src
$ wget http://pastebin.com/download.php?i=UgpaRda1 -O ./Makefile

Um später beim Kompilieren bzw. Ausführen von make Makefile dem Fehler

Makefile:11: *** missing separator (did you mean TAB instead of 8 spaces?).  Stop.

aus dem Weg zu gehen, muss man alle Leerzeichen-Einrückungen durch echte Tabs ersetzen.

3. Kompilierung

$ mkdir /tmp/phar
$ cd /tmp/php-src
$ make

4. PEAR PHP_Archive

Bei mir wird bei der Kompilierung eine Notice ausgegeben:

$ make
Generating phar.php
Generating phar.phar
PHP Notice:  Undefined index: PATH in /tmp/phar/phar.php on line 707
PHP Stack trace:
PHP   1. {main}() /tmp/phar/phar.php:0
PHP   2. CLICommand->__construct($argc = 19, $argv = array (0 => '/tmp/phar//phar.php', 1 => 'pack', 2 => '-f', 3 => '/tmp/phar//phar.phar', 4 => '-a', 5 => 'pharcommand', 6 => '-c', 7 => 'auto', 8 => '-x', 9 => '\\.svn', 10 => '-p', 11 => '0', 12 => '-s', 13 => '/tmp/php-src/ext/phar/phar/phar.php', 14 => '-h', 15 => 'sha1', 16 => '-b', 17 => '/usr/bin/env php ', 18 => '/tmp/php-src/ext/phar/phar/')) /tmp/phar/phar.php:2089
PHP   3. CLICommand->checkArgTyp($arg = 'p', $i = 11, $argc = 19, $argv = array (0 => '/tmp/phar//phar.php', 1 => 'pack', 2 => '-f', 3 => '/tmp/phar//phar.phar', 4 => '-a', 5 => 'pharcommand', 6 => '-c', 7 => 'auto', 8 => '-x', 9 => '\\.svn', 10 => '-p', 11 => '0', 12 => '-s', 13 => '/tmp/php-src/ext/phar/phar/phar.php', 14 => '-h', 15 => 'sha1', 16 => '-b', 17 => '/usr/bin/env php ', 18 => '/tmp/php-src/ext/phar/phar/')) /tmp/phar/phar.php:189
PHP   4. call_user_func(array (0 => class PharCommand { protected $argc = 19; protected $argv = array (...); protected $cmds = array (...); protected $args = array (...); protected $typs = array (...) }, 1 => 'cli_arg_typ_loader'), '0', array ('typ' => 'loader', 'val' => NULL, 'inf' => '<loader> Location of PHP_Archive class file (pear list-files PHP_Archive).You can use \'0\' or \'1\' to locate it automatically using the mentioned pear command. When using \'0\' the command does not error out when the class file cannot be located. This switch also adds some code around the stub so that class PHP_Archive gets registered as phar:// stream wrapper if necessary. And finally this switch will add the file phar.inc from this package and load it to ensure class Phar is present.', 'required' => FALSE), 'p') /tmp/phar/phar.php:244
PHP   5. PharCommand->cli_arg_typ_loader($arg = '0', $cfg = array ('typ' => 'loader', 'val' => NULL, 'inf' => '<loader> Location of PHP_Archive class file (pear list-files PHP_Archive).You can use \'0\' or \'1\' to locate it automatically using the mentioned pear command. When using \'0\' the command does not error out when the class file cannot be located. This switch also adds some code around the stub so that class PHP_Archive gets registered as phar:// stream wrapper if necessary. And finally this switch will add the file phar.inc from this package and load it to ensure class Phar is present.', 'required' => FALSE), $key = 'p') /tmp/phar/phar.php:244
PEAR package PHP_Archive not installed: generated phar will require PHP's phar extension be enabled.
directorytreeiterator.inc
pharcommand.inc
directorygraphiterator.inc
invertedregexiterator.inc
clicommand.inc
phar.inc

Das PEAR-Paket PHP_Archive kann leicht (nach-)installiert werden:

# pear install PHP_Archive-alpha
downloading PHP_Archive-0.11.4.tgz ...
Starting to download PHP_Archive-0.11.4.tgz (83,047 bytes)
....................done: 83,047 bytes
install ok: channel://pear.php.net/PHP_Archive-0.11.4

Doch auch nach der Installation des Pakets endet (bei mir) die Phar-Kompilierung mit der selben Fehlermeldung. Zugleich funktioniert Phar scheinbar unabhängig von PHP_Archive. Jedenfalls kann ich auch beim deinstallierten PHP_Archive Phar-Archive erstellen und auspacken.

5. Phar von überall erreichbar und ausführabar machen

Dazu verschieben wir das unter <span class="inlineCode">/temp/</span> befindliche Verzeichnis <span class="inlineCode">phar</span> ins <span class="inlineCode">/usr/share/</span> (nicht nötig aber sinnvoll) und erstellen im /usr/bin/ einen Symlink zum <span class="inlineCode">/usr/share/phar/phar.phar</span>.
$ mv phar /usr/share/ln -s /usr/share/phar/phar.phar /usr/bin/phar

Fertig ist die Laube! :)

Alles hier Beschriebene bezieht sich auf ein System mit folgenden Parametern:

$ lsb_release -a
No LSB modules are available.
Distributor ID:    Debian
Description:    Debian GNU/Linux 6.0.6 (squeeze)
Release:    6.0.6
Codename:    squeeze

 

 


08
Mar 13

Git mit mehreren SSH-Users auf Windows-Hostsystem und Linux-Guestsystem (VirtualBox)

Das GitHub HowTo “Generating SSH Keys” zeigt den einfachsten und kürzesten Weg, Git mit GitHub zum Laufen zu bekommen, und ist ein hevorragendes QuickStrart-Tutorial für die Einseiger, die zunächst damit zufrieden sind, dass es überhaupt läuft und sie mit den Standard-Einstellungen clonen und pushen können. So war das auch bei mir. Doch die Ansprüche — meine jedenfalls — an die Arbeitsumgebung wachsen und irgendwann ergab sich für mich folgende Fragestallung:

Ich nutze Windows als Host-System, Debian als Gast-System (VirtualBox VM), habe mehrere Accounts auf GitHub und möchte auf sie (lesend und schreibend) über msysGit  und TortoiseGit auf dem Windows Host-System und über das Standard-Terminal (Gnome Terminal) auf dem Debian Gast-System zugreifen.  Im Folgenden wird gezeigt, wie das geht. Ich nehme als Beispiel zwei imaginäre GitHub-Accounts, aber das Ganze gilt natürlich genauso im Falle eines einzigen bzw. von mehr als zwei Accounts.

0. Ausgangssituation

Es wird vorausgesetzt, dass auf dem Linux-Gastsystem Git und auf dem Windows-Hostsystem Git samt msysGit sowie TortoiseGit installiert ist; ein oder mehrere GitHub-Accounts sind angelegt.

1. SSH-Keys erstellen

Da GitHub es nicht zulässt, ein und den selben SSH-Schlüssel für mehrere Accounts zu verwenden muss zuerst ein Schlüssel(-Paar) je Account erstellt werden. In unserem Fall also zwei. (Davor sollten die ggf. vorhandenen Key-Dateien gesichert werden.) Hier so wie im ganzen Artikel wird msysGit als Windows-Terminal verwendet.

hostuser@hostsystem /usr
$ cd ~/.ssh/
 
hostuser@hostsystem ~/.ssh
$ ssh-keygen -t rsa -C "foomail@foo.com"
Generating public/private rsa key pair.
Enter file in which to save the key (/c/Users/hostuser/.ssh/id_rsa): id_rsa_fookey
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in id_rsa_fookey.
Your public key has been saved in id_rsa_fookey.pub.
The key fingerprint is:
65:e7:25:77:4f:00:c3:9b:56:b2:c4:fe:c8:4a:0d:e8 foomail@foo.com
 
hostuser@hostsystem ~/.ssh
$ ssh-keygen -t rsa -C "barmail@bar.com"
Generating public/private rsa key pair.
Enter file in which to save the key (/c/Users/hostuser/.ssh/id_rsa): id_rsa_barkey
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in id_rsa_barkey.
Your public key has been saved in id_rsa_barkey.pub.
The key fingerprint is:
eb:c9:d8:41:9a:d4:f5:53:b6:9d:f2:3b:7b:8e:96:99 barmail@bar.com

2. Keys auf dem Server / zum GitHub-Account hinzufügen.

Das Kopieren der Schlüssel geht am einfachsten über die Konsole:

hostuser@hostsystem ~/.ssh
$ clip < ~/.ssh/id_rsa_fookey.pub
 
hostuser@hostsystem ~/.ssh
$ clip < ~/.ssh/id_rsa_barkey.pub

3. Hosts einstellen

Testet man nun die Verbindung, wie es im Standard-HowTo steht, scheitert sie mit einem Fehler:

hostuser@hostsystem ~/.ssh
$ ssh -T git@github.com
The authenticity of host 'github.com (207.97.227.239)' can't be established.
RSA key fingerprint is 16:27:ac:a5:76:28:2d:36:63:1b:56:4d:eb:df:a6:48.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'github.com,207.97.227.239' (RSA) to the list of known hosts.
Permission denied (publickey).

Zunächst wird github.com zur Liste der bekannten Hosts bzw. zur ~/.ssh/known_hosts hinzugefügt.

Dann wird ein Verbindungsversuch gestartet -- und der scheitert. Ich erkläre mir das wie folgt: Der SSH-Client sucht zuerst nach Standard-Keyfiles wie id_rsa bzw. id_rsa.pub. Als er sie nicht findet, untersucht er die Datei ~/.ssh/config (falls vorhanden), in der die (Pfade zu den) Key-Dateien auf die Hosts gemappt sind. Findet er die Datei nicht bzw. keinen passenden Eintrag in der Datei, "weiß" er nicht, welcher Schlüssel verwendet werden soll, und kann sich nicht auf dem Server autentifizieren.

Ergo brauchen wir eine Konfigurationsdatei config in ~/.ssh/, und zwar mit folgendem Inhalt:

#foo account
Host github.com-foo
    HostName github.com
    User git
    IdentityFile ~/.ssh/id_rsa_fookey
 
#bar account
Host github.com-bar
    HostName github.com
    User git
    IdentityFile ~/.ssh/id_rsa_barkey

Nun testen wir die Verbindung für jeden der Accounts/Schlüssel und stellen fest, dass sie funktioniert:

hostuser@hostsystem ~/.ssh
$ ssh -T git@github.com-foo
Hi foo! You've successfully authenticated, but GitHub does not provide shell access.
 
hostuser@hostsystem ~/.ssh
$ ssh -T git@github.com-bar
Hi bar! You've successfully authenticated, but GitHub does not provide shell access.

4. Projekt einstellen

Wenn ein Repository schon vor den Spielereien mit mehreren Accounts geclonet wurde, wird die remote.origin.url nun wahrscheinlich micht mehr richtig gesettz sein, nämlich auf die URL:

hostuser@hostsystem ~/Desktop/test/barproject (master)
$ git config --local remote.origin.url
git@github.com:bar/barproject.git

Wie man sieht, fehlt hier hinter URL der mit einem Bindestrich von ihr getrennter Benutzername. Beim Versuch, sich zu autentifizieren, führt es zu einem Fehler:

hostuser@hostsystem ~/Desktop/test/barproject (master)
$ git push
Permission denied (publickey).
fatal: The remote end hung up unexpectedly

Die remote.origin.url kann entweder direkt in der Datei [Projekt-Root]/.git/config oder über git config definiert werden.

Die Struktur der URL zum Repository sieht (im Fall meines Servers) wie folgt aus: git@%Host aus der ~/.ssh/config%:%Projektname%.git. Und für GitHub-Repositories git@%Host aus der ~/.ssh/config%:%GitHub Benutzername%/%Projektname%.git.

hostuser@hostsystem ~/Desktop/test/barproject (master)
$ git config remote.origin.url git@github.com-bar:bar/barproject.git

Nun funktioniert es wieder:

hostuser@hostsystem ~/Desktop/test/barproject (master)
$ git push
Everything up-to-date

5. git clone mit msysGit

hostuser@hostsystem ~/.ssh
$ cd ~/Desktop/
 
hostuser@hostsystem ~/Desktop
$ mkdir test
 
hostuser@hostsystem ~/.ssh
$ cd test/
 
hostuser@hostsystem ~/Desktop/test
$ git clone git@github.com-foo:foo/fooproject.git
Cloning into 'fooproject'...
remote: Counting objects: 572, done.
remote: Compressing objects: 100% (120/120), done.
remote: Total 572 (delta 434), reused 564 (delta 431)
Receiving objects: 100% (572/572), 1.78 MiB | 425 KiB/s, done.
Resolving deltas: 100% (434/434), done.
 
hostuser@hostsystem ~/Desktop/test
$ git clone git@github.com-bar:bar/barproject.git
Cloning into 'barproject'...
remote: Counting objects: 99, done.
remote: Compressing objects: 100% (55/55), done.
remote: Total 99 (delta 31), reused 95 (delta 31)
Receiving objects: 100% (99/99), 284.33 KiB | 281 KiB/s, done.

6. GIT_SSH

Falls dieser Fehler auftritt:

hostuser@hostsystem ~/Desktop/test
$ git clone git@github.com-foo:foo/fooproject.git
Cloning into 'fooproject'...
fatal: The remote end hung up unexpectedly
 
hostuser@hostsystem ~/Desktop/test
$ git clone git@github.com-bar:bar/barproject.git
Cloning into 'barproject'...
fatal: The remote end hung up unexpectedly

liegt es möglicherweise an der Umgebungsvariablen GIT_SSH (die wahrscheinlich auf C:\Program Files\TortoiseGit\bin\TortoisePlink.exe gesetzt sein wird). Diese muss entfernt werden.

7. TortoiseGit

Dazu ist nicht viel zu sagen. Funktioniert.

8. Virtuelle Maschine einstellen

Die auf dem Host-System unter ~/.ssh/ befindlichen Dateien (Private und Public Key Files sowie config und known_hosts) müssen nach ~/.ssh/ des Hosts kopiert werden.

Sollte dieser Fehler auftreten:

root@devvm:~/Desktop/test# git clone git@github.com-bar:bar/barproject.git
Cloning into barproject...
Bad owner or permissions on /root/.ssh/config
fatal: The remote end hung up unexpectedly

müssen eine oder mehrere Eigenschaften der [chmod 700 config] korrigiert werden: Benutzer muss auf root, Benutzergruppe ebenfalls auf root und das Zugriff-Level auf 700 gesetzt werden.

root@devvm:~/.ssh# chown root:ax config
root@devvm:~/.ssh# chown root:root config

9. ~/.ssh/ als Shared Folder

Um sich das Leben einfacher zu machen und nicht an die Keys denken zu müssen, wenn man seine VM jemandem zur Verfügung stellt, kann man das ~/.ssh/ Verzeichnis komplett ins Host-System "auslagern", indem man es als Shared Folder verwendet. Wie Shared Folders im Allgemeinen angelegt werden, beschreibe ich im Artikel "Shared Folders für die VirtualBox-VM". Was speziell den Fall mit dem .ssh-Verzeichnis angeht, muss beim Mounten -- um den "Bad owner or permissions"-Fehler zu vermeiden -- auf den Benutzernamen, die Benutzergruppe und die eingeschränkten Zugriffsrechte geachtet werden. Für den root User (ob man im Kontext einer Entwicklungs-VM als root arbeiten darf, sei dahingestellt) mit uid 0 der Gruppe mit gid 0 wird der Mount-Befehl etwa so aussehen:

mount -t vboxsf -o uid=0,gid=0,umask=077 sshkeys /root/.ssh

That's it! :)


18
Jan 13

Linux Terminal History

History ausgeben lassen

Die History lässt sich komplett mit dem Befehl

# history

ausgeben. Dabei die Zeilen sind durchnummeriert. Möchte man mehr, als lediglich einen Blick in die History werfen — beispielsweise sie verändern und wieder importieren, könnten die Zeilennummern stören. Kein Problem — mit sed und einem simplen regulären Ausdruck lässt sich eine saubere Liste von Befehlen erzeugen:

# history | sed 's/^[ ]*[0-9]*[ ]*//'

Vorsicht: Das Tool sed implementiert reguläre Ausdrücke nicht komplett. Ich habe mich nämlich erst gewundert, warum mein Ausdruck /^[\s]{2,4}[0-9]{1,3}[\s]{2}/ nicht funktioniert hat — schließlich hat konnte ich damit in einem Editor prima finden, was ich gesucht habe. Doch dann las ich im sed-Manual: “POSIX.2 BREs should be supported, but they aren’t completely because of performance problems.“.

Alternativ geht das mit cut:

# history | history | cut -c 8-

Der cut-Befehl schneidet hier einfach die ersten acht Zeichen der Zeile ab. Ob es mehr werden können, habe ich nicht weiter untersucht. Vermutlich aber theoretisch schon. Die Methode nit sed ist flexibler.

# history > /path/to/my/history.txt

History editieren/importieren

Die History wird in einer Text-Datei gespeichert. Deren Speicherort wird in der Umgebungsvariablen $HISTFILE gehalten. Üblicherweise is es ~/.bash_history.

# echo $HISTFILE
/root/.bash_history

Die History-Datei kann angepasst oder durch eine andere Datei ganz ersetzt werden. Dabei sollte man beachten, dass die Änderungen in der laufenden Terminal-Seeeion nicht sichtbar sind (offenbar greifen einzelne Terminal-Fesnter nicht direkt auf die ~/.bash_history zu, ondern auf eine Zwischengespeicherte Kopie, die beim Anlegen er Terminal-Session erzeugt wird).

History-Länge

Es gibt zwei Typen von History: die “allgemeine” History, die in der ~/.bash_history gespeichert wird, und die Session-History, die der History-Datei hinzugefügt wird, sobald das Terminal-Fenster geschlossen wird. Die maximale Länge der History-Datei ist in der Umgebungsvariablen HISTFILESIZE gehalten, die der Session-History — in der HISTSIZE.

# echo $HISTFILESIZE
500
# echo $HISTSIZE
500

Die Länge der gespeicherten Liste der verwendeten Befehle ist zwar begrenzt, kann aber geändert werden. Um sie dauerhaft zu setzen, kann man das export-Befehl, mit dem der Wert einer Umgebungsvariablen definiert wird, in die ~/.profile eingetragen werden, z.B::

export HISTSIZE=1000
export HISTFILESIZE=100000

Alles hier Beschriebene bezieht sich auf ein Debian 6.0.6 System.


15
Jan 13

Feste IP für eine Virtualbox-VM

In diesem Tutorial ist wunderbar beschrieben, wie man einer VirtualBox-VM eine statische IP zuweist. Auf meinem Guest-System Debian 6 (Squeeze) mit Gnome 2.30.2 sahen die Schritte jedoch teilweise anders aus.

Zunächst alles, wie im bereits erwähnten Tutorial beschrieben:

1. Unter VM-Settings → Network aktivieren wir zwei Netzwerkadapter und konfigurieren einen davon für NAT und den anderen für die Kommunikation mit dem Host ein.

VM-Settings-Network-Adapter-NAT

VM-Settings-Network-Adapter-HostOnly

2. Unter File → Preferences… → Network das Host-only Netzwerk einstellen. Die DHCP-Einstelleungen müssen leer gelassen werden.

VirtualBox-Settings-Network

VirtualBox-Settings-Network-HostOnlyNetwork-Adapter

VirtualBox-Settings-Network-HostOnlyNetwork-DHCPServer

3. Der Guest-Part lässt sich über das GUI hier konfigurieren:  Applications → System Tools → Network Tools → [Network device] Ethernet Interface (eth1) → [Button] Configure .

Debian-Settings-NetworkTools

Im Dialog “Network Connections” wählen wir den Eintrag “Auto eth1″ und klicken auf “Edit…”

Debian-Settings-NetworkTools-NetworkConnections

Weiterhin definieren wir eine Adresse und tragen die Konfigurationen für die Netzmaske und das Gateway ein.

Debian-Settings-NetworkTools-NetworkConnections-AuthoEth1

4. Die /etc/udev/rules.d/70-persistent-net.rules wird entfernt.

5. Als Letztes starten wir den Netzwerk-Service neu:

# /etc/init.d/networking restart

Alles hier Beschriebene bezieht sich auf die VirtualBox 4.2.6, ein Windows-7 Host-System und ein Guest-System mit folgenden Parametern:

# lsb_release -a
No LSB modules are available.
Distributor ID:    Debian
Description:    Debian GNU/Linux 6.0.6 (squeeze)
Release:    6.0.6
Codename:    squeeze
# gnome-about --gnome-version
Version: 2.30.2
Distributor: Debian
Build Date: 11/12/2010

14
Jan 13

Shared Folders für die VirtualBox-VM

Shared Folders ermöglichen es, auf einem einfachen Wege, einen Bereich zu definieren, auf den sowohl das Host- und das Guest-System gleichermaßen zugreifen können. Bei mir ist das v.a. mein Workspace-Verzeichnis auf dem Host, das für das Guest-System als Web-Root-Verzeichnis dient.

Hier ist eine Kurzanleitung:

1. In den Einstellungen einen gemeinsamen Ordner festlegen:

Shared-Folders-Defining-1

Shared-Folders-Defining-2

2. Guest Additions für die VM installieren.

Die Guest Additions sind VM-Zusatz-Features, die nach dem Aufsetzen des Guest-Systems installiert werden können. Zwar sind es “nur” Extras, aber, wie im VirtualBox-Manual steht, “for any serious and interactive use, the VirtualBox Guest Additions will make your life much easier by providing closer integration between host and guest and improving the interactive performance of guest systems.” Shared Folders sind eines dieser Zusatz-Funktionen.

Die Guest Additions lassen sich installieren, indem man im VM-Menü auf Devices → Install Guest Additions… geht und die wenigen Installationsschritte durchführt.

Guest-Additionals-Installation-1

Guest-Additionals-Installation-2

Laut der Guest Additions Installation HowTo, auf die ich unten verweise, braucht man noch einige Vorbereitungen zu treffen, ehe die Additions installiert werden können. Bei mir war dies nicht nötig.

Heute bin ich zufällig auf die einfachste Möglichkeit der Installation der GAs gestoßen. Beim Installationsprozess von Debian können Software-Pakete ausgewählt werden, die gleich mitinstalliert werden (SSH-Server, Web-Server, Datenbank etc.). Ich habe ausgewählt, was ich brauchte und auf “next” geklickt, musst dann aber wieder paar Schritte zurück gehen. Als ich aber wieder an dieser Stelle war, wurde mir anstatt der zu diesem Zeitpunkt bereits installierten SSH-, Web-Server etc. die GAs vorgeschlagen. Nach der Installation brauchte mich nicht mehr um diesen Part zu kümmern — alles hat auf Anhieb funktioniert.

3. Gemeinsamen Ordner einbinden.

Jetzt muss das gemeinsame Verzeichnis nur gemountet werden:

mount -t vboxsf -o uid=1000,gid=1000 workspace /var/www

Möchte man seinen ~/.ssh Ordner als SF haben, muss genau auf die Parameter uid (user ID) und gid (group ID) geachtet werden. Sonst ist es, wenn man auf der VM als root:root arbeitet, nicht rforderlich, aber in dem Fall schon. Außerdem muss dem mount-Befehl ein weiteres Argument (umask) mitgegeben werden, um die Zugriffsrechte auf ~/.ssh einzuschränken:

mount -t vboxsf -o uid=0,gid=0,umask=077 sshkeys /root/.ssh

Sonst können die SSH-Keys nicht verwendet werden:

# git clone git@github.com-user:user/project.git
Cloning into project...
Bad owner or permissions on /root/.ssh/config
fatal: The remote end hung up unexpectedly

Damit man das nicht jedes Mal von Hand machen muss, wird der mount-Befehl in die /etc/rc.local (vor dem exit 0) eingefügt. Alternativ geht das über die /etc/fstab.

Alles hier Beschriebene bezieht sich auf die VirtualBox 4.2.6, ein Windows-7 Host-System und ein Guest-System mit folgenden Parametern:

# lsb_release -a
No LSB modules are available.
Distributor ID:    Debian
Description:    Debian GNU/Linux 6.0.6 (squeeze)
Release:    6.0.6
Codename:    squeeze
# gnome-about --gnome-version
Version: 2.30.2
Distributor: Debian
Build Date: 11/12/2010

14
Jan 13

Gnome-Login als root auf Debian

Auf einer realen Maschine sollte man sich nicht als Superuser anmelden. Doch bei einer VM ist es keine Sünde, mit root zu arbeiten. Dabei erleichtert das einem die Arbeit (man braucht kein “sudo”; Systemdateien lassen sich mit einem GUI-Editor berarbeiten, ohne dass dieser erst über die Konsole gestartet werden muss, etc.).

Meldet man sich übers GUI an, kann man — anders als bei der Konsolen-Anmeldung — nicht ohne Weiteres “root” als Login-Namen angeben. Diese Option ist per Default ausgeschaltet und muss aktiviert werden, indem in der /etc/pam.d/gdm3 die Zeile

auth   required        pam_succeed_if.so user != root quiet_success

auskommentiert wird.

Alles hier Beschriebene bezieht sich auf ein System mit folgenden Parametern:

$ lsb_release -a
No LSB modules are available.
Distributor ID:    Debian
Description:    Debian GNU/Linux 6.0.6 (squeeze)
Release:    6.0.6
Codename:    squeeze
$ gnome-about --gnome-version
Version: 2.30.2
Distributor: Debian
Build Date: 11/12/2010

14
Jan 13

Eigene CSS-Klassen im TinyMCE von WordPress

Es gibt mehrere Möglichkeiten, eigene CSS-Klassen in den WordPress-Editor einzubinden. Die einfachste, wie ich finde, bietet das Plugin Custom Editor Styles. Es muss wohl mehrere Plugins mit diesem Namen geben. Denn das Custom Editor Styles Plugin, von dem hier die Rede ist, ist nicht auf der offiziellen WP-Plugn-Seite zu finden und hat mit dem Custom Editor Styles offenbar nichts zu tun.

Vorgehen:

1. Klassen-DropDown im TinyMCE anzeigen lassen (z.B. mit TinyMCE Advanced).

2. Das Plugin Custom Editor Styles von Aliso the Geek‘s Seite herunterladen (Link zum Artikel; Download-Link).

3. Das ZIP-Archiv unter /wp-content/plugins/ entpacken.

4. Das Plugin im WP-Backend aktivieren.

5. Elemente im Array der in der /wp-content/plugins/custom-editor-styles/custom-editor-styles.php befindlichen tiny_mce_before_init(…) definieren (s.u.).

public function tiny_mce_before_init( $settings ) {
	$style_formats = array(
		array(
			'title'		=> 'My Block',
			'block'		=> 'div',
			'classes'	=> 'myClass',
			'wrapper'	=> true
		),
		...
	);
	...
}

Klassen in der /wp-content/plugins/custom-editor-styles/custom-styles.css definieren (s.u.).

div.myClass {
	background: #cc0000;
}

12
Jan 13

Mit grep Dateien durchsuchen

Das einfachste Beispiel:

# grep 'string' *

Rekursive (-r oder –recursive), Case-insensitive (-i oder –ignore-case) Suche mit Dateiliste (-l oder –files-with-matches) als Output:

# grep -lir 'string' *

Textsuche in Dateien nach Dateitypen/-Namen einschränken (mit include oder exclude):

# find ./ -type f -name '*.php' -exec grep -li 'string' {} \;
# grep -lir --include='*.php' --include='*.js' 'string' .
# grep -lir --exclude=*.css --exclude=*.html 'string' .

If all the links remain blue and you don't get an alert box, visit one of the links on the list and refresh the page.