MAMP und VirtualHostX

Wer auf dem Mac ein wenig Webentwicklung betreibt und sich nicht den Tag mit tausend kryptischen Unix-Befehlen versauen will, kommt um zwei kostenlose Programme kaum herum.

Das erste ist selbstverständlich MAMP, seit vielen Jahren bekannt und beliebt. Mit diesem Tool lässt sich mittels zwei Mausklicks eine komplette Server-Infrastruktur etablieren: Apache, PHP, MySQL und sogar SQLite können auf Knopfdruck aktiviert und auf beliebige Verzeichnisse des Systems gemappt werden. Meine Praxistipps:

  • Den vorinstallierten Apache-Server von Mac OS X deaktivieren (Systemeinstellungen > Sharing > Web-Sharing)
  • Die einzelnen Web-Projekte jeweils als Ordner innerhalb von /Users/nutzername/Sites ablegen (wo sie auch hingehören)
  • Die Ports von MAMP mit den Standard-Werten :80 (für Apache) und :3306 (für MySQL) belegen. Man muss dann zwar bei jedem Aktivieren und Deaktivieren das Admin-Passwort eingeben, aber wer will schon so komische Ports wie :8888 und :8889 immer mit eingeben?

MAMP und VirtualHostX

Unser Server läuft nun und wir können lokal unsere Projekte anlegen und pflegen. Soweit, so gut. Allerdings hört der Server nun ausschließlich auf den Namen »localhost« oder »127.0.0.1«, was ja prinzipiell logisch ist. Doch gerade hier gibt es ein Problem mit vielen CMSen (allen voran WordPress), die diese (Development)-Basis-URL in großer Menge in der Datenbank ablegen – total doof!

Deswegen gibt es sogenannte Virtual Hosts. Diese Systemeinträge können beliebige URLs auf den localhost umleiten – ohne dass die Systemkomponenten dies merken. Die Anfragen gehen also nicht raus ins Internet, sondern landen automatisch auf dem aktiven Apache-Server von MAMP – eine feine Sache.

Und weil diese Systemeinträge ein wenig kryptisch und schwer zu lokalisieren sind, nimmt man dafür das praktische Tool VirtualHostX, welches einem diese Arbeit abnimmt. man kann dort beliebig viele Adressen umleiten (und zwar praktischerweise direkt zu den entsprechenden Unterverzeichnissen, wo sich die entsprechenden Projekte befinden – voila!

Nun kann ich so tun, als ob die Seite meines Kunden bereits online wäre, alles komplett fertig machen, und dann bei der Migrierung nur noch die Datein und die Datenbank aufspielen (jaja, und ggf. den internen Pfad des Servers anpassen)

18 Kommentare

Nico Wenig

Hm … hat mir die Server-Konfiguration ziemlich zerschossen. Scheint wohl nicht ganz ausgereift zu sein.

Christian

Naja, lokales entwickeln mit virtuellen Hosts ist so ne Sache… dem Kunden kann man das ganze dann immer erst Zeigen nachdem man alles auf dem eigentlichem Zielserver geschoben hat. Ich verstehe ja noch immer nicht warum es CMSe gibt die die URL hart im Editor eincoden, aber seis drum… wenn ich lokal entwickle mache ich meist über DynDNS virtuelle Hosts das macht die Seite über eine eigene Subdomain dann auch von extern einsehbar. Das Problem mit den hardcoded URLs behebt es aber natürlich nicht.

Ich glaube wenn ich mit solch einem CMS arbeiten müsste würde ich doch direkt dazu umsteigen und das Projekt direkt über den FTP-Server bearbeiten.

Aber ich scheine Glück zu haben das ich bisher nur mit fähigen CMSen arbeiten musste ;)

tboley

Mhm, neun Dollar für etwas, was ich mit zwei Dateien von Hand auch ohne Probleme kostenlos machen kann? Ich halte die Software eher für überflüssig.

Andi

danke für den tipp. zwar nutze ich mamp seit längerem nicht mehr, da ich eigentlich alle projekte online erstelle und bearbeite, aber man kann grundsätzlich nie wissen :)

Frank

Ich bearbeite die vhosts und die hosts Datei ebenfalls von Hand. Und das lokale Entwickeln und raus»stagen« ins Netz bei Meilensteinen war mir am Ende zu aufwendig: Mittlerweile gleichen sich meine Serverumgebungen mit der lokalen Entwicklungsumgebung zu 100% (Pfade etc.) und die Kunden hole ich per C-Name Record und DynDNS zu mir ins Büro (z. B. neu.kundendomain.de).

So können alle am System arbeiten (Text Kunde, Rest ich), ich bin deutlich entlastet und es passieren keine Schlunzenfehler wie vergessene Pfadänderungen mehr.

Nur online entwickeln mache ich aus 3 Gründen nicht:

1. Subversion
2. Backups (obwohl die Server natürlich sichern)
3. Geschwindigkeit und Netzabhängigkeit

macx

Ãœbrigens: Es gibt auch MAMP Pro. Das enthält MAMP plus die komplette Verwaltung, die du hier mit VirtualHostX abzubilden versuchst.
Die Hosts lassen sich bis ins kleinste Detail einstellen und optimieren, auch in Sicherheits- und Featurefragen. Das Teil ist Mörderumfrangreich, ermöglicht dir aber eine echte Simulation eines echten Webservers. Und das ist gerade bei php-Entwicklungen ungemein wichtig.

