Virtualbox für eine Entwicklungs-Umgebung verwenden

Samstag, 10. Oktober, 2020

Wenn man auf seiner lokalen Maschine entwickelt - aber seinen Code auf mehreren Betriebsystemen - oder unterschiedlichen Software-Versionen - sei es z.B. Programmiersprache (Ruby, NodeJs, PHP) oder Datenbankversion - dann braucht man verschiedene Testsysteme. Der eine mag Docker bevorzugen … ich beschreibe die Variante mit Virtualbox, weil dies über Linux und Windows für Clients als auch Ziel-VMs durchmischt funktioniert.

— Virtualbox.

Virtualbox ist kostenlos und OpenSource. Es existiert für Windows, Mac, Linux und Solaris.

In der Virtualbox habe ich je 1 VM mit einer Linux-Instanzen installiert (Debian, CentOS). In der VM ist das Setting installiert, was ich zum Testen heranziehen möchte.

  • Zum einen SSH, damit ich von der Konsole auf die VM komme - ohne dass ich über das “Fenster” der VM gehen muss.
  • Und dann Webserver, Programmiersprache, Module, Libraries … und was es sonst auf dem Zielsystem braucht.

— Dateien der Applikation

Was hingegen NICHT in der VM ist, ist die Applikation / Webseite: diese ist lokal bei mir auf dem Rechner. Ich nenne es mal abstrakt: web1.example.com.

[meine Webs]               <<< Basisverzeichnis aller meiner Webseiten
  |
  +-- ...
  +-- web1.example.com     <<< Verzeichnis ist Name der Webseite/ Applikation
  |   |
  |   +-- ...
  |   +-- public_html      <<< jenes public_html ist DOCUMENT_ROOT der Webseite
  |   +-- ...
  +-- ...

Um diese Struktur in einer Virtualbox VM verfügbar zu machen, hat Virtualbox ein Feature der Shared Folders. Das lokale Verzeichnis meiner Webdaten wird dann automatisch ins Linux reingemountet und ist unter /media/sf_[Name]/ sichtbar.

Man könnte nun im Apache Httpd das Web als VHost einrichten und Document_root auf das /media Verzeichnis zeigen lassen. Ich mag es aber, wenn es an einem schönen Ort liegt. Daher lege ich unter /var/www einen Softlink namens web1.example.com an, der auf /media/sf_[Name]/web1.example.com/ zeigt.

Wenn man Linux-Systeme zum Testen braucht - z.B. Debian und CentOS - dann kann man die Apache Config auch lokal halten … und einen Softlink als /etc/apache2/sites-enabled bzw. /etc/httpd/conf.d anlegen.

Mit der lokal installierten IDE meiner Wahl kann ich dann lokal meine Dateien bearbeiten - und mit Speichern habe ich es 1:1 in einer gestarteten VM.

— Dienste

Zum Zugriff per SSH … oder auf das Web muss ich jede laufende VM ansprechen können - auf deren Port 80/ 443 resp 22.
Virtualbox kennt dazu in den Netzwerkeinstellungen der VM das Portmapping.

Es braucht eindeutige Ports, wenn man mehrere VMs laufen lassen und diese parallel ansprechen wollte, z.B. VM 1 leitet SSH von 8022 auf 22 um, VM 2 geht 1000 Ports hoch und leitet 9022 auf 22 um; Port 80 und andere analog SSH Login auf VM 2:

ssh -p 9022 localhost

Und beim Webbrowser? Und mehreren VHosts in der jeweiligen VM?

Man kann sich mit der /etc/hosts behelfen und die Namen der Domain auf 127.0.0.1 zeigen lassen

web1.example.com  127.0.0.1

Im Browser gibt man mit http://web1.example.com:[Port] das jeweilige Web an … und der Port steuert die Anfrage zur gewünschten VM.

Grafisch sieht das Ganze etwa so aus:

2020-10-10-virtualbox-devenv-axel.png

Viel Spass beim Nachbauen!

weiterführende Links:

  1. www.virtualbox.org/ (en)

Matomo-Javascript Tracking Code auslagern

Samstag, 3. Oktober, 2020

Matomo empfiehlt zum Tracken einer Webseite den Einbau des Codeschnipsels innerhalb des HTML Dokuments … im Head Bereich. [1]

Aber: das Hineinschreiben von Javascript Code in das HTML Dokument ist nicht so recht günstig, wenn man im CSP Security Header das Attribut script-src sicher und ohne unsafe-inline konfigurieren will. [3]

Die Abhilfe besteht darin, dass man [2]

  1. das Snippet in eine Javascript Datei auslagert.
  2. den Aufruf des Trackens im Onload Event einfügt - der ebenfalls in der Javascript-Datei ist und nicht im HTML-Code einer Webseite.

Hier einmal ist die Funktion embedTrackingCode benannt:

function embedTrackingCode() {
	var _paq = window._paq = window._paq || [];
	_paq.push(["trackPageView"]);
	_paq.push(["enableLinkTracking"]);

	var u="/matomo/";
	_paq.push(['setTrackerUrl', u+'matomo.php']);
	_paq.push(['setSiteId', 1]);

	var d=document, g=d.createElement("script"), s=d.getElementsByTagName("script")[0]; g.type="text/javascript";
	g.defer=true; g.async=true; g.src=u+"matomo.js"; s.parentNode.insertBefore(g,s);    
}

… welche bei Abschluss des Ladevorgangs initialisiert wird:

window.onload = (event) => {
	embedTrackingCode();
};

Hinweis:

Wenn der Tracking Code in einer Javascript-Datei ist, muss man das Http-Caching der JS Datei bei einem expires= im Http Response Header beachten. Man ist u.U. nicht mehr so flexibel, wenn man den Code anpassen wollte, weil Browser das Javascript aus dem Cache nehmen, statt frisch vom Server die angepasste Version zu holen. Man kann per ETag cachen lassen … oder kann die JS-Datei mit Versionsnummer benennen.

weiterführende Links:

  1. Matomo Guide: JavaScript Tracking Client (en)
  2. Matomo Blog: Different ways of embedding the Matomo tracking code for faster website performance (en)
  3. developer.mozilla.org: CSP Header - script-src (en)