Vortrag "Apache Konfiguration" online
Mein Vortrag "Apache Konfiguration" bei dem ich versucht habe zu vermitteln "Warum ein Apache tut was er tut und wie man ihn dazu bringt auch das zu tun was man will" beim Treffen der PHPUG Stuttgart am 14.07.2010 ist online.
(Navigieren in den slides mit Space,Pfeilen usw.) Ein besonderen Dank auch noch mal an Harald Amelung vom Coworking0711 für die Möglichkeit jetzt dort unsere Vorträge halten zu können. Wir kommen gerne wieder!
Autor: Jens Giessmann
in Apache, PHPUG
am
Dienstag, 20. Juli 2010
um
09:02
Kommentare (0) | Trackbacks (0) PHPUG Stuttgart Treffen, Juli 2010
Wie jeden 2. Mittwoch im Monat, gibt es auch im Juli 2010 wieder ein Treffen der PHPUG Stuttgart.
Als Vortrag gibt's was zum Thema: "Apache Konfiguration". Und da mich keiner davon abgehalten hat, werde ich diesen Vortrag halten und mich mal wieder bemühen das Thema irgendwie in einen 60-90min Vortrag zu packen. Vermitteln will ich dabei, warum ein Apache tut was er tut und wie man ihn dazu bringt auch das zu tun was man von ihm haben will. Wie immer ist jede(r) eingeladen zu kommen, wir freuen uns immer über neue Gesichter. Da wir ab diesem Treffen einen neuen Raum für die Vorträge haben, bitte die neue Adresse beachten! Termin: 14.07.2010, 19:00 Uhr Ort: Coworking0711 (Heilbronner Straße 7, 70174 Stuttgart). Weitere Infos zum Vortrag und zur PHPUG an sich finden sich wie immer auf www.phpugs.de Domain- und Pfad-Abhängigkeiten vermeiden
Manchmal frage ich mich schon, warum manche Webentwickler es sich (und anderen) so schwer machen...
Wenn man eine Webapplikation erstellt, dann macht man das ja (hoffentlich!) auf einer Testplattform, also meist unter einer Test-Subdomain. Wenn auf der Testplattform dann alles funktioniert, fertig und getestet ist, geht der ganze Kram unter der richtigen Domain live. Alles ganz einfach, sollte man denken... ABER: Immer wieder wird an diversen (meist völlig unnötigen!) Stellen die Domain unter der die Applikation gerade läuft, hart rein kodiert, was dazu führt, daß man an genau diesen Stellen noch mal hinfassen muss damit die tolle Applikation auch unter einer anderen Domain läuft. Meist muss es dann aber irgendwann ganz schnell gehen, der Mensch der sich damit auskennt ist krank, hat Urlaub oder ist vom Bus überfahren worden, was dazu führt, dass es beim Switch auf eine andere Domain kracht, weil eben "irgendwo" noch die Test-Domain drin steht. Beliebte Stellen für so was sind: - include Pfade - <base> Tags in HTML-Headern - Configs für dynamisch erzeugte URLs Hatte hier eben wieder mal ein schönes Beispiel dafür wie man es nicht machen sollte. Kunde hat sich von einer Webagentur seine Seiten neu machen lassen. Es gibt 4 Domains die auf die Seiten zeigen sollen, .de als Hauptdomain, .com für die englischen Inhalte und 2 weitere Domains mit Varianten der Schreibweise. Für die Entwicklung der neuen Seiten haben wir einen weiteren virt. Server unter einer dev. Subdomain eingerichtet. Wenn die neuen Seiten fertig sind, soll nur noch der DNS umgestellt werden, die Apache-Config im dev. virt. Server war schon für die 4 "richtigen" www. Domains vorbereitet. Jetzt sind die neuen Seiten fertig und es soll umgestellt werden. Weil heute ein "SuperWichtigEvent" ist, bei dem die neuen Seiten vorgestellt werden sollen, muss es natürlich wieder mal ganz schnell gehen. Kein Problem denkt man sich, DNS umstellen und gut ist... Falsch, gar nix ist gut. Da die App bisher nur unter der dev. Subdomain funktioniert, bekommt man unter allen 4 Domains nur das (eh schon fragwürdige) FlashIntro zu sehen. Dann ist Schluss, kein "skip" oder "weiter" Link, einfach nichts. Also kurzerhand für die 4 www. Domains Redirects auf die dev. Subdomain eingerichtet. Ist zwar nicht schön, funktioniert aber erst mal, wir erinnern uns: Heute ist der "SuperWichtigEvent", es muss also auf jeden Fall "irgendwie" laufen. Mail an die Webagentur, sie mögen das doch bitte fixen und uns dann Bescheid geben, wann und wie wir welche Domain auf die Seiten zeigen lassen sollen (ServerAlias, Redirect,...) Prompte Antwort: "Jetzt tut es, wir mussten nur noch $wasauchimmer umstellen. Bitte Redirects rausnehmen und alle 4 Domains als Alias einrichten. Die App entscheidet dann intern was für welche Domain angezeigt wird" Kein Problem, also wieder umgestellt. Ergebnis: Die .de Hauptdomain funktioniert jetzt immerhin, bei der .com gibt es immer noch nur das FlashIntro, das jetzt aber schon mal mit "weiter" Link. Wenn man auf den klickt wird aber nur noch mal das Intro abgespielt. Bei den beiden anderen Domains bekommt man jetzt nur noch eine Fehlerseite angezeigt, die einem sagt, dass die App mit den Domains mal so gar nix anfangen kann... Mail an die Agentur da sei wohl immer noch was nicht ganz korrekt... Wieder die schnelle Antwort: " Jetzt aber, wir mussten noch....." Nunja, ich weiss ja nicht was die getestet haben, bei mir funktioniert es immer noch nicht unter allen 4 Domains, aber wer bin ich schon. Und solange man mir nicht sagt was genau gewünscht ist, kann ich auch nicht mehr weiter helfen... Liebe Webentwickler: Das muss nicht sein! Es gibt ENV-Vars in denen aktuelle Pfade, ServerName, usw. stehen. Diese muss man aber eben auch (sinnvoll) verwenden damit die tolle Webapplikation auf verschiedenen Systemen unter verschiedenen Domains läuft OHNE dass man irgendwo hinfassen muss. Wenn man Redirects haben will, dann kann man die ganz einfach in der Websever-Config einrichten, daß muss man nicht mit wilden if/else Konstrukten hart kodiert in der App machen. Für verschiedene Sprachen bieten sich z.B. Prefixe in der URL an (/de/, /en/,...). Auf die kann man dann ganz einfache Redirects einrichten. Und wenn die App anhand der Domain verschiedene Inhalte anzeigen soll, sollte man zumindest immer einen Fallback drin haben, damit wenigstens "irgendwas" angezeigt wird. Den Grundsatz "Abhängigkeiten vermeiden" sollte man eben immer, nicht nur bei super-cooler OOP (Stichwort Dependency Injection) im Kopf haben...
Autor: Jens Giessmann
in Webdev
am
Mittwoch, 17. Februar 2010
um
10:33
Kommentare (0) | Trackbacks (0) OS X: sshd aktivieren
Netterweise ist ein OS X in der Default-Config recht dicht, will sagen, da ist nach aussen kein unsinniger Port offen wie es ja bei anderen OSen schon vorgkommen sein soll...
Allerdings will man sich ja vielleicht mal per ssh auf das gute Stück einloggen. Dazu muss dann erst mal ssh freigegeben werden. Das kann man auf 2 Arten machen:
- Eintrag in /etc/hostconfig
SSHSERVER=-YES-
- Über die Sys-Preferences,
-> Sharing
-> Remote Login aktivieren
OS X: Hostname setzen
Der Default Hostname unter OS X, den man auch im Prompt des Terminals angzeigt bekommt, hat ja in der Regel nix mit einem vernünftigen Rechnername zu tun.
Bei mir stand da z.B. irgendsowas wie "Jens Giessmanns Macbook". Ahja.... Einen vernünftigen Hostname setzt man, indem man einen Eintrag in der Datei /etc/hostconfig macht: HOSTNAME=mac.handcode.de
(Seite 1 von 2, insgesamt 6 Einträge)
» nächste Seite
|
blog powered by Serendipity