Das Technikwürze-Redesign entwickel ich deshalb lokal (inkl. WordPress und allem drum und dran) bei zurhilfenahme von MAMP Pro. Das ganze geht dann über SVN und einem Deploy auf den Live-Server.

Frank

MAMP Pro finde ich für den schleppenden Support und das merkwürdige und etwas verworrene »Drumrum« zu teuer.

Mit etwas Wissen über die Apache-Konfig kann man den normalen Mamp ebenfalls als eingeschränkt zugänglichen Produktivserver nutzen (ohne klaffende Scheunentore).

Das Technikwürze-Redesign ist übrigens sehr gut geworden :)

Martin

Ich frage mich immer, warum man MAMP einsetzen sollte, wenn doch in OS X schon ein Apache2 mit PHP5 integriert ist. Man muss lediglich in der /private/etc/apache2/httpd.conf (am besten zu erreichen mittels der Option »Gehe zu…« im Finder) die Zeile »#LoadModule php5_module …« auskommentieren sowie im Verzeichnis darüber (/private/etc/) die Datei php.ini.default in php.ini umbenennen. Schon läuft PHP auf dem integrierten Apachen.

Einen MySQL-Server für OS X kann man sich dann ja von mysql.org runterladen und installieren.

Stefan

Wer überwiegend Design macht, für den ist eine GUI oft was gutes, ich persönlich mache das auch lieber kurz selber. Ein Skript hilft einem dann auch die »tausend kryptischen Unix-Befehle« umgehen zu können.

Frank

@Martin: Weil z. B. beim OS X eigenen PHP keine gdlib mit dabei ist.

Dafür muss man auch wieder nachinstallieren, z. B. so.

Veit

Ich hatte mal nen kurzen Ausflug zum systemeigenen Apachen in OS X, bin dann aber wieder bei MAMP gelandet, weil es mein System sauber lässt.

In die MAMP-eigenen httpd.conf füge ich noch ein Include ein:

Include /Users/vl/Sites/vhosts.conf

und definiere mir dann in der vhosts.conf meine Projekte Port-basiert mit aufsteigender Portnummer:

Listen 8801
<VirtualHost *:8801>
DocumentRoot/Users/vl/Sites/Projekt1
</VirtualHost>

Listen 8802
<VirtualHost *:8802>
DocumentRoot/Users/vl/Sites/Projekt2
</VirtualHost>

So hab ich über die Ports auch von anderen Rechnern und virtuellen Maschinen (IE-Tests) Zugriff auf die Seiten. Nicht über localhost, sondern über den Rechenrnamen – bei mir vl.local:8801 o.ä.

Name-based geht nach dem Muster natürlich genauso einfach, wenn man das lieber mag.

Felix de Ruiter

Hallo Gerrit,

VirtualHostX wirkt sehr praktisch. Gibt es das auch für Windoof?

Liebe Grüße
Felix

paul

Gerrit, das Hintergrundbild hast du jetzt schon seit fast 14 Monaten! Wird’s nicht langsam mal Zeit für ein neues? Guck mal bei Desktoptopia

Anne-Kathrin

Das klingt praktisch.
Danke für den Hinweis, kannte ich nicht. Habe ich bisher auch nie gebraucht- komischerweise, scheint mir.
Egal – der Hinweis fehlt mir irgendwie:
wer sich heute an irgendsowas wie einen Server wagt, sollte eigentlich einen virtuellen Host auch per Hand eintragen können – einfach um es mal selbst gemacht und die ganzen Widrigkeiten kennengelernt zu haben.

Friedrich Gerken

Ich bin mit MAMP Pro sehr zufrieden! Die Investition hat sich für mich vollkommen gelohnt!

Nur am Rande: » Ultra Edit 15 gibt es bald für Mac und Linux«

http://www.ultraedit.com/company/blog/products/uex_development_update-3-09-09.html

Gruß Friedrich

Alex

Danke für den VirtualHostX-Tipp, Gerrit.

Philipp Maan

Ich gestalte meine Web-Applikationen stets so, dass sie nicht unbedingt einen eigenen V-Host brauchen, geht alles über einen selbst definierten root-Ordner in der WebApp-Konfiguration selbst..

Bin damit bisher immer gut gefahren, und hat mir einiges an Arbeit beim Veröffentlichen auf Uralt-Serverumgebungen geholfen.

VirtualHostX hat mir zwar gemeldet dass er meine MAMP-Installation gefunden hat, nichtsdestotrotz wurde mein config-File ebenfalls zerschossen und musste vom Backup wiederherstellen.

Michael Kaiser

Nach der Installation von VirtualHostX ließ sich mein MAMP-Apache nicht mehr starten. In der config fand ich einen fehlerhaften Eintrag. Aber auch nach Entfernen der Zeile wollte sich der Apache nicht mehr starten lassen. Ich habe ziemlich viel Zeit gebraucht um herauszufinden, dass VirtualHostX mir das OS X-eigene Websharing eingeschaltet hatte. Dabei hatte VirtualHostX die MAMP-Installation gefunden. Unberechenbarer Schrott.

Kommentar verfassen