SSH Config Datei: bequemen Shortcut für remote Verbindungen erstellen

Manchmal machen SSH-Verbindungen einfach keinen Spaß! Man verbindet sich immer zum gleichen Server und muss jedesmal einen ellenlangen Shell-Befehl im Terminal eintippseln. Hier beschreibe ich, wie man einfach einen Shortcut erstellt.

Statt sich jedes Mal an alle Einstellungen erinnern zu müssen und dann so etwas wie ssh -luser0815 -p 2222 host4711.example.com eingeben zu müssen, reicht es plötzlich ssh myserver zu tippseln. Boom. Verbunden. Fertig.

Dazu erstellt man zunächst folgende Datei ~/.ssh/config und öffnet diese in einem Texteditor seiner Wahl. Folgendermaßen sieht eine Beispielkonfiguration aus, die sich glaube ich von selbst erklärt.

Host myserver
	HostName host4711.example.com
	Port 2222
	User user0815

	ServerAliveInterval 30
	ServerAliveCountMax 120

Host github.com
	IdentityFile ~/.ssh/mygithubkey_rsa

Host tunnel
	HostName database.example.com
	User dbuser
	IdentityFile ~/.ssh/rsa_id
	LocalForward 9906 127.0.0.1:3306
	# forwards local port 9906 to remote port 3306
	# activate tunnel with: ssh -f -N tunnel
	# -f puts ssh in background
	# -N makes it not execute a remote command

Das spart nicht nur viel Zeit und Tipperei, sondern auch Befehle wie rsync werden viel übersichtlicher zu konfigurieren. als remote server kann einfach der hier angegebene Host verwendet werden.

Alle Details zum SSH Config File finden sich auf der zugehörigen man page (Wenn der Link nicht funktioniert installiere das super praktische Bwana).

Meine Quelle ist ein Artikel auf nerderati.com. Dort finden sich noch mehr Details zur SSH config Datei.

table_prefix einer WordPress Installation ändern

Ein Mangel an Datenbanken in meinem Tarif bei meinem Lieblings-Hosting-Anbieter hat mich dazu gezwungen zwei WordPress-Installationen in eine gemeinsame Datenbank zu schieben. Da die zu ergänzende Installation bei mir lokal eine eigene Datenbank hatte, musste eine Änderung der table_prefix Konfiguration von WordPress her. Nachdem ich zunächst stumpf versucht habe, den table_prefix von WordPress in der Konfigurationsdatei zu ändern und die Tabellen umzubenennen, habe ich feststellen müssen, dass es noch weiterer Schritte bedarf den table_prefix einer bestehenden WordPress-Installation zu ändern. Nach etwas googlen bin ich auf den Beitrag „6 Simple Steps to Change Your Table Prefix in WordPress“ gestoßen, der den Weg anschaulich erklärt.

Ich fasse kurz zusammen:

  1. Backup machen, sicherheitshalber alle Plugins deaktivieren.
  2. table_prefix in wp-config.php nach belieben ändern.
  3. Tabellen entsprechend umbenennen:
    RENAME TABLE wp_commentmeta TO myTablePrefix_commentmeta;
    RENAME TABLE wp_comments TO myTablePrefix_comments;
    RENAME TABLE wp_links TO myTablePrefix_links;
    RENAME TABLE wp_options TO myTablePrefix_options;
    RENAME TABLE wp_postmeta TO myTablePrefix_postmeta;
    RENAME TABLE wp_posts TO myTablePrefix_posts;
    RENAME TABLE wp_terms TO myTablePrefix_terms;
    RENAME TABLE wp_term_relationships TO myTablePrefix_term_relationships;
    RENAME TABLE wp_term_taxonomy TO myTablePrefix_term_taxonomy;
    RENAME TABLE wp_usermeta TO myTablePrefix_usermeta;
    RENAME TABLE wp_users TO myTablePrefix_users;
    
  4. wp_user_roles in vormals wp_options entsprechend umbenennen.
  5. In der früheren Tabelle wp_usermeta alle Einträge in der Spalte meta_key die mit wp_ beginnen entsprechend umbenennen.
    SELECT * FROM myTablePrefix_usermeta WHERE meta_key LIKE 'wp_%';
  6. Fertig. Plugins wieder aktivieren und alles testen.

Der Hinweis im Artikel auf die Sicherheit durch Verwenden eines anderen table_prefix, als des Standardmäßigen klingt logisch. Der Prefix sollte jedoch vielleicht nicht ganz leicht zu erraten sein, aber ganz so kompliziert wie dort, muss man den table_prefix meiner Meinung nach dann doch nicht wählen. Ein Angriff bei dem eine größere Zahl table_prefix Einstellungen durchprobiert wird, halte ich dann doch für eher unwahrscheinlich, ich lasse mich jedoch gern eines Besseren belehren.

Mac OS X: Apache und FileVault – 403 Forbidden Error

Nach der installation von Snow Leopard auf meinem MacBook habe ich mich dazu entschlossen die mitgelieferten Versionen von Apache und PHP zu verwenden. Ich habe dazu eine sehr übersichtliche Anleitung zur Installation von Apache, PHP und MySQL auf Mac OS X 10.6 „Snow Leopard“ gefunden. Leider war es mir damit jedoch nicht möglich auf meinen Websites-Ordner im Home-Verzeichnis zuzugreifen. immer wieder tauchte der Fehler 403 Forbidden auf. Es hat lange gedauert, bis ich darauf gekommen bin, daß meine Entscheidung für die Verschlüsselung meines Home-Verzeichnisses mittels FileVault die Ursache für diesen Fehler ist.

