Blog 73

Ich habe in letzter Zeit beruflich viel mit der Erzeugung und Anpassung von PAC-Dateien zu tun.
Wikipedia: Proxy auto-config

Grundsätzlich ist es dabei schon einmal eine gute Idee, wenn man die PAC-Dateien in einem Repository ablegt, sodass man Änderungen nachvollziehen kann.

Noch besser ist es, wenn man sie vor dem Einsatz testet. Beispielsweise mit Python und PyPAC

Nun hab ich mich aber gefragt, ob man das ProxyScript auch aus einer Deklaration heraus erstellen könnte, beispielsweise mit einer YAML-Datei. Das hätte den Vorteil, dass Kollegen die Ausnahmen leichter pflegen können. Sie müssten dafür kein JavaScript mehr verstehen.

Da ich Python mag, habe ich genau das mal mit Python versucht. Zu finden ist der Code bei Github. https://github.com/73h/paccreator

Eine YAML-Datei sieht nun beispielsweise so aus. Man erfasst die Proxies und die entsprechenden Ziele. Dann benötigt man noch einen Default-Proxy und den Rest macht Python.

example.yaml:
description: My proxy script version: 1.0 proxies: - description: take the direct route route: DIRECT tags: - default # default proxy targets: - .example.com - description: take the proxy route route: PROXY company.example.com targets: - example.com - foo.example.com - 93.184.0.0/16

Mit wenigen Zeilen Python, kann man nun den Inhalt der PAC-Datei erzeugen.

import os from paccreator import PacCreator p = PacCreator() with open(os.path.join("example.yaml"), "r") as f: p.load_from_yaml(f.read()) print(p.output())

Und das Ergebnis sieht dann so aus. Das geschulte Auge erkennt vielleicht die Besonderheit, dass es eine Überschneidung der Ziele gibt. Das wird sogar beachtet und entsprechend umsortiert. So ist die Bedingung auf .example.com nach unten gerutscht. Würde sie als erstes kommen, würde sie auch foo.example.com schlucken. Auch die Übersetzung der Netzmaske 93.184.0.0/16 erleichtert die Pflege.

Das Ergebnis - example.pac:
function FindProxyForURL(url, host) { host = host.toLowerCase(); if ( localHostOrDomainIs(host, "example.com") || localHostOrDomainIs(host, "foo.example.com") || isInNet(host, "93.184.0.0", "255.255.0.0") ) { return "PROXY company.example.com"; } if ( dnsDomainIs(host, ".example.com") ) { return "DIRECT"; } return "DIRECT"; }

Mein Fazit nach ein paar Stunden Arbeit. Es geht und ich werde den Ansatz weiter verfolgen. Klar ist aber auch, das man hier nicht alles oder jede Varianz abbilden kann. Dennoch wird es für die meisten Proxy-Skripte reichen denke ich.

Ich baue ein Haus und dafür habe ich einen kleinen Weblog in PHP programmiert. Der Blog sollte kein aufwendiges CMS beinhalten und für mich und meine Partnerin möglichst einfach zu bedienen sein.

Vor allem Bilder, die man meist mit dem Handy macht, sollten möglichst leicht im Weblog bereitgestellt werden können ohne sie beispielsweise erst auf den Computer ziehen zu müssen oder Ähnliches.

Die Lösung

Ich hatte bereits in der Vergangenheit mit der Telegram-API interagiert und hab meine Lösung darauf aufgebaut. So kann man beispielsweise ein Bild auf dem Handy einfach mit dem Telegram-Bot teilen, als würde man es Jemanden schicken. Der Bot sendet das Bild dann per Webhook an den Weblog und der speichert das Bild in einer Datenbank. Im Anschluss fragt der Bot noch nach einem Bildtitel per Chat und man antwortet einfach darauf. Leichter kann man ein Bild nicht in ein CMS laden.

Ich habe weitere Funktionen mit dem Telegram-Bot umgesetzt. Schaut dafür einfach im Blog selbst oder in das Github-Projekt.

Das Projekt auf Github: https://github.com/73h/hausblog

Der Weblog: https://haus.jessiheiko.de

Diesen Blog hoste ich in Googles App Engine.

Meine Secrets (z.B. Passwörter), aber auch Konfigurationsparameter, habe ich bei der Entwicklung in einem .env-File. Um die Environment-Variablen auch produktiv in der App Engine verwenden zu können, musste ich diese in die app.yaml schreiben, die für das Deployment verantwortlich ist. Das sieht dann so aus.

Ausschnitt app.yaml
env_variables: SECRET_ONE: abc123 ANOTHER_SECRET: passwort

Jetzt wollte ich das Deployment automatisch per Github-Action umsetzen, sodass ich nicht immer manuell veröffentlichen muss. Damit konnte ich die Secrets nun aber nicht mehr in die app.yaml schreiben, denn die sollen ja nicht im Repository landen.

In Github kann man Secrets für Projekte hinterlegen und diese dann beim Deployment verwenden. Ich muss also die Secrets in der app.yaml während des Deployments ersetzen.

Nach einigen Versuchen im Projekt selbst, hab ich dafür eine Github-Action mit Python geschrieben. Die Github-Action ersetzt die Secrets für mich und ich kann sie wiederverwenden.

Und so nutze ich die Github Action.

Zunächst ersetze ich die Secrets im App-Engine-Deployment-File durch Variablen mit einem $.

Ausschnitt app.yaml
env_variables: SECRET_ONE: $SECRET_ONE ANOTHER_SECRET: $ANOTHER_SECRET

Im Anschluss füge ich im Github-Workflow die Action 73h/gae-app-yaml-replace-env-variables@v0.3 und ebenfalls die env-Variablen ein. Dabei verweise ich durch die ${{ secrets.XXX }} Notation auf die Github Secrets.

Ausschnitt workflow.yml
steps: - uses: actions/checkout@v2 - uses: 73h/gae-app-yaml-replace-env-variables@v0.3 env: SECRET_ONE: ${{ secrets.SECRET_ONE }} ANOTHER_SECRET: ${{ secrets.ANOTHER_SECRET }}

Und das war es auch schon. Die Secrets werden während des Deployments ersetzt.

Als Corona aufkam und viele von uns plötzlich von zuhause arbeiten mussten, mussten wir auch das Scrum-Poker online durchführen. Karten in die Kamera halten ist nicht wirklich gut, deshalb habe ich nach Lösungen gesucht. Es gab zwar schon einige Online-Lösungen, aber diese Lösungen waren zu Beginn von Corona nicht wirklich einfach und schön.

Also habe ich selbst ein Online-Scrum-Poker entwickelt, ganz einfach und ohne viel Schnick Schnack.

Ich habe dabei größtenteils auf Paket-Abhängigkeiten verzichtet. Dies ist kein Urteil darüber, wie man mit Abhängigkeiten in Projekten umgeht, sondern ich hatte einfach Spaß daran, die Dinge selbst zu entwickeln.

Und hier gehts zum Scrum Poker.

Wenn Dich der Quellcode interessiert, findest Du ihn github.com.