Google hat mich zu einer Lösung von Mac OS X Hints geführt, die ich hier für Snow Leopard angepaßt und reduziert wiedergebe.

The following statement grants the user _www the right to look into known sub-directories, provided their permissions allow such access:

chmod +a "_www allow search" /Users/username

You can check the ACLs by using the ls command with the -e option:

ls -alske /Users

Jetzt muß nur noch sichergestellt sein, daß das Verzeichnis ~/Sites Lese- und Schreibrechte für Other hat. Das geht mit dem Befehl chmod -R o+rwX ~/Sites/
Jetzt funktioniert der Apache von Snow Leopard problemlos zusammen mit FileVault. Das der Nutzer _www jetzt in mein Home-Directory gucken kann sehe ich nicht als Sicherheitsproblem an. Erstens können nur Verzeichnisse mit Leserechten für die Welt (Other) angeguckt werden, zweitens sehe ich FileVault weniger als Schutz bei laufendem System, sondern vielmehr als Datenschutz bei Verlust meines Rechners.

phpMyAdmin Hinweis „zusätzliche Funktionen deaktiviert“ deaktivieren

Nach der Installation von phpMyadmin erscheint i.d.R. folgernder Hinweistext auf allen Seiten:

Die zusätzlichen Funktionen für verknüpfte Tabellen wurden automatisch deaktiviert. Klicken Sie hier um herauszufinden warum

Diese Zusatzfunktionen habe ich noch nie benötigt, daher verunsichert die Warnung nur die Benutzer. Deaktiviert wird die Meldung wie folgt:

Ändere (oder ergänze) in der Datei ./config.inc.php die folgende Einstellung: $cfg['PmaNoRelation_DisableWarning'] = TRUE;

Voilà, die Meldung ist verschwunden!

WordPress Blog Domain ändern

Oft steht man vor dem Problem, ein WordPress Blog von einer Domain zur anderen umziehen zu müssen. Sei es, daß man sich für eine andere Domain entscheidet, oder man das zu Hause auf localhost entwickelte Blog online stellen will. Ursache für die Schwierigkeiten ist, daß WordPress Links zu internen Artikeln nicht relativ, sondern absolut speichert. Es müssen also alle Links geändert werden. Nach verschieben aller Dateien und eventuellem Anpassen der Dateien wp-config.php und .htaccess, hilft folgendes Fundstück ungemein weiter:

To update WordPress options with the new blog location, use the following SQL command:

UPDATE wp_options SET option_value = replace(option_value, ‚http://www.old-domain.com‘, ‚http://www.new-domain.com‘) WHERE option_name = ‚home‘ OR option_name = ’siteurl‘;

After that you will need to fix URLs of the WordPress posts and pages, which translated from post slug, and stored in database wp_posts table as guid field. The URL values in this field are stored as absolute URLs instead of relative URLs, so it needs to be changed with the following SQL query:

UPDATE wp_posts SET guid = replace(guid, ‚http://www.old-domain.com‘,’http://www.new-domain.com‘);

If you have linked internally within blog posts or pages with absolute URLs, these links will point to wrong locations after you move the blog location. Use the following SQL commands to fix all internal links to own blog in all WordPress posts and pages:

UPDATE wp_posts SET post_content = replace(post_content, ‚http://www.old-domain.com‘, ‚http://www.new-domain.com‘);

via How to Move WordPress Blog to New Domain or Location » My Digital Life.

WordPress Blog zu neuer Domain verschieben

Wenn man ein WordPress-Blog auf einem lokalen Webserver erstellt und/oder wartet, steht man immer wieder vor dem Problem, daß viele Konfigurationen und Links wegen der veränderten Domain nicht mehr funktionieren. Der Grund ist, daß WordPress leider absolute statt relativer URLs in der Datenbank speichert. Erfreulicherweise habe ich jetzt eine Lösung gefunden, wie man diese absoluten Links ändern kann:

To update WordPress options with the new blog location, use the following SQL command:

UPDATE wp_options SET option_value = replace(option_value, 'http://www.old-domain.com', 'http://www.new-domain.com') WHERE option_name = 'home' OR option_name = 'siteurl';

After that you will need to fix URLs of the WordPress posts and pages, which translated from post slug, and stored in database wp_posts table as guid field. The URL values in this field are stored as absolute URLs instead of relative URLs, so it needs to be changed with the following SQL query:

UPDATE wp_posts SET guid = replace(guid, 'http://www.old-domain.com','http://www.new-domain.com');

If you have linked internally within blog posts or pages with absolute URLs, these links will point to wrong locations after you move the blog location. Use the following SQL commands to fix all internal links to own blog in all WordPress posts and pages:

UPDATE wp_posts SET post_content = replace(post_content, 'http://www.old-domain.com', 'http://www.new-domain.com');

Quelle: My Digital Life: How to Move WordPress Blog to New Domain.

Das gleiche gilt natürlich auch, wenn man mit einem WordPress-Blog zu einer neuen Domain umziehen möchte